- openldap-bugs - openldap.org

Re: (ITS#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 24 Feb '07

24 Feb '07

cyril wrote: > The message is located in > > isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) > > located in file bin/named/dlz_ldap_driver.c provided by > ctrix_dlz_9.3.3.patch OK. In your initial posting you claimed to be using bind 9.3.4, I assume you patched 9.3.4 with 9.3.3 patch. Anyway, in that patch I still don't see the message you reported; did you copy it verbatim, or did you elaborate it?. Anyway, that patch looks definitely similar to the analogous code in bind 9.4.0. That code seems to make use of LDAP URLs only as a means to define a LDAP search in compact form; but URLs have a specific syntax with restrictions, as indicated in RFC4516 and RFC3986; pretending to parse them with standards compliant library functions while they don't comply with their definition sounds a bit hazardous. In any case, it's astonishing that the URL syntax is used along with a marker for macro replacement that's the most reserved char in URLs. Sounds like someone chose the largest available gun to shoot in his own foot. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 24 Feb '07

24 Feb '07

Il s'agit d'un message ` parties multiples au format MIME. ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI =20 -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it]=20 Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 =20 cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; = but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a = bind > problem. > However, I will transmit this information to the BIND/DLZ team. =20 I have few more comments; see below. =20 =20 > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or = %client%) is >> replaced with the ns domain (the client name). >>=20 >> It was working well since I upgrade to 2.3.30-r2. =20 There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. This is a Gentoo relase based on 2.3.30 (the latest relase available is 2.3.33) =20 Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex = values". =20 The message is located in =20 isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg) located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch =20 Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? =20 =20 p. =20 =20 =20 Ing. Pierangelo Masarati OpenLDAP Core Team =20 SysNet s.n.c. 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 ------------------------------------------ =20 ------=_NextPart_000_0163_01C75810.9E49DBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)"> <style>  </style>  </head> <body lang=3DFR link=3Dblue vlink=3Dpurple> <div class=3DSection1> FYI<o:p></o:p> <o:p> </o:p> -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoy=E9 : vendredi 23 f=E9vrier 2007 22:02 =C0 : cyril(a)coupel.net Cc : openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with = bind9<o:p></o:p> <o:p> </o:p> cyril(a)coupel.net wrote:<o:p></o:p> > Tanks for your answer.<o:p></o:p> > I tested by removing the %xxxx% from the = URL and the tests are passed; but<o:p></o:p> > there is an error saying that there is no = %xxx% token.<o:p></o:p> > I already open a case to the BIND team, but = they reply this is not a bind<o:p></o:p> > problem.<o:p></o:p> > However, I will transmit this information = to the BIND/DLZ team.<o:p></o:p> <o:p> </o:p> I have few more comments; see = below.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> > Cyril COUPEL wrote:<o:p></o:p> >> I agree with this = information.<o:p></o:p> >> The fact is the ldapURL is not used as = it, the key %zone% (or %client%) is<o:p></o:p> >> replaced with the ns domain (the client = name).<o:p></o:p> >><o:p> </o:p> >> It was working well since I upgrade to 2.3.30-r2.<o:p></o:p> <o:p> </o:p> There is no = OpenLDAP 2.3.30-r2; the current version is 2.3.34.<o:p></o:p> This = is a Gentoo relase based on 2.3.30 (the latest relase available is = 2.3.33)<o:p></o:p> <o:p> </o:p> Also, you mentioned an error message = "failed to parse ldap URL"; there's<o:p></o:p> no such message in bind 9.3.4 code, nor in = 9.4.0rc2.=A0 Also, there's no<o:p></o:p> explicit ldap_url_parse() call, so the problem = could only arise when<o:p></o:p> performing an operation with that broken DN.=A0 = However, I don't see how<o:p></o:p> the error message could be raised by bind, since = the URL is parsed by<o:p></o:p> bind itself, without using the OpenLDAP API = function, and the DN is only<o:p></o:p> used as base for other operations, so OpenLDAP = API cannot have any<o:p></o:p> notion of that DN being part of an URL.=A0 = Finally, bind itself, while<o:p></o:p> parsing the URL, checks for badly encoded = portions of the URL, and the<o:p></o:p> corresponding error message is "LDAP sdb = zone '%s': URL: bad hex values".<o:p></o:p> <o:p> </o:p> The = message is located in =A0=A0=A0 <o:p></o:p> isc_result_t dlz_ldap_checkURL(char *URL, int attrCnt, const char *msg)<o:p></o:p> located in file bin/named/dlz_ldap_driver.c provided by ctrix_dlz_9.3.3.patch<o:p></o:p> <o:p> </o:p> Could you point us to the __real__ version of = OpenLDAP __and__ bind you<o:p></o:p> pretend to be broken?<o:p></o:p> <o:p> </o:p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Ing. Pierangelo Masarati<o:p></o:p> OpenLDAP Core Team<o:p></o:p> <o:p> </o:p> SysNet s.n.c.<o:p></o:p> Via Dossi, 8 - 27100 Pavia - = ITALIA<o:p></o:p> http://www.sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > Office:=A0=A0 +39.02.23998309<o:p></o:p> Mobile:=A0=A0 +39.333.4963172<o:p></o:p> Email:=A0=A0=A0 = pierangelo.masarati(a)sys-net.it<o:p></o:p> ------------------------------------------<o:p></o:p= > <o:p> </o:p> </div> </body> </html> ------=_NextPart_000_0163_01C75810.9E49DBB0--

1 0

Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

ando(a)sys-net.it wrote: >> # No limits for CNO-LDC >> limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited >> time=unlimited > > Is this "time=unlimited" starting in the first column a wrap of the > mailer or is it really there? Something absurd is happening: that limit > option starting in the first column is a syntax error, but 2.3 ignores > it. What's odd is that with this syntax error I exactly get your crash, > while without it I don't get any crash. The above had nothing to do with your problem. Your problem is related to the fact that you intermixed overlay and database configuration statements, so the idletimeout statement after the accesslog overlay instantiation was causing invalid memory write (beyond the private data of the accesslog overlay instead of in the private data of the bdb database) resulting in heap corruption. Maybe it hasn't been stressed enough, but the order of directives is: - global [- global overlay [- global overlay [...] ]] [- database [- overlay [- overlay [...] ]] [- database [- overlay [- overlay [...] ]]]] and each overlay's directives have to appear before any other overlay's. I'll see if sanity checks may be added to avoid your issue. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Just one quick question: > # No limits for CNO-LDC > limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited > time=unlimited Is this "time=unlimited" starting in the first column a wrap of the mailer or is it really there? Something absurd is happening: that limit option starting in the first column is a syntax error, but 2.3 ignores it. What's odd is that with this syntax error I exactly get your crash, while without it I don't get any crash. >From valgrind, there appears to be some invalid write and an invalid free. I keep investigating... p. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4848) Another slapd startup segfault
by ando＠sys-net.it 24 Feb '07

24 Feb '07

michael.heep(a)o2.com wrote: > Full_Name: Michael Heep > Version: 2.3.34 > OS: RHES30 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.113.101.1) Few preliminary comments: 1) could easily reproduce 2) doesn't core with HEAD/2.4 code 3) you probably don't need the unique overlay on the consumer, since it's supposed to trust consistency of data coming from the producer The direct cause of the crash is that the LDAPDN structure that's being used to rebuild a normalized string representation of the unique_base is corrupted. I'm investigating how it got corrupted. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

cyril(a)coupel.net wrote: > Tanks for your answer. > I tested by removing the %xxxx% from the URL and the tests are passed; but > there is an error saying that there is no %xxx% token. > I already open a case to the BIND team, but they reply this is not a bind > problem. > However, I will transmit this information to the BIND/DLZ team. I have few more comments; see below. > Cyril COUPEL wrote: >> I agree with this information. >> The fact is the ldapURL is not used as it, the key %zone% (or %client%) is >> replaced with the ns domain (the client name). >> >> It was working well since I upgrade to 2.3.30-r2. There is no OpenLDAP 2.3.30-r2; the current version is 2.3.34. Also, you mentioned an error message "failed to parse ldap URL"; there's no such message in bind 9.3.4 code, nor in 9.4.0rc2. Also, there's no explicit ldap_url_parse() call, so the problem could only arise when performing an operation with that broken DN. However, I don't see how the error message could be raised by bind, since the URL is parsed by bind itself, without using the OpenLDAP API function, and the DN is only used as base for other operations, so OpenLDAP API cannot have any notion of that DN being part of an URL. Finally, bind itself, while parsing the URL, checks for badly encoded portions of the URL, and the corresponding error message is "LDAP sdb zone '%s': URL: bad hex values". Could you point us to the __real__ version of OpenLDAP __and__ bind you pretend to be broken? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4850) back-meta stops returning data
by ando＠sys-net.it 23 Feb '07

23 Feb '07

hyc(a)symas.com wrote: >> I am experiencing problems with back_meta. It does return search results for >> some time, but at some point starts returning empty search results, with SEARCH >> RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 >> minutes. > > Significant changes were made to back-meta between 2.3.32 and 2.3.33. The > current version is 2.3.34. Please upgrade and see if the issue is still present. I believe the reported behavior does no longer occur with 2.3.34. What you report seems to be related to broken behavior when the remote server closes the connection as a consequence of an idletimeout. 2.3.33 saw a lot of improvements on this side, resulting from significant development efforts and stress testing in a harsh environment, where resilience to odd target behavior was a key requirement. 2.3.34 fixed minor issues after that upgrade, and more minor fixes already are in re23 for next 2.3 release, if any. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

quanah(a)stanford.edu wrote: > --On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > >> It might be nice to set up an automated script to pull the updated >> manpages from CVS onto the web site. > >>From CVS for the current primary release. I.e., I think it would be bad if > the manpages for 2.4 showed up right now on the website. You'll note that the web site has a selector for the release you want to view. In some respects I like the old pages being on there because their dates establish a ballpark for when a feature first appeared (well, was first documented). But I think we should always have a "Current" selection as well, that always corresponds to the latest general-use release. -- -- 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#3812
by quanah＠stanford.edu 23 Feb '07

23 Feb '07

--On Friday, February 23, 2007 7:27 PM +0000 hyc(a)symas.com wrote: > It might be nice to set up an automated script to pull the updated > manpages from CVS onto the web site. >From CVS for the current primary release. I.e., I think it would be bad if the manpages for 2.4 showed up right now on the website. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

ITS#3812
by hyc＠symas.com 23 Feb '07

23 Feb '07

It might be nice to set up an automated script to pull the updated manpages from CVS onto the web site. -- -- 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="Howard Chu"> > ghenry(a)suretecsystems.com wrote: >> <quote who="ando(a)sys-net.it"> >>> ghenry(a)suretecsystems.com wrote: >>> >>>> Just a quick to note that there are some overlays missing from >>>> slapd.overlays.5 >>>> in 2.4.4alpha and actual man pages. >>> Please enumerate them; some are intentionally not present because they >>> are not intended for real use. >> >> * dyngroup has no man page, but is listed slapd.overlays.5 >> * slapo-valsort.5 isn't in slapd.overlays.5 >> * slapo-dds.5 isn't listed in slapd.overlays.5 >> * constraint.c has no docs or listed in slapd.overlays.5 > > slapo-constraint.5 was added to CVS April 29 2006. Ok, it wasn't in the 2.4.4alpha though. > >> * seqmod.c has no docs or listed in slapd.overlays.5 > > This is a demo overlay, not intended for actual use. Ah, ok. > > -- > -- 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#4850) back-meta stops returning data
by hyc＠symas.com 23 Feb '07

23 Feb '07

ulf.moeller(a)secardeo.com wrote: > Full_Name: Ulf Moeller > Version: 2.3.32 > OS: SLES 9 > URL: > Submission from: (NULL) (62.245.244.226) > > > I am experiencing problems with back_meta. It does return search results for > some time, but at some point starts returning empty search results, with SEARCH > RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 > minutes. Significant changes were made to back-meta between 2.3.32 and 2.3.33. The current version is 2.3.34. Please upgrade and see if the issue is still present. -- -- 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#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 23 Feb '07

23 Feb '07

Full_Name: Ulf Moeller Version: 2.3.32 OS: SLES 9 URL: Submission from: (NULL) (62.245.244.226) I am experiencing problems with back_meta. It does return search results for some time, but at some point starts returning empty search results, with SEARCH RESULT err=32 in the logfile. This often (but not always) happens after 5 - 30 minutes. It doesn't return data from either of the ldap servers it is connected to. The problem also occurs in a minimal configuration with just one "uri" defined. After slapd is restarted, it again works properly for some time. When running in GDB, I get the following backtrace: Program received signal SIGPIPE, Broken pipe. 0xffffe410 in __kernel_vsyscall () (gdb) bt #0 0xffffe410 in __kernel_vsyscall () #1 0x4003a55b in __write_nocancel () from /lib/tls/libpthread.so.0 #2 0x08127f34 in sb_stream_write (sbiod=0x81e69c0, buf=0x81deb60, len=64) at sockbuf.c:521 #3 0x081287b6 in sb_debug_write (sbiod=0x81e69d8, buf=0x81deb60, len=64) at sockbuf.c:820 #4 0x08127e50 in ber_int_sb_write (sb=0x81e6d38, buf=0x81deb60, len=64) at sockbuf.c:431 #5 0x08124dd6 in ber_flush (sb=0x81e6d38, ber=0x81e6e40, freeit=0) at io.c:232 #6 0x08111813 in ldap_int_flush_request (ld=0x81e6c00, lr=0x81dfb88) at request.c:151 #7 0x08111c1a in ldap_send_server_request (ld=0x81e6c00, ber=0x81e6e40, msgid=21, parentreq=0x0, srvlist=0x0, lc=0x81dfb40, bind=0x0) at request.c:301 #8 0x081117ca in ldap_send_initial_request (ld=0x81e6c00, msgtype=99, dn=0x40a1300c "", ber=0x81e6e40, msgid=21) at request.c:135 #9 0x08104661 in ldap_search_ext (ld=0x81e6c00, base=0x40a1300c "", scope=2, filter=0x81e6e18 "(mail=someone(a)domain.de)", attrs=0x0, attrsonly=0, sctrls=0x0, cctrls=0x0, timeout=0x40a10f18, sizelimit=500, msgidp=0x81e6b60) at search.c:109 #10 0x080c8194 in meta_back_search_start (op=0x40c007b0, rs=0x40a12210, dc=0x40a110f0, msc=0x81e6bb8, candidate=0, candidates=0x81e6b58) at search.c:208 #11 0x080c83f3 in meta_back_search (op=0x40c007b0, rs=0x40a12210) at search.c:285 #12 0x08063944 in fe_op_search (op=0x40c007b0, rs=0x40a12210) at search.c:355 #13 0x08063465 in do_search (op=0x40c007b0, rs=0x40a12210) at search.c:217 #14 0x08061180 in connection_operation (ctx=0x40a122a0, arg_v=0x40c007b0) at connection.c:1132 #15 0x0810052f in ldap_int_thread_pool_wrapper (xpool=0x81b8b18) at tpool.c:478 #16 0x40035cf7 in start_thread () from /lib/tls/libpthread.so.0 #17 0x400fa21e in clone () from /lib/tls/libc.so.6 #18 0x40a12bb0 in ?? () Here is an (anonymized) log: Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: >>> slap_listener(ldap://:3389) Feb 22 15:16:17 server slapd[14494]: daemon: listen=8, new connection on 11 Feb 22 15:16:17 server slapd[14494]: daemon: added 11r (active) listener=(nil) Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 ACCEPT from IP=127.0.0.1:34632 (IP=0.0.0.0 :3389) Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_bind Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: do_bind: version=3 dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 BIND dn="" method=128 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=0 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=0 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=1 tag=97 err=0 Feb 22 15:16:17 server slapd[14494]: conn=5 op=0 RESULT tag=97 err=0 text= Feb 22 15:16:17 server slapd[14494]: do_bind: v3 anonymous bind Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_search Feb 22 15:16:17 server slapd[14494]: >>> dnPrettyNormal: <> Feb 22 15:16:17 server slapd[14494]: <<< dnPrettyNormal: <>, <> Feb 22 15:16:17 server slapd[14494]: SRCH "" 2 0 Feb 22 15:16:17 server slapd[14494]: 0 0 0 Feb 22 15:16:17 server slapd[14494]: begin get_filter Feb 22 15:16:17 server slapd[14494]: EQUALITY Feb 22 15:16:17 server slapd[14494]: end get_filter 0 Feb 22 15:16:17 server slapd[14494]: filter: (mail=someone(a)domain.de) Feb 22 15:16:17 server slapd[14494]: attrs: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SRCH base="" scope=2 deref=0 filter="(mail=someone(a)domain.de)" Feb 22 15:16:17 server slapd[14494]: ==> limits_get: conn=5 op=1 dn="[anonymous]" Feb 22 15:16:17 server slapd[14494]: conn=5 op=1: meta_back_getconn[0] Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_getconn: candidates=1 conn=-1 fet ched Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 meta_back_dobind: conn=-1 bound=1 Feb 22 15:16:17 server slapd[14494]: [rw] searchBase: "" -> "" Feb 22 15:16:17 server slapd[14494]: send_ldap_result: conn=5 op=1 p=3 Feb 22 15:16:17 server slapd[14494]: send_ldap_result: err=32 matched="" text="" Feb 22 15:16:17 server slapd[14494]: send_ldap_response: msgid=2 tag=101 err=32 Feb 22 15:16:17 server slapd[14494]: conn=5 op=1 SEARCH RESULT tag=101 err=32 nentries=0 tex t= Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: 11r Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: read active on 11 Feb 22 15:16:17 server slapd[14494]: connection_get(11) Feb 22 15:16:17 server slapd[14494]: connection_get(11): got connid=5 Feb 22 15:16:17 server slapd[14494]: connection_read(11): checking for input on id=5 Feb 22 15:16:17 server slapd[14494]: ber_get_next on fd 11 failed errno=0 (Success) Feb 22 15:16:17 server slapd[14494]: connection_read(11): input error=-2 id=5, closing. Feb 22 15:16:17 server slapd[14494]: connection_closing: readying conn=5 sd=11 for close Feb 22 15:16:17 server slapd[14494]: connection_close: deferring conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: activity on 1 descriptor Feb 22 15:16:17 server slapd[14494]: daemon: activity on: Feb 22 15:16:17 server slapd[14494]: Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 22 15:16:17 server slapd[14494]: do_unbind Feb 22 15:16:17 server slapd[14494]: conn=5 op=2 UNBIND Feb 22 15:16:17 server slapd[14494]: connection_resched: attempting closing conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: connection_close: conn=5 sd=11 Feb 22 15:16:17 server slapd[14494]: =>meta_back_conn_destroy: fetching conn=5 DN="" Feb 22 15:16:17 server slapd[14494]: daemon: removing 11 Feb 22 15:16:17 server slapd[14494]: conn=5 fd=11 closed ()

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by hyc＠symas.com 23 Feb '07

23 Feb '07

ghenry(a)suretecsystems.com wrote: > <quote who="ando(a)sys-net.it"> >> ghenry(a)suretecsystems.com wrote: >> >>> Just a quick to note that there are some overlays missing from >>> slapd.overlays.5 >>> in 2.4.4alpha and actual man pages. >> Please enumerate them; some are intentionally not present because they >> are not intended for real use. > > * dyngroup has no man page, but is listed slapd.overlays.5 > * slapo-valsort.5 isn't in slapd.overlays.5 > * slapo-dds.5 isn't listed in slapd.overlays.5 > * constraint.c has no docs or listed in slapd.overlays.5 slapo-constraint.5 was added to CVS April 29 2006. > * seqmod.c has no docs or listed in slapd.overlays.5 This is a demo overlay, not intended for actual use. -- -- 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#4849) LDAP URL not recognized with bind9
by cyril＠coupel.net 23 Feb '07

23 Feb '07

Tanks for your answer. I tested by removing the %xxxx% from the URL and the tests are passed; but there is an error saying that there is no %xxx% token. I already open a case to the BIND team, but they reply this is not a bind problem. However, I will transmit this information to the BIND/DLZ team. -----Message d'origine----- De : Pierangelo Masarati [mailto:ando@sys-net.it] Envoyé : vendredi 23 février 2007 12:56 À : Cyril COUPEL; openldap-its(a)openldap.org Objet : Re: (ITS#4849) LDAP URL not recognized with bind9 Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 23 Feb '07

23 Feb '07

Please keep replies on the Issue Tracking System (ITS) list, otherwise you'll defeat its purpose of tracking issues. Cyril COUPEL wrote: > I agree with this information. > The fact is the ldapURL is not used as it, the key %zone% (or %client%) is > replaced with the ns domain (the client name). > > It was working well since I upgrade to 2.3.30-r2. > I tried to downgrade to a previous version of openldap and it was working > again, so it is a openldap problem. I see the fact that earlier versions of OpenLDAP were not compliant with standard track documents as a good reason to improve it by making it compliant, rather than a reason to keep it broken. The client is broken since it appears to parse the URL __before__ replacing portions of it that are marked using a character that is invalid in URLs. Either that client implements and uses its own broken URL parsing routines (at the risk of parsing broken URLs incorrectly, since they contain invalid characters), or it does URL parsing __after__ string replacement (i.e. after their string has been turned into a valid URL). I don't see why OpenLDAP should break (or, in this case, remain broken) to maintain compatibility with a poorly implemented client. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 23 Feb '07

23 Feb '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Just a quick to note that there are some overlays missing from >> slapd.overlays.5 >> in 2.4.4alpha and actual man pages. > > Please enumerate them; some are intentionally not present because they > are not intended for real use. * dyngroup has no man page, but is listed slapd.overlays.5 * slapo-valsort.5 isn't in slapd.overlays.5 * slapo-dds.5 isn't listed in slapd.overlays.5 * constraint.c has no docs or listed in slapd.overlays.5 * seqmod.c has no docs or listed in slapd.overlays.5 > >> Also, relay and rwm are still marked as experimental in some places. > >> grep experimental doc/man/man5/* >> >> doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay >> are >> experimental. >> >> doc/man/man5/slapo-rwm.5:This overlay is experimental. >> >> I'll help where I can, > > Sure. I believe they are no longer experimental, but they still do not > support back-config, so better wait until they're complete. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > 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#4849) LDAP URL not recognized with bind9
by ando＠sys-net.it 22 Feb '07

22 Feb '07

cyril_coupel(a)yahoo.fr wrote: > Full_Name: Cyril COUPEL > Version: 2.3.30-r2 > OS: Gentoo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.241.40.178) > > > Since the openldap update 2.3.30-r2, le LDAP URL are no more recognized in the > bind 9.3.4 named.conf. > > Reproducible: Always > > Steps to Reproduce: > 1. compile BIND with DLZ and LDAP > 2. add dlz "ldap zone" { > database "ldap 2 > v3 simple {} {} {10.1.2.253} > ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???objectclass=dlzZone ^^^ this is not a valid URL, since the two chars following each "%" are not a valid pair of hexadecimal digits, as required by URL encoding. "%" need to be URLescaped, as per RFC3986, section 2.4. The problem is in the client, not in OpenLDAP software. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4849) LDAP URL not recognized with bind9
by cyril_coupel＠yahoo.fr 22 Feb '07

22 Feb '07

Full_Name: Cyril COUPEL Version: 2.3.30-r2 OS: Gentoo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.241.40.178) Since the openldap update 2.3.30-r2, le LDAP URL are no more recognized in the bind 9.3.4 named.conf. Reproducible: Always Steps to Reproduce: 1. compile BIND with DLZ and LDAP 2. add dlz "ldap zone" { database "ldap 2 v3 simple {} {} {10.1.2.253} ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???objectclass=dlzZone ldap:///dlzHostName=%record%,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzPreference,dlzData,dlzIPAddr?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzHostName=@,dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzData,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(dlzType=soa)) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz?dlzTTL,dlzType,dlzHostName,dlzPreference,dlzData,dlzIPAddr,dlzPrimaryNS,dlzAdminEmail,dlzSerial,dlzRefresh,dlzRetry,dlzExpire,dlzMinimum?sub?(&(objectclass=dlzAbstractRecord)(!(dlzType=soa))) ldap:///dlzZoneName=%zone%,ou=dns,o=bind-dlz???(&(objectclass=dlzXFR)(dlzIPAddr=%client%)) "; }; to /etc/bind/named.conf 3. start named Actual Results: the log says :"failed to parse ldap URL" Expected Results: eb 15 16:51:35 sc1 process `named' is using obsolete setsockopt SO_BSDCOMPAT Feb 15 16:51:35 sc1 named[2220]: Loading 'ldap zone' using driver ldap Feb 15 16:51:35 sc1 named[2220]: command channel listening on 127.0.0.1#953 Feb 15 16:51:35 sc1 named[2220]: zone 127.in-addr.arpa/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: zone localhost/IN: loaded serial 2002081601 Feb 15 16:51:35 sc1 named[2220]: running

1 0

(ITS#4848) Another slapd startup segfault
by michael.heep＠o2.com 22 Feb '07

22 Feb '07

Full_Name: Michael Heep Version: 2.3.34 OS: RHES30 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Since I'm not sure whether this is realted to my previos ITS (4847) so I'm filing another report as the OS and circumstances are different. As of 2.3.34 slapd crashes on Red Hat Enterprise 3.0 during startup. The funny thing is it only crashes on our slave, not on the master. The slave uses the following slapd.conf: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files to include include /opt/openldap/etc/schema/core.schema include /opt/openldap/etc/schema/cosine.schema include /opt/openldap/etc/schema/sudo.schema include /opt/openldap/etc/schema/nis.schema include /opt/openldap/etc/schema/openssh-lpk.schema include /opt/openldap/etc/schema/dyngroup.schema # Put those into the 'ldap' user's homedir (/var/lib/ldap) because # user 'ldap' has no write permissions in /var/run pidfile /var/lib/ldap/slapd.pid argsfile /var/lib/ldap/slapd.args # Security restrictions (all operations require at least 128bit encryption) security ssf=128 update_ssf=128 simple_bind=128 # Access control policy # rootdn can always read/write anything! # DO NOT MESS WITH THIS UNLESS YOU KNOW WHAT YOU’ARE DOING! access to dn.subtree="cn=Monitor" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to dn.subtree="cn=accesslog" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to * by dn.children="ou=Area 52,dc=o2online,dc=de" none by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write by dn.exact="cn=syncreader,dc=o2online,dc=de" read by * break access to attrs=userPassword by self write by anonymous auth access to attrs=shadowLastChange by self write by * read access to * by * read # Logging loglevel 256 # Close idle connections after 120sec idletimeout 120 # SSL/TLS Stuff TLSCACertificateFile /opt/openldap/etc/ssl-certs/cno-ldc_ca.cert TLSCertificateFile /opt/openldap/etc/ssl-certs/sgmldap02.cert TLSCertificateKeyFile /opt/openldap/etc/ssl-keys/sgmldap02.key TLSCipherSuite HIGH TLSVerifyClient try # Chainig overlay for automatic referral chasing (global so it affects updaterefs!) # chain-uri must be EXACTLY the same as updateref (ip/host, port), otherwise it wont't work! overlay chain chain-uri "ldap://sgmldap01" chain-idassert-bind bindmethod=sasl binddn="cn=syncreader,dc=o2online,dc=de" saslmech=external mode=self chain-tls start ######################## # Database definitions # ######################## # Database for access logging database bdb suffix cn=accesslog rootdn "cn=root,cn=accesslog" rootpw {SSHA}FORBIDDEN directory /var/lib/ldap/openldap-accesslog # Indices to maintain index reqStart eq index objectClass eq # Checkpointing & caching checkpoint 256 5 cachesize 1000 idlcachesize 3000 # No limits for CNO-LDC limits dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" size=unlimited time=unlimited # Database with monitor backend for the Directory Informartion Tree database monitor database bdb suffix "dc=o2online,dc=de" rootdn "cn=root,dc=o2online,dc=de" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA} # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/openldap-data # Accesslog overlay - Keep logs for 30 days and purge old entries once a day overlay accesslog logdb cn=accesslog logops writes logold (objectclass=*) logpurge 30+00:00 01+00:00 # Indices to maintain # WARNING: If you add indices stop slapd, run slapindex, then start slapd! # Otherwise you'll experience problems like searches returning improper results. index objectClass eq index entryCSN eq index entryUUID eq index sudoUser pres,eq,sub index uid,cn pres,eq,sub index uidNumber eq index gidNumber eq index memberUid eq index uniqueMember eq index host eq ## Syncrepl provider settings #overlay syncprov #syncprov-checkpoint 50 5 #syncprov-sessionlog 100 # Syncrepl consumer settings # Set attrs="*,+" or don't configure it at all to also replicate all operational attributes # (createTimestamp, creatorsName, modifiersName, modifyTimestamp, etc.) syncrepl rid=100 provider=ldap://sgmldap01 type=refreshAndPersist interval=00:00:00:10 retry="60 10 300 +" searchbase="dc=o2online,dc=de" filter="(objectclass=*)" scope=sub attrs="*,+" schemachecking=on starttls=critical bindmethod=sasl saslmech="external" # URL to return to clients which submit update requests updateref ldap://sgmldap01 # No limits for the "syncreader" account limits dn.exact="cn=syncreader,dc=o2online,dc=de" size=unlimited time=unlimited # Caches & Checkpointing (see slapd-bdb(5) manual) cachesize 10000 idlcachesize 30000 checkpoint 1024 5 # Attribute uniqueness overlay for POSIX accounts overlay unique unique_base "ou=People,dc=o2online,dc=de" unique_attributes uid uidNumber # Dynlist overlay to dynamically add members to groups through memberURLs overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember # Value sorting overlay overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend valsort-attr host dc=o2online,dc=de alpha-ascend # Allow Proxy Authorization authz-policy to # SASL rewrite rules authz-regexp email=[we want no spam](a)o2.com,cn=sgmldap([0-9]*),ou=cno-ldc,o=o2\ germany,l=frankfurt,st=hessen,c=de cn=syncreader,dc=o2online,dc=de The master's conf is basically the same. Just overlay chain + syncrepl commaneted out and overlay syncprov commented in. Uncommenting the following directives results in a clean startup: ## Syncrepl provider settings #overlay syncprov #syncprov-checkpoint 50 5 #syncprov-sessionlog 100 Here's the gdb dump: (gdb) file ./slapd Reading symbols from /home/heepm/slapd...done. Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:///" Starting program: /home/heepm/slapd -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:///" [Thread debugging using libthread_db enabled] [New Thread -1218506624 (LWP 29908)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1218506624 (LWP 29908)] 0x0062ff95 in memmove () from /lib/tls/libc.so.6 (gdb) bt full #0 0x0062ff95 in memmove () from /lib/tls/libc.so.6 No symbol table info available. #1 0x0817722a in rdn2str (rdn=0x901ea28, str=0x901ed12 "", flags=272, len=0x90177e2, s2s=0x8176420 <strval2str>) at getdn.c:2571 iAVA = 0 l = 3 #2 0x08177dfc in ldap_dn2bv_x (dn=0x901ebe0, bv=0x901e854, flags=272, ctx=0x0) at getdn.c:3044 rdnl = 10 iRDN = 1 rc = -3 len = 28 l = 10 sv2l = (int (*)(struct berval *, unsigned int, ber_len_t *)) 0x8176130 <strval2strlen> sv2s = (int (*)(struct berval *, char *, unsigned int, ber_len_t *)) 0x8176420 <strval2str> #3 0x08095479 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbfffb098, out=0x901e854, ctx=0x0) at dn.c:627 dn = 0x901ebe0 rc = 0 #4 0x081516c5 in unique_config (be=0x90177e2, fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno=156, argc=2, argv=0x9006ff8) at unique.c:151 bv = {bv_len = 27, bv_val = 0x901e7fd "ou=People,dc=o2online,dc=de"} on = (slap_overinst *) 0x90177e2 ud = (unique_data *) 0x901e848 up = (unique_attrs *) 0xbfffb098 text = 0xbfffb21c "/opt/openldap/etc/slapd.conf: line 156" ad = (AttributeDescription *) 0x6030a4 i = 7256760 #5 0x080ddb1a in over_db_config (be=0x901e040, fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno=156, argc=2, argv=0x9006ff8) at backover.c:157 on2 = (slap_overinst *) 0x0 onp = (slap_overinst **) 0x81512c0 be2 = {bd_info = 0x0, be_ctrls = '\0' <repeats 32 times>, be_flags = 0, be_restrictops = 0, be_requires = 0, be_ssf_set = { sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x0, be_nsuffix = 0x0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 0, lms_t_hard = 0, lms_s_soft = 0, lms_s_hard = 0, lms_s_unchecked = 0, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_NONE, be_replica = 0x0, be_replogfile = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_pcl_mutexp = 0x0, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x0, be_next = {stqe_next = 0x0}} i = 0 oi2 = (slap_overinfo *) 0x90177e2 oi = (slap_overinfo *) 0x901e4f8 on = (slap_overinst *) 0x901ebf8 be_cf_ocs = (struct ConfigOCs *) 0x82a0900 ca = {argc = 2, argv = 0x9006ff8, argv_size = 0, line = 0x0, tline = 0x0, fname = 0x8fd9018 "/opt/openldap/etc/slapd.conf", lineno = 156, log = "/opt/openldap/etc/slapd.conf: line 156", '\0' <repeats 4085 times>, msg = '\0' <repeats 255 times>, depth = 0, valx = 0, values = {v_int = 0, v_long = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 0, ---Type <return> to continue, or q <return> to quit--- be = 0x901e040, bi = 0x0, ca_entry = 0x0, private = 0x0, cleanup = 0} rc = -1026 #6 0x0807918f in read_config_file (fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x9007800, cft=0x829bea0) at config.c:807 fp = (FILE *) 0x9007800 ct = (ConfigTable *) 0x90177e2 c = (ConfigArgs *) 0x9005e80 rc = 151019136 s = {st_dev = 26626, __pad1 = 0, st_ino = 229380, st_mode = 33184, st_nlink = 1, st_uid = 0, st_gid = 55, st_rdev = 0, __pad2 = 0, st_size = 5199, st_blksize = 4096, st_blocks = 16, st_atim = {tv_sec = 1172158204, tv_nsec = 0}, st_mtim = { tv_sec = 1171993893, tv_nsec = 0}, st_ctim = {tv_sec = 1171993893, tv_nsec = 0}, __unused4 = 0, __unused5 = 0} #7 0x0807357e in read_config (fname=0x8fd9018 "/opt/openldap/etc/slapd.conf", dir=0x8fd9018 "/opt/openldap/etc/slapd.conf") at bconfig.c:3077 st = {st_dev = 7, __pad1 = 50360, st_ino = 135507850, st_mode = 150982944, st_nlink = 3221210280, st_uid = 1, st_gid = 150983096, st_rdev = 588336130853561644, __pad2 = 50360, st_size = 134901884, st_blksize = 136982680, st_blocks = 0, st_atim = {tv_sec = -1073756936, tv_nsec = 134933086}, st_mtim = {tv_sec = 0, tv_nsec = 24582}, st_ctim = {tv_sec = -1073756952, tv_nsec = 135684567}, __unused4 = 136990016, __unused5 = 0} be = (BackendDB *) 0x9005bb8 cfb = (CfBackInfo *) 0x9005cc0 cfdir = 0x901ea60 "\002" cfname = 0x8fd9018 "/opt/openldap/etc/slapd.conf" rc = 151018424 #8 0x0806c445 in main (argc=7, argv=0xbfffc614) at main.c:667 val = 0x0 opt = {bv_len = 3221210504, bv_val = 0x822db6e "\215\223\024\207ÿÿ\215\213\024\207ÿÿ)ÊÁú\0021ö9Ös\017\211×\220ÿ\224³\024\207ÿÿF9þrô\203Ä\f[^_ÉÃU\211åVSè"} i = 0 i = 136960888 no_detach = 0 rc = 0 urls = 0x8fd9040 "ldap:/// ldaps:///" username = 0x8fd9008 "ACI Item" groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x8fd9018 "/opt/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbfffec31 "slapd" scp = (struct sync_cookie *) 0x829db78 scp_entry = (struct sync_cookie *) 0x90177e2 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x90177e2 "" slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 With kind regards Michael Heep

1 0

(ITS#4847) slapd segfaults on startup
by michael.heep＠o2.com 22 Feb '07

22 Feb '07

Full_Name: Michael Heep Version: 2.3.34 OS: RHES21 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.113.101.1) Since version 2.3.34 slapd simply segfaults during startup on a Red Hat Enterprise 2.1 system. I've been building a customized OpenLDAP RPM for our purposes (installs to /opt/openldap) for over a year now and never encountered any problems like this before. + CPPFLAGS= -I/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/include -I/usr/include/sasl2 + LDFLAGS= -L/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/lib + CFLAGS= -O2 -march=i386 -mcpu=i686 -D_REENTRANT -fPIC -I/usr/src/redhat/BUILD/openldap-2.3.34/db-instroot/include -I/usr/include/sasl2 -g -O2 + ./configure --prefix=/opt/openldap --exec_prefix=/opt/openldap --bindir=/opt/openldap/bin --sbindir=/opt/openldap/sbin --sysconfdir=/opt/openldap/etc --datadir=/opt/openldap/share --includedir=/opt/openldap/include --libdir=/opt/openldap/lib --libexecdir=/opt/openldap/sbin --localstatedir=/var/run --sharedstatedir=/usr/com --mandir=/opt/openldap/man --infodir=/opt/openldap/info --enable-debug --enable-bdb --enable-hdb --enable-ldap --enable-monitor --disable-ldbm --enable-slapd --disable-slurpd --enable-syncprov --enable-accesslog --enable-ppolicy --enable-unique --enable-proxycache --enable-dynlist --enable-valsort --enable-refint --with-threads --enable-shared --enable-static --enable-local --disable-rlookups --with-tls --with-cyrus-sasl --disable-wrappers --disable-ipv6 --enable-passwd --enable-crypt --enable-cleartext --enable-spasswd --enable-syslog --enable-modules --disable-sql --disable-shell Here is the stacktrace when run under gdb: (gdb) file ./slapd Load new symbol table from "./slapd"? (y or n) y Reading symbols from ./slapd...done. (gdb) run -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" Starting program: /usr/src/redhat/BUILD/openldap-2.3.34/servers/slapd/slapd -u ldap -f /opt/openldap/etc/slapd.conf -h "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" [Thread debugging using libthread_db enabled] [New Thread 8192 (LWP 30130)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 30130)] 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 519 validf = ad->ad_type->sat_syntax->ssyn_validate; (gdb) bt full #0 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 validf = (slap_syntax_validate_func *) 0 transf = (slap_syntax_transform_func *) 0 bv = {bv_len = 0, bv_val = 0x0} ava = (LDAPAVA *) 0x833e3a8 ad = (AttributeDescription *) 0x833e418 normf = (slap_mr_normalize_func *) 0 mr = (MatchingRule *) 0x0 do_sort = 1 iAVA = 0 iRDN = 0 rc = 2 #1 0x08092615 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbffeac18, out=0x833e804, ctx=0x0) at dn.c:619 val = (struct berval *) 0xbffeac18 dn = 0x833f618 rc = 137623037 #2 0x08140898 in unique_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at unique.c:151 bv = {bv_len = 17, bv_val = 0x833f5fd "dc=o2online,dc=de"} be = (BackendDB *) 0x7530 on = (slap_overinst *) 0x2 ud = (unique_data *) 0x833e7f8 up = (unique_attrs *) 0xbffeac18 text = 0x101b <Address 0x101b out of bounds> ad = (AttributeDescription *) 0xbffead9c i = 137003568 #3 0x080d5c95 in over_db_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at backover.c:157 oi = (slap_overinfo *) 0x833e210 on = (slap_overinst *) 0x8355c98 be_cf_ocs = (struct ConfigOCs *) 0x827f2b4 ca = {argc = 2, argv = 0x833cef8, argv_size = 0, line = 0x0, tline = 0x0, fname = 0x82a8230 "/opt/openldap/etc/slapd.conf", lineno = 168, log = "/opt/openldap/etc/slapd.conf: line 168", '\0' <repeats 4084 times>, msg = '\0' <repeats 255 times>, depth = 0, valx = 0, values = {v_int = 0, v_long = 0, v_ber_t = 0, v_string = 0x0, v_bv = {bv_len = 0, bv_val = 0x0}, v_dn = {vdn_dn = {bv_len = 0, bv_val = 0x0}, vdn_ndn = {bv_len = 0, bv_val = 0x0}}}, rvalue_vals = 0x0, rvalue_nvals = 0x0, op = 0, type = 0, be = 0x833f810, bi = 0x0, ca_entry = 0x0, private = 0x0, cleanup = 0} rc = -1026 #4 0x08078bbf in read_config_file (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x827a5f4) at config.c:807 fp = (FILE *) 0x833d700 ct = (ConfigTable *) 0x2 c = (ConfigArgs *) 0x833bd80 rc = -1026 s = {st_dev = 26632, __pad1 = 0, st_ino = 229391, st_mode = 33184, st_nlink = 1, st_uid = 0, st_gid = 55, st_rdev = 0, __pad2 = 0, st_size = 6040, st_blksize = 4096, st_blocks = 16, st_atime = 1172155110, __unused1 = 0, st_mtime = 1170837817, __unused2 = 0, st_ctime = 1171879479, __unused3 = 0, __unused4 = 0, __unused5 = 0} #5 0x080731fd in read_config (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3077 dir = 0x82a8230 "/opt/openldap/etc/slapd.conf" be = (BackendDB *) 0x833bac8 cfb = (CfBackInfo *) 0x833bbd0 cfdir = 0x7530 <Address 0x7530 out of bounds> cfname = 0x82a8230 "/opt/openldap/etc/slapd.conf" rc = 137607880 #6 0x0806c33d in main (argc=7, argv=0xbffec1a4) at main.c:667 i = 137003568 no_detach = 0 rc = 0 urls = 0x82a8258 "ldap:/// ldaps:/// ldaps://192.168.128.204:80/" username = 0x82a8220 "HÏ,@Àò.@\020" groupname = 0x0 sandbox = 0x0 syslogUser = 160 configfile = 0x82a8230 "/opt/openldap/etc/slapd.conf" configdir = 0x0 serverName = 0xbffedbd0 "slapd" scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x2 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x2 <Address 0x2 out of bounds> slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 (gdb) (gdb) thread apply all bt Thread 1 (Thread 8192 (LWP 30130)): #0 0x08092364 in LDAPDN_rewrite (dn=0x833f618, flags=0, ctx=0x0) at dn.c:519 #1 0x08092615 in dnNormalize (use=0, syntax=0x0, mr=0x0, val=0xbffeac18, out=0x833e804, ctx=0x0) at dn.c:619 #2 0x08140898 in unique_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at unique.c:151 #3 0x080d5c95 in over_db_config (be=0x833f810, fname=0x82a8230 "/opt/openldap/etc/slapd.conf", lineno=168, argc=2, argv=0x833cef8) at backover.c:157 #4 0x08078bbf in read_config_file (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", depth=0, cf=0x0, cft=0x827a5f4) at config.c:807 #5 0x080731fd in read_config (fname=0x82a8230 "/opt/openldap/etc/slapd.conf", dir=0x0) at bconfig.c:3077 #6 0x0806c33d in main (argc=7, argv=0xbffec1a4) at main.c:667 (gdb) I hope this helps, since I'm not that experienced in gdb/strace usage and thus cannot make much of the output ;) OpenLDAP 2.3.33 (or lower) worked flawlessly. This is the slapd.conf we use, which hasn't changed since 2.3.32. I kept all comments, etc. to provide accurate data. Just censored the passwords: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /opt/openldap/etc/schema/core.schema include /opt/openldap/etc/schema/cosine.schema include /opt/openldap/etc/schema/sudo.schema include /opt/openldap/etc/schema/nis.schema include /opt/openldap/etc/schema/openssh-lpk.schema include /opt/openldap/etc/schema/dyngroup.schema include /opt/openldap/etc/schema/ppolicy.schema # Put those into the 'ldap' user's homedir (/var/lib/ldap) because # user 'ldap' has no write permissions in /var/run pidfile /var/lib/ldap/slapd.pid argsfile /var/lib/ldap/slapd.args # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 112-bit encryption for simple bind #security ssf=1 update_ssf=112 simple_bind=112 security ssf=128 update_ssf=128 simple_bind=128 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! access to dn.subtree="cn=accesslog" by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" read access to * by dn.children="ou=CNO-LDC,ou=People,dc=o2online,dc=de" write by dn.exact="cn=syncreader,dc=o2online,dc=de" read by * break access to attrs=userPassword by self write by anonymous auth access to attrs=shadowLastChange by self write by * read access to * by * read # Logging loglevel 256 # Remove idle connections after 5 minutes idletimeout 300 # SSL/TLS Stuff TLSCACertificateFile /opt/openldap/etc/ssl-certs/cno-ldc_ca.cert TLSCertificateFile /opt/openldap/etc/ssl-certs/sgmldaptest02.cert TLSCertificateKeyFile /opt/openldap/etc/ssl-keys/sgmldaptest02.key TLSCipherSuite HIGH TLSVerifyClient try ## Chainig overlay for automatic referral chasing (global so it affects updateref entries!) ## chain-uri must be EXACTLY the same as updateref (ip/host, port), otherwise it wont't work! #overlay chain #chain-uri "ldap://192.168.128.205" #chain-idassert-bind bindmethod=sasl binddn="cn=syncreader,dc=o2online,dc=de" saslmech=external mode=self #chain-tls start ####################################################################### # BDB database definitions ####################################################################### # Database for access logging database bdb suffix cn=accesslog rootdn "cn=root,cn=accesslog" rootpw {SSHA}FORBIDDEN directory /var/lib/ldap/openldap-accesslog #Iindices to maintain index objectClass eq index reqStart eq # Checkpointing & caching checkpoint 256 5 cachesize 1000 idlcachesize 3000 # Main database definitions database bdb suffix "dc=o2online,dc=de" rootdn "cn=root,dc=o2online,dc=de" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw {SSHA} # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/openldap-data # Accesslog overlay - Keep logs for 30 days and purge old entries once a day overlay accesslog logdb cn=accesslog logops writes logold (objectclass=*) logpurge 30+00:00 01+00:00 # Indices to maintain # WARNING: If you add indices stop slapd, run slapindex, then start slapd! # Otherwise you'll experience problems like searches returning improper results. index objectClass eq index entryCSN eq index entryUUID eq index sudoUser pres,eq,sub index uid,cn pres,eq,sub index uidNumber eq index gidNumber eq index memberUid eq index uniqueMember eq index host eq # Syncrepl provider settings overlay syncprov syncprov-checkpoint 50 5 syncprov-sessionlog 1000 ## Syncrepl consumer settings ## Set attrs="*,+" or don't configure it at all to also replicate all operational attributes ## (createTimestamp, creatorsName, modifiersName, modifyTimestamp, etc.) #syncrepl rid=100 # provider=ldap://sgmldaptest01 # type=refreshAndPersist # interval=00:00:00:10 # retry="60 10 300 +" # searchbase="dc=o2online,dc=de" # filter="(objectclass=*)" # scope=sub # attrs="*,+" # schemachecking=on # starttls=critical # bindmethod=sasl # saslmech="external" # ## URL to return to clients which submit update requests #updateref ldap://192.168.128.205 # No limits for the "syncreader" account limits dn.exact="cn=syncreader,dc=o2online,dc=de" size=unlimited time=unlimited # Caches & Checkpointing (see slapd-bdb(5) manual) cachesize 10000 idlcachesize 30000 checkpoint 1024 5 # Attribute uniqueness overlay for POSIX accounts overlay unique unique_base "dc=o2online,dc=de" unique_attributes uid uidNumber # 2 gleiche overlays gehen nicht. Tja, was tun mit gidNumber? #overlay unique #unique_base "ou=Groups,dc=o2online,dc=de" #unique_attributes gidNumber # Dynlist overlay to dynamically add members to groups through memberURLs overlay dynlist dynlist-attrset extensibleObject memberURL uniqueMember # Valsort overlay overlay valsort valsort-attr uniqueMember dc=o2online,dc=de alpha-ascend valsort-attr host dc=o2online,dc=de alpha-ascend # Password policy configuration overlay ppolicy #ppolicy_default "cn=Standard,ou=Password_Policies,dc=o2online,dc=de" #ppolicy_hash_cleartext ppolicy_use_lockout # Allow Proxy Authorization authz-policy to # SASL rewrite rules authz-regexp email=[we want no spam],cn=sgmldaptest([0-9]*),ou=cno-ldc,o=o2\ germany,l=frankfurt,st=hessen,c=de cn=syncreader,dc=o2online,dc=de With kind regards Michael Heep

