openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by quanah＠zimbra.com 13 Oct '10

13 Oct '10

--On Wednesday, October 13, 2010 10:11 AM +0000 donal.duane(a)ericsson.com wrote: > Full_Name: Donal Duane > Version: 2.4.16 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (95.45.199.134) The current stable release is 2.4.23. Please use the current release. You also should note the size of your database, BDB version (and whether or not it is up to date on patches), and the relevant configuration bits for the database configuration. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6674) OpenLDAP 2.4.16 has very high CPU load on Solaris 10, x86
by donal.duane＠ericsson.com 13 Oct '10

13 Oct '10

Full_Name: Donal Duane Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.45.199.134) Hi, I would like to know if this is a known issue, and if so, if a fix has been issued. We have only recently started using OpenLDAP 2.4.16 on Solaris 10, x86 HW. (Because of this, we have no previous benchmark for CPU usage for OpenDLAP for comparison - we also have sparc systems, but have not stress tested OpenLDAP on sparc yet). We have noticed that the slapd process is using a huge amount of CPU. There are massive CPU time spikes obvious over a period of time which we monitored, reaching 520 CPU seconds and even 700 CPU seconds at one stage. there are also some completely flat periods. The activities seem to be purely LDAP searches. Processor info: # psrinfo -pv The physical processor has 4 virtual processors (0 4 8 12) x86 (chipid 0x0 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (1 5 9 13) x86 (chipid 0x1 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (2 6 10 14) x86 (chipid 0x2 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz The physical processor has 4 virtual processors (3 7 11 15) x86 (chipid 0x3 GenuineIntel family 6 model 29 step 1 clock 2400 MHz) Intel(r) Xeon(r) CPU E7440 @ 2.40GHz # isainfo -b 64 => (64 bit) # uname -a SunOS atrcxb1226 5.10 Generic_142901-13 i86pc i386 i86pc Any help appreciated. Regards, Dónal

1 0

Re: (ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by hyc＠symas.com 13 Oct '10

13 Oct '10

arthur(a)arthurdejong.org wrote: > Full_Name: Arthur de Jong > Version: 2.4.23 > OS: Debian/unstable > URL: > Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) > > > When a network connection to the LDAP server fails (is severed with iptables in > my set-up) the error is detected properly with ldap_result() > (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are > set), however closing the connection with ldap_unbind() hangs indefinitely on a > read() operation (determined by strace) when using a ldaps:// connection. > > If the connection is opened without TLS ldap_unbind() only writes some data on > the connection and then closes it but with TLS it expects some response back. > Since read() is used this blocks. Looks like this is a GnuTLS issue. Have you duplicated this with OpenSSL? > > This is a backtrace of the thread that was hanging: > > #0 0xb7fe2424 in __kernel_vsyscall () > #1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82 > #2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493 > #3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827 > #4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at > tls_g.c:904 > #5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26 > #6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26 > #7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26 > #8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26 > #9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970 > #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8) > at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383 > #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1, > unbind=1) at request.c:768 > #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0) > at unbind.c:93 > #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at > unbind.c:52 > #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69 > #15 0x0804cfc0 in ?? () > #16 0x0804e750 in ?? () > #17 0x08057a9f in ?? () > #18 0x0804bb8d in ?? () > #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300 > #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 > > > More background information is available at [0]. > > As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the > connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it. > This fixes the problem for me at least but I'm not 100% this has no unwanted > side-effects. > > [0] http://bugs.debian.org/596983 > [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264 > -- -- 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

Local structure mech in servers/slapd/bind.c assigned to op->orb_mech.
by Grafton Kennedy 13 Oct '10

13 Oct '10

The local structure mech in servers/slapd/bind.c is declared in do_bind as struct berval mech = BER_BVNULL; at about line 44. Further in do_bind, around line 201, mech is assigned to op->orb_mech. As a newbie to slapd, I'm concerned about this assignment. Later, slapd cores in an_find and I see that op->orb_mech.bv_len shares the same address as op->o_request.oq_search.rs_attrs: Program received signal SIGSEGV, Segmentation fault. an_find (a=0x6, s=0x814322c) at ad.c:874 874 for ( ; a->an_name.bv_val; a++ ) { (gdb) up #1 0x0807f865 in slap_attr_flags (an=0x6) at result.c:1659 1659 flags |= an_find( an, slap_bv_all_operational_attrs ) (gdb) up #2 0x08080a54 in slap_send_search_entry (op=0x81e74e0, rs=0xbfffa368) at result.c:821 821 rs->sr_attr_flags = slap_attr_flags( rs->sr_attrs ); (gdb) print &op->o_request.oq_bind.rb_mech $97 = (struct berval *) 0x81e751c (gdb) print &op->o_request.oq_bind.rb_mech.bv_len $98 = (ber_len_t *) 0x81e751c (gdb) print &op->o_request.oq_search.rs_attrs $99 = (AttributeName **) 0x81e751c I am using back-shell and slapd cores when my bind shell script outputs blank lines between data lines. If I remove the blank lines slapd doesn't core. But then it dumps the whole input and complains "expected RESULT" which I know isn't right. Thanks, Grafton

