From owner-freebsd-hackers Sat Jan 10 10:44:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA29006 for hackers-outgoing; Sat, 10 Jan 1998 10:44:40 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28999 for ; Sat, 10 Jan 1998 10:44:26 -0800 (PST) (envelope-from karl@Mars.mcs.net) Received: from Mars.mcs.net (karl@Mars.mcs.net [192.160.127.85]) by Kitten.mcs.com (8.8.7/8.8.2) with ESMTP id MAA12266; Sat, 10 Jan 1998 12:44:13 -0600 (CST) Received: (from karl@localhost) by Mars.mcs.net (8.8.7/8.8.2) id MAA10330; Sat, 10 Jan 1998 12:44:12 -0600 (CST) Message-ID: <19980110124412.19068@mcs.net> Date: Sat, 10 Jan 1998 12:44:12 -0600 From: Karl Denninger To: Wolfram Schneider Cc: Jaye Mathisen , hackers@FreeBSD.ORG Subject: Re: How are people handling lots of accounts? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84 In-Reply-To: ; from Wolfram Schneider on Sat, Jan 10, 1998 at 05:54:52PM +0100 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Sat, Jan 10, 1998 at 05:54:52PM +0100, Wolfram Schneider wrote: > Jaye Mathisen writes: > > With 50000 test accounts in master.passwd, it takes something like 10 > > minutes to rebuild the .db files, completely preventing anybody else from > > doing anything password related. > > > > Is there anything that can be done to speed this up? Changing the > > password isn't too bad, only about 30 seconds, but adding takes forever. > > You can increase the database cache size from 4MB to a higher value in > pwd_mkdb. See pwd_mkdb.c line 70. You must recompile pwd_mkdb for this > change. > > Did you use the -u option? > pwd_mkdb(8) > -u username > Only update the record for the specified user. Utilities that op- > erate on a single user can use this option to avoid the overhead of > rebuilding the entire database. > > -- > Wolfram Schneider http://www.freebsd.org/~wosch/ We handled this problem (and I consider it a serious one) by replacing the entire authorization system with a DBMS-based package written in-house that uses encrypted data streams between the client and server. This was a serious pain in the ass (and done incorrectly or with insufficient redundancy screws you completely, as you then can't log in!) but its worth it - our management is now centralized. We still create "fallback" pwd.db and spwd.db files from that database and distribute them for the "emergency" case, but this is then a low-priority thing that can be done at the "background noise" level. For multi-machine environments you *have to* centralize things somehow, and NIS just isn't secure enough for an ISP environment. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost