- openldap-bugs - openldap.org

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 06 Feb '09

06 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at > begining of the hostname to say "use SRV record" of this domain - search > domain(s) if only '.') ?... I'd recommend not to mess around with the hostport portion of the LDAP URL. In opposite to Hallvard I'm not even sure whether a distinction is really needed when invoking ldap_initialize(). Ciao, Michael.

1 0

Re: (ITS#5927) assertion error when using pcache
by hyc＠symas.com 06 Feb '09

06 Feb '09

hyc(a)symas.com wrote: > There's something more going on here, because the query in question was > searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). I meant (&(objectclass=posixgroup)(|(memberUid=foo)(member=foo-DN))) > There > was no memberUid at all in the returned entry, so it must have matched on > member, so the member attr should not have been empty. > > AD is flaky enough already, but it's possible that back-meta may have dropped > the attr values during rewriting, etc. -- -- 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#5927) assertion error when using pcache
by hyc＠symas.com 06 Feb '09

06 Feb '09

ando(a)sys-net.it wrote: > mhardin(a)symas.com wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We have an LDAP server that is proxying for Active Directory. Periodically slapd >> throws an assertion: >> >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: >> Assertion `i> 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> >> Howard Chu's examination of the core file showed that the remote AD server >> returned a member attribute with no values. This is only legal in LDAP when a >> client sets the attrsonly flag in its search request, and that flag was not set >> here. >> >> The indexer rightly asserts because pcache handed it an attribute with nothing >> to >> index. >> >> I'm not sure what the correct thing to do might be here, but it should not take >> down the slapd. > > The entry should not be cached, IMHO. Perhaps. But then the entire query cannot be cached, because its result set would be known to be incomplete. There's something more going on here, because the query in question was searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There was no memberUid at all in the returned entry, so it must have matched on member, so the member attr should not have been empty. AD is flaky enough already, but it's possible that back-meta may have dropped the attr values during rewriting, etc. -- -- 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#5927) assertion error when using pcache
by ando＠sys-net.it 06 Feb '09

06 Feb '09

mhardin(a)symas.com wrote: > Full_Name: Matthew Hardin > Version: 2.4.13 > OS: Red Hat Enterprise Linux 4 i686 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.114.185) > > > Hi All, > > We have an LDAP server that is proxying for Active Directory. Periodically slapd > throws an assertion: > > slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: > Assertion `i > 0' failed. > /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) > "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS > > Howard Chu's examination of the core file showed that the remote AD server > returned a member attribute with no values. This is only legal in LDAP when a > client sets the attrsonly flag in its search request, and that flag was not set > here. > > The indexer rightly asserts because pcache handed it an attribute with nothing > to > index. > > I'm not sure what the correct thing to do might be here, but it should not take > down the slapd. The entry should not be cached, IMHO. 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,dc=domaine)
by philippe.eychart＠informatique.gov.pf 06 Feb '09

06 Feb '09

Sorry : -ldap_initialize( LDAP **ldp, LDAP_CONST char *url ) +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in ) -- PE

1 0

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

06 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01C987A2.419734D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit and patch could be something like that ... -- pe -----Message d'origine----- De : Philippe EYCHART [mailto:philippe.eychart@informatique.gov.pf] Envoye : jeudi 5 fevrier 2009 11:33 A : h.b.furuseth(a)usit.uio.no; ando(a)sys-net.it Cc : openldap-its(a)openldap.org Objet : RE: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard ------=_NextPart_000_00B1_01C987A2.419734D0 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 = 13:23:58.000000000 -1000=0A= +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-05 = 14:34:14.000000000 -1000=0A= @@ -212,19 +212,33 @@=0A= return( ld );=0A= }=0A= =0A= +char *=0A= +url_expand_on_srv_search ( const char *url_in )=0A= +{=0A= + // soon=0A= +=0A= + return LDAP_STRDUP( url_in );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, 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 url_expand_on_srv_search ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=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 +248,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_00B1_01C987A2.419734D0--

1 0

