- openldap-bugs - openldap.org

(ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 06 Jun '10

06 Jun '10

Full_Name: Daniel Pluta Version: 2.4.21 OS: Lnx URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:6834:fd61:37f:67da) Hi, after a silly typo (removed the "," rdn-separator character) in refint's cn=config settings while modifying "olcRefintNothing" attribute the attribute contained the following escaped value: olcRefintNothing: cn=refintcn\3Dconfig Using ldapmodify with cn=config to correct this value back into e.g. "cn=refint,cn=config" caused slapd to crash. Re-starting slapd (recovering db files...) worked fine but the value of course is still the "ugly" one above. Trying to correct (using ldapmodify) this value once more caused slapd to crash again. Cheers Daniel

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 06 Jun '10

06 Jun '10

Hi, I have run slapd in valgrind now, which produced following error: ==15353== 1 errors in context 1 of 5: ==15353== Invalid write of size 4 ==15353== at 0x80E64B5: slap_sl_free (sl_malloc.c:492) ==15353== by 0x80A0EEA: ch_free (ch_malloc.c:137) ==15353== by 0x80E3DC9: mra_free (mra.c:43) ==15353== by 0x80855B0: filter_free_x (filter.c:556) ==15353== by 0x80836CD: do_search (search.c:230) ==15353== by 0x8080588: connection_operation (connection.c:1109) ==15353== by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:685) ==15353== by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.so) ==15353== by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so) ==15353== Address 0x843692b1 is not stack'd, malloc'd or (recently) free'd Full valgrind log can be found at http://pastebin.de/6914 -Dieter

1 0

(ITS#6571) rebind-as-user only works on first connection attempt
by maci＠satgnu.net 04 Jun '10

04 Jun '10

Full_Name: Marcel Wysocki Version: 2.4.22 OS: Solaris/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.79.126.162) Hello, i have the same problem as described here: http://www.openldap.org/lists/openldap-software/200712/msg00283.html here are some logs: @(#) $OpenLDAP: slapd 2.4.22 (Jun 4 2010 11:56:46) $ slapd starting Initial connection: ########################## conn=1000 fd=11 ACCEPT from IP=127.0.0.1:45654 (IP=0.0.0.0:389) conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" method=128 conn=1000 op=0 BIND dn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" mech=SIMPLE ssf=0 conn=1000 op=0 RESULT tag=97 err=0 text= ########################## First ldapsearch: ########################## conn=1000 op=2 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=2 SRCH attr=objectclass conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been restarted, sencond ldapsearch: ########################## conn=1000 op=3 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=3 SRCH attr=objectclass conn=1000 op=3 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text= ########################## backend server has been stopped, third ldapsearch, fails as it should: ########################## conn=1000 op=4 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=4 SRCH attr=objectclass conn=1000 op=4 ldap_back_retry: retrying URI="ldap://10.2.163.13:389" DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" conn=1000 op=4 SEARCH RESULT tag=101 err=52 nentries=0 text= ########################## backend server has been restarted, fourth ldapsearch, rebind fails: ########################## conn=1000 op=5 SRCH base="ou=users,ou=BAR,c=de,o=bazbaz" scope=1 deref=3 filter="(mobile=491721000227)" conn=1000 op=5 SRCH attr=objectclass conn=1000 op=5 ldap_back_dobind_int: DN="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" without creds, binding anonymously conn=1000 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= ########################## following the configuration for back-ldap: database ldap suffix "o=bazbaz" uri ldap://10.2.163.13:389 rootdn "cn=PEX,o=bazbaz" rootpw secret idle-timeout 301 rebind-as-user yes single-conn yes chase-referrals no acl-bind bindmethod=simple binddn="uid=FOOO,ou=applications,ou=admin,ou=BAR,c=de,o=bazbaz" credentials=supersecret

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

On Jun 2, 2010, at 11:11 AM, Michael Str=F6der wrote: > Kurt(a)OpenLDAP.org wrote: >> However, one issue I have with this code is that highly dependent =3D >> behaviors which, aside from not be standardized, aren't even = specified =3D >> in RFCs. For instance, there is no RFC describing dnsHostName or =3D >> ldapServiceName or any specification detailing how GSS-SPNEGO is to = be =3D >> used in LDAP. Without a formal specification (e.g., RFC), I oppose =3D= >> release of this code. That is, it should stay HEAD only until such = time =3D >> that a formal specification (e.g., RFC) is available. >=20 > Kurt, I somewhat can understand your concerns. > But as a general answer to your comment above: There is already a lot = of code > in OpenLDAP for which no RFC or at least an I-D was specified but = which serves > a certain use-case. Strictly (following your statement above) speaking = one > would have to hunk out all the stuff only specified in I-Ds. An I-D would be a start. I would think there's a number of interesting = security considerations that would bubble up if someone would ever have = taken the time to submit a specification regarding use of SPNEGO in SASL = and in application protocols such as LDAP to an open standards = organization such as the IETF. > So I don't see > the strong need to be overly strict here. It's long been a stated goal of the project to promote interoperability = through open standards. This work seems more to come from a community = whose stated goal is to behave like one particular vendor. I'm not a = fan of chasing any particular vendor. > Quality of certain code is another story. But I cannot comment on = this. How can one independently verify the code acts as intended without a = specification of the intended behavior? (Saying it should act like = some particular commercial product, is not a specification.) -- Kurt >=20 > Ciao, Michael.

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by michael＠stroeder.com 02 Jun '10

02 Jun '10

Kurt(a)OpenLDAP.org wrote: > However, one issue I have with this code is that highly dependent = > behaviors which, aside from not be standardized, aren't even specified = > in RFCs. For instance, there is no RFC describing dnsHostName or = > ldapServiceName or any specification detailing how GSS-SPNEGO is to be = > used in LDAP. Without a formal specification (e.g., RFC), I oppose = > release of this code. That is, it should stay HEAD only until such time = > that a formal specification (e.g., RFC) is available. Kurt, I somewhat can understand your concerns. But as a general answer to your comment above: There is already a lot of code in OpenLDAP for which no RFC or at least an I-D was specified but which serves a certain use-case. Strictly (following your statement above) speaking one would have to hunk out all the stuff only specified in I-Ds. So I don't see the strong need to be overly strict here. Quality of certain code is another story. But I cannot comment on this. Ciao, Michael.

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

On Jun 2, 2010, at 4:28 AM, gcarter(a)likewise.com wrote: >=20 > Is it just the public ldap_bind_gssapi_s() signature that you > have an issue with? If, as you suggest, we give you a patch > that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep > the same (existing) ldap_bind_gssapi_s() internals, would that > be acceptable? There's already LDAP_AUTH_NEGOTIATE which does this. So technically, = the API is already exposed via ldap_bind_s. But I strongly oppose the introduction of abuse of the LDAP_AUTH_* = enumeration of LDAP authentication methods and ldap_bind_s(). This = enumeration and method are intended to have a one-to-one relationship = with the wire protocol. There is no "negotiate" LDAP authentication = mechanism. If this code is going to pursued (see my other comments), I think it = should be treated as a high level negotiation wrapper similar to = ldap_sasl_interactive_bind_s(). If at all possible, it should be = integrated into ldap_sasl_interactive_bind_s() (which can handle = non-interactive cases as well). However, I could (*) see it desirable = for it to be separately accessible as well, so = ldap_sasl_gss_spnego_bind_s() would be better. (* it might be easier to = see this if a proponent of this feature would implement it in = ldapwhoami(1) and slapd(8).) However, I still have objections to releasing code which implements = undocumented protocol features. Someone really needs to specify the the = SASL GSS-SPNEGO mechanism and how its used in LDAP. -- Kurt=20 >=20 >=20 >=20 >=20 >=20 >=20 > cheers, jerry > - --=20 > Director of Engineering http://www.likewise.com/ > Likewise-CIFS http://www.likewiseopen.org/ > "What man is a man who does not make the world better?" --Balian >=20 >=20 >=20 >=20 >=20 > On 6/2/10 12:10 AM, Scott Salley wrote: >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: Tue 6/1/2010 6:07 PM >> To: Scott Salley >> Cc: openldap-its(a)openldap.org >> Subject: Re: (ITS#6567) Enable GSSAPI support and expose = ldap_gssadpi_bind_s >>=20 >> ssalley(a)likewise.com wrote: >>> Full_Name: Scott Salley >>> Version: HEAD >>> OS: Linux >>> URL: >> = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >>> Submission from: (NULL) (67.51.54.234) >>>=20 >>>=20 >>> Note that a similar issue/contribution was submitted in 2008 >> (Contrib/5369) and >>> appears to have been 'lost'. >>=20 >>> The patch >> = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >>> makes it possible to use the GSSAPI support in OpenLDAP by: >>>=20 >>> 1. Defining --with-gssapi in configure which >>> a. Checks for appropriate header files >>> b. Checks for the appropriate library >>> c. Defines HAVE_GSSAPI to 1 in everything is in order >>>=20 >>> 2. Exposing ldap_gssapi_bind_s in ldap.h >>=20 >> I am still disinclined to publish any of this. The standard mechanism = for >> using GSSAPI in LDAP is via SASL. I see no benefit to propagating = more >> non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach >> and it >> increases our support workload for no appreciable gain. It increases >> application developer's workload as well, if they have to test for = the >> existence of multiple flavors of ldap_XXX_bind and code for them each >> separately in their apps. >>=20 >> If you really want to have "direct" access to other authentication >> mechanisms, >> the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can >> be muxed out from a single ldap_bind API. Of course, by the time = you've >> implemented option parsing so that generic client code can be = configured >> with >> arbitrary Bind mechanisms, you would have re-implemented SASL. >>=20 >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>=20 >=20 >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu > 9/F8j8UQJ5C3X0sW5LytRq8=3D > =3DtkYo > -----END PGP SIGNATURE----- >=20 >=20

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

Lastly, I note that it might be good for proponent of this feature to at = least offer extensions to ldapwhoami(1) and other command line tools. = Aside from the educational value that would provide to developers in how = this feature would be used along side other libldap features (such as = ldap_sasl_interactive_bind_s), it would provide a means to test the = code. Of course, without support in OpenLDAP's slapd(8), testing would = be cumbersome for many. -- Kurt On Jun 1, 2010, at 6:08 PM, hyc(a)symas.com wrote: > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >>=20 >>=20 >> Note that a similar issue/contribution was submitted in 2008 = (Contrib/5369) and >> appears to have been 'lost'. >=20 >> The patch = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >>=20 >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >>=20 >> 2. Exposing ldap_gssapi_bind_s in ldap.h >=20 > I am still disinclined to publish any of this. The standard mechanism = for=20 > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20= > non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach and it=20 > increases our support workload for no appreciable gain. It increases=20= > application developer's workload as well, if they have to test for the=20= > existence of multiple flavors of ldap_XXX_bind and code for them each=20= > separately in their apps. >=20 > If you really want to have "direct" access to other authentication = mechanisms,=20 > the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can=20 > be muxed out from a single ldap_bind API. Of course, by the time = you've=20 > implemented option parsing so that generic client code can be = configured with=20 > arbitrary Bind mechanisms, you would have re-implemented SASL. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 02 Jun '10

02 Jun '10

In looking at the code a bit more closely, one could argue that what = this code actually provides is an alternative to = ldap_sasl_interactive_bind_s() which, instead of negotiating any = mechanism, is designed to negotiate GSS API mechanisms via GSS-SPNEGO. = In that light, maybe it should be integrated into = ldap_sasl_interactive_bind_s() or renamed to be more clear to be a = higher level negotiation routine, maybe ldap_sasl_gss_spnego_bind_s(). However, one issue I have with this code is that highly dependent = behaviors which, aside from not be standardized, aren't even specified = in RFCs. For instance, there is no RFC describing dnsHostName or = ldapServiceName or any specification detailing how GSS-SPNEGO is to be = used in LDAP. Without a formal specification (e.g., RFC), I oppose = release of this code. That is, it should stay HEAD only until such time = that a formal specification (e.g., RFC) is available. I would assume GSS-SPNEGO is usable without these attributes. It seems = odd to me that this code requires them. I note that use of the SASL GSS-SPNEGO in LDAP has actually be = discouraged in IETF circles because SASL "GSS-SPNEGO" is itself not well = specified and multiple levels of negotiation leads to downgrade attacks. = The general consensus in the IETF seems that application protocol = clients (including LDAP clients) should use SASL mechanism negotiation = to select mechanisms, whether GSS API based mechanisms or non GSS API = based mechanisms. There is a general move on foot that all new SASL = mechanisms be described as GSS API mechanisms, ala SCRAM. -- Kurt=

1 0

Re: FW: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by gcarter＠likewise.com 02 Jun '10

02 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howard, We are trying to make likewise-open packages available for Fedora but they only want to pull OpenLDAP patches from upstream. So I'm in a bit of a spot here. You've already accepted the lsap_bind_gssapi patch, this one simply exposes the existing code. Is it just the public ldap_bind_gssapi_s() signature that you have an issue with? If, as you suggest, we give you a patch that adds an LDAP_AUTH_GSSAPI flag to ldap_bind_s() but keep the same (existing) ldap_bind_gssapi_s() internals, would that be acceptable? cheers, jerry - -- Director of Engineering http://www.likewise.com/ Likewise-CIFS http://www.likewiseopen.org/ "What man is a man who does not make the world better?" --Balian On 6/2/10 12:10 AM, Scott Salley wrote: > > > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: Tue 6/1/2010 6:07 PM > To: Scott Salley > Cc: openldap-its(a)openldap.org > Subject: Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s > > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: > http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… >> Submission from: (NULL) (67.51.54.234) >> >> >> Note that a similar issue/contribution was submitted in 2008 > (Contrib/5369) and >> appears to have been 'lost'. > >> The patch > http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… >> makes it possible to use the GSSAPI support in OpenLDAP by: >> >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >> >> 2. Exposing ldap_gssapi_bind_s in ldap.h > > I am still disinclined to publish any of this. The standard mechanism for > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more > non-standard one-off ldap_XXX_bind flavors. It's a poor design approach > and it > increases our support workload for no appreciable gain. It increases > application developer's workload as well, if they have to test for the > existence of multiple flavors of ldap_XXX_bind and code for them each > separately in their apps. > > If you really want to have "direct" access to other authentication > mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions that can > be muxed out from a single ldap_bind API. Of course, by the time you've > implemented option parsing so that generic client code can be configured > with > arbitrary Bind mechanisms, you would have re-implemented SASL. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMBj/7IR7qMdg1EfYRAjmcAKC1MyKit8TKa1W96cZ2Uh3Cdm/EMACeJtbu 9/F8j8UQJ5C3X0sW5LytRq8= =tkYo -----END PGP SIGNATURE-----

1 0

Re: (ITS#6536) Autogroup overlay enhancement
by raphael.ouazana＠linagora.com 02 Jun '10

02 Jun '10

Le Mer 2 juin 2010 03:44, Howard Chu a écrit : > The code patch looks OK to me, but could you also provide a patch for the > README file summarizing this new behavior? I'm not too keen on supporting > groups of anything other than DNs in general, but I see the usefulness of > it. > However the potential performance hit can be quite a concern. Thank you for your feedback. Here is the patch of the README file: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-readme-1000602.pa… Regards, Raphaël Ouazana.

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by alexs＠ulgsm.ru 01 Jun '10

01 Jun '10

* alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2010-01-19 07:25:25 +0000]: > * alexs(a)ulgsm.ru <alexs(a)ulgsm.ru> [2009-11-05 07:43:02 +0000]: > > OpenLDAP 2.4.22, 8.1-PRERELEASE is still crashed. > > > New OpenLdapd 2.4.21 on new freebsd 8.0 is still crashed. > I can make a public test server, to let some one check my configs and > see faults. > > Also intresting have any body same failures? > > > > > > Full_Name: Aleksey > > Version: 2.4.19 > > OS: Freebsd7.2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (93.93.136.26) > > > > > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls > > Freebsd 7.2 amd64 > > Slapd built with the "-g" flag and install with the make install STRIP="" > > > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > > In slapd config added using hdb as backend and indexes. > > > > Testing database consist of 1000 users accounts with minimum attributes. > > > > On stress test load slapd Segmentation fault in 10-30 sec. > > > > > > #ldd /usr/local/libexec/slapd > > /usr/local/libexec/slapd: > > libldap_r-2.4.so.7 => /usr/local/lib/libldap_r-2.4.so.7 (0x80073b000) > > liblber-2.4.so.7 => /usr/local/lib/liblber-2.4.so.7 (0x800881000) > > libltdl.so.7 => /usr/local/lib/libltdl.so.7 (0x80098e000) > > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) > > libssl.so.5 => /usr/lib/libssl.so.5 (0x800ccf000) > > libcrypto.so.5 => /lib/libcrypto.so.5 (0x800e19000) > > libfetch.so.5 => /usr/lib/libfetch.so.5 (0x8010ab000) > > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x8011b9000) > > libcrypt.so.4 => /lib/libcrypt.so.4 (0x8012bb000) > > libwrap.so.5 => /usr/lib/libwrap.so.5 (0x8013d4000) > > libthr.so.3 => /lib/libthr.so.3 (0x8014dd000) > > libc.so.7 => /lib/libc.so.7 (0x8015f5000) > > > > > > > > > > #gdb /usr/local/libexec/slapd > > (gdb) run -d 0 > > Starting program: /usr/local/libexec/slapd -d 0 > > [New LWP 100311] > > [New Thread 0x801a020b0 (LWP 100311)] > > [New Thread 0x801a02880 (LWP 100073)] > > [New Thread 0x8034040b0 (LWP 100076)] > > [New Thread 0x803404240 (LWP 100077)] > > [New Thread 0x8034043d0 (LWP 100078)] > > [New Thread 0x803404560 (LWP 100116)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 > > 511 { > > (gdb) > > (gdb) > > (gdb) where > > #0 0x0000000802d5aa4b in hdb_idl_fetch_key (be=Error accessing memory > > address 0x7ffffd9f9f38: dress. > > ) at idl.c:511 > > #1 0x0000000802d50dc5 in hdb_key_read (be=0x801a853d0, db=0x803519800, > > txn=0x80352b040, k=0x8069005 > > 70, ids=0x806a00000, saved_cursor=0x0, get_flag=0) at key.c:50 > > #2 0x0000000802d5363c in equality_candidates (op=0x803521000, rtxn=0x80352b040, > > ava=0x7ffffda7a4f0, > > ids=0x806c00000, tmp=0x806a00000) at filterindex.c:788 > > #3 0x0000000802d51d10 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a550, > > ids=0x806c00000, tmp=0x806a00000, stack=0x806d00000) at filterindex.c:154 > > #4 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=161, ids=0x806b00000, tmp=0x806a00000, save=0x806c00000) at > > filterindex.c:581 > > #5 0x0000000802d5229c in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a530, > > ids=0x806b00000, tmp=0x806a00000, stack=0x806c00000) at filterindex.c:204 > > #6 0x0000000802d5297f in list_candidates (op=0x803521000, rtxn=0x80352b040, > > flist=0x7ffffda7a5 f > > type=160, ids=0x7ffffdafa760, tmp=0x806a00000, save=0x806b00000) at > > filterindex.c:581 > > #7 0x0000000802d521e4 in hdb_filter_candidates (op=0x803521000, > > rtxn=0x80352b040, f=0x7ffffda7a570, > > ids=0x7ffffdafa760, tmp=0x806a00000, stack=0x806b00000) at filterindex.c: > > #8 0x0000000802d4dca9 in search_candidates (op=0x803521000, rs=0x7ffffdbfab30, > > e=0x7ffffda7a71 tx > > n=0x80352b040, ids=0x7ffffdafa760, scopes=0x7ffffda7a760) at search.c:1206 > > #9 0x0000000802d4befa in hdb_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:586 > > #10 0x0000000000439bb5 in fe_op_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:366 > > #11 0x0000000000439520 in do_search (op=0x803521000, rs=0x7ffffdbfab30) at > > search.c:217 > > #12 0x000000000043613d in connection_operation (ctx=0x7ffffdbfac70, > > arg_v=0x803521000) at connection > > .c:1123 > > #13 0x00000000004366d9 in connection_read_thread (ctx=0x7ffffdbfac70, argv=0x12) > > at connection.c:125 > > 9 > > #14 0x0000000800797052 in ldap_int_thread_pool_wrapper () from > > /usr/local/lib/libldap_r-2.4.so. > > #15 0x000000080164b4d1 in pthread_getprio () from /lib/libthr.so.3 > > #16 0x0000000000000000 in ?? () > > Error accessing memory address 0x7ffffdbfb000: Bad address. -- alexs

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by Kurt＠OpenLDAP.org 01 Jun '10

01 Jun '10

On Jun 2, 2010, at 1:08 AM, hyc(a)symas.com wrote: > ssalley(a)likewise.com wrote: >> Full_Name: Scott Salley >> Version: HEAD >> OS: Linux >> URL: = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> Submission from: (NULL) (67.51.54.234) >>=20 >>=20 >> Note that a similar issue/contribution was submitted in 2008 = (Contrib/5369) and >> appears to have been 'lost'. >=20 >> The patch = http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-def= ine-have-gssapi.patch >> makes it possible to use the GSSAPI support in OpenLDAP by: >>=20 >> 1. Defining --with-gssapi in configure which >> a. Checks for appropriate header files >> b. Checks for the appropriate library >> c. Defines HAVE_GSSAPI to 1 in everything is in order >>=20 >> 2. Exposing ldap_gssapi_bind_s in ldap.h >=20 > I am still disinclined to publish any of this. The standard mechanism = for=20 > using GSSAPI in LDAP is via SASL. I see no benefit to propagating more=20= > non-standard one-off ldap_XXX_bind flavors. It's a poor design = approach and it=20 > increases our support workload for no appreciable gain. It increases=20= > application developer's workload as well, if they have to test for the=20= > existence of multiple flavors of ldap_XXX_bind and code for them each=20= > separately in their apps. I concur and add: At one time I thought it might be useful to implement = a few SASL mechanisms directly in libldap for cases where one didn't = want to suck in a SASL library. But for most mechanisms removing the = SASL library is worth it in my eyes, especially any mechanism other than = PLAIN or EXTERNAL. But where this is worth it, it should be done = through existing APIs. Adding mech specific APIs should be avoided. >=20 > If you really want to have "direct" access to other authentication = mechanisms, > the right way to do this is by adding new LDAP_AUTH_xxx definitions = that can=20 > be muxed out from a single ldap_bind API. I could see adding new API to support new authentication frameworks to = which LDAP was extended to support. For instance, if LDAP was extended = to directly support GSS API mechanisms, then adding LDAP_AUTH_GSSAPI = would make sense (here GSS API refers to the GSS API not the SASL = Kerberos mechanism called GSSAPI). But for security reasons, it = unlikely this will ever happen, =20 > Of course, by the time you've=20 > implemented option parsing so that generic client code can be = configured with=20 > arbitrary Bind mechanisms, you would have re-implemented SASL. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >=20 >=20

1 0

Re: (ITS#6536) Autogroup overlay enhancement
by hyc＠symas.com 01 Jun '10

01 Jun '10

raphael.ouazana(a)linagora.com wrote: > Full_Name: Raphael Ouazana > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch > Submission from: (NULL) (213.41.232.151) > > > Hi, > > The attached patch allow the autogroup overlay to handle correctly the attr part > of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the > attr part was simply ignored. Now the group entry is populated by the values of > the attribute attr in the resulting entries. > > Implementation details: > Some cases (modify, delete) are harder to handle when you store values instead > of dn. In this cases the overlay try to detect if groups have been modified and > then simply refresh them. This can cause performance hits if the search > specified by the URL deals with an important number of entries. > > Legal notice: > This patch file is derived from OpenLDAP Software. All of the modifications to > OpenLDAP Software represented in this following patch were developed by Raphael > Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to > any > license of Linagora. > > The attached modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2010 Raphael Ouazana, Linagora > Redistribution and use in source and binary forms, with or without > modification, > are permitted only as authorized by the OpenLDAP Public License. The code patch looks OK to me, but could you also provide a patch for the README file summarizing this new behavior? I'm not too keen on supporting groups of anything other than DNs in general, but I see the usefulness of it. However the potential performance hit can be quite a concern. -- -- 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#6569) patch: Set ld_errno on error.
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Ubuntu > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… > Submission from: (NULL) (67.51.54.234) > > > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… > ensures ld_errno is set to an error when there is no valid result. > Thanks for the report. Actually the Notice of Disconnect comes with an error code from the server, and that's actually what should be returned to the client here. Fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6568) patch: Memory leak in connectionless
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Ubuntu > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… > Submission from: (NULL) (67.51.54.234) > > > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… > closes memory leaks associated with using connectionless mode. > Thanks for the patch, applied to HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by hyc＠symas.com 01 Jun '10

01 Jun '10

ssalley(a)likewise.com wrote: > Full_Name: Scott Salley > Version: HEAD > OS: Linux > URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > Submission from: (NULL) (67.51.54.234) > > > Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and > appears to have been 'lost'. > The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… > makes it possible to use the GSSAPI support in OpenLDAP by: > > 1. Defining --with-gssapi in configure which > a. Checks for appropriate header files > b. Checks for the appropriate library > c. Defines HAVE_GSSAPI to 1 in everything is in order > > 2. Exposing ldap_gssapi_bind_s in ldap.h I am still disinclined to publish any of this. The standard mechanism for using GSSAPI in LDAP is via SASL. I see no benefit to propagating more non-standard one-off ldap_XXX_bind flavors. It's a poor design approach and it increases our support workload for no appreciable gain. It increases application developer's workload as well, if they have to test for the existence of multiple flavors of ldap_XXX_bind and code for them each separately in their apps. If you really want to have "direct" access to other authentication mechanisms, the right way to do this is by adding new LDAP_AUTH_xxx definitions that can be muxed out from a single ldap_bind API. Of course, by the time you've implemented option parsing so that generic client code can be configured with arbitrary Bind mechanisms, you would have re-implemented SASL. -- -- 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#6569) patch: Set ld_errno on error.
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-set-… ensures ld_errno is set to an error when there is no valid result.

1 0

(ITS#6568) patch: Memory leak in connectionless
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Ubuntu URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… Submission from: (NULL) (67.51.54.234) The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-fix-… closes memory leaks associated with using connectionless mode.

1 0

(ITS#6567) Enable GSSAPI support and expose ldap_gssadpi_bind_s
by ssalley＠likewise.com 01 Jun '10

01 Jun '10

Full_Name: Scott Salley Version: HEAD OS: Linux URL: http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… Submission from: (NULL) (67.51.54.234) Note that a similar issue/contribution was submitted in 2008 (Contrib/5369) and appears to have been 'lost'. The patch http://archives.likewiseopen.org/~ssalley/OpenLDAP/scott-salley-100601-defi… makes it possible to use the GSSAPI support in OpenLDAP by: 1. Defining --with-gssapi in configure which a. Checks for appropriate header files b. Checks for the appropriate library c. Defines HAVE_GSSAPI to 1 in everything is in order 2. Exposing ldap_gssapi_bind_s in ldap.h

1 0

(ITS#6566) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR
by mhardin＠symas.com 01 Jun '10

01 Jun '10

Full_Name: Matt Hardin Version: 2.4.22 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141) rwm, ppolicy, sssvlv, and valsort display warnings on STDERR, not syslog. It seems these warnings should go into syslog instead.

1 0

Re: (ITS#6565) DNSSRV referrals: chaining without search base
by masarati＠aero.polimi.it 01 Jun '10

01 Jun '10

> Hi, > this is a partly duplicate of ITS 6463: I think it's better to split > these 2 > items into 2 separate ITS. > > This ITS only describes the behaviour of OpenLDAP using referrals > generated by > DNSSRV; just ldap (no ldaps) is used. > > You stated that not returning DNs in DNSSRV "conforms to RFC4511". This > seems to > be OK. Nevertheless these returned URLs are used in the chaining code. > > This means that the chained search always searches with base "" (root). I > don't > think that this the right behavior. > > I debugged the code several hours but couldn't find a solution. What I > could > see: > - dnssrv_back_referrals just puts server names into the referral structure > ("ref") > - the functions called afterwards - esp. ldap_chain_op - parse this > structure > "ref" for server names AND DNs (search bases) > > I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose > a > solution. But I think that this should be fixed: Chained Searches with "" > as > search base in a distributed environment can't really work: problems like > - some servers don't support this kind of search > - loop detection > - access control > are there. Hi. I don't have time to work at this right now, but I think the solution would be to modify slapo-chain(5) so that when a referral's DN is "" and the DN in the original request is not "", to use that DN instead. The original request DN can be found in op->o_req_dn. p.

1 0

(ITS#6565) DNSSRV referrals: chaining without search base
by jochen＠keutel.de 01 Jun '10

01 Jun '10

Full_Name: Jochen Keutel Version: 2.4.22 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.159.200.236) Hi, this is a partly duplicate of ITS 6463: I think it's better to split these 2 items into 2 separate ITS. This ITS only describes the behaviour of OpenLDAP using referrals generated by DNSSRV; just ldap (no ldaps) is used. You stated that not returning DNs in DNSSRV "conforms to RFC4511". This seems to be OK. Nevertheless these returned URLs are used in the chaining code. This means that the chained search always searches with base "" (root). I don't think that this the right behavior. I debugged the code several hours but couldn't find a solution. What I could see: - dnssrv_back_referrals just puts server names into the referral structure ("ref") - the functions called afterwards - esp. ldap_chain_op - parse this structure "ref" for server names AND DNs (search bases) I'm sorry, my knowledge of the OpenLDAP code is not deep enough to propose a solution. But I think that this should be fixed: Chained Searches with "" as search base in a distributed environment can't really work: problems like - some servers don't support this kind of search - loop detection - access control are there. Regards, Jochen.

1 0

ITS#6564
by masarati＠aero.polimi.it 28 May '10

28 May '10

Is this a joke or what? Version 2.2.23 was released about 2005 (as stated by the log message you report). The current release is 2.4.22. The LDIF you're reporting dn: dc=HVRNG1,dc=com objectclass: dcObject objectclass: comanization o: Domain Server dc: HVRNG1 dn: cn=root,dc=HVRNG1,dc=com objectclass: comanizationalRole cn: root clearly contains a typo (twice), assuming by "comanization" you mean "organization". You need to leave one blank like between entries. In any case, the ITS is intended to report software bugs; usage questions should be directed to openldap-technical(a)openldap.org (you need to subscribe first). This ITS will be closed. p.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 28 May '10

28 May '10

I now have a fully patched (with the stuff on the oracle/sleepycat) build with db-4.6.21, and it seems to be working correctly with the patches. You can close the its, sorry for the noise and thanks for the help.

1 0

(ITS#6564) Problem of parsing
by herve.gouyet＠free.fr 28 May '10

28 May '10

Full_Name: herve gouyet Version: vendredi 21 octobre 2005, 16:04:16 OS: Windows XP PRO URL: Submission from: (NULL) (82.241.150.119) I don't know the version but its probably the last (i try to install openLdap this week). slapd.exe : $OpenLDAP: slapd 2.2.29 (Oct 21 2005 16:01:14) $ My problem is that i receive the message slapadd : could not parse entry when i run "slapadd -f slapd.conf -l init.ldif". I try to had or remove blanks everywhere. Everytime it's the same error, line number = the last line +1 I search on google, but all propositions found give the same result. My last try of init.ldif --------------------------- dn: dc=HVRNG1,dc=com objectclass: dcObject objectclass: comanization o: Domain Server dc: HVRNG1 dn: cn=root,dc=HVRNG1,dc=com objectclass: comanizationalRole cn: root my ldap.conf ------------------- # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ucdata-path ./ucdata include ./schema/core.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:/root.openldap.org pidfile ./run/slapd.pid argsfile ./run/slapd.args # Load dynamic backend modules: # modulepath ./libexec/openldap # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=HVRNG1,dc=com" rootdn "cn=Manager,dc=HVRNG1,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory ./data # Indices to maintain index objectClass eq Thanks Hervé GOUYET

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 27 May '10

27 May '10

On Thu, May 27, 2010 at 8:43 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wr= ote: > Is that BDB 4.6.21 with or without the patches from Sleepycat/Oracle? =C2= =A0IIRC > they are required to be in place to have a functioning BDB build. > This is straight 4.6.21 without the oracle patches. I am working on building a new package with the patches. I will report back if a patched BDB fixes the problems.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by quanah＠zimbra.com 27 May '10

27 May '10

--On Wednesday, May 26, 2010 10:54 PM -0700 Aravind Gottipati=20 <aravind(a)freeshell.org> wrote: > On Wed, May 26, 2010 at 8:38 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> > wrote: >> You should use db_recover from the appropriate bdb release to clean them >> up. =C2=A0Not ipcrm. =C2=A0You also fail to note which version of BDB = you are >> linked against. =C2=A0I've certainly never seen this issue. > > I am using Berkeley DB 4.6.21. > > I didn't think to use a db_recover right after slapadd was done since > I assumed that it would be a clean database. When slapd didn't start, > I did try a db_recover, but it didn't help. Is that BDB 4.6.21 with or without the patches from Sleepycat/Oracle? IIRC = they are required to be in place to have a functioning BDB build. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 27 May '10

27 May '10

Hi, I have run slapd in valgrind now. The full log kan be found here: http://pastebin.de/6914 In short, valgrind reported following error: =20 =3D15353=3D=3D 1 errors in context 1 of 5: =3D=3D15353=3D=3D Invalid write of size 4 =3D=3D15353=3D=3D at 0x80E64B5: slap_sl_free (sl_malloc.c:492) =3D=3D15353=3D=3D by 0x80A0EEA: ch_free (ch_malloc.c:137) =3D=3D15353=3D=3D by 0x80E3DC9: mra_free (mra.c:43) =3D=3D15353=3D=3D by 0x80855B0: filter_free_x (filter.c:556) =3D=3D15353=3D=3D by 0x80836CD: do_search (search.c:230) =3D=3D15353=3D=3D by 0x8080588: connection_operation (connection.c:1109) =3D=3D15353=3D=3D by 0x403B376: ldap_int_thread_pool_wrapper (tpool.c:68= 5) =3D=3D15353=3D=3D by 0x43046E4: start_thread (in /lib/libpthread-2.10.1.= so) =3D=3D15353=3D=3D by 0x43045FF: ??? (in /lib/libpthread-2.10.1.so) =3D=3D15353=3D=3D Address 0x843692b1 is not stack'd, malloc'd or (recently= ) free'd -Dieter --=20 Dieter Kl=C3=BCnter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 26 May '10

26 May '10

On Wed, May 26, 2010 at 8:38 PM, Quanah Gibson-Mount <quanah(a)zimbra.com> wr= ote: > You should use db_recover from the appropriate bdb release to clean them = up. > =C2=A0Not ipcrm. =C2=A0You also fail to note which version of BDB you are= linked > against. =C2=A0I've certainly never seen this issue. I am using Berkeley DB 4.6.21. I didn't think to use a db_recover right after slapadd was done since I assumed that it would be a clean database. When slapd didn't start, I did try a db_recover, but it didn't help. Aravind.

1 0

Re: (ITS#6563) slapadd locks up shared memory segments
by quanah＠zimbra.com 26 May '10

26 May '10

--On Wednesday, May 26, 2010 10:45 PM +0000 aravind(a)freeshell.org wrote: > Full_Name: Aravind Gottipati > Version: 2.4.21 > OS: RHEL 5.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (63.245.220.240) > > > I have enabled shared memory in my slapd.conf file. With this setup, it > appears that slapadd does not release the shared memory segments once its > done. This prevents the ldap server from starting up after, because it > complains that these shared memory segments are in use. > > To reproduce: > With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. > Try to then start up slapd. > > Work around: > When you slapadd the database, turn off shared memory settings in the > slapd.conf file. Re-enable it after slapadd is done. > > I have tried cleaning up those segments with ipcrm, but ipcrm simply says > that the memory segments are already removed. Its lying to you, those > segments are still there (ipcs lists them). > > Please let me know if I can get any you any more information to help with > the troubleshooting. I am not sure if you'd see the same issues with a > bdb backend (I use hdb, but afaik they are pretty similar). You should use db_recover from the appropriate bdb release to clean them up. Not ipcrm. You also fail to note which version of BDB you are linked against. I've certainly never seen this issue. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 26 May '10

26 May '10

A new patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-26-add-if-not-p…> It includes support for SLAP_MOD_SOFTDEL (see discussion here <http://www.openldap.org/lists/openldap-devel/201005/msg00003.html>). p.

1 0

(ITS#6563) slapadd locks up shared memory segments
by aravind＠freeshell.org 26 May '10

26 May '10

Full_Name: Aravind Gottipati Version: 2.4.21 OS: RHEL 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.245.220.240) I have enabled shared memory in my slapd.conf file. With this setup, it appears that slapadd does not release the shared memory segments once its done. This prevents the ldap server from starting up after, because it complains that these shared memory segments are in use. To reproduce: With shm_key enabled in the slapd.conf file, slapdd a (hdb) database. Try to then start up slapd. Work around: When you slapadd the database, turn off shared memory settings in the slapd.conf file. Re-enable it after slapadd is done. I have tried cleaning up those segments with ipcrm, but ipcrm simply says that the memory segments are already removed. Its lying to you, those segments are still there (ipcs lists them). Please let me know if I can get any you any more information to help with the troubleshooting. I am not sure if you'd see the same issues with a bdb backend (I use hdb, but afaik they are pretty similar).

1 0

(ITS#6562) nssov in OpenLDAP 2.4.22 doesn't build
by fahadsadah＠gmail.com 26 May '10

26 May '10

Full_Name: Fahad Sadah Version: 2.4.22 OS: Debian Squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.31.135.30) Chris Breneman recently filed a bug (#6488, http://www.openldap.org/its/index.cgi?findid=6488) about nssov, and submitted a patch. The patch was correctly applied in CVS. In release 2.4.22, most of the code has Chris' patch applied, but one file, network.c, isn't patched. This is stopping nssov from building.

1 0

Re: (ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 25 May '10

25 May '10

A patch is available here <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-05-25-add-if-not-p…> p.

1 0

(ITS#6561) Add-if-not-present
by masarati＠aero.polimi.it 25 May '10

25 May '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.141.24) Submitted by: ando I need to implement a modify operation whose semantics is "add if not present", an add that only takes place if that attribute is not yet present in the entry. I need it as an internal operation, so right now I wouldn't bother formalizing it as an extension of the semantics of the modify operation. Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an attribute value only if that value is not already present. See <http://www.openldap.org/lists/openldap-devel/201005/msg00000.html> for discussion. I have introduced a SLAP_MOD_ADD_IF_NOT_PRESENT flag and added code to support it in back-bdb/hdb. It works as intended. I plan to extend its support to all backends and overlays. p.

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 25 May '10

25 May '10

--On Friday, April 30, 2010 1:23 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > quanah(a)zimbra.com writes: >> Actually, the issue seems to be name changes in the header files under >> BSD. This causes TIOCNOTTY to end up being undefined. > > That would not give the error message shown in > <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021. > html>: > > build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libr > aries/liblutil/detach.c:131:7: error: missing binary operator before > token "long" > > Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is > undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY > somewhere is defined to expand to an expression involving a (long) cast. Apprently so. <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259.html> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#6557 published: SECURITY: About Referrals and BIND
by openldap-its＠OpenLDAP.org 25 May '10

25 May '10

Private ITS#6557 is now publicly readable URL: http://www.OpenLDAP.org/its/?findid=6557

1 0

Re: (ITS#6551) wrapping lines option
by masarati＠aero.polimi.it 24 May '10

24 May '10

> this is a feature request for making wrapping optional. Duplicate of ITS#6149; see related discussion. p.

1 0

Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it 24 May '10

24 May '10

> On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote: > >> Isn't ldif-filter supposed to deal with this? Probably, test043 needs >> to >> sort entries (-s bdb=a,hdb=a). > > Yes, Thanks. > > Here is a patch: Works for me, but I can't check using windows. I'd commit it, pending verification. Thanks, p. > Index: test043-delta-syncrepl > =================================================================== > RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v > retrieving revision 1.1.1.5 > diff -r1.1.1.5 test043-delta-syncrepl > 342c342 > < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $MASTEROUT | grep -iv "^auditcontext:" > >> $MASTERF > LT > 344c344 > < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT > --- >> $LDIFFILTER -s bdb=a,hdb=a < $SLAVEOUT | grep -iv "^auditcontext:" > >> $SLAVEFLT > > >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Windows 7 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> test043 fails under Windows because the contextCSN attribute for the >>> entry >>> dc=example,dc=com are returned in different places within the entry for >>> the >>> producer and consumer. To wit: >>> >>> server1.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> hasSubordinates: TRUE >>> >>> >>> >>> server2.flt- >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100518161938Z >>> entryCSN: 20100518161938.140191Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100518161938Z >>> contextCSN: 20100518162026.443250Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> hasSubordinates: TRUE >>> >>> >>> While this is not a problem in operation, and is not specifically a bug >>> according to the RFCs, test043 nonetheless fails because it expects an >>> exact >>> match in the ordering between the producer and consumer. It's not clear >>> whether >>> the desired fix is in slapd or in the test itself. >>> >>> This test does not fail on any other platforms with which we are >>> currently >>> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related >>> to >>> ITS#6549, which is now fixed (thanks Ando!). >>> >>> >>> >>> >> >> > > >

1 0

Re: (ITS#6553) Test043 oddities under Windows
by mhardin＠symas.com 24 May '10

24 May '10

On May 23, 2010, at 9:57 AM, masarati(a)aero.polimi.it wrote: > Isn't ldif-filter supposed to deal with this? Probably, test043 needs = to > sort entries (-s bdb=3Da,hdb=3Da). Yes, Thanks. Here is a patch: Index: test043-delta-syncrepl =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /var/CVSROOT/ldap24/tests/scripts/test043-delta-syncrepl,v retrieving revision 1.1.1.5 diff -r1.1.1.5 test043-delta-syncrepl 342c342 < $LDIFFILTER < $MASTEROUT | grep -iv "^auditcontext:" > $MASTERFLT --- > $LDIFFILTER -s bdb=3Da,hdb=3Da < $MASTEROUT | grep -iv = "^auditcontext:" > $MASTERF LT 344c344 < $LDIFFILTER < $SLAVEOUT | grep -iv "^auditcontext:" > $SLAVEFLT --- > $LDIFFILTER -s bdb=3Da,hdb=3Da < $SLAVEOUT | grep -iv "^auditcontext:" = > $SLAVEFLT >=20 > p. >=20 >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >>=20 >>=20 >> test043 fails under Windows because the contextCSN attribute for the = entry >> dc=3Dexample,dc=3Dcom are returned in different places within the = entry for >> the >> producer and consumer. To wit: >>=20 >> server1.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 = $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >> creatorsName: cn=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> hasSubordinates: TRUE >>=20 >>=20 >>=20 >> server2.flt- >>=20 >> dn: dc=3Dexample,dc=3Dcom >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 = $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 >> creatorsName: cn=3DManager,dc=3Dexample,dc=3Dcom >> createTimestamp: 20100518161938Z >> entryCSN: 20100518161938.140191Z#000000#000#000000 >> modifiersName: cn=3DManager,dc=3Dexample,dc=3Dcom >> modifyTimestamp: 20100518161938Z >> contextCSN: 20100518162026.443250Z#000000#000#000000 >> entryDN: dc=3Dexample,dc=3Dcom >> subschemaSubentry: cn=3DSubschema >> hasSubordinates: TRUE >>=20 >>=20 >> While this is not a problem in operation, and is not specifically a = bug >> according to the RFCs, test043 nonetheless fails because it expects = an >> exact >> match in the ordering between the producer and consumer. It's not = clear >> whether >> the desired fix is in slapd or in the test itself. >>=20 >> This test does not fail on any other platforms with which we are = currently >> working (HP-UX, Linux, Solaris, AIX), nor does it appear to be = related to >> ITS#6549, which is now fixed (thanks Ando!). >>=20 >>=20 >>=20 >>=20 >=20 >=20

1 0

Re: (ITS#6560) Samba4 OpenLDAP backend
by masarati＠aero.polimi.it 24 May '10

24 May '10

> Full_Name: Nitin Bhadauria > Version: OpenLDAP 2.X-Devel > OS: Ubuntu 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (119.82.72.226) > > > I am try to configure Samba4 with OpenLDAP and while setup provision... > > Using Following doc: > > http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP > > I got this error in messages logs. > > May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at > 7ffffffb > ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000] > May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0 Please read this <http://www.openldap.org/faq/data/cache/56.html> and act accordingly. p.

1 0

Re: (ITS#6559) About Referrals and BIND
by quanah＠zimbra.com 24 May '10

24 May '10

--On Monday, May 24, 2010 3:39 AM +0000 jet(a)hf.webex.com wrote: > Full_Name: Jet Du > Version: openldap-2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (61.191.27.34) > > > Because there are some typo in some description of (ITS#6558). So, I > submit a new ITS as below. > > There are two openLDAP Directory. > > 10.224.39.165 openLDAP has suffix dc=cisco,dc=com > 10.224.39.172 openLDAP has suffix dc=webex,dc=com > > In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: > referral ldap://10.224.39.165:389/ > > Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like > following: > lc.connect("10.224.39.172", 389); > lc.bind(LDAPConnection.LDAP_V3, > "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", > "pass".getBytes("UTF8")); > > But, I can not BIND successfully. Exception like below: > Connect ERRORLDAPException: Invalid Credentials (49) Invalid > Credentials LDAPException: Matched DN: ...... > > How to do BIND based on Referral? Thanks ... Two things: (a) Don't submit a new ITS because you typoed on the previous one. Just follow up to it. (b) Don't submit ITSes for software usage questions. Use the openldap-technical(a)openldap.org software list. The ITS system is for reporting bugs found in the software. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6560) Samba4 OpenLDAP backend
by bhadauria.nitin＠gmail.com 24 May '10

24 May '10

Full_Name: Nitin Bhadauria Version: OpenLDAP 2.X-Devel OS: Ubuntu 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.82.72.226) I am try to configure Samba4 with OpenLDAP and while setup provision... Using Following doc: http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP I got this error in messages logs. May 24 06:12:08 ubuntu kernel: [171547.545660] slapd[8141]: segfault at 7ffffffb ip 004b7e91 sp bffd8148 error 4 in libc-2.11.1.so[448000+153000] May 24 06:15:51 ubuntu slapd[8159]: rdnval: repaired=0

1 0

(ITS#6559) About Referrals and BIND
by jet＠hf.webex.com 23 May '10

23 May '10

Full_Name: Jet Du Version: openldap-2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.191.27.34) Because ther are some typo in some description of (ITS#6558). So, I submit a new ITS as below. There are two openLDAP Directory. 10.224.39.165 openLDAP has suffix dc=cisco,dc=com 10.224.39.172 openLDAP has suffix dc=webex,dc=com In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: referral ldap://10.224.39.165:389/ Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like following: lc.connect("10.224.39.172", 389); lc.bind(LDAPConnection.LDAP_V3, "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8")); But, I can not BIND successfully. Exception like below: Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Matched DN: ...... How to do BIND based on Referral? Thanks ...

1 0

(ITS#6558) About Referrals and BIND
by jet＠hf.webex.com 23 May '10

23 May '10

Full_Name: Jet Du Version: openldap-2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.191.27.34) There are two openLDAP Directory. 10.224.39.165 openLDAP has suffix dc=cisco,dc=webex 10.224.39.172 openLDAP has suffix dc=webex,dc=webex In 10.224.39.172 OpenLDAP, I configure referral in slapd.conf like below: referral ldap://10.224.39.165:389/ Connect 10.224.39.172 to BIND entry existing in 10.224.39.165. Code like following: lc.connect("10.224.39.172", 389); lc.bind(LDAPConnection.LDAP_V3, "uid=xxx(a)hf.cisco.com,ou=People,dc=cisco,dc=com", "pass".getBytes("UTF8")); But, I can not BIND successfully. Exception like below: Connect ERRORLDAPException: Invalid Credentials (49) Invalid Credentials LDAPException: Matched DN: ...... How to do BIND based on Referral? Thanks ...

1 0

Re: (ITS#6553) Test043 oddities under Windows
by masarati＠aero.polimi.it 23 May '10

23 May '10

Isn't ldif-filter supposed to deal with this? Probably, test043 needs to sort entries (-s bdb=a,hdb=a). p. > Full_Name: Matt Hardin > Version: 2.4.22 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.117.141) > > > test043 fails under Windows because the contextCSN attribute for the entry > dc=example,dc=com are returned in different places within the entry for > the > producer and consumer. To wit: > > server1.flt- > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100518161938Z > entryCSN: 20100518161938.140191Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100518161938Z > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > contextCSN: 20100518162026.443250Z#000000#000#000000 > hasSubordinates: TRUE > > > > server2.flt- > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100518161938Z > entryCSN: 20100518161938.140191Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100518161938Z > contextCSN: 20100518162026.443250Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > hasSubordinates: TRUE > > > While this is not a problem in operation, and is not specifically a bug > according to the RFCs, test043 nonetheless fails because it expects an > exact > match in the ordering between the producer and consumer. It's not clear > whether > the desired fix is in slapd or in the test itself. > > This test does not fail on any other platforms with which we are currently > working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to > ITS#6549, which is now fixed (thanks Ando!). > > > >

1 0

(ITS#6556) test031 core dumps after applying first filter
by dieter＠dkluenter.de 23 May '10

23 May '10

Full_Name: Dieter Kluenter Version: HEAD OS: openSuSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.11.71) I have enabled slapd-modules/comp_match and properly installed all relevant files to tests/data/comp_libs. When running test031, slapd segfaults: Running ./scripts/test031-component-filter for bdb... running defines.sh Running slapadd to build slapd database... Running slapindex to index slapd database... Starting slapd on TCP/IP port 9011... Testing slapd searching... Testing Component Filter Match RFC3687 Certificate searching: f=(userCertificate:componentFilterMatch:=item:{ component "toBeSigned.serialNumber", rule allComponen tsMatch, value 0 }) ... f=(userCertificate:componentFilterMatch:=item:{ component "toBeSigned.version", rule allComponentsMat ch, value 2 }) ... ./scripts/test031-component-filter: Zeile 105: 5312 Speicherzugriffsfehler (Speicherabzug geschrieben) $SLA PD -f $ADDCONF -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 ldapsearch failed (255)! ./scripts/test031-component-filter: Zeile 110: kill: (5312) - Kein passender Prozess gefunden (gdb) core-file core Core was generated by `/home/dieter/build/openldap/servers/slapd/.libs/lt-slapd -s0 -f /home/dieter/bu'. Program terminated with signal 11, Segmentation fault. (gdb) file /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd Reading symbols from /home/dieter/build/openldap/servers/slapd/.libs/lt-slapd...done. (gdb) where #0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at sl_malloc.c:492 #1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137 #2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43 #3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at filter.c:556 #4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230 #5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at connection.c:1109 #6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at connection.c:1245 #7 0xb7f963b7 in ?? () #8 0xb7cf86e5 in ?? () (gdb) bt full #0 0x080e6525 in slap_sl_free (ptr=0x87ba173, ctx=0x89aa3c0) at sl_malloc.c:492 sh = 0x89aa3c0 size = 543520108 p = 0x87ba16f nextp = 0x28e116db tmpp = 0xb7119198 __PRETTY_FUNCTION__ = "slap_sl_free" #1 0x080a0f5b in ch_free (ptr=0x87ba173) at ch_malloc.c:137 ctx = 0x89aa3c0 #2 0x080e3e3a in mra_free (op=0x89adc80, mra=0x87ba218, freeit=1) at mra.c:43 No locals. #3 0x08085621 in filter_free_x (op=0x89adc80, f=0x87ba258, freeme=1) at filter.c:556 p = 0x8214680 next = 0x89adcac #4 0x0808373e in do_search (op=0x89adc80, rs=0xb71190c4) at search.c:230 base = {bv_len = 17, bv_val = 0x89aff28 "dc=example,dc=com"} siz = 0 off = 0 i = 0 #5 0x080805f9 in connection_operation (ctx=0xb7119198, arg_v=0x89adc80) at connection.c:1109 rc = 80 cancel = 0 op = 0x89adc80 rs = {sr_type = REP_RESULT, sr_tag = 101, sr_msgid = 2, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 2, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x8433e04 memctx = 0x89aa3c0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #6 0x08080b18 in connection_read_thread (ctx=0xb7119198, argv=0x11) at connection.c:1245 ---Type <return> to continue, or q <return> to quit--- rc = 0 cri = {op = 0x89adc80, func = 0, arg = 0x0, ctx = 0xb7119198, nullop = 0} s = 17 #7 0xb7f963b7 in ?? () No symbol table info available. #8 0xb7cf86e5 in ?? () No symbol table info available. (gdb) -Dieter

1 0

Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by hyc＠symas.com 21 May '10

21 May '10

ralf(a)OpenLDAP.org wrote: > Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu: >> Ralf Haferkamp wrote: >>> A fix is now in syncprov.c r1.312. Would be great if someone could >>> review it if it makes sense. Testing results look good so far. >> >> Not sure why this makes the difference. After all, mincsn will be set >> to the consumer's cookie, and any writes that occur during the >> refresh phase will naturally have an entryCSN greater than mincsn and >> still be queued. > That doesn't seem to be true for deletes of entries that have an entryCSN > less than the value from the cookie. What I did to reproduce the problem > was: > > 1. load provider with about 100 entries > 2. start consumer wait for it to get synced. > 3. stop consumer > 4. load more entries in to the provider (in my test case about 1000) > 5. restart consumer (the consumer will start a ldapsync session with a > cookie) > 6. use ldapdelete to delete in an entry for the initial 100 entries. > (those that have an entryCSN< csn provide in the cookie). This ldap > delete as to happened during the refresh part of the ldapsync session > (when the 1000 new entries are sent) > 7. watch it fail > > What happens is that when syncprov_op_mod() calls syncprov_matchops() it > tests the to be deleted entry against the syncrepl filter (which has the > entryCSN>=cookie filter prepended currently as we are in refresh). That > test fails because of the older entryCSN value. Because of that the > syncoperation will not be inserted into the smatches queue of the > opcookie and the delete will not get synched in the syncprov_op_response > callback (as the smatches queue is empty). > > (As a side note: Modification that happen during the refresh phase will > get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above > reasons. This doesn't cause any failure AFAICS but seemed wrong as well.) OK, that explanation makes sense. Just wanted to make sure we didn't regress on ITS#4622, which seems to be the last time these filters were tweaked. -- -- 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#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org 21 May '10

21 May '10

Am Freitag 21 Mai 2010 05:52:31 schrieb Howard Chu: > Ralf Haferkamp wrote: > > A fix is now in syncprov.c r1.312. Would be great if someone could > > review it if it makes sense. Testing results look good so far. > > Not sure why this makes the difference. After all, mincsn will be set > to the consumer's cookie, and any writes that occur during the > refresh phase will naturally have an entryCSN greater than mincsn and > still be queued. That doesn't seem to be true for deletes of entries that have an entryCSN less than the value from the cookie. What I did to reproduce the problem was: 1. load provider with about 100 entries 2. start consumer wait for it to get synced. 3. stop consumer 4. load more entries in to the provider (in my test case about 1000) 5. restart consumer (the consumer will start a ldapsync session with a cookie) 6. use ldapdelete to delete in an entry for the initial 100 entries. (those that have an entryCSN < csn provide in the cookie). This ldap delete as to happened during the refresh part of the ldapsync session (when the 1000 new entries are sent) 7. watch it fail What happens is that when syncprov_op_mod() calls syncprov_matchops() it tests the to be deleted entry against the syncrepl filter (which has the entryCSN>=cookie filter prepended currently as we are in refresh). That test fails because of the older entryCSN value. Because of that the syncoperation will not be inserted into the smatches queue of the opcookie and the delete will not get synched in the syncprov_op_response callback (as the smatches queue is empty). (As a side note: Modification that happen during the refresh phase will get synched as LDAP_SYNC_ADD instead of LDAP_SYNC_MODIFY for the above reasons. This doesn't cause any failure AFAICS but seemed wrong as well.)

1 0

Re: (ITS#6555) Syncprov (refreshAndPersist) loses deletes
by hyc＠symas.com 20 May '10

20 May '10

Ralf Haferkamp wrote: > A fix is now in syncprov.c r1.312. Would be great if someone could review it if > it makes sense. Testing results look good so far. > Not sure why this makes the difference. After all, mincsn will be set to the consumer's cookie, and any writes that occur during the refresh phase will naturally have an entryCSN greater than mincsn and still be queued. -- -- 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#6554) OpenLDAP + TLS multiple server certificates
by hyc＠symas.com 20 May '10

20 May '10

stepan.kipel(a)ab-group.biz wrote: > Full_Name: Stepan Kipel > Version: 2.4.19 > OS: Red Hat Enterprise Linux AS release 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.140.224.210) > > > In our network there are 2 servers running slapd, one is syncrepl-provider and > other is consumer. Both have identical IP address for LDAP requests and > configured in manner that when one goes down, second takes over (configured > externally, by routing). Also, TLS is configured and works transparently for > client machines (DNS resolves their "common" IP), but it`s hard to use their > Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We > decided to put up other interface on syncrepl-provider for replication purposes, > mapped another Domain Name on this interface and appended CA, server and private > server certs created for this Domain Names to files included by > TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf > file, respectively. We`ve tried to execute ldapsearch with two different > ldap.conf configs - for first and second domain name of the server, one works > and another - not? error looks like "TLS: hostname (first_srv_name) does not > match common name in certificate (second_srv_name)." > > The question is - can slapd server use more than 2 server certificates or we > should use another technology (tunneling, etc...) for encrypted syncrepl? > A server cert file and key file may only contain one item; that's a constraint from the underlying TLS library. You should not have needed to create a new CA for this situation. You should look at using a single server cert with a subjectAltName matching the the alternate interface name. The ITS is for bug reports, not for hetting help on using the software. This ITS will be closed. Use the -software mailing list. -- -- 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#6555) Syncprov (refreshAndPersist) loses deletes
by Ralf Haferkamp 20 May '10

20 May '10

A fix is now in syncprov.c r1.312. Would be great if someone could review it if it makes sense. Testing results look good so far.

1 0

(ITS#6555) Syncprov (refreshAndPersist) loses deletes
by ralf＠OpenLDAP.org 20 May '10

20 May '10

Full_Name: Ralf Haferkamp Version: HEAD/RE24 OS: SLES11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.42.18) Submitted by: ralf If entries are deleted on the provider during the refresh Phase of a "refreshAndPersist" sync session, those deletes won't get replicated to the provider. This only happens if the consumer provided a cookie with the search, i.e. after the consumer was restarted (not during the initial sync) and if there were changes since the last sync. I am working on a fix.

1 0

(ITS#6554) OpenLDAP + TLS multiple server certificates
by stepan.kipel＠ab-group.biz 20 May '10

20 May '10

Full_Name: Stepan Kipel Version: 2.4.19 OS: Red Hat Enterprise Linux AS release 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.140.224.210) In our network there are 2 servers running slapd, one is syncrepl-provider and other is consumer. Both have identical IP address for LDAP requests and configured in manner that when one goes down, second takes over (configured externally, by routing). Also, TLS is configured and works transparently for client machines (DNS resolves their "common" IP), but it`s hard to use their Domain Name for TLS syncrepl - DNS resolves IP, that is up on local machine. We decided to put up other interface on syncrepl-provider for replication purposes, mapped another Domain Name on this interface and appended CA, server and private server certs created for this Domain Names to files included by TLSCACertificateFile, TLSCertificateFile and TLSCertificateKey in slapd.conf file, respectively. We`ve tried to execute ldapsearch with two different ldap.conf configs - for first and second domain name of the server, one works and another - not? error looks like "TLS: hostname (first_srv_name) does not match common name in certificate (second_srv_name)." The question is - can slapd server use more than 2 server certificates or we should use another technology (tunneling, etc...) for encrypted syncrepl?

1 0

(ITS#6553) Test043 oddities under Windows
by mhardin＠symas.com 18 May '10

18 May '10

Full_Name: Matt Hardin Version: 2.4.22 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141) test043 fails under Windows because the contextCSN attribute for the entry dc=example,dc=com are returned in different places within the entry for the producer and consumer. To wit: server1.flt- dn: dc=example,dc=com dc: example objectClass: organization objectClass: domainRelatedObject objectClass: dcObject l: Anytown, Michigan st: Michigan o: Example, Inc. o: EX o: Ex. description: The Example, Inc. at Anytown postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com structuralObjectClass: organization entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20100518161938Z entryCSN: 20100518161938.140191Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20100518161938Z entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema contextCSN: 20100518162026.443250Z#000000#000#000000 hasSubordinates: TRUE server2.flt- dn: dc=example,dc=com dc: example objectClass: organization objectClass: domainRelatedObject objectClass: dcObject l: Anytown, Michigan st: Michigan o: Example, Inc. o: EX o: Ex. description: The Example, Inc. at Anytown postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com structuralObjectClass: organization entryUUID: 1602452e-3d10-4fb1-9d55-efb8c08ac643 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20100518161938Z entryCSN: 20100518161938.140191Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20100518161938Z contextCSN: 20100518162026.443250Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE While this is not a problem in operation, and is not specifically a bug according to the RFCs, test043 nonetheless fails because it expects an exact match in the ordering between the producer and consumer. It's not clear whether the desired fix is in slapd or in the test itself. This test does not fail on any other platforms with which we are currently working (HP-UX, Linux, Solaris, AIX), nor does it appear to be related to ITS#6549, which is now fixed (thanks Ando!).

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 18 May '10

18 May '10

> Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on = Windows in a little while. Back-ported to 2.4.22 and tested in Windows. Works. -Matt >=20 > Thanks! >=20 > -Matt >=20 > On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote: >=20 >>=20 >>> Indeed, syncprov_operational() is right: it duplicates the entry = only if >>> contextCSN is already present in the entry, and thus may need to be >>> updated. What's wrong is back-bdb, which gives up when the entry = does not >>> have e_private set appropriately, while it could do more to find out = about >>> the entry's subordinates. This may explain why in some cases the >>> attribute is present. This occurs whenever contextCSN is not = already >>> present in the entry. I'm preparing a fix for back-bdb. >>=20 >> Fixed in HEAD; please test. Thanks, p. >>=20 >=20

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 18 May '10

18 May '10

Hi Ando. I've tested on RHEL 4/5 x86 and all seems good. I'll test on = Windows in a little while. Thanks! -Matt On May 17, 2010, at 6:27 PM, masarati(a)aero.polimi.it wrote: >=20 >> Indeed, syncprov_operational() is right: it duplicates the entry only = if >> contextCSN is already present in the entry, and thus may need to be >> updated. What's wrong is back-bdb, which gives up when the entry = does not >> have e_private set appropriately, while it could do more to find out = about >> the entry's subordinates. This may explain why in some cases the >> attribute is present. This occurs whenever contextCSN is not already >> present in the entry. I'm preparing a fix for back-bdb. >=20 > Fixed in HEAD; please test. Thanks, p. >=20

1 0

Re: (ITS#6544) how to implement password policy
by masarati＠aero.polimi.it 17 May '10

17 May '10

The ITS is intended to track bugs; please direct usage questions to openldap-software(a)openldap.org. This ITS will be closed. p. > Full_Name: Devender Singh > Version: openldap 2.4.16 > OS: RHEL5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (122.177.190.226) > > > Hello Dear, > > Please let me know, how to implement ppolicy in > openldap2.4.16. I > am using RHEL5.4 > > I have followed below steps on installation time: > > ************************************************** > Installing BerkeleyDB > ************************************************** > 1) Create build_unix directory in /opt directory > 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory > 3) Goto /opt/build_unix directory > 4) gzip -d db-4.7.25.tar.gz > 5) tar xvf db-4.7.25.tar > 6) db-4.7.25/dist/configure > 7) make > 8) make install > 9) vi /root/.bash_profile > 10) Add below lines in .bash_profile of root user > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib > export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib > 11) Close existing PUTTY and start new PUTTY > ************************************************** > > Before Installation check the below packages: > #rpm �qa|grep openssl* > After the above command if you don�t find the all openssl packages than > install > them via yum command > ************************************************** > Installing OpenLDAP > ************************************************** > 1) Copy openldap-stable-20090411.tgz to /opt directory > 2) gunzip -c openldap-stable-20090411.tgz | tar xf - > 3) cd openldap-2.4.16 > 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include > -I/usr/local/ssl/include/openssl" > 5) export CPPFLAGS > 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib > -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib > -R/usr/local/ssl/lib" > 7) export LDFLAGS > 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib" > 9) export LD_LIBRARY_PATH > 10) ./configure > 11) make depend > 12) make > 13) make install > 14) vi /root/.bash_profile > 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export > PATH=$PATH:$HOME/bin:/usr/local/sbin) > 16) Close existing PUTTY and start new PUTTY > ************************************************** > > > Thanks in Advance. > > Regards, > Devender Singh > (+919818107222) > >

1 0

Re: (ITS#6546) Default olcRootDN of "cn=config" should be documented
by masarati＠aero.polimi.it 17 May '10

17 May '10

> While using the "cn=config" configuration, I found that "cn=config" is > also the > default olcRootDN. By just configuring a olcRootPW , login to the config > database is possible using "cn=config" and the configured olcRootPW. This > default should be documented in the admin guide, etc. Fixed in HEAD's slapd-config(5); may be worth mentioning in the admin guide as well. Thanks, p.

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> Indeed, syncprov_operational() is right: it duplicates the entry only if > contextCSN is already present in the entry, and thus may need to be > updated. What's wrong is back-bdb, which gives up when the entry does not > have e_private set appropriately, while it could do more to find out about > the entry's subordinates. This may explain why in some cases the > attribute is present. This occurs whenever contextCSN is not already > present in the entry. I'm preparing a fix for back-bdb. Fixed in HEAD; please test. Thanks, p.

1 0

Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> masarati(a)aero.polimi.it wrote: >> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS >> 5.2, >> for what it matters, and db-4.6.21, for what it matters), and it works >> fine if you explicitly ask for hasSubordinates, while this specific attr >> is not returned if you request '+'. The fact hasSubordinates does not >> appear means that the appropriate backend operational attrs hook was not >> called, or its value was ignored. > > Since hasSubordinates is a generated attribute, it would be filtered out > on > the consumer anyway. There's no reason to ever include it in replication > traffic. Indeed, syncprov_operational() is right: it duplicates the entry only if contextCSN is already present in the entry, and thus may need to be updated. What's wrong is back-bdb, which gives up when the entry does not have e_private set appropriately, while it could do more to find out about the entry's subordinates. This may explain why in some cases the attribute is present. This occurs whenever contextCSN is not already present in the entry. I'm preparing a fix for back-bdb. p. >> After a quick check, I figured out that bdb_hasSubordinates is passed a >> copy of the original entry, thus without bdb information, and >> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry >> instead of putting operational attrs in rs_operational_attrs in >> SlapReply. >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Red Hat AS 4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> In test043 the test database defines a root entry of dc=example,dc=com. >>> For this >>> entry, the results of the ldapsearch do not include the hasSubordinates >>> attribute at all, in spite of the fact that the entry does have >>> subordinates. >>> Test043 passes, due to the fact that this attribute is missing from the >>> root >>> entry in both the provider and the consumer. >>> >>> Other entries with subordinates do include this attribute and its value >>> is >>> correct in all the cases I examined. >>> >>> Here is the snippet from tests/testrun/server1.flt: >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100512194705Z >>> entryCSN: 20100512194705.076849Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100512194705Z >>> contextCSN: 20100512194748.621773Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> >>> The version of BDB in use here is 4.8.30, although I note this happens >>> with >>> earlier releases of BDB as well. >>> >>> Also of interest is the fact that this test fails on some platforms >>> (e.g. >>> Windows), because the provider slapd correctly reports >>> hasSubordinates=TRUE, >>> while the consumer omits the attribute entirely, in spite of the fact >>> that >>> subordinate entries do exist on the consumer. >>> >>> -Matt >>> >>> >>> >> >> >> >> > > > -- > -- 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#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

> masarati(a)aero.polimi.it wrote: >> I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS >> 5.2, >> for what it matters, and db-4.6.21, for what it matters), and it works >> fine if you explicitly ask for hasSubordinates, while this specific attr >> is not returned if you request '+'. The fact hasSubordinates does not >> appear means that the appropriate backend operational attrs hook was not >> called, or its value was ignored. > > Since hasSubordinates is a generated attribute, it would be filtered out > on > the consumer anyway. There's no reason to ever include it in replication > traffic. I'd concur, but syncprov_operational steps in even for regular operations (correctly, because a client might want to see the contextCSN), and duplicates the entry unnecessarily, as contextCSN could be appended to sr_operational_attrs, unless it needs to be in the entry for some reason. p. >> After a quick check, I figured out that bdb_hasSubordinates is passed a >> copy of the original entry, thus without bdb information, and >> bdb_hasSubordinates bails out. Apparently, syncprov copies the entry >> instead of putting operational attrs in rs_operational_attrs in >> SlapReply. >> >> p. >> >>> Full_Name: Matt Hardin >>> Version: 2.4.22 >>> OS: Red Hat AS 4 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (74.38.117.141) >>> >>> >>> In test043 the test database defines a root entry of dc=example,dc=com. >>> For this >>> entry, the results of the ldapsearch do not include the hasSubordinates >>> attribute at all, in spite of the fact that the entry does have >>> subordinates. >>> Test043 passes, due to the fact that this attribute is missing from the >>> root >>> entry in both the provider and the consumer. >>> >>> Other entries with subordinates do include this attribute and its value >>> is >>> correct in all the cases I examined. >>> >>> Here is the snippet from tests/testrun/server1.flt: >>> >>> dn: dc=example,dc=com >>> dc: example >>> objectClass: organization >>> objectClass: domainRelatedObject >>> objectClass: dcObject >>> l: Anytown, Michigan >>> st: Michigan >>> o: Example, Inc. >>> o: EX >>> o: Ex. >>> description: The Example, Inc. at Anytown >>> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >>> US >>> telephoneNumber: +1 313 555 1817 >>> associatedDomain: example.com >>> structuralObjectClass: organization >>> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >>> creatorsName: cn=Manager,dc=example,dc=com >>> createTimestamp: 20100512194705Z >>> entryCSN: 20100512194705.076849Z#000000#000#000000 >>> modifiersName: cn=Manager,dc=example,dc=com >>> modifyTimestamp: 20100512194705Z >>> contextCSN: 20100512194748.621773Z#000000#000#000000 >>> entryDN: dc=example,dc=com >>> subschemaSubentry: cn=Subschema >>> >>> The version of BDB in use here is 4.8.30, although I note this happens >>> with >>> earlier releases of BDB as well. >>> >>> Also of interest is the fact that this test fails on some platforms >>> (e.g. >>> Windows), because the provider slapd correctly reports >>> hasSubordinates=TRUE, >>> while the consumer omits the attribute entirely, in spite of the fact >>> that >>> subordinate entries do exist on the consumer. >>> >>> -Matt >>> >>> >>> >> >> >> >> > > > -- > -- 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#6549) test043 hasSubordinates attribute inconsistencies
by hyc＠symas.com 17 May '10

17 May '10

masarati(a)aero.polimi.it wrote: > I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2, > for what it matters, and db-4.6.21, for what it matters), and it works > fine if you explicitly ask for hasSubordinates, while this specific attr > is not returned if you request '+'. The fact hasSubordinates does not > appear means that the appropriate backend operational attrs hook was not > called, or its value was ignored. Since hasSubordinates is a generated attribute, it would be filtered out on the consumer anyway. There's no reason to ever include it in replication traffic. > After a quick check, I figured out that bdb_hasSubordinates is passed a > copy of the original entry, thus without bdb information, and > bdb_hasSubordinates bails out. Apparently, syncprov copies the entry > instead of putting operational attrs in rs_operational_attrs in SlapReply. > > p. > >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Red Hat AS 4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >> >> >> In test043 the test database defines a root entry of dc=example,dc=com. >> For this >> entry, the results of the ldapsearch do not include the hasSubordinates >> attribute at all, in spite of the fact that the entry does have >> subordinates. >> Test043 passes, due to the fact that this attribute is missing from the >> root >> entry in both the provider and the consumer. >> >> Other entries with subordinates do include this attribute and its value is >> correct in all the cases I examined. >> >> Here is the snippet from tests/testrun/server1.flt: >> >> dn: dc=example,dc=com >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >> creatorsName: cn=Manager,dc=example,dc=com >> createTimestamp: 20100512194705Z >> entryCSN: 20100512194705.076849Z#000000#000#000000 >> modifiersName: cn=Manager,dc=example,dc=com >> modifyTimestamp: 20100512194705Z >> contextCSN: 20100512194748.621773Z#000000#000#000000 >> entryDN: dc=example,dc=com >> subschemaSubentry: cn=Subschema >> >> The version of BDB in use here is 4.8.30, although I note this happens >> with >> earlier releases of BDB as well. >> >> Also of interest is the fact that this test fails on some platforms (e.g. >> Windows), because the provider slapd correctly reports >> hasSubordinates=TRUE, >> while the consumer omits the attribute entirely, in spite of the fact that >> subordinate entries do exist on the consumer. >> >> -Matt >> >> >> > > > > -- -- 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#6549) test043 hasSubordinates attribute inconsistencies
by masarati＠aero.polimi.it 17 May '10

17 May '10

I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS 5.2, for what it matters, and db-4.6.21, for what it matters), and it works fine if you explicitly ask for hasSubordinates, while this specific attr is not returned if you request '+'. The fact hasSubordinates does not appear means that the appropriate backend operational attrs hook was not called, or its value was ignored. After a quick check, I figured out that bdb_hasSubordinates is passed a copy of the original entry, thus without bdb information, and bdb_hasSubordinates bails out. Apparently, syncprov copies the entry instead of putting operational attrs in rs_operational_attrs in SlapReply. p. > Full_Name: Matt Hardin > Version: 2.4.22 > OS: Red Hat AS 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (74.38.117.141) > > > In test043 the test database defines a root entry of dc=example,dc=com. > For this > entry, the results of the ldapsearch do not include the hasSubordinates > attribute at all, in spite of the fact that the entry does have > subordinates. > Test043 passes, due to the fact that this attribute is missing from the > root > entry in both the provider and the consumer. > > Other entries with subordinates do include this attribute and its value is > correct in all the cases I examined. > > Here is the snippet from tests/testrun/server1.flt: > > dn: dc=example,dc=com > dc: example > objectClass: organization > objectClass: domainRelatedObject > objectClass: dcObject > l: Anytown, Michigan > st: Michigan > o: Example, Inc. > o: EX > o: Ex. > description: The Example, Inc. at Anytown > postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US > telephoneNumber: +1 313 555 1817 > associatedDomain: example.com > structuralObjectClass: organization > entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 > creatorsName: cn=Manager,dc=example,dc=com > createTimestamp: 20100512194705Z > entryCSN: 20100512194705.076849Z#000000#000#000000 > modifiersName: cn=Manager,dc=example,dc=com > modifyTimestamp: 20100512194705Z > contextCSN: 20100512194748.621773Z#000000#000#000000 > entryDN: dc=example,dc=com > subschemaSubentry: cn=Subschema > > The version of BDB in use here is 4.8.30, although I note this happens > with > earlier releases of BDB as well. > > Also of interest is the fact that this test fails on some platforms (e.g. > Windows), because the provider slapd correctly reports > hasSubordinates=TRUE, > while the consumer omits the attribute entirely, in spite of the fact that > subordinate entries do exist on the consumer. > > -Matt > > >

1 0

(ITS#6552) Request For Improvement - DSML support to ldap-clients/slap-tools
by marco.pizzoli＠gmail.com 16 May '10

16 May '10

Full_Name: Marco Pizzoli Version: ALL OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.133.1.151) Request For Improvement I would like to export a LDAP-database in DSML format with command line tools like ldapsearch or slapcat, so I ask if is it possible to extend functionality of openldap client tools.

1 0

openldap test-058 error
by tibor benke 15 May '10

15 May '10

Hi, I try to compile openLDAP 2.4.21 with this flags: ldap:~# ./configure --enable-bdb --enable-hdb --enable-dnssrv --enable-ldap --enable-ppolicy --disable-nbd The configuration works perfectly (make depend too), but i get 3 erros messages by test-058. ERROR: Second site1 backend not replicated to central master ERROR: Second site1 backend not replicated to central search What could cause this? Does anyone know? Any suggestions or help will be appreciated platform: Debian Lenny

3 2

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com 15 May '10

15 May '10

Michael Ströder wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> While I agree that slapo-ppolicy is the better solution in the long run I >>> see no reason why to not set both attributes at the server's side to >>> make older LDAP clients happy. >> >> This is not a realistic use case. smbk5pwd was written starting in 2004; >> pam_ldap started supporting LDAP password policy long before then. > > Yes, pam_ldap supports enforcing the password policy probably by correcty > handling the response controls. Grepping through the source of recent versions > it seems to me it does not read attribute pwdChangedTime nor does nss_ldap. Because clients don't need to read the value. Since password modification is all managed on the server, it's an irrelevant detail on the client. >> Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far >> worse problems to worry about. > > AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when > someone or something invokes a call like this > > getent shadow michael Nobody does that. Normal users don't even have read permission to do that. > 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is > Integer with seconds since epoch. In theory nss_ldap could convert it. But > AFAICs it doesn't. Also if an older client would search for > (shadowLastChange<=<value>) this wouldn't work either. You've just proven the point why shadowLastChange is problematic. The encoded value is in *minutes* since the epoch. All of the shadow values were poorly defined to begin with (talking about /etc/shadow, not just RFC2307), inconsistent with common Unix practice, and most people don't understand them anyway. They have no role in an LDAP-enabled environment, all they do is perpetuate confusion. >> This ITS will be closed. > > Well, you're the OpenLDAP boss and free to refuse anything you want. But > personally I don't understand your strong objections. -- -- 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#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 15 May '10

15 May '10

Howard Chu wrote: > Michael Ströder wrote: >> While I agree that slapo-ppolicy is the better solution in the long run I >> see no reason why to not set both attributes at the server's side to >> make older LDAP clients happy. > > This is not a realistic use case. smbk5pwd was written starting in 2004; > pam_ldap started supporting LDAP password policy long before then. Yes, pam_ldap supports enforcing the password policy probably by correcty handling the response controls. Grepping through the source of recent versions it seems to me it does not read attribute pwdChangedTime nor does nss_ldap. > Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far > worse problems to worry about. AFAICS nss_ldap cannot deliver the correct value for 'shadowLastChange' when someone or something invokes a call like this getent shadow michael 'pwdChangedTime' is of syntax Generalized Time whereas 'shadowLastChange' is Integer with seconds since epoch. In theory nss_ldap could convert it. But AFAICs it doesn't. Also if an older client would search for (shadowLastChange<=<value>) this wouldn't work either. > This ITS will be closed. Well, you're the OpenLDAP boss and free to refuse anything you want. But personally I don't understand your strong objections. Ciao, Michael.

1 0

(ITS#6551) wrapping lines option
by muzzol＠gmail.com 15 May '10

15 May '10

Full_Name: muzzol Version: 2.4.18 OS: ubuntu karmic URL: http://www.openldap.org/its/index.cgi/Contrib?id=4269;page=1 Submission from: (NULL) (62.43.106.218) this is a feature request for making wrapping optional. there's an old discussion here: http://www.openldap.org/its/index.cgi/Contrib?id=4269;page=1 but seems that no one take any final decission. disabling wrapping helps a lot when creating simple scripts and several ldap search utilities have this option (mozldap tools, etc).

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 14 May '10

14 May '10

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9D91E1E8CB10AE4177453556 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, I'll have to do some work to set that up -- I'll get back to you. Frank On 5/13/10 8:44 PM, masarati(a)aero.polimi.it wrote: > I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn'= t > reproduce the issue. Can you provide the configuration and an example > LDIF that triggers the issue? I simply ran test043, restart both serve= rs, > and perform a modification similar to yours, and it went through with n= o > problems. > > p. > > =20 >> Full_Name: Francis Swasey >> Version: 2.4.22 >> OS: Red Hat Enterprise Linux 5 update 5 64-bit >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (132.198.107.64) >> >> >> Platform: Red Hat Enterprise Linux 5, update 5, 64-bit >> OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. >> >> The following modify ldif successfully applies to the master: >> >> dn: uid=3Dfcswasey,ou=3DPeople,dc=3Duvm,dc=3Dedu >> changetype: modify >> replace: sn >> sn: Swasey >> - >> replace: sn >> sn: Swasey >> - >> >> In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" >> attribute is presented twice. In OpenLDAP 2.4 -- it works, but the >> delta-syncrepl replica pukes on it with this error: >> >> syncrepl_message_to_op: rid=3D100 mods check (sn: value #0 provided mo= re >> than once) >> >> >> >> =20 > =20 --=20 Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------enig9D91E1E8CB10AE4177453556 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL7YngAAoJEK5S4SsZ5NvSXhMP/24kilppZcRb+NHqXnP1yqaP 3Y4U/6UJ4E6/oVOccr2trGXzCk4LDPyRvGrlY9SouX5Rf8Y7FsddoE0aiTN3mU+L xd4iTsExl7lTTuPZ55BvLBgCQWIkwppArXR/u8OasNTtIcgdDPKVkjbCsGY6xcji ISefkXix5jNgqOe6dQl/DTfJtsAQepCC18t2AvFh727udKu592e5lawlvc3EBH9C ZB+8Pn7iKbVsUX9htwD3PQY+v52SAgmANoPvbTIeH7HQiclqLBi5qgWW9EbOt43Y 716+FCB55M5W5SKSiFncj45UVAv7z+E1qVuduzcFDuX0LrnC1BMjL/9SbIN2IQX6 ATMrsR1DgxIlBFrKuEAyyQ3IdWMlEtNZQsKj1p+z3YXAJT6C2u8RC3slyL11vMAH OvkOLwj56Nlib70Zezuevh/5R+KnzEipVrGosIbsZSmTUx32MR4ByRy8DMi8uNkt JEGSULErsfQEiCr1UsFnwO7d06bf+m0NvcvxTJYvWPBXOjMkTQja1cKnxdEtgoP5 Qg9MZKia3PqO6lQUHgIkRfcqutbuJ+IIuQJ8/oijD3zc198fuUurtiIis/2mjRQv 1Jd/sa52A4z3YFqQ4GyEJokzxFa3xwF4pIoO8NEf1nE1kvUid2gBfqpIfn+SlwBQ nEKtuFX8bXBV0y2Ze3tv =7Ac3 -----END PGP SIGNATURE----- --------------enig9D91E1E8CB10AE4177453556--

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com 14 May '10

14 May '10

Michael Ströder wrote: > Howard Chu wrote: >> michael(a)stroeder.com wrote: >>> michael(a)stroeder.com wrote: >>>> I'd rather argue that for >>>> Samba 3 'sambaPwdLastSet' should be set. >>> >>> Uumpf! This is already set. Sorry for the noise. >>> >>>> 'shadowLastChange' is rather a POSIX account attribute which from my >>>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope >>>> could be >>>> extended... >>> >>> But still it's the question whether we want to have this functionality >>> for >>> various password-related attribute all in on overlay or whether there >>> should >>> be distinct overlays for each account type (posixAccount/shadowAccount, >>> sambaSAMAccount, Kerberos user). >> >> shadowAccount is deprecated. LDAP ppolicy already provides a >> pwdChangedTime attribute. > > While I agree that slapo-ppolicy is the better solution in the long run I see > no reason why to not set both attributes at the server's side to make older > LDAP clients happy. This is not a realistic use case. smbk5pwd was written starting in 2004; pam_ldap started supporting LDAP password policy long before then. Anyone running LDAP clients (pam_ldap, nss_ldap) older than that has far worse problems to worry about. >> Ultimately both Kerberos and Samba will just be using LDAP ppolicy. > > Yes. But there is indeed a real need for a solution in the meantime... Yes, in the meantime both Heimdal and Samba use the smbPwdLastSet attribute which is already taken care of. This ITS will be closed. -- -- 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#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

Howard Chu wrote: > michael(a)stroeder.com wrote: >> michael(a)stroeder.com wrote: >>> I'd rather argue that for >>> Samba 3 'sambaPwdLastSet' should be set. >> >> Uumpf! This is already set. Sorry for the noise. >> >>> 'shadowLastChange' is rather a POSIX account attribute which from my >>> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope >>> could be >>> extended... >> >> But still it's the question whether we want to have this functionality >> for >> various password-related attribute all in on overlay or whether there >> should >> be distinct overlays for each account type (posixAccount/shadowAccount, >> sambaSAMAccount, Kerberos user). > > shadowAccount is deprecated. LDAP ppolicy already provides a > pwdChangedTime attribute. While I agree that slapo-ppolicy is the better solution in the long run I see no reason why to not set both attributes at the server's side to make older LDAP clients happy. > Ultimately both Kerberos and Samba will just be using LDAP ppolicy. Yes. But there is indeed a real need for a solution in the meantime... Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

Mark A. Ziesemer wrote: > 2010/5/14 Michael Ströder <michael(a)stroeder.com > <mailto:michael@stroeder.com>> > 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be > extended... > > I guess I wouldn't have any objections if all the references to "shadow" > were renamed to "posix". However, the shadowLastChange attribute is > part of the shadowAccount objectClass - with neither of these names > referring to POSIX. I didn't consider to change the name of the attribute. With POSIX account data I rather wanted to point to RFC 2307 where posixAccount and shadowAccount object classes and the accompanying attributes are defined. Don't get me wrong. I support the idea of setting shadowLastChange even if Howard considers it to be deprecated. And I have no objections to a one-sets-all-of-these overlay. But I'd even like to see this overlay available as standard feature. Since in the current state it has build dependencies to Kerberos libs this is not easy. Only building the Samba support is possible and needs some tweaking of the Makefile. > There are many issues posted online with all the password attributes > except shadowLastChange getting updated. This patch should provide a > solution for many of these cases. Yupp. I already thought these problems long ago when implementing the different password change use-cases in web2ldap. Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by online＠mark.ziesemer.com 14 May '10

14 May '10

--00504501586f17398e04868dddb7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2010/5/14 Michael Str=F6der <michael(a)stroeder.com> > online(a)mark.ziesemer.com wrote: > > Full_Name: Mark A. Ziesemer > > Version: 2.4.21 / HEAD > > OS: Ubuntu Linux > > URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch > > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > > > Using the PasswordModify Extended Operation (exop) along with the > smbk5pwd slapd > > overlay provides several benefits, but does not currently include the > > shadowLastChange attribute of the shadowAccount class. This means the > > shadowLastChange is missed from update, unless specially done along wit= h > a > > PasswordModify. > > While I agree that this could be useful in general I'd rather argue that > for > Samba 3 'sambaPwdLastSet' should be set. > sambaPwdLastSet is already handled by the "samba" portion of this overlay. 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could b= e > extended... > I guess I wouldn't have any objections if all the references to "shadow" were renamed to "posix". However, the shadowLastChange attribute is part o= f the shadowAccount objectClass - with neither of these names referring to POSIX. I had considered a separate overlay. However, in terms of purpose, shared code, functionality, and performance, it seems to make the most sense to include this addition into the smbk5pwd overlay. Both pam_ldap and the Samba client support use of exop password changes. Additionally, pam_ldap doesn't appear to support hashing to SSHA (only MD5, which is also the default) - so setting to "exop" also allows for a stronge= r hash of the password to be stored. With the unpatched overlay, doing an exop password change updates userPassword (used by POSIX), as well as all the Samba attributes: sambaLMPassword, sambaNTPassword, and sambaPwdLastSet . This allows Samba clients to use the updated password as well as seeing when the password was last set, but POSIX clients do not see an updated shadowLastChange. This patch adds support for the otherwise missing shadowLastChange, keeping everything consistent. There are many issues posted online with all the password attributes except shadowLastChange getting updated. This patch should provide a solution for many of these cases. > Ciao, Michael. > -- Mark A. Ziesemer www.ziesemer.com --00504501586f17398e04868dddb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">2010/5/14 Michael Str=F6der &l= t;<a href=3D"mailto:michael@stroeder.com">michael(a)stroeder.com</a>></spa= n> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;= border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <a href=3D"mailto:online@mark.ziesemer.com">online(a)mark.ziesemer.com</a> wr= ote: > Full_Name: Mark A. Ziesemer > Version: 2.4.21 / HEAD > OS: Ubuntu Linux > URL: <a href=3D"ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patc= h" target=3D"_blank">ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patc= h</a> > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > Using the PasswordModify Extended Operation (exop) along with the smbk= 5pwd slapd > overlay provides several benefits, but does not currently include the<= br> > shadowLastChange attribute of the shadowAccount class. =A0This means t= he > shadowLastChange is missed from update, unless specially done along wi= th a > PasswordModify. While I agree that this could be useful in general I'd rather argue tha= t for Samba 3 'sambaPwdLastSet' should be set. </blockquote><div> s= ambaPwdLastSet is already handled by the "samba" portion of this = overlay. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0= pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: = 1ex;"> 'shadowLastChange' is rather a POSIX account attribute which from m= y understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be<= br> extended... </blockquote><div> I guess I wouldn't have any object= ions if all the references to "shadow" were renamed to "posi= x".=A0 However, the shadowLastChange attribute is part of the shadowAc= count objectClass - with neither of these names referring to POSIX. I had considered a separate overlay.=A0 However, in terms of purpose, s= hared code, functionality, and performance, it seems to make the most sense= to include this addition into the smbk5pwd overlay. Both pam_ldap a= nd the Samba client support use of exop password=20 changes.=A0 Additionally, pam_ldap doesn't appear to support hashing to= =20 SSHA (only MD5, which is also the default) - so setting to "exop"= also=20 allows for a stronger hash of the password to be stored. With the unpatched overlay, doing an exop password change updates userP= assword (used by POSIX), as well as all the Samba attributes: sambaLMPasswo= rd, sambaNTPassword, and sambaPwdLastSet .=A0 This allows Samba clients to = use the updated password as well as seeing when the password was last set, = but POSIX clients do not see an updated shadowLastChange.=A0 This patch add= s support for the otherwise missing shadowLastChange, keeping everything co= nsistent. =A0 There are many issues posted online with all the password attributes= except shadowLastChange getting updated.=A0 This patch should provide a so= lution for many of these cases. </div><blockquote class=3D"gmail_quo= te" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204= , 204); padding-left: 1ex;"> Ciao, Michael. </blockquote><div>=A0</div></div>-- Mark A. Ziesemer<b= r><a href=3D"http://www.ziesemer.com">www.ziesemer.com</a> --00504501586f17398e04868dddb7--

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by hyc＠symas.com 14 May '10

14 May '10

michael(a)stroeder.com wrote: > michael(a)stroeder.com wrote: >> I'd rather argue that for >> Samba 3 'sambaPwdLastSet' should be set. > > Uumpf! This is already set. Sorry for the noise. > >> 'shadowLastChange' is rather a POSIX account attribute which from my >> understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be >> extended... > > But still it's the question whether we want to have this functionality for > various password-related attribute all in on overlay or whether there should > be distinct overlays for each account type (posixAccount/shadowAccount, > sambaSAMAccount, Kerberos user). shadowAccount is deprecated. LDAP ppolicy already provides a pwdChangedTime attribute. > Personally I'd like to see this overlay moved from contrib/ into the standard > build. But for Kerberos-related attributes the build and schema dependencies > are an obstacle. => separate overlays at least for KDC/LDAP and Samba-Posix/LDAP. Ultimately both Kerberos and Samba will just be using LDAP ppolicy. But yes, the build dependencies are still annoying. -- -- 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#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

michael(a)stroeder.com wrote: > I'd rather argue that for > Samba 3 'sambaPwdLastSet' should be set. Uumpf! This is already set. Sorry for the noise. > 'shadowLastChange' is rather a POSIX account attribute which from my > understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be > extended... But still it's the question whether we want to have this functionality for various password-related attribute all in on overlay or whether there should be distinct overlays for each account type (posixAccount/shadowAccount, sambaSAMAccount, Kerberos user). Personally I'd like to see this overlay moved from contrib/ into the standard build. But for Kerberos-related attributes the build and schema dependencies are an obstacle. => separate overlays at least for KDC/LDAP and Samba-Posix/LDAP. Ciao, Michael.

1 0

Re: (ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by michael＠stroeder.com 14 May '10

14 May '10

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.21 / HEAD > OS: Ubuntu Linux > URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch > Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) > > Using the PasswordModify Extended Operation (exop) along with the smbk5pwd slapd > overlay provides several benefits, but does not currently include the > shadowLastChange attribute of the shadowAccount class. This means the > shadowLastChange is missed from update, unless specially done along with a > PasswordModify. While I agree that this could be useful in general I'd rather argue that for Samba 3 'sambaPwdLastSet' should be set. 'shadowLastChange' is rather a POSIX account attribute which from my understanding is out-of-scope for slapo-smbk5pwd. Well, the scope could be extended... Ciao, Michael.

1 0

(ITS#6550) Patch for smbk5pwd slapd overlay to include shadowLastChange
by online＠mark.ziesemer.com 13 May '10

13 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 / HEAD OS: Ubuntu Linux URL: ftp://ftp.openldap.org/incoming/smbk5pwd-shadow-b.patch Submission from: (NULL) (2001:470:1f11:3ae:dc54:73ba:be16:148) Using the PasswordModify Extended Operation (exop) along with the smbk5pwd slapd overlay provides several benefits, but does not currently include the shadowLastChange attribute of the shadowAccount class. This means the shadowLastChange is missed from update, unless specially done along with a PasswordModify. This patch adds support for updating shadowLastChange into the smbk5pwd overlay for slapd. An added benefit is that once the updated overlay is in effect, write access to the shadowLastChange attribute can optionally be restricted by configuration, preventing users from updating shadowLastChange without actually updating their password. The SHA-1 hash of the provided patch (smbk5pwd-shadow-b.patch) is c29ff518ea4fe03a4c5ee87d07a3af0082256950 . (Please discard "smbk5pwd-shadow.patch".) Patch was generated against HEAD just now, but also applies cleanly to 2.4.21. I am currently using the patched overlay in my current environment without noticeable issue. However, C is not current primary language, so please give appropriate attention to review. This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Mark A. Ziesemer <online(a)mark.ziesemer.com>. I have not assigned rights and/or interest in this work to any party. I, Mark A. Ziesemer, 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#6545) delta-syncrepl rejects modification master accepted
by masarati＠aero.polimi.it 13 May '10

13 May '10

I checked with HEAD and re24 (basically, 2.4.22 from CVS) and I couldn't reproduce the issue. Can you provide the configuration and an example LDIF that triggers the issue? I simply ran test043, restart both servers, and perform a modification similar to yours, and it went through with no problems. p. > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" > attribute is presented twice. In OpenLDAP 2.4 -- it works, but the > delta-syncrepl replica pukes on it with this error: > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) > > >

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com 13 May '10

13 May '10

--On May 12, 2010 1:06:53 PM +0000 Frank.Swasey(a)uvm.edu wrote: > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enig666A26622E67D44DE6AFFA9C > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > I see someone has tagged this as unreproducable in head/re24.=20 > > Ok.... Are you saying that 2.4.23 will not have this bug or that I did > something wrong in compiling 2.4.22???? Pierangelo made that note, but failed to follow up with the ITS in any way. Maybe he will be willing to provide more information, since RE24 and 2.4.22 are identical. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6549) test043 hasSubordinates attribute inconsistencies
by mhardin＠symas.com 12 May '10

12 May '10

Full_Name: Matt Hardin Version: 2.4.22 OS: Red Hat AS 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (74.38.117.141) In test043 the test database defines a root entry of dc=example,dc=com. For this entry, the results of the ldapsearch do not include the hasSubordinates attribute at all, in spite of the fact that the entry does have subordinates. Test043 passes, due to the fact that this attribute is missing from the root entry in both the provider and the consumer. Other entries with subordinates do include this attribute and its value is correct in all the cases I examined. Here is the snippet from tests/testrun/server1.flt: dn: dc=example,dc=com dc: example objectClass: organization objectClass: domainRelatedObject objectClass: dcObject l: Anytown, Michigan st: Michigan o: Example, Inc. o: EX o: Ex. description: The Example, Inc. at Anytown postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ US telephoneNumber: +1 313 555 1817 associatedDomain: example.com structuralObjectClass: organization entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20100512194705Z entryCSN: 20100512194705.076849Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20100512194705Z contextCSN: 20100512194748.621773Z#000000#000#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema The version of BDB in use here is 4.8.30, although I note this happens with earlier releases of BDB as well. Also of interest is the fact that this test fails on some platforms (e.g. Windows), because the provider slapd correctly reports hasSubordinates=TRUE, while the consumer omits the attribute entirely, in spite of the fact that subordinate entries do exist on the consumer. -Matt

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 12 May '10

12 May '10

--00c09f76b87ebad978048667feb6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 12, 2010 at 10:05 AM, Howard Chu <hyc(a)symas.com> wrote: > online(a)mark.ziesemer.com wrote: > >> Full_Name: Mark A. Ziesemer >> Version: 2.4.21 >> OS: Ubuntu Linux 10.04 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) >> >> >> Many "connection_read(): no connection!" warnings are written to >> /var/log/debug >> and /var/log/syslog by slapd. As stated at >> http://www.openldap.org/lists/openldap-software/200811/msg00079.html , >> this is >> apparently not a problem with slapd, but a client that is disconnecting >> without >> first unbinding. >> > > This also happens when the connection manager queues up a thread to handle > a "socket is readable" event on a socket that's in the process of closing. > Pretty much unavoidable, when a lot of threads are active. I don't see this > as a high enough priority to warrant fixing. > This was not happening under a high load, but with only 1-2 connections active. I might not have focused on it enough in the original report, but isn't this looking like it is probably an issue with the libldap client library (provided by OpenLDAP), rather than the slapd daemon? Looking at the provided logs, it appears that no do_unbind request is received (not sent by the client) when using ldapi:/// with a bind DN. If it can't / won't be fixed, can the logging of the "connection_read(): no connection!" event in slapd at least be demoted to a lower level so that it doesn't fill the default logging output, without having to change the overall configured logging level and potentially missing other logged events that do require attention? > This appears to be an issue with the libldap client library provided by >> OpenLDAP >> itself (2.4.21), and not the slapd daemon. >> >> Issue is reproducible even by just using "ldapsearch -H ldapi:///", but >> only if >> a bind DN is specified (-D) and external authentication is not used. >> >> Running slapd with logging enabled (-d 8) shows the following 3 sequences >> - >> ldapsearch command followed by the slapd logs. Note that the >> "connection_read(): no connection!" is only visible on the middle pair. >> >> >> $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" >> SASL/EXTERNAL authentication started >> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth >> SASL SSF: 0 >> No such object (32) >> >> slap_listener_activate(9): >> >>> slap_listener(ldapi:///) >>>>> >>>> connection_get(14): got connid=1000 >> connection_read(14): checking for input on id=1000 >> ber_get_next >> ber_get_next: tag 0x30 len 24 contents: >> op tag 0x60, time 1273546410 >> ber_get_next >> conn=1000 op=0 do_bind >> ber_scanf fmt ({imt) ber: >> ber_scanf fmt ({m) ber: >> ber_scanf fmt (m) ber: >> ber_scanf fmt (}}) ber: >> >>> dnPrettyNormal:<> >>>>> >>>> <<< dnPrettyNormal:<>,<> >> do_bind: dn () SASL mech EXTERNAL >> ==>slap_sasl2dn: converting SASL name >> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN >> <==slap_sasl2dn: Converted SASL name to<nothing> >> SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" >> send_ldap_sasl: err=0 len=-1 >> do_bind: SASL/EXTERNAL bind: >> dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 >> send_ldap_response: msgid=1 tag=97 err=0 >> ber_flush2: 14 bytes to sd 14 >> <== slap_sasl_bind: rc=0 >> connection_get(14): got connid=1000 >> connection_read(14): checking for input on id=1000 >> ber_get_next >> ber_get_next: tag 0x30 len 37 contents: >> op tag 0x63, time 1273546410 >> ber_get_next >> conn=1000 op=1 do_search >> ber_scanf fmt ({miiiib) ber: >> >>> dnPrettyNormal:<> >>>>> >>>> <<< dnPrettyNormal:<>,<> >> ber_scanf fmt (m) ber: >> ber_scanf fmt ({M}}) ber: >> send_ldap_result: conn=1000 op=1 p=3 >> send_ldap_response: msgid=2 tag=101 err=32 >> ber_flush2: 14 bytes to sd 14 >> connection_get(14): got connid=1000 >> connection_read(14): checking for input on id=1000 >> ber_get_next >> ber_get_next: tag 0x30 len 5 contents: >> op tag 0x42, time 1273546410 >> ber_get_next >> conn=1000 op=2 do_unbind >> connection_close: conn=1000 sd=14 >> >> $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W >> Enter LDAP Password: >> ldap_bind: Invalid credentials (49) >> >> slap_listener_activate(9): >> >>> slap_listener(ldapi:///) >>>>> >>>> connection_get(14): got connid=1001 >> connection_read(14): checking for input on id=1001 >> ber_get_next >> ber_get_next: tag 0x30 len 44 contents: >> op tag 0x60, time 1273546420 >> ber_get_next >> conn=1001 op=0 do_bind >> ber_scanf fmt ({imt) ber: >> ber_scanf fmt (m}) ber: >> >>> dnPrettyNormal:<cn=admin,dc=example,dc=com> >>>>> >>>> <<< >> dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> >> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 >> send_ldap_result: conn=1001 op=0 p=3 >> send_ldap_response: msgid=1 tag=97 err=49 >> ber_flush2: 14 bytes to sd 14 >> connection_get(14): got connid=1001 >> connection_read(14): checking for input on id=1001 >> ber_get_next >> ber_get_next on fd 14 failed errno=0 (Success) >> connection_close: conn=1001 sd=14 >> connection_read(14): no connection! >> connection_read(14): no connection! >> >> $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W >> Enter LDAP Password: >> ldap_bind: Invalid credentials (49) >> >> slap_listener_activate(8): >> >>> slap_listener(ldap:///) >>>>> >>>> connection_get(14): got connid=1002 >> connection_read(14): checking for input on id=1002 >> ber_get_next >> ber_get_next: tag 0x30 len 44 contents: >> op tag 0x60, time 1273546425 >> ber_get_next >> conn=1002 op=0 do_bind >> ber_scanf fmt ({imt) ber: >> ber_scanf fmt (m}) ber: >> >>> dnPrettyNormal:<cn=admin,dc=example,dc=com> >>>>> >>>> <<< >> dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> >> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 >> send_ldap_result: conn=1002 op=0 p=3 >> send_ldap_response: msgid=1 tag=97 err=49 >> ber_flush2: 14 bytes to sd 14 >> connection_get(14): got connid=1002 >> connection_read(14): checking for input on id=1002 >> ber_get_next >> ber_get_next on fd 14 failed errno=0 (Success) >> connection_close: conn=1002 sd=14 >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Mark A. Ziesemer www.ziesemer.com --00c09f76b87ebad978048667feb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Wed, May 12, 2010 at 10:05 AM, Howard Chu <sp= an dir=3D"ltr"><<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>></= span> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt = 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <a href=3D"mailto:online@mark.ziesemer.com" target=3D"_blank">online(a)mark.z= iesemer.com</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux 10.04 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" target=3D"_blank">ftp://f= tp.openldap.org/incoming/</a> Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) Many "connection_read(): no connection!" warnings are written to = /var/log/debug and /var/log/syslog by slapd. =A0As stated at <a href=3D"http://www.openldap.org/lists/openldap-software/200811/msg00079.= html" target=3D"_blank">http://www.openldap.org/lists/openldap-software/200= 811/msg00079.html</a> , this is apparently not a problem with slapd, but a client that is disconnecting wit= hout first unbinding. </blockquote> This also happens when the connection manager queues up a thread to handle = a "socket is readable" event on a socket that's in the proces= s of closing. Pretty much unavoidable, when a lot of threads are active. I = don't see this as a high enough priority to warrant fixing. </blockquote><div> This was not happening under a high load, but with on= ly 1-2 connections active. I might not have focused on it enough in = the original report, but isn't this looking like it is probably an issu= e with the libldap client library (provided by OpenLDAP), rather than the s= lapd daemon?=A0 Looking at the provided logs, it appears that no do_unbind = request is received (not sent by the client) when using ldapi:/// with a bi= nd DN. If it can't / won't be fixed, can the logging of the "conn= ection_read(): no connection!" event in slapd at least be demoted to a= lower level so that it doesn't fill the default logging output, withou= t having to change the overall configured logging level and potentially mis= sing other logged events that do require attention? =A0 </div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex;= border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote= class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px= solid rgb(204, 204, 204); padding-left: 1ex;"> This appears to be an issue with the libldap client library provided by Ope= nLDAP itself (2.4.21), and not the slapd daemon. Issue is reproducible even by just using "ldapsearch -H ldapi:///&quot= ;, but only if a bind DN is specified (-D) and external authentication is not used. Running slapd with logging enabled (-d 8) shows the following 3 sequences -= ldapsearch command followed by the slapd logs. =A0Note that the "connection_read(): no connection!" is only visible on the middle= pair. $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" SASL/EXTERNAL authentication started SASL username: gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn= =3Dauth SASL SSF: 0 No such object (32) slap_listener_activate(9): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldapi:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 24 contents: op tag 0x60, time 1273546410 ber_get_next conn=3D1000 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<>,<> do_bind: dn () SASL mech EXTERNAL =3D=3D>slap_sasl2dn: converting SASL name gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=3Dauth to a DN<b= r> <=3D=3Dslap_sasl2dn: Converted SASL name to<nothing> SASL Authorize [conn=3D1000]: =A0proxy authorization allowed authzDN=3D&quo= t;" send_ldap_sasl: err=3D0 len=3D-1 do_bind: SASL/EXTERNAL bind: dn=3D"gidNumber=3D0+uidNumber=3D0,cn=3Dpeercred,cn=3Dexternal,cn=3Daut= h" sasl_ssf=3D0 send_ldap_response: msgid=3D1 tag=3D97 err=3D0 ber_flush2: 14 bytes to sd 14 <=3D=3D slap_sasl_bind: rc=3D0 connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 37 contents: op tag 0x63, time 1273546410 ber_get_next conn=3D1000 op=3D1 do_search ber_scanf fmt ({miiiib) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<>,<> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=3D1000 op=3D1 p=3D3 send_ldap_response: msgid=3D2 tag=3D101 err=3D32 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1000 connection_read(14): checking for input on id=3D1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1273546410 ber_get_next conn=3D1000 op=3D2 do_unbind connection_close: conn=3D1000 sd=3D14 $ ldapsearch -H ldapi:/// -D "cn=3Dadmin,dc=3Dexample,dc=3Dcom" -= b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(9): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldapi:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1001 connection_read(14): checking for input on id=3D1001 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546420 ber_get_next conn=3D1001 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>,&lt= ;cn=3Dadmin,dc=3Dexample,dc=3Dcom> do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc=3Dcom" meth= od=3D128 send_ldap_result: conn=3D1001 op=3D0 p=3D3 send_ldap_response: msgid=3D1 tag=3D97 err=3D49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1001 connection_read(14): checking for input on id=3D1001 ber_get_next ber_get_next on fd 14 failed errno=3D0 (Success) connection_close: conn=3D1001 sd=3D14 connection_read(14): no connection! connection_read(14): no connection! $ ldapsearch -H ldap:/// -D "cn=3Dadmin,dc=3Dexample,dc=3Dcom" -b= "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(8): <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> slap_listener(ldap:///) </blockquote></blockquote></blockquote> connection_get(14): got connid=3D1002 connection_read(14): checking for input on id=3D1002 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546425 ber_get_next conn=3D1002 op=3D0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class= =3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid= rgb(204, 204, 204); padding-left: 1ex;"> <blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; borde= r-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom> </blockquote></blockquote></blockquote> <<< =A0dnPrettyNormal:<cn=3Dadmin,dc=3Dexample,dc=3Dcom>,&lt= ;cn=3Dadmin,dc=3Dexample,dc=3Dcom> do_bind: version=3D3 dn=3D"cn=3Dadmin,dc=3Dexample,dc=3Dcom" meth= od=3D128 send_ldap_result: conn=3D1002 op=3D0 p=3D3 send_ldap_response: msgid=3D1 tag=3D97 err=3D49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=3D1002 connection_read(14): checking for input on id=3D1002 ber_get_next ber_get_next on fd 14 failed errno=3D0 (Success) connection_close: conn=3D1002 sd=3D14 </blockquote> -- =A0-- Howard Chu =A0CTO, Symas Corp. =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.symas.com" t= arget=3D"_blank">http://www.symas.com</a> =A0Director, Highland Sun =A0 =A0 <a href=3D"http://highlandsun.com/hyc/" = target=3D"_blank">http://highlandsun.com/hyc/</a> =A0Chief Architect, OpenLDAP =A0<a href=3D"http://www.openldap.org/project= /" target=3D"_blank">http://www.openldap.org/project/</a> </blockquote></div> -- Mark A. Ziesemer <a href=3D"http://www.zies= emer.com">www.ziesemer.com</a> --00c09f76b87ebad978048667feb6--

1 0

Re: (ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by hyc＠symas.com 12 May '10

12 May '10

online(a)mark.ziesemer.com wrote: > Full_Name: Mark A. Ziesemer > Version: 2.4.21 > OS: Ubuntu Linux 10.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) > > > Many "connection_read(): no connection!" warnings are written to /var/log/debug > and /var/log/syslog by slapd. As stated at > http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is > apparently not a problem with slapd, but a client that is disconnecting without > first unbinding. This also happens when the connection manager queues up a thread to handle a "socket is readable" event on a socket that's in the process of closing. Pretty much unavoidable, when a lot of threads are active. I don't see this as a high enough priority to warrant fixing. > This appears to be an issue with the libldap client library provided by OpenLDAP > itself (2.4.21), and not the slapd daemon. > > Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if > a bind DN is specified (-D) and external authentication is not used. > > Running slapd with logging enabled (-d 8) shows the following 3 sequences - > ldapsearch command followed by the slapd logs. Note that the > "connection_read(): no connection!" is only visible on the middle pair. > > > $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" > SASL/EXTERNAL authentication started > SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > SASL SSF: 0 > No such object (32) > > slap_listener_activate(9): >>>> slap_listener(ldapi:///) > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 24 contents: > op tag 0x60, time 1273546410 > ber_get_next > conn=1000 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt ({m) ber: > ber_scanf fmt (m) ber: > ber_scanf fmt (}}) ber: >>>> dnPrettyNormal:<> > <<< dnPrettyNormal:<>,<> > do_bind: dn () SASL mech EXTERNAL > ==>slap_sasl2dn: converting SASL name > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN > <==slap_sasl2dn: Converted SASL name to<nothing> > SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" > send_ldap_sasl: err=0 len=-1 > do_bind: SASL/EXTERNAL bind: > dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 > send_ldap_response: msgid=1 tag=97 err=0 > ber_flush2: 14 bytes to sd 14 > <== slap_sasl_bind: rc=0 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 37 contents: > op tag 0x63, time 1273546410 > ber_get_next > conn=1000 op=1 do_search > ber_scanf fmt ({miiiib) ber: >>>> dnPrettyNormal:<> > <<< dnPrettyNormal:<>,<> > ber_scanf fmt (m) ber: > ber_scanf fmt ({M}}) ber: > send_ldap_result: conn=1000 op=1 p=3 > send_ldap_response: msgid=2 tag=101 err=32 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1000 > connection_read(14): checking for input on id=1000 > ber_get_next > ber_get_next: tag 0x30 len 5 contents: > op tag 0x42, time 1273546410 > ber_get_next > conn=1000 op=2 do_unbind > connection_close: conn=1000 sd=14 > > $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(9): >>>> slap_listener(ldapi:///) > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546420 > ber_get_next > conn=1001 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: >>>> dnPrettyNormal:<cn=admin,dc=example,dc=com> > <<< dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1001 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1001 > connection_read(14): checking for input on id=1001 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1001 sd=14 > connection_read(14): no connection! > connection_read(14): no connection! > > $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > slap_listener_activate(8): >>>> slap_listener(ldap:///) > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next: tag 0x30 len 44 contents: > op tag 0x60, time 1273546425 > ber_get_next > conn=1002 op=0 do_bind > ber_scanf fmt ({imt) ber: > ber_scanf fmt (m}) ber: >>>> dnPrettyNormal:<cn=admin,dc=example,dc=com> > <<< dnPrettyNormal:<cn=admin,dc=example,dc=com>,<cn=admin,dc=example,dc=com> > do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 > send_ldap_result: conn=1002 op=0 p=3 > send_ldap_response: msgid=1 tag=97 err=49 > ber_flush2: 14 bytes to sd 14 > connection_get(14): got connid=1002 > connection_read(14): checking for input on id=1002 > ber_get_next > ber_get_next on fd 14 failed errno=0 (Success) > connection_close: conn=1002 sd=14 > > -- -- 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#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 12 May '10

12 May '10

This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig666A26622E67D44DE6AFFA9C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I see someone has tagged this as unreproducable in head/re24.=20 Ok.... Are you saying that 2.4.23 will not have this bug or that I did something wrong in compiling 2.4.22???? --=20 Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900) --------------enig666A26622E67D44DE6AFFA9C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL6qe8AAoJEK5S4SsZ5NvSFWcQAJJ3SvQyoD+Te4dvxJghyF44 FlOv9y6hi9vWw6fHcPJlvKBY6ZCgJoq7QeWjYXhYCk8643Yq7HRA0q3TtADwRw08 8UObJjrNoABII3QHuta7wQWNC6xKoGRUd17hzTDTZAv2AH8lMYRQPjpUKNOXAE1G gaVOcIEM5ZHTX3y1uusu5xUbEVc/t8YlDRMIzDBukyLJaPO+/Aqy+adhpEkdULV3 1K3AlcrQDZWiD6TeWd1xIPGtrNaW1poHKIDa7ziU75D/8GQdP4FIDxwb83wQUbwi 5ZjYD0jjtoRqSvaprRL5GUPrq/s9E5ccqlPsjaVUoalHc3/VoMMpFWYewE2P/b5e R89U9kHKkimFOUROyC4gS/cI9SiNhL0L9TOryUAE4JUG1PEGiAHEYoxxRQj8Cmk0 7OcVTNLS5Jtyx3MRCqds2CSfNL71rXJxJok6n/1OlZvkx4E7GlVXWxmWs7o9uL5P GsYHlbTiWH08NoEb5cejOekALV6p8OY8gXLYSvxslc0p4a5HTAQI6ozwMhAY1JNS 0hZAG7cOTsBcmoNsF1Vf2DQbkZ68je6N/Hz75QfBJgzkFvd/kqadpIwu3yCljCEo eZal5tkC5CcmcPNOIndxPgyMrafX7CogSvZ80cPGlwWd8rBL7rAccBO7JjGhf9dM 9X57ftTkOpZzsi1/oA+q =sb/D -----END PGP SIGNATURE----- --------------enig666A26622E67D44DE6AFFA9C--

1 0

(ITS#6548) Many "connection_read(): no connection!" warnings when using ldapi:/// and a bind DN (no external authentication)
by online＠mark.ziesemer.com 10 May '10

10 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux 10.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:1f11:3ae:4d6d:3d3e:faa6:ee3d) Many "connection_read(): no connection!" warnings are written to /var/log/debug and /var/log/syslog by slapd. As stated at http://www.openldap.org/lists/openldap-software/200811/msg00079.html , this is apparently not a problem with slapd, but a client that is disconnecting without first unbinding. This appears to be an issue with the libldap client library provided by OpenLDAP itself (2.4.21), and not the slapd daemon. Issue is reproducible even by just using "ldapsearch -H ldapi:///", but only if a bind DN is specified (-D) and external authentication is not used. Running slapd with logging enabled (-d 8) shows the following 3 sequences - ldapsearch command followed by the slapd logs. Note that the "connection_read(): no connection!" is only visible on the middle pair. $ ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "" SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 No such object (32) slap_listener_activate(9): >>> slap_listener(ldapi:///) connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 24 contents: op tag 0x60, time 1273546410 ber_get_next conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: ber_scanf fmt (}}) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> do_bind: dn () SASL mech EXTERNAL ==>slap_sasl2dn: converting SASL name gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth to a DN <==slap_sasl2dn: Converted SASL name to <nothing> SASL Authorize [conn=1000]: proxy authorization allowed authzDN="" send_ldap_sasl: err=0 len=-1 do_bind: SASL/EXTERNAL bind: dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" sasl_ssf=0 send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 <== slap_sasl_bind: rc=0 connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 37 contents: op tag 0x63, time 1273546410 ber_get_next conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> ber_scanf fmt (m) ber: ber_scanf fmt ({M}}) ber: send_ldap_result: conn=1000 op=1 p=3 send_ldap_response: msgid=2 tag=101 err=32 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ber_get_next: tag 0x30 len 5 contents: op tag 0x42, time 1273546410 ber_get_next conn=1000 op=2 do_unbind connection_close: conn=1000 sd=14 $ ldapsearch -H ldapi:/// -D "cn=admin,dc=example,dc=com" -b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(9): >>> slap_listener(ldapi:///) connection_get(14): got connid=1001 connection_read(14): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546420 ber_get_next conn=1001 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=admin,dc=example,dc=com> <<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 send_ldap_result: conn=1001 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1001 connection_read(14): checking for input on id=1001 ber_get_next ber_get_next on fd 14 failed errno=0 (Success) connection_close: conn=1001 sd=14 connection_read(14): no connection! connection_read(14): no connection! $ ldapsearch -H ldap:/// -D "cn=admin,dc=example,dc=com" -b "" -W Enter LDAP Password: ldap_bind: Invalid credentials (49) slap_listener_activate(8): >>> slap_listener(ldap:///) connection_get(14): got connid=1002 connection_read(14): checking for input on id=1002 ber_get_next ber_get_next: tag 0x30 len 44 contents: op tag 0x60, time 1273546425 ber_get_next conn=1002 op=0 do_bind ber_scanf fmt ({imt) ber: ber_scanf fmt (m}) ber: >>> dnPrettyNormal: <cn=admin,dc=example,dc=com> <<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com> do_bind: version=3 dn="cn=admin,dc=example,dc=com" method=128 send_ldap_result: conn=1002 op=0 p=3 send_ldap_response: msgid=1 tag=97 err=49 ber_flush2: 14 bytes to sd 14 connection_get(14): got connid=1002 connection_read(14): checking for input on id=1002 ber_get_next ber_get_next on fd 14 failed errno=0 (Success) connection_close: conn=1002 sd=14

1 0

(ITS#6247)
by daniel＠pluta.biz 09 May '10

09 May '10

An updated version of the patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100509.patch

1 0

(ITS#6547) config.guess needs updating
by panth13＠gmail.com 07 May '10

07 May '10

Full_Name: Bryan Stopp Version: 2.4.21 OS: AIX6.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.197.28.158) The latest version of the config.guess that is bundled with the source is about 5 years out of date. It doesn't pick up new operating systems (specifically AIX6.? in my case). Can someone grab the latest from GNU? (http://cvs.savannah.gnu.org/viewvc/config/config/config.guess) -B

1 0

(ITS#6546) Default olcRootDN of "cn=config" should be documented
by bugs＠mark.ziesemer.com 07 May '10

07 May '10

Full_Name: Mark A. Ziesemer Version: 2.4.21 OS: Ubuntu Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:1f11:3ae:4d06:cdd1:50ce:9c64) While using the "cn=config" configuration, I found that "cn=config" is also the default olcRootDN. By just configuring a olcRootPW , login to the config database is possible using "cn=config" and the configured olcRootPW. This default should be documented in the admin guide, etc. IRC user hyc on #openldap mentioned "it's been the default since 2005", but "I can't find the reference either, perhaps we lost it."

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 06 May '10

06 May '10

On 5/6/10 3:18 PM, Quanah Gibson-Mount wrote: > Can you please show the contents of the accesslog databsae for this > change? dn: reqStart=20100506114012.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20100506114012.000002Z reqEnd: 20100506114012.000003Z reqType: modify reqSession: 1006 reqAuthzID: cn=manager,dc=uvm,dc=edu reqDN: uid=fcswasey,ou=People,dc=uvm,dc=edu reqResult: 0 reqMod: sn:= Swasey reqMod: sn:= Swasey reqMod: entryCSN:= 20100506114012.200297Z#000000#000#000000 reqMod: modifiersName:= cn=manager,dc=uvm,dc=edu reqMod: modifyTimestamp:= 20100506114012Z entryUUID: 7ba18504-6f3b-450a-8420-a101ba6b76c5 creatorsName: cn=accesslog createTimestamp: 20100506114012Z entryCSN: 20100506114012.200297Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20100506114012Z entryDN: reqStart=20100506114012.000002Z,cn=accesslog subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

1 0

Re: (ITS#6545) delta-syncrepl rejects modification master accepted
by quanah＠zimbra.com 06 May '10

06 May '10

--On Wednesday, May 05, 2010 5:37 PM +0000 Frank.Swasey(a)uvm.edu wrote: > Full_Name: Francis Swasey > Version: 2.4.22 > OS: Red Hat Enterprise Linux 5 update 5 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (132.198.107.64) > > > Platform: Red Hat Enterprise Linux 5, update 5, 64-bit > OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. > > The following modify ldif successfully applies to the master: > > dn: uid=fcswasey,ou=People,dc=uvm,dc=edu > changetype: modify > replace: sn > sn: Swasey > - > replace: sn > sn: Swasey > - > > syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more > than once) Can you please show the contents of the accesslog databsae for this change? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6545) delta-syncrepl rejects modification master accepted
by Frank.Swasey＠uvm.edu 05 May '10

05 May '10

Full_Name: Francis Swasey Version: 2.4.22 OS: Red Hat Enterprise Linux 5 update 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.107.64) Platform: Red Hat Enterprise Linux 5, update 5, 64-bit OpenLDAP: 2.4.22 (locally compiled), configured with delta-syncrepl. The following modify ldif successfully applies to the master: dn: uid=fcswasey,ou=People,dc=uvm,dc=edu changetype: modify replace: sn sn: Swasey - replace: sn sn: Swasey - In OpenLDAP 2.3 -- this modify ldif deck failed because the "sn" attribute is presented twice. In OpenLDAP 2.4 -- it works, but the delta-syncrepl replica pukes on it with this error: syncrepl_message_to_op: rid=100 mods check (sn: value #0 provided more than once)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 05 May '10

05 May '10

I made an important discovery this morning (with a fresh set of eyes...): without Pierangelo's patch, chaining does *NOT* work, as originally stated. So, the patch does fix the broken test that started this ITS, making it both valid and absolutely necessary, but alas, the functionality of the chaining configuration is the same with both the patched and unpatched package: the DN is not being passed through, so the automatic chasing of the referral does not work. Here is an example with ldapvi: ### Command issued on slave to change one attribute of user uid=ryans,ou=Users,dc=example,dc=com ryans@slave:~# ldapvi --ldap-conf --starttls -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://ldapmaster.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] ### Logs on slave generated by ldapvi command May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 ACCEPT from IP=127.0.0.1:34118 (IP=0.0.0.0:389) May 5 10:27:04 slave slapd[30408]: conn=44 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 5 10:27:04 slave slapd[30408]: conn=44 op=0 STARTTLS May 5 10:27:04 slave slapd[30408]: conn=44 op=0 RESULT oid= err=0 text= May 5 10:27:04 slave slapd[30408]: conn=44 fd=41 TLS established tls_ssf=128 ssf=128 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 May 5 10:27:04 slave slapd[30408]: conn=44 op=1 RESULT tag=97 err=0 text= May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SRCH attr=+ * May 5 10:27:04 slave slapd[30408]: conn=44 op=2 ENTRY dn="" May 5 10:27:04 slave slapd[30408]: conn=44 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=admin,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=ryans,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="uid=xxxxx,ou=users,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxx,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=ryans,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 ENTRY dn="cn=xxxxxx,ou=groups,dc=example,dc=com" May 5 10:27:04 slave slapd[30408]: conn=44 op=3 SEARCH RESULT tag=101 err=0 nentries=159 text= May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 5 10:27:22 slave slapd[30408]: conn=44 op=4 MOD attr=displayColor May 5 10:27:22 slave slapd[30408]: conn=44 op=4 RESULT tag=103 err=10 text= The referral is generated (err=10), and sent to the master, and here's what the logs there look like: ### Logs on master generated by referral May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 ACCEPT from IP=10.0.1.196:43376 (IP=0.0.0.0:389) May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 BIND dn="" method=128 May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=0 RESULT tag=97 err=0 text= May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 MOD attr=displayColor May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=1 RESULT tag=103 err=8 text=modifications require authentication May 5 10:43:04 ldap1 slapd[8794]: conn=402475 op=2 UNBIND May 5 10:43:04 ldap1 slapd[8794]: conn=402475 fd=273 closed May 5 10:43:04 ldap1 slapd[8794]: conn=402476 fd=273 ACCEPT from IP=10.0.1.196:43377 (IP=0.0.0.0:389) As you can see, the DN is empty. It might be worth mentioning that I have tried the olcDbURI with dotted-quads, hostnames, and with and without quotes, and the value portions of the attr=value pairs in the olcDbIDAssertBind attribute with and without quotes, to no avail, though I did not expect it to. I have also tried with and without TLS (my configuration supports both) in the chaining configuration, and explicitly with olcDbChaseReferrals set to TRUE, though that should be the default. I've also tried with and without proxy authz (authzTo/authzFrom) in a vain attempt to get this working, as is mentioned above in this ITS (because it is referenced in the Admin Guide section on chaining), but that too failed. However, most of this would seem unnecessary since test022-ppolicy does almost none of them, although that test was recently patched to detect the bug fixed by Pierangelo's patch so it may not be an ironclad example. But since there's no other officially documented example of setting up chaining with cn=config, it's really all the community has to go on. Again, for reference, the most recent configuration used is provided below: 1 cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}back_ldap.la 20 olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain 21 olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "ldap://10.1.1.164:389" olcDbStartTLS: start olcDbIDAssertBind: bindmethod="simple" binddn="cn=admin,dc=example,dc=com" credentials="secret" mode="self" olcDbChaseReferrals: TRUE If you want an example using an officially distributed tool, or one that doesn't handle referrals, here it is, using ldappasswd: ### Command issued on slave ryans@slave:~# ldappasswd -h localhost uid=ryans,ou=Users,dc=example,dc=com New password: Re-enter new password: Enter LDAP Password: Result: Strong(er) authentication required (8) Additional info: only authenticated users may change passwords ### Slave side logs using ldappasswd May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 ACCEPT from IP=127.0.0.1:32947 (IP=0.0.0.0:389) May 5 10:30:47 slave slapd[30408]: conn=47 op=0 EXT oid=1.3.6.1.4.1.1466.20037 May 5 10:30:47 slave slapd[30408]: conn=47 op=0 STARTTLS May 5 10:30:47 slave slapd[30408]: conn=47 op=0 RESULT oid= err=0 text= May 5 10:30:47 slave slapd[30408]: conn=47 fd=41 TLS established tls_ssf=128 ssf=128 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" method=128 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 BIND dn="uid=ryans,ou=Users,dc=example,dc=com" mech=SIMPLE ssf=0 May 5 10:30:47 slave slapd[30408]: conn=47 op=1 RESULT tag=97 err=0 text= May 5 10:30:47 slave slapd[30408]: conn=47 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1 May 5 10:30:47 slave slapd[30408]: conn=47 op=2 PASSMOD id="uid=ryans,ou=Users,dc=example,dc=com" new May 5 10:30:47 slave slapd[30408]: conn=47 op=2 RESULT oid= err=8 text=only authenticated users may change passwords

1 0

(ITS#6544) how to implement password policy
by dsbrar16＠yahoo.com 05 May '10

05 May '10

Full_Name: Devender Singh Version: openldap 2.4.16 OS: RHEL5.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (122.177.190.226) Hello Dear, Please let me know, how to implement ppolicy in openldap2.4.16. I am using RHEL5.4 I have followed below steps on installation time: ************************************************** Installing BerkeleyDB ************************************************** 1) Create build_unix directory in /opt directory 2) Copy db-4.7.25.tar.gz to /opt/build_unix directory 3) Goto /opt/build_unix directory 4) gzip -d db-4.7.25.tar.gz 5) tar xvf db-4.7.25.tar 6) db-4.7.25/dist/configure 7) make 8) make install 9) vi /root/.bash_profile 10) Add below lines in .bash_profile of root user export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/BerkeleyDB.4.7/lib export LD_RUN_PATH=$LD_RUN_PATH:/usr/local/BerkeleyDB.4.7/lib 11) Close existing PUTTY and start new PUTTY ************************************************** Before Installation check the below packages: #rpm qa|grep openssl* After the above command if you dont find the all openssl packages than install them via yum command ************************************************** Installing OpenLDAP ************************************************** 1) Copy openldap-stable-20090411.tgz to /opt directory 2) gunzip -c openldap-stable-20090411.tgz | tar xf - 3) cd openldap-2.4.16 4) CPPFLAGS="-I/usr/local/BerkeleyDB.4.7/include -I/usr/local/ssl/include/openssl" 5) export CPPFLAGS 6) LDFLAGS="-L/usr/local/lib -L/usr/local/BerkeleyDB.4.7/lib -L/usr/local/ssl/lib -R/usr/local/lib -R/usr/local/BerkeleyDB.4.7/lib -R/usr/local/ssl/lib" 7) export LDFLAGS 8) LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.7/lib" 9) export LD_LIBRARY_PATH 10) ./configure 11) make depend 12) make 13) make install 14) vi /root/.bash_profile 15) Add OpenLDAP sbin path in .bash_profile of root user (E.g. export PATH=$PATH:$HOME/bin:/usr/local/sbin) 16) Close existing PUTTY and start new PUTTY ************************************************** Thanks in Advance. Regards, Devender Singh (+919818107222)

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

Ryan Steele wrote: > Actually, it would appear I'm hitting the same problem as the OP in this thread: > > http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require > authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results > > > I say that because when I get prompted for authentication by the slave (instead of having the referral handled > server-side), I see this corresponding entry in the master's logs: > > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND > May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed > > > So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down... > The same issue affects ldappasswd (it refuses to change the passwd because it thinks the user has not bound to the directory), so it's not just third party utilities. It really does appear as though the chain overlay is stripping the DN before sending the request out to the master, because the logs seem to indicate that the request makes it to the master and fails because there is no DN before a referral is presented to the client that initially sent the update to the slave. I added the 'ACL' loglevel to what I already use ('stats' and 'sync'), just to confirm that it is wasn't being denied by ACL's or anything like that. I do see references to the 'authzFrom' and 'authzTo' attributes in the admin guide's section on chaining, and on the FAQ (http://www.openldap.org/faq/data/cache/1425.html), but the example in test022-ppolicy does not use them, so I would not think that they are required or causing this problem. In any case, I did add olcDbIDAssertAuthzFrom: {0}"*" to the slaves (as the FAQ says) just to be absolutely sure, but it made no difference. I initially thought that the uncommenting of that check was responsible for this behavior, but the followup I sent just prior to this has a link to an OpenLDAP mailing list thread that was made in February, well before these changes that you made, Pierangelo. In either case, the behavior is broken. Exactly where, I'm still trying to figure out, but would definitely appreciate any input from more seasoned OpenLDAP developers.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

Actually, it would appear I'm hitting the same problem as the OP in this thread: http://markmail.org/message/fhfhzy5uehh6e4us#query:openldap chain "modifications require authentication"+page:1+mid:fhfhzy5uehh6e4us+state:results I say that because when I get prompted for authentication by the slave (instead of having the referral handled server-side), I see this corresponding entry in the master's logs: May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 ACCEPT from IP=10.x.x.x:45081 (IP=0.0.0.0:389) May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 BIND dn="" method=128 May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=0 RESULT tag=97 err=0 text= May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD dn="uid=ryans,ou=Users,dc=example,dc=com" May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 MOD attr=displayColor May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=1 RESULT tag=103 err=8 text=modifications require authentication May 4 12:22:43 ldap1 slapd[8794]: conn=226810 op=2 UNBIND May 4 12:22:43 ldap1 slapd[8794]: conn=226810 fd=50 closed So, it looks like the DN is not being passed through for some reason. Still working on trying to track it down...

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 04 May '10

04 May '10

After patching, and using the same configuration as I had when the chain overlay was causing issues with slapcat and restarting slapd, I now get prompted with a referral instead of it being automatically chased. However, it does automatically fill in the DN and password to rebind with: root@somehost:~# ldapvi -h localhost --bind=simple -D cn=admin,dc=example,dc=com -w `cat /etc/ldap.secret` --discover 159 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Received referral to ldap://ldapmaster.example.com/uid=ryans,ou=Users,dc=example,dc=com. You are not logged in to ldap://ldapmaster.example.com:389 yet. Type '!' or 'y' to do so. Rebind? [y!nB*qQ?] y --- Login Type M-h for help on key bindings. Filter or DN: cn=admin,dc=example,dc=com Password: *********** Bound as cn=admin,dc=example,dc=com. Done. Before, I never got prompted with this message when using ldapvi, which makes me think that chaining is no longer working. For reference, I am using the same configuration as is documented in test022-ppolicy: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}autogroup.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_ldap.la dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: ldap://ldapmaster.example.com olcDbIDAssertBind: bindmethod=simple binddn="cn=admin,dc=example,dc=com" credentials=SECRET mode=self I am still looking in to what might be causing this to fail.

1 0

(ITS#6247)
by daniel＠pluta.biz 03 May '10

03 May '10

I've enabled <g-differential> format as default for the Root-DSE's serverTime attribute (and thus removed the #ifdef CTM_G_DIFFERENTIAL_SERVERTIME). The updated patch can be downloaded from here: ftp://ftp.openldap.org/incoming/daniel-pluta-100503.patch Please use -DCTM during compilation. Below is a sample schema file called "example.schema" and some sample data called "example.ldif". In addition also some sample ldif change files and filter statements are provided to: - offer you some first, quick and easy testing possibilities regarding "LDAP server side current time matching"'s matching rules in action - and to give us a chance to get more detailed feedback regarding problems concerning the LDAP specification in common (e.g. violation of the standard) and slapd in detail. Many thanks! Depending on your feedback and the current status of the discussion on ldapext the code will be updated accordingly. It's currently just a prototype, the obviously open implementation TODOs are: - use operation's time-stamp instead of system calls (OpenLDAP 2.5?) - X.680 duration-syntax (instead of custom offset fun: "n#n#n#n#n#n") - further cleanups: function aggregation / coding style / ... - integration into "make test"? e.g. using FTPL: http://www.code-wizards.com/projects/libfaketime (?!) #========================================= $: cat example.schema attributetype ( 1.3.6.1.4.1.7650.666.1.1.1 NAME 'demoTs1' DESC 'draft-pluta-ldap-srv-side-current-time-match: 1st demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.7650.6.2.3.1.0 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.2 NAME 'demoTs2' DESC 'draft-pluta-ldap-srv-side-current-time-match: 2nd demo attribute' EQUALITY nowMatch ORDERING nowOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) attributetype ( 1.3.6.1.4.1.7650.666.1.1.3 NAME 'demoTs3' DESC 'draft-pluta-ldap-srv-side-current-time-match: 3rd demo attribute (violat es RFC4517)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) objectclass ( 1.3.6.1.4.1.7650.666.1.2.1 NAME 'ctmDemo' DESC 'draft-pluta-ldap-srv-side-current-time-match: demo objectClass' AUXILIARY MAY ( demoTs1 $ demoTs2 $ demoTs3 ) ) #==DATA======================================= $: cat example.ldif dn: dc=example,dc=com objectClass: domain objectClass: extensibleObject objectClass: top dn: ou=dev,dc=example,dc=com objectClass: organizationalUnit objectClass: top objectClass: ctmDemo ou: dev demoTs1: 20100101000000Z demoTs2: 20100101000000Z demoTs3: 20100101000000Z #==LDIF=CHANGE=FILES========================== $: cat add_delete.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 demoTs1: 20100101000000Z - add: demoTs1 demoTs1: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 demoTs2: 20100101000000Z - add: demoTs2 demoTs2: 20100201000001Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 demoTs3: 20100101000000Z - add: demoTs3 demoTs3: 20100201000001Z #----------------------------------------- $: cat add_mv.ldif dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs1 demoTs1: 20110201000000Z - add: demoTs1 demoTs1: 20120201000000Z - add: demoTs1 demoTs1: 20130201000000Z - add: demoTs1 demoTs1: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs2 demoTs2: 20110201000000Z - add: demoTs2 demoTs2: 20120201000000Z - add: demoTs2 demoTs2: 20130201000000Z - add: demoTs2 demoTs2: 20100201000000Z dn: ou=dev,dc=example,dc=com changetype: modify add: demoTs3 demoTs3: 20110201000000Z - add: demoTs3 demoTs3: 20120201000000Z - add: demoTs3 demoTs3: 20130201000000Z - add: demoTs3 demoTs3: 20100201000000Z #----------------------------------------- $: cat reset.ldif dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs1 - add: demoTs1 demoTs1: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs2 - add: demoTs2 demoTs2: 20100101000000Z dn: ou=dev,dc=example,dc=com changetype: modify delete: demoTs3 - add: demoTs3 demoTs3: 20100101000000Z #==FILTER=STATEMENTS====================== #BTW: You can use the FakeTime Preload Library #(link above) to easily fake slapd's time to #get constant results for automatic testing (demoTs1=20100101000000Z) (demoTs1<=NOW) (demoTs1>=NOW) (demoTs1>=-2#0#0#0#0#0) (demoTs2=20100101000000Z) (demoTs2<=NOW) (demoTs2>=NOW) (demoTs2<=0#-1#0#0#0#0) (demoTs3=20100101000000Z) #Only possible if compiled using: #-DRFC4517_ASSERTION_SYNTAX_VIOLATION (demoTs3<=NOW) (demoTs3>=NOW)

1 0

Re: (ITS#6543) make test failure
by quanah＠zimbra.com 03 May '10

03 May '10

--On Monday, May 03, 2010 3:50 PM +0000 sven.falempin(a)gmail.com wrote: > No race errors found after 10 iterations > Found 2 errors >>>>>>> Exiting with a false success status for now >>>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb. The point of these lines about exiting with false success is that you are to ignore the issue. I.e., please don't file a bug report about failure with test058. That's why it exits with "success". --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6543) make test failure
by sven.falempin＠gmail.com 03 May '10

03 May '10

Full_Name: Sven Version: 2.4.21 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.80.162.131) Using OpenBSD 4.3 or OpenBSD 4.7 with both bdb 4.6.21 and 5.0.21 The following test failed , to help reproduction i do a trick explained below: >>>>> Starting test058-syncrepl-asymmetric for hdb... running defines.sh Initializing master configurations... Initializing search configurations... Starting central master slapd on TCP/IP port 9011... [...] lots of output [...] Using ldapdelete to delete entry on site1 master... Starting central master again... Using ldapsearch to check that entry was deleted on central master... Using ldapsearch to check that entry was deleted on central search... No race errors found after 10 iterations Found 2 errors >>>>>> Exiting with a false success status for now >>>>> ./scripts/test058-syncrepl-asymmetric completed OK for hdb. To trigger the failure i do an ugly #find / | grep whatever

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 02 May '10

02 May '10

In regards to my X.501 comments, see "Matching Rule Requirements" = section of X.501(93). Note that only the 93 edition is normative here. I note that you actually need to specify the syntaxes and matching rules = in X.500 terms, and then simply specify a string representation for the = syntaxes for use in LDAP. See RFC 4521, Section 5.1 (for LDAP Syntaxes) = and 5.2 (for Matching Rules) and Section 5 more generally for schema. As far as your I-D goes, I currently deferring to Steve's initial review = at this early stage in its development because I'm busy and I trust = Steve to tease out any obvious ASN.1, X.500, and/or LDAP issues with = your I-D and to "educate" you as might be necessary. I'll join in = later, possibly after you revise your I-D once or twice to address = Steve's comments. -- Kurt=

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs