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

[Mark Adamson <adamson@andrew.cmu.edu>]

> You mean using the include mechanism to have different slapd.conf files for 
> each database but also one global slapd.conf which includes the replication 
> core commands from files which are included by the unused (by slapd) 
> slapd.conf files, too? Tricky workaround

No, I mean have a slapd.conf file for slapd, and then a slurpd.conf1,
slurpd.conf2, and slurpd.conf3.  No file includes any of the others, they
are all freestanding. If you want to try it with "include" directives, you
can, but that is not what I would do.  You'd run

 #  slapd
 #  slurpd -f slurpd.conf1 -t var/slurpd1
 #  slurpd -f slurpd.conf2 -t var/slurpd2
 #  slurpd -f slurpd.conf3 -t var/slurpd3



> > Consider that the slurpd has to authenticate to the slave servers,
> > and you should authenticate to a DN within the database being updated. If
> > you try to run one slurpd that updates 3 different databases, what DN are
> > you binding as to update THREE databases?
> 
> As stated on the replica line?! Not sure whether I understand the core of 
> your question.


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.

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.


  -Mark Adamson
   Carnegie Mellon