LDAP [was: Re: [plug] NFS]
Craig Ringer
craig at postnewspapers.com.au
Sat May 31 18:04:14 WST 2003
> A general note (probably not applicable to a home-office scenario) is
> that OpenLDAP's slurpd replication works well (when it works).
It's a bit fussy to set up, but once it's running it works well. The
method I use involves adding a "replica master" user to the db,
generally outside the normal user tree. slapd on the master is then
configured to replicate to a given host (all on one line):
replica host=bucket.localnet binddn="cn=repmaster,dc=localnet"
bindmethod=simple credentials="repmaster"
while the client sets the "updatedn" and "updateref" values to accept
replication from the remote slurpd and forward modifications to the
master server:
updatedn cn=repmaster,dc=localnet
updateref ldap://10.0.0.10/dc=localnet
Then, I stop slapd, use slapcat > /tmp/dbfile, copy the db to the new
machine then use slapadd to read it back. This works well even if the
two hosts are running different slapd versions or are compiled against
different db libraries.
You'll usually want to remove any pending "rejected" replications too.
Put it this way - its easy enough that I'm running it on my home network
(OK, that's because we have several users, several machines, and I need
to know it well for work anyway). One of the big advantages is that each
machine can refer to its local slapd for user accounts - great if you've
borrowed the ethernet cable to do something else. Its also (marginally)
faster because the slapd is on the local machine.
> As a general authentication note, one 'save the day' feature is if your
> authentication system allows multiple auth methods to be used. Thus if
> your LDAP authentication breaks, you have a "fall back" authentication
> method.
This can be done pretty easily with PAM on linux, and is pretty much the
default when using ldap authentication. OTOH, it means you still have to
maintain users in /etc/passwd and /etc/shadow, so its usually only worth
bothering with for a few critical users, eg the person doing the ldap
dir admin.
> People often aim (and I
> think Craig mentioned something along these lines) to ensure that each
> machine's root account is always accessible.
Unfortunately, its not all that easy to do. PAM has the nasty habit of
assuming that an error on any auth method means the user should not be
authenticated, rather than that more methods should be tried. As a
result, a box that loses its ldap server may refuse to authenticate
local-only accounts. I think this is fixable with the right parameters
in PAM, but I haven't had time to really dig and find out yet.
Craig Ringer
More information about the plug
mailing list