- openldap-bugs - openldap.org

ITS#6375
by masarati＠aero.polimi.it 13 Nov '09

13 Nov '09

The ITS is to track software bugs. Please direct software usage questions to <openldap-solftware(a)openldap.org> and software interoperation questions to <openldap-technical(a)openldap.org>. This ITS will be closed. p.

1 0

(ITS#6375) Master Replica Synchronization
by jose.oliveira＠mailondemand.com.pt 13 Nov '09

13 Nov '09

Full_Name: Jose Vicente Fonseca de Oliveira Version: 2.4.11-1 OS: Debian 5.03 URL: ftp://mailondemand.com.pt Submission from: (NULL) (81.193.248.175) Dear Team, We have a PineApp antispam appliance that can authenticate users with our LDAP master server but cannot authenticate users with our LDAP replica server. For us everything seems OK but PineApp appliance just can't authenticate with our replica. PineApp refuses to give us further help saying that something is wrong in LDAP replication. Please, could you help us with that issue: the replica has the same information that master server has? We thank OpenLDAP Team in advance. Best regards, Jose Oliveira

1 0

Re: (ITS#6374) LDAP
by michael＠stroeder.com 12 Nov '09

12 Nov '09

atzig(a)mail2tim.com wrote: > Full_Name: Tim > Version: ? > OS: Win2003 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.62.17.129) > > > "Error 10: Referral" > > Unable to perform LDAP search - Error 10: Referral > This error means that the user's record in Active Directory was located on some > other server. > A "referral" in LDAP is simply a pointer or redirection to some other location > (or server). The "Error 10: Referral" error is usually caused by a misconfigured > LDAPBaseDN setting > > > LDAP was working correctly...started to receive this error after upgrading from > win2003 AD to Win2008. Could you please elaborate on what's the issue is with OpenLDAP client libs and/or tools? Ciao, Michael.

1 0

(ITS#6374) LDAP
by atzig＠mail2tim.com 12 Nov '09

12 Nov '09

Full_Name: Tim Version: ? OS: Win2003 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.62.17.129) "Error 10: Referral" Unable to perform LDAP search - Error 10: Referral This error means that the user's record in Active Directory was located on some other server. A "referral" in LDAP is simply a pointer or redirection to some other location (or server). The "Error 10: Referral" error is usually caused by a misconfigured LDAPBaseDN setting LDAP was working correctly...started to receive this error after upgrading from win2003 AD to Win2008.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

--001636988beae98b80047830ba81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable pitpalme(a)gmail.com wrote: > masarati(a)aero.polimi.it wrote: > > pitpalme(a)gmail.com wrote: >> >> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >>> >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. >> > > That=92s korrekt. > > > I inferred that you checked about the existence of the object and you go= t >> a negative result. >> > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just che= ck if > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > > > Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. >> > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles m= e. > We don=92t actually neither have =84multi master mode=93, but =84mirror m= ode=93 and > writes are done only on exactly one server, so there should not be a prob= lem > with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check i= t is > is, simply because I have to little knowledge to read debug log correctly= . Follow up: I modified my test Perl script to do a 'ldapSearch' after deleting and it returns zero as number of found entries. Sadly I have no idea, how to emulate '-MM' when using 'Net::LDAP' and it's search function, so I can't check for 'glue' entries this way. --=20 Regards, Peter --001636988beae98b80047830ba81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><span dir=3D"ltr"><a href=3D"mailto:pitpalme@gma= il.com">pitpalme(a)gmail.com</a></span>=A0wrote:<br><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex;"><div class=3D"im"> <a href=3D"mailto:masarati@aero.polimi.it" target=3D"_blank">masarati(a)aero.= polimi.it</a> wrote:<br> <br> </div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <a href=3D"mailto:pitpalme@gmail.com" target=3D"_blank">pitpalme(a)gmail.com<= /a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I do see attributes reflecting state after "modify" (which change= s<br> "sn" attribute).<br> Where exactly should I expect to see a note about "glue state"?<b= r> Is output from "-d Any" helpful to figure what's going on (or= wrong)?<br> </blockquote> <br> My understanding of your previous message was that you got a positive<br> result from delete, but an "Already exists" from a subsequent add= .<br> </blockquote> <br></div> That=92s korrekt.<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I inferred that you checked about the existence of the object and you got<b= r> a negative result.<br> </blockquote> <br></div> In my current test scenario I do not check.<br> I assume a non-error on =84delete=93 in fact =84deletes=93, so I just check= if response<br> code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91= ).<div class=3D"im"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Apparently, my guess was wrong. =A0In that case, you probably hit<br> ITS#6097 <<a href=3D"http://www.openldap.org/its?findid=3D6097" target= =3D"_blank">http://www.openldap.org/its?findid=3D6097</a>>.<br> </blockquote> <br></div> *hmmm* Good idea, thanks.<br> But after reading ITS description I don=92t think it=92s =A0what troubles m= e.<br> We don=92t actually neither have =84multi master mode=93, but =84mirror mod= e=93 and writes are done only on exactly one server, so there should not be= a problem with second server producing a concurrent write/modify.<br> I=92d expect the delete to be correctly propagated, but I can=92t check it = is is, simply because I have to little knowledge to read debug log correctl= y.</blockquote></div><div><br></div>Follow up:<div><br></div><div>I modifie= d my test Perl script to do a 'ldapSearch' after deleting and it re= turns zero as number of found entries.</div> <div>Sadly I have no idea, how to emulate '-MM' when using 'Net= ::LDAP' and it's search function, so I can't check for 'glu= e' entries this way.</div><div>-- <br>Regards, <div>Peter</div></div> --001636988beae98b80047830ba81--

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 12 Nov '09

12 Nov '09

masarati(a)aero.polimi.it wrote: > pitpalme(a)gmail.com wrote: > >> I do see attributes reflecting state after "modify" (which changes >> "sn" attribute). >> Where exactly should I expect to see a note about "glue state"? >> Is output from "-d Any" helpful to figure what's going on (or wrong)? > > My understanding of your previous message was that you got a positive > result from delete, but an "Already exists" from a subsequent add. That=92s korrekt. > I inferred that you checked about the existence of the object and =20 > you got > a negative result. In my current test scenario I do not check. I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = check if =20 response code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > Apparently, my guess was wrong. In that case, you probably hit > ITS#6097 <http://www.openldap.org/its?findid=3D6097>. *hmmm* Good idea, thanks. But after reading ITS description I don=92t think it=92s what troubles = me. We don=92t actually neither have =84multi master mode=93, but =84mirror = mode=93 =20 and writes are done only on exactly one server, so there should not be =20= a problem with second server producing a concurrent write/modify. I=92d expect the delete to be correctly propagated, but I can=92t check = it =20 is is, simply because I have to little knowledge to read debug log =20 correctly. =97 Regards, Peter

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 12 Nov '09

12 Nov '09

pitpalme(a)gmail.com wrote: > I do see attributes reflecting state after "modify" (which changes > "sn" attribute). > Where exactly should I expect to see a note about "glue state"? > Is output from "-d Any" helpful to figure what's going on (or wrong)? My understanding of your previous message was that you got a positive result from delete, but an "Already exists" from a subsequent add. I inferred that you checked about the existence of the object and you got a negative result. Apparently, my guess was wrong. In that case, you probably hit ITS#6097 <http://www.openldap.org/its?findid=6097>. p.

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme＠gmail.com 11 Nov '09

11 Nov '09

masarati(a)aero.polimi.it wrote: > pitpalme+openldap(a)gmail.com wrote: >> [...] >> When adding, modifying and deleting an entry it can happend I do >> get a positive >> return from delete, but a subsequent "add" fails with "code=68: >> Already >> exists". > > Can you check whether the entry actually exist, although in "glue" > state? You can do this by searching (e.g. with ldapsearch) as the > rootdn, to bypass access checking, and using the manageDSAit control > (-MM). I modified my test perl script to exit if adding the entry failed, albeit a preceding delete should have removed it. Then I manually ran ldapsearch -D "rootdn" ... -b "TestBaseDN" -MM "cn=TestEntry" I got ==== 8>< ========================== [...] # with manageDSAit critical control [...] dn: cn=TestEntry,TestBaseDN objectClass: inetOrgPerson description: oldValue [...] # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ==== 8>< ========================== I do see attributes reflecting state after "modify" (which changes "sn" attribute). Where exactly should I expect to see a note about "glue state"? Is output from "-d Any" helpful to figure what's going on (or wrong)? -- Regards, Peter

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 11 Nov '09

11 Nov '09

On Nov 11, 2009, at 9:45 AM, Quanah Gibson-Mount wrote: > --On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan = <bduncan(a)apple.com> wrote: >=20 >>=20 >> On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: >>=20 >>> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan >>> <bduncan(a)apple.com> wrote: >>>=20 >>>=20 >>>> It was tested on OS X 10.6. Should work on all BSDs; nothing >>>> OSX-specific about the kqueue usage in the patch. As far as kqueue >>>> support in OS X 10.5, from what I see, most everything is there. >>>> Certainly all of the kqueue features in this patch are supported in = OS X >>>> 10.5. >>>=20 >>> Hi Bryan, >>>=20 >>> The URL to the patch you submitted with this ITS doesn't work. Can = you >>> please put the patch somewhere accessible and let us know where it = is? >>>=20 >>> Thanks, >>> Quanah >>=20 >> Hi Quanah, >>=20 >> My apologies for the bad URL. >>=20 >> The new URL is: >> http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If = you >> use a web browser to get it, there are extra steps: select the file >> "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl = can >> pull it down directly with no extra steps. >=20 > Hi Bryan, >=20 > Thanks for the quick response. Hopefully we can get this incorporated = for OpenLDAP 2.5 series, and I'm interested in playing with it against = 2.4 to see how things change when used with Mac. >=20 > Thanks! >=20 > --Quanah Awesome! I look forward to seeing it OpenLDAP. If there's anything I = can do to help, please let me know. Thanks.=20 -- Bryan

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 11 Nov '09

11 Nov '09

--On Wednesday, November 11, 2009 9:36 AM -0800 Bryan Duncan <bduncan(a)apple.com> wrote: > > On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: > >> --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan >> <bduncan(a)apple.com> wrote: >> >> >>> It was tested on OS X 10.6. Should work on all BSDs; nothing >>> OSX-specific about the kqueue usage in the patch. As far as kqueue >>> support in OS X 10.5, from what I see, most everything is there. >>> Certainly all of the kqueue features in this patch are supported in OS X >>> 10.5. >> >> Hi Bryan, >> >> The URL to the patch you submitted with this ITS doesn't work. Can you >> please put the patch somewhere accessible and let us know where it is? >> >> Thanks, >> Quanah > > Hi Quanah, > > My apologies for the bad URL. > > The new URL is: > http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If you > use a web browser to get it, there are extra steps: select the file > "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl can > pull it down directly with no extra steps. Hi Bryan, Thanks for the quick response. Hopefully we can get this incorporated for OpenLDAP 2.5 series, and I'm interested in playing with it against 2.4 to see how things change when used with Mac. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6300) Add kqueue support to slapd
by bduncan＠apple.com 11 Nov '09

11 Nov '09

On Nov 11, 2009, at 9:04 AM, Quanah Gibson-Mount wrote: > --On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan = <bduncan(a)apple.com> wrote: >=20 >=20 >> It was tested on OS X 10.6. Should work on all BSDs; nothing >> OSX-specific about the kqueue usage in the patch. As far as kqueue >> support in OS X 10.5, from what I see, most everything is there. >> Certainly all of the kqueue features in this patch are supported in = OS X >> 10.5. >=20 > Hi Bryan, >=20 > The URL to the patch you submitted with this ITS doesn't work. Can = you please put the patch somewhere accessible and let us know where it = is? >=20 > Thanks, > Quanah Hi Quanah, My apologies for the bad URL. The new URL is: = http://public.me.com/bryan.duncan/bryan-duncan.kqueue.090922.patch If you use a web browser to get it, there are extra steps: select the = file "bryan-duncan.kqueue.090922.patch" and click download. ftp & curl = can pull it down directly with no extra steps. -- Bryan=

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠zimbra.com 11 Nov '09

11 Nov '09

--On Tuesday, September 22, 2009 2:40 PM -0700 Bryan Duncan <bduncan(a)apple.com> wrote: > It was tested on OS X 10.6. Should work on all BSDs; nothing > OSX-specific about the kqueue usage in the patch. As far as kqueue > support in OS X 10.5, from what I see, most everything is there. > Certainly all of the kqueue features in this patch are supported in OS X > 10.5. Hi Bryan, The URL to the patch you submitted with this ITS doesn't work. Can you please put the patch somewhere accessible and let us know where it is? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

10 Nov '09

--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * mbackes(a)symas.com <mbackes(a)symas.com> [2009-11-10 22:55:10 +0000]: > Hello, Aleksey. >=20 > > Openldap 2.4.19 installed from freebsd ports. All configs in defauls = =20 > > Freebsd 7.2 amd64 Slapd built with the "-g" flag and install with =20 > > the make install STRIP=3D"" >=20 > Okay. >=20 > > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. >=20 > > libdb-4.6.so.0 =3D> /usr/local/lib/libdb-4.6.so.0 (0x800a97000) >=20 > At the same time? Your ldd list below shows only berkeley db 4.6. =20 > These don't mix... Not same time. I tried with both backends. Results are same. >=20 > > In slapd config added using hdb as backend and indexes. Testing =20 > > database consist of 1000 users accounts with minimum attributes. On = =20 > > stress test load slapd Segmentation fault in 10-30 sec. >=20 > What sort of operations? Reading (Binds and searches).=20 Test script is loop of id command checking ldap via nss_ldap. >=20 > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 0x803404560 (LWP 100116)] > > 0x0000000802d5aa4b in hdb_idl_fetch_key (be=3DError accessing memory = =20 > > address > > 0x7ffffd9f9f38: Bad s. > > ) at idl.c:511 >=20 > Does it always fail at the same location? How reproducible is this? Often it is fail in "hdb_idl_fetch_key (be=3DError accessing memory address= ". 100% Reproducible on different hardware. On our normal work, slapd fails every 2-3 hours, on stress test slapd fail in 10-30 sec. Problem on freebsd7.x,8 and openldap2.3.43,2.4.18,2.4.19=20 I tryed on debian lenny and openldap2.4.11 and netbsd5.0.1 and openldap2.4.16 it rock stable. I think problem some where in freebsd and bdb backends.=20 Because freebsd7.1 openldap2.3.43 with depricated ldbm don`t fail on reading.=20 Ask if need any information.=20 Also I can give a shell access to testing server. =20 >=20 > Matthew Backes > Symas Corporation > mbackes(a)symas.com --=20 Email: alexs(a)ulgsm.ru Email/Jabber: alexs(a)ulgsm.ru --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iQEcBAEBAgAGBQJK+lahAAoJELAIdrQw5JcdnyYIAJrpD8OhUgzabzlAfcSmOZhH XUM+vzujX4N/czArACk/dXibX3D2AqQxv1CeUs0pI7Bo+iHLG0gsP6UD8k1fvDEg NecNe1zigD7JEGJDetHTMSXHjYkOvSJsqdBcWjNPuJZn62mg5hVs0S3XdGtqMRxw 4Ck+MwyWiAVQmCDYaXSCEEl6IyGehtD6f5liyNVakHIHG7bZ5MFSm0yP2oMtgxw2 W5vY7nUYK7w3l8ZXqx5pyjQBVBHoUCLFaqHXdXTcBHe3WJ2TQMx6utyvWi3uuqaR HFmg2NMvJSVnTnQsscxZgd2qILAmAx0SE2wd4D312ywsYZvFSGkzjX50JNpklT0= =s9Mn -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--

1 0

ITS#5944 configure options --program-prefix and --program-suffix
by hyc＠symas.com 10 Nov '09

10 Nov '09

The OpenLDAP configure script and Makefiles don't do anything with these options. Sounds like you're looking at a RedHat-specific issue. 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

(ITS#6373) syncrepl subentry support
by hyc＠OpenLDAP.org 10 Nov '09

10 Nov '09

Full_Name: Howard Chu Version: 2.4/HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc As discussed in this email thread http://www.openldap.org/lists/openldap-software/200910/msg00059.html in some situations it's necessary to store the syncrepl contextCSNs in a subentry of the database, instead of the context entry. Syncrepl in 2.2 used to do this but most of that code was removed in 2.3. It needs to be resurrected and usable as an option.

1 0

Re: (ITS#6312)
by hyc＠symas.com 10 Nov '09

10 Nov '09

neustradamus(a)hotmail.com wrote: > --_add76be3-02e1-47b1-b978-259bce59b479_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > > You must change in configure and \include\PORTABLE.H : > > #define vsnprintf _vsnprintf > > with > > #if _MSC_VER < 1500 // 1500 =3D=3D VC++ 9.0 > #define vsnprintf _vsnprintf > #endif > > or > > #if _MSC_VER < 1500 > #define vsnprintf _vsnprintf > #endif You reported this issue against 2.2.16, which is several years obsolete. (Current version is 2.4.19.) The configure script has checked for vsnprintf and _vsnprintf for many years; it will not setup this #define if it doesn't need to. Closing this ITS. -- -- 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#6309) missing SEARCH information
by hyc＠symas.com 10 Nov '09

10 Nov '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.18 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > I see the following logged at level 256: > > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 ACCEPT from > IP=171.67.219.70:51122 (IP=0.0.0.0:389) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=0 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=1 RESULT tag=97 err=14 > text=SASL(0): successful result: > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND dn="" method=163 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > authcid="service/vacation(a)stanford.edu" authzid="service/vacation(a)stanford.edu" > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 BIND > dn="cn=vacation,cn=service,cn=applications,dc=stanford,dc=edu" mech=GSSAPI > sasl_ssf=56 ssf=56 > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=2 RESULT tag=97 err=0 text= > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 do_search: invalid dn > (basedn) > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 op=3 SEARCH RESULT tag=101 err=34 > nentries=0 text=invalid DN > Sep 28 17:35:23 ldap1 slapd[18015]: conn=409 fd=117 closed (connection lost) > > > Since the actual search is not logged, there is no way to determine what the > invalid DN being used is in this case. This seems faulty. I'd expect to see > some additional logging like: The invalid DN *was* logged, it was "basedn". Sounds like you have a really badly configured client out there somewhere. Closing this ITS... -- -- 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#6372) slapd lockup on shutdown
by quanah＠zimbra.com 10 Nov '09

10 Nov '09

Full_Name: Quanah Gibson-Mount Version: 2.4.19 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Had an idle slapd lock up during shutdown. Backtrace as follows: Thread 10 (process 627): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=2) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #5 <signal handler called> #6 0x0000003c0c706ffb in pthread_join () from /lib64/tls/libpthread.so.0 #7 0x0000002a956b2408 in ldap_pvt_thread_join (thread=1082132832, thread_return=0x0) at thr_posix.c:197 #8 0x0000000000431c8c in slapd_daemon () at daemon.c:2835 #9 0x00000000004146d8 in main (argc=10, argv=0x7fbfffae38) at main.c:950 Thread 9 (process 637): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 8 (process 636): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #4 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #5 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #6 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #7 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 7 (process 635): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 6 (process 634): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 5 (process 633): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 4 (process 632): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 3 (process 631): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 2 (process 630): #0 0x0000003c0c7089ba in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/tls/libpthread.so.0 #1 0x0000002a956b24b0 in ldap_pvt_thread_cond_wait (cond=0x932030, mutex=0x932008) at thr_posix.c:277 #2 0x0000002a956b0fbf in ldap_int_thread_pool_wrapper (xpool=0x932000) at tpool.c:672 #3 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #4 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6 Thread 1 (process 629): #0 0x0000003c0c70b04f in __write_nocancel () from /lib64/tls/libpthread.so.0 #1 0x0000000000431d3e in slap_sig_shutdown (sig=15) at daemon.c:2926 #2 <signal handler called> #3 0x0000003c0c70b04d in __write_nocancel () from /lib64/tls/libpthread.so.0 #4 0x000000000042d17d in slapd_clr_write (s=4113, wake=1) at daemon.c:951 #5 0x0000000000433ae8 in connection_wake_writers (c=0x1451ec0) at connection.c:778 #6 0x0000000000433c40 in connection_closing (c=0x1451ec0, why=0x4e3ee2 "slapd shutdown") at connection.c:806 #7 0x00000000004322bb in connections_shutdown () at connection.c:209 #8 0x0000000000431b31 in slapd_daemon_task (ptr=0x0) at daemon.c:2761 #9 0x0000003c0c70610a in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000003c0b8c68c3 in clone () from /lib64/tls/libc.so.6

1 0

Re: (ITS#6362) slapd 2.4.19 Segmentation fault under load
by mbackes＠symas.com 10 Nov '09

10 Nov '09

Hello, Aleksey. > 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="" Okay. > Used backends db46-4.6.21.4, db47-4.7.25.4 latest from freebsd ports. > libdb-4.6.so.0 => /usr/local/lib/libdb-4.6.so.0 (0x800a97000) At the same time? Your ldd list below shows only berkeley db 4.6. These don't mix... > 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. What sort of operations? > 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 Does it always fail at the same location? How reproducible is this? Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

(ITS#6371) problem with ber_flatten2
by dave.daugherty＠centrify.com 10 Nov '09

10 Nov '09

Full_Name: Dave Daugherty Version: 2.2.6 and 2.4.17 OS: RedHat EL3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.170.119.248) We use ber_flatten2 in an unusual way, but I think this issue is generic int ber_flatten2( BerElement *ber, struct berval *bv, int alloc ) { /* copy the berval */ ber_len_t len = ber_pvt_ber_write( ber ); if ( alloc ) { bv->bv_val = (char *) ber_memalloc_x( len + 1, ber->ber_memctx ); if ( bv->bv_val == NULL ) { return -1; } AC_MEMCPY( bv->bv_val, ber->ber_buf, len ); } else { bv->bv_val = ber->ber_buf; } bv->bv_val[len] = '\0'; <- ???? bv->bv_len = len; The problem I have is a crash, because of the bv->bv_val[len] = \0 when alloc is set to zero, AND the buffer that was passed in was generated by ber_realloc, which did not leave an extra byte at the end, resulting in a write beyond the allocated memory block. The questions I have are: 1) Is the zero terminator really necessary? 2) If so, seems like it should only be done if we actually allocated a new buffer (which does leave one byte at the end).

1 0

Re: (ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

Fixed in HEAD, servers/slapd/overlays/syncprov.c 1.289 -> 1.290 Please test. The fix should apply smoothly to recent 2.4 releases. Thanks for reporting, p.

1 0

(ITS#6370) Error converting syncprov-checkpoint option to olcSpCheckpoint attribute
by kblaney＠nortel.com 10 Nov '09

10 Nov '09

Full_Name: Kyle Blaney Version: 2.4.15 OS: Redhat Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.11.182.187) In OpenLDAP 2.4.19, values change when converting from the syncprov-checkpoint option in file-based configuration to the olcSpCheckpoint attribute in online configuration. To reproduce: 1. Configure OpenLDAP using file-based slapd.conf configuration that contains the following line: syncprov-checkpoint 100 10 2. Make slapd.d directory. 3. Convert file-based configuration to online configuration using the following command: slapd -f slapd.conf -F slapd.d File-based configuration is converted to the cn=config database, but after conversion the value of the olcSpCheckpoint attribute in the "olcOverlay={1}syncprov,olcDatabase={1}bdb,cn=config entry" is "100 600" when it should be the same as in file-based configuration ("100 10").

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by masarati＠aero.polimi.it 10 Nov '09

10 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Full_Name: Peter Palmreuther > Version: 2.4.19 > OS: FreeBSD 7.2 / Solaris 8 > URL: > Submission from: (NULL) (87.123.91.4) > > > I've set up OpenLDAP to run in "MirrorMode": > > # [...] > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > # [...] > syncrepl rid=001 > provider=ldap://localhost:11389 > type=refreshAndPersist > searchbase="o=esolution,dc=deutscherv,dc=de" > schemachecking=on > bindmethod=simple > binddn="cn=MirrorMode,o=esolution,dc=deutscherv,dc=de" > credentials="M1rr0rM3" > retry="60 +" > > serverID 1 > mirrormode on > # [...] > > The second server is set up identically, except "serverID" is 2 and "provider" > is set to URL of first server. The fact addresses are "localhost" is because I > replicated my main setup on my private server (FreeBSD) to better inspect and > debug the problem. > > When adding, modifying and deleting an entry it can happend I do get a positive > return from delete, but a subsequent "add" fails with "code=68: Already > exists". Can you check whether the entry actually exist, although in "glue" state? You can do this by searching (e.g. with ldapsearch) as the rootdn, to bypass access checking, and using the manageDSAit control (-MM). p.

1 0

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

10 Nov '09

Hi, I've uploaded a cleaned up version. It's nearly a complete rewrite of the original contribution. In addition to the previous version which (intentionally) just supported the constant MRA "NOW" the updated version also supports now[+/-]offset calculation and matching. The offset's syntax is "NYears#Nmonths#Ndays#NHours#NMinutes#NSeconds" where '#' separates the different time unit fields and N is the amount of time (offset) for a distinct time unit. N can be a negative or positive value (all none-digits and blanks are ignored, multiple signs are simply aggregated to a single (the first from the left) sign). Thanks to previous normalization before the actual matching the "timedrift effect" (see followup #4 above) isn't present any more, too. The two matching rule's (nowOrEarlier/nowOrLaterMatch) are compatible with any generalizedTime-syntax based attribute. Additionally the module introduces two specialized syntaxes exclusively dedicated to this modules matching rules (intentionally not supporting any kind of generalizedTime[Ordering]Match-ing extensible match). Please have a look at the README, the sample schema definition, and/or the source for further details. The current version can be found here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-091110-1.tgz Any kind of feedback is very welcome. Thanks a lot! Daniel

1 0

(ITS#6369) Get rid of cacertdir_rehash
by FullName＠in-valid.com 10 Nov '09

10 Nov '09

Full_Name: Full Name Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:708:10:10:21c:25ff:fe98:3f0e) It is inconvenient to have to use cacertdir_rehash command to hash the certs. IMO it does not service any purpose. It would be nice if cert could be just dropped to a dir and then openldap sees it.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs