openldap-bugs

openldap-bugs@openldap.org

1 participants
21513 discussions

(ITS#5406) slapd-meta(5) does not mention idassert-* directives
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando See subject

1 0

Re: (ITS#5396) Too much open connections
by ando＠sys-net.it 08 Mar '08

08 Mar '08

ecip(a)gmv.es wrote: > Hi all, using openldap 2.4.8 as a metadirectory server in front of a couple of > Active Directory Servers and a local database we have found an issue with the > number of ESTABLISHED connections. > > This is a part of the slapd configuration file: > > backend meta > database meta > > ## Sufijo del arbol mostrado por el metadirectorio y usuario > ## administrador del mismo(superusuario de ldap). > suffix "dc=gmv,dc=es" > rootdn "cn=diradmin,dc=gmv,dc=es" > ## Password del superusuario, pasar a texto cifrado con slappasswd. > rootpw secret > > ############################################## > ### Opciones comunes a todo el metadirectorio. > ############################################## > ######################################### > #### Directivas comunes de configuracion. > ## TTL para tirar una conexion, aunque no este inactiva (6 minutos). > conn-ttl 360 > ## Version del protocolo LDAP a utilizar. > protocol-version 3 > ## Accion ante un referral. > chase-referrals no > ## TTL para tirar una conexion inactiva (5 minutos). > idletimeout 300 > ##################################################################### > ### Definicion del LDAP remoto para las consultas de informacion de > ### usuario y grupos UNIX desde maquinas que son clientes LDAP. > ##################################################################### > ## Definicion de los servidores target remotos a consultar. > ## Se consultara el primer servidor remoto que responda. > ## Defino una lista de dcs que pueden responder para el contexto de > ## nombre dc=gmv,dc=es. Primer target con sus parametros de configuracion. > uri "ldap://gmvdc1.gmv.es/DC=gmv,DC=es ldap://gmvdc2.gmv.es/" > idle-timeout 300 > ## Habilitamos el sistema de reescritura para las consultas. > rewriteEngine on > overlay rwm > > and the output of the netstat -an command shows too much ESTABLISHED connections > between the metadirectory and the remote servers. > > After a while, the process runs out of file descriptors. There seems to be no clear indication of a software bug, but rather a resource exhaustion, which could be reduced by properly identifying how the proxy works and how the clients exploit its functionalities. Few comments: - why do you use back-meta with just one URI? use back-ldap instead - why do you enable the rewrite engine for that uri but you don't specify any rewrite rule? Is your server so performing to deserve wasting some cycles? - why do you add a slapo-rwm (not needed with back-meta, since it has built-in rewrite capabilities you don't need, but you just switched on, see previous remark)? Again, do you urge to reduce the performances of your proxy? With respect to resource exhaustion, it might depend on the usage you make of your system. Are you using it for multiple authentications on the same client connection? In that case, you might need to look at the "single-conn" directive; in that case, if your clients are using authenticated connections for repeated operations, you might look at idassert-bind (I note it's not documented in slapd-meta(5), but it's identical to that for slapd-ldap(5), except it's on a per-target basis). Hope this helps. I suggest you move discussion to openldap-software, to find out how to improve your configuration. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Please test and report; servers/slapd/back-ldap/bind.c new revision: 1.244; previous revision: 1.243 The patch applies straightforwardly to re23 only if the first chunk is omitted. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

toby(a)inf.ed.ac.uk wrote: > The backtrace (in ldap_host_connected_to) is: > > (gdb) bt > #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") > at os-ip.c:586 > #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, > mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) > at cyrus.c:643 > #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, > mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 > #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, > rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) > at bind.c:1997 > #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) > at search.c:166 Actually, I was too quick: the above stack backtrace looks inconsistent: there is a call to ldap_sasl_interactive_bind_s at bind.c:1997, but it's not inside ldap_back_dobind_int(); it's rather in ldap_back_proxy_authz_bind(), which might be called by ldap_back_dobind_int(). It might be useful if you try to see if the issue can be reproduced with a non-optimized build, so that we can see the actual behavior of the code from the backtrace, and see some arg values that are now missing. What could actually be happening is that although the authentication fails, the fact that LDAP_OTHER is returned is not considered a condition that requires to invalidate the connection handler, while probably it should. I'll provide a fix in this sense. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

toby(a)inf.ed.ac.uk wrote: > (gdb) bt > #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") > at os-ip.c:586 > #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, > mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) > at cyrus.c:643 > #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, > mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 > #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, > rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) > at bind.c:1997 > #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) > at search.c:166 I think I see the issue: either ldap_back_search() or ldap_back_dobind_int() should invalidate that handle. I'll see if I can fix it. 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#5402) Sets: Hyphens within attribute names considered as separate tokens
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Since the ITS' purpose consists in helping tracking issues, please keep it in CC in replies, otherwise you defeat its purpose. Norbert Rittel wrote: > Am 06.03.2008 um 23:32 schrieb Pierangelo Masarati: > >> The code that parses attribute descriptions appears to be definitely >> broken, since it does allow underscores but no hyphens, and it does not >> allow digits in attribute descriptions (including OIDs). This should be >> fixed now in HEAD, and the patch >> >> servers/slapd/sets.c 1.41 -> 1.42 >> >> seems to apply to current re24 and re23 without much hassle. >> >> Please test, p. > > Wow, really great turnaround :-) > > To test I've downloaded the current OpenLDAP sources used in Mac OS X > 10.5.2 from Apple's site at > > http://www.opensource.apple.com/darwinsource/10.5.2/ > > But unfortunately issuing a 'make' (on the unaltered source already) > results in an error (config.log enclosed if you want to take a look). > I've sent a follow-up to Apple, with A LOT of luck someone at > engineering there will come back to me on that > > If you have access to a Mac OS X (Server) box you might want to give it > a try, but I fully understand if this is not the platform you're working > on ;-) This error appears to have nothing to do with the proposed fix, so you should rather post to OpenLDAP-software (and, only in case another issue surfaces, file a separate ITS). I do not develop on that platform, nor I have access to it, so I'm afraid I can't help. 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#5405) syncprov psearch race condition
by hyc＠OpenLDAP.org 07 Mar '08

07 Mar '08

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc It's possible for a new update to be recorded after the syncprov_qtask has examined its response queue but before it has removed itself from the slapd runqueue. In this case, the qtask will not process the new response right away, it won't see it until the next time an operation occurs on the server.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 07 Mar '08

07 Mar '08

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Howard Chu writes: >>>>> Both RFCs disagree. >>>> They are wrong. Or at least, under-specified. In X.501 section 17.3 >>>> "Directory Distribution Model" it's quite clear that all of the >>>> components of a distributed directory must belong to a single DIT. >>> Which is not true in the LDAP world, and I don't know about today's >>> X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe >>> the X.500 world has also switched to 'dc' structure, I don't know. >>> >>> Anyway, LDAP is not X.500. >> RFC4510 Section 2 "Relationship to X.500" >> (...) An LDAP server MUST act in accordance with the X.500 (1993) >> series (...) > > Except when it doesn't. Like the various implications of sending text > instead of ASN.1 and numeric OIDs. That's irrelevant. The service model and the on-the-wire encoding are two completely different things. The encoding of LDAP is of course different from DAP, but both are required to provide the same service model. Just as DSML is encoded differently, but still delivers the X.500 service model. >> (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 >> it's clear that nobody knew what they were doing, or nobody wanted to >> tackle the glaring absence of an analogue to X.500 DSP. > LDAPv2 (the standard) has no referrals. The Umich implementation > introduced them as a hack: It stuffed them into the errorMessage field. > LDAPv3 moved them into the standard. And speaking for my own little > corner of the standardization process, I definitly was ignorant about > them and wanted nothing to do with them. I've still never had any use > for LDAP referrals. > >> They should never have been introduced. We're stuck with them for >> now, but we can at least try to make them make sense. > > Well, take it up with ldapext. And add an option to slapd to reject > attempts to add 'ref' attrs with a DN, or whatever. > > For now, once the directory contains a 'ref' URL which includes the DN, > I don't see any reason not to rewrite like the spec says. Whatever the > "right answer" is, a referral with an un-rewritten DN seems worse than > with a rewritten one. > Regarding the branches of bdb_referrals() and ldif_back_referrals() > which rewrite default_referral: I suggest we delete it. > The back-ldif code breaks exactly as one would expect: With > referral ldap://urgle/ > database ldif > suffix o=foo > and an empty database, ldapcompare cn=bar,o=foo gives a referral to > urgle. So does ldapadd of o=foo:-( I seem to remember someone meant > the latter was correct and there was a control to prevent it at some > point, maybe that is related. back-bdb has a test which prevents this > referral in case of the suffix dn, but not for superior DNs. But I > don't see why it would not be just as buggy for superiors, if it could > happen. Yeah, I noticed that in the source recently and thought that was bogus. The default referral was only supposed to be used when fielding a query for a completely unknown naming context. However, e.g. back-bdb tries to use the default referral whenever a requested entry does not exist, and leaves it to the frontend to turn that result back into NoSuchObject as appropriate. For cases where the context is known, but no data is present, it should just return NoSuchObject. Sending the client off to who-knows-where is completely wrong in this case. And of course, there should have been genuine X.500-style knowledge references, explicitly set for superior, peer, and subordinate DSAs. Any request that doesn't match the known naming contexts, or any of the explicitly defined knowledge references, should simply fail with NoSuchObject. The notion of "default referral" is just sloppy all around. -- -- 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#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

I wrote: > And speaking for my own little corner of the standardization process, > I definitly was ignorant about them and wanted nothing to do with > them. I've still never had any use for LDAP referrals. Hmm. Now that I think of it, that's not true. I did get involved in the details, sort of, but indeed not with the "big picture". It's just in real life I never used them, so to me it was almost a purely theoretical exercise. -- Hallvard

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >>Howard Chu writes: >>>> Both RFCs disagree. >>> >>> They are wrong. Or at least, under-specified. In X.501 section 17.3 >>> "Directory Distribution Model" it's quite clear that all of the >>> components of a distributed directory must belong to a single DIT. >> >> Which is not true in the LDAP world, and I don't know about today's >> X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe >> the X.500 world has also switched to 'dc' structure, I don't know. >> >> Anyway, LDAP is not X.500. > > RFC4510 Section 2 "Relationship to X.500" > (...) An LDAP server MUST act in accordance with the X.500 (1993) > series (...) Except when it doesn't. Like the various implications of sending text instead of ASN.1 and numeric OIDs. > (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 > it's clear that nobody knew what they were doing, or nobody wanted to > tackle the glaring absence of an analogue to X.500 DSP. LDAPv2 (the standard) has no referrals. The Umich implementation introduced them as a hack: It stuffed them into the errorMessage field. LDAPv3 moved them into the standard. And speaking for my own little corner of the standardization process, I definitly was ignorant about them and wanted nothing to do with them. I've still never had any use for LDAP referrals. > They should never have been introduced. We're stuck with them for > now, but we can at least try to make them make sense. Well, take it up with ldapext. And add an option to slapd to reject attempts to add 'ref' attrs with a DN, or whatever. For now, once the directory contains a 'ref' URL which includes the DN, I don't see any reason not to rewrite like the spec says. Whatever the "right answer" is, a referral with an un-rewritten DN seems worse than with a rewritten one. Regarding the branches of bdb_referrals() and ldif_back_referrals() which rewrite default_referral: I suggest we delete it. The back-ldif code breaks exactly as one would expect: With referral ldap://urgle/ database ldif suffix o=foo and an empty database, ldapcompare cn=bar,o=foo gives a referral to urgle. So does ldapadd of o=foo:-( I seem to remember someone meant the latter was correct and there was a control to prevent it at some point, maybe that is related. back-bdb has a test which prevents this referral in case of the suffix dn, but not for superior DNs. But I don't see why it would not be just as buggy for superiors, if it could happen. -- Hallvard

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs