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

Re: Q: bug? slurpd only using first defined replog file?

To: OpenLDAP Bugs <openldap-bugs@OpenLDAP.org>
Subject: Re: Q: bug? slurpd only using first defined replog file?
From: Heiko Nardmann <h.nardmann@secunet.de>
Date: Thu, 22 Mar 2001 18:07:16 +0100
In-reply-to: <0103221701370H.05582@snsrv053>
Organization: secunet Security Networks AG
References: <0103221701370H.05582@snsrv053>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seeking for the reason of the described behaviour I had a look the treatment 
of the replogfile option in both slapd and slurpd.
Here is what I found out:
in slapd the replogfile value is stored together with its BackendDB structure 
(or in the global variable replogfile if no BackendDB is available); in 
slurpd there is only this global variable replogfile - so there is no 
possibility to store multiple replogfile. As soon as a replogfile option is 
seen everyone coming later is thrown away.

What has to be done to solve this problem?

First I thought that adding a 'replogfile' member to the Ri structure which 
holds all information about a replication should be enough for keeping the 
information. But since the replogfile has to be associated with its database 
I now think that we need a database structure (as in slapd  the structure 
BackendDB) which holds its list of replications and its replogfile 
information.

E.g.

typedef struct slap_backend_db BackendDB;
struct slap_backend_db {
	/* Number of replicas we're servicing */
	int num_replicas;
	/* Array of pointers to replica info */
	Ri **replicas;
	/* Name of slurpd status file (timestamp of last replog */
	char slurpd_status_file[ MAXPATHLEN ];
	/* Name of the replication log slapd is writing (and we are reading) */
	char slapd_replogfile[ MAXPATHLEN ];
};

So the identical entries in the struct globals have to be move to this new 
structure which has to replace them in struct globals.

The file config.c has to be rewritten so that it recognizes the "database" 
statements (as slapd does) and creates an apropriate slap_backend_db 
structure. Maybe both slapd and slurpd config.c files could be merged to one 
file (with some additional defines or macros)?

Since I did not receive any comments about my bug report by the developers so 
far I include my old mail here for reference.

On Thursday 22 March 2001 17:01, Heiko Nardmann wrote:
> -----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-----

- -- 
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

iD8DBQE6ujFEpm53PRScYygRAnj6AKDYt73xbarwBKQkvAe0j0R8UyyrpQCg4aPi
GiNtDd+dHQ9W04eQG9vQWKY=
=zReV
-----END PGP SIGNATURE-----

Follow-Ups:
- Re: Q: bug? slurpd only using first defined replog file?
  - From: Mark Adamson <adamson@andrew.cmu.edu>

References:
- Q: bug? slurpd only using first defined replog file?
  - From: Heiko Nardmann <h.nardmann@secunet.de>

Prev by Date: Q: bug? slurpd only using first defined replog file?
Next by Date: Referral chasing mistery
Index(es):
- Chronological
- Thread