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

Cannot create a database with more than one level of subordination -- again



Hi all,

About one month ago I wrote to this list and asked for help with a
problem mentioned in the subject field. Here I repeat a brief
description of the problem.
------------------8><----------------------------

I try to create an OpenLDAP database with more than one level of
subordination. It should look like this (the picture is somewhat
simplified by not showing some unrelated details like other branches):

dc=kt-privat,dc=donetsk,dc=ua    - the topmost level
dc=druzh,dc=kt-privat,dc=donetsk,dc=ua    - the next level, stored in
its own database
dc=micro7,dc=druzh,dc=kt-privat,dc=donetsk,dc=ua    - one more level,
also with its own database

I want to have an OpenLDAP server on each level. Or, to be more precise,
I want to have 3 servers, each holding databases for all three levels,
but the first server should be responsible for the topmost level master
replica, the second one - for the master replica of the second level and
so on. Each server should replicate the changes in its corresponding
master replica to all other ones. I hope I've managed to explain what I
mean despite of the quality of my English  :-) 

All this worked as long as there where only two levels. Two-level
configuration works now without any problems in my "real-life" environment.
Moreover, everything seemed to be good when I've tried to add the third
level (dc=micro7,...) to OpenLDAP 2.1.xxx server (I don't remember the
minor release number). But when I've tried the same thing on the
OpenLDAP 2.2.13 server, I've got an error.

...................
When I copied the database generated on the 2.1 server to the 2.2
server, the server started normally, but I observed errors when I tried
to access even the second level of the tree with various LDAP clients.
------------------8><----------------------------

Then I was advised by Matthew Sporleder to upgrade my database to 2.2
format because my problem could be caused by some hidden
incompatibilities between OpenLDAP 2.1 and 2.2 formats. I tried to do
this. Or even more, I've dumped my database with slapcat, run OpenLDAP
2.2 on the spare server and created the database with the same structure
from scratch, but now with BDB backend, which is AFAIK more natural for
OpenLDAP 2.2 than LDBM. At last I've loaded data from the old database
to the new one with slapadd.

Unfortunately this did not help. But now the situation became slightly
more clear. If with LDBM backend slapd started successfully and then
could not read data from the database, with a newly created BDB database
it even could not start. Here is an excerpt from its log (with debug
options on):
------------------8><----------------------------
Oct 11 11:14:05 trojanda slapd[18418]: slapd startup: initiated.
Oct 11 11:14:05 trojanda slapd[18418]: bdb_db_open:
dc=7micro,dc=druzh,dc=kt-pri
vat,dc=donetsk,dc=ua
Oct 11 11:14:05 trojanda slapd[18418]: bdb_db_open:
dbenv_open(/var/lib/ldap/dru
zh/7micro)
Oct 11 11:14:05 trojanda ldap: запуск slapd succeeded
Oct 11 11:14:05 trojanda slapd[18418]:
bdb(dc=7micro,dc=druzh,dc=kt-privat,dc=do
netsk,dc=ua): /var/lib/ldap/druzh/7micro/__db.001: Permission denied
Oct 11 11:14:05 trojanda slapd[18418]: bdb_db_open: dbenv_open failed:
Permissio
n denied (13)
Oct 11 11:14:05 trojanda slapd[18418]: backend_startup: bi_db_open(0)
failed! (1
3)
Oct 11 11:14:05 trojanda slapd[18418]: slapd shutdown: initiated
Oct 11 11:14:05 trojanda slapd[18418]: ====> bdb_cache_release_all
Oct 11 11:14:05 trojanda last message repeated 2 times
Oct 11 11:14:05 trojanda slapd[18418]: slapd shutdown: freeing system
resources.

Oct 11 11:14:05 trojanda slapd[18418]:
bdb(dc=7micro,dc=druzh,dc=kt-privat,dc=do
netsk,dc=ua): txn_checkpoint interface requires an environment
configured for th
e transaction subsystem
Oct 11 11:14:05 trojanda slapd[18418]: bdb_db_destroy: txn_checkpoint
failed: In
valid argument (22)
Oct 11 11:14:05 trojanda slapd[18418]: slapd stopped.
------------------8><----------------------------

Here BDB backend apparently complains on the permission denial when
trying to open the third-level database. But I cannot understand why it
does. Probably there are some unconfigured parameters, as the last 3
lines indicate (I surely am not an expert in BDB), but the same
configuration with only 2 subordination levels works well. I've checked
the access right for the file "/var/lib/ldap/druzh/7micro/__db.001"
mentioned in the 5-th and 6-th log messages. They are exactly the same
as the rights all the files on the upper database level (owner: ldap,
group: ldap, mode: 0600). So I cannot see any reason why OpenLDAP
doesn't want to work with a 3-levels database.

So, does anybody know, is it possible at all to use databases with more
than 2 levels of subordination with OpenLDAP 2.2 or higher. And if it
is, where I am wrong?

-- 

Sayonara
_______________________________________
Dmitriy Stepanenko aka Mudropolk
e-mail: mpolk@kt-privat.donetsk.ua
ICQ: 112689047 phone: (38)(0626)41-93-06