On Wed, Oct 13, 2004 at 11:01:42PM +1000, Russell Coker wrote:
> On Wed, 13 Oct 2004 21:26, Wouter Verhelst <wouter@grep.be> wrote:
> > On Wed, Oct 13, 2004 at 01:05:26PM +1000, Russell Coker wrote:
> > > On Wed, 13 Oct 2004 07:29, Henrique de Moraes Holschuh <hmh@debian.org>
> wrote:
> > > > The third is to not use LDAP for lookups, but rather cache them all in
> > > > a local, exteremly fast DB (I hope we are already doing that!). That
> > > > alone could get us a big speed increase on address resolution and
> > > > rewriting, depending on how the MTA is configured.
> > >
> > > I've run an ISP with more than 1,000,000 users with LDAP used for the
> > > back-end.
> >
> > Yes, but that was probably with the LDAP servers and the mail servers
> > being in the same data center, or at least with a local replication.
>
> Yes. Local replication is not difficult to setup.
Obviously not.
> > This is not the case for Debian; and yes, we already do have local fast
> > DB caches (using libnss-db).
>
> That's an entirely different issue.
No, it's not, not in this case anyway.
> libnss-db is just for faster access to /etc/passwd.
You are mistaken. In the FreeBSD implementation, it is; however, the
Linux implementation allows other things to be done with it.
For instance, my /etc/default/libnss-db contains the following lines:
ETC = /root/stage
DBS = passwd group shadow
I also have a script which creates (incomplete (as in, without system
users)) files /root/stage/{passwd,shadow,group} containing just the user
and group records that are in LDAP. Next, /etc/nsswitch.conf contains
the following:
passwd: db compat
group: db compat
shadow: db compat
/etc/passwd contains only system users and root; /var/lib/misc/passwd.db
contains my 'local' users (the ones that are in LDAP), and they can both
be queried via getent(1) or other mechanisms. Same goes, of course, for
group and shadow.
I did this after checking out how Debian does things -- although I'm
using my own (Perl) implementation, rather than the python one which is
used by Debian, called 'userdir-ldap'.
> The implementation in Linux is fairly poor however, it doesn't even
> stat /etc/passwd to see if it's newer than the db.
That's a feature, not a bug. Unless you want it to check 'the passwd
file' as it is defined in /etc/default/libnss-db (or another
configuration file), in which case it would indeed be a good idea.
> The performance gain isn't as good as you would expect either.
Been there, done that.
IME, doing this kind of thing is *way* faster than using libnss-ldap.
When I first installed LDAP, I tried using libnss-ldap. It worked; but
on my network, it was quite slow. Since the goal was to have a
centralized user database, rather than to have a fully configured LDAP
environment, I didn't want to install a slapd on each and every host.
So, I first tried the nscd solution to speed up performance. That worked
(kinda), but it still wasn't ideal. When I found out about the way
userdir-ldap handles things, I tried that out; and immediately liked it.
An added bonus is that the libnss-db Makefile will not update the .db
files if the original ones are empty; so if the LDAP daemon dies or is
unavailable for some reason, my users can still login, even after the
next time the cronjob runs. This is not the case with libnss-ldap, AIUI.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature