Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!spool.mu.edu!uunet!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.unix.admin Subject: Re: Who's in charge here: Oracle or Unix? Message-ID: Date: 8 Feb 91 17:38:26 GMT References: <635@uswnvg.UUCP> <3178@canisius.UUCP> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 34 In-Reply-To: pavlov@canisius.UUCP's message of 8 Feb 91 05:24:57 GMT In article <3178@canisius.UUCP> pavlov@canisius.UUCP (Greg Pavlov) writes: So what we end up with is data redundancy (system- and dbms- related) and the usual problems this causes, such as inconsistencies. It is very temp- ting, then, to contemplate using the dbms as the recipient and repository of a "master" user database from which we could generate passwd, group, and other files on demand. I think this is backwards. It requires training everyone who wants to change the data in the password/etc files to use a new set of tools, and probably learn a new way of dealing with them. By doing it the other way - regenerating the database each time the system files are changed - you allow people to continue using their old tools. Any programs that read the file can be left unchanged. Programs that _write_ the file need to be tweaked. The worst case is a shell wrapper that runs the real writer program, then runs a program to rebuild the database from the password file, with appropriate locking on the database to keep things in synch. This allows you to continue using current admin tools with no change, and keeps the database in sync (barring accidents) with the password file. Doing it the other way means that the class of accidents that break the database would break all the programs that depend on /etc/password, unless you've changed them to use the database (not a bad idea if they're doing liner searches).