openldap-bugs February 2008

openldap-bugs@openldap.org

42 participants
207 discussions

(ITS#5359) Add BDB encryption support
by hyc＠OpenLDAP.org 08 Feb '08

08 Feb '08

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc Encryption support was added to HEAD on 2007-12-15. Just filing this here for tracking purposes. Some discussion followed here http://www.openldap.org/lists/openldap-devel/200712/msg00082.html

1 0

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

08 Feb '08

Howard Chu writes: >Hallvard B Furuseth wrote: >>hyc(a)symas.com writes: >>> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >>> anything specific about it. >> >> Yes it does. Section 4.1.10. Referral: >> - If the<dn> part is present, the client uses this name in its next >> request to progress the operation, and if it is not present the >> client uses the same name as in the original request. > > Yes, I saw that. But the text doesn't give any explanation of the > ramifications of what it's describing. Which is what I'm complaining > about here. Take it up with ldapext:-) And I guess we could make a slapd.conf option which turns on your preferred way. The ramifications are that things can break, I think. In particular DN-valued attributes in the search result or in an Add request. The server can't help with that either, the client would have to handle it. Also, now that I think of it, back-hdb/ldif subtree rename is broken if there are referral objects with DNs in the subtree. So I guess the slapd.conf option should allow to strip DNs that match the entry DN. And maybe allow to be more paranoid about rewriting writes (and Binds?) than searches. However... >> 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. Remember, LDAP referrals need not even be LDAP URLs. My guess is that's one reason for the difference from X.500: When you can even return a HTTP URL, why should you _not_ be allowed to return a far smaller change from the original URL? Also LDAP started out a lot sloppier than X.500. Getting some response which hopefully resembled what you wanted was better than none:-) > And again, the service model requires the directory to store the > client's data without any alteration. If the client wants to create > the entry "cn=me,o=we" either that exact entry must be created, or the > operation must fail. Well, the operation does fail in the original server. Then the client may try another operation at another server... I don't know if that's a valid interpretation of the service model or not. In any case, it's a detail compared to the mess -- Hallvard

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Howard Chu wrote: > Oren Laadan wrote: >> Howard Chu wrote: >>> This discussion has wandered off of potential bugs and into regular >>> software usage. You should pick this up again on the -software mailing >>> list. This ITS will be closed. >> >> Well, the fact is that as far as I can tell the meta-URIs are not >> mis-configured, the server works well for some random amount of time >> and then reaches a lockup. True, the configuration isn't the optimal >> in terms of performance. However, in the absence of text in the man >> pages that prohibits doing so, the observed behavior is buggy. >> >> In fact, there is at least one example in the archives of -software >> that discusses a deployment of meta with "uri ldap://localhost/" that >> seems to have gone ok without too much criticism: >> http://www.openldap.org/lists/openldap-software/200301/msg00112.html) > > The URIs in that example clearly do not overlap with the actual meta > database. It's also not stated in the example, but it's most likely that > that example is directing queries to a separate slapd process. In your > config, your URIs clearly *do* overlap with your meta database, which > guarantees an infinite loop. True. The guy is merging three subtrees into a single tree to a common root, while I try to merge two database that into the exact same DN. > >> To that I'll add, that to the best of my knowledge and after reading >> and re-reading the docs and the man-pages, I cannot find another way >> to merge two databases (not distinct subtrees) such that a local db >> adds entries to a remote db, but to use meta. > > You haven't provided any information to explain why you cannot structure > your additional entries as a distinct subtree. You're still just > handwaving when we ask for concrete examples of the entries involved. Clearly I'm new to LDAP. Please indicate what information is missing, I'll be happy to provide, even the local database (my .ldif file) and sample queries from the remote server. Just name it. Taking a step back: we have a departmental LDAP server for user auth, (posix) groups, autofs maps and so on. In my group, we add to the DB groups and autofs maps that do not exist on the remote server, so a user on our machines can belong to additional groups. I am not arguing that I cannot structure it differently. I simply do not know if I can structure it differently. Ideally I could add entries to the remote database, but that is impossible. The remote server gives DN dc=MAIN,dc=EXAMPLE,dc=COM, which is what I made the local server give (via the meta backend) and which is what the clients are using as their base DN. The local database (.ldif file) currently looks like this, in this example adding the group LOCAL_GRP with user USER1 USER2 (there are more entries, also for autofs maps, but I think this explains the idea). # root/base dn: dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM dc: EXAMPLE objectClass: top objectClass: domain # group subtree dn: ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM ou: Group objectClass: top objectClass: organizationalUnit # specific group information dn: cn=LOCAL_GRP,ou=Group,dc=ABC,dc=MAIN,dc=EXAMPLE,dc=COM cn: LOCAL_GRP objectClass: posixGroup objectClass: uidObject gidNumber: 1000 memberUid: USER1 memberUid: USER2 uid: root > The best of your knowledge clearly didn't get you very far or you > wouldn't have been asking for help in the first place. For you to > second-guess the folks trying to help you and omit the information > requested really isn't very productive. No need to make it a personal. I'm new to LDAP, but not clueless either. I truly appreciate the time and efforts that you guys are putting into this issue (and ldap in general). I only omit information because I'm not aware of its importance to you. It helps if you indicate what's missing, and I'll provide promptly, as I've been doing so far. > >> So: the config seems fine (see the original ticket), I need to use meta, >> but it exhibits random lockups. Using a suboptimal solution is not a >> bug. Random lockups are a symptom of a bug :( > > No. Lockups due to thread exhaustion are a symptom of a bad configuration. I then suggest that this specific issue be mentioned in the ldap-meta man-page (as it is now, it doesn't read so), for the sake of others. > >> (That said, I will ask on the -software list with regard to alternative >> configurations, as you suggest). (also sent a message to the -software list as you suggested; made it with shorted DN for simplicity) Thanks, Oren.

1 0

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

08 Feb '08

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >> Frankly this whole example doesn't make sense, and RFC4511 doesn't say >> anything specific about it. > > Yes it does. Section 4.1.10. Referral: > - If the<dn> part is present, the client uses this name in its next > request to progress the operation, and if it is not present the > client uses the same name as in the original request. Yes, I saw that. But the text doesn't give any explanation of the ramifications of what it's describing. Which is what I'm complaining about here. >> A referral is not an alias. If I try to add an entry "cn=me,o=we" then >> that is the DN that the entry must be created with. If something >> redirects me to create "cn=me,o=they" this should be an error - that >> is not the entry I requested the server to create. > 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. And again, the service model requires the directory to store the client's data without any alteration. If the client wants to create the entry "cn=me,o=we" either that exact entry must be created, or the operation must fail. > RFC 4511 4.1.10. Referral: > - It is RECOMMENDED that the<dn> part be present to avoid ambiguity. > RFC 3296 section 2.2 (about 'ref'): > The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP > URLs with absent or empty DN parts or with explicit scope specifier > is not defined by this specification. > RFC 3296 Section 5.2: > The DN part MUST be modified such that it refers to the appropriate > target in the referenced server (as detailed below). Even where the > DN to be returned is the same as the target DN, the DN part SHOULD > NOT be trimmed. The X.500 model does not allow for arbitrary DNs to be inserted here. The RFC text implies that arbitrary DNs are allowed, but that's incorrect. -- -- 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 08 Feb '08

08 Feb '08

hyc(a)symas.com writes: > Frankly this whole example doesn't make sense, and RFC4511 doesn't say > anything specific about it. Yes it does. Section 4.1.10. Referral: - If the <dn> part is present, the client uses this name in its next request to progress the operation, and if it is not present the client uses the same name as in the original request. > A referral is not an alias. If I try to add an entry "cn=me,o=we" then > that is the DN that the entry must be created with. If something > redirects me to create "cn=me,o=they" this should be an error - that > is not the entry I requested the server to create. RFC 3296 (Named Subordinate References in LDAP) disagrees: 4. Named Subordinate References Typically the DN of the referral object and the DN of the object in ^^^^^^^^^ the referenced server are the same. 5.1. Example Configuration dn: OU=People,O=MNN,C=WW ^^^^ ou: People ref: ldap://hostb/OU=People,O=MNN,C=US ref: ldap://hostc/OU=People,O=MNN,C=US ^^^^ objectClass: referral objectClass: extensibleObject > In general, I think it is inappropriate for referral URIs to contain DNs. Both RFCs disagree. RFC 4511 4.1.10. Referral: - It is RECOMMENDED that the <dn> part be present to avoid ambiguity. RFC 3296 section 2.2 (about 'ref'): The LDAP URL SHOULD contain a non-empty DN. The handling of LDAP URLs with absent or empty DN parts or with explicit scope specifier is not defined by this specification. RFC 3296 Section 5.2: The DN part MUST be modified such that it refers to the appropriate target in the referenced server (as detailed below). Even where the DN to be returned is the same as the target DN, the DN part SHOULD NOT be trimmed. -- Hallvard

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 08 Feb '08

08 Feb '08

Oren Laadan wrote: > Howard Chu wrote: >> This discussion has wandered off of potential bugs and into regular >> software usage. You should pick this up again on the -software mailing >> list. This ITS will be closed. > > Well, the fact is that as far as I can tell the meta-URIs are not > mis-configured, the server works well for some random amount of time > and then reaches a lockup. True, the configuration isn't the optimal > in terms of performance. However, in the absence of text in the man > pages that prohibits doing so, the observed behavior is buggy. > > In fact, there is at least one example in the archives of -software > that discusses a deployment of meta with "uri ldap://localhost/" that > seems to have gone ok without too much criticism: > http://www.openldap.org/lists/openldap-software/200301/msg00112.html) The URIs in that example clearly do not overlap with the actual meta database. It's also not stated in the example, but it's most likely that that example is directing queries to a separate slapd process. In your config, your URIs clearly *do* overlap with your meta database, which guarantees an infinite loop. > To that I'll add, that to the best of my knowledge and after reading > and re-reading the docs and the man-pages, I cannot find another way > to merge two databases (not distinct subtrees) such that a local db > adds entries to a remote db, but to use meta. You haven't provided any information to explain why you cannot structure your additional entries as a distinct subtree. You're still just handwaving when we ask for concrete examples of the entries involved. The best of your knowledge clearly didn't get you very far or you wouldn't have been asking for help in the first place. For you to second-guess the folks trying to help you and omit the information requested really isn't very productive. > So: the config seems fine (see the original ticket), I need to use meta, > but it exhibits random lockups. Using a suboptimal solution is not a > bug. Random lockups are a symptom of a bug :( No. Lockups due to thread exhaustion are a symptom of a bad configuration. > (That said, I will ask on the -software list with regard to alternative > configurations, as you suggest). -- -- 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#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Howard Chu wrote: > Oren Laadan wrote: >> >> Pierangelo Masarati wrote: >>> hyc(a)symas.com wrote: >>>> Oren Laadan wrote: >>>>>> It shows enough; back-meta is hanging waiting for responses from >>>>>> some other >>>>>> LDAP server. This is a pretty bad configuration; you should not >>>>>> use back-meta >>>>>> (or back-ldap) to redirect queries back into the same slapd. You >>>>>> should use >>>>>> back-relay instead. >>>>> I'm not quite sure why having the server query itself is such a bad >>>>> idea. >>>>> Can you please explain ? >>>> Any request then occupies a minimum of two slapd threads - one for >>>> back-meta >>>> itself, and one for the extra inbound query. If you misconfigure the >>>> meta URIs >>>> then you get into an infinite loop, which consumes all of the >>>> available slapd >>>> threads. >>> Let me add that, moreover, any request is re-encoded as an LDAP request, >>> sent to itself, re-decoded and re-processed by slapd. Back-relay >>> directly relies the original, decoded request to another database, >>> within the same thread. So it saves at least 3 resource-consuming >>> steps- >>> >> >> Ok, I see the rational. So I guess my question is whether back-relay >> gives >> the same functionality like ldap-meta (that is, merging the two >> databases, >> the remote one and the local one) except better with respect to a local >> database ? and if so, then how would I set it up for this ? >> >> I looked at "subordinate" directive but I'm not sure it helps, since as >> far as I could tell it can join two disjoint subtrees into seemingly one >> big database. However, what I need is to add local (new) entries (not >> only modify attributes) to an existing database. > > This discussion has wandered off of potential bugs and into regular > software usage. You should pick this up again on the -software mailing > list. This ITS will be closed. Well, the fact is that as far as I can tell the meta-URIs are not mis-configured, the server works well for some random amount of time and then reaches a lockup. True, the configuration isn't the optimal in terms of performance. However, in the absence of text in the man pages that prohibits doing so, the observed behavior is buggy. In fact, there is at least one example in the archives of -software that discusses a deployment of meta with "uri ldap://localhost/" that seems to have gone ok without too much criticism: http://www.openldap.org/lists/openldap-software/200301/msg00112.html) To that I'll add, that to the best of my knowledge and after reading and re-reading the docs and the man-pages, I cannot find another way to merge two databases (not distinct subtrees) such that a local db adds entries to a remote db, but to use meta. So: the config seems fine (see the original ticket), I need to use meta, but it exhibits random lockups. Using a suboptimal solution is not a bug. Random lockups are a symptom of a bug :( (That said, I will ask on the -software list with regard to alternative configurations, as you suggest). Oren.

1 0

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

08 Feb '08

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If a referral object's "ref" DN differs from the entry DN, and > you update a subordinate of the referral object, the DN part > of the referral from back-bdb is wrong. > > bash$ cat ref.ldif > dn: o=we > o: we > ref: ldap://elsewhere/o=they > objectClass: referral > objectClass: extensibleObject > > dn: cn=me,o=we > cn: me > objectClass: organizationalRole > > bash$ ldapadd ...< ref.ldif > adding new entry "o=we" > > adding new entry "cn=me,o=we" > ldap_add: Referral (10) > matched DN: o=we > referrals: > ldap://elsewhere/cn=me,o=we Frankly this whole example doesn't make sense, and RFC4511 doesn't say anything specific about it. A referral is not an alias. If I try to add an entry "cn=me,o=we" then that is the DN that the entry must be created with. If something redirects me to create "cn=me,o=they" this should be an error - that is not the entry I requested the server to create. In general, I think it is inappropriate for referral URIs to contain DNs. It is inappropriate for the server to alter the DN that the client supplied. In the case of a search, it is inappropriate for the server to continue the search outside the scope specified by the client. E.g., if the client requests a subtree search with base "o=we" it is incorrect for the client to receive entries based at "o=they". (Aliases are an exception to this behavior, but aliases also are only valid for searches, not for any other operation.) > It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96: > > rs->sr_ref = referral_rewrite( ref, NULL, > &op->o_req_dn, LDAP_SCOPE_DEFAULT ); > > I don't quite understand that function though: > Why does it use default_referral (slapd.conf 'referral')? That is for > use when no local backend database handles the operation, which I would > think means no database's be_chk_referrals() gets be called. And indeed > the function uses it if > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database. -- -- 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#5354) slapd repeatedly hangs and stops reponding
by hyc＠symas.com 08 Feb '08

08 Feb '08

Oren Laadan wrote: > > Pierangelo Masarati wrote: >> hyc(a)symas.com wrote: >>> Oren Laadan wrote: >>>>> It shows enough; back-meta is hanging waiting for responses from some other >>>>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>>>> (or back-ldap) to redirect queries back into the same slapd. You should use >>>>> back-relay instead. >>>> I'm not quite sure why having the server query itself is such a bad idea. >>>> Can you please explain ? >>> Any request then occupies a minimum of two slapd threads - one for back-meta >>> itself, and one for the extra inbound query. If you misconfigure the meta URIs >>> then you get into an infinite loop, which consumes all of the available slapd >>> threads. >> Let me add that, moreover, any request is re-encoded as an LDAP request, >> sent to itself, re-decoded and re-processed by slapd. Back-relay >> directly relies the original, decoded request to another database, >> within the same thread. So it saves at least 3 resource-consuming steps- >> > > Ok, I see the rational. So I guess my question is whether back-relay gives > the same functionality like ldap-meta (that is, merging the two databases, > the remote one and the local one) except better with respect to a local > database ? and if so, then how would I set it up for this ? > > I looked at "subordinate" directive but I'm not sure it helps, since as > far as I could tell it can join two disjoint subtrees into seemingly one > big database. However, what I need is to add local (new) entries (not > only modify attributes) to an existing database. This discussion has wandered off of potential bugs and into regular software usage. You should pick this up again on the -software mailing list. This ITS will be closed. -- -- 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#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 08 Feb '08

08 Feb '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> Oren Laadan wrote: >>>> It shows enough; back-meta is hanging waiting for responses from some other >>>> LDAP server. This is a pretty bad configuration; you should not use back-meta >>>> (or back-ldap) to redirect queries back into the same slapd. You should use >>>> back-relay instead. >>> I'm not quite sure why having the server query itself is such a bad idea. >>> Can you please explain ? >> Any request then occupies a minimum of two slapd threads - one for back-meta >> itself, and one for the extra inbound query. If you misconfigure the meta URIs >> then you get into an infinite loop, which consumes all of the available slapd >> threads. > > Let me add that, moreover, any request is re-encoded as an LDAP request, > sent to itself, re-decoded and re-processed by slapd. Back-relay > directly relies the original, decoded request to another database, > within the same thread. So it saves at least 3 resource-consuming steps- > Ok, I see the rational. So I guess my question is whether back-relay gives the same functionality like ldap-meta (that is, merging the two databases, the remote one and the local one) except better with respect to a local database ? and if so, then how would I set it up for this ? I looked at "subordinate" directive but I'm not sure it helps, since as far as I could tell it can join two disjoint subtrees into seemingly one big database. However, what I need is to add local (new) entries (not only modify attributes) to an existing database. Thanks, Oren. > 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

← Newer
1
...
11
12
13
14
15
16
17
...
21
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2008