On Thu, Oct 14, 2004 at 12:20:07AM +1000, Russell Coker wrote:
> On Wed, 13 Oct 2004 23:23, Wouter Verhelst <wouter@grep.be> wrote:
> > For instance, my /etc/default/libnss-db contains the following lines:
> >
> > ETC = /root/stage
> > DBS = passwd group shadow
>
> shadow is part of the passwd setup. group does no good on most systems (on my
> system /etc/group is only 70 lines and the database gives no benefit).
The point was that at home, I'm not using libnss-db for its performance
gain (which would be silly). In the case of group, it's because I want
to avoid having to concatenate multiple files (which is messy) and
because I want to maintain certain groups in the centralized database.
AFAIK, it's not possible to use 'compat' in /etc/nsswitch.conf with
multiple passwd (and friends) files, so that's not an option.
> > 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
>
> So what's the point of having LDAP if you are going to manually copy flat
> files around?
First, I'm not manually copying flat files around. Every host generates
its own version of the flat file, which allows me to apply filters based
on the time, the host name, etc; this way, I can give a guest a
time-limited account on just *one* of my machines. pam_mkhomedir helps
in that I don't have to create the home directory, either.
Second, having stuff in LDAP allows my users to update certain
attributes connected to their user object in the directory (such as,
e.g., loginShell). This would also be possible using NIS (which I simply
don't like) or, provided I'm up to maintaining a gross and error-prone
hack, a flat file on a file server which is maintained through a bunch
of access-checking SetUID programs, but I very much prefer doing it this
way.
> > > 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.
>
> If you want the database to be in sync with the flat file and be usable
> without gross hacks as it is in AIX then it's a serious bug.
The flat files are updated by a cron job, which looks like this:
#!/bin/bash
/root/stage/passwd-gen
cd /var/lib/misc
make
I understand how it is problematic if you have to remember to regenerate
the database files every time you modify something vaguely related to a
user; but that is not the case, so in my situation the fact that stuff
isn't automatigically updated is a feature, not a bug. Moreover, if
libnss-db would be modified to suddenly update the .db files if
/etc/passwd (and friends) change, that would completely break my setup.
> > > 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.
>
> Way faster than a non-local LDAP. But not significantly faster than flat
> files unless you have >10,000 users (which isn't the case for Debian).
Oh, that's what you mean. Misunderstood you then, sorry.
--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune
Attachment:
signature.asc
Description: Digital signature