2 1

Re: (ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by hyc＠symas.com 12 Oct '10

12 Oct '10

doug.leavitt(a)oracle.com wrote: > Full_Name: Douglas Leavitt > Version: HEAD > OS: OpenSolaris > URL: http://cr.opensolaris.org/~djl/openldap-patch2/ > Submission from: (NULL) (192.18.43.225) > > > This patch is part 2 of 3 of the original ITS #6625 effort. > (aka openldap draft-zeilenga-ldap-c-api-concurrency) > > As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 > distinct patches. > > This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap. > The patch converts almost all > > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_[un]lock(...) > #endif > > sequences to simpler > LDAP_MUTEX_[UN]LOCK macros. > > No behavioral changes are introduced by this patch. It is strictly a > code cleanup patch. Thanks, committed. > > Regression testing (post conversion) performed using both > 32-bit and 64-bit x86 compiles on an OpenSolaris system. > > IPR Notice > > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in the following patch(es) were developed > by Oracle Corporation. Oracle Corporation has not assigned rights and/or > interest in this work to any party. I, Douglas Leavitt am authorized by Oracle > Corporation, my employer, to release this work under the following terms. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6673) ldap_unbind() hangs on unreachable LDAP server when using TLS
by arthur＠arthurdejong.org 12 Oct '10

12 Oct '10

Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian/unstable URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) When a network connection to the LDAP server fails (is severed with iptables in my set-up) the error is detected properly with ldap_result() (LDAP_OPT_TIMELIMIT, LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT options are set), however closing the connection with ldap_unbind() hangs indefinitely on a read() operation (determined by strace) when using a ldaps:// connection. If the connection is opened without TLS ldap_unbind() only writes some data on the connection and then closes it but with TLS it expects some response back. Since read() is used this blocks. This is a backtrace of the thread that was hanging: #0 0xb7fe2424 in __kernel_vsyscall () #1 0xb7f5809b in read () at ../sysdeps/unix/syscall-template.S:82 #2 0xb7e021bb in sb_stream_read (sbiod=0x8064630, buf=0x8083038, len=5) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:493 #3 0xb7e0132a in sb_debug_read (sbiod=0x807e250, buf=0x8083038, len=5) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:827 #4 0xb7fa0d27 in tlsg_recv (ptr=0x806fb50, buf=0x8083038, len=4294966784) at tls_g.c:904 #5 0xb7c65aa2 in ?? () from /usr/lib/libgnutls.so.26 #6 0xb7c65f77 in ?? () from /usr/lib/libgnutls.so.26 #7 0xb7c611e7 in _gnutls_recv_int () from /usr/lib/libgnutls.so.26 #8 0xb7c626b8 in gnutls_bye () from /usr/lib/libgnutls.so.26 #9 0xb7fa0dc4 in tlsg_sb_close (sbiod=0x807e268) at tls_g.c:970 #10 0xb7e01831 in ber_int_sb_close (sb=0x80645a8) at /build/buildd-openldap_2.4.23-6-i386-fyqRGs/openldap-2.4.23/libraries/liblber/sockbuf.c:383 #11 0xb7f8d1a0 in ldap_free_connection (ld=0x8066418, lc=0x8065b60, force=1, unbind=1) at request.c:768 #12 0xb7f83060 in ldap_ld_free (ld=0x8066418, close=1, sctrls=0x0, cctrls=0x0) at unbind.c:93 #13 0xb7f83326 in ldap_unbind_ext (ld=0x8066418, sctrls=0x0, cctrls=0x0) at unbind.c:52 #14 0xb7f8343f in ldap_unbind (ld=0x8066418) at unbind.c:69 #15 0x0804cfc0 in ?? () #16 0x0804e750 in ?? () #17 0x08057a9f in ?? () #18 0x0804bb8d in ?? () #19 0xb7f50955 in start_thread (arg=0xb7b92b70) at pthread_create.c:300 #20 0xb7ed0e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 More background information is available at [0]. As a workaround [1] I've used LDAP_OPT_DESC to get the file descriptor for the connection and used setsockopt(SO_RCVTIMEO) and setsockopt(SO_SNDTIMEO) on it. This fixes the problem for me at least but I'm not 100% this has no unwanted side-effects. [0] http://bugs.debian.org/596983 [1] http://arthurdejong.org/viewvc/nss-pam-ldapd?view=rev&revision=1264

1 0

(ITS#6672) OpenLDAP LDAP_R_COMPILE cleanup (LDAP_MUTEX_LOCK/LDAP_MUTEX_UNLOCK)
by doug.leavitt＠oracle.com 12 Oct '10

12 Oct '10

Full_Name: Douglas Leavitt Version: HEAD OS: OpenSolaris URL: http://cr.opensolaris.org/~djl/openldap-patch2/ Submission from: (NULL) (192.18.43.225) This patch is part 2 of 3 of the original ITS #6625 effort. (aka openldap draft-zeilenga-ldap-c-api-concurrency) As discussed on openldap-devel(a)openldap.org, #6625 is to be split into 3 distinct patches. This patch cleans up much of the LDAP_R_COMPILE ifdefs in libldap. The patch converts almost all #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_[un]lock(...) #endif sequences to simpler LDAP_MUTEX_[UN]LOCK macros. No behavioral changes are introduced by this patch. It is strictly a code cleanup patch. Regression testing (post conversion) performed using both 32-bit and 64-bit x86 compiles on an OpenSolaris system. IPR Notice This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Oracle Corporation. Oracle Corporation has not assigned rights and/or interest in this work to any party. I, Douglas Leavitt am authorized by Oracle Corporation, my employer, to release this work under the following terms.

1 0

(ITS#6671) multi-master replication fails to delete objects from consumer
by bcolston＠xtec.com 12 Oct '10

12 Oct '10

Full_Name: Barry Colston Version: 2.4.23 OS: Fedora 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.200) When a "Refresh Present" phase is performed at a multi-master consumer, objects that were deleted at the provider while the consumer was down are not deleted from the multi-master consumer (if the provider is brought down and back up after the consumer is down). This problem can be duplicated as follows: 1. Start provider 2. Start consumer, which is configured as a multi-master server 3. Add 10 records to the provider and wait until the records are replicated to the multi-master consumer 4. Stop the consumer 5. Delete 3 of the records that were added to the provider 6. Stop the provider 7. Start the provider 8. Start the consumer 9. After giving the consumer time to perform the refresh present phase, the 3 records that were deleted at the provider while the consumer was down are still present on the consumer and were not deleted during the refresh present phase Note: the consumer database must have a contextCSN attribute value present for itself (e.g., there should be 2 contextCSN attribute values present in the consumer database, one for the provider (in my configuration, this is serverID 000), and one value for the consumer (in my configuration, this is serverID 001). An example of the contextCSN values follows: dn: dc=authentx objectClass: top entryUUID: 8eb6b259-ab66-49bd-b012-674c4f0fba8f contextCSN: 20101012154030.379053Z#000000#000#000000 contextCSN: 20101012141508.956053Z#000000#001#000000 OpenLDAP 2.4.23 is being used, along with Berkeley 4.6.21 (plus patches). Consumer log file from -d sync logging option: @(#) $OpenLDAP: slapd 2.4.23 (Oct 11 2010 18:00:59) $ Barry@XTecVisaAdmin:/usr/src/openldap-2.4.23/servers/slapd slapd starting do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - SYNC_ID_SET do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE - REFRESH_PRESENT do_syncrep2: rid=001 cookie=rid=001,csn=20101012180219.072053Z#000000#000#000000 slap_queue_csn: queing 0x1841a30 20101012180219.072053Z#000000#000#000000 slap_graduate_commit_csn: removing 0x1841b18 20101012180219.072053Z#000000#000#000000 daemon: shutdown requested and initiated. slapd shutdown: waiting for 1 operations/tasks to finish slapd stopped. Provider slapd.conf file: # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/authentx.schema pidfile /usr/local/var/slapd.sync1.pid argsfile /usr/local/var/slapd.sync1.args allow bind_v2 threads 32 #loglevel 416 password-hash {SSHA} serverID 000 database bdb suffix "dc=authentx" rootdn "cn=xroot,dc=authentx" rootpw SECRET directory /authentx/db/ldap/authentx-sync1 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 150000 # checkpoint <kbytes> <min> checkpoint 128 20 #index for the objectclass index objectClass eq,pres index cid,eid,pid eq,pres index gcoid eq,pres index sysid,certid eq,pres index imageid,bioid eq,pres index addrid,emplid eq,pres index acid,apid,aeid eq,pres index acpid,agpid eq,pres index deviceid eq,pres index qid eq,pres index scid eq,pres index docid eq,pres index procid eq,pres index prochandlerid eq,pres index ounit eq,pres index credentials eq,pres index entities eq,pres index permissions eq,pres index region eq,pres index aliasedObjectName eq,pres index proctype eq,pres index procname eq,pres index status eq,pres index upi,ediident eq,pres index xsync eq,pres index role,xrole eq,pres index eroid eq,pres index esfunction eq,pres index nippsector eq,pres index ercog,ercoop eq,pres index eropron eq,pres index xsyncid eq,pres index stockid eq,pres index stocktypecode eq,pres index lotserialin eq,pres index lotserialout eq,pres index entryCSN,entryUUID eq index incl eq,pres cachesize 10000 dncachesize 20000 idlcachesize 1000 sizelimit 500000 timelimit 36000 include /usr/local/etc/openldap/acl.authentx database monitor Consumer slapd.conf file: # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/authentx.schema pidfile /usr/local/var/slapd.sync2.pid argsfile /usr/local/var/slapd.sync2.args allow bind_v2 threads 32 #loglevel 416 password-hash {SSHA} serverID 001 database bdb suffix "dc=authentx" rootdn "cn=xroot,dc=authentx" rootpw SECRET directory /authentx/db/ldap/authentx-sync2 overlay syncprov syncprov-checkpoint 100 15 syncprov-sessionlog 5000 # SLAVE server replication section syncrepl rid=001 provider=ldap://localhost:3891 type=refreshAndPersist retry="30 60 60 +" searchbase="dc=authentx" scope=sub schemachecking=off bindmethod=simple binddn="cn=xroot,dc=authentx" credentials="SECRET" mirrormode on # checkpoint <kbytes> <min> checkpoint 128 20 #index for the objectclass index objectClass eq,pres index cid,eid,pid eq,pres index gcoid eq,pres index sysid,certid eq,pres index imageid,bioid eq,pres index addrid,emplid eq,pres index acid,apid,aeid eq,pres index acpid,agpid eq,pres index deviceid eq,pres index qid eq,pres index scid eq,pres index docid eq,pres index procid eq,pres index prochandlerid eq,pres index ounit eq,pres index credentials eq,pres index entities eq,pres index permissions eq,pres index region eq,pres index aliasedObjectName eq,pres index proctype eq,pres index procname eq,pres index status eq,pres index upi,ediident eq,pres index xsync eq,pres index role,xrole eq,pres index eroid eq,pres index esfunction eq,pres index nippsector eq,pres index ercog,ercoop eq,pres index eropron eq,pres index xsyncid eq,pres index stockid eq,pres index stocktypecode eq,pres index lotserialin eq,pres index lotserialout eq,pres index entryCSN,entryUUID eq index incl eq,pres cachesize 10000 dncachesize 20000 idlcachesize 1000 sizelimit 100000 timelimit 36000 # the authentx database access control directives include /usr/local/etc/openldap/acl.authentx database monitor

1 0

(ITS#6670) memberof overlay problem
by henjes＠informatik.uni-wuerzburg.de 12 Oct '10

12 Oct '10

Full_Name: Robert Henjes Version: 2.4.23-4 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.187.12.89) Hi, while using memberof overlay I recognized the following problem in conjunction with groupOfNames. If you try to add an empty group of names you have to set at least one member attribute, since it is mandatory. One could have the idea to point to the group dn itself. If having the memberof overlay active this leads to a loop while executing an ldapadd. I assume this happens while the memberof overlay is triggered. Tried to analyze the slapd debug output, but it stops, after the addition is completed. Example LDIF file: dn: cn=stupid,ou=groups,dc=domain objectClass: top objectClass: groupOfNames cn: stupid member: cn=stupid,ou=groups,dc=domain The slapd server seems proceed working, except the add process and the subtree where the LDIF is gets added. You can not stop the slapd server in a normal way, you just have to do a "kill -9". After that the LDIF file seems to be added, but I assume, that the memberof overlay representation is inconsistent. The memberof overlay should be aware of such situations, even if building loops in dn references is in general not a good idea. Best regards, Robert

1 0

Re: (ITS#5693) [enhancement] extension of slapo-translucent filtering approach
by wdh＠vasco.com 12 Oct '10

12 Oct '10

Hi Pierangelo, I want to override the objectclass of a remote server to extend it with the attribute posixAccount This works but when I search on the attribute objectclass=* the only result giving me back i the ones with the local defined objectclass. Is it this issue? If so, can we do something about it? is here an easy fix? Thanks Wouter

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs