Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 24 Sep 1998 00:52:50 -0500
From:      Dan Howard - EnterAct Admin Team <djhoward@enteract.com>
To:        freebsd-isp@FreeBSD.ORG
Subject:   adding users to populous systems
Message-ID:  <19980924005250.F9091@enteract.com>

next in thread | raw e-mail | index | archive | help
We have a busy shell machine available to our customers that runs a great many
services and has over 14000 user accounts.

Over the past month, I've been involved in overhauling bits and pieces of the
system involved in adding new users into the system.  For a long time, we'd
been running an old version of the standard adduser script, hacked in very
scary ways by various persons who've been in charge of the system for the
past two years.  It was prone to breakage, and was scary to maintain, so I
scrapped it and wrote our own version, which uses pw.

I've observed that stuff like adduser, pwd_mkdb, and even pw, are not
particularly suited to running in this environment.  Why?  1) Race conditions
involved with either of the first two regarding multiple copies being used at
a time. (We have several employees adding users every day.)  2) A preference
for rebuilding the entire password database once a user is added.

A few things we've done are:

- Wrap pwd_mkdb with lockf so it'll only run one at a time - it can be invoked
  several times, but those invocations will block and complete serially.

- Hack pw so that it doesn't rebuild the database.  After the new script runs
  pw, it calls pwd_mkdb -u.

Even so, I notice that pw likes to make certain assumptions, such as that the
password environment it's working in reflects accurately the state of the
passwd file it's editing - this means that until I put a lock around pw ->
pwd_mkdb -u, that some duplicate UIDs were appearing on accasion.

I think pw is a cool program though, and keep thinking that some spare time
should be devoted to getting it, and possibly pwd_mkdb to act in a different
manner - the former rebuilding the database more conservatively, and the
latter not running over itself, as other utilities like passwd, chfn, et al,
manage to do.

Before I start getting too intimate with some rather sober and serious code
there, I was wondering if anyone else has been involved with this sort of
stuff too, and hopefully has certain suggestions or insight they might share?

Thanks!

-danny

-- 
Dan Howard, EnterAct System Administration Team || EnterAct: Top-rated
     http://www.dannyland.org/~dannyman/        ||   ISP in Illinois

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980924005250.F9091>