[Date Prev][Date Next]
Re: Replication, ACL's - newbie questions.
--On Tuesday, June 19, 2007 12:05 PM -0300 email@example.com wrote:
I have about 10 locations on my tree where specific DN's have write
access. To get the ACL's properly processed I have these ACL's before an
ACL to resource "*" to the LDAP admin (access to * \ by "admin,suffix"
write \ by * read).
On the slaves I should not have an ACL to each of those entries (those
10 before), cause if so, on each one I have to add an extra line to the
replication agent for that slave. I need just one like this:
access to *
by "admin,suffix" write
by replication-agent-for-this-slave,suffix write
by * read
on the slave the replication DN is the only one requesting write access
on syncronization(?), at least on the logs that's what I get, and it
makes more sense. Despite the DN used to write on the master, always the
replication agent is the one to request write access to the slave tree.
And another thing:
If I try to write anything on the slave with any DN (even admin DN) I
get a referral error/message, ok, but when using the replication DN for
that slave, I can write with no problems..then the databases are out of
sync. I know nobody but the slapd and slurpd will have access to that DN
pass, but is that right? Should the replication DN be able to write to
the slave tree directly? Is there a way to make it right just when called
by slurpd? (*Of course* it does have to write directly to the slave db,
that's why it exists, if there were a way to make it do so just when
called by slurpd..(I don't know who starts the write process if it's
slapd or slurpd.)
You aren't supposed to write to the slave directly by yourself. Only the
replication DN is supposed. Which is why only an entity authorized to do
replication (slurpd, syncrepl) should use that bind dn. If you are giving
that bind dn to multiple applications, then that's bad design.
Principal Software Engineer
Zimbra :: the leader in open source messaging and collaboration