Who's in charge here: Oracle or Unix?

[Mike My Watch Has Windows Meyer]

In article <3178 at canisius.UUCP> pavlov at 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).

	<mike

--
When logic and proportion have fallen softly dead,	Mike Meyer
And the white knight is talking backwards,		mwm at pa.dec.com
And the red queen's off her head,			decwrl!mwm
Remember what the dormouse said.