- openldap-bugs - openldap.org

Re: (ITS#4702) out-of-memory on huge DB ?
by quanah＠stanford.edu 08 Oct '06

08 Oct '06

--On Sunday, October 08, 2006 4:35 AM +0000 hyc(a)symas.com wrote: >> Then I've tried to syncrepl the entire DB, turning on the empty >> consumers (crazy idea ;) i know ) but the provider memory allocated, >> again reached 4GB and... bum >> >> some ideas? 4GB is the memory limit on 32-bit Solaris, IIRC. Just like it is 2GB on 32-bit linux. Try building everything 64-bit. Another thing to try, from when I ran my servers on Solaris, is to fix the limits in /etc/system for the maximum amount of memory that can be allocated. I vaguely recall having to do this for my Solaris systems. Oh, and with BDB on Solaris, you want to use the "shm_key" flag in slapd.conf to use shared memory segments, when running on SPARC. Here's the last portions of /etc/system on my old Solaris LDAP servers: * turn off executable stacks set noexec_user_stack = 1 set noexec_user_stack_log = 1 * increase the size of the kernel stack to 24k for Solaris 8/64-bit set rpcmod:svc_default_stksize=0x6000 set lwp_default_stksize=0x6000 * force load the shared module kernel information. forceload: sys/shmsys * allow shared memory segments of up to 3 GB (default 1MB) * See http://www.sun.com/sun-on-net/itworld/UIR960101perf.html set shmsys:shminfo_shmmax=3221225472 * Increase memory performance when filesystem is being heavily used. * See http://www.sun.com/sun-on-net/performance/priority_paging.html set priority_paging=1 * Increase memory performance when filesystem is being heavily used. * See http://www.samag.com/documents/s=1323/sam0110e/0110e.htm set maxpgio=25468 set slowscan=500 * autoup influences how much RAM is checked by fsflush every 5 seconds. * Default = 30. Increase autoup to decrease mem management overhead. * See http://docs.sun.com/db/doc/806-7009/6jftnqsin?a=view set autoup = 60 * Up tcp conn hash size. Defaults to 256. * See http://www.deny-all.com/en/solsecu/tech/tuning.html set tcp:tcp_conn_hash_size = 16384 * Up file descriptor limit. Defaults to 1024. set rlim_fd_max = 16384 --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by hyc＠symas.com 08 Oct '06

08 Oct '06

PS: 4GB of RAM is probably not enough for a 20GB database, you won't be able to configure caches large enough to get decent search performance. I think 8GB would be a practical minimum here. Paolo.Rossi.con(a)h3g.it wrote: > Full_Name: Paolo Rossi > Version: 2.3.27 > OS: Solaris 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.149.168.114) > > > Hi, during some test on very huge DB, due to see how syncrepl works in this > scenario, I've found a strange behavior: > > Solaris 8 on 2xUSIII+ 4GB RAM > openLDAP 2.3.27 > BDB 4.2.52.4 > > backend hdb > > 1 provider, 1 consumer, 1 consumer with filter. > > on 1 million dn LDAP whit 2 sub-dn for each dn, all the systems works fine, > when I've tried to use a 10m dn with 3 sub-dn (very big ldap, openldap-data dir > about 20GB): -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4702) out-of-memory on huge DB ?
by hyc＠symas.com 08 Oct '06

08 Oct '06

No ideas, this problem doesn't occur on my Linux system. We've slapadd'd and slapcat'd databases of over a terabyte in size, with hundreds of millions of entries, and never seen slapcat grow beyond the size of the BDB cache. How large is your cache in DB_CONFIG? Paolo.Rossi.con(a)h3g.it wrote: > Full_Name: Paolo Rossi > Version: 2.3.27 > OS: Solaris 8 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (88.149.168.114) > > > Hi, during some test on very huge DB, due to see how syncrepl works in this > scenario, I've found a strange behavior: > > Solaris 8 on 2xUSIII+ 4GB RAM > openLDAP 2.3.27 > BDB 4.2.52.4 > > backend hdb > > 1 provider, 1 consumer, 1 consumer with filter. > > on 1 million dn LDAP whit 2 sub-dn for each dn, all the systems works fine, > when I've tried to use a 10m dn with 3 sub-dn (very big ldap, openldap-data dir > about 20GB): > > slapadd with -w on producer. it works. > some ldapsearch, it works. > > stop producer, > slapcat the producer to obtain the ldif for consumer preload and... bum > > after about 150 minutes of slapcat, memory full (look the screenshot of top ) > > PID |USERNAME | SIZE |RES |TIME | CPU |COMMAND > 21495 | ldap |4072M |3591M |150:07 | 21.36% |slapd > > memory full, then coredump and a console messages: > > ch_malloc of 16392 bytes failed > ch_malloc.c:57: failed assertion `0' > > the out ldif was about 85% of the full LDAP > > I've tried again with same results. > > > Then I've tried to syncrepl the entire DB, turning on the empty consumers (crazy > idea ;) i know ) but the provider memory allocated, again reached 4GB and... > bum > > core dumped > > in the slapd.log > > ch_calloc of 1 elems of 80 bytes failed > > second try: > ch_malloc of 16 bytes failed > > seems to be a issue like ITS#4010 > > some ideas? > > Regards -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by richton＠nbcs.rutgers.edu 06 Oct '06

06 Oct '06

Rutgers just ran into this earlier today, fix (from RE23 CVS) verified on an x86_64 client, will try on sparc later (likely next week).

1 0

(ITS#4703) mirrormode hole
by hyc＠OpenLDAP.org 06 Oct '06

06 Oct '06

Full_Name: Howard Chu Version: HEAD/re24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.126.120.178) Submitted by: hyc If the current master commits an update but crashes before the change is propagated to the mirror, and then new updates are subsequently committed on the new master, the non-propagated changes will never be picked up, because the new master's context is newer than everything on the crashed master. The hole can be plugged by keeping a per-consumer contextCSN in addition to the overall contextCSN, so that the old state isn't lost. While we're at it, we should add a consumer option for specifying additional locations in which to store contextCSNs. This would e.g. solve ITS#4626 by allowing a consumer in a glued subordinate to keep its parent context up to date.

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ando＠sys-net.it 06 Oct '06

06 Oct '06

> Pierangelo Masarati wrote: > >> I don't see an error in OpenLDAP software here. authz regexp matching >> is >> designed to succeed only if the identity is univoquely resolved to >> exactly one >> DN. I'm afraid but I cannot even imagine how slapd could decide to pick >> one out >> of many DNs when authenticating a user; I guess noone else can. >> >> p. >> > > Matched dn's are unique, as they describing the same Entry: > > dn: uid=works,dc=example,dc=org > objectClass: extensibleObject > uid: works > > dn: cn=worksalso,dc=example,dc=org > objectClass: extensibleObject > cn: worksalso > > dn: uid=fails,dc=example,dc=org > objectClass: extensibleObject > uid: fails > cn: fails > > "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching > either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but > describes the same object. > > ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one > and unique entry "uid=fails,dc=example,dc=org" What authz-regexp does is run an internal search. If the search returns exactly one entry, then there's no way it can be, say, returned twice, otherwise it would also when running aregular search. Moreover, I've recrated you scenario in 2.3.27 and HEAD, and everything seems to work as expected in all cases. I suspect something else is wrong, for example data in your DB is not like it appears. Usually, guessing and expecting is a bad practice when debugging software. Please perform offending operations with full logs on; check that your data is not duplicated (for example, you might not see duplicates because they're hidden by ACLs) and so. Unless you can show a clear malfunction of the software (which I don't see here) I'm inclined towards closing this ITS. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4702) out-of-memory on huge DB ?
by Paolo.Rossi.con＠h3g.it 06 Oct '06

06 Oct '06

Full_Name: Paolo Rossi Version: 2.3.27 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.149.168.114) Hi, during some test on very huge DB, due to see how syncrepl works in this scenario, I've found a strange behavior: Solaris 8 on 2xUSIII+ 4GB RAM openLDAP 2.3.27 BDB 4.2.52.4 backend hdb 1 provider, 1 consumer, 1 consumer with filter. on 1 million dn LDAP whit 2 sub-dn for each dn, all the systems works fine, when I've tried to use a 10m dn with 3 sub-dn (very big ldap, openldap-data dir about 20GB): slapadd with -w on producer. it works. some ldapsearch, it works. stop producer, slapcat the producer to obtain the ldif for consumer preload and... bum after about 150 minutes of slapcat, memory full (look the screenshot of top ) PID |USERNAME | SIZE |RES |TIME | CPU |COMMAND 21495 | ldap |4072M |3591M |150:07 | 21.36% |slapd memory full, then coredump and a console messages: ch_malloc of 16392 bytes failed ch_malloc.c:57: failed assertion `0' the out ldif was about 85% of the full LDAP I've tried again with same results. Then I've tried to syncrepl the entire DB, turning on the empty consumers (crazy idea ;) i know ) but the provider memory allocated, again reached 4GB and... bum core dumped in the slapd.log ch_calloc of 1 elems of 80 bytes failed second try: ch_malloc of 16 bytes failed seems to be a issue like ITS#4010 some ideas? Regards

1 0

Re: (ITS#4701) slapd crash using slapmodrdn
by ando＠sys-net.it 06 Oct '06

06 Oct '06

> slapd crashed with an "assert failure" in lastmod.c line 593 when using > slapmodrn command. Fault is reproducable. Get around is to remove lastmod > overlay from config file. There is no slapmodrdn tool in OpenLDAP suite; I assume you mean ldapmodrdn. In any case, slapo-lastmod(5) is essentially unmaintained and basically useless. I suggest you use slapo-accesslog(5) instead. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4701) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

Full_Name: Andrew Neil Parker Version: 2.3.27 OS: RHEL 3.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) slapd crashed with an "assert failure" in lastmod.c line 593 when using slapmodrn command. Fault is reproducable. Get around is to remove lastmod overlay from config file. Trace output using -d 1 is provided on ftp site. 150 Opening BINARY mode data connection for 'andy.n.parker-061006.ext'. 226 Transfer complete (unique file name:andy.n.parker-061006.ext). 3036 bytes sent in 0.00025 seconds (1.2e+04 Kbytes/s)

1 0

(ITS#4700) slapd crash using slapmodrdn
by andy.n.parker＠unilever.com 06 Oct '06

06 Oct '06

Full_Name: Andrew Neil Parker Version: 2.3.27 OS: RHEL 3.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.60.106.5) slapd crashed with an "assert failure" in lastmod.c line 593 when using slapmodrn command. Fault is reproducable. Get around is to remove lastmod overlay from config file. Trace output using -d 1 is provided

1 0

Re: (ITS#4699) snacc-2.3.3beta doesn't compile
by Kurt＠OpenLDAP.org 05 Oct '06

05 Oct '06

I suggest that anyone wanting to toy with LDAP component matching in OpenLDAP Software use HEAD... the feature needs work. At 02:18 PM 10/5/2006, dieter(a)dkluenter.de wrote: >Full_Name: Dieter Kluenter >Version: openldap-snacc-2.3.3beta Not sure why you didn't try 2.3.6, but regardless, see above. Kurt

1 0

(ITS#4699) snacc-2.3.3beta doesn't compile
by dieter＠dkluenter.de 05 Oct '06

05 Oct '06

Full_Name: Dieter Kluenter Version: openldap-snacc-2.3.3beta OS: linux x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.210.55) Hi, This are the errors from my attempt to compile snacc /usr/include/c++/3.3.5/backward/backward_warning.h:32:2: Warnung: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated. vdatest.cpp: In function `void test_timingDoTestPrint(long int, long int, int, long int)': vdatest.cpp:1048: Warnung: int Format, anderer Typ Argument (Argument 4) vdatest.cpp: In function `void AsnIntTest()': vdatest.cpp:1283: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const vdatest.cpp:1335: error: no matching function for call to `SNACC::AsnInt:: getPadded(unsigned char*&, unsigned int&, int)' ../../c++-lib/inc/asn-incl.h:645: error: candidates are: void SNACC::AsnInt::getPadded(unsigned char*&, size_t&, long unsigned int) const make[3]: *** [vdatest.o] Fehler 1 make[3]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples/src' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/work/openldap-snacc-2.3.3beta/c++-examples' make: *** [all] Fehler 2 -Dieter

1 0

Re: authz-regexp matches twice on same dse (ITS#4698)
by ap＠d-dt.de 05 Oct '06

05 Oct '06

Pierangelo Masarati wrote: > I don't see an error in OpenLDAP software here. authz regexp matching is > designed to succeed only if the identity is univoquely resolved to exactly one > DN. I'm afraid but I cannot even imagine how slapd could decide to pick one out > of many DNs when authenticating a user; I guess noone else can. > > p. > Matched dn's are unique, as they describing the same Entry: dn: uid=works,dc=example,dc=org objectClass: extensibleObject uid: works dn: cn=worksalso,dc=example,dc=org objectClass: extensibleObject cn: worksalso dn: uid=fails,dc=example,dc=org objectClass: extensibleObject uid: fails cn: fails "(|(cn=works)(uid=works))" and "(|(cn=worksalso)(uid=worksalso))" matching either attribute, whereas "(|(cn=works)(uid=works))" matches twice, but describes the same object. ldapsearching for "(|(cn=fails)(uid=fails))" will also return only the one and unique entry "uid=fails,dc=example,dc=org" A --

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 05 Oct '06

05 Oct '06

Howard Chu wrote: > tim(a)dcs.qmul.ac.uk wrote: >> Full_Name: Tim Kay >> Version: OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The >> provider "sends" a valid modify but the consumer, having received the >> modify >> request walks the tree, returns the parent DN to the entry, >> determines that >> write access is permitted and the iterates, at this point >> newSuperior->bv_val is >> set to "*" !? bdb_dn2entry is now searching for "�UUU" which >> looks like >> some unicode screw up. > > Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 > That appears to have nailed it. Thank you very much and bug closed I think. Seven hours between bug report and patch release is something to shout from the rooftops too. Best, Tim -- Tim Kay Systems Programmer Department of Computer Science Queen Mary, University of London. Tel: +44 (0) 207 882 7521 Fax: +44 (0) 208 980 6533

1 0

(ITS#4698) authz-regexp matches twice on same dse
by adampordzik＠gmx.de 05 Oct '06

05 Oct '06

Full_Name: Adam pordzik Version: 2.3.27 OS: FreeBSD 5-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.171.35.164) authz-regexp uid=([^,]+),cn=[^,]+,cn=auth ldap:///dc=example,dc=org??sub?(|(cn=$1)(uid=$1)) Below dc=example,dc=org there is a DSE with same value for uid and cn, which I can't bind to with SASL. Since Authentication against this entry works after its cn-attributes rename (or deletition of same-valued cn) works, as also agianst other found entries, I assueme this is due to twice matching the same entry.

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by hyc＠symas.com 05 Oct '06

05 Oct '06

tim(a)dcs.qmul.ac.uk wrote: > Full_Name: Tim Kay > Version: > OS: Linux (Fedora core 5 RPM) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.95.144) > > > Modifying a DN on the syncrepl provider fails to propogate to the consumer. The > provider "sends" a valid modify but the consumer, having received the modify > request walks the tree, returns the parent DN to the entry, determines that > write access is permitted and the iterates, at this point newSuperior->bv_val is > set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like > some unicode screw up. Try the patch in CVS slapd/syncrepl.c 1.272 -> 1.273 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 05 Oct '06

05 Oct '06

--On Wednesday, October 04, 2006 8:21 PM +0000 quanah(a)stanford.edu wrote: The acl bits of "a" show: (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) print *a $1 = {acl_filter = 0x0, acl_dn_style = ACL_STYLE_CHILDREN, acl_dn_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_dn_pat = {bv_len = 18, bv_val = 0x2b9d6e54e900 "dc=stanford,dc=edu"}, acl_attrs = 0x2b9d6e4c0080, acl_attrval_mr = 0x0, acl_attrval_style = ACL_STYLE_REGEX, acl_attrval_re = {buffer = 0x0, allocated = 0, used = 0, syntax = 0, fastmap = 0x0, translate = 0x0, re_nsub = 0, can_be_null = 0, regs_allocated = 0, fastmap_accurate = 0, no_sub = 0, not_bol = 0, not_eol = 0, newline_anchor = 0}, acl_attrval = {bv_len = 0, bv_val = 0x0}, acl_access = 0x2b9d6e969ae0, acl_next = 0x2b9d6e9455c0} It seems we should have never gotten to this section of the code: (gdb) l 855 /* Is this ACL only for a specific value? */ 856 if ( a->acl_attrval.bv_len ) { 857 if ( val == NULL ) { 858 continue; 859 } 860 861 if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) { 862 state->as_recorded |= ACL_STATE_RECORDED_VD; 863 state->as_vd_acl = a; 864 state->as_vd_acl_count = *count; 865 state->as_vd_access = a->acl_access; 866 state->as_vd_access_count = 1; 867 ACL_INVALIDATE( state->as_vd_acl_mask ); 868 } 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) Since a->acl_attrval.bv_len is 0. At the moment, Howard and I blame the compiler (gcc 3.4) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 04 Oct '06

04 Oct '06

Quanah Gibson-Mount wrote: > > > --On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote: > >> Full_Name: Tim Kay >> Version: >> OS: Linux (Fedora core 5 RPM) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (138.37.95.144) >> >> >> Modifying a DN on the syncrepl provider fails to propogate to the >> consumer. The provider "sends" a valid modify but the consumer, having >> received the modify request walks the tree, returns the parent DN to the >> entry, determines that write access is permitted and the iterates, at >> this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now >> searching for "�UUU" which looks like some unicode screw up. > > You didn't provide an OpenLDAP version. I'll note that if you intend to > use syncrepl, use OpenLDAP 2.3.27 (or later). > > --Quanah > Sorry Quanah (and everyone else), The identical problem is happening in both 2.3.27 and 2.3.19 with both the bdb and ldbm back ends. Tim > > -- > Quanah Gibson-Mount > Principal Software Developer > ITS/Shared Application Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4697) core dump from acl.c regex
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core happened today on one of my replicas: Core was generated by `/usr/local/lib/slapd -h ldap:///'. Program terminated with signal 11, Segmentation fault. (gdb) info threads 10 process 28453 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 9 process 28455 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 8 process 28456 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 28457 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 28458 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 28459 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 28462 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 28463 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 28464 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 28461 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) thread 10 [Switching to thread 10 (process 28453)]#0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da82e2c in pthread_join () from /lib/libpthread.so.0 #1 0x0000000000425d41 in slapd_daemon () at daemon.c:2261 #2 0x0000000000416254 in main (argc=3, argv=0x7fffffd3c4c8) at main.c:854 (gdb) thread 9 [Switching to thread 9 (process 28455)]#0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc62b2c in epoll_wait () from /lib/libc.so.6 #1 0x0000000000425389 in slapd_daemon_task (ptr=0x6) at daemon.c:1859 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 8 [Switching to thread 8 (process 28456)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 7 [Switching to thread 7 (process 28457)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 6 [Switching to thread 6 (process 28458)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 5 [Switching to thread 5 (process 28459)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 4 [Switching to thread 4 (process 28462)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 (gdb) thread 3 [Switching to thread 3 (process 28463)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 2 [Switching to thread 2 (process 28464)]#0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 (gdb) bt #0 0x00002b9d6da844e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00002b9d6d03f5ae in ldap_int_thread_pool_wrapper (xpool=0x2b9d6e9400c0) at tpool.c:490 #2 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #3 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 #4 0x00002b9d6dc627f0 in clone () from /lib/libc.so.6 (gdb) thread 1 [Switching to thread 1 (process 28461)]#0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 (gdb) bt #0 0x00002b9d6dc427dd in fnmatch () from /lib/libc.so.6 #1 0x00002b9d6dc4dd22 in re_exec () from /lib/libc.so.6 #2 0x00002b9d6dc4b70b in re_exec () from /lib/libc.so.6 #3 0x00002b9d6dc49d83 in re_exec () from /lib/libc.so.6 #4 0x00002b9d6dc48526 in re_exec () from /lib/libc.so.6 #5 0x00002b9d6dc47e83 in re_exec () from /lib/libc.so.6 #6 0x00002b9d6dc474a6 in regexec () from /lib/libc.so.6 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 #8 0x0000000000448521 in fe_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:318 #9 0x0000000000443df3 in access_allowed_mask (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x0) at acl.c:429 #10 0x0000000000436e1b in slap_send_search_entry (op=0x2aaaafd40080, rs=0x42ffeeb0) at result.c:894 #11 0x00002b9d6f7342dc in hdb_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:878 #12 0x000000000042a30a in fe_op_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:355 #13 0x0000000000429c45 in do_search (op=0x2aaaafd40080, rs=0x42ffeeb0) at search.c:217 #14 0x000000000042837d in connection_operation (ctx=0x42fff020, arg_v=0x2aaaafd40080) at connection.c:1100 #15 0x0000000000428a33 in connection_read_thread (ctx=0x42fff020, argv=0x0) at connection.c:1227 #16 0x00002b9d6d03f522 in ldap_int_thread_pool_wrapper (xpool=0x1) at tpool.c:478 #17 0x00002b9d6cd50c93 in startMeUp () from /usr/local/lib/libhoard.so #18 0x00002b9d6da81b55 in start_thread () from /lib/libpthread.so.0 Given that all threads except thread 1 appear to be in the same spot, I'm guessing the problem is in thread 1. Code is: (gdb) frame 7 #7 0x0000000000446058 in slap_access_allowed (op=0x2aaaafd40080, e=0x2b9e6fde1f78, desc=0x2b9d6e563d50, val=0x2aaab4e07580, access=ACL_READ, state=0x42e7d4e0, maskp=0x42e7d408) at acl.c:874 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) (gdb) l 869 870 if ( a->acl_attrval_style == ACL_STYLE_REGEX ) { 871 Debug( LDAP_DEBUG_ACL, 872 "acl_get: valpat %s\n", 873 a->acl_attrval.bv_val, 0, 0 ); 874 if ( regexec( &a->acl_attrval_re, val->bv_val, 0, NULL, 0 ) ) 875 { 876 continue; 877 } 878 --Quanah

1 0

(ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.27/HEAD OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) The following core occurred on one of my replica systems today: (gdb) info threads 10 process 22650 0x00002b41c03a1e2c in pthread_join () from /lib/libpthread.so.0 9 process 22652 0x00002b41c0581b2c in epoll_wait () from /lib/libc.so.6 8 process 22653 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 22654 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 22655 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 5 process 22663 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 4 process 22706 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 22707 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 2 process 22708 0x00002b41c03a34e4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 1 process 22705 0x00002b41c04de545 in raise () from /lib/libc.so.6 In particular: [Switching to thread 1 (process 22705)]#3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) bt #0 0x00002b41c04de545 in raise () from /lib/libc.so.6 #1 0x00002b41c04dfcce in abort () from /lib/libc.so.6 #2 0x00002b41c04d8362 in __assert_fail () from /lib/libc.so.6 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 #4 0x0000000000428a6c in connection_read_thread (ctx=0x42fff020, argv=0x68) at connection.c:1391 #5 0x00002b41bf95e522 in ldap_int_thread_pool_wrapper (xpool=0x587a) at tpool.c:478 #6 0x00002b41bf66fc93 in startMeUp () from /usr/local/lib/libhoard.so #7 0x00002b41c03a0b55 in start_thread () from /lib/libpthread.so.0 #8 0x00002b41c05817f0 in clone () from /lib/libc.so.6 (gdb) frame 3 #3 0x00000000004271c5 in connection_close (c=0x2b42c5088358) at connection.c:655 655 assert( c->c_writewaiter == 0); (gdb) l 650 assert( connections != NULL ); 651 assert( c != NULL ); 652 assert( c->c_struct_state != SLAP_C_UNUSED ); 653 assert( c->c_conn_state != SLAP_C_INVALID ); 654 assert( LDAP_STAILQ_EMPTY(&c->c_ops) ); 655 assert( c->c_writewaiter == 0); 656 657 /* only for stats (print -1 as "%lu" may give unexpected results ;) */ 658 connid = c->c_connid; 659 close_reason = c->c_close_reason; --Quanah

1 0

Re: (ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by quanah＠stanford.edu 04 Oct '06

04 Oct '06

--On Wednesday, October 04, 2006 6:06 PM +0000 tim(a)dcs.qmul.ac.uk wrote: > Full_Name: Tim Kay > Version: > OS: Linux (Fedora core 5 RPM) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.95.144) > > > Modifying a DN on the syncrepl provider fails to propogate to the > consumer. The provider "sends" a valid modify but the consumer, having > received the modify request walks the tree, returns the parent DN to the > entry, determines that write access is permitted and the iterates, at > this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now > searching for "�UUU" which looks like some unicode screw up. You didn't provide an OpenLDAP version. I'll note that if you intend to use syncrepl, use OpenLDAP 2.3.27 (or later). --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4695) syncrepl modrdn failing with garbage returned by bdb_dn2entry
by tim＠dcs.qmul.ac.uk 04 Oct '06

04 Oct '06

Full_Name: Tim Kay Version: OS: Linux (Fedora core 5 RPM) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (138.37.95.144) Modifying a DN on the syncrepl provider fails to propogate to the consumer. The provider "sends" a valid modify but the consumer, having received the modify request walks the tree, returns the parent DN to the entry, determines that write access is permitted and the iterates, at this point newSuperior->bv_val is set to "*" !? bdb_dn2entry is now searching for "�UUU" which looks like some unicode screw up. Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_search (0) Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: ==>bdb_modrdn(cn=laptT2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,cn=laptT5,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk,*) Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("cn=laptt2,ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk") Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: wr to children of entry ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk OK Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: parent dn=ou=auto.import,dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: new parent "*" requested... Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("�UUU") Oct 4 17:38:37 auth1 slapd[2975]: => bdb_dn2id("") Oct 4 17:38:37 auth1 slapd[2975]: <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30989) Oct 4 17:38:37 auth1 slapd[2975]: bdb_modrdn: newSup(ndn=�UUU) not here! Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=32 matched="" text="new superior not found" Oct 4 17:38:37 auth1 slapd[2975]: syncrepl_entry: be_modrdn (32) Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_dn2entry("dc=dcs,dc=qmul,dc=ac,dc=uk") Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: 0x00000001: dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify_internal: replace contextCSN Oct 4 17:38:37 auth1 slapd[2975]: => entry_encode(0x00000001): dc=dcs,dc=qmul,dc=ac,dc=uk Oct 4 17:38:37 auth1 slapd[2975]: bdb_modify: updated id=00000001 dn="dc=dcs,dc=qmul,dc=ac,dc=uk" Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: conn=-1 op=0 p=0 Oct 4 17:38:37 auth1 slapd[2975]: send_ldap_result: err=0 matched="" text=""

1 0

Re: (ITS#4691) syncrepl in refreshOnly dies when bind to provider fails
by bgmilne＠staff.telkomsa.net 04 Oct '06

04 Oct '06

--nextPart1470088.V9xMQ7mU2U Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 02 October 2006 17:37, Howard Chu wrote: > I don't see any indication of an OpenLDAP software bug here. > Use the "retry" parameter if your connections are unreliable. Since slapd.conf(5) isn't explicit on whether retry is valid for refreshOnl= y=20 (I'll submit a patch for the documentation later), I had initially not set= =20 retry when switching from refreshAndPersist, and when setting it subsequent= ly=20 I had only added it back on one of the four databases. I have subsequently set retry on all the databases, such that the syncrepl= =20 configuration now looks as follows: syncrepl rid=3D124 provider=3Dldaps://<master hostname> retry=3D"60 10 300 10 600 +" type=3DrefreshOnly interval=3D"00:00:01:00" searchbase=3D"<suffix>" scope=3Dsub attrs=3D"*" schemachecking=3Doff bindmethod=3Dsimple binddn=3D"<dn for consumer>" credentials=3D"<password for consumer>" However, since restarting the consumer with this config, replication has=20 stopped again: Oct 4 09:39:43 leda slapd2.3[28811]: syncrepl_entry: uid=3Dmail10015 Oct 4 09:39:44 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:39:44 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 09:39:58 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_INTERMEDIATE -= =20 SYNC_ID_SET Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dtelkomdsl9953 Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dtelkomsa122193 Oct 4 09:39:59 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dintekom37262 Oct 4 09:40:00 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dsusanna Oct 4 09:40:01 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline139514 Oct 4 09:40:01 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline546691 Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline193813 Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dsusannas Oct 4 09:40:02 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline457755 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline27380 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dti3345 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Dtelkomsa232906 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline555146 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline555146 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline566281 Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:03 leda slapd2.3[28811]: syncrepl_entry: uid=3Dti3345 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline546691 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline193813 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dsusannas Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dtelkomdsl9953 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dintekom37262 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Dtelkomsa122193 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry:=20 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_search (0) Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: uid=3Donline27899 Oct 4 09:40:04 leda slapd2.3[28811]: syncrepl_entry: be_add (0) Oct 4 09:40:04 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 09:40:07 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 09:43:47 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed= =20 (-1) Oct 4 09:43:53 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed= =20 (-1) Oct 4 09:44:13 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed (-1) More bind failures occurred until: Oct 4 10:38:54 leda slapd2.3[28811]: do_syncrep1: ldap_sasl_bind_s failed= =20 (-1) after which there was only: Oct 4 10:40:15 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 10:40:46 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 10:41:15 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT [...] Oct 4 17:24:14 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 17:24:46 leda slapd2.3[28811]: do_syncrep2: LDAP_RES_SEARCH_RESULT After a restart: Oct 4 17:25:54 leda slapd2.3[28811]: daemon: shutdown requested and=20 initiated. Oct 4 17:26:26 leda slapd2.3[30580]: slapd starting Oct 4 17:26:26 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 17:26:26 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 4 17:26:28 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_INTERMEDIATE -= =20 SYNC_ID_SET Oct 4 17:26:29 leda slapd2.3[30580]: do_syncrep2: LDAP_RES_INTERMEDIATE -= =20 SYNC_ID_SET Oct 4 17:26:45 leda slapd2.3[30580]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline185588 Oct 4 17:26:46 leda slapd2.3[30580]: syncrepl_del_nonpresent: be_delete=20 uid=3Donline193883 (In these log extracts, the DN's have been truncated for privacy reasons) This doesn't occur on any of the slaves in our production site, but I will = see=20 if I can reproduce it via other means. Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart1470088.V9xMQ7mU2U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFI9borJK6UGDSBKcRAvE/AJ44a1QsX/zY66CpkGzJkbfeFHm/kwCdHUyl /uTp0anElaKJZ21EXkeaGO0= =q/t2 -----END PGP SIGNATURE----- --nextPart1470088.V9xMQ7mU2U--

1 0

(ITS#4694) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net 04 Oct '06

04 Oct '06

Full_Name: Buchan Milne Version: 2.3.27 OS: Linux 2.4 (RHEL 3) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) One of our replicas sits on the other side of a relatively congested WAN link (with multiple firewalls in between, which I have no control over). Since switching to syncrepl, it has been difficult to achieve a configuration that supports replication reliably to any extent. Using syncrepl consumer configuration with: syncrepl rid=124 provider=ldaps://<master hostname> type=refreshOnly interval="00:00:01:00" searchbase="<suffix>" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="<dn for consumer>" credentials="<password for consumer>" I see replication dies frequently, it seems to occur when (for whatever reason) the consumer fails to bind: ct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: uid=lere1 Oct 2 12:03:37 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:03:43 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=deleted/telkomsa133309,ou=radius,o=intekom,c=za (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online564666 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa220585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=mail109585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa196118 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online313812 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=online536857 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa233527 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564379 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=ihatechromium Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online18609 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=telkomdsl56797 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=hotkaj Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=magda22 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:06:27 leda slapd2.3[1332]: do_syncrep1: ldap_sasl_bind_s failed (-1)

1 0

Re: (ITS#4692) ppolicy.c module doesn't respect Draft policy
by hyc＠symas.com 04 Oct '06

04 Oct '06

alexandrelabiche(a)yahoo.com wrote: > Full_Name: Alexandre LABICHE > Version: 2.3.27 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.120.54.227) > > > Hello, > > draft-behera-ldap-password-policy-xx.txt says: > > > 5.3.2 pwdChangedTime > > This attribute specifies the last time the entry's password was > changed. This is used by the password expiration policy. If this > attribute does not exist, the password will never expire. > > > > And ppolicy.c overlay says contrary This is now fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by Kurt＠OpenLDAP.org 04 Oct '06

04 Oct '06

At 11:25 AM 10/3/2006, quanah(a)stanford.edu wrote: >Full_Name: Quanah Gibson-Mount >Version: All >OS: NA >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (171.66.155.86) Nothing in this message should be construed or represented as as legal advice to any party. Recent versions of this file (and numerous other files comprising OpenLDAP Software) have contained material copied (with or without modification) from various ISOC-published documents, namely RFCs and I-Ds. It is the OpenLDAP Foundation current policy and practice to include notices from the source documents even where OpenLDAP Foundation believe the nature of our copying is not subject to any license. The inclusion of this notice in recent revisions of this file (including both 1.88 and 1.89) is consistent with the current policy and practice and, hence, is not to be removed. This report should be closed as no further action is required or appropriate. Regards, Kurt (as Executive Director of the OpenLDAP Foundation)

1 0

Re: (ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu 03 Oct '06

03 Oct '06

--On Tuesday, October 03, 2006 6:25 PM +0000 openldap-its(a)OpenLDAP.org wrote: Follow-on note: note that a literal reading of the current license would say that you're not allowed to modify the schema on your local system unless you write a completely new schema from scratch without referring to that one. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4693) Unnecessary licensing statement in core.schema?
by quanah＠stanford.edu 03 Oct '06

03 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The core.schema file has the following included in it: ## Portions Copyright (C) The Internet Society (1997-2003). ## All Rights Reserved. ## ## This document and translations of it may be copied and furnished to ## others, and derivative works that comment on or otherwise explain it ## or assist in its implementation may be prepared, copied, published ## and distributed, in whole or in part, without restriction of any ## kind, provided that the above copyright notice and this paragraph are ## included on all such copies and derivative works. However, this ## document itself may not be modified in any way, such as by removing ## the copyright notice or references to the Internet Society or other ## Internet organizations, except as needed for the purpose of ## developing Internet standards in which case the procedures for ## copyrights defined in the Internet Standards process must be ## followed, or as required to translate it into languages other than ## English. ## ## The limited permissions granted above are perpetual and will not be ## revoked by the Internet Society or its successors or assigns. ## ## This document and the information contained herein is provided on an ## "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING ## TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ## BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION ## HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF ## MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. This is causing some unhappiness from the Debian folks, but their final conclusion is that core.schema is not copyrightable under US law: [snip email 1] > Doesn't the copyright in question apply to the RFC only? AFAICS, > core.schema basically reads: > 1. Part of OpenLDAP, with the following license: > 2. OpenLDAP license (see license.html) > 3. Based on an RFC, with the following license: > 4. RFC license > 5. Specific RFC attributions > 6. The schema itself [snip email 2] > Plus, this is an interface specification if I've ever seen one, and > interface specifications are not copyrightable under US law. [snip email 3] > If this file is a non-copyrightable interface definition, the bug here is > the presence of a copyright notice and license statement where there should > be none. If these are correct, then shouldn't this license actually be removed from core.schema? --Quanah

1 0

(ITS#4692) ppolicy.c module doesn't respect Draft policy
by alexandrelabiche＠yahoo.com 03 Oct '06

03 Oct '06

Full_Name: Alexandre LABICHE Version: 2.3.27 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.120.54.227) Hello, draft-behera-ldap-password-policy-xx.txt says: 5.3.2 pwdChangedTime This attribute specifies the last time the entry's password was changed. This is used by the password expiration policy. If this attribute does not exist, the password will never expire. And ppolicy.c overlay says contrary /* * Hmm. No password changed time on the * entry. This is odd - it should have * been provided when the attribute was added. * * However, it's possible that it could be * missing if the DIT was established via * an import process. */ Debug( LDAP_DEBUG_ANY, "ppolicy_bind: Entry %s does not have valid pwdChangedTime attribute - assuming password expired\n", e->e_name.bv_val, 0, 0); pwExpired = 1; Regards. Alexandre LABICHE

1 0

Re: (ITS#4691) syncrepl in refreshOnly dies when bind to provider fails
by hyc＠symas.com 02 Oct '06

02 Oct '06

I don't see any indication of an OpenLDAP software bug here. Use the "retry" parameter if your connections are unreliable. bgmilne(a)staff.telkomsa.net wrote: > Full_Name: Buchan Milne > Version: 2.3.27 > OS: Linux 2.4 (RHEL 3) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (196.15.129.131) > > > One of our replicas sits on the other side of a relatively congested WAN link > (with multiple firewalls in between, which I have no control over). > > Since switching to syncrepl, it has been difficult to achieve a configuration > that supports replication reliably to any extent. > > Using syncrepl consumer configuration with: > > syncrepl rid=124 > provider=ldaps://<master hostname> > type=refreshOnly > interval="00:00:01:00" > searchbase="<suffix>" > scope=sub > attrs="*" > schemachecking=off > bindmethod=simple > binddn="<dn for consumer>" > credentials="<password for consumer>" > > I see replication dies frequently, it seems to occur when (for whatever reason) > the consumer fails to bind: -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4691) syncrepl in refreshOnly dies when bind to provider gails
by bgmilne＠staff.telkomsa.net 02 Oct '06

02 Oct '06

Full_Name: Buchan Milne Version: 2.3.27 OS: Linux 2.4 (RHEL 3) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (196.15.129.131) One of our replicas sits on the other side of a relatively congested WAN link (with multiple firewalls in between, which I have no control over). Since switching to syncrepl, it has been difficult to achieve a configuration that supports replication reliably to any extent. Using syncrepl consumer configuration with: syncrepl rid=124 provider=ldaps://<master hostname> type=refreshOnly interval="00:00:01:00" searchbase="<suffix>" scope=sub attrs="*" schemachecking=off bindmethod=simple binddn="<dn for consumer>" credentials="<password for consumer>" I see replication dies frequently, it seems to occur when (for whatever reason) the consumer fails to bind: ct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:36 leda slapd2.3[1332]: syncrepl_entry: uid=lere1 Oct 2 12:03:37 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:03:43 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=deleted/telkomsa133309,ou=radius,o=intekom,c=za (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online517446 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa158118 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: uid=online564666 Oct 2 12:03:46 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:03:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:37 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=telkomsa220585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=mail109585 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa196118 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online313812 Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:38 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=online536857 Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:39 leda slapd2.3[1332]: syncrepl_entry: uid=telkomsa233527 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564379 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: uid=ihatechromium Oct 2 12:04:40 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:04:46 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online519355 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online556601 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: uid=online564667 Oct 2 12:04:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:04:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:25 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:40 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online18609 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=online188476 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=telkomdsl56797 Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:40 leda slapd2.3[1332]: syncrepl_entry: uid=mail140571 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_modify (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=hotkaj Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: uid=magda22 Oct 2 12:05:41 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:41 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_INTERMEDIATE - SYNC_ID_SET Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_del_nonpresent: be_delete uid=online534772 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_search (0) Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: uid=online561383 Oct 2 12:05:47 leda slapd2.3[1332]: syncrepl_entry: be_add (0) Oct 2 12:05:47 leda slapd2.3[1332]: do_syncrep2: LDAP_RES_SEARCH_RESULT Oct 2 12:06:27 leda slapd2.3[1332]: do_syncrep1: ldap_sasl_bind_s failed (-1)

1 0

Re: (ITS#4690) segfault in ldap_count_values() with PHP
by Kurt＠OpenLDAP.org 02 Oct '06

02 Oct '06

At 06:12 PM 10/1/2006, ando(a)sys-net.it wrote: >madcoder(a)gmail.com wrote: >... >You know, what makes me mad about PHP is that it internally uses >something comparable to bervals, since the abstract type they use to >wrap strings takes care of the length of the string itself; but in the >LDAP extension, ldap_get_values() is used everywhere, and then strlen is >run to compute the length of the values! Why on earth don't they get >ldap_get_values_len() should be used instead? Somehow it got hardwired >in people's brain that ldap_get_values_len() is only good for "binary" >(that is, non-printable) stuff, and not for strings as well! Folks also tend to forget that U+0000 is a valid Unicode character, as is ASCII 0... but I digress. Kurt

1 0

Re: (ITS#4690) segfault in ldap_count_values() with PHP
by ando＠sys-net.it 02 Oct '06

02 Oct '06

madcoder(a)gmail.com wrote: ... You know, what makes me mad about PHP is that it internally uses something comparable to bervals, since the abstract type they use to wrap strings takes care of the length of the string itself; but in the LDAP extension, ldap_get_values() is used everywhere, and then strlen is run to compute the length of the values! Why on earth don't they get ldap_get_values_len() should be used instead? Somehow it got hardwired in people's brain that ldap_get_values_len() is only good for "binary" (that is, non-printable) stuff, and not for strings as well! p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4690) segfault in ldap_count_values() with PHP
by ando＠sys-net.it 02 Oct '06

02 Oct '06

madcoder(a)gmail.com wrote: > What more can I do to debug this problem? > Well, I've posted a bug to PHP about their using deprecated LDAP code, but it was basically bounced with "mind your own business" or sort of (and this __IS__ my own business, by the way :). You could try rebuilding PHP's LDAP stuff defining -DLDAP_DEPRECATED=1 and see what happens. I've seen similar problems with AMD64 when functions got linked without a prototype, and ldap_get_values does not have a prototype in ldap.h unless the above is defined. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4690) segfault in ldap_count_values() with PHP
by madcoder＠gmail.com 01 Oct '06

01 Oct '06

Full_Name: Joe H Version: 2.3.24 OS: gentoo linux (2.6.17) on amd64 Athlon X2 URL: http://bugs.php.net/bug.php?id=38819 Submission from: (NULL) (70.245.125.224) I'm not certain yet whether this is a bug in openldap, or in PHP, but my bug report with PHP has stalled, so I am hoping that cross-posting it here might garnish some further insight into the problem. The PHP bug report should explain the segfault I'm experiencing, and where the segfault occurs. It can be found at http://bugs.php.net/bug.php?id=38819 The segfault occurs in libraries/libldap/getvalues.c, in the ldap_count_values() function. The value for vals that is passed to the function cannot be read for some reason. At first I thought this might be a PHP problem, since the ldapsearch utility works fine performing the same search. However, it should also be mentioned that the value that is sent to ldap_get_values, is a value returned directly from ldap_get_values(): > ldap_value = ldap_get_values(ldap, ldap_result_entry, attribute); > num_values = ldap_count_values(ldap_value); While in ldap_count_values(), the backtrace shows that the segfault occurs during the first iteration of the for() loop: > Program received signal SIGSEGV, Segmentation fault. > 0x00002b2871ad210b in ldap_count_values (vals=0x55a170c0) at getvalues.c:152 > 152 for ( i = 0; vals[i] != NULL; i++ ) Further investigating the problem shows: > (gdb) p i > $1 = 0 > (gdb) p vals > $2 = (char **) 0x55a170c0 > (gdb) p vals[0] > Cannot access memory at address 0x55a170c0 The memory address changes obviously, but the segfault always occurs at that point. In PHP's ldap_get_entries() function, ldap_values is defined as: > char **ldap_value; which is the data type expected by ldap_count_entries(). Fetching the entry reference itself, or counting the number of entries, does not cause the segfault -- only when getting values from the entry. For example, PHP's ldap_first_entry($result) works fine (as well as iterating over the entries using ldap_next_entry()), but trying to read any of the values within the entry will cause the segfault. Again, the fact that it works fine with ldapsearch, but segfaults in PHP, lead me to believe that it would be a PHP problem, but looking more into the source code of both applications makes me lean more and more to some obscure problem in OpenLDAP's code. The value of 'vals' is declared and returned from this function: > char ** > ldap_get_values( LDAP *ld, LDAPMessage *entry, LDAP_CONST char *target ) > { >>... > char **vals; >>... > if ( (res = ber_scanf( &ber, "[v]", &vals )) == LBER_ERROR ) { > ld->ld_errno = LDAP_DECODING_ERROR; > return( NULL ); > } > return( vals ); The return value of ber_scanf is 4, but I haven't investigated what that value indicates (it is obviously not LBER_ERROR). In any case, that value of 'vals' is allocated inside OpenLDAP's code, and that makes me believe that it is not a problem with PHP's code. The same test script functions properly on a similar 32-bit system (as similar as 32- and 64-bit systems can be). What more can I do to debug this problem?

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs