[Date Prev][Date Next]
Re: Q: bug? slurpd only using first defined replog file?
-----BEGIN PGP SIGNED MESSAGE-----
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
Heiko Nardmann (Dipl.-Ing.), email@example.com, 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
-----END PGP SIGNATURE-----