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

[Heiko Nardmann <h.nardmann@secunet.de>]

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

On Friday 23 March 2001 16:14, you wrote:
[...]
>
> I'm saying that the DN in the "updateDN" directive on the slave servers
> ought to be within the database being updated. It seems illogical to me
> that a single slurpd server would update entries in more than one database
> on a slave slapd server. If you had databases with prefixes "dc=a"  "dc=b"
> and "dc=c",  and the slurpd binds as "cn=root,dc=a", that binding DN
> should only be able to update entries in the "dc=a" database, and has no
> business updating entries in "dc=b" and "dc=c" databases.  You could run
> into trouble later with other authentication mechanisms where the database
> being updated wants to look up the DN that is doing the updating. "dc=b"
> will not be able to find "cn=root,dc=a" within itself.
>

Ok, that's clear, but why does a 'replica' option exist then which defines 
which binddn to use? The 'replica' option then should be a global one if one 
cannot use it for more than one replication. Probably I don't understand the 
concept behind 'replica' because it's monday morning :-)

> I have not tried this, and cannot point to code segments that will break,
> and I only bring this up as a caution that you could run into trouble
> later on if you allow 1 slurpd process to update more than 1 database on a
> slave server.

In the replogfiles of slapd (which I am observing) it can be distinguished by 
slurpd between entries which are targeted for the correct slave or not 
(saying something about 'not mine' by checking the suffix).

As far as I can say from the "huge" amount of discussion of this points 
nobody seems to be really interested in fixing it or at least possible 
solution ways?!

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

iD8DBQE6vuK3pm53PRScYygRAtj+AJ9l/FOJ0nZ93+5rjG86+VSfHU9H+gCeJ2s+
PJD8pigIUeoQZxdpVQOYdM4=
=wfUf
-----END PGP SIGNATURE-----