Who's in charge here: Oracle or Unix?

[Horst Laumer]

tensmekl at infonode.ingr.com (Kermit Tensmeyer) writes:

>In article <237 at raysnec.UUCP> shwake at raysnec.UUCP (Ray Shwake) writes:
>>gbarnet at uswnvg.UUCP (Gary Barnette) writes:
>>>Request for open discussion:
>>
>>>There has been a battle going on around here on administrating
>>>some of the system flat files associated with Unix. The file of concern
>>>are /etc/passwd, /etc/group, /etc/hosts, and some configuration files 
>>>used by a menuing system. 
>>
>>	Well, I cast my vote strongly with the SA staff - and not just
>>because I've spent much of my UN!X career as an administrator. For years
>>I've blasted programs that usurp system priviledge without cause.
>>
>>uunet!media!ka3ovk!raysnec!shwake				shwake at rsxtech


>Most of use already use scripts to generate new users. What's wrong with
>using some database to store the information and make some use of the
>confonded information. For instance if the user information is stored in
>some table it should be easy to delete the person when he leaves the system.

>Recreating the afflicted area is easy, when the data is stored elsewhere.

[ stuff about BSD/SysV deleted ]

>Oracle is most likly overkill for the problem. However as a oracle
>application, Sys Admin might be easier and less problem prone than it currently
>is now. 

>Kermit Tensmeyer                        | Intergraph Corporation

No. Simply no. The only thing I admit is your statement 'Oracle is .. overkill
for the problem', and so is with any *DBMS.

It's OK for an application to mirror things like /etc/passwd or /etc/<any-
config-file>, but only *mirror* it (i.e. reflect, what authorized institutions
put there).

Since all the well-known *DBMSes run on various platforms, the only way I
could imagine is to call trusted (sic) SA-routines to manage these things
(BTW, did you ever try getpwent() on an IBM 370 running OS/VS ? on VMS ?).

Such interface-routines might be managable in cases of changes in the OS,
or would you prefer to keep track of these changes in the application ?
Also, they could be developed by *authorized* persons.

I only remember an OS update (only a PC box), that added /etc/shadow to
the needed files, and an older app was used to add/delete users .....
I had to do the installation from scratch, re-install the app, get the
application-data from a tape that was 4 weeks old .....

I think, that's sufficient to simply say NO !

But, it would be really *great* to imagine that a fired DBA enters the SQL
Interpreter and says:

delete from <user-table> ; commit ;

Leave the jobs to those who are payed for it; it's far more better to let
them work TOGETHER.

Horst
-- 
============================================================================
Horst Laumer, Kantstrasse 107, D-1000 Berlin 12 ! Bang-Adress: Junk-Food 
INET: hotte at sunrise.in-berlin.de                ! for Autorouters -- me --
UUCP: ..unido!fub!geminix!sunrise.in-berlin.de!hotte