- openldap-bugs - openldap.org

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

raphael.ouazana(a)linagora.com wrote: > Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : >> adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" >> ldap_add: No such object (32) >> additional info: Parent does not exist >> >> which is erroneous. > > My new crystal ball tells me that you are not saying the essential part of > the problem: you are using back-ldif, isn't it ? Well, if Raphael's analysis is correct (in that case, can I borrow your crystal ball, occasionally?), the problem is now fixed in HEAD/re24/re23. Please test. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ando(a)sys-net.it"> > ghenry(a)OpenLDAP.org wrote: > >> >> "master and R1 slave databases differ" >> >> I'd like to learn how to debug this. Any tips? >> >> This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. > > Can't look at your tar right now; but: > > - check in scripts/test048* where the "master and R1 slave databases > differ" line is, and see what files are being tested > > - they probably are macros, defined in scripts/defines.sh, something > like testrun/ldif.flt and testrun/ldapsearch.flt yeah, did all that. It's one entry difference. server1.1.flt and server2.1.flt > > - run diff -iu FILE1 FILE2 as resolved above and see where it fails. > > If it points you somewhere (e.g. the difference is trivial, or there's > something very specific to a precise modification) fine, otherwise post > the outcome. Will check again on HEAD and continue. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠suretecsystems.com 10 Oct '07

10 Oct '07

<quote who="ghenry(a)OpenLDAP.org"> > Full_Name: Gavin Henry > Version: OPENLDAP_REL_ENG_2_4 > OS: Fedora 7 > URL: http://www.suretec.org/our_docs/test048.tar.gz > Submission from: (NULL) (80.229.93.1) > Submitted by: ghenry > > > I'm getting a fail at: > > "master and R1 slave databases differ" > > I'd like to learn how to debug this. Any tips? > > This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. > > Thanks. I'll double check this in HEAD now too. Should have done that first.

1 0

Re: (ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ando＠sys-net.it 10 Oct '07

10 Oct '07

ghenry(a)OpenLDAP.org wrote: > > "master and R1 slave databases differ" > > I'd like to learn how to debug this. Any tips? > > This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Can't look at your tar right now; but: - check in scripts/test048* where the "master and R1 slave databases differ" line is, and see what files are being tested - they probably are macros, defined in scripts/defines.sh, something like testrun/ldif.flt and testrun/ldapsearch.flt - run diff -iu FILE1 FILE2 as resolved above and see where it fails. If it points you somewhere (e.g. the difference is trivial, or there's something very specific to a precise modification) fine, otherwise post the outcome. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5182) test048 in OPENLDAP_REL_ENG_2_4
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Full_Name: Gavin Henry Version: OPENLDAP_REL_ENG_2_4 OS: Fedora 7 URL: http://www.suretec.org/our_docs/test048.tar.gz Submission from: (NULL) (80.229.93.1) Submitted by: ghenry I'm getting a fail at: "master and R1 slave databases differ" I'd like to learn how to debug this. Any tips? This is on a 64-Bit AMD machine, 2GB Ram, Berkeley 4.2.52. Thanks.

1 0

Re: (ITS#5172) slash in dn
by raphael.ouazana＠linagora.com 10 Oct '07

10 Oct '07

Le Mer 10 octobre 2007 02:31, reinhold.may(a)gmx.de a écrit : > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. My new crystal ball tells me that you are not saying the essential part of the problem: you are using back-ldif, isn't it ? Regards, Raphael Ouazana.

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

>> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > Oh, I've just checked. That's still not great. How about: <TITLE>OpenLDAP - community developed LDAP software</TITLE> -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 10 Oct '07

10 Oct '07

Kurt Zeilenga wrote: > Fixed. Many thanks. > > On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > >> Full_Name: Gavin Henry >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> Submitted by: ghenry >> >> >> We need a better title ;-) >> >> <TITLE>OpenLDAP, Title</TITLE> >> >> Gavin. >> >> >> > -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5172) slash in dn
by ando＠sys-net.it 10 Oct '07

10 Oct '07

reinhold.may(a)gmx.de wrote: > Pierangelo, > > First of all: Sorry, I've left in fact a paragraph in my .ldif example > that should have come out. > > I can reproduce what you've said and using the following code: > > #include <ldap.h> > #include <stdio.h> > > int main() { > char **c = ldap_explode_dn( > "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", > 1); > > int i; > for (i = 0; c[i] != 0; i++) { > printf("%s\n", c[i]); > } > > return 0; > } > > which correctly produces: > > cn=With/Slash > ou=My address book > dc=somedomain > dc=org > > And executing: > > # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > > produces the expected: > > DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded > normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> > pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> > > However, running the actual example produces the following full output: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" > ldap_add: No such object (32) > additional info: Parent does not exist > > which is erroneous. > > Just to check that it is the forward slash that must be to blame, here's > the full output of the counter check: > > $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif > Enter LDAP Password: > adding new entry "dc=somedomain,dc=org" > > adding new entry "ou=My address book,dc=somedomain,dc=org" > > adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" > > So, I still suspect a bug... This output is not useful. First of all, can you tell what ldapadd you're using? Please make sure you run the version of ldapadd that comes with OpenLDAP sources you built. Second, please provide an indication of what happens at the server side. Logs at "stats,trace" would be helpful. I can confirm that I can successfully add an entry whose RDN contains a slash "/" to OpenLDAP 2.3. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5172) slash in dn
by reinhold.may＠gmx.de 10 Oct '07

10 Oct '07

Pierangelo, First of all: Sorry, I've left in fact a paragraph in my .ldif example that should have come out. I can reproduce what you've said and using the following code: #include <ldap.h> #include <stdio.h> int main() { char **c = ldap_explode_dn( "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", 1); int i; for (i = 0; c[i] != 0; i++) { printf("%s\n", c[i]); } return 0; } which correctly produces: cn=With/Slash ou=My address book dc=somedomain dc=org And executing: # slapdn "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" produces the expected: DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> However, running the actual example produces the following full output: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_add: No such object (32) additional info: Parent does not exist which is erroneous. Just to check that it is the forward slash that must be to blame, here's the full output of the counter check: $ ldapadd -x -D 'cn=root,dc=somedomain,dc=org' -W -f test2.ldif Enter LDAP Password: adding new entry "dc=somedomain,dc=org" adding new entry "ou=My address book,dc=somedomain,dc=org" adding new entry "cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org" So, I still suspect a bug... Reinhold

1 0

Re: (ITS#5180) OpenLDAP Website Home Page
by kurt＠OpenLDAP.org 09 Oct '07

09 Oct '07

Fixed. On Oct 9, 2007, at 7:41 PM, ghenry(a)OpenLDAP.org wrote: > Full_Name: Gavin Henry > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > Submitted by: ghenry > > > We need a better title ;-) > > <TITLE>OpenLDAP, Title</TITLE> > > Gavin. > > >

1 0

(ITS#5181) ITS Copyright
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Copyright on ITS website page and ITS auto-replies is still at 2006: "Copyright 1998-2006 The OpenLDAP Foundation, All Rights Reserved."

1 0

(ITS#5180) OpenLDAP Website Home Page
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry We need a better title ;-) <TITLE>OpenLDAP, Title</TITLE> Gavin.

1 0

(ITS#5179) Weekly generation of Admin Guide for Website
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry Dear all, Not sure if I already requested this (can't find the ITS), but can we set up something to do a weekly doc generation for http://www.openldap.org/devel/admin/ Thanks.

1 0

Re: (ITS#4860) Sets' enhancement
by ghenry＠OpenLDAP.org 09 Oct '07

09 Oct '07

ando(a)sys-net.it wrote: >> Howard Chu a écrit : > >> Unfortunately, it's currently heavily dependant on one of our customer's >> specific schema extensions and data tree structure. The ACLs in use >> implement a lot of the logic specific to their environment, therefore I >> can't send them as is. >> >> However, I will see if I can "translate" some of the more complicated >> ACLs (with sets) to perform on a simple data set for inclusion in the >> test suite. >> >> Could some examples such as these also fit your documentation request >> for sets and their applications [1]? Assuming this is the case, I will >> try and provide at least a subset of our test set soon. >> >> Cheers, >> Jon >> >> [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html > > Let me state first that right now I believe sets do not belong to > slapd(8); they should rather move into a module, under the dynacl > umbrella. And, as such, they should be documented separately from > slapd.access(5), mostly because having them in slapd.access(5) would sort > of encourage unexperienced people into (ab-)using them. > > Also, I'd like sets' users to document them (especially in terms of useful > hints, scenarios, case studies and so), as they probably best know what > one can gain from their use. Otherwise, a bare description of the syntax, > although necessary, would hardly be useful to most of the users. > > p. > Agreed. Once decided, we can discuss where they would fit in the Admin guide. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5176) Segmentation Fault in test001-slapadd
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> Full_Name: Mark > Version: 2.3.38 > OS: Suse Linux 10.01 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.128.87.178) > > > ** Problem > test001-slapdadd fails with segmentation fault. > > ** Environment > Suse Linux 10.1 > Berkly DB 4.6.21 > Openldap 2.3.38 OpenLDAP 2.3 does not support Berkeley > 4.6.9; this issue has been risen dozens of times, but apprently browsing archives for known issues has become unfashionable. Please either upgrade to OpenLDAP 2.4 or downgrade to Berkeley < 4.6. This ITS will be closed. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5178) [feature request] pcache stats & monitoring
by ando＠sys-net.it 09 Oct '07

09 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando This is a feature request for stats and monitoring capabilities for pcache; basically: - the number of cached queries - the number of cached entries - possibly, a list of cached queries in cachedQueryURL form - how many times each cached query was used instead of re-running the request - the ratio answerable / cacheable for each cacheable query - some global figure like the average response time (send searchResult time - start caching time) for each query, and the overall average. Adding per-query info could be done by either extending the cachedQueryURL format or by adding a child entry for each cached query (like connections and other dynamic info). p.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> Howard Chu a écrit : > Unfortunately, it's currently heavily dependant on one of our customer's > specific schema extensions and data tree structure. The ACLs in use > implement a lot of the logic specific to their environment, therefore I > can't send them as is. > > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html Let me state first that right now I believe sets do not belong to slapd(8); they should rather move into a module, under the dynacl umbrella. And, as such, they should be documented separately from slapd.access(5), mostly because having them in slapd.access(5) would sort of encourage unexperienced people into (ab-)using them. Also, I'd like sets' users to document them (especially in terms of useful hints, scenarios, case studies and so), as they probably best know what one can gain from their use. Otherwise, a bare description of the syntax, although necessary, would hardly be useful to most of the users. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. Absolutely. Thanks... > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- -- Howard Chu Chief Architect, 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#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Got this one: it was a double-free in sets.c occuring after a >> slap_set_join() with lset or rset empty - the non empty set was >> returned, and then freed, causing a double-free error or segfault. >> >> The patch attached corrects this problem on RE23 and HEAD for me and >> doesn't have any side effects on our test set. However, it may not be >> the "right" way - please correct if necessary! > > Is your test set something you can clean up for inclusion in our test > suite? Unfortunately, it's currently heavily dependant on one of our customer's specific schema extensions and data tree structure. The ACLs in use implement a lot of the logic specific to their environment, therefore I can't send them as is. However, I will see if I can "translate" some of the more complicated ACLs (with sets) to perform on a simple data set for inclusion in the test suite. Could some examples such as these also fit your documentation request for sets and their applications [1]? Assuming this is the case, I will try and provide at least a subset of our test set soon. Cheers, Jon [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> jclarke(a)linagora.com a écrit : >> Pierangelo Masarati a écrit : >>> Should be fixed now in HEAD/re24/re23. Please test. p. >> >> I've been testing (at last, sorry for the delay), and I've come across >> another memory problem. Backtrace is below, and valgrind output is >> attached. > > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Thanks for spotting it - I had no time to look at your last report. I'll check the fix and eventually apply it. > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. Sure. Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Is your test set something you can clean up for inclusion in our test suite? > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. > > Jon -- -- Howard Chu Chief Architect, 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#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

This is a multi-part message in MIME format. --------------080102080503050601010703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit jclarke(a)linagora.com a écrit : > Pierangelo Masarati a écrit : >> Should be fixed now in HEAD/re24/re23. Please test. p. > > I've been testing (at last, sorry for the delay), and I've come across > another memory problem. Backtrace is below, and valgrind output is attached. Got this one: it was a double-free in sets.c occuring after a slap_set_join() with lset or rset empty - the non empty set was returned, and then freed, causing a double-free error or segfault. The patch attached corrects this problem on RE23 and HEAD for me and doesn't have any side effects on our test set. However, it may not be the "right" way - please correct if necessary! Your recent fixes have solved all the issues from our test cases we were encountering. Thank you very much for them. Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------080102080503050601010703 Content-Type: text/x-patch; name="jonathan-clarke-071008.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jonathan-clarke-071008.patch" --- servers/slapd/sets.c.orig 2007-10-08 18:20:08.000000000 +0200 +++ servers/slapd/sets.c 2007-10-08 18:22:29.000000000 +0200 @@ -261,11 +261,15 @@ } else { set = set_dup( cp, lset, SLAP_SET_LREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_LREFVAL | SLAP_SET_LREFARR; break; } } else if ( j == 0 ) { set = set_dup( cp, rset, SLAP_SET_RREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_RREFVAL | SLAP_SET_RREFARR; break; } --------------080102080503050601010703--

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 09 Oct '07

09 Oct '07

Philip Guenther wrote: > Anyway, this issue isn't worth keep an ITS open about, as it doesn't > actually cause failures or visible errors. I might someday chase down a > clean way of implementing this second option, but only after the much more > useful work of coming up with a reasonable API to let event-driven apps do > STARTTLS without blocking. Someday. Ah yes, Someday. Drop by this page when you get a chance: http://scratchpad.wikia.com/wiki/LDAP_C_API Some day it'll be more than just a single page... -- -- Howard Chu Chief Architect, 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#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 09 Oct '07

09 Oct '07

On Mon, 8 Oct 2007, Howard Chu wrote: ... >> There are a number of ways this can be handled: >> 1) change the client to wait until it sees the server's close_notify alert >> by >> replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: >> if (SSL_shutdown( p->ssl ) == 0) >> SSL_shutdown( p->ssl ); >> (I have confirmed that this works. As documented, the first call >> will return 1 if the server's close_notify has already been >> received, if not, the second call will block until it is received.) > > So if the server doesn't send one, the client will be stuck waiting forever? It would also unblock if the server closed the connection. One downside of this option that I thought of later is that it shifts the TCP CLOSE_WAIT state from the client to the server. Fixing that would add more complexity to the sockbuf layer than this entire change is worth. Having chatted with Kurt about this at the last IETF meeting and pondered failure modes, I'm no longer in favor of this option. >> 2) change the client to not bother to send a close_notify alert when >> it's just going to close() the connection; change the server to not >> send a close_notify if it didn't get one. <...> > > Sounds like a change in the SSL library, not something for us to worry > about. Since "send a close_notify alert" == "call SSL_shutdown() for the first time", it would be a change in how the SSL library was used by libldap. Anyway, this issue isn't worth keep an ITS open about, as it doesn't actually cause failures or visible errors. I might someday chase down a clean way of implementing this second option, but only after the much more useful work of coming up with a reasonable API to let event-driven apps do STARTTLS without blocking. Someday. Philip Guenther

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> The reason I reported it was that I wrote a parser for LDAP schema > based directly on the formal grammar, downloaded all the schema from > OpenLDAP as a test, and that was the only schema that broke, and only > on the one element. I did not have any trouble with the OpenLDAP > software accepting the schema. If you use a grammar builder (I used > ANTLR) rather than a hand-coded parser, being permissive makes it a > bit more complex. Allowing the elements to appear in any order would > be easy to parse for the RFC 4512 elements, because they happen to be > defined with markers ("NAME", "DESC" and so on) that makes them easy > to differentiate, but then enforcing at-most-once semantics on the > elements requires either an additional pass or some hand coded > predicates to check for duplicates in a data structure being built on- > the-fly. Thanks for the feedback. It's now fixed in HEAD/re24. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by bhanafee＠gmail.com 09 Oct '07

09 Oct '07

p., Thanks for looking at it. I think the RFC 4234 parse of the elements in the RFC 4512 definition would be as a 'concatenation' (based on rule->elements->alternation->concatenation). To get "any order" behavior under RFC 4234, I think the elements in the definition would be separated by '/' characters, and all the elements would be enclosed in a group with a repetition element. There's an example in the "Generalized Time" definition (RFC 4517, section 3.3.13) that shows why the optional members must be in sequence by default. In that particular case, the [fraction] can't be allowed to appear before the [minute ...] part, or it would be ambiguous whether the final "3015" in "2007100807.53015" was part of the fraction or a minute and second that appears (for no good reason) after the fraction ".5" The reason I reported it was that I wrote a parser for LDAP schema based directly on the formal grammar downloaded all the schema from OpenLDAP as a test. That was the only schema that broke, and only on the one element. I did not have any trouble with the OpenLDAP software accepting the schema. If you use a grammar builder (I used ANTLR) rather than a hand-coded parser, being permissive makes it a bit more complex. Allowing the elements to appear in any order would be easy to parse for the RFC 4512 elements, because they happen to be defined with markers ("NAME", "DESC" and so on) that makes them easy to differentiate, but then enforcing at-most-once semantics on the elements requires either an additional pass or some hand coded predicates to check for duplicates in a data structure being built on-the-fly. -- Brian On 10/8/07, Pierangelo Masarati <ando(a)sys-net.it> wrote: > Not sure if ordering of optional sequence members is required by RFC > 4234, but the change you suggest sounds harmless. OpenLDAP software, in > this sense, is usually permissive in what is accepted and strict in what > is emitted. > > Thanks, p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 09 Oct '07

09 Oct '07

guenther+ldapdev(a)sendmail.com wrote: > Full_Name: Philip Guenther > Version: 2.3.27 > OS: Linux and Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.58.1.252) > > > [I vaguely recall seeing a report of this issue in the archives of one of the > mailing lists, but I can no longer find the original.] > > If you trace the packets sent when you use, for example, ldapsearch against a > server on a different host, using either the -Z option to do TLS or using an > ldaps URI, you'll discover that the TCP connection is actually reset instead of > being closed cleanly: the client sends TCP RSTs in response to the server's > final packets. > > This is because libldap uses the following sequence when unbind a TLS or SSL > connection: > 1) send the unbind request (over the TLS or SSL layer) > 2) call SSL_shutdown(), sending the TLS close_notify alert > 3) call close() > > After receiving the close_notify alert from step (2), the server sends back its > own close_notify alert and then calls close(). However, because the client > didn't wait for the server's response before calling close() on its end, the > client's TCP stack considers the TCP connection to already be gone and responds > with the RST packets. This occurs with Linux and Solaris clients and probably > most other unices: the response to packets after a close() doesn't vary in my > experience. > > There are a number of ways this can be handled: > 1) change the client to wait until it sees the server's close_notify alert by > replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: > if (SSL_shutdown( p->ssl ) == 0) > SSL_shutdown( p->ssl ); > (I have confirmed that this works. As documented, the first call will return > 1 > if the server's close_notify has already been received, if not, the second > call > will block until it is received.) So if the server doesn't send one, the client will be stuck waiting forever? > 2) change the client to not bother to send a close_notify alert when it's just > going to close() the connection; change the server to not send a > close_notify > if it didn't get one. This probably violates the TLS spec, but the fact > that > TLS/1.1 permits resumption of sessions without close_notify having been sent > indicates that the violation is not a major issue, particularly given that > LDAP's > unbind request prevents truncation attacks. Close_notifies are, of course, > required if the client just wants to terminate the TLS layer and resume > unprotected LDAP operations. Sounds like a change in the SSL library, not something for us to worry about. > > 3) ignore the issue: it only causes one or two extra packets to be sent. While > it > also eliminates the TIME_WAIT state, LDAP's application-level close (the > unbind > request) means it doesn't need reliable full-duplex closure, so the only > concern > would be random connection issues from reincarnations of the TCP tuple, > which > is unlikely for an LDAP connection. > Personally, I like the simplicity and cleanliness of solution (1). (1) has the possibility of an indefinite hang. As such, I think it best to leave it with the current behavior. -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> One more thing to check is just using "ls -l" to see if the actual size of > the log files corresponds with the db_stat offsets. E.g. if slave6 base1's > log.0000001 is really 8MB but the LSN is only 233KB, then we have to look for > a weird in-memory corruption. If not, then somebody reset your logs. No, it looks like those sizes all match. Actually, the "reset logs" may well be the case (although I still can't imagine how, I'm willing to just chalk this whole thing up to user error...of course logs show that the user was me, which is a shame :) and is hard to disprove (with only one log file active) with the exception of base2. base2 has multiple log files going back: [slave4] -rw------- 1 root root 9999986 Sep 6 18:03 log.0000000001 -rw------- 1 root root 9999967 Sep 10 14:03 log.0000000002 -rw------- 1 root root 9999983 Sep 18 16:33 log.0000000003 -rw------- 1 root root 9429761 Oct 8 05:33 log.0000000004 [slave6] -rw------- 1 root root 9999986 Sep 6 18:03 log.0000000001 -rw------- 1 root root 9999967 Sep 10 14:03 log.0000000002 -rw------- 1 root root 9999983 Sep 18 16:33 log.0000000003 -rw------- 1 root root 9429761 Oct 8 05:33 log.0000000004 which of course match the db_stat -l, but also extend back prior to September 24 according to the filesystem timestamps. I guess the argument could be made that log 4 was truncated on September 24...would that be detected/come up sane/come up bad in the db_stat?

1 0

(ITS#5177) refreshAndPersist race condition
by hyc＠OpenLDAP.org 08 Oct '07

08 Oct '07

Full_Name: Howard Chu Version: 2.3/2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc If heavy Add traffic is occurring while a refreshAndPersist consumer is refreshing, newly added entries may be omitted from the refresh phase without being queued into the Persist phase. reported by stelios.xx.grigoriadis(a)ericsson.com http://www.openldap.org/lists/openldap-bugs/200709/msg00172.html

1 0

Sync replication failure during startup.
by Stelios Grigoriadis 08 Oct '07

08 Oct '07

OpenLDAP v. 2.3.32 Berkeley DB 4.6 gcc 4.1.0 Replication doesn't work if the master server is started after the replica servers and a large amount of simoultaneous updates are performed while the server is starting up. The entries that didn't get replicated to the replicas will not be replicated even after a restart of both master and replicas. The contextCSN is set to a value larger than the entryCSN of the "lost" entries. This is what I think happens during a master server startup with simoultaneous updates ongoing (and replicas trying to sync in the initial phase). Suppose that two clients (Client1 and Client2) are adding the entries a and b respectively. If that happens between t1 and t2 (one second between) they will get the same entryCSN (same timestamp). If entry a is committed at tc1 and b at tc2, any replica search inbetween will only get the entry a. The entry b will be lost. Client1 entry=a, csn=x Client2 entry=b, csn=x Timeline ------+----------+---------+----+------> | | t1 | | t2=t1+1 | | tc1=entry a tc2=entry b committed committed Replica search query between tc1 and tc2. I don't know if a higher granularity would prevent this, or even better, to have some kind of a counter so that every modification gets a unique csn. Can you please comment on our analyzis to let us know if the analyzis is correct or if we have missed something important? Any help or hints on how to avoid or fix this problem is greatly appreciated. If I receive useful information direcly in private email, I will post a summary. Regards Stelios Grigoriadis

4 23

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> It's still rather suspicious that slave4 and slave6 both had identical log >> status for base1 (1/188113) but different requested locations (1/8730339 vs >> 1/8730401). If they're identically configured slaves then they ought to be in >> lock-step. Then again, obviously they're not identical since slave6 doesn't >> show base4 in your log. > > Identical is relative. They've got the same OpenLDAP and supporting > binaries running on the same patches of Solaris 9 running identical > turn-up scripts with identical configuration files. But this is > production, so we've got data changes over time. For instance, the slaves > bootstrap with a slapadd -q, and the underlying slapcat could easily be > different from slave4 vs. slave6 (the most recent one is automatically > used). I'd imagine this would look different at the db layer, even once > syncrepl eventually converged the logical data? > >> Do you have the db_stat output from an uncorrupted slave? What about the >> master? > > Sure... https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl2 Judging from the LSNs in use on these other servers, it sure looks like somebody went in and zeroed out your logs on slave4 and slave6. I don't think the environment spontaneously corrupted itself and reset the log offsets... One more thing to check is just using "ls -l" to see if the actual size of the log files corresponds with the db_stat offsets. E.g. if slave6 base1's log.0000001 is really 8MB but the LSN is only 233KB, then we have to look for a weird in-memory corruption. If not, then somebody reset your logs. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5176) Segmentation Fault in test001-slapadd
by openldap＠consotec.de 08 Oct '07

08 Oct '07

Full_Name: Mark Version: 2.3.38 OS: Suse Linux 10.01 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.128.87.178) ** Problem test001-slapdadd fails with segmentation fault. ** Environment Suse Linux 10.1 Berkly DB 4.6.21 Openldap 2.3.38 ** Configuration of ldap configure --prefix=/usr --enable-debug ** Shared Library depency libdb-4.6.so => /usr/lib/libdb-4.6.so (0x40028000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x40169000) libdl.so.2 => /lib/libdl.so.2 (0x40182000) libresolv.so.2 => /lib/libresolv.so.2 (0x40185000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40197000) libc.so.6 => /lib/i686/libc.so.6 (0x401e9000) ** StackTrace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 28247)] 0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at ../lock/lock.c:740 740 no_dd = sh_locker->master_locker == INVALID_ROFF && (gdb) bt #0 0x400bd3bd in __lock_get_internal (lt=0x8215ae8, sh_locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, timeout=0, lock=0x40d8e50c) at ../lock/lock.c:740 #1 0x400bcc85 in __lock_get (dbenv=0x82154e8, locker=0x7, flags=0, obj=0x82168d4, lock_mode=DB_LOCK_READ, lock=0x40d8e50c) at ../lock/lock.c:447 #2 0x400ec2f7 in __db_lget (dbc=0x8216858, action=0, pgno=1, mode=DB_LOCK_READ, lkflags=0, lockp=0x40d8e50c) at ../db/db_meta.c:1012 #3 0x40054d7d in __bam_get_root (dbc=0x8216858, pg=1, slevel=1, flags=1409, stack=0x40d8e614) at ../btree/bt_search.c:94 #4 0x400551a4 in __bam_search (dbc=0x8216858, root_pgno=1, key=0x40d8e97c, flags=1409, slevel=1, recnop=0x0, exactp=0x40d8e818) at ../btree/bt_search.c:200 #5 0x40045160 in __bamc_search (dbc=0x8216858, root_pgno=0, key=0x40d8e97c, flags=26, exactp=0x40d8e818) at ../btree/bt_cursor.c:2486 #6 0x400411bc in __bamc_get (dbc=0x8216858, key=0x40d8e97c, data=0x40d8e95c, flags=26, pgnop=0x40d8e8ac) at ../btree/bt_cursor.c:961 #7 0x400da81d in __dbc_get (dbc_arg=0x8217158, key=0x40d8e97c, data=0x40d8e95c, flags=26) at ../db/db_cam.c:697 #8 0x400e7dfb in __dbc_get_pp (dbc=0x8217158, key=0x40d8e97c, data=0x40d8e95c, flags=26) at ../db/db_iface.c:2022 #9 0x080d455f in bdb_id2entry (be=0x7, tid=0x0, locker=7, id=1, e=0x40d8e9f8) at id2entry.c:125 #10 0x080cdabb in bdb_cache_find_id (op=0x822a638, tid=0x0, id=1, eip=0x40d8ea84, islocked=0, locker=7, lock=0x40d8eb1c) at cache.c:760 #11 0x080d12cd in bdb_dn2entry (op=0x822a638, tid=0x0, dn=0x0, e=0x40d8eb14, matched=1, locker=7, lock=0x40d8eb1c) at dn2entry.c:68 #12 0x080b4ae9 in bdb_search (op=0x822a638, rs=0x40e4fc9c) at search.c:374 #13 0x0805ec5b in fe_op_search (op=0x822a638, rs=0x40e4fc9c) at search.c:355 #14 0x0805e43f in do_search (op=0x822a638, rs=0x40e4fc9c) at search.c:217 #15 0x0805cae2 in connection_operation (ctx=0x7, arg_v=0x822a638) at connection.c:1133 #16 0x080fd514 in ldap_int_thread_pool_wrapper (xpool=0x81c0a88) at tpool.c:478 #17 0x4019cf60 in pthread_start_thread () from /lib/i686/libpthread.so.0 #18 0x4019d0fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0 #19 0x402c5327 in clone () from /lib/i686/libc.so.6 ** Description We added some printf's and found the that sh_locker has the value 0x7 which seems to be an index but not a valid lock for the database. Note: With the following modification the tests are running: File: servers/slapd/back-bdb/id2entry.c Line: 120 #if 0 /* Use our own locker if needed */ if ( !tid && locker ) cursor->locker = locker; #endif Any help is appriated Regards Mark

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> It's still rather suspicious that slave4 and slave6 both had identical log > status for base1 (1/188113) but different requested locations (1/8730339 vs > 1/8730401). If they're identically configured slaves then they ought to be in > lock-step. Then again, obviously they're not identical since slave6 doesn't > show base4 in your log. Identical is relative. They've got the same OpenLDAP and supporting binaries running on the same patches of Solaris 9 running identical turn-up scripts with identical configuration files. But this is production, so we've got data changes over time. For instance, the slaves bootstrap with a slapadd -q, and the underlying slapcat could easily be different from slave4 vs. slave6 (the most recent one is automatically used). I'd imagine this would look different at the db layer, even once syncrepl eventually converged the logical data? > Do you have the db_stat output from an uncorrupted slave? What about the > master? Sure... https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl2

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> itself. Again, we can't really tell without single-stepping thru the BDB >> library code. It may not be worth the effort, but that's your call. > > The lock was > > env_region.c:290 MUTEX_LOCK(dbenv, &renv->mutex); > > but that wasn't making much sense....and after a couple minutes in dbx I > realized that I've been killing myself with the attempts at db_stat. > Yesterday's attempts were running db_* binaries with a wrong (but > compatible) ABI. It'd be nice if Sleepycat had some more/earlier checks > for that, but oh well... Kinda figured that that's what happened. > So anyway, I corrupted base2/slave4 by running the wrong db_stat, but that > left three other bases on slave4 and all three bases on slave6. I ran > db_stat -l on them, the output is: > > https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl > BTW, this ABI screwup shouldn't be the root cause of the failures...I > haven't tried any db tools until the course of debugging this. These are > AUTOREMOVE, so db_archive is unlikely, for instance. It's still rather suspicious that slave4 and slave6 both had identical log status for base1 (1/188113) but different requested locations (1/8730339 vs 1/8730401). If they're identically configured slaves then they ought to be in lock-step. Then again, obviously they're not identical since slave6 doesn't show base4 in your log. Do you have the db_stat output from an uncorrupted slave? What about the master? -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> itself. Again, we can't really tell without single-stepping thru the BDB > library code. It may not be worth the effort, but that's your call. The lock was env_region.c:290 MUTEX_LOCK(dbenv, &renv->mutex); but that wasn't making much sense....and after a couple minutes in dbx I realized that I've been killing myself with the attempts at db_stat. Yesterday's attempts were running db_* binaries with a wrong (but compatible) ABI. It'd be nice if Sleepycat had some more/earlier checks for that, but oh well... So anyway, I corrupted base2/slave4 by running the wrong db_stat, but that left three other bases on slave4 and all three bases on slave6. I ran db_stat -l on them, the output is: https://www.nbcs.rutgers.edu/~richton/its5171_dbstatl BTW, this ABI screwup shouldn't be the root cause of the failures...I haven't tried any db tools until the course of debugging this. These are AUTOREMOVE, so db_archive is unlikely, for instance.

1 0

Re: (ITS#5050) array bounds violation in test045-syncreplication-proxied
by hyc＠symas.com 08 Oct '07

08 Oct '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE23 > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > syncprov + back-ldap, and presumably + back-meta if that were used, > give an array bounds violation in test045-syncreplication-proxied: > > syncprov_db_open() uses connection_fake_init(), which sets op->o_tag=0. > It passes op to back-ldap. > > ldap_back_op_result() assumes op is a known LDAP request: It calls > slap_req2op() and gets SLAP_OP_LAST (for unknown tag). That is used as > an index into ldapinfo_t.li_timeout[], which has size SLAP_OP_LAST. > > back-meta/bind.c does the same in meta_back_bind_op_result() and > meta_back_op_result(). I fixed back-ldap but I believe the same fix is still needed in back-meta. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5175) After 6 times authenticate sucessfully.Open LDAP is failing
by pattanaikhr＠gmail.com 08 Oct '07

08 Oct '07

Full_Name: HR Pattanaik Version: 2.2.29 OS: Windows XP Professional URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.126.136.220) When I have sign in my authentication page .It's successfully authenticate 5-6 times after that it's failing . I have searched lot of forums But I didn't get any solution for that. So I have raised this issues on your web site. Hopefully I'll get any solutions for that.Please reply me I have mention my exception is here.Please follows below. javax.naming.ServiceUnavailableException: localhost: 389; socket closed

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by ando＠sys-net.it 08 Oct '07

08 Oct '07

Not sure if ordering of optional sequence members is required by RFC 4234, but the change you suggest sounds harmless. OpenLDAP software, in this sense, is usually permissive in what is accepted and strict in what is emitted. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5164) slapi plugins prevent slapd starting.
by m.d.t.evans＠qmul.ac.uk 08 Oct '07

08 Oct '07

On Sun, 2007-10-07 at 16:29 -0700, Howard Chu wrote: > m.d.t.evans(a)qmul.ac.uk wrote: > > Full_Name: Martin Evans > > Version: 2.4.5beta > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (138.37.8.140) > > > > > > This is mentioned in #4611 but marked as fixed there. > > Now fixed in HEAD. > Thanks! I spotted your fixes to slapi/plugin.c, back-monitor/conn.c and back-monitor/database.c applied these to my version of 2.4.5beta and they seem to work fine. Martin. -- -- Dr MDT Evans, Computing Services, Queen Mary, University of London

1 0

(ITS#5174) openldap.schema entry not valid per RFC 4512
by bhanafee＠gmail.com 08 Oct '07

08 Oct '07

Full_Name: Brian Hanafee Version: 1.24.2.2 OS: Mac OS/X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.4.251.75) The final definition in /servers/slapd/schema/openldap.schema is not valid per RFC 4512. It reads: objectClass ( OpenLDAPobjectClass:6 NAME 'OpenLDAPdisplayableObject' DESC 'OpenLDAP Displayable Object' MAY displayName AUXILIARY ) Per RFC 4512, section 4.1.1, the 'kind' AUXILIARY comes before any MUST or MAY entries. The corrected entry should read: objectClass ( OpenLDAPobjectClass:6 NAME 'OpenLDAPdisplayableObject' DESC 'OpenLDAP Displayable Object' AUXILIARY MAY displayName )

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

richton(a)nbcs.rutgers.edu wrote: >> If this is happening even with slapd cleanly shut down then it should also >> prevent slapd from restarting, since slapd first attempts to join an existing >> environment before trying to create a new one. And that really implies that >> the rest of the environment is shot. > > Agreed, but that's a pretty awful condition to have in a long-running > slapd process. Without db_stat (easily) working, is there any hope at > finding clues as to how this might have happened, or is it just time to > rm/slapadd and hope it doesn't happen again? It doesn't seem like we can get much more info out of this. One more thing to try would be a full-debug build of libdb, so we can see exactly where it hangs when trying to join the environment. Looking thru the code, I only see one mutex to acquire the environment, and looking at your stack trace it's already past that location, but the trace could be lying. Also the mutex used to lock the environment is a regular mutex, not a persistent lock. So when all processes have closed the environment, there shouldn't be anything left to conflict with here. So most likely the environment data structures are hosed, and the thread is locking against itself. Again, we can't really tell without single-stepping thru the BDB library code. It may not be worth the effort, but that's your call. -- -- Howard Chu Chief Architect, 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#5173) Cannot add pcache to config
by hyc＠symas.com 08 Oct '07

08 Oct '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: RE23/RE24/HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (76.168.84.21) > Submitted by: hyc > > > As reported by Ralf here > http://www.openldap.org/lists/openldap-devel/200709/msg00036.html > > Fixed in HEAD But the same problem also occurs with the translucent overlay... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5173) Cannot add pcache to config
by hyc＠OpenLDAP.org 08 Oct '07

08 Oct '07

Full_Name: Howard Chu Version: RE23/RE24/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc As reported by Ralf here http://www.openldap.org/lists/openldap-devel/200709/msg00036.html Fixed in HEAD

1 0

Re: (ITS#5171) hdb txn_checkpoint failures
by richton＠nbcs.rutgers.edu 08 Oct '07

08 Oct '07

> (Of course, if you only appended to /etc/hosts then the old address is still > in there and getting used first..) "files dns" in nsswitch.conf, and no prior /etc/hosts entry. i.e., this overrode DNS to the 192.168.* interface. netstat shows that (by now, at least) this has completely taken. > If this is happening even with slapd cleanly shut down then it should also > prevent slapd from restarting, since slapd first attempts to join an existing > environment before trying to create a new one. And that really implies that > the rest of the environment is shot. Agreed, but that's a pretty awful condition to have in a long-running slapd process. Without db_stat (easily) working, is there any hope at finding clues as to how this might have happened, or is it just time to rm/slapadd and hope it doesn't happen again?

1 0

Re: (ITS#4884) Back-config inheritance issue
by hyc＠symas.com 08 Oct '07

08 Oct '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD (re23,...) > OS: irrelevant > URL: > Submission from: (NULL) (87.28.220.33) > Submitted by: ando > > > I think I've spotted a potential issue in back-config. When creating a custom > object, say an overlay, the configuration objectClass should inherit from > olcOverlayConfig. While adding the object via LDAP, however, if the ancestor > class is not explicitly listed, the derived object must provide a co_ldadd() > hook, otherwise addition fails. > Currently, the code uses all defined objectClasses and stops the first time a > hook is available and it does not fail. That was of course the designed and desired behavior... > It would be more sound, IMHO, to have something like: > > - if the structural objectClass provides a co_ldadd() hook, use it; it is that > hook's responsibility to call the superior's one if required; > > - if it doesn't, then climb the inheritance tree and call co_ldadd() for the > first occurrence of a valid one. The point is that structural classes are not the only ones that matter here, and if you're creating an entry that has a special class, you must provide the necessary handlers for that class. Climbing the inheritance tree seems an ok convenience for entries that don't explicitly list all their superior classes, but that should not have precluded the existing behavior (checking all of the explicitly listed classes, whether they are structural or auxiliary). -- -- Howard Chu Chief Architect, 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#4884) Back-config inheritance issue
by hyc＠symas.com 08 Oct '07

08 Oct '07

ando(a)sys-net.it wrote: > I've committed to HEAD a fix that exploits inheritance. The rationale is: > > - lookup the structural objectClass; starting from it, check it and > subordinates for a function that successfully adds the entry > > - using all objectClass values, collect all, including ancestors, that > may be of use in checking configuration. > > Passes all tests (049->051), and allows to add an overlay using only the > overlay's objectClass, provided it's derived from olcOverlayConfig. > > Please test. p. Something's wrong here, it's only checking structural classes but not auxiliary classes. This breaks proxycache now, which uses an auxiliary class for the ldadd hook when adding its private DB. -- -- Howard Chu Chief Architect, 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#5171) hdb txn_checkpoint failures
by hyc＠symas.com 08 Oct '07

08 Oct '07

Aaron Richton wrote: >> No. The BDB transaction log files don't know (or care) anything about IP >> addresses. Nothing at the slapd layer could have any direct effect on the BDB >> transaction logs. How exactly did you reconfigure the servers, did you stop >> them and restart them or did you use cn=config? > > echo 192.blahblah master.r.e >> /etc/hosts > > The master changed from 128.blahblah to 192.blahblah. Same physical > machine, just different interface. On slave4 and 6, I didn't touch slapd. (Of course, if you only appended to /etc/hosts then the old address is still in there and getting used first..) >> Might as well get the db_stat -l output for a few of them to compare. > > This isn't going well at all; they just can't join the environment. I > tried on slave1, it hung. I tried on slave4 under truss, it hung. (We're > talking >30 minutes here.) Although I swear I've run db_stat hot, I killed > db_stat (ungracefully, sadly) and stopped slapd (gracefully) on slave1, > ran db_stat again, and it hung there...and corrupted the environment to > the point where I couldn't get db_recover/slapd to run. (I ended up > blowing the slave1 database away; it's refreshing from syncrepl now.) > I've got a few more slaves that I haven't shot in the foot yet, and I only > tried this on one of the suffixes on slave{1,4}. Plenty of more > opportunities to screw this up yet if there's anything to try...I suppose > I could go for -N, or if the command line is going to be a pain, I could > join the slapd process with dbx and print ->log_stat myself (although I > might need a bit of hand holding on that)... > > [the hang on slave4] > db_stat -> libdb-4.2.so:*db_env_create(0xffbffaec, 0x0, 0x17154) > lwp_mutex_lock(0xFF0D0000) (sleeping...) > mutex type: USYNC_PROCESS > > ff307248 __db_des_get (29ac0, 29d78, 29d78, ffbff9d0, 0, ffbff9d9) + c0 > ff305780 __db_e_attach (29ac0, ffbffa94, 40400, 40000, 33e021, 29d71) + 6e0 > ff2ff434 __dbenv_open (29ac0, 0, 40400, 0, 0, 0) + 664 > 00016514 db_init (29ac0, 0, 4, 100000, ffbffba0, ff3deb54) + 64 > 00011e3c main (2, ffbffc44, ffbffc50, 29800, 0, 0) + 9a4 > 00011470 _start (0, 0, 0, 0, 0, 0) + 108 If this is happening even with slapd cleanly shut down then it should also prevent slapd from restarting, since slapd first attempts to join an existing environment before trying to create a new one. And that really implies that the rest of the environment is shot. -- -- Howard Chu Chief Architect, 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#5164) slapi plugins prevent slapd starting.
by hyc＠symas.com 08 Oct '07

08 Oct '07

m.d.t.evans(a)qmul.ac.uk wrote: > Full_Name: Martin Evans > Version: 2.4.5beta > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (138.37.8.140) > > > This is mentioned in #4611 but marked as fixed there. Now fixed in HEAD. -- -- Howard Chu Chief Architect, 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#5172) slash in dn
by ando＠sys-net.it 07 Oct '07

07 Oct '07

reinhold.may(a)gmx.de wrote: > I'm fairly new to OpenLDAP and hope I've not misunderstood things... in that > case: sorry. > > I've been trying to import the following .ldif: > > dn: dc=somedomain,dc=org > objectclass: top > objectclass: dcObject > objectclass: organization > o: somedomain LDAP > dc: somedomain > > dn: ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: My address book > > dn: ou=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: organizationalUnit > ou: Medical > > dn: cn=With/Slash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: With/Slash > sn: With/Slash The above LDIF is inconsistent: the "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" entry is repeated, and in the first occurrence it is inconsistent: the distinguished value "With/Slash" is not present in the entry, there's a "Medical" instead. I suspect you messed things up when sanitizing your data. > > The "/" results into the following error message: > > ldap_add: No such object (32) > additional info: Parent does not exist This error means that the parent of the entry you're trying to add does not exist. Here "parent" means the entry immediately below the one you're trying to add, so assuming you're trying to add "cn=With/Slash,ou=My address book,dc=somedomain,dc=org", what appears to be missing is "ou=My address book,dc=somedomain,dc=org". Are you sure it exists? By looking at the server's logs at "stats,trace" level, can you tell what DN is being looked up for the parent? > If my last entry reads: > > dn: cn=WithoutSlash,ou=My address book,dc=somedomain,dc=org > objectclass: top > objectclass: person > objectclass: organizationalPerson > objectclass: inetOrgPerson > objectclass: mozillaAbPersonAlpha > cn: WithoutSlash > sn: WithoutSlash > > slapd accepts the entry and adds it to its directory. > > I've read RFCs 2849 (about LDIF) and 2253 (about DNs) and can't even find "/" to > be a special character. But just in case it was forgotten, I tried to represent > it as "\/" and "\2f" but neither solution helped. Yes, it's not. Using OpenLDAP 2.3 code, I can correctly parse the DN you suspect to trigger the unexpected behavior you reported: $ slapdn 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' DN: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> check succeeded normalized: <cn=with/slash,ou=my address book,dc=somedomain,dc=org> pretty: <cn=With/Slash,ou=My address book,dc=somedomain,dc=org> $ ./libraries/libldap/dntest 'cn=With/Slash,ou=My address book,dc=somedomain,dc=org' ldap_rdn2str() = "cn=With/Slash" ldap_rdn2str() = "ou=My address book" ldap_rdn2str() = "dc=somedomain" ldap_rdn2str() = "dc=org" ldap_dn2str(ldap_str2dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org")) = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2domain("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org" ldap_dn2ufn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "With/Slash, My address book, somedomain.org" ldap_dn2dcedn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash" ldap_dcedn2dn("/dc=org/dc=somedomain/ou=My address book/cn=With\/Slash") = "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ldap_dn2ad_canonical("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") = "somedomain.org/My address book/With\/Slash" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org"): "cn=With/Slash" ldap_explode_rdn("cn=With/Slash") 'cn=With/Slash' ldap_explode_rdn("cn=With/Slash") (no types) "With/Slash" "ou=My address book" ldap_explode_rdn("ou=My address book") 'ou=My address book' ldap_explode_rdn("ou=My address book") (no types) "My address book" "dc=somedomain" ldap_explode_rdn("dc=somedomain") 'dc=somedomain' ldap_explode_rdn("dc=somedomain") (no types) "somedomain" "dc=org" ldap_explode_rdn("dc=org") 'dc=org' ldap_explode_rdn("dc=org") (no types) "org" ldap_explode_dn("cn=With/Slash,ou=My address book,dc=somedomain,dc=org") (no types): "With/Slash" "My address book" "somedomain" "org" "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" == "cn=With/Slash,ou=My address book,dc=somedomain,dc=org" ? yes p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs