[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: backend overlays
> And what about other auth mechanisms
> instead of using a rootpw?
Other mechs (i.e. SASL) is handled by the frontend; in this case, you get
to back-config operations already bound. The rootdn is only to solve the
chicken'n'egg problem or so.
>
> For item #1:
>
> My master's slapd.conf is very different from the slapd.conf on the
> replica's, as it has minimal indexing, and a completely different set of
> ACL's. How am I supposed to make modifications to the replica's
> configuration? I have to assume that the back-config DB is never a
> candidate for replication? In that case, it will be a pain to make
> updates
> to the replica's, as you'll have to modify every single one individually.
> If not, then do we have multiple back-config directives, one per system,
> residing on the master, so that when a modification is made to the master
> for a particular replica, it'll propagate the changes to that particular
> replica? Or do we now require that the master & replica always match in
> configuration?
I think the latter should be an option (maybe it's already taken into
account?), i.e. some config options could be generic, and other DSA
specific, and DSAs could be instructured as where to get their config
options from, resorting to generic whenever specific are not available
(e.g. by using collective attributes or so).
Maybe the syncprov overlay could be used to point consumers to the
appropriate configuration server, e.g. by installing appropriate
operational attributes in the context or so.
I note that back-monitor is providing a backend API to allow internals to
install custom attributes and/or entries and subtrees inside back-monitor;
I was considering the possibility to use this API to generate all
back-monitor entries.
>
> For item #2:
>
> I don't have any rootpw defined in any of my systems, as I use SASL/GSSAPI
> authentication for all write-related activity. I assume for the
> back-config stuff then, it will be possible to define an ACL saying what
> principal can write to that DB? Or a configuration directive?
I guess that, as soon as back-config uses the frontend's access checking
capabilities, your guess is correct. I only fear transient cases, when
access control is not ready yet but you want to write a configuration. In
those cases you'll likely need the rootdn.
p.
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497