- openldap-bugs - openldap.org

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

Kurt(a)OpenLDAP.org wrote: > On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > >> On 10/12/10 17:14, Howard Chu wrote: >>> jonathan(a)phillipoux.net wrote: >>>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>>> Full_Name: Jonathan Clarke >>>>> Version: RE24 >>>>> OS: >>>>> URL: >>>>> = > ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>>> Submission from: (NULL) (82.67.204.30) >>>>> =20 >>>>> =20 >>>>> Hi, >>>>> =20 >>>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = > that >>>>> intercepts successful binds and records the current timestamp in an >>>>> attribute >>>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>>> is to detect >>>>> unused accounts. >>>>> =20 >>>>> A configuration parameter (olcLastBindPrecision) allows to set a = > minimum >>>>> precision for the timestamp (ie, don't update the timestamp unless >>>>> it's older >>>>> than<n> seconds). This avoids a performance hit from many >>>>> unnecessary writes in >>>>> case there are many binds per minute/hour/day/week/etc. >>>>> =20 >>>>> Of course, the behaviour this overlay implements is not described = > in >>>>> any RFC, or >>>>> other. However, it closely resembles some of the functionality from >>>>> the password >>>>> policy overlay, and similar functionality already exists in other >>>>> LDAP servers. >>> =20 >>> There is an equivalent attribute defined in the latest ppolicy draft. >>> Perhaps you could use that. > > That attribute is last successful password authentication, not last = > authentication by any means. > > For the latter, I suggest a separate attribute. At Isode, we use an = > authTimestamp dsaOperational attribute for this. > > It's wise to have the updating of this attribute off by default. Good point. In that case it's probably fine as a separate overlay, the way it is now. Can we use the schema definition that Isode is using? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 10:37 AM, jonathan(a)phillipoux.net wrote: > On 10/12/10 17:14, Howard Chu wrote: >> jonathan(a)phillipoux.net wrote: >>> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>>> Full_Name: Jonathan Clarke >>>> Version: RE24 >>>> OS: >>>> URL: >>>> = ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>>> Submission from: (NULL) (82.67.204.30) >>>>=20 >>>>=20 >>>> Hi, >>>>=20 >>>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, = that >>>> intercepts successful binds and records the current timestamp in an >>>> attribute >>>> named "bindTimestamp" in the bound-to entry. It's original use-case >>>> is to detect >>>> unused accounts. >>>>=20 >>>> A configuration parameter (olcLastBindPrecision) allows to set a = minimum >>>> precision for the timestamp (ie, don't update the timestamp unless >>>> it's older >>>> than<n> seconds). This avoids a performance hit from many >>>> unnecessary writes in >>>> case there are many binds per minute/hour/day/week/etc. >>>>=20 >>>> Of course, the behaviour this overlay implements is not described = in >>>> any RFC, or >>>> other. However, it closely resembles some of the functionality from >>>> the password >>>> policy overlay, and similar functionality already exists in other >>>> LDAP servers. >>=20 >> There is an equivalent attribute defined in the latest ppolicy draft. >> Perhaps you could use that. That attribute is last successful password authentication, not last = authentication by any means. For the latter, I suggest a separate attribute. At Isode, we use an = authTimestamp dsaOperational attribute for this. It's wise to have the updating of this attribute off by default. >> Or just submit a patch to incorporate this >> feature into the current ppoloicy overlay. >=20 > Indeed. At the time I wrote this overlay, I think the ppolicy draft = was > not yet finished or at least I wasn't aware of it. My client at the = time > found it useful to just add this simple overlay, without worrying = about > configuring ppolicy. >=20 > Since then, I actually haven't had any time to work on this overlay, = but > today Michael expressed an interest in it, asking for a public IPR > notice, thus the "thread revival". >=20 > I hope to pick it up in the future, and at that point possibly submit = a > patch for ppolicy also, as you suggest. >=20 > Regards, > Jonathan >=20 >=20

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 17:14, Howard Chu wrote: > jonathan(a)phillipoux.net wrote: >> On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >>> Full_Name: Jonathan Clarke >>> Version: RE24 >>> OS: >>> URL: >>> ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >>> Submission from: (NULL) (82.67.204.30) >>> >>> >>> Hi, >>> >>> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >>> intercepts successful binds and records the current timestamp in an >>> attribute >>> named "bindTimestamp" in the bound-to entry. It's original use-case >>> is to detect >>> unused accounts. >>> >>> A configuration parameter (olcLastBindPrecision) allows to set a minimum >>> precision for the timestamp (ie, don't update the timestamp unless >>> it's older >>> than<n> seconds). This avoids a performance hit from many >>> unnecessary writes in >>> case there are many binds per minute/hour/day/week/etc. >>> >>> Of course, the behaviour this overlay implements is not described in >>> any RFC, or >>> other. However, it closely resembles some of the functionality from >>> the password >>> policy overlay, and similar functionality already exists in other >>> LDAP servers. > > There is an equivalent attribute defined in the latest ppolicy draft. > Perhaps you could use that. Or just submit a patch to incorporate this > feature into the current ppoloicy overlay. Indeed. At the time I wrote this overlay, I think the ppolicy draft was not yet finished or at least I wasn't aware of it. My client at the time found it useful to just add this simple overlay, without worrying about configuring ppolicy. Since then, I actually haven't had any time to work on this overlay, but today Michael expressed an interest in it, asking for a public IPR notice, thus the "thread revival". I hope to pick it up in the future, and at that point possibly submit a patch for ppolicy also, as you suggest. Regards, Jonathan

1 0

Oddities with searching for a specific attribute value
by Sebastian Urbanneck 10 Dec '10

10 Dec '10

Sorry for this weird topic, but I didn'T know how to name this one. These are the facts: we're using the phamm.schema from the PHAMM Project for saving virtual domain entries in our Ldap database. Searching for them is mostly no pronblem, but one specific circumstance is bothering me to death: when I try to search for a specific value of the attribute "vd", the corresponding entry is not always found. Any other attribute does the trick, but vd does'nt. For example: the search for (using the root_dn) ldapsearch -x -W -D "cn=admin,dc=uebergebuehr,dc=de" -b "ou=domains,dc=uebergebuehr,dc=de" "(vd=*) -s"one" produces following output: ---------output------------- # extended LDIF # # LDAPv3 # base <vd=lak-hessen.de,ou=domains,dc=uebergebuehr,dc=de> with scope baseObject # filter: (vd=*) # requesting: ALL # # lak-hessen.de, domains, uebergebuehr.de dn: vd=lak-hessen.de,ou=domains,dc=uebergebuehr,dc=de vd: lak-hessen.de lastChange: 1291723263 maxMail: 100 maxAlias: 100 maxQuota: 100 accountActive: TRUE editAV: TRUE delete: FALSE postfixTransport: dovecot objectClass: top objectClass: VirtualDomain description: lak-hessen.de # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ------------------------------------- This is true for everytime I put a Wildcard (*) into the search pattern, and with scope "sub" there's also no matter in which part of the tree above this entry I am. But when I'm searching specificly for the value (lak-hessen.de) nothin is found, no matter in which entry I am and which scope use. Strangely this pattern _is_ found when you go into the entry of the domain itself (vd=lak-hessen.de,ou=domains,...) and search with scobe 'base'. Any idea what I'm doing wrong? Or is this a bug? I think ACLs are ruled out because of using the root_dn. I didn't want to file a Bug before being reallly sure that this is one regards Sebastian

2 1

Re: (ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 10 Dec '10

10 Dec '10

New patch to supplement the other patch for this ITS: ftp://ftp.openldap.org/incoming/openldap-2.4.23-allow-self-issued-certs-to-… Should only allow a cert to pass verification with BasicConstraints CA == FALSE if the cert is self issued. This is what openssl does. Forgot to include the IP statement for the previous patch. The statement applies to that patch and this one. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by hyc＠symas.com 10 Dec '10

10 Dec '10

jonathan(a)phillipoux.net wrote: > On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz >> Submission from: (NULL) (82.67.204.30) >> >> >> Hi, >> >> Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that >> intercepts successful binds and records the current timestamp in an attribute >> named "bindTimestamp" in the bound-to entry. It's original use-case is to detect >> unused accounts. >> >> A configuration parameter (olcLastBindPrecision) allows to set a minimum >> precision for the timestamp (ie, don't update the timestamp unless it's older >> than<n> seconds). This avoids a performance hit from many unnecessary writes in >> case there are many binds per minute/hour/day/week/etc. >> >> Of course, the behaviour this overlay implements is not described in any RFC, or >> other. However, it closely resembles some of the functionality from the password >> policy overlay, and similar functionality already exists in other LDAP servers. There is an equivalent attribute defined in the latest ppolicy draft. Perhaps you could use that. Or just submit a patch to incorporate this feature into the current ppoloicy overlay. >> >> I post it here in the hope that it may serve others, and in case the OpenLDAP >> wishes to include it in one form or another. I would most appreciate any >> comments or feedback. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 10 Dec '10

10 Dec '10

cmikk(a)qwest.net wrote: > This fix would have the effect of treating the sessionlog > as empty until it overflows, and will cause unnecessary > refresh traffic. > > Other than the patch I suggested (using the list head's > CSN value directly), I can think of two other approaches: > > 1) When adding an entry to the sessionlog, check > if sl_mincsn is empty. If it is, update sl_mincsn > to the new entry's CSN. > > 2) When initializing the sessionlog, set sl_mincsn > to the maximum contextCSN value of the underlying > database. > > #2 seems ideal from an efficiency standpoint, although it > differs from the algorithm the current code appears to be > intended to implement. #2 sounds fine, but it sounds like Rein has already got a good solution underway. -- -- 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#6744) memory leak when chasing referrals
by arthur＠arthurdejong.org 10 Dec '10

10 Dec '10

Full_Name: Arthur de Jong Version: 2.4.23 OS: Debian URL: Submission from: (NULL) (2001:888:1613:0:218:8bff:fe55:2c9f) There seems to be a memory leak in the LDAP client library when casing referrals. When the code below is run through valgrind it reports: ==30395== 4,184 (80 direct, 4,104 indirect) bytes in 1 blocks are definitely lost in loss record 3 of 3 ==30395== at 0x402328F: calloc (vg_replace_malloc.c:467) ==30395== by 0x41D2CDF: ber_memcalloc_x (in /usr/lib/liblber-2.4.so.2.5.6) ==30395== by 0x40650A0: ldap_send_server_request (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x4065EB1: ldap_chase_v3referrals (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x40510A3: ldap_result (in /usr/lib/libldap_r-2.4.so.2.5.6) ==30395== by 0x8048871: main (test.c:28) The code below is not very pretty (does not include error handling) but should free all returned buffers. I can also reproduce the above leak with the ldapsearch command-line tool. Some background: http://www.openldap.org/lists/openldap-technical/201012/msg00031.html http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00166.html -----8<-- test.c --8<----- #include <stdio.h> #include <errno.h> #define LDAP_DEPRECATED 1 #include <ldap.h> int main(int argc,char *argv[]) { char *base="dc=test,dc=tld"; char *filter="(objectClass=posixAccount)"; char *attrs[] = { "uid", NULL }; int i; LDAP *ld; LDAPMessage *msg=NULL; int msgid; char **values; /* set up connection */ ldap_initialize(&ld,"ldap://localhost";); i=3; ldap_set_option(ld,LDAP_OPT_PROTOCOL_VERSION,&i); ldap_simple_bind_s(ld,NULL,NULL); /* start search and handle results */ ldap_search_ext(ld,base,LDAP_SCOPE_SUB,filter,attrs, 0,NULL,NULL,NULL,LDAP_NO_LIMIT,&msgid); while (1) { switch (ldap_result(ld,msgid,LDAP_MSG_ONE,NULL,&msg)) { case LDAP_RES_SEARCH_ENTRY: /* we have a normal search entry, print some attribute values */ values=ldap_get_values(ld,msg,attrs[0]); for (i=0;values[i]!=NULL;i++) fprintf(stderr,"%s=%s\n",attrs[0],values[i]); ldap_value_free(values); break; case LDAP_RES_SEARCH_RESULT: /* end of results */ ldap_msgfree(msg); ldap_unbind(ld); return 0; case LDAP_RES_SEARCH_REFERENCE: break; /* just ignore search references */ default: /* we have some error condition, bail out */ return -1; } ldap_msgfree(msg); } } -----8<-- test.c --8<-----

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 10/12/10 14:53, Kurt Zeilenga wrote: > > On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > >> I'd like to add an IPR notice to this >> contribution: > > I note that you only provide half the notice. A complete notice would be followed by a statement of what license the contribution is provided under. Ah, the licence is included in the files, but I repeat it here for clarity: * Copyright 2009 Jonathan Clarke <jonathan(a)phillipoux.net>. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted only as authorized by the OpenLDAP * Public License. * * A copy of this license is available in the file LICENSE in the * top-level directory of the distribution or, alternatively, at * <http://www.OpenLDAP.org/license.html>. Jonathan

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by Kurt＠OpenLDAP.org 10 Dec '10

10 Dec '10

On Dec 10, 2010, at 6:43 AM, jonathan(a)phillipoux.net wrote: > I'd like to add an IPR notice to this > contribution: I note that you only provide half the notice. A complete notice would = be followed by a statement of what license the contribution is provided = under. -- Kurt=

1 0

Re: (ITS#6238) contrib: lastbind overlay to record timestamp of last successful bind
by jonathan＠phillipoux.net 10 Dec '10

10 Dec '10

On 30/07/09 13:50, jonathan(a)phillipoux.net wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-lastbind-20090730.tgz > Submission from: (NULL) (82.67.204.30) > > > Hi, > > Please find, at the above URL, an overlay, built for OpenLDAP 2.4, that > intercepts successful binds and records the current timestamp in an attribute > named "bindTimestamp" in the bound-to entry. It's original use-case is to detect > unused accounts. > > A configuration parameter (olcLastBindPrecision) allows to set a minimum > precision for the timestamp (ie, don't update the timestamp unless it's older > than <n> seconds). This avoids a performance hit from many unnecessary writes in > case there are many binds per minute/hour/day/week/etc. > > Of course, the behaviour this overlay implements is not described in any RFC, or > other. However, it closely resembles some of the functionality from the password > policy overlay, and similar functionality already exists in other LDAP servers. > > I post it here in the hope that it may serve others, and in case the OpenLDAP > wishes to include it in one form or another. I would most appreciate any > comments or feedback. > > Regards, > Jonathan > > PS: please note that the OIDs used are not registered, but used temporarily. I > do not currently have access to a registered OID to use. To respond to an off-list request, I'd like to add an IPR notice to this contribution: The above mentioned files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the files were developed by Jonathan Clarke <jonathan(a)phillipoux.net>. I have not assigned rights and/or interest in this work to any party. Hope this is the right wording... Jonathan

1 0

Re: (ITS#6743) LDAP 3000
by masarati＠aero.polimi.it 10 Dec '10

10 Dec '10

sylvie.longeau(a)axa-lm.com wrote: > Full_Name: Longeau > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.18.2.133) > > > Please, could you explain what is the [LDAP 3000] error code? This is not an OpenLDAP (nor an LDAP) error code, as far as I know. In any case, the ITS is intended to track software bugs and related issues. Usage questions should be addressed to openldap-technical. This ITS will be closed. p.

1 0

(ITS#6743) LDAP 3000
by sylvie.longeau＠axa-lm.com 10 Dec '10

10 Dec '10

Full_Name: Longeau Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.18.2.133) Please, could you explain what is the [LDAP 3000] error code? Thanks

1 0

(ITS#6742) Patch - Mozilla NSS - centralize and improve certificate verification
by rmeggins＠redhat.com 10 Dec '10

10 Dec '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-centralize-and-improve-cert… Submission from: (NULL) (76.113.111.209) The changes are to make Mozilla NSS certificate verification work like OpenSSL. The former is using Fedora 14 with Mozilla NSS 3.12.8, the latter, Fedora 13 with OpenLDAP 2.4.21 and OpenSSL 1.0.0b. I tested the following scenarios: * self signed server + CA cert as generated by openssl req -x509 * server cert generated by self signed CA (/etc/pki/tls/misc/CA) I tested various combinations of certs, with and with CA certs, on both the server and the client, and verified that the F-14 system worked the same as the F-13, excepting differences in error messages. I added a new function - tlsm_verify_cert() - that could handle different types of cert verification. I replaced other calls to CERT_Verify* with this function and consolidated exception and error handling there. In order to make error handling more flexible, I use the CERT_VerifyCertificate() function which takes a logging parameter. The log contains a list of the errors found along with each cert that caused a problem (a cert may be listed in the log multiple times if a cert had more than one problem). The use of logging also allows cert verification to continue to search for all problems, rather than just returning at the first problem. This allows fine grained error handling which is needed for the following problem: OpenSSL allows CA certs with the Basic Constraints extension set with the CA flag set to FALSE. NSS does not. If tlsm_verify_cert finds this case, it can just log a warning and allow it. I also added the ability to specify an error code to ignore in cert verification, which is needed when using a self signed CA cert for the server cert. I also changed the way trust is handled. In OpenSSL, certs specified by the user (e.g. in TLS_CACERT, TLS_CACERTDIR, TLS_CERT) are explicitly trusted. So, for example, you can specify a server or client cert without specifying the CA cert issuer, and OpenSSL will allow it. NSS will allow it if the cert is specified as trusted. I changed the add_cert code to accept an istrusted flag so that you can specify if a PEM cert is trusted. The PEM NSS code stores trusted certs in a special slot, so the code had to be changed to accommodate that. Finally, I added a default error message which has the error code if an error message was not already set by the library.

1 0

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 09 Dec '10

09 Dec '10

I "rebased" the patch on top of a recent change: revision 1.24 date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 ITS#6625 Remove some LDAP_R_COMPILEs The new patch is here: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

rein(a)OpenLDAP.org wrote: > On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >> I think the best (blind) fix consists in only performing that test if >> sl_mincsn is assigned a value; something like > > I'm looking at an extended fix. The problem with the current > implementation is that is assumes the entries arrives in CSN order, > which isn't necessarily true in a MMR configuration. > > My fix drops sl_mincsn, keeps the log queue in CSN order and compares > with the head entry. It also wipes the log if it receives any changes > without CSN (i.e during refresh). > > There might still be a theoretical problem there, if the sid of an entry > in the log is not in the set sent by the consumer. But since we know > they have the same number of CSNs this can only happen during initial > setup of a multi-master configuration. In which case the admins real > problem is that he didn't bring the servers online in a controlled order.. OK, I'm not looking at this any more. Thanks, p.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 09 Dec '10

09 Dec '10

On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: > I think the best (blind) fix consists in only performing that test if > sl_mincsn is assigned a value; something like I'm looking at an extended fix. The problem with the current implementation is that is assumes the entries arrives in CSN order, which isn't necessarily true in a MMR configuration. My fix drops sl_mincsn, keeps the log queue in CSN order and compares with the head entry. It also wipes the log if it receives any changes without CSN (i.e during refresh). There might still be a theoretical problem there, if the sid of an entry in the log is not in the set sent by the consumer. But since we know they have the same number of CSNs this can only happen during initial setup of a multi-master configuration. In which case the admins real problem is that he didn't bring the servers online in a controlled order.. Rein

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 09 Dec '10

09 Dec '10

On Thu, Dec 09, 2010 at 09:09:21AM +0100, Pierangelo Masarati wrote: > I think the best (blind) fix consists in only performing that test > if sl_mincsn is assigned a value; something like > > /* Are there any log entries, and is the consumer state > * present in the session log? > */ > - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, > &sl->sl_mincsn ) >= 0 ) { > + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && > + sl->sl_num > 0 && > + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) > + { > do_present = 0; > /* mutex is unlocked in playlog */ > syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); > > However I'd like to hear some other opinion. This fix would have the effect of treating the sessionlog as empty until it overflows, and will cause unnecessary refresh traffic. Other than the patch I suggested (using the list head's CSN value directly), I can think of two other approaches: 1) When adding an entry to the sessionlog, check if sl_mincsn is empty. If it is, update sl_mincsn to the new entry's CSN. 2) When initializing the sessionlog, set sl_mincsn to the maximum contextCSN value of the underlying database. #2 seems ideal from an efficiency standpoint, although it differs from the algorithm the current code appears to be intended to implement. -- Chris Mikkelson | Vampireware; n, a project capable of sucking the cmikk(a)qwest.net | lifeblood out of anyone unfortunate enough to be | assigned to it which never actually sees the light | of day, but nonetheless refuses to die. (tlode(a)nyx.net)

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

I think the best (blind) fix consists in only performing that test if sl_mincsn is assigned a value; something like /* Are there any log entries, and is the consumer state * present in the session log? */ - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && + sl->sl_num > 0 && + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) + { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); However I'd like to hear some other opinion. p.

1 0

(ITS#6741) x500UniqueIdentifier handling
by jgcardoso＠seguridata.com 09 Dec '10

09 Dec '10

Full_Name: Juan González Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101208.cer Submission from: (NULL) (201.148.141.170) Inserting userCertificate values containing x500UniqueIdentifier attribute at issuerNames fails. Some values even makes server to crash.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by masarati＠aero.polimi.it 08 Dec '10

08 Dec '10

> What's special about DN rewriting so it has a configure option > anyway? It doesn't disable building of libraries/librewrite. It used to, as far as I remember. I remember something about performing simple suffixmassage when librewrite is not built. In any case I agree that given the widespread usage of rewrite capabilities (authz regexp, for example) not building librewrite is somehow pointless. p.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

What's special about DN rewriting so it has a configure option anyway? It doesn't disable building of libraries/librewrite. -- Hallvard

1 0

(ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard configure should mention syncrepl here: --enable-rewrite enable DN rewriting in back-ldap and rwm overlay test059-slave-config fails with --disable-rewrite. Testrun/test.out says parse_syncrepl_line: unable to parse "suffixmassage=cn=schema,cn=config,cn=slave"

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 06 Dec '10

06 Dec '10

On 12/ 6/10 04:09 AM, h.b.furuseth(a)usit.uio.no wrote: > I've made two fixes (I hope) to the concurrency commit, please review: > > - In do_abandon(), protected ldap_free_connection() with > ld->ld_conn_mutex. The function would unlock it when it did not own > the mutex. > > However I do not know why the mutex was moved out of > ldap_free_connection(), so maybe something more needs to be done. > The abandon operation is now protected by it's own abandon mutex, not by the conn mutex. So do_abandon is not protecting the conn unless it is actually in use. ldap_free_connection reference counts the connection and only frees it if there are no other users of the connection. This is why ldap_free_connection requires protection. If there are multiple simultaneous threads using the connection some of which may have in flight operations, those threads are not interrupted by the abandon of another thread. Consider connection A with 3 threads performing searches. Thread 3 may abandon it's search but threads 1 and 2 may continue with their operations. Removing the protection around ldap_free_connection will disrupt the reference counting for the connection and cause potential connection leakage and/or disrupt other threads usage of the connection. Doug.

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

I've made two fixes (I hope) to the concurrency commit, please review: - I inverted the test in NT threads MUTEX_FIRSTCREATE. I assume LDO_MUTEX_NULL = (HANDLE)0 is not a valid handle, so FIRSTCREATE must initialize m if it *is* 0, not if is *not*. - In do_abandon(), protected ldap_free_connection() with ld->ld_conn_mutex. The function would unlock it when it did not own the mutex. However I do not know why the mutex was moved out of ldap_free_connection(), so maybe something more needs to be done. Also I've cleaned up macros and namespace: Add proper values for NO_THREADS. Support LDAP_THREAD_DEBUG. Define LDAP_INT_* and LDAP_DEBUG_* in ldap_int_thread.h, LDAP_PVT_* in ldap_pvt_thread.h. libraries/libldap/ldap-int.h: Remove unnecessary #ifdef LDAP_R_COMPILE for LDAP_NEXT_MSGID. define LDAP_LDO_MUTEX_NULLARG as ,LDAP_PVT_MUTEX_NULL or empty in the same place which decides whether the initializer is needed. Wrap some macros and arguments in parens or do{}while(0), so they can be used more like C statements. Also replace empty macros with ((void) 0) expansions, to shut up 'empty statement' compiler warnings. Finally, I've another wish for the test060-mt-hot: This test takes way to long under Valgrind. It ought to obey $TESTLOOPS (default 50) like the concurrency tests do: Set parameters to run ca $TESTLOOPS/50 of the current time. I don't know which parameters it's best to reduce in that case, however? -- Hallvard

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> >> slapdmodify(8) is the (nearly untested) result of non negligible >> cut'n'paste. > > In any case, there seems to be significant side code commonality between > slapadd and slapmodify, basically everything related to syncing the > context entry. Maybe we should move that code in helpers in slapcommon.c. See <ftp://ftp.openldap.org/incoming/pierangelo.masarati-2010-12-06-update_ctxcs…>. p.

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> slapdmodify(8) is the (nearly untested) result of non negligible > cut'n'paste. In any case, there seems to be significant side code commonality between slapadd and slapmodify, basically everything related to syncing the context entry. Maybe we should move that code in helpers in slapcommon.c. p.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

hyc(a)symas.com writes: > See the definition of pwdChangedTime, section 5.3.2: Duh, I misread what you said. In any case, it's a separate issue. That's about slapd expiring the passwor, this patch is about the user deleting it. -- Hallvard

1 0

(ITS#6739) broken do_syncrep2()
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd/syncrepl.c:do_syncrep2() initializes many variables once which should have been initialized inside the loop. I'll add the initializations I can figure out, and move most variables into the loop for readability. TODO: Variables 'm' and 'refreshDeletes' may still be wrong. In particular 'm'. It "feels" like it should be local to the loop, but there's no logic that I can see to prevent previous value from being used. Perhaps they depend on the peer not breaking the sync protocol? I haven't read that myself, I'm just peering at the code. I've added three somewhat arbitrary bits of code for error handling: - A Debug() statement on line 847 which can likely be improved. - Set err and rc to LDAP_OTHER on ldap_parse_result/ldap_get_option failure. The correct fix would be proper error checks (ITS#6738), but I don't know what to do on error.

1 0

Re: (ITS#6737) slapmodify strangeness
by masarati＠aero.polimi.it 06 Dec '10

06 Dec '10

> Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > 'sid' in slapmodify.c is read uninitialized before it is written, at line > 693: > > if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != > SLAP_SYNC_SID_MAX > + 1 ) { > > A loop _below_ that statement can set sid to the expected value: > > for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) > > Also slapmodify sets up but does not use variables opbuf and op. slapdmodify(8) is the (nearly untested) result of non negligible cut'n'paste. p.

1 0

(ITS#6738) missing checks for ber errors
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard There are a fair number of ber calls which do not check for errors: Just ber_scanf and use the expected output variable, which may or may not have a useful NULL value on error. Syncrepl is particularly bad. This in slapd/ and libldap/: egrep '^<tab>*ber_(scanf|get_)' *.c */*.c returns mostly syncrepl matches. I can't even fix these easily because there's not enough error handling code to copy. grepping for ber_(printf|put_) find other modules as well.

1 0

(ITS#6737) slapmodify strangeness
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard 'sid' in slapmodify.c is read uninitialized before it is written, at line 693: if ( rc == EXIT_SUCCESS && update_ctxcsn && !dryrun && sid != SLAP_SYNC_SID_MAX + 1 ) { A loop _below_ that statement can set sid to the expected value: for ( sid = 0; sid <= SLAP_SYNC_SID_MAX; sid++ ) Also slapmodify sets up but does not use variables opbuf and op.

1 0

(ITS#6736) Listener info destroyed too early on shutdown
by h.b.furuseth＠usit.uio.no 06 Dec '10

06 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard On shutdown, slapd_daemon_task() calls close_listeners() which destroys slap_listeners[] while other threads may be accessing it. This is not mutex-protected. Valgrind reports freed data accesses in back-monitor and slapd_listener() when they try to read the URLs in the listeners. Giving HEAD a minimal fix: Stop listening but delay destruction. If anyone feels like it, the new 'listening' flag probably can be used more intelligently, e.g. by rearranging the use of it and some shutdown flags.

1 0

(ITS#6735) Uninitialized filter in slapd-tester
by h.b.furuseth＠usit.uio.no 04 Dec '10

04 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard rflts[jj] can be used uninitialized at slapd-tester.c:875. Fixing.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 04 Dec '10

04 Dec '10

masarati(a)aero.polimi.it wrote: > h.b.furuseth(a)usit.uio.no wrote: >> Hopefully fixed with the latest ITS#6632/6720 commits. > > You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), > it looked unrelated. For me, ITS#6727 is now fixed with your patch. > Can you confirm, Michael? 30 test iterations without problems. Seems to be fixed now. Ciao, Michael.

1 0

(ITS#6734) Implment delta-sync based MMR
by quanah＠OpenLDAP.org 03 Dec '10

03 Dec '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) To help resolve ITS#6097, it would be helpful to have delta-sync MMR available. I'm mainly filing this bug for tracking.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 03 Dec '10

03 Dec '10

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >>> >>> Reproducing the bug: >>> >>> userPassword can exist without pwdChangedTime if you bypass >>> ppolicy: Use slapadd to add an entry with userPassword, or add >>> it to a subtree with no policy and then configure a policy. >>> >>> Then set up ppolicy and use ldapmodify to delete userPassword. >> >> In that case the correct fix is to skip the pwdChangedTime attribute >> completely. > > Well, that's what this fix does in this particular code chunk: > Don't try to delete pwdChangedTime if it isn't there. > >> The ppolicy spec says that entries without pwdChangedTime are not >> subject to password expiration at all. > > Sounds like a different issue, but I don't see where it says that. > What I did find is > > 8.2.7. Policy State Updates > > If the value of either pwdMaxAge or pwdMinAge is non-zero, the server > updates the pwdChangedTime attribute on the entry to the current > time. > See the definition of pwdChangedTime, section 5.3.2: 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. -- -- 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

MemberOf out of sync on consumer[s]
by Yuri Bank 03 Dec '10

03 Dec '10

Hello, I've been putting this off for a while, but this is happening frequently enough that I think its time to ask for opinions on the bug I'm running into with OpenLDAP and the MemberOf overlay. Version: 2.4.23 Configuration: Single Provider, with 4 Consumers. It seems that when I add a new users on my provider, the MemberOf attribute disappears randomly for some users, on some ( not all ) consumer nodes. Everything in the DIT is in tact, and the changes made on my provider are replicated to the consumers correctly. The only issue here is with the memberof attribute. The only way for me to remedy this problem is to shutdown slapd on the affected consumer node, delete everything in /var/sun/slapd, and then start slapd again which then fully syncs with my provider with all memberof attributes in tact. My testing shows that this is triggered by making changes to to my LDAP groups/users on the provider node, but that is all I can find. Nothing in the logs gives me any clues as to what is happening. Has anyone experienced similar problems? Thanks, -Yuri Bank

2 1

Re: (ITS#6684) Patch for autogroup overlay
by ryans＠aweber.com 03 Dec '10

03 Dec '10

Just wanted to say that I've tested the patch Norbert submitted with 2.4.21 and 2.4.23, and it fixes the problems for me on both installations. Great job on the patch, Norbert. -Ryan

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by masarati＠aero.polimi.it 03 Dec '10

03 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Hopefully fixed with the latest ITS#6632/6720 commits. You mean ITS#6727, I guess. I fixed ITS#6720 (rwm.c 1.132 -> 1.133), it looked unrelated. For me, ITS#6727 is now fixed with your patch. Can you confirm, Michael? Thanks, p.

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Hopefully fixed with the latest ITS#6632/6720 commits. -- Hallvard

1 0

(ITS#6733) LDAP_MEMORY_DEBUG issues
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard With LDAP_MEMORY_DEBUG, - ber_memcalloc_x does not check for overflow. - LBER_MEM_JUNK and the ber_int_mem_hdr initializer get compiler warnings. Fixing.

1 0

Re: (ITS#6632) Core dump in test030 when using back-ldap
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Easily found with valgrind --track-origins=yes. Fixed in rwm.c rev 1.134. -- Hallvard

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: > It is not an error in ldif_back_add() since rs->sr_text is only used by > send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. Okay. I wondered if overlays could do something strange, but that does seem wrong. Then this bug only affected modify and modrdn. -- Hallvard

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by h.b.furuseth＠usit.uio.no 03 Dec '10

03 Dec '10

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >> Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. >> >> Reproducing the bug: >> >> userPassword can exist without pwdChangedTime if you bypass >> ppolicy: Use slapadd to add an entry with userPassword, or add >> it to a subtree with no policy and then configure a policy. >> >> Then set up ppolicy and use ldapmodify to delete userPassword. > > In that case the correct fix is to skip the pwdChangedTime attribute > completely. Well, that's what this fix does in this particular code chunk: Don't try to delete pwdChangedTime if it isn't there. > The ppolicy spec says that entries without pwdChangedTime are not > subject to password expiration at all. Sounds like a different issue, but I don't see where it says that. What I did find is 8.2.7. Policy State Updates If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time. -- Hallvard

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by quanah＠zimbra.com 02 Dec '10

02 Dec '10

--On December 2, 2010 6:45:45 PM +0000 doug.leavitt(a)oracle.com wrote: > At the end of my test threads 11-14 were not terminated. I > believe this may imply significant thread stack growth not 'leakage'. > > I will provide more info as I get it. I hope this helps in resolving > this ITS. Hi Doug, Thanks for the data point. We've definitely identified that it is not leakage, but problems with having multiple cores (> 2 or 3). In that scenario, the entry cache grows up until the point that every entry is present in the cache. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6660) paged result searches fail to deallocate memory until slapd shutdown
by doug.leavitt＠oracle.com 02 Dec '10

02 Dec '10

I may have another data point w.r.t this ITS. I tried replicating this ITS by: setting up a slapd based on test003-search config plus 100,000 additional entries similar to the other OpenLDAPperson test entries. running 20+ simultaneous instances of the test003 search tests I see a definite memory growth in the server. After the test run, according to libumem transaction logs there is about 600k lost memory in leaks (in my case). BUT the leaks are not lost cache entries or other obvious malloc/free errors. According to libumem the "leaks" are all 4k - 16k chunks of MMAP memory allocated to thread stacks associated with threads 11 - 14. I plan to investigate further. libumem may be reporting that there are no leaks, but instead that certain threads have significant thread stack growth under heavy activity. Alternately the threads may be terminating, resulting in loss of thread stack memory and later being restarted multiple times resulting in multiple thread stack leaks. (I am not sure yet which situation is the correct one). Either situation may produce an unaccounted for memory growth that may not be exposed via normal debugging malloc techniques because the memory loss does not seem to be heap related. At the end of my test threads 11-14 were not terminated. I believe this may imply significant thread stack growth not 'leakage'. I will provide more info as I get it. I hope this helps in resolving this ITS. Doug.

1 0

Re: (ITS#6620) ppolicy: pwdChangedTime/userPassword delete issue.
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Thanks. Applied a similar patch to cvs HEAD, after fixing a memory leak. > > Reproducing the bug: > > userPassword can exist without pwdChangedTime if you bypass > ppolicy: Use slapadd to add an entry with userPassword, or add > it to a subtree with no policy and then configure a policy. > > Then set up ppolicy and use ldapmodify to delete userPassword. > In that case the correct fix is to skip the pwdChangedTime attribute completely. The ppolicy spec says that entries without pwdChangedTime are not subject to password expiration at all. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6731) Scrambled error strings from back-ldif
by hyc＠symas.com 02 Dec '10

02 Dec '10

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.157.203.245) > Submitted by: hallvard > > > apply_modify_to_entry() and ldif_back_add() can return with > rs->sr_text pointing into the stack, at textbuf[]. Fixing. > It is not an error in ldif_back_add() since rs->sr_text is only used by send_ldap_result(). Its value upon return from ldif_back_add is irrelevant. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6727) ./scripts/test047-ldap: line 599: 26709 Segmentation fault
by michael＠stroeder.com 02 Dec '10

02 Dec '10

I can still reproduce this pretty soon when running this test with several iterations. testrun/slapd.3.log ends with: connection_close: conn=1014 sd=9 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 =>ldap_back_conn_destroy: fetching conn 1014 conn=1014 fd=9 closed (connection lost) daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 operations/tasks to finish lt-slapd shutdown: initiated lt-slapd destroy: freeing system resources. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 13 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 11 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 ldap_free_connection: actually freed ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 10 ldap_free_connection: actually freed slapd stopped. lt-slapd: at.c:242: at_delete_names: Assertion `air != ((void *)0)' failed.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs