Re: Antwort: Re: distributed directories [Virus checked]

["Pierangelo Masarati" <ando@sys-net.it>]

>>> A) How do ACLs work in such a setup? I can imagine that one may get
>>> better  performance if ACLs are determined on the caching server:
>
>>In general it is not a good idea, but it can be based on the trust you
> can
>>put on the caching servers.  In the scenario you're drawing it appears
>
> In fact, this whole bussines with ACLs has been bothering me since the
> beginning. Everything else in openLDAP scales quite nicely, but ACLs
> (and  other things, like "limit" statements & ssl certs) have to be
> entered  again and again on every server. It's exactly the
> administrators nightmare  situation we are trying to avoid in the first
> place. :-(

If you work with (caching) proxies, you don't need ACLs on the proxy,
because the ACLs at the remote, central server will ensure that
the proxy doesn't get more than it's allowed.  This, if you don't cache,
doesn't load the proxy with the extra overhead of doing ACL checks
twice, in addition to fetching data.  According to OpenLDAP's
implementation, caching is based on filter patterns and on client's
identity (please correct me if I'm wrong), so you don't need ACLs again,
because the cache is used only if the SAME identity performs the SAME
search asking the SAME attributes.

>
> Automatically updating part of the slapd configuration file on slave
> servers at server start (btw, can slapd re-load the configuration
> without  restart?)

Not yet.  There are plans to move configuration to a back-config that
allows configuraton changes at run-time via LDAP protocol, but it's a work
in progress.  Howard Chu might give you more details and maybe a roadmap.

> sounds like a good idea. I can think of two ways to
> do it:
>
> 1) classical way, with scp/rsync or such. That's simple to do, but why
> do  we have an LDAP server for?
> 2) Store the ACLs data for slaves in LDAP, and read them from the master
>  server when needed. Anyone went this way?

This is called ACI.  There's no standard, but OpenLDAP can do it.
It's not my favourite ACL solution, but it works.

>
> One step further would be to "read the slapd configuration from master
> LDAP server". I presume this is an old idea - what was the result of
> discussions so far?

See above.  Of course, you can implement your own solution of remotely
gently killing, rsync'ing and restarting slapd to update configuration
(I did it once, and it worked fine); when the back-config will be
available, I guess to load the configuration at startup from another
server would be an option; it can then be kept in sync by means of ldap
sync.

I don't like too much this type of solutions, because they imply that the
remote server with the configuration is up and running; moreover, what if
there's an error in the remote configuration?  Instead of disabling just
one server, you disable all simultaneously, and you can easily re-enable
the one you have access to, but what if the other ones are set to a state
that is unable to recover and sync again with the master configuration? 
Too many problems.  Unless you plan to have hundreds of servers...

In any case, if this type of solution is really necessary or advisable,
it's worth thinking about it.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it