From owner-freebsd-hackers Fri Oct 31 18:29:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA22592 for hackers-outgoing; Fri, 31 Oct 1997 18:29:59 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id SAA22547 for ; Fri, 31 Oct 1997 18:29:48 -0800 (PST) (envelope-from shimon@sendero-ppp.i-connect.net) Received: (qmail 26051 invoked by uid 1000); 1 Nov 1997 02:30:12 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-100797 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 31 Oct 1997 18:30:12 -0800 (PST) Organization: Atlas Telecom From: Simon Shapiro To: Tom Subject: Re: Password file builds Cc: "Bryn Wm. Moslow" , freebsd-hackers@FreeBSD.ORG, Dave Chapeskie Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Tom; On 31-Oct-97 you wrote: > > On Fri, 31 Oct 1997, Dave Chapeskie wrote: > > ... > > I think that if done properly the above changes should be incorporated > > into FreeBSD and the text password files made optional. Ie, on a small > > system like my home system leave things as they are but allow for ISPs > > and the like to do away with the text versions. > > The biggest problem with this is, that there are no tools to fix or > verify db files. If the /etc/pwd.db or /etc/spwd.db becomes damaged, > you're screwed. Same thing if the filesystem gets corrupted. Both are a complex, not easily human-readable structures that contain complex data. A file system, in this view is a simple, single-indexed heirarchial database (almost network, but not quite). In well written software, the risk is similar, except that a db file is sompler to backup. > Also, there are locking issue with in place updates of db files. Do > the > pw routines in libc even do locking? I don't think so. What happens if > someone calls getpwnam() at the while someone else is writing a new > entry > into the database? Bang, you're dead. Now, these are legitimate concerns. BTW, is the passwd db using B trees or hash, or what? I am not sure that one would not want to switch indexing method based on anticipated size. Another approach to maintenance of these large files, is to use the database and in-line with it, dump all deltas to a log file. Since the log is always sequential, always appending, its impact on perfrormance should be minimal. A simple utility can roll the log forward and restore a corrupt database very rapidly (been there, done that :-) --- If Microsoft Built Cars: Every time they repainted the lines on the road, you'd have to buy a new car. Sincerely Yours, Simon Shapiro Atlas Telecom Senior Architect 14355 SW Allen Blvd., Suite 130 Beaverton OR 97005 Shimon@i-Connect.Net Voice: 503.799.2313