1 0

Re: (ITS#4844) Missing 2.4 man pages and things marked as "Experimental"
by ghenry＠suretecsystems.com 21 Feb '07

21 Feb '07

<quote who="ando(a)sys-net.it"> > ghenry(a)suretecsystems.com wrote: > >> Just a quick to note that there are some overlays missing from >> slapd.overlays.5 >> in 2.4.4alpha and actual man pages. > > Please enumerate them; some are intentionally not present because they > are not intended for real use. Certainly. Will do in the morning. > >> Also, relay and rwm are still marked as experimental in some places. > >> grep experimental doc/man/man5/* >> >> doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay >> are >> experimental. >> >> doc/man/man5/slapo-rwm.5:This overlay is experimental. >> >> I'll help where I can, > > Sure. I believe they are no longer experimental, but they still do not > support back-config, so better wait until they're complete. Understood. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.n.c. > 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#4845) Back-perl is non working
by ando＠sys-net.it 21 Feb '07

21 Feb '07

kiwi(a)oav.net wrote: > Full_Name: Xavier Beaudouin > Version: 2.3.33 > OS: FreeBSD 6.2 > URL: http://www.oav.net/tmp/openldap/ > Submission from: (NULL) (82.225.248.92) > Sending -> dn : uid=kiwi(a)oav.net,ou=mailboxes,dc=kazar,dc=net > objectClass : top > objectClass : kazarPerson > uid : kiwi(a)oav.net > cn : Nom Prenom > description : Sample description > uidNumber : 10 > gidNumber : 10 > userPassword : Password > homeDirectory : /home/test > mailQuota : 50 > CouriermailQuota : 50S > > str2entry: entry -1 has no dn > str2entry(dn) failed > send_ldap_result: err=0 matched="" text="" > connection_get(8) If the above is the way your LDIF is formatted, then back-perl (actually, str2entry, a helper function in the core of slapd) is working as intended. There's supposed to be no space between attribute names or "dn" and the colon ":". Please fix you PERL and report. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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#4844) Missing 2.4 man pages and things marked as "Experimental"
by ando＠sys-net.it 21 Feb '07

21 Feb '07

ghenry(a)suretecsystems.com wrote: > Just a quick to note that there are some overlays missing from slapd.overlays.5 > in 2.4.4alpha and actual man pages. Please enumerate them; some are intentionally not present because they are not intended for real use. > Also, relay and rwm are still marked as experimental in some places. > grep experimental doc/man/man5/* > > doc/man/man5/slapd-relay.5:This backend and the above mentioned overlay are > experimental. > > doc/man/man5/slapo-rwm.5:This overlay is experimental. > > I'll help where I can, Sure. I believe they are no longer experimental, but they still do not support back-config, so better wait until they're complete. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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

old devel bugs
by Howard Chu 21 Feb '07

21 Feb '07

Are ITS#4332 and #4473 still relevant, or can we close them? -- -- 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/

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs