- openldap-bugs - openldap.org

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

05 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 05 Feb '09

05 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 05 Feb '09

05 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs