[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Password file with over 3000 users.





--On September 21, 2007 12:02:23 AM +0200 Ian <iforbes@zsd.co.za> wrote:

Craig Sanders wrote:

if you have the libnss-db package (part of nsswitch) installed, you have
everything you need already.

Thanks. This is exactly what I need. I actually found this and got it
running shortly after I posted my original message. Everything is in
Debian - except the documentation!

My setup is pretty much exactly as you recommend.

PS: this works.  i did this several years ago on one server when the
number of accounts grew to about 5000.  there is one small catch - with
the cron job running every 5 minutes, there is a small window of time
when the source files in /etc have been updated but the .db versions
haven't been regenerated yet.

Just one small addition.

I added this line to end of our /usr/local/sbin/adduser.local

[ -e /var/lib/misc/Makefile ] && cd /var/lib/misc/ && make



And I have a cron job which runs the same command once per hour to
effect deletions and account locking etc.

I will have to look into controlling the cron spam.

2>&1 > /dev/null to end of command line.


We actually use this password file across a couple of servers with a
cron job that copies it across with rsync every 5 minutes. At some stage
I must look at a SQL or LDAP based solution. I originally chose the
rsync because each server can run on its own if one goes down and there
are no performance issues. But libpam-ccreds and nss-updatedb appear to
offer the same functionality when coupled with ldap.

We already have a postgresql backend for our radius server, would it be
better to run SQL -> LDAP -> nss or go directly from SQL -> nss?

Up to you to me it seems simplest to run LDAP via it's builtin bdb/ldbm/gdbm facilities. You can run replica slaves on the other machines. It's what we do here. We're working on improving security by doing authentication in a different method so we're not syncing auth information elsewhere but have account data available everywhere. (we've something like 10 webservers that each have LDAP slaves, another like 5 or 6 mail servers, etc).

You also have to be careful not to get service dependencies (like you need to make sure your mysql and ldap server daemons users aren't in LDAP) when you start making services depend on eachother.



Reply to: