From owner-freebsd-isp Wed Sep 23 22:52:56 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA04184 for freebsd-isp-outgoing; Wed, 23 Sep 1998 22:52:56 -0700 (PDT) (envelope-from owner-freebsd-isp@FreeBSD.ORG) Received: from joshua.enteract.com (joshua.enteract.com [207.229.129.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id WAA04178 for ; Wed, 23 Sep 1998 22:52:54 -0700 (PDT) (envelope-from djhoward@joshua.enteract.com) Received: (qmail 11926 invoked by uid 1032); 24 Sep 1998 05:52:50 -0000 Message-ID: <19980924005250.F9091@enteract.com> Date: Thu, 24 Sep 1998 00:52:50 -0500 From: Dan Howard - EnterAct Admin Team To: freebsd-isp@FreeBSD.ORG Subject: adding users to populous systems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i X-Loop: djhoward@uiuc.edu X-URL: http://www.dannyland.org/~dannyman/ Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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