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

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



If this is a test machine, try chmod 777 on the Permission denied
file, and then try the fuser command (or lsof, or whatever) to figure
out who/what is trying to open that specific file.

On 10/11/05, Dmitriy Stepanenko <mpolk@kt-privat.donetsk.ua> wrote:
> 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
>