(ITS#5927) assertion error when using pcache
by mhardin＠symas.com 06 Feb '09

06 Feb '09

Full_Name: Matthew Hardin Version: 2.4.13 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We have an LDAP server that is proxying for Active Directory. Periodically slapd throws an assertion: slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: Assertion `i > 0' failed. /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS Howard Chu's examination of the core file showed that the remote AD server returned a member attribute with no values. This is only legal in LDAP when a client sets the attrsonly flag in its search request, and that flag was not set here. The indexer rightly asserts because pcache handed it an attribute with nothing to index. I'm not sure what the correct thing to do might be here, but it should not take down the slapd. Thanks, -Matt

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > gavin.henry(a)gmail.com wrote: >> Ok, but wouldn't that detail be best served staying in the man page? I >> mean, what "user" will want to enter hex for loglevels? > > Actually, I wonder what user would use the decimal notation. I > introduced the hexadecimal because I find it a little more intuitive in > terms of bitwise (then I decided to move to string-based :) After giving many training sessions, I can assure you many "doing their best" users trust the decimal notation. Their managers, trying to help analyze problems, also. I know one such guy, head of infrastructure for a multinational company, with little or no background in IT, who speaks fluently in decimal OpenLDAP log levels :) Also, specifying "255" is much shorter than "Trace Packets Args Conns BER Filter Config Args". Thus, I feel it's still useful to find decimal notations in the guide. At least, to understand existing configs. On the same basis, hex could be useful. Jonathan

1 0

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

05 Feb '09

And what do you think about : ldap://.nameOfSrvDomainSearch/ ('.' at begining of the hostname to say "use SRV record" of this domain - search domain(s) if only '.') ?... -- pe -----Message d'origine----- De : Hallvard Breien Furuseth [mailto:h.b.furuseth@usit.uio.no] Envoye : mercredi 4 fevrier 2009 05:02 A : Philippe.eychart(a)informatique.gov.pf Cc : openldap-its(a)openldap.org Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine) I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: ITS#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

Pierangelo Masarati wrote: > Howard Chu wrote: >> ando(a)sys-net.it wrote: >>> If it works, then we still have an issue: operations for "o=1,o=2" will >>> probably be intercepted by the back-bdb. However, I understand that >>> since the first database is glued, it wants to know whom it's glued to. >> A fix is in HEAD. It will allow this scenario to succeed, but it will >> also allow completely broken subordinate configs to be dynamically >> created in cn=config. (configs read from slapd.conf/slapd.d will still >> be error checked appropriately.) As such, it needs a bit more thought. > > Need ldap-txn, don't we? I guess that could help. We haven't figured out yet how to propagate TXNs in syncrepl though. -- -- 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#5925
by hyc＠symas.com 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > If it works, then we still have an issue: operations for "o=1,o=2" will > probably be intercepted by the back-bdb. However, I understand that > since the first database is glued, it wants to know whom it's glued to. A fix is in HEAD. It will allow this scenario to succeed, but it will also allow completely broken subordinate configs to be dynamically created in cn=config. (configs read from slapd.conf/slapd.d will still be error checked appropriately.) As such, it needs a bit more thought. -- -- 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#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Howard Chu wrote: > ando(a)sys-net.it wrote: >> If it works, then we still have an issue: operations for "o=1,o=2" will >> probably be intercepted by the back-bdb. However, I understand that >> since the first database is glued, it wants to know whom it's glued to. > > A fix is in HEAD. It will allow this scenario to succeed, but it will > also allow completely broken subordinate configs to be dynamically > created in cn=config. (configs read from slapd.conf/slapd.d will still > be error checked appropriately.) As such, it needs a bit more thought. Need ldap-txn, don't we? 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#5792) structuralObjectClass modification w/ relax not conformant to draft-zeilenga-ldap-relax
by ando＠sys-net.it 05 Feb '09

05 Feb '09

This is now fixed in HEAD: modifications to the objectClass attribute that change the structural objectClass are automatically reflected by in the structuralObjectClass attribute. What's missing right now is that structuralObjectClass should no longer be manageable (I believe). test037 also needs to be cleaned up. 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

ITS#5925
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Does it work if you change the order of the databases? I mean: +++ original dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] +++ original +++ modified dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn: olcDatabase={3}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] +++ modified If it works, then we still have an issue: operations for "o=1,o=2" will probably be intercepted by the back-bdb. However, I understand that since the first database is glued, it wants to know whom it's glued to. 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#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Should be fixed 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

(ITS#5926) slapd proxying AD with back-meta locks up
by mhardin＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Hardin Version: 2.4.12 OS: Red Hat Enterprise Linux 4 i686 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.114.185) Hi All, We are using a pair of OpenLDAP 2.4.12 servers with back-meta to proxy an active directory domain. The clients are all current versions of PADL's nss_ldap libraries. Every once in a while (sometimes twice a day, sometimes once every two weeks) one of the slapd servers will peg CPU use at 100% and stop answering requests. The only way to stop slapd is with a kill -9. There doesn't seem to be anything to explain the lockup or allow us to reproduce it. We are using redundant AD servers and they are not going offline. A third slapd server running as a test server using the same AD servers and configured identically but serving a much lighter nss_ldap load does not fail at all. We have ruled out hardware, OS, and connectivity as possible causes. We are unfortunately unable to attach gdb to the running processes, as these are production servers and need to be restarted immediately. Our smaller test system does not exhibit the same behavior, either. There is nothing unusual in the server logs, either. We do have core files generated from kill -6 commands, and they are all eerily similar to the back-trace below in that they have one or more threads waiting for a search or a bind response from AD. I am also enclosing relevant portions of slapd.conf for these systems. Please let me know if any additional information would be useful. Thanks, -Matt ----- (gdb) thr apply all bt Thread 18 (process 24520): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038b557 in pthread_join () from /lib/libpthread.so.0 #2 0x00a118dc in ldap_pvt_thread_join (thread=20691856, thread_return=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:197 #3 0x08070f79 in slapd_daemon () at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2656 #4 0x08058544 in main (argc=7, argv=0xbf90dec4) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/main.c:948 Thread 17 (process 24525): #0 0x005fa410 in __kernel_vsyscall () #1 0x005862c6 in epoll_wait () from /lib/libc.so.6 #2 0x080704ab in slapd_daemon_task (ptr=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:2291 #3 0x0038a45b in start_thread () from /lib/libpthread.so.0 #4 0x00585c4e in clone () from /lib/libc.so.6 Thread 16 (process 24526): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 15 (process 24527): #0 0x005fa410 in __kernel_vsyscall () #1 0x00586ca8 in send () from /lib/libc.so.6 #2 0x00582269 in __vsyslog_chk () from /lib/libc.so.6 #3 0x005825aa in syslog () from /lib/libc.so.6 #4 0x08085093 in slap_send_ldap_result (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/result.c:656 #5 0x00149c3c in bdb_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-bdb/search.c:1025 #6 0x080e09b1 in overlay_op_walk (op=0x9b5d968, rs=0x17bc120, which=op_search, oi=0x95d0e90, on=0x0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:667 #7 0x080e0b41 in over_op_func (op=0x9b5d968, rs=0x17bc120, which=op_search) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:719 #8 0x080e0bb9 in over_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/backover.c:741 #9 0x08076577 in fe_op_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #10 0x08075fa2 in do_search (op=0x9b5d968, rs=0x17bc120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #11 0x08073682 in connection_operation (ctx=0x17bc220, arg_v=0x9b5d968) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #12 0x08073acf in connection_read_thread (ctx=0x17bc220, argv=0x19c) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #13 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #14 0x0038a45b in start_thread () from /lib/libpthread.so.0 #15 0x00585c4e in clone () from /lib/libc.so.6 Thread 14 (process 24528): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 13 (process 24935): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 12 (process 26566): #0 0x005fa410 in __kernel_vsyscall () #1 0x0057c033 in poll () from /lib/libc.so.6 #2 0x00a2af30 in ldap_int_select (ld=0xaaf60a28, timeout=0x1bbbdb0) at os-ip.c:1053 #3 0x00a12eb8 in wait4msg (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:355 #4 0x00a12881 in ldap_result (ld=0xaaf60a28, msgid=59, all=2, timeout=0x1bbc028, result=0x1bbbeb4) at result.c:127 #5 0x00d73bba in meta_back_search (op=0xaaff7ce0, rs=0x1bbd120) ---Type <return> to continue, or q <return> to quit--- at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/back-meta/search.c:1027 #6 0x08076577 in fe_op_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:366 #7 0x08075fa2 in do_search (op=0xaaff7ce0, rs=0x1bbd120) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/search.c:217 #8 0x08073682 in connection_operation (ctx=0x1bbd220, arg_v=0xaaff7ce0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1084 #9 0x08073acf in connection_read_thread (ctx=0x1bbd220, argv=0x146) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1210 #10 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #11 0x0038a45b in start_thread () from /lib/libpthread.so.0 #12 0x00585c4e in clone () from /lib/libc.so.6 Thread 11 (process 26567): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 10 (process 29015): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 9 (process 11659): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 ---Type <return> to continue, or q <return> to quit--- #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 8 (process 29762): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080727c1 in connection_destroy (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:664 #6 0x08072d05 in connection_close (c=0xb7d7c450) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:799 #7 0x080741e3 in connection_read (s=333, cri=0x328b1a0) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1386 #8 0x08073a4d in connection_read_thread (ctx=0x328b220, argv=0x14d) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1203 #9 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #10 0x0038a45b in start_thread () from /lib/libpthread.so.0 #11 0x00585c4e in clone () from /lib/libc.so.6 Thread 7 (process 29763): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 6 (process 29764): #0 0x005fa410 in __kernel_vsyscall () #1 0x005925ee in __lll_mutex_lock_wait () from /lib/libc.so.6 #2 0x0058267d in _L_lock_700 () from /lib/libc.so.6 #3 0x005821a9 in __vsyslog_chk () from /lib/libc.so.6 #4 0x005825aa in syslog () from /lib/libc.so.6 #5 0x080d36b9 in do_syncrep2 (op=0x3a8cd70, si=0x95d0ff8) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1174 #6 0x080d3b93 in do_syncrepl (ctx=0x3a8d220, arg=0x95d1250) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/syncrepl.c:1301 ---Type <return> to continue, or q <return> to quit--- #7 0x08073aeb in connection_read_thread (ctx=0x3a8d220, argv=0xe) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/connection.c:1212 #8 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #9 0x0038a45b in start_thread () from /lib/libpthread.so.0 #10 0x00585c4e in clone () from /lib/libc.so.6 Thread 5 (process 29765): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 4 (process 29766): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 3 (process 29767): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 2 (process 29768): #0 0x005fa410 in __kernel_vsyscall () #1 0x0038e256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x00a119e6 in ldap_pvt_thread_cond_wait (cond=0x959a02c, mutex=0x959a014) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/thr_posix.c:277 ---Type <return> to continue, or q <return> to quit--- #3 0x00a10729 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:654 #4 0x0038a45b in start_thread () from /lib/libpthread.so.0 #5 0x00585c4e in clone () from /lib/libc.so.6 Thread 1 (process 29769): #0 0x005fa410 in __kernel_vsyscall () #1 0x004ddd10 in raise () from /lib/libc.so.6 #2 0x004df621 in abort () from /lib/libc.so.6 #3 0x004d715b in __assert_fail () from /lib/libc.so.6 #4 0x0806eec8 in slap_listener (sl=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1803 #5 0x0806f643 in slap_listener_thread (ctx=0x4e92220, ptr=0x9583108) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/servers/slapd/daemon.c:1997 #6 0x00a10783 in ldap_int_thread_pool_wrapper (xpool=0x959a010) at /home/build/sol-2_4_12-1-nonopt/sol24/ldap24/libraries/libldap_r/tpool.c:663 #7 0x0038a45b in start_thread () from /lib/libpthread.so.0 #8 0x00585c4e in clone () from /lib/libc.so.6 (gdb) ------ slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include /opt/symas/etc/openldap/schema/core.schema #include /opt/symas/etc/openldap/schema/ppolicy.schema #include /opt/symas/etc/openldap/schema/corba.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema #include /opt/symas/etc/openldap/schema/eduperson.schema #include /opt/symas/etc/openldap/schema/java.schema #include /opt/symas/etc/openldap/schema/krb5-kdc.schema #include /opt/symas/etc/openldap/schema/misc.schema include /opt/symas/etc/openldap/schema/nis.schema.my-customer #include /opt/symas/etc/openldap/schema/connexitor.schema #include /opt/symas/etc/openldap/schema/openldap.schema #include /opt/symas/etc/openldap/schema/samba.schema # TLS Setup Section # # TLSCACertificateFile <filename> # Specifies the file that contains certificates for all # of the Certificate Authorities that slapd will # recognize. #TLSCACertificateFile /opt/symas/ssl/cacert.pem TLSCACertificatePath /opt/symas/ssl/certs # # TLSCertificateFile <filename> # Specifies the file that contains the slapd server # certificate. TLSCertificateFile /opt/symas/etc/openldap/ldap-server1-4-cert.pem # # TLSCertificateKeyFile <filename> # Specifies the file that contains the slapd server # private key that matches the certificate stored in the # TLSCertificateFile file. Currently, the private key # must not be protected with a password, so it is of # critical importance that it is protected carefully. TLSCertificateKeyFile /opt/symas/etc/openldap/ldap-server1-4-key.pem # # TLSRandFile <filename> # Specifies the file from which to obtain random bits when # /dev/[u]random is not available. Generally set to the # name of the EGD/PRNGD socket. The environment variable # RANDFILE can also be used to specify the filename. #TLSRandFile /var/symas/egd-pool TLSVerifyClient never pidfile /var/symas/slapd.pid argsfile /var/symas/slapd.args modulepath /opt/symas/lib/openldap moduleload back_bdb.la moduleload syncprov.la moduleload back_ldap.la moduleload back_meta.la moduleload back_monitor.la # Access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn="" by * read access to * by self write by users read by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! ####################################################################### # Logging configuration loglevel none ####################################################################### # bdb database definitions ####################################################################### database bdb suffix "ou=nisdata" rootdn "ou=nisdata" rootpw xxxxxx # Indices to maintain. index default eq index objectClass index cn,sn,uid index uidNumber,gidNumber,memberUid,uniqueMember index oncRpcNumber,ipServicePort,ipServiceProtocol index ipNetworkNumber,ipHostNumber,ipProtocolNumber index entryCSN index entryUUID directory /var/symas/openldap-data/my-customer-nis cachesize 5000 idlcachesize 5000 checkpoint 512 60 # syncrepl consumer # Note that RIDs in mirrormode pair must be identical syncrepl rid=7 provider=ldaps://server01.my-customer.com searchbase=ou=nisdata type=refreshAndPersist retry="30 +" bindmethod=simple binddn=ou=nisdata credentials=xxxxxx tls_cacertdir=/opt/symas/ssl/certs tls_cert=/opt/symas/etc/openldap/ldap-server1-4-cert.pem tls_key=/opt/symas/etc/openldap/ldap-server1-4-key.pem tls_reqcert=demand syncdata=default # syncrepl Provider overlay syncprov syncprov-checkpoint 1000 60 mirrormode on ####################################################################### # Definitions for proxy and cache to AD ####################################################################### database meta suffix "dc=my-customer,dc=com" rootdn "cn=proxy,dc=my-customer,dc=com" rootpw xxxxxx limits users time.soft=30 time.hard=soft # The link to AD: uri ldaps://ldap-prd-dc01.my-customer.com/dc=ad,dc=my-customer,dc=com ldaps://ldap-prd-dc02.my-customer.com/ # Switch(es) we need for this target rewriteEngine on chase-referrals no conn-ttl 300 network-timeout 10 pseudoroot-bind-defer yes idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=cnsproxy,ou=service,ou=accounts,ou=restricted,dc=my-customer,dc=com" credentials=xxxxxx mode=legacy flags=override idassert-authzFrom "dn.regex:cn=proxy,dc=my-customer,dc=com" # We are putting the AD information under 'dc=ad' because it's going to # end up there in an upcoming change to the AD environment. This is also # a good thing because it helps back-meta unambiguously resolve references # to the AD target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=ad,dc=my-customer,dc=com"). This suffixmassage can be removed when that # change has been made in AD. suffixmassage "dc=ad,dc=my-customer,dc=com" "dc=my-customer,dc=com" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map objectClass posixAccount user map attribute uid samAccountName map attribute "" gecos map attribute gecos displayName map attribute homeDirectory unixHomeDirectory map attribute "" homeDirectory map attribute shadowLastChange pwdLastSet map attribute cn * map attribute gidNumber * map attribute sn * map attribute uidNumber * map attribute loginShell * map attribute "" accountExpires map attribute "" badPasswordTime map attribute "" badPwdCount map attribute "" codePage map attribute "" company map attribute "" countryCode map attribute "" department map attribute "" distinguishedName map attribute "" homeDrive map attribute "" initials map attribute "" instanceType map attribute "" lastLogoff map attribute "" lastLogon map attribute "" lastLogonTimeStamp map attribute "" logonCount #map attribute "" memberOf map attribute "" name map attribute "" objectCategory map attribute "" objectGuid map attribute "" objectSid map attribute "" primaryGroupId map attribute "" samAccountType map attribute "" userAccountControl map attribute "" userPrincipalName map attribute "" usnChanged map attribute "" usnCreated map attribute "" whenChanged map attribute "" whenCreated map attribute "" dscoRepropagationData map attribute "" groupType map objectClass posixGroup group # # The link to the NIS data directory (yes, we could chain/glue, that's # for later) uri ldapi://%2fvar%2fsymas%2frun%2fldapi/dc=nis,dc=my-customer,dc=com # Switch(es) needed for this target rewriteEngine on idassert-authzFrom "cn=proxy,dc=my-customer,dc=com" idassert-bind bindmethod=simple binddn="cn=proxy,ou=principals,dc=nis,dc=my-customer,dc=com" credentials=xxxxxxx mode=legacy # We are putting the NIS information under 'dc=nis' so that back-meta can # unambiguously resolve references to the NIS target. # This suffixmassage rewites the foreign DN suffix ("dc=my-customer,dc=com") # to the one we'll be using within the combined directory # ("dc=nis,dc=my-customer,dc=com"). suffixmassage "dc=nis,dc=my-customer,dc=com" "ou=nisdata" # It is necessary to map a number of objectclass and attribute names to # various other names that are supported in RFC2307. This section takes # care of that. map attribute member uniqueMember ####################################################################### # Monitor database ####################################################################### database monitor

1 0

ITS#5924
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Using valgrind, I note few issues conn=0 op=1 MODRDN dn="olcDatabase={2}bdb,cn=config" ==17038== Thread 3: ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715C1: config_rename_kids (bconfig.c:3816) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F140 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071583: config_rename_kids (bconfig.c:3814) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== ==17038== Invalid read of size 1 ==17038== at 0x821D904: lutil_strncopy (utils.c:438) ==17038== by 0x80A12E6: build_new_dn (dn.c:1172) ==17038== by 0x80715EE: config_rename_kids (bconfig.c:3818) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) ==17038== by 0x8224F80: ldap_int_thread_pool_wrapper (tpool.c:663) ==17038== Address 0x475F1A0 is 0 bytes inside a block of size 48 free'd ==17038== at 0x4004FDA: free (vg_replace_malloc.c:233) ==17038== by 0x825B5A9: ber_memfree_x (memory.c:152) ==17038== by 0x80A8129: ch_free (ch_malloc.c:139) ==17038== by 0x8071594: config_rename_kids (bconfig.c:3815) ==17038== by 0x80719E1: config_rename_one (bconfig.c:3893) ==17038== by 0x8071C08: config_renumber_one (bconfig.c:3943) ==17038== by 0x8073A4C: config_rename_del (bconfig.c:4663) ==17038== by 0x8075703: config_back_modrdn (bconfig.c:5373) ==17038== by 0x80A7273: fe_op_modrdn (modrdn.c:314) ==17038== by 0x80A6BD6: do_modrdn (modrdn.c:186) ==17038== by 0x8086511: connection_operation (connection.c:1100) ==17038== by 0x80869EB: connection_read_thread (connection.c:1226) conn=0 op=1 RESULT tag=109 err=0 text= which eventually result in the screwed name of the children entries of the renamed database. I'm investigating... 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ando＠sys-net.it 05 Feb '09

05 Feb '09

gavin.henry(a)gmail.com wrote: > Ok, but wouldn't that detail be best served staying in the man page? I > mean, what "user" will want to enter hex for loglevels? Actually, I wonder what user would use the decimal notation. I introduced the hexadecimal because I find it a little more intuitive in terms of bitwise (then I decided to move to string-based :) 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: Docs: admin guide describes log levels inconsistently (ITS#5904)
by gavin.henry＠gmail.com 05 Feb '09

05 Feb '09

Ok, but wouldn't that detail be best served staying in the man page? I mean, what "user" will want to enter hex for loglevels? I'll make the same anyway. Thanks. On 05/02/2009, quanah(a)zimbra.com <quanah(a)zimbra.com> wrote: > --On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > >> Awww, aren't we nice! ;-) >> >> Patch applied, > > The new patch is definitely an improvement, however it fails to document > the hexadecimal notation for log levels, which is also perfectly valid. > See slapd.conf(5): > > 1 (0x1 trace) trace function calls > 2 (0x2 packets) debug packet handling > 4 (0x4 args) heavy trace debugging (function args) > > > and the description therein: > > The desired log level can be input as a single integer that > combines the (ORed) desired levels, both in decimal or in > hexadecimal notation, as a list of integers (that are ORed > internally), or as a list of the names that are shown between > brackets, such that > > loglevel 129 > loglevel 0x81 > loglevel 128 1 > loglevel 0x80 0x1 > loglevel acl trace > > are equivalent. > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/

1 0

Re: (ITS#5326) Add could re-build entry's DN using parent's DN and entry's RDN
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Fixed in HEAD for back-bdb & back-hdb; back-ldif does not suffer from this issue. proxy backends and so should neither. Not sure about other backends like back-sql and back-ndb. 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

Re: (ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

ando(a)sys-net.it wrote: > A fix is coming (hopefully for 2.4.14 :). p. Fixed in HEAD. 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

(ITS#5925) [backend config] glue: no superior found in N-Way Multi-Master replication
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) When : when a replica replicates its entire cn=config from a provider, and the configuration has gluing databases. Suppose you have into your config backend the following : 8<-------- dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://1.2.3.4/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 olcSyncrepl: {1}rid=002 provider=ldap://1.2.3.5/ binddn="cn=config" bin dmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPer sist retry="5 +" timeout=3 [...] dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config [...] dn: olcDatabase={2}ldap,cn=config olcSuffix: o=1,o=2 olcSubordinate: TRUE [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config [...] 8<-------- slaptest passes successfully, and OpenLDAP starts. When a new provider joins the N-Way Multi-Master replication, it replicates all the configuration from the primary provider (which is indicated in its minimalistic configuration). But, the replication failed on the following error : 8<-------- Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_search (0) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 olcDatabase={2}ldap,cn=config Feb 5 18:25:04 server2 slapd[6202]: glue: no superior found for sub o=1,o=2! Feb 5 18:25:04 server2 slapd[6202]: olcSubordinate: value #0: <olcSubordinate> handler exited with 32! Feb 5 18:25:04 server2 slapd[6202]: null_callback : error code 0x50 Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add (80) Feb 5 18:25:04 server2 slapd[6202]: syncrepl_entry: rid=001 be_add failed (80) Feb 5 18:25:04 server2 slapd[6202]: do_syncrepl: rid=001 retrying 8<-------- It appears that ldap's backend which is subordinate to an other backend should be declared after this gluing database. This is exactly the contrary on how works slapd.conf. Thomas.

1 0

(ITS#5924) [backend config] modify rdn on a backend entry will cause bad renaming of all subentries when retrieving by ldapsearch
by tchemineau＠linagora.com 05 Feb '09

05 Feb '09

Full_Name: Thomas Chemineau Version: OPENLDAP_REL_ENG_2_4 OS: CentOS 5.2 64 bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.243.192) Renaming an entry of a configugred OpenLDAP backend causes bad renaming of its subentries and all subentries of all other backends, when retrieving them by a simple LDAP search. For example, suppose you have these configuration into slapd.conf : 8<-------- database bdb suffix "o=1" directory /usr/local/openldap-2.4/var/openldap-data-1 overlay rwm rwm-suffixmassage o=1 dc=1 database bdb suffix "o=2" overlay glue rootdn "cn=Directory Manager,o=2" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-2 database bdb suffix "o=3" rootdn "cn=Directory Manager,o=3" rootpw secret directory /usr/local/openldap-2.4/var/openldap-data-3 8<-------- When you convert slapd.conf to slapd.d (backend config), then you should obtain something like the following (slapcat -b cn=config -F ...) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=1 [...] dn: olcOverlay={0}rwm,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={3}bdb,cn=config olcSuffix: o=2 [...] dn: olcOverlay={0}glue,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig olcOverlay: {0}glue dn: olcDatabase={4}bdb,cn=config olcSuffix: o=3 [...] 8<-------- Now, for some reason, you want to rename olcDatabase={2}bdb,cn=config into olcDatabase={3}bdb,cn=config (to invert declaration for example). This operation works successfully but causes all subentries DN to be rename improperly. You obtain someting like the following via ldapsearch (not via slapcat) : 8<-------- [...] dn: olcDatabase={-1}frontend,cn=config [...] dn: olcDatabase={0}config,cn=config [...] dn: olcDatabase={1}monitor,cn=config [...] dn: olcDatabase={2}bdb,cn=config olcSuffix: o=2 [...] dn:: IHFbGSxvbGNEYXRhYmFzZT17Mn1iZGIsY249Y29uZmlnAGJkYixjbj1jb25maWc= objectClass: olcOverlayConfig olcOverlay: {0}glue [...] dn: olcDatabase={3}bdb,cn=config olcSuffix: o=1 [...] dn:: LG9sY0RhdGFiYXNlPXszfWJkYixjbj1jb25maWcAezJ9YmRiLGNuPWNvbmZpZw== objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-suffixmassage "o=1" "dc=1" olcRwmTFSupport: false olcRwmNormalizeMapped: FALSE dn: olcDatabase={4}bdb,cn=config [...] 8<-------- When decoding DN, we obtain bad characters. This issue provide broken replication in a N-Way Multi-Master cluster. Thomas.

1 0

Re: Re (ITS#5843) N-way Multi-master doesn't replicate deletes under certain circumstances.
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

adrien.futschik(a)atosorigin.com wrote: > >> No. Replication is supposed to work regardless of mode, refreshOnly / >> refreshAndPersist should yield identical results. > ... > >> There is still a bug here. > > You mean that the fact that N-way Multi-master doesn't replicate deletes properly when using "refreshOnly" is a bug ? > > But N-way Multi-master seams to be working correctly when using "refreshAndPersist". I see some reasons why using "refreshOnly" instead of "refreshAndPersist", will this be corrected in the next release of OpenLDAP ? > > What is recommended with OpenLDAP 2.4.11. Should we wait for the next stable release if we intend to use N-way Multi-master in production ? I would wait for 2.4.14. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by quanah＠zimbra.com 05 Feb '09

05 Feb '09

--On Thursday, February 05, 2009 11:41 AM +0000 ghenry(a)OpenLDAP.org wrote: > Awww, aren't we nice! ;-) > > Patch applied, The new patch is definitely an improvement, however it fails to document the hexadecimal notation for log levels, which is also perfectly valid. See slapd.conf(5): 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging (function args) and the description therein: The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that loglevel 129 loglevel 0x81 loglevel 128 1 loglevel 0x80 0x1 loglevel acl trace are equivalent. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5923) slapo-rwm may cause double frees when rewriting DN-valued attrs in search entry responses
by ando＠sys-net.it 05 Feb '09

05 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.6) Submitted by: ando A fix is coming (hopefully for 2.4.14 :). p.

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- jclarke(a)linagora.com wrote: > Gavin Henry wrote: > > Can you follow the IPR notice details at: > > > > http://www.openldap.org/devel/contributing.html > > > > Since this is a patch, we need the above adhering to. > > Gavin, > > Of course. Thanks Jonathan. > I, Jonathan Clarke, hereby place the following modifications to > OpenLDAP > Software (and only these modifications) into the public domain. Hence, > > these modifications may be freely used and/or redistributed for any > purpose with or without attribution and/or other notice. > > URL: > ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch > > Since this is not new code (mostly simple copy and paste from the man > > pages), I have not included a notice of origin in the patch file. I > hope > this is correct. Let me know, otherwise. > > > Thanks for your work, it's always appreciated when someone take time > to > > contribute! > > My pleasure, it's always nice to have such a great base to contribute > to :) Awww, aren't we nice! ;-) Patch applied, Thanks. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Docs: admin guide describes log levels inconsistently (ITS#5904)
by jclarke＠linagora.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > Can you follow the IPR notice details at: > > http://www.openldap.org/devel/contributing.html > > Since this is a patch, we need the above adhering to. Gavin, Of course. I, Jonathan Clarke, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-guide-20090124-2.patch Since this is not new code (mostly simple copy and paste from the man pages), I have not included a notice of origin in the patch file. I hope this is correct. Let me know, otherwise. > Thanks for your work, it's always appreciated when someone take time to > contribute! My pleasure, it's always nice to have such a great base to contribute to :) Jonathan

1 0

Re: (ITS#5922) progress bar proposal
by ghenry＠OpenLDAP.org 05 Feb '09

05 Feb '09

----- "Howard Chu" <hyc(a)symas.com> wrote: > Gavin Henry wrote: > > ----- hyc(a)symas.com wrote: > > > >> hyc(a)symas.com wrote: > >>> progress seems a bit too generic; the names probably should be > >> prefixed with > >>> lutil. Also I suggest using "meter" instead of "progress". > >>> > >>> lutil-meter.h, meter.c. > >> Currently it's enabled by default. I have a feeling it should be > >> disabled when > >> various debug flags are set. Any thoughts? Would there ever be a > >> situation > >> where you want debug enabled *and* the progress meter enabled? > > > > How would that work? The debug message would stream down your > console > > and then the meter would have to consistently return to the start of > the > > prompt/window to make any sense? Or would it would it switch to just > showing > > an elapsed time and the end of the run? > > > The messages would all be interleaved; it would be rather ugly. Thought so. So off when debug is on make perfect sense to me. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

Gavin Henry wrote: > ----- hyc(a)symas.com wrote: > >> hyc(a)symas.com wrote: >>> progress seems a bit too generic; the names probably should be >> prefixed with >>> lutil. Also I suggest using "meter" instead of "progress". >>> >>> lutil-meter.h, meter.c. >> Currently it's enabled by default. I have a feeling it should be >> disabled when >> various debug flags are set. Any thoughts? Would there ever be a >> situation >> where you want debug enabled *and* the progress meter enabled? > > How would that work? The debug message would stream down your console > and then the meter would have to consistently return to the start of the > prompt/window to make any sense? Or would it would it switch to just showing > an elapsed time and the end of the run? > The messages would all be interleaved; it would be rather ugly. -- -- 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#5922) progress bar proposal
by ghenry＠suretecsystems.com 05 Feb '09

05 Feb '09

----- hyc(a)symas.com wrote: > hyc(a)symas.com wrote: > > progress seems a bit too generic; the names probably should be > prefixed with > > lutil. Also I suggest using "meter" instead of "progress". > > > > lutil-meter.h, meter.c. > > Currently it's enabled by default. I have a feeling it should be > disabled when > various debug flags are set. Any thoughts? Would there ever be a > situation > where you want debug enabled *and* the progress meter enabled? How would that work? The debug message would stream down your console and then the meter would have to consistently return to the start of the prompt/window to make any sense? Or would it would it switch to just showing an elapsed time and the end of the run? -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html

1 0

Re: (ITS#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

hyc(a)symas.com wrote: > progress seems a bit too generic; the names probably should be prefixed with > lutil. Also I suggest using "meter" instead of "progress". > > lutil-meter.h, meter.c. Currently it's enabled by default. I have a feeling it should be disabled when various debug flags are set. Any thoughts? Would there ever be a situation where you want debug enabled *and* the progress meter enabled? -- -- 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#5922) progress bar proposal
by hyc＠symas.com 05 Feb '09

05 Feb '09

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, head > OS: any > URL: > Submission from: (NULL) (76.88.99.93) > > > Here is a proposal for a progress bar reporting tool, to appear in > slapadd and other long running tools. A similar version was used > previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is > significantly more modular, so that alternative estimators and display > systems may be added. > > By default, it displays a text bar showing activity, progress, percent > completion, estimated time to completion, elapsed time, and speed in > bytes of ldif per second. > > The display functions are modular so that we could add a running trace > of numbers that a graphical front-end might read and transform into > pretty animated pie charts, or potentially fancier display within > these tools. > > The default (and only) supplied display system currently relies only > on carriage return, with no external libraries needed or dependencies > on terminal features. > > Estimators are modular as well, as the default linear estimator can be > frustratingly poor for very large, poorly tuned databases with > extremely non-linear load times. > > Progress is estimated by fstat()ing the ldif file and ftell()ing to > see the position. As a result, ldif read from stdin automatically > disables the progress bar. > > Files are available at: > > http://lirone.symas.net/lucca/progress-bar/ > > * Apply progress.patch > * Copy progress.c into libraries/liblutil/progress.c > * Copy progress.h into include/progress.h progress seems a bit too generic; the names probably should be prefixed with lutil. Also I suggest using "meter" instead of "progress". lutil-meter.h, meter.c. > We should probably make this configurable via the commandline (on/off, > as well as which display and estimator systems to use), but currently > it is always on provided stderr is a tty and the ldif is a file. -- -- 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#5922) progress bar proposal
by mbackes＠symas.com 05 Feb '09

05 Feb '09

In clarification of software origins, the progress bar code is my own original work (as a Symas employee). Symas retains copyright but licenses it under the OpenLDAP Public License. Patches to makefiles and slapd.c are derivative of work by the OpenLDAP project. "progress.c" and "progress.h" are Copyright 2009 by Symas Corporation and myself. Redistribution and use in source and binary forms, with or without modification, are permitted as authorized by the OpenLDAP Public License. progress.patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the patch were developed by myself at Symas Corporation. We have not assigned rights and/or interest in this work to any party. I, Matthew Backes, am authorized by Symas Corporation, my employer, to release this work under the terms of the OpenLDAP Public License, as available from http://www.OpenLDAP.org/license.html . Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#5922) progress bar proposal
by mbackes＠symas.com 05 Feb '09

05 Feb '09

Full_Name: Matthew Backes Version: 2.4, head OS: any URL: Submission from: (NULL) (76.88.99.93) Here is a proposal for a progress bar reporting tool, to appear in slapadd and other long running tools. A similar version was used previously in Symas's OpenLDAP 2.3 (CDS3) product. This version is significantly more modular, so that alternative estimators and display systems may be added. By default, it displays a text bar showing activity, progress, percent completion, estimated time to completion, elapsed time, and speed in bytes of ldif per second. The display functions are modular so that we could add a running trace of numbers that a graphical front-end might read and transform into pretty animated pie charts, or potentially fancier display within these tools. The default (and only) supplied display system currently relies only on carriage return, with no external libraries needed or dependencies on terminal features. Estimators are modular as well, as the default linear estimator can be frustratingly poor for very large, poorly tuned databases with extremely non-linear load times. Progress is estimated by fstat()ing the ldif file and ftell()ing to see the position. As a result, ldif read from stdin automatically disables the progress bar. Files are available at: http://lirone.symas.net/lucca/progress-bar/ * Apply progress.patch * Copy progress.c into libraries/liblutil/progress.c * Copy progress.h into include/progress.h We should probably make this configurable via the commandline (on/off, as well as which display and estimator systems to use), but currently it is always on provided stderr is a tty and the ldif is a file. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

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

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: Most of system définitions may also be centralized without any used of Active Directory. Redundance notions are nevertheless necessary, also inside Linux-land ... ;-) Used of SRV rr is a good reponse, (in particular in case of large Intranet with many remote sites -islands in pacific- and poor communication ressources - satellite) but require to be performed in all client applications : nssldap, samba, ldap client tools for rsync/mail/DNS/proxy/supervision definitions, ... or openldap.

1 0

Re: (ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > This can be solved along with ITS#5792 relatively easily from within > entry_schema_check(), provided the structuralObjectClass attribute is not > indexed. Otherwise, things get a little bit more complicated. Fixed in HEAD, including the (unlikely) case structuralObjectClass is indexed. 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

(ITS#5921) When structural objectClass is modified, the structuralObjectClass attribute is not
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.100.26) Submitted by: ando When the structural objectClass of an entry is modified, the corresponding structuralObjectClass attr is not modified accordingly. While addressing ITS#5792, I found out that the only other case that allows modification of the structural objectClass of an object, from "glue" to any other class using the manageDSAit control, results in an entry with the objectClass attribute set to the modified values, while the structuralObjectClass attribute remains "glue". This can be solved along with ITS#5792 relatively easily from within entry_schema_check(), provided the structuralObjectClass attribute is not indexed. Otherwise, things get a little bit more complicated. p.

1 0

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

04 Feb '09

----- "h b furuseth" <h.b.furuseth(a)usit.uio.no> wrote: > I'm not quite sure if it's a good idea to move ldap SRV lookup into > ldap_initialize(), since ldap:/// is also means "this LDAP server" in > referral objects and some slapd backends. Possibly some other syntax > should be used to say "use SRV record", e.g. "ldap://./", or another > function could work like ldap_initialize() but be more clever. Though > a > helper function which copies clients/tools/common.c:tool_conn_setup() > functionality could in any case be useful. Probably the cleanest solution is to use extensions. 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 michael＠stroeder.com 04 Feb '09

04 Feb '09

h.b.furuseth(a)usit.uio.no wrote: > Also note that _ldap._tcp.domain is of limited utility outside > Windows-land, because Microsoft annexed it for Active Directory: I don't see why. > On a site which has Windows and Active Directory, _ldap._tcp.domain > is normally required to refer to Active Directory. Thus if such > a site uses another LDAP server for their public LDAP data, they > can't _ldap._tcp.domain for that. Off course you should use distinct "domains" (better say dc-style naming contexts for MS AD and other OpenLDAP DSAs). But then it won't collide. Ciao, Michael.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by h.b.furuseth＠usit.uio.no 04 Feb '09

04 Feb '09

I'm not quite sure if it's a good idea to move ldap SRV lookup into ldap_initialize(), since ldap:/// is also means "this LDAP server" in referral objects and some slapd backends. Possibly some other syntax should be used to say "use SRV record", e.g. "ldap://./", or another function could work like ldap_initialize() but be more clever. Though a helper function which copies clients/tools/common.c:tool_conn_setup() functionality could in any case be useful. Also note that _ldap._tcp.domain is of limited utility outside Windows-land, because Microsoft annexed it for Active Directory: On a site which has Windows and Active Directory, _ldap._tcp.domain is normally required to refer to Active Directory. Thus if such a site uses another LDAP server for their public LDAP data, they can't _ldap._tcp.domain for that. -- Hallvard

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by michael＠stroeder.com 04 Feb '09

04 Feb '09

ando(a)sys-net.it wrote: > Philippe.eychart(a)informatique.gov.pf wrote: > >> The "tool_conn_setup" function (in common.c) autorise the Url synthaxe >> "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server >> to request (not yet according the rfc 2782 - I've made dnssrv.c patch to >> implement priorities and I try to implement weight before submit this work). So, >> the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via >> "ldap_dn2domain" and "ldap_domain2hostlist" functions). > > This was done to allow testing client-side the DNS SRV feature. > >> Unfortunately, ldap_initialize() doesn't use these functions (but only >> ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages >> (like SAMBA) doesn't enjoy this capability : "passdb backend = >> ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition >> "_ldap._tcp.my.domain. IN SRV ..." >> >> Is there any reason for that ? Can we envisage to increase this possibility ? > > None that I'm aware of. Feel free to move that code from tools to > libldap. Patches are welcome, as usual. But please put a note into the accompanying man-page with a strong recommendation not to use it without further security mechs. I wouldn't configure Samba like this. (Similar problems like DNS lookups in Kerberos implementations for realm- and KDC-discovery.) I've implemented something like this in web2ldap but the SRV mech causes an user interaction on the UI. So the user has a vague chance to determine whether he's tricked to another DSA by DNS spoofing. Ciao, Michael.

1 0

Re: (ITS#5920) segfault in sockbuf.c
by hyc＠symas.com 04 Feb '09

04 Feb '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: RE24 01/30/2009 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I link postfix against OpenLDAP libraries for its ldap lookups. With my > previous CVS checkout of RE24 (12/9/2008) there were no problems with this. > However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap > binary always segfaults: > This is likely related to the recent TLS changes in RE24. Yes, 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#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 04 Feb '09

04 Feb '09

Philippe.eychart(a)informatique.gov.pf wrote: > The "tool_conn_setup" function (in common.c) autorise the Url synthaxe > "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server > to request (not yet according the rfc 2782 - I've made dnssrv.c patch to > implement priorities and I try to implement weight before submit this work). So, > the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via > "ldap_dn2domain" and "ldap_domain2hostlist" functions). This was done to allow testing client-side the DNS SRV feature. > Unfortunately, ldap_initialize() doesn't use these functions (but only > ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages > (like SAMBA) doesn't enjoy this capability : "passdb backend = > ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition > "_ldap._tcp.my.domain. IN SRV ..." > > Is there any reason for that ? Can we envisage to increase this possibility ? None that I'm aware of. Feel free to move that code from tools to libldap. Patches are welcome, as usual. 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

(ITS#5920) segfault in sockbuf.c
by quanah＠zimbra.com 04 Feb '09

04 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 01/30/2009 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) I link postfix against OpenLDAP libraries for its ldap lookups. With my previous CVS checkout of RE24 (12/9/2008) there were no problems with this. However, I updated to CVS of RE24 as of 1/30/2009, and now the postfix proxymap binary always segfaults: Core was generated by `proxymap -t unix -u'. Program terminated with signal 11, Segmentation fault. [New process 19154] #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 168 sockbuf.c: No such file or directory. in sockbuf.c (gdb) bt #0 0xb7de3836 in ber_sockbuf_ctrl (sb=0x807bfc0, opt=7, arg=0xbf8c9760) at sockbuf.c:168 #1 0xb7e21eaf in ldap_pvt_tls_inplace (sb=0x807bfc0) at tls2.c:456 #2 0xb7e21f2c in ldap_tls_inplace (ld=0x807ce18) at tls2.c:475 #3 0xb7e22e84 in ldap_start_tls_s (ld=0x807ce18, serverctrls=0x0, clientctrls=0x0) at tls2.c:922 #4 0x080514aa in dict_ldap_connect (dict_ldap=0x807ca08) at dict_ldap.c:711 #5 0x0805257e in dict_ldap_lookup (dict=0x807ca08, name=0x807cbc8 "*") at dict_ldap.c:1123 #6 0x0804b590 in proxymap_service (client_stream=0x80799a8, unused_service=0xbf8cbf6d "proxymap", argv=0xbf8c9f24) at proxymap.c:354 #7 0x0804c5d2 in multi_server_execute (unused_event=1, context=0x80799a8 "") at multi_server.c:311 #8 0x0805b08d in event_loop (delay=-1) at events.c:1079 #9 0x0804bee0 in multi_server_main (argc=4, argv=0xbf8c9f14, service=0x804b1b0 <proxymap_service>) at multi_server.c:841 #10 0x0804add4 in main (argc=4, argv=0xbf8c9f14) at proxymap.c:651 (gdb) print *sb $2 = {sb_opts = {lbo_valid = 3, lbo_options = 0, lbo_debug = 0}, sb_iod = 0x0, sb_fd = -1, sb_max_incoming = 0, sb_trans_needs_read = 0, sb_trans_needs_write = 0} This is likely related to the recent TLS changes in RE24.

1 0

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

03 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My first work ... -----Message d'origine----- De : openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org] Envoy=E9 : mardi 3 f=E9vrier 2009 11:02 =C0 : Philippe.eychart(a)informatique.gov.pf Objet : Re: (ITS#5919) URI syntaxe (ldap:///dc=3Dmy%2cdc=3Ddomaine) *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#5919. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#5919) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#5919) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D5919 Please remember to retain your issue tracking number (ITS#5919) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. ------=_NextPart_000_002C_01C985F1.ABA10980 Content-Type: application/octet-stream; name="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="openldap-2.4.13-i486-1.rfc2782-priOnly.dnssrv.c.patch" --- openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-23 = 20:56:43.000000000 +0000=0A= +++ openldap-2.4.13/libraries/libldap/dnssrv.c 2009-01-24 = 01:00:47.000000000 +0000=0A= # This patch file is derived from OpenLDAP Software. All of the = modifications to OpenLDAP Software represented in the following = patch(es) were developed by Philippe.EYCHART(a)mail.pf. I have not = assigned rights and/or interest in this work to any party.=0A= # this patch for more compliance with RFC 2782 : the result string is = sorted by priorities (SRV rr) in function ldap_domain2hostlist() ... not = yet according weight :-(=0A= @@ -223,10 +223,14 @@=0A= #endif=0A= if (len >=3D 0) {=0A= unsigned char *p;=0A= - char host[DNSBUFSIZ];=0A= + struct hostInfo {=0A= + char name[DNSBUFSIZ];=0A= + int priority;=0A= + /* int weight; */=0A= + u_short port;=0A= + } *host =3D NULL;=0A= + int curhost=3D0;=0A= int status;=0A= - u_short port;=0A= - /* int priority, weight; */=0A= =0A= /* Parse out query */=0A= p =3D reply;=0A= @@ -242,8 +246,15 @@=0A= p +=3D sizeof(HEADER);=0A= #endif=0A= =0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + host =3D (struct hostInfo *) LDAP_MALLOC (sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + goto out;=0A= + }=0A= +=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -251,8 +262,9 @@=0A= =0A= while (p < reply + len) {=0A= int type, class, ttl, size;=0A= - status =3D dn_expand(reply, reply + len, p, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= p +=3D status;=0A= @@ -265,35 +277,61 @@=0A= size =3D (p[0] << 8) | p[1];=0A= p +=3D 2;=0A= if (type =3D=3D T_SRV) {=0A= - int buflen;=0A= - status =3D dn_expand(reply, reply + len, p + 6, host, sizeof(host));=0A= + status =3D dn_expand(reply, reply + len, p + 6, host[curhost].name, = sizeof(host[curhost].name));=0A= if (status < 0) {=0A= + LDAP_FREE (host);=0A= goto out;=0A= }=0A= - /* ignore priority and weight for now */=0A= - /* priority =3D (p[0] << 8) | p[1]; */=0A= - /* weight =3D (p[2] << 8) | p[3]; */=0A= - port =3D (p[4] << 8) | p[5];=0A= + host[curhost].priority =3D (p[0] << 8) | p[1];=0A= + /* ignore weight for now */=0A= + /* host[curhost].weight =3D (p[2] << 8) | p[3]; */=0A= + host[curhost].port =3D (p[4] << 8) | p[5];=0A= =0A= - if ( port =3D=3D 0 || host[ 0 ] =3D=3D '\0' ) {=0A= + if ( host[curhost].port =3D=3D 0 || host[curhost].name[ 0 ] =3D=3D = '\0' ) {=0A= goto add_size;=0A= }=0A= =0A= - buflen =3D strlen(host) + STRLENOF(":65355 ");=0A= - hostlist =3D (char *) LDAP_REALLOC(hostlist, cur + buflen + 1);=0A= - if (hostlist =3D=3D NULL) {=0A= + curhost++;=0A= + host =3D (struct hostInfo *) LDAP_REALLOC (host, (curhost + 1) * = sizeof (struct hostInfo));=0A= + if ( ! host ) {=0A= rc =3D LDAP_NO_MEMORY;=0A= goto out;=0A= }=0A= - if (cur > 0) {=0A= - /* not first time around */=0A= - hostlist[cur++] =3D ' ';=0A= - }=0A= - cur +=3D sprintf(&hostlist[cur], "%s:%hd", host, port);=0A= +=0A= }=0A= add_size:;=0A= p +=3D size;=0A= }=0A= +=0A= + if ( host[0].name[ 0 ] ) {=0A= + int nbhosts=3Dcurhost, bull;=0A= + unsigned char buffer[sizeof (struct hostInfo)]; // :(=0A= +=0A= + // sort hosts by priorities ...=0A= + for (bull=3D(char)1; bull; ) { bull=3D(char)0;=0A= + for ( curhost=3D1; curhost < nbhosts; curhost++ ) {=0A= + if ( host[curhost].priority < host[curhost-1].priority ) {=0A= + bull =3D (char)1;=0A= + memcpy ( (struct hostInfo *)buffer, &host[curhost-1], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost-1], &host[curhost], sizeof = (struct hostInfo));=0A= + memcpy ( &host[curhost], (struct hostInfo *)buffer, sizeof = (struct hostInfo));=0A= + } } }=0A= +=0A= + // do hostlist, string result ...=0A= + for ( cur=3Dcurhost=3D0; curhost < nbhosts; curhost++ ) {=0A= +=0A= + hostlist =3D (char *) LDAP_REALLOC (hostlist, cur + = strlen(host[curhost].name) + STRLENOF(":65535 ") + 1);=0A= + if (hostlist =3D=3D NULL) {=0A= + rc =3D LDAP_NO_MEMORY;=0A= + LDAP_FREE (host);=0A= + goto out;=0A= + }=0A= + cur +=3D sprintf(&hostlist[cur], "%s:%hd ", host[curhost].name, = host[curhost].port);=0A= +=0A= + } hostlist[cur] =3D '\0'; /* remove last ' ' */=0A= + }=0A= +=0A= + LDAP_FREE (host);=0A= }=0A= if (hostlist =3D=3D NULL) {=0A= /* No LDAP servers found in DNS. */=0A= ------=_NextPart_000_002C_01C985F1.ABA10980--

1 0

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

03 Feb '09

Full_Name: Philippe EYCHART Version: 2.4.13 OS: slack12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.82.141) Hi, The "tool_conn_setup" function (in common.c) autorise the Url synthaxe "ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server to request (not yet according the rfc 2782 - I've made dnssrv.c patch to implement priorities and I try to implement weight before submit this work). So, the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via "ldap_dn2domain" and "ldap_domain2hostlist" functions). Unfortunately, ldap_initialize() doesn't use these functions (but only ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages (like SAMBA) doesn't enjoy this capability : "passdb backend = ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition "_ldap._tcp.my.domain. IN SRV ..." Is there any reason for that ? Can we envisage to increase this possibility ? Regards

1 0

(ITS#5918) slapacl(8c) badly worded
by quanah＠zimbra.com 03 Feb '09

03 Feb '09

Full_Name: Quanah Gibson-Mount Version: RE24 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Slapacl is used to check the behavior of the slapd in verifying access to data according to ACLs, as specified in slapd.access(5). It opens the slapd.conf(5) configuration file, reads in the access directives, and then parses the attr list given on the command-line; if none is given, access to the entry pseudo-attribute is tested. Besides the bit about "of the slapd", the first sentence is rather awkward.

1 0

RE: (ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com 03 Feb '09

03 Feb '09

Hi We have tested the solution. It works OK. Greetings, Jorge. -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: jueves, 29 de enero de 2009 20:34 To: Jorge Nevado Cc: openldap-its(a)openldap.org Subject: Re: (ITS#5912) Meta modify increment feature Fixed in HEAD; please test. Thanks, 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#5398) An account locked in a consumer is only unlocked when the password is changed two times
by hyc＠symas.com 03 Feb '09

03 Feb '09

ssnet(a)ua.es wrote: > Full_Name: maria saez > Version: 2.4.8 > OS: debian etch > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.145.230.2) > > > > An account locked in a consumer needs two password changes in the provider to be > unlocked. I'm unable to reproduce this behavior in current code. > The first time that we change the password in the provider the password change > is replicated in the consumer but the account remains locked. A single password change on the provider results in unlocking on the consumer for me. > > Can you help us? > We have openldap-2.4.7 and openldap-2.4.8 > > Is this situation normal? > > We have the following configuration: > > Provider > ------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > # define the replica provider for this database > # (last directives in database section) > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es" > ppolicy_use_lockout > > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > > Consumer > ---------------------------------------------------------------- > database bdb > suffix "dc=xx,dc=es" > rootdn "cn=config" > directory /xx/data > index entryCSN eq > index entryUUID eq > index objectClass eq > index mail eq > > overlay ppolicy > ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es" > ppolicy_use_lockout > > syncrepl rid=123 > provider=ldaps://xx.xx.es:xx/ > binddn="cn=config" > bindmethod=simple > credentials=xx > searchbase="dc=xx,dc=es" > schemachecking=on > type=refreshAndPersist > retry="60 +" > > overlay syncprov > ------------------------------------------------------------------- > The policy we have defined: > > dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es > cn: Standard Policy > objectClass: top > objectClass: device > objectClass: pwdPolicy > pwdAttribute: 2.5.4.35 > pwdLockout: TRUE > pwdLockoutDuration: 0 > pwdInHistory: 6 > pwdCheckQuality: 2 > pwdExpireWarning: 10 > pwdMaxAge: 120 > pwdMinLength: 5 > pwdGraceAuthnLimit: 3 > pwdAllowUserChange: TRUE > pwdMustChange: TRUE > pwdMaxFailure: 3 > pwdFailureCountInterval: 120 > pwdSafeModify: TRUE > pwdMinAge: 120 > ------------------------------------------------------------- > > > -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs