- openldap-bugs - openldap.org

Re: (ITS#3952) Patch: 'make test' does not fail at all errors
by michael＠stroeder.com 18 Feb '09

18 Feb '09

Howard Chu wrote: > I suspect that all of these issues have been fixed in subsequent releases. Can > we close this? I don't know how to really test it and therefore I just believe your statement that it's fixed => no objections against closing this ITS. Ciao, Michael.

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by hyc＠symas.com 18 Feb '09

18 Feb '09

michael(a)stroeder.com wrote: > Quanah Gibson-Mount wrote: >> --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: >> >>> Full_Name: Michael Str?der >>> Version: 2.4.14 >>> OS: SLES 10 >>> URL: >>> Submission from: (NULL) (193.197.158.1) >>> >>> >>> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >>> authz-regexp configuration is correct in slapd.conf >> What makes you think this is a bug with OpenLDAP and not cyrus-sasl? > > Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 > which was running on the same machine before. With 2.3 when this file > was missing only this message was sent to syslog: "unable to open > Berkeley db /etc/sasldb2". Today it seg faults. What version of BDB was libsasl built with? What version was OpenLDAP built with? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by michael＠stroeder.com 18 Feb '09

18 Feb '09

Quanah Gibson-Mount wrote: > --On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: > >> Full_Name: Michael Str?der >> Version: 2.4.14 >> OS: SLES 10 >> URL: >> Submission from: (NULL) (193.197.158.1) >> >> >> If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the >> authz-regexp configuration is correct in slapd.conf > > What makes you think this is a bug with OpenLDAP and not cyrus-sasl? Hmm, I'm not really sure. But IIRC this didn't happen with OpenLDAP 2.3 which was running on the same machine before. With 2.3 when this file was missing only this message was sent to syslog: "unable to open Berkeley db /etc/sasldb2". Today it seg faults. Ciao, Michael.

1 0

Re: (ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by jclarke＠linagora.com 18 Feb '09

18 Feb '09

hyc(a)symas.com wrote: > jclarke(a)linagora.com wrote: > >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: CentOS >> URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi all, >> >> It seems that when adding syncrepl consumers to be->be_syncinfo, they are added >> in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete >> on cn=config from be->be_syncinfo, the nth entry in the list is removed, which >> is not the same one. >> > > Thanks for the patch, fixed in HEAD. > This ITS' subject was rather vague. Just for reference, this problem only affected in-memory structures, not the actual data in cn=config. Always solved by restarting slapd, thus.

1 0

Re: (ITS#3952) Patch: 'make test' does not fail at all errors
by Howard Chu 18 Feb '09

18 Feb '09

I suspect that all of these issues have been fixed in subsequent releases. Can we close this?

1 0

(ITS#5956) Unallocatable shm keys lock up slapd
by quanah＠OpenLDAP.org 18 Feb '09

18 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.14 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) If I set OpenLDAP to use an shm key, and the kernel is not configured to allow SHM keys of the size requested, slapd goes into an infinite loop trying to connect to the DB, and can only be stopped with a kill -9: Feb 17 15:06:53 tribes slapd[7683]: hdb_db_open: database "": shared memory env open failed, assuming stale env. Feb 17 15:06:53 tribes slapd[7683]: bdb(): shmget: key: 7: unable to create shared system memory region: Invalid argument Feb 17 15:06:53 tribes slapd[7683]: bdb(): PANIC: Invalid argument Feb 17 15:06:53 tribes slapd[7683]: bdb(): unable to join the environment is what it logs endlessly.

1 0

Re: (ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by hyc＠symas.com 17 Feb '09

17 Feb '09

jclarke(a)linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS > URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch > Submission from: (NULL) (213.41.243.192) > > > Hi all, > > It seems that when adding syncrepl consumers to be->be_syncinfo, they are added > in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete > on cn=config from be->be_syncinfo, the nth entry in the list is removed, which > is not the same one. Thanks for the patch, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 3:15 PM +0000 michael(a)stroeder.com wrote: > Full_Name: Michael Str?der > Version: 2.4.14 > OS: SLES 10 > URL: > Submission from: (NULL) (193.197.158.1) > > > If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the > authz-regexp configuration is correct in slapd.conf What makes you think this is a bug with OpenLDAP and not cyrus-sasl? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 12:42 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, February 17, 2009 8:34 PM +0000 > steve.langasek(a)canonical.com wrote: > >> >> --uAKRQypu60I7Lcqm >> Content-Type: text/plain; charset=us-ascii >> Content-Disposition: inline >> >> Here's the patch. > > Thanks! This fix has been applied to HEAD and RE24 for the 2.4.15 > release. In addition, I saw there were some missing ifdefs around another > OpenSSL specific bit of code that used to be covered in the old tls.c, so > I added that as well: > > <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls2.c.diff?h > ideattic=1&r1=text&tr1=1.8&r2=text&tr2=1.9&f=h> Sorry, ignore that bit. The comment in the code was wrong, rather than the code being wrong. I've removed the comment. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by quanah＠zimbra.com 17 Feb '09

17 Feb '09

--On Tuesday, February 17, 2009 8:34 PM +0000 steve.langasek(a)canonical.com wrote: > > --uAKRQypu60I7Lcqm > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > Here's the patch. Thanks! This fix has been applied to HEAD and RE24 for the 2.4.15 release. In addition, I saw there were some missing ifdefs around another OpenSSL specific bit of code that used to be covered in the old tls.c, so I added that as well: <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls2.c.diff?hide…> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5955) build failure with gnutls: error: .struct ldapoptions. has no member named .ldo_tls_crlcheck.
by steve.langasek＠canonical.com 17 Feb '09

17 Feb '09

--uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's the patch. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=no-crlcheck-for-gnutls Author: Steve Langasek <steve.langasek(a)canonical.com> OpenLDAP 2.4.14 doesn't build with GnuTLS due to a missed guard around a use of an OpenSSL-specific option. ITS #5955 Index: trunk/libraries/libldap/tls2.c =================================================================== --- trunk.orig/libraries/libldap/tls2.c +++ trunk/libraries/libldap/tls2.c @@ -562,6 +562,7 @@ } return ldap_pvt_tls_set_option( ld, option, &i ); } +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ i = -1; if ( strcasecmp( arg, "none" ) == 0 ) { @@ -575,6 +576,7 @@ return ldap_pvt_tls_set_option( ld, option, &i ); } return -1; +#endif } return -1; } @@ -638,9 +640,11 @@ case LDAP_OPT_X_TLS_REQUIRE_CERT: *(int *)arg = lo->ldo_tls_require_cert; break; +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ *(int *)arg = lo->ldo_tls_crlcheck; break; +#endif case LDAP_OPT_X_TLS_CIPHER_SUITE: *(char **)arg = lo->ldo_tls_ciphersuite ? LDAP_STRDUP( lo->ldo_tls_ciphersuite ) : NULL; @@ -764,6 +768,7 @@ return 0; } return -1; +#ifdef HAVE_OPENSSL_CRL case LDAP_OPT_X_TLS_CRLCHECK: /* OpenSSL only */ if ( !arg ) return -1; switch( *(int *) arg ) { @@ -774,6 +779,7 @@ return 0; } return -1; +#endif case LDAP_OPT_X_TLS_CIPHER_SUITE: if ( lo->ldo_tls_ciphersuite ) LDAP_FREE( lo->ldo_tls_ciphersuite ); lo->ldo_tls_ciphersuite = arg ? LDAP_STRDUP( (char *) arg ) : NULL; --uAKRQypu60I7Lcqm--

1 0

(ITS#5955) build failure with gnutls: error: struct ldapoptions has no member named ldo_tls_crlcheck
by steve.langasek＠canonical.com 17 Feb '09

17 Feb '09

Full_Name: Steve Langasek Version: 2.4.14 OS: n/a URL: Submission from: (NULL) (2001:1938:316:0:219:d2ff:fe76:2acb) Building OpenLDAP 2.4.14 with GnuTLS fails because an OpenSSL-specific option isn't properly #ifdefed in tls2.c: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c: In function ldap_pvt_tls_get_option: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c:642: error: struct ldapoptions has no member named ldo_tls_crlcheck /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c: In function ldap_pvt_tls_set_option: /home/devel/openldap/build-area/openldap-2.4.14/libraries/libldap/tls2.c:773: error: struct ldapoptions has no member named ldo_tls_crlcheck make[3]: *** [tls2.lo] Error 1 (Trivial) patch to follow.

1 0

RE: (ITS#5954) deleting one of several syncrepl consumers deletes thewrong one
by worganc＠nortel.com 17 Feb '09

17 Feb '09

LOL -----Original Message----- From: openldap-bugs-bounces+worganc=nortel.com(a)openldap.org [mailto:openldap-bugs-bounces+worganc=nortel.com@openldap.org] On Behalf Of jclarke(a)linagora.com Sent: Tuesday, February 17, 2009 3:05 PM To: openldap-its(a)openldap.org Subject: (ITS#5954) deleting one of several syncrepl consumers deletes thewrong one Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.

1 0

(ITS#5954) deleting one of several syncrepl consumers deletes the wrong one
by jclarke＠linagora.com 17 Feb '09

17 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.

1 0

(ITS#5953) slapd seg faults with SASL bind DIGEST-MD5
by michael＠stroeder.com 17 Feb '09

17 Feb '09

Full_Name: Michael Ströder Version: 2.4.14 OS: SLES 10 URL: Submission from: (NULL) (193.197.158.1) If /usr/lib/sasl2/slapd.conf is missing 2.4.14 seg faults even though the authz-regexp configuration is correct in slapd.conf See GDB information below. (gdb) info threads 5 process 4888 0xffffe410 in __kernel_vsyscall () 4 process 4889 0xffffe410 in __kernel_vsyscall () 3 process 4890 0xffffe410 in __kernel_vsyscall () 2 process 4891 0xffffe410 in __kernel_vsyscall () * 1 process 4892 0xb7e89c2f in __db_get_flags () from /appserver/bdb-4.6/lib/libdb-4.6.so (gdb) thread apply all bt Thread 5 (process 4888): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8b5d8 in pthread_join () from /lib/libpthread.so.0 #2 0xb7f356db in ldap_pvt_thread_join (thread=3023272864, thread_return=0x0) at thr_posix.c:197 #3 0x080773fb in ?? () #4 0xb4337ba0 in ?? () #5 0x00000000 in ?? () Thread 4 (process 4889): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7b5957e in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0xb7ae4e63 in _L_mutex_lock_41 () from /lib/libc.so.6 #3 0xb4334314 in ?? () #4 0xb4334314 in ?? () #5 0x00000032 in ?? () #6 0x00000021 in ?? () #7 0xb7f2611c in ?? () from /appserver/openldap-2.4/lib/liblber-2.4.so.2 #8 0x00000001 in ?? () #9 0x0000003c in ?? () #10 0xb4335318 in ?? () #11 0xb7f2173e in lutil_debug (debug=-1271708908, level=-1212492416, fmt=0x8139194 "daemon: activity on %d descriptor%s\n") at debug.c:72 Backtrace stopped: frame did not save the PC Thread 3 (process 4890): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8e056 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7f357e0 in ldap_pvt_thread_cond_wait (cond=0x81eca6c, mutex=0x81eca54) at thr_posix.c:277 #3 0xb7f3449b in ldap_int_thread_pool_wrapper (xpool=0x81eca50) at tpool.c:654 #4 0xb7d8a2ab in start_thread () from /lib/libpthread.so.0 #5 0xb7b4da4e in clone () from /lib/libc.so.6 Thread 2 (process 4891): #0 0xffffe410 in __kernel_vsyscall () #1 0xb7d8e056 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7f357e0 in ldap_pvt_thread_cond_wait (cond=0x81eca6c, mutex=0x81eca54) at thr_posix.c:277 #3 0xb7f3449b in ldap_int_thread_pool_wrapper (xpool=0x81eca50) at tpool.c:654 #4 0xb7d8a2ab in start_thread () from /lib/libpthread.so.0 #5 0xb7b4da4e in clone () from /lib/libc.so.6 Thread 1 (process 4892): #0 0xb7e89c2f in __db_get_flags () from /appserver/bdb-4.6/lib/libdb-4.6.so #1 0xb7a81385 in ?? () from /usr/lib/sasl2/libsasldb.so #2 0x082f9570 in ?? () #3 0x00000000 in ?? ()

1 0

Re: (ITS#3957) Insert ITS# in ITS message download
by Howard Chu 17 Feb '09

17 Feb '09

Fix is now installed, this ITS will be closed.

1 0

Re: (ITS#5948) jitterbug
by hyc＠symas.com 17 Feb '09

17 Feb '09

Testing followups hyc(a)OpenLDAP.org wrote: > Full_Name: me > Version: 1.0 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.91.220.157) > > > Checking new patches in jitterbug > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5948) test its
by hyc＠OpenLDAP.org 17 Feb '09

17 Feb '09

Full_Name: me Version: 1.0 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Checking new patches in jitterbug

1 0

(ITS#5947) Contect CSN corruption
by quanah＠OpenLDAP.org 17 Feb '09

17 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.14 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) The contextCSN can get corrupted at times in 2.4.14 and previous releases. This is currently fixed in HEAD.

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 16 Feb '09

16 Feb '09

On 13 Feb 2009, at 22:01, Howard Chu wrote: > toby(a)inf.ed.ac.uk wrote: > >> This looks a little strange to me... >> >> (gdb) p f2->f_choice >> Cannot access memory at address 0x39 >> (gdb) up >> #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, >> fcmp=0x81399b0<pcache_query_cmp>, fdup=0x8154700<avl_dup_error>) >> at tavl.c:82 >> 82 cmp = fcmp( data, p->avl_data ); >> (gdb) p p->avl_data >> $1 = (void *) 0x8af62e0 >> (gdb) > > It appears you've compiled with debug and optimization, can you > please compile without optimization and try to reproduce this? Sure, will do. Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

(ITS#5946) mirror mode cannot be set to FALSE when it may not be set to TRUE
by jclarke＠linagora.com 16 Feb '09

16 Feb '09

Full_Name: Jonathan Clarke Version: RE24 OS: URL: http://milopita.phillipoux.net/jonathan-clarke-20090216-bconfig.patch Submission from: (NULL) (213.41.243.192) Dear all, The value checking of "mirror mode" configuration boolean disallows setting mirror mode if the database is not a shadow. However, it also refuses setting mirror mode to "FALSE" in the same condition. Unless this is deliberate, may I suggest the above patch which allows setting mirror mode to FALSE anytime? Regards, Jonathan

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 16 Feb '09

16 Feb '09

On 14.02.2009 01:51, Howard Chu wrote: > Jonathan Clarke wrote: >> On 13.02.2009 01:23, Howard Chu wrote: >>> If you want a setup similar to test049, follow what it does. If you >>> want to something else, do otherwise. >> I am following what test049 does. Only difference is test049 starts >> slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start >> slapd with no -h option or a slightly different URI. This is quite >> common, I believe. > > And the slapd(8) manpage clearly states that with no -h option, it > defaults to "ldap:///". If the default suits your purpose, use it. If > not, then specify the URL you want explicitly. Yes, it's quite common to > start slapd with no -h option, because it suits the general case. This > discussion is not about the general case. > >> If you patch the test as follows, it fails: > > Obviously you should not do that. > >>> There are valid reasons to point a syncrepl consumer at the same slapd >>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>> subtree of a main database, etc.). Using the exhaustive matching that >>> serverID uses would preclude those cases from working. >> I see. I understand you don't want to break existing functionality. >> However, I still feel this is a bug, or at least that you need to "hack" >> the setup to get things working as expected. > > The docs state that "syncrepl provider" is the LDAP URI of the master > server. If you're not putting in the same URI as the master is using, > that's a config error, not a bug. Understood. Nothing is broken, and we have worked around this issue using explicit listeners to slapd -h. This behaviour did surprise me, considering the behaviour of serverID matching. May I suggest that a note of warning is included in the admin guide? For example: http://milopita.phillipoux.net/jonathan-clarke-20090216.patch >> Would I be right in assuming that in all the "valid reasons to point a >> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >> uses a different base DN than the base DN of the database that the >> syncrepl consumer is configured on? If so, maybe the exhaustive matching >> that serverID uses could be used, if and only if those two base DNs are >> different? > > That sounds reasonable. Will think about it a bit more. Certainly if the > two base DNs are the same, it will cause a loop... Indeed. For what it's worth, while testing on cn=config, I noticed this having various consequences including: 1) cn=config becoming read-only (shadow) and updates returning a referral. 2) in a MMR setup, some updates not being replicated to all N servers. Regards, Jonathan

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e6520602e44cff0462e14152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > The missing operational attrs are my fault: I erroneously tested back-meta > with slapo-rwm's mapping, instead of the native one (which may make sense, > but not in your case). This issue should now be fixed in HEAD. > > Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): > they're actually generated by the frontend. This should be prevented now. > Please re-test. Yep all looks good now, using either the meta backend, or the ldap + rwm overlay. Good work :) --0016e6520602e44cff0462e14152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Mas= arati <<a href=3D"mailto:ando@sys-net.it">ando@sys-net= .it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"bor= der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-= left: 1ex;"> The missing operational attrs are my fault: I erroneously tested back-meta = with slapo-rwm's mapping, instead of the native one (which may make sen= se, but not in your case).  This issue should now be fixed in HEAD.<br= > Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): th= ey're actually generated by the frontend.  This should be prevente= d now.  Please re-test.</blockquote><div> Yep all looks good now, u= sing either the meta backend, or the ldap + rwm overlay. Good work :) </div></div> --0016e6520602e44cff0462e14152--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

brett.maxfield(a)gmail.com wrote: > Yes, sorry i was originally using meta backend & switched to ldap. Although > openldap seems to accept the DN component, but happily ignore it. Well, AFAIK it complains. You'll get a warning, unless anything worse happens: if your DN contains a comma (","), parsing would (correctly) fail. > Here the correct spelling is "organisation", i forgot to type it "wrong" for > openldap :P You know, Oscar Wilde wrote that US and UK (and the Commonwealth, I presume) have lots in common, except language :) > Just tried, the fix works perfectly with database meta, overlay rwm, and > rwm-map : (snip) > However, there is also a similar problem with database meta, and map : > > database meta > suffix "c=AU" > uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" > (snip) > When i run the above i get : > > ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' '+' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * + > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > entryDN: cn=test00496,ou=support,o=openldap,c=AU > subschemaSubentry: cn=Subschema > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > Which is not (yet) showing the user attributes, and is leaking some > un-requested operational attributes. The missing operational attrs are my fault: I erroneously tested back-meta with slapo-rwm's mapping, instead of the native one (which may make sense, but not in your case). This issue should now be fixed in HEAD. Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): they're actually generated by the frontend. This should be prevented now. Please re-test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e648d4747104c80462dfbb05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > brett.maxfield(a)gmail.com wrote: > >> --0016e65206024a6d9d0462d5c0d0 >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: 7bit >> >> I have re-tested with recent RE24 and this still happens. >> >> Assuming the config (database meta, and map instead of rwm-map shows >> similar >> problem) : >> >> database ldap >> suffix "c=AU" >> uri "ldap://127.0.0.1:390/c=AU" >> > > You messed things up a little bit: back-ldap does not allow the DN part of > the URI. > Yes, sorry i was originally using meta backend & switched to ldap. Although openldap seems to accept the DN component, but happily ignore it. overlay rwm > > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute * > > rwm-map objectclass inetOrgPerson * > rwm-map objectclass organisationalUnit * > s/organisationalUnit/organizationalUnit/: this raises a warning. Ditto with the typing error. Here the correct spelling is "organisation", i forgot to type it "wrong" for openldap :P Probably * and + (or *,+) should be expanded to the list of user or > administrative attributes (respectively) by meta/rwm first, specifically > those that are allowed by "map attribute" lines, before being handed to the > real directory (helpful to performance if the backend directory has many > attributes, that the meta directory is not interested in). > > This is also why attributes don't appear in a GUI browser for me, if i am > using a GUI browser, as they commonly use *,+ as their default. > Well, if you don't request any attribute, those that are mapped appear. > I've modified slapo-rwm to pass thru special attribute names ("*", "+", > "1.1") in order to defer their mapping when results are returned. This looks > simpler than detecting whether non-mapped attrs are filtered and, in tat > case, replace "*" by the mapped attributes, although the latter could be an > optimization. > > A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please > test. Unfortunately it seems to be too late for OpenLDAP 2.4.14. > Just tried, the fix works perfectly with database meta, overlay rwm, and rwm-map : database ldap suffix "c=AU" uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass * Eg : ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' '+' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * + # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 20090213130450Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 However, there is also a similar problem with database meta, and map : database meta suffix "c=AU" uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU" map attribute cn * map attribute sn * map attribute givenName * map attribute * map objectclass inetOrgPerson * map objectclass organizationalUnit * map objectclass organization * map objectclass country * map objectclass * When i run the above i get : ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' '+' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * + # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU entryDN: cn=test00496,ou=support,o=openldap,c=AU subschemaSubentry: cn=Subschema # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Which is not (yet) showing the user attributes, and is leaking some un-requested operational attributes. Cheers Brett --0016e648d4747104c80462dfbb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masa= rati <<a href=3D"mailto:ando@sys-net.it" target=3D"_bl= ank">ando(a)sys-net.it</a>> wrote: <blockquote class=3D"gmail_qu= ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p= t 0.8ex; padding-left: 1ex;"> <div><a href=3D"mailto:brett.maxfield@gmail.com" target=3D"_blank">brett.ma= xfield(a)gmail.com</a> wrote: </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb= (204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --0016e65206024a6d9d0462d5c0d0 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit<div> I have re-tested with recent RE24 and this still happens. Assuming the config (database meta, and map instead of rwm-map shows simila= r problem) : database        ldap suffix          "c=3DAU" uri             "ldap://<a href=3D"http:= //127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1:390/c=3DAU</a>"<br= > </div></blockquote> You messed things up a little bit: back-ldap does not allow the DN part of = the URI.<div></div></blockquote><div> Yes, sorry i was originally using = meta backend & switched to ldap. Although openldap seems to accept the = DN component, but happily ignore it. <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organisationalUnit * </blockquote> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> s/organisationalUnit/organizationalUnit/: this raises a warning.</blockquot= e><div> Ditto with the typing error. Here the correct spelling is= "organisation", i forgot to type it "wrong" for openld= ap :P <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Probably * an= d + (or *,+) should be expanded to the list of user or administrative attributes (respectively) by meta/rwm first, specifically<br= > those that are allowed by "map attribute" lines, before being han= ded to the real directory (helpful to performance if the backend directory has many<br= > attributes, that the meta directory is not interested in). This is also why attributes don't appear in a GUI browser for me, if i = am using a GUI browser, as they commonly use *,+ as their default. </blockquote> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Well, if you don't request any attribute, those that are mapped appear.=  I've modified slapo-rwm to pass thru special attribute names (&q= uot;*", "+", "1.1") in order to defer their mappin= g when results are returned. This looks simpler than detecting whether non-= mapped attrs are filtered and, in tat case, replace "*" by the ma= pped attributes, although the latter could be an optimization. A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please = test.  Unfortunately it seems to be too late for OpenLDAP 2.4.14.<div>= </div></blockquote><div> Just tried, the fix works perfectly with databa= se meta, overlay rwm, and rwm-map : database       ldap suffix  =         "c=3DAU" uri &= nbsp;           "lda= p://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>= :390/c=3DAU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribut= e createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attri= bute * rwm-map objectclass inetOrgPerson * rwm-map objectclass or= ganizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-= map objectclass * Eg : ldapsearch -H ldap://<a href=3D"http:/= /127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:391 -x -b 'cn=3D= test00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)'= '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: = test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 2009= 0213130450Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 </div></div>However, there = is also a similar problem with database meta, and map : database&nbs= p;       meta suffix   &nbs= p;      "c=3DAU" uri  &nbsp= ;          "ldap://<a hre= f=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:390/c=3DA= U" map attribute cn * map attribute sn * map attribute givenName *<b= r>map attribute * map objectclass inetOrgPerson * map objectclass= organizationalUnit * map objectclass organization * map objectclass = country * map objectclass * When i run the above i get : ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1<= /a>:391 -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' &#3= 9;(objectclass=3D*)' '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU entryDN: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU subschemaSubent= ry: cn=3DSubschema # search result search: 2 result: 0 Success= # numResponses: 2 # numEntries: 1 Which is not (yet) show= ing the user attributes, and is leaking some un-requested operational attri= butes. Cheers Brett --0016e648d4747104c80462dfbb05--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

I note there remains an inconsistency: if you request a specific operational attribute, it is not returned unless explicitly allowed by the mapping. However, if you request all operational attributes using "+", you get all. This occurs because when returning search entries, operational attributes are ignored. I think that we should either: - consistently ignore operational attributes when mapping; or - treat them like other attributes. The latter seems more appropriate to me, since mapping operational attributes could be useful when interacting with other implementations. In any case, the behavior should be consistent. It is up to system administrators to use it appropriately. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5945) --enable-backends=auto support
by michael＠stroeder.com 14 Feb '09

14 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > >> Perhaps a decent alternative would be just to read a set of --enable >> switches >> from ~/.openldap_config or somesuch. I.e., have a file of defaults... > > I think I prefer the current situation to such... And I already > have ./config.status --r > > But on new checkouts, I normally just do --enable-backends --enable- > overlays, wait for breakage, and then add disable flags as needed. > Unforunately, it sometimes takes a few tries. > > So, in short, I concur that doing more here is likely not worth the > effort. +1 Ciao, Michael.

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

brett.maxfield(a)gmail.com wrote: > --0016e65206024a6d9d0462d5c0d0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > I have re-tested with recent RE24 and this still happens. > > Assuming the config (database meta, and map instead of rwm-map shows similar > problem) : > > database ldap > suffix "c=AU" > uri "ldap://127.0.0.1:390/c=AU" You messed things up a little bit: back-ldap does not allow the DN part of the URI. > overlay rwm > > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute * > > rwm-map objectclass inetOrgPerson * > rwm-map objectclass organisationalUnit * s/organisationalUnit/organizationalUnit/: this raises a warning. > rwm-map objectclass organization * > rwm-map objectclass country * > rwm-map objectclass * > > I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// > 127.0.0.1:390/c=AU with some dummy data, and when i query the source > directory i get sensible results: > > suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > objectClass: inetOrgPerson > cn: test00496 > givenName: test00496 > uid: test00496 > sn: test00496lname > displayName: test00496 test00496lname > userPassword:: bm92ZWxs > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > When i query the meta directory, i get no attributes (* or + or *,+, in the > requested attributes all return no attributes as below) : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > But if i query the meta directory explicitly for some attributes (no * +), > it works, i get : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: cn sn firstName > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > cn: test00496 > sn: test00496lname > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > So i conclude then that the default attribute lists of *, +, or *,+ are > somehow being lost by backend meta or overlay rwm ? > > Probably * and + (or *,+) should be expanded to the list of user or > administrative attributes (respectively) by meta/rwm first, specifically > those that are allowed by "map attribute" lines, before being handed to the > real directory (helpful to performance if the backend directory has many > attributes, that the meta directory is not interested in). > > This is also why attributes don't appear in a GUI browser for me, if i am > using a GUI browser, as they commonly use *,+ as their default. Well, if you don't request any attribute, those that are mapped appear. I've modified slapo-rwm to pass thru special attribute names ("*", "+", "1.1") in order to defer their mapping when results are returned. This looks simpler than detecting whether non-mapped attrs are filtered and, in tat case, replace "*" by the mapped attributes, although the latter could be an optimization. A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please test. Unfortunately it seems to be too late for OpenLDAP 2.4.14. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 14 Feb '09

14 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > As I leave one week for a security formation ISO 27001 (and in case it would > persuade me to make never more programming ;), here is the current state > (not finished) of the patch You should upload patches to ftp.openldap.org and post a link to them, otherwise mailers screw them up as below. Please follow instructions at <http://www.openldap.org/devel/contributing.html#submitting>. p. (only the modified function - cf "Followup 19"). > In fact, 2 more options must be validated there : > 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search > SRV-domain (or the default domain, if $hostname=="") ... > 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the > result of the SRV search)) ... > -- > PE > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: application/octet-stream; > name="open.c.url_expand.patch" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="open.c.url_expand.patch" > > --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = > 23:23:58.000000000 +0000=0A= > +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = > 00:31:27.000000000 +0000=0A= > @@ -212,19 +212,164 @@=0A= > return( ld );=0A= > }=0A= > =0A= > +int=0A= > +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = > char *domain )=0A= > +{ int rc =3D 0;=0A= > + char *scheme, *hostname, *port, *opt;=0A= > +=0A= > + // Syntax validation ...=0A= > + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= > + return -1; // memory error ...=0A= > +=0A= > + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= > + if ( *hostname++ !=3D '/' )=0A= > + return -1; // syntax error ...=0A= > + =0A= > + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = > '\0';=0A= > + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = > '\0';=0A= > +=0A= > + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = > =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = > if $hostname=3D=3D"") ...=0A= > + return -1; // syntax error ...=0A= > +=0A= > + // So now, we can search the server name(s) of the _ldap._tcp.$domain = > service ...=0A= > + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = > $port ...=0A= > +=0A= > + // Coming soon ...=0A= > +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = > ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= > +=0A= > + // Search is finished : so now, add initial scheme and opt to result = > hostport(s) ...=0A= > + if ( *result !=3D NULL ) {=0A= > + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= > + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= > + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = > strlen ( (char *)((*result)[rc]) ) + plus ); =0A= > + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = > 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= > + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= > + char *s =3D (char *)((*result)[rc]);=0A= > + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= > + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= > + }=0A= > + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= > + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= > + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = > *)((*result)[rc]), opt );=0A= > + rc++;=0A= > + }=0A= > + } else rc =3D 0;=0A= > +=0A= > + LDAP_FREE ( scheme );=0A= > + return rc;=0A= > +}=0A= > +=0A= > +char *=0A= > +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= > +{=0A= > ...=0A= > =0A= > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10-- > > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 14 Feb '09

14 Feb '09

On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > Perhaps a decent alternative would be just to read a set of --enable > switches > from ~/.openldap_config or somesuch. I.e., have a file of defaults... I think I prefer the current situation to such... And I already have ./config.status --r But on new checkouts, I normally just do --enable-backends --enable- overlays, wait for breakage, and then add disable flags as needed. Unforunately, it sometimes takes a few tries. So, in short, I concur that doing more here is likely not worth the effort. -- Kurt

1 0

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

Howard Chu wrote: > Kurt Zeilenga wrote: >> I just noting that for testing, it kind of nice to just be able to do >> ./configure --enable-backends=auto --enable-overlays=auto >> make >> make test >> >> To test everything that available on the box. > > Note that there's no need for an "auto" for overlays - all of the core > overlays are self-contained with no external dependencies, and that should > always be the case. > > I agree that "testing everything available" would be nice, because I > frequently forget to --enable-slapi or various other switches. But I don't > think --enable-everything will suit either. > Perhaps a decent alternative would be just to read a set of --enable switches from ~/.openldap_config or somesuch. I.e., have a file of defaults... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

Kurt Zeilenga wrote: > I just noting that for testing, it kind of nice to just be able to do > ./configure --enable-backends=auto --enable-overlays=auto > make > make test > > To test everything that available on the box. Note that there's no need for an "auto" for overlays - all of the core overlays are self-contained with no external dependencies, and that should always be the case. I agree that "testing everything available" would be nice, because I frequently forget to --enable-slapi or various other switches. But I don't think --enable-everything will suit either. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 14 Feb '09

14 Feb '09

On Feb 13, 2009, at 5:55 PM, hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> It would be handy to allow --enable-backends to have auto support >> so that all >> available backends can be selected. The current behavior is "yes", >> which means >> that if you don't have the requisites for a given backend, >> configure stops. > > Accommodating this request would make other things much more > inconvenient. > > Currently the backends and overlay options toggle between "no | yes > | mod" > where "yes" means "yes+static" and "mod" means "yes+dynamic". An > "auto" option > here doesn't allow you to select static vs dynamic. We could have auto => yes+static and automod => yes+dyanmic. But that might be too cumbersome as well. > Adding "auto" would revert > us back to OpenLDAP 2.0's behavior, where every backend required two > enable > switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) > which IMO > was far too cumbersome. > > > Likewise it would require rewriting most of the backends' detection > tests in > configure.in, which currently use AC_MSG_ERROR when a prereq isn't > found. All > of those would have to be turned into warnings/bailouts in the > "auto" case, > instead of aborting the configure run. There's still a lot of old auto tests in configure.in, even for new things like ndb. :-) > > > IMO, seems like more effort than it's worth. possibly. I just noting that for testing, it kind of nice to just be able to do ./configure --enable-backends=auto --enable-overlays=auto make make test To test everything that available on the box. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >

1 0

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > It would be handy to allow --enable-backends to have auto support so that all > available backends can be selected. The current behavior is "yes", which means > that if you don't have the requisites for a given backend, configure stops. Accommodating this request would make other things much more inconvenient. Currently the backends and overlay options toggle between "no | yes | mod" where "yes" means "yes+static" and "mod" means "yes+dynamic". An "auto" option here doesn't allow you to select static vs dynamic. Adding "auto" would revert us back to OpenLDAP 2.0's behavior, where every backend required two enable switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) which IMO was far too cumbersome. Likewise it would require rewriting most of the backends' detection tests in configure.in, which currently use AC_MSG_ERROR when a prereq isn't found. All of those would have to be turned into warnings/bailouts in the "auto" case, instead of aborting the configure run. IMO, seems like more effort than it's worth. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5945) --enable-backends=auto support
by quanah＠OpenLDAP.org 14 Feb '09

14 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) It would be handy to allow --enable-backends to have auto support so that all available backends can be selected. The current behavior is "yes", which means that if you don't have the requisites for a given backend, configure stops.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 14 Feb '09

14 Feb '09

jclarke(a)linagora.com wrote: > This is a multi-part message in MIME format. Please do not send HTML/MIME emails here. > On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > I am following what test049 does. > Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't > a problem for test049 indeed. > > Although I am curious as to why test049 creates a syncrepl consumer > targeted at itself? Can't quite get my head around it yet, but will keep > thinking, with regard to multimaster. Very simple. Once the real consumer connects to the master and replicates, it will acquire whatever config was on the master. If the master doesn't have a consumer pointed at itself, then once the consumer acquires the master's configuration, the consumer's syncrepl config will disappear, and replication will stop. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 14 Feb '09

14 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00C2_01C98DEA.AA80EF10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit As I leave one week for a security formation ISO 27001 (and in case it would persuade me to make never more programming ;), here is the current state (not finished) of the patch (only the modified function - cf "Followup 19"). In fact, 2 more options must be validated there : 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search SRV-domain (or the default domain, if $hostname=="") ... 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the result of the SRV search)) ... -- PE ------=_NextPart_000_00C2_01C98DEA.AA80EF10 Content-Type: application/octet-stream; name="open.c.url_expand.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.url_expand.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 23:23:58.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = 00:31:27.000000000 +0000=0A= @@ -212,19 +212,164 @@=0A= return( ld );=0A= }=0A= =0A= +int=0A= +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = char *domain )=0A= +{ int rc =3D 0;=0A= + char *scheme, *hostname, *port, *opt;=0A= +=0A= + // Syntax validation ...=0A= + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= + return -1; // memory error ...=0A= +=0A= + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= + if ( *hostname++ !=3D '/' )=0A= + return -1; // syntax error ...=0A= + =0A= + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = '\0';=0A= + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = '\0';=0A= +=0A= + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = if $hostname=3D=3D"") ...=0A= + return -1; // syntax error ...=0A= +=0A= + // So now, we can search the server name(s) of the _ldap._tcp.$domain = service ...=0A= + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = $port ...=0A= +=0A= + // Coming soon ...=0A= +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= +=0A= + // Search is finished : so now, add initial scheme and opt to result = hostport(s) ...=0A= + if ( *result !=3D NULL ) {=0A= + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = strlen ( (char *)((*result)[rc]) ) + plus ); =0A= + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= + char *s =3D (char *)((*result)[rc]);=0A= + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= + }=0A= + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = *)((*result)[rc]), opt );=0A= + rc++;=0A= + }=0A= + } else rc =3D 0;=0A= +=0A= + LDAP_FREE ( scheme );=0A= + return rc;=0A= +}=0A= +=0A= +char *=0A= +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= +{=0A= ...=0A= =0A= ------=_NextPart_000_00C2_01C98DEA.AA80EF10--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 14 Feb '09

14 Feb '09

Jonathan Clarke wrote: > On 13.02.2009 01:23, Howard Chu wrote: >> If you want a setup similar to test049, follow what it does. If you >> want to something else, do otherwise. > I am following what test049 does. Only difference is test049 starts > slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start > slapd with no -h option or a slightly different URI. This is quite > common, I believe. And the slapd(8) manpage clearly states that with no -h option, it defaults to "ldap:///". If the default suits your purpose, use it. If not, then specify the URL you want explicitly. Yes, it's quite common to start slapd with no -h option, because it suits the general case. This discussion is not about the general case. > If you patch the test as follows, it fails: Obviously you should not do that. >> There are valid reasons to point a syncrepl consumer at the same slapd >> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >> subtree of a main database, etc.). Using the exhaustive matching that >> serverID uses would preclude those cases from working. > I see. I understand you don't want to break existing functionality. > However, I still feel this is a bug, or at least that you need to "hack" > the setup to get things working as expected. The docs state that "syncrepl provider" is the LDAP URI of the master server. If you're not putting in the same URI as the master is using, that's a config error, not a bug. > Would I be right in assuming that in all the "valid reasons to point a > syncrepl consumer at the same slapd" you mention, the syncrepl consumer > uses a different base DN than the base DN of the database that the > syncrepl consumer is configured on? If so, maybe the exhaustive matching > that serverID uses could be used, if and only if those two base DNs are > different? That sounds reasonable. Will think about it a bit more. Certainly if the two base DNs are the same, it will cause a loop... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e65206024a6d9d0462d5c0d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have re-tested with recent RE24 and this still happens. Assuming the config (database meta, and map instead of rwm-map shows similar problem) : database ldap suffix "c=AU" uri "ldap://127.0.0.1:390/c=AU" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organisationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass * I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// 127.0.0.1:390/c=AU with some dummy data, and when i query the source directory i get sensible results: suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid: test00496 sn: test00496lname displayName: test00496 test00496lname userPassword:: bm92ZWxs # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 When i query the meta directory, i get no attributes (* or + or *,+, in the requested attributes all return no attributes as below) : ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 But if i query the meta directory explicitly for some attributes (no * +), it works, i get : ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: cn sn firstName # # test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU cn: test00496 sn: test00496lname # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So i conclude then that the default attribute lists of *, +, or *,+ are somehow being lost by backend meta or overlay rwm ? Probably * and + (or *,+) should be expanded to the list of user or administrative attributes (respectively) by meta/rwm first, specifically those that are allowed by "map attribute" lines, before being handed to the real directory (helpful to performance if the backend directory has many attributes, that the meta directory is not interested in). This is also why attributes don't appear in a GUI browser for me, if i am using a GUI browser, as they commonly use *,+ as their default. Cheers Brett On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > [please reply to the ITS, otherwise issues can't be tracked] > > Brett @Google wrote: > >> HI Ando, >> >> Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it >> into RE24 in time for the 2.4.13 release ? >> > > apparently, yes. > > If so, i can still see the behaviour here with 2.4.13, i can see >> operational >> attributes, but non non-operational attributes, when mapping both >> objectclass and attribute.. >> >> Bug seems to be focused on using of *, rather than an explicit list of >> non-operational attrs which works, ie : >> >> I can search for attributes with * ( get all non-operational attributes ) >> and don't get any non-operational attributes, whereas explicitly adding >> any >> non-operational attribute will result i a search returning the named >> values, >> which is allowable via the objectclass maps. >> >> seems to work the same (omitting non-oprational attrs), even if i dont >> specufy the objectclass rwm maps. >> > > Not sure I understand. Can you post simple (both working and not working) > examples? > > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > > --0016e65206024a6d9d0462d5c0d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I have re-tested with recent RE24 and this still happens. Assuming = the config (database meta, and map instead of rwm-map shows similar problem= ) : database        ldap suffi= x          "c=3DAU"<= br>uri           &nb= sp; "ldap://<a href=3D"http://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3D= AU</a>" overlay rwm rwm-map attribute cn * rwm-map attribute sn * = rwm-map attribute givenName * rwm-map attribute * rwm-map objectc= lass inetOrgPerson * rwm-map objectclass organisationalUnit * rwm-map= objectclass organization * rwm-map objectclass country * rwm-map objectclass * I have a stan= dard LDAP with standard inetOrgPerson style schemas on ldap://<a href=3D"ht= tp://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3DAU</a> with some dummy data, a= nd when i query the source directory i get sensible results: suse:/usr/local/etc/openldap # ldapsearch -H ldap://<a href=3D"http://1= 27.0.0.1:390">127.0.0.1:390</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3D= openldap,c=3DAU' '(objectclass=3D*)' '*' # extended = LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU= > with scope subtree # filter: (objectclass=3D*) # requesting: *<b= r># # test00496, support, openldap, AU dn: cn=3Dtest00496,ou=3Dsu= pport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid:= test00496 sn: test00496lname displayName: test00496 test00496lname<b= r>userPassword:: bm92ZWxs # search result search: 2 result: 0 = Success # numResponses: 2 # numEntries: 1 When i query the meta direc= tory, i get no attributes (* or + or *,+, in the requested attributes all r= eturn no attributes as below) : ldapsearch -H ldap://<a href=3D"http= ://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU' '(objectclass=3D*)' '*' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * # # test00496, support, openldap, AU dn: cn= =3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU # search result search: 2 result: 0 Success # numResponses= : 2 # numEntries: 1 But if i query the meta directory explicitly = for some attributes (no * +), it works, i get :  ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dt= est00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)' = cn sn firstName # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: cn sn firstName # # test00496, support, openldap,= AU dn: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU cn: test00496 sn:= test00496lname # search result search: 2 result: 0 Success<br= > # numResponses: 2 # numEntries: 1 So i conclude then that th= e default attribute lists of *, +, or *,+ are somehow being lost by backend= meta or overlay rwm ? Probably * and + (or *,+) should be expanded to the list of user or adm= inistrative attributes (respectively) by meta/rwm first, specifically those= that are allowed by "map attribute" lines, before being handed t= o the real directory (helpful to performance if the backend directory has m= any attributes, that the meta directory is not interested in). This is also why attributes don't appear in a GUI browser for me, i= f i am using a GUI browser, as they commonly use *,+ as their default. <= br>Cheers Brett <div class=3D"gmail_quote">On Sun, Jan 25, 2009 a= t 12:53 AM, Pierangelo Masarati <<a href=3D"mailto:and= o(a)sys-net.it">ando(a)sys-net.it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[please reply to = the ITS, otherwise issues can't be tracked]<div class=3D"Ih2E3d"> Brett @Google wrote: <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> HI Ando, Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it<= br> into RE24 in time for the 2.4.13 release ? </blockquote> </div> apparently, yes.<div class=3D"Ih2E3d"> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If so, i can still see the behaviour here with 2.4.13, i can see operationa= l attributes, but non non-operational attributes, when mapping both objectclass and attribute.. Bug seems to be focused on using of *, rather than an explicit list of non-operational attrs which works, ie : I can search for attributes with * ( get all non-operational attributes )<b= r> and don't get any non-operational attributes, whereas explicitly adding= any non-operational attribute will result i a search returning the named values= , which is allowable via the objectclass maps. seems to work the same (omitting non-oprational attrs), even if i dont specufy the objectclass rwm maps. </blockquote> </div> Not sure I understand.  Can you post simple (both working and not work= ing) examples?<div><div></div><div class=3D"Wj3C7c"> p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA <a href=3D"http://www.sys-net.it" target=3D"_blank">http://www.sys-net.it</= a> ----------------------------------- Office:  +39 02 23998309 Mobile:  +39 333 4963172 Fax:     +39 0382 476497 Email:   <a href=3D"mailto:ando@sys-net.it" target=3D"_blank">ando@sys= -net.it</a> ----------------------------------- </div></div></blockquote></div> --0016e65206024a6d9d0462d5c0d0--

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by hyc＠symas.com 13 Feb '09

13 Feb '09

toby(a)inf.ed.ac.uk wrote: > This looks a little strange to me... > > (gdb) p f2->f_choice > Cannot access memory at address 0x39 > (gdb) up > #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, > fcmp=0x81399b0<pcache_query_cmp>, fdup=0x8154700<avl_dup_error>) > at tavl.c:82 > 82 cmp = fcmp( data, p->avl_data ); > (gdb) p p->avl_data > $1 = (void *) 0x8af62e0 > (gdb) It appears you've compiled with debug and optimization, can you please compile without optimization and try to reproduce this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5944) configure options --program-prefix and --program-suffix do not update servers/slapd/main.c
by Frank.Swasey＠uvm.edu 13 Feb '09

13 Feb '09

Full_Name: Francis Swasey Version: 2.4.13 OS: Red Hat Enterprise Linux 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.37.250) When using the configure options --program-prefix or --program-suffix, the binaries are named as exspected. However, slapd's tools array is not updated and so when using the slap* tool binaries, slapd doesn't recognize that it is being executed as a tool and attempts to start up as slapd.

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 13 Feb '09

13 Feb '09

This is a multi-part message in MIME format. --------------030704040902090700090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > On 13.02.2009 01:23, Howard Chu wrote: > >> Jonathan Clarke wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> Ah right. For the serverID code, we're doing a liberal match because >>>> anything >>>> that matches the current name:port is obviously the current server, >>>> and we >>>> want it to be identified as such. >>>> >>>> For syncrepl, we know full well that it may be the current server, >>>> but for >>>> whatever reason you may want to replicate against yourself anyway >>>> (e.g., >>>> against a different baseDN, etc...). >>>> >>> Actually, this comes straight from test049 (config replication). With >>> multimaster config replication, it starts by replicating itself >>> (useless, but necessary for other masters). This problem doesn't appear >>> in the test case, since a variable ($URI1) is used for both the slapd -h >>> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >>> would produce weird results. >>> >> If you want a setup similar to test049, follow what it does. If you >> want to something else, do otherwise. >> > I am following what test049 does. Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster. --------------030704040902090700090604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 13.02.2009 14:29, <a class="moz-txt-link-abbreviated" href="mailto:jclarke@linagora.com">jclarke(a)linagora.com</a> wrote: <blockquote cite="mid:200902131329.n1DDTKF6072656@boole.openldap.org" type="cite"> <pre wrap="">On 13.02.2009 01:23, Howard Chu wrote: </pre> <blockquote type="cite"> <pre wrap="">Jonathan Clarke wrote: </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). </pre> </blockquote> <pre wrap="">Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. </pre> </blockquote> <pre wrap="">If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. </pre> </blockquote> <pre wrap="">I am following what test049 does.</pre> </blockquote> Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster. </body> </html> --------------030704040902090700090604--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 13 Feb '09

13 Feb '09

On 13.02.2009 01:23, Howard Chu wrote: > Jonathan Clarke wrote: >> hyc(a)symas.com wrote: >>> Ah right. For the serverID code, we're doing a liberal match because >>> anything >>> that matches the current name:port is obviously the current server, >>> and we >>> want it to be identified as such. >>> >>> For syncrepl, we know full well that it may be the current server, >>> but for >>> whatever reason you may want to replicate against yourself anyway >>> (e.g., >>> against a different baseDN, etc...). >> Actually, this comes straight from test049 (config replication). With >> multimaster config replication, it starts by replicating itself >> (useless, but necessary for other masters). This problem doesn't appear >> in the test case, since a variable ($URI1) is used for both the slapd -h >> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >> would produce weird results. > > If you want a setup similar to test049, follow what it does. If you > want to something else, do otherwise. I am following what test049 does. Only difference is test049 starts slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start slapd with no -h option or a slightly different URI. This is quite common, I believe. If you patch the test as follows, it fails: 8<---------------------------------------------------- --- tests/scripts/test049-sync-config 10 Feb 2009 12:29:01 -0000 1.4.2.9 +++ tests/scripts/test049-sync-config 13 Feb 2009 10:11:22 -0000 @@ -112,7 +112,7 @@ $LDAPMODIFY -D cn=config -H $URI1 -y $CO -olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple +olcSyncRepl: rid=001 provider=`echo $URI1 | sed "s/localhost/127.0.0.1/"` binddn="cn=config" bindmethod=simple 8<---------------------------------------------------- Error: 8<---------------------------------------------------- Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... ldapmodify failed for syncrepl config (10)! 8<---------------------------------------------------- > There are valid reasons to point a syncrepl consumer at the same slapd > (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a > subtree of a main database, etc.). Using the exhaustive matching that > serverID uses would preclude those cases from working. I see. I understand you don't want to break existing functionality. However, I still feel this is a bug, or at least that you need to "hack" the setup to get things working as expected. Would I be right in assuming that in all the "valid reasons to point a syncrepl consumer at the same slapd" you mention, the syncrepl consumer uses a different base DN than the base DN of the database that the syncrepl consumer is configured on? If so, maybe the exhaustive matching that serverID uses could be used, if and only if those two base DNs are different? Jonathan

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 13 Feb '09

13 Feb '09

Hi there, I've put this patched version on a small lab of clients (about 23) and on one of them slapd has segfaulted and dumped core. Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 608 switch( f2->f_choice ) { (gdb) bt #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 #2 0x0813a95d in add_query (op=0x8ae3658, qm=0x8a74cc0, query=0xb55af394, templ=0x8a90f88, why=PC_POSITIVE, wlock=1) at pcache.c:1252 #3 0x0813d7f1 in pcache_op_cleanup (op=0x8ae3658, rs=0xb5eb1148) at pcache.c:2041 #4 0x08076a04 in slap_cleanup_play (op=0x8ae3658, rs=0xb5eb1148) at result.c:341 #5 0x08079a56 in send_ldap_response (op=0x8ae3658, rs=0xb5eb1148) at result.c:522 #6 0x0807aa42 in slap_send_ldap_result (op=0x8ae3658, rs=0xb5eb1148) at result.c:650 #7 0x080f4fef in ldap_back_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:549 #8 0x080cf431 in overlay_op_walk (op=0x8ae3658, rs=0xb5eb1148, which=op_search, oi=0x8a74ff0, on=0x8a750f0) at backover.c:670 #9 0x080cf9ed in over_op_func (op=0x8ae3658, rs=0xb5eb1148, which=op_search) at backover.c:722 #10 0x08069016 in fe_op_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:366 #11 0x0806989b in do_search (op=0x8ae3658, rs=0xb5eb1148) at search.c: 217 #12 0x08066a66 in connection_operation (ctx=0xb5eb1218, arg_v=0x8ae3658) at connection.c:1090 #13 0x08067082 in connection_read_thread (ctx=0xb5eb1218, argv=0xf) at connection.c:1216 #14 0x08159704 in ldap_int_thread_pool_wrapper (xpool=0x8a52f90) at tpool.c:663 #15 0x0064f46b in start_thread () from /lib/libpthread.so.0 #16 0x005a6dbe in clone () from /lib/libc.so.6 This looks a little strange to me... (gdb) p f2->f_choice Cannot access memory at address 0x39 (gdb) up #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 82 cmp = fcmp( data, p->avl_data ); (gdb) p p->avl_data $1 = (void *) 0x8af62e0 (gdb) Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 13 Feb '09

13 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here is a first result (patch integration) ... It doen't more remains to write the actual SRV search ... (coming soon) Here is a running log : root@testldap0:/var/log# >syslog root@testldap0:/var/log# grep "^[^#].*ldapsam:" /etc/samba/smb.conf passdb backend = ldapsam:"ldap://ns0 ldap://ns0/ou=profile%2cdc=gov%2cdc=pf??sub?(objectClass=*)?x-dnssrv=dc=gov% 2cdc=pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap:///dc=srv%2cdc=gov%2cdc=pf??sub??toto" root@testldap0:/var/log# /etc/rc.d/rc.samba restart Starting Samba: /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/nmbd -D root@testldap0:/var/log# cat syslog Feb 13 01:38:25 testldap0 smbd: the final url is: "ldap://ns0 ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf-" -- PE ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: application/octet-stream; name="open.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.patch" --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = 23:23:58.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-13 = 01:30:35.000000000 +0000=0A= @@ -212,19 +212,128 @@=0A= return( ld );=0A= }=0A= =0A= +int=0A= +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = char *domain )=0A= +{ int rc =3D 0;=0A= +=0A= +if ( (*result =3D ldap_str2charray( "ldap://ldap1.gov.pf = ldap://ldap2.gov.pf ldap://ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; = // line to delete ...=0A= +=0A= + // Coming soon ...=0A= +=0A= + return rc;=0A= +}=0A= +=0A= +char *=0A= +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= +{=0A= + char *dom, *s, *dn =3D NULL, **srvSearchResult =3D NULL;=0A= + char **urls =3D NULL, **extentions =3D NULL;=0A= + int i, ii, urlsNb=3D0;=0A= +=0A= + if( url_in =3D=3D NULL ) {=0A= + return NULL;=0A= + }=0A= +=0A= + urls =3D ldap_str2charray( url_in, " " );=0A= +=0A= + while( urls[urlsNb] ) urlsNb++; // How many urls is there ?...=0A= +=0A= + for( i=3D0; (dom=3Durls[i]); i++ ) { // for each URL, search SRV = domain ...=0A= +=0A= + // Search for "x-dnssrv" extention (fifth field) ...=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + extentions =3D ldap_str2charray( dom, "," );=0A= + for ( dom=3DNULL,ii=3D0; extentions[ii]; ii++ ) {=0A= + ldap_pvt_str2lower ( extentions[ii]+1 );=0A= + if ( strncmp( extentions[ii], "x-dnssrv=3D", sizeof ( "x-dnssrv=3D" = )-1) =3D=3D 0 ) {=0A= + dom =3D extentions[ii] + sizeof ( "x-dnssrv=3D" ) - 1;=0A= + break;=0A= + } }=0A= +=0A= + // Search for dn =3D=3D "dc=3D.*[,dc=3D.*]*" - only in case there was = not any "x-dnssrv" extension ...=0A= + if ( ! dom ) { dom=3Durls[i];=0A= + if ( *(dom =3D (char *)strchrnul( dom, '/' )) !=3D '/' = || !strncmp ( dom, "///dc=3D", 6 ) =3D=3D 0 ) continue;=0A= + dom=3Ddn=3D (char *) LDAP_STRDUP ( dom+3 );=0A= + if ( dom ) *(char *)strchrnul( dom, '?' ) =3D '\0';=0A= + }=0A= + =0A= + // Does dom realy look like a domain name (if a dn format is = detected) ?...=0A= + if ( dom && strncmp(dom, "dc=3D", 3) =3D=3D 0 ) // It's effectively a = dn definition (not just a domaine name) ?...=0A= + for ( s=3Ddom+3; *s; s++ ) // Nothing else than "dc=3D" in the = string ?...=0A= + if ( *s =3D=3D '=3D' && *(s-1) !=3D 'c' && *(s-2) !=3D 'd') {=0A= + dom =3D NULL; // never mind, a next time !...=0A= + break; =0A= + }=0A= +=0A= + // Replace the current url with the result of the SRV search ...=0A= + if ( dom ) {=0A= + int rc =3D url_expand_on_srv_search ( &srvSearchResult, urls[i], dom = );=0A= +=0A= + if ( rc > 0 ) { // Substitution (must keep the initial order of = the urls) ...=0A= + char **u, **result =3D srvSearchResult;=0A= + if ( (u =3D (char **)LDAP_MALLOC( (urlsNb + rc) * sizeof(char *) )) = ) {=0A= + for ( ii=3DurlsNb + rc; ii; ) u[--ii] =3D NULL;=0A= + while ( ii<i ) {=0A= + u[ii] =3D urls[ii];=0A= + ii++;=0A= + } while ( ii<i+rc && rc ) { // replace url[i] with url(s) = resulting from the SRV search ...=0A= + u[ii] =3D *result++;=0A= + ii++;=0A= + } while ( urls[ii-rc+1] && rc ) {=0A= + u[ii] =3D urls[ii-rc+1];=0A= + ii++;=0A= + } u[ii] =3D NULL;=0A= + LDAP_FREE ( urls );=0A= + urls =3D u;=0A= + rc--; i +=3D rc; urlsNb +=3D rc;=0A= + }=0A= + LDAP_FREE ( srvSearchResult );=0A= + } }=0A= +=0A= + // it's done for the current url ...=0A= + LDAP_FREE( dn );=0A= + ldap_charray_free( extentions );=0A= + }=0A= +=0A= + // last job : to construct the result string ...=0A= + for ( i=3D0; urls[i]; i++ ) {=0A= + urlsNb +=3D strlen( urls[i] );=0A= + urlsNb++; // for urls separator: ' ' ...=0A= + } if ( (s =3D (char *)LDAP_MALLOC( ++urlsNb )) !=3D NULL ) {=0A= + for ( *s=3D'\0',i=3D0; urls[i]; i++ )=0A= + sprintf ( &s[strlen(s)], "%s ", urls[i] );=0A= + s[strlen(s)-1] =3D '\0'; // delete last ' ' ...=0A= + }=0A= +=0A= + ldap_charray_free( urls );=0A= +=0A= + // bye ...=0A= + return ( s );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in )=0A= {=0A= int rc;=0A= LDAP *ld;=0A= + char *url;=0A= =0A= *ldp =3D NULL;=0A= rc =3D ldap_create(&ld);=0A= if ( rc !=3D LDAP_SUCCESS )=0A= return rc;=0A= =0A= - if (url !=3D NULL) {=0A= + if (url_in !=3D NULL) {=0A= + url =3D expand_dnssrv_definitions ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=0A= +syslog ( 3, "the final url is: \"%s-\"", url ); // to delete ...=0A= +=0A= rc =3D ldap_set_option(ld, LDAP_OPT_URI, url);=0A= if ( rc !=3D LDAP_SUCCESS ) {=0A= ldap_ld_free(ld, 1, NULL, NULL);=0A= @@ -234,6 +343,7 @@=0A= if (ldap_is_ldapc_url(url))=0A= LDAP_IS_UDP(ld) =3D 1;=0A= #endif=0A= + LDAP_FREE( url );=0A= }=0A= =0A= *ldp =3D ld;=0A= ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 13 Feb '09

13 Feb '09

Jonathan Clarke wrote: > hyc(a)symas.com wrote: >> Ah right. For the serverID code, we're doing a liberal match because anything >> that matches the current name:port is obviously the current server, and we >> want it to be identified as such. >> >> For syncrepl, we know full well that it may be the current server, but for >> whatever reason you may want to replicate against yourself anyway (e.g., >> against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With > multimaster config replication, it starts by replicating itself > (useless, but necessary for other masters). This problem doesn't appear > in the test case, since a variable ($URI1) is used for both the slapd -h > $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it > would produce weird results. If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. There are valid reasons to point a syncrepl consumer at the same slapd (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a subtree of a main database, etc.). Using the exhaustive matching that serverID uses would preclude those cases from working. As usual, when you're configuring a server, you have to pay attention to what you're doing and what effect you want to accomplish. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 13 Feb '09

13 Feb '09

ando(a)sys-net.it wrote: > Also, please note that modifications to olcRwmRewrite is not allowed, > unless consisting in a full replace without {} idxes. The operation you > were trying, More about this: now slapo-rwm supports add/delete/modify olcRwmRewrite values (in a far from optimal manner). p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 13 Feb '09

13 Feb '09

ando(a)sys-net.it wrote: > Please forget my previous posting. Your issue should now be solved in > HEAD. Please test. p. Also, please note that modifications to olcRwmRewrite is not allowed, unless consisting in a full replace without {} idxes. The operation you were trying, 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- is not allowed. This is allowed, though: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- note the missing {0}. Support for renumbering of olcRwmRewrite could be introduced by removing rewrite info and regenerating it from the saved values. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > Howard Chu wrote: > >> hyc(a)symas.com wrote: >> >>> jclarke(a)linagora.com wrote: >>> >>>> I saw the comment in the code that clarifies this behaviour. However, it's a >>>> surprising behaviour, and I think there is code to parse this kind of thing in >>>> the serverID detection now. Maybe it could be reused? >>>> >> Oops, never mind. I was thinking of the serverID code, and you're talking >> about the syncrepl code. >> >> I'll have to think a bit about why the two aren't behaving identically; >> probably they should both use the same code. >> >> > Ah right. For the serverID code, we're doing a liberal match because anything > that matches the current name:port is obviously the current server, and we > want it to be identified as such. > > For syncrepl, we know full well that it may be the current server, but for > whatever reason you may want to replicate against yourself anyway (e.g., > against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. Jon

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. Please forget my previous posting. Your issue should now be solved in HEAD. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs