[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5354) slapd repeatedly hangs and stops reponding
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.