[Date Prev][Date Next]
Re: Q: bug? slurpd only using first defined replog file?
> 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
# 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