[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Q: bug? slurpd only using first defined replog file?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have a problem with slurpd. To me it seems that slurpd only uses the first
replog entry inside of a slapd.conf. Reason: I have three databases (based on
ldbm) inside my slapd.conf, something like this:
# first database
database ldbm
access to * by * write
lastmod off
readonly off
suffix "ou=ou_a,o=otop,c=de""
directory /usr/local/LDAP/ou_a
replogfile /usr/local/LDAP/ou_a/replog
replica host=10.151.4.13:9389 bindmethod=simple
binddn="cn=localAdmin,ou=ou_a,o=otop,c=de" credentials=ladmin
rootdn "cn=root,o=otop,c=de"
rootpw secret
# second database
database ldbm
access to * by * write
lastmod off
readonly off
suffix "ou=ou_b,o=otop,c=de""
directory /usr/local/LDAP/ou_b
replogfile /usr/local/LDAP/ou_b/replog
replica host=10.151.4.13:8389 bindmethod=simple
binddn="cn=localAdmin,ou=ou_b,o=otop,c=de" credentials=ladmin
rootdn "cn=root,o=otop,c=de"
rootpw secret
# third database
database ldbm
access to * by * write
lastmod off
readonly off
suffix "o=otop,c=de""
directory /usr/local/LDAP
rootdn "cn=root,o=otop,c=de"
rootpw secret
So I want the two first databases to be replicated. I set up the replicated
databases, started the master server, the slave servers (2) and then the
replication daemon. What happens is that only the first database is
replicated. What can be the reason for this?
When I place the definition of the first database (ou_a) as the second one in
the config file (ou_b is now the first database definition in slapd.conf)
then the ou_b is replicated but ou_a is no longer replicated. This I can
verify by:
1) running the three LDAP servers (master + 2 slaves) and slurpd with full
debugging; nothing happens on slurpd or slave part; only master changes
2) viewing the databases with slapcat
FYI: I am using OpenLDAP 2.0.7 with Linux Kernel 2.2.18 (SuSE 7.0).
Can anyone verify this behaviour and/or explain it?
If I understand the manpage right then replog is a backend option and no
global one.
Hmm ... I found some information inside the debugging output of slurpd:
Retrieved state information for 10.151.4.13:8389 (timestamp 985252666.1)
Retrieved state information for 10.151.4.13:9389 (timestamp .0)
Can this be the reason for this behaviour? As I see every entry for the
second-placed database definition is considered as being "old".
FYI: looking at the process table I see 5 instances of the slurpd daemon. Is
this ok? I would have expected one master process and one for each
replogfile.
Another curious thing: looking at the used file descriptors using the proc
file system I notice that all 5 instances use the same files. Here is an
example:
dr-x------ 2 root root 0 Mar 22 10:57 .
dr-xr-xr-x 3 root root 0 Mar 22 10:57 ..
lrwx------ 1 root root 64 Mar 22 10:57 0 -> /dev/pts/24
l-wx------ 1 root root 64 Mar 22 10:57 1 ->
/usr/local/LDAP/slurpd.log
l-wx------ 1 root root 64 Mar 22 10:57 2 ->
/usr/local/LDAP/slurpd.log
lrwx------ 1 root root 64 Mar 22 10:57 3 -> socket:[1002305]
lr-x------ 1 root root 64 Mar 22 10:57 4 -> pipe:[1002306]
l-wx------ 1 root root 64 Mar 22 10:57 5 -> pipe:[1002306]
lrwx------ 1 root root 64 Mar 22 10:57 6 -> socket:[1002307]
l-wx------ 1 root root 64 Mar 22 10:57 7 ->
/opt/openldap-2.0.7/var/openldap-slurp/replica/slurpd.status.lock
lrwx------ 1 root root 64 Mar 22 10:57 8 ->
/opt/openldap-2.0.7/var/openldap-slurp/replica/slurpd.status
Descriptors 1 und 2 (stdout/stderr) are redirected to a log file. All other
entries point to the same socket/pipe ids for every instance.
- --
Heiko Nardmann (Dipl.-Ing.), h.nardmann@secunet.de, Software Development
secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de),
Weidenauer Str. 223-225, D-57076 Siegen
Tel. : +49 271 48950-13, Fax : +49 271 48950-50
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6uiHhpm53PRScYygRAoBuAJ45kk8ekVHSSpn3basi+0EOANlwDACeMc2U
gQWBKVvYozVR5U5K+VKt+nA=
=b07u
-----END PGP SIGNATURE-----