[Date Prev][Date Next] [Chronological] [Thread] [Top]

Backglue + global rwm hang


I'm still trying to solve a problem that was already discussed here.

According to ITS#3971 comments, I've tried to instantiate rwm globally:

overlay         rwm
rwm-suffixmassage       o=Foo,ou=Domains dc=foo,dc=ru
rwm-suffixmassage       o=Bar,ou=Domains dc=bar,dc=ru
# and so on, about 10 directives

# Real database
database        bdb
directory       /var/lib/ldap/foo.ru
suffix          dc=foo,dc=ru
rootdn          ...

# "Mount" it under o=Foo,ou=Domains
database        relay
suffix          o=Foo,ou=Domains
relay           dc=foo,dc=ru
rootdn          ...

# Another one
database        bdb
directory       /var/lib/ldap/bar.ru
suffix          dc=bar,dc=ru
rootdn          ...

# "Mount" it under o=Bar,ou=Domains
database        relay
suffix          o=Bar,ou=Domains
relay           dc=bar,dc=ru
rootdn          ...

# and so on, about 10 databases

# Finally:
# Dummy db to provide root to subordinates
database        bdb
suffix          ou=Domains
directory       /var/lib/ldap
rootdn          ...

(What's this all about? I'm trying to propagate search based at
ou=Domains to several databases, in order to achieve interoperability
with legacy software that supports searching only one base DN for its
Subordinates + relay/massage seems to be the best solution for now.)

ldapsearch'ing -b o=Foo,ou=Domains gives correct results (the same as
searching dc=foo,dc=ru)
ldapsearch'ing -b ou=Domains makes slapd eat 99% CPU and gives no
output, even if there is only one real database (say, dc=foo,dc=ru).

Tested on both 2.3.7 and HEAD (as of 03.10.2005), Linux 2.6.12. 

In fact I need this functionality (subordinates + relay + suffixmassage)
rather urgently; so I'll probably continue investigating this on my own,
but any information and useful tips are welcome. I'll ask you OpenLDAP
developers please to estimate whether it would be easier to fix this
instability issue or to focus at that "nasty interaction" between
backglue and local rwm, filed as ITS#3971.

Thank you!