gbarnet@uswnvg.UUCP (Gary Barnette) (02/06/91)
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. On one side is the system administration staff
and on the other is the Oracle dba staff and other Oracle developers.
The Oracle people want their database to contain the "seat of truth"
when it comes to Unix system files. They want Oracle applications written
(some are in development as I write this) that will accept input of what
would normally be put directly into the flat files mentioned above. Then,
Oracle would execute a SUID program with PRO-C calls to extract the
information from from its tables and modify the system files. System
administration is fighting to have this approach stopped and wonder why
there is even a hassle about it.
Database people contend:
The master of all data (even system) is Oracle. This data is needed
for a variety of things and, because of company policy, if it is in the
database that should be the master copy. More check can be made on
the integrity of the data and that means a more dependable system.
Sys admin responds:
Fine, if you want system data, the files are readable. But, Oracle
does not control the system; Oracle run on top of Unix
If it takes root access, it's our responsibility so don't worry about it
We don't want any Oracle programs controlling system files for the
following reasons:
a. Support issues (system administration doesn't know Oracle).
b. We want to build and modify our own admin tools.
c. There is a question of security. Database people need root access
to write these applications. Also, anyone could put a command in
to provide a suid shell.
d. If something break, who get called? System administration.
Has anyone run into this argument before? Can someone explain to me
why there is even an issue here? I admit to being a system administrator
but tried to relate what is happening with as little bias as possible.
Thank you all,
Gary Barnette
uunet!uswnvg!gbarnetshwake@raysnec.UUCP (Ray Shwake) (02/07/91)
gbarnet@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, and even cast a few words about programmers who are too lazy to work out a proper permission strategy. (Some guidelines for programmers in this regard can be found in _Unix_System_Security_ by Wood and Kochan.) ----------- uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech
pavlov@canisius.UUCP (Greg Pavlov) (02/08/91)
In article <635@uswnvg.UUCP>, gbarnet@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. On one side is the system administration staff > and on the other is the Oracle dba staff and other Oracle developers. > The Oracle people want their database to contain the "seat of truth" > when it comes to Unix system files. They want Oracle applications written > (some are in development as I write this) that will accept input of what > would normally be put directly into the flat files mentioned above. Then, > Oracle would execute a SUID program with PRO-C calls to extract the > information from from its tables and modify the system files. System > administration is fighting to have this approach stopped and wonder why > there is even a hassle about it. > Since you stated your potential "bias", I will state mine: I am responsible for a facility whose predominant "services" are electronic mail & communica- tions and several moderate-sized database applications. I have been tempted to implement something similar to what your Oracle people propose, for several reasons: 1. better "data management" of system files. We have people logging in to multiple cpus, for reasons I won't go into we do not run YP or Kereboros, we add/delete/modify 10-20 users per week, and system ad- ministration is a major pain and often "inaccurate". This in itself is not enough to recruit the use of a large, unwieldy dbms, since tools can (and have been) developed, but for subsequent reasons; 2. the dbms itself, that we run in client-server configurations (e.g., multiple clients and multiple servers), also has user information data that has to be maintained. Much of it overlaps (from the point of view of what one has to enter) the system files; 3. most individuals are put directly into menus as soon as they log in. These menus are implemented in and are tied to the dbms and the appli- cations we have developed. Which menus a given user sees and what data the user has access to is determined by information in the databases, some of it via formal dbms permits the rest of it by our own tables. This data too overlaps the data in the system files. 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 would not permit the use of SUID'd scripts. But this is not a restric- tion in itself. It's been a long time since I had the "pleasure" of using Oracle, so I don't know whether the following is possible: in our case, if we proceed with this, the user database will be "owned" by root but with updating privileges granted to other appropriate users. So "root" will determine who those "appropriate" users are and will also control who will have access to which parts of the database. Routines to generate and install system files will have to be executed by the few who have "root" access. Or, put it this way: it may well be that others will be able to create the output, but a "root" will have to install it. I realize that we are not a "typical" site in that our environment is tilted very heavily towards dbms-based applications which, furthermore, are rather homogeneous. This factor has pushed us in a certain direction which may or may not have relevance to your environment. pavlov@stewart.fstrf.org
wwm@pmsmam.uucp (Bill Meahan) (02/08/91)
In article <237@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >gbarnet@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, and >even cast a few words about programmers who are too lazy to work out a >proper permission strategy. (Some guidelines for programmers in this >regard can be found in _Unix_System_Security_ by Wood and Kochan.) > >----------- >uunet!media!ka3ovk!raysnec!shwake shwake@rsxtech I agree wholeheartedly. Have the Oracle-heads considered how they are going to handle passwords? What happens if a user changes his/her password using 'passwd' (whether or not they are "supposed" to).? Will the new password be incorporated into ORACLE? Or will a change in ORACLE exported shortly after the user has made a change overwrite the change when overwriting the file? What if password aging is in effect and forces the user to change passwords using 'passwd'? Passwords control is >>far from the only<< issue but is sufficiently illustrative to show the dangers of the "ORACLE IS TRUTH" approach. Bet IBM doesn't keep VM passwords in DB2 (or do they?)! -- Bill Meahan |Product Design & Testing Section Production Test Engineer |Starter Motor Engineering wwm@pmsmam | +1 313 484 9320
craig@attcan.UUCP (Craig Campbell) (02/08/91)
In article <635@uswnvg.UUCP> gbarnet@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. On one side is the system administration staff >and on the other is the Oracle dba staff and other Oracle developers. >The Oracle people want their database to contain the "seat of truth" >when it comes to Unix system files. They want Oracle applications written >(some are in development as I write this) that will accept input of what >would normally be put directly into the flat files mentioned above. Then, >Oracle would execute a SUID program with PRO-C calls to extract the >information from from its tables and modify the system files. System >administration is fighting to have this approach stopped and wonder why >there is even a hassle about it. > >Database people contend: > The master of all data (even system) is Oracle. This data is needed > for a variety of things and, because of company policy, if it is in the > database that should be the master copy. More check can be made on > the integrity of the data and that means a more dependable system. Are you kidding? Oracle is not part of the O/S. It's an add-on. How well would Oracle work in single user mode with only the root file system mounted? What is there to enforce Oracle (or any DB system) as the data 'God'? Why would you want to add layers of complexity to a relatively simple task? Have the Database people ever heard of the K.I.S.S. methodology? (Keep It Simple Stupid) Hmm, "simple", "Database",.....oxymoron. Silly question. The database people are "Users". Period. The system administrators are the "System Administrators". Period. The system administrators are responsible for the systems. How well would the excuse, "Well, you see, the data base is corrupted and we can't recover..." go over? That's what I thought. It sounds to me like the Oracle people need more work to do, and are trying to generate some for silly reasons. You as system administrator may use or develop any tools you like. It is also YOUR A*S on the line. I would tell the users to do their own job and let me do mine. I would be very hesitant to surrender control of critical functions to a User written application (Unless I wrote it, of course. :-)). (You just can't TRUST a user...:-)) (If that hasn't set me up as the main course for a "Users feeding frenzy", then I don't know what would.... Do users read the net? :-)) craig
vancleef@nas.nasa.gov (Robert E. Van Cleef) (02/09/91)
Two points/questions: 1) How are you going deal with the other programs that are used to maintain those files? passwd, chfn, chsh, and any of the other programs that use the standard system calls, with the appropriate privileges, allow general users to modify their information in those files. These commands must be eliminated or modified to comply with your 'NEW STANDARD'. Is your programming staff ready to take on OS support and development responsibilities for all of the OS varients that Oracle runs on? Will it work with the BSD password hashing routines, the Unicos passwd file shadowing routines, the UTS /etc/identity file, etc.? 2 ) Using a database to maintain those files is a "good thing". Adding the requirement that a commercial package that I must install on my system will manage those files is a "bad thing". I would probably veto the procurement of a commercial database package for general use if I discovered that it came with hooks to modify system files... --- My suggestions would be a tool that monitors those files, and reports pertinent discrepancies to the administrators, or a set of general tools for mantaining those files, that could be tested, modified, and accepted by the local system administrators on a case-by-case basis. --- To clarify my biases <grin> We have a locally developed account management system that maintains the passwd and group files on over 200 systems. It runs unders a commercial database package on one system and can update the system files on all of the client systems. We also have a separate software package that audits the files on all of the systems, monitoring for changes. However, the information in the passwd and GECOS fields tend to drift over time as the users manually update them on individual systems. We do not try to control t hat drift... Host tables are control by a different mechanism, based on nameservice. -- Bob Van Cleef vancleef@nas.nasa.gov NASA Ames Research Center (415) 604-4366 --- Perception is reality...
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/09/91)
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).
<mike
--
When logic and proportion have fallen softly dead, Mike Meyer
And the white knight is talking backwards, mwm@pa.dec.com
And the red queen's off her head, decwrl!mwm
Remember what the dormouse said.rad@genco.bungi.com (Bob Daniel) (02/09/91)
In article <635@uswnvg.UUCP> gbarnet@uswnvg.UUCP (Gary Barnette) writes: > >Request for open discussion: > > We don't want any Oracle programs controlling system files for the > following reasons: > a. Support issues (system administration doesn't know Oracle). > b. We want to build and modify our own admin tools. > c. There is a question of security. Database people need root access > to write these applications. Also, anyone could put a command in > to provide a suid shell. > d. If something break, who get called? System administration. Hmm.. I have never seen the need for an application to ALTER unix blessed files. Particulary /etc/passwd... why do they need to alter /etc/passwd? We might read from UNIX files in an Oralce app but we've never needed to change anything. I'd say an Oracle app should NOT alter UNIX system files! And for whatever reason they need to alter (which I don't know why), they should come up with another alternative. Such as a sysadm tool that is developed and supplied by the system administrator and has contains a log of what was modified. The Oracle app could only then use this tool and then the Sys administrators will know if any alterations have occurred.
brad@huey.Jpl.Nasa.GOV (Brad Hines) (02/09/91)
Let me start by saying that I basically feel like everyone else does that applications should not mess with system files, that the application should be subservient to the OS and not vice versa. I think there is another side to the coin, too. I don't know that much about Oracle, but I know that Oracle is trying to provide a product to people that works across systems made up of diverse hardware and software. If it isn't the case already, it will someday be the case that your Sun, PC, IBM, etc can all be on the same network running Oracle, accessing the same database. Think about trying to provide a consistent interface between Unix and something like Pick, which is so different I've never wanted to try to understand it. It's no wonder the Oracle people chose to take over administration rather than requesting it of the OS/administrator. It makes sense for a big installation where database use is the big thing. In the sense that Oracle runs on all these different platforms and is the one constant in a diverse computing environment, maybe it is Oracle that is the OS and the lone Unix machine on the end of an IBM mainframe network is the add-on. That said, I wish they could find a different way to do it, too. -- Brad Hines Internet: brad@huey.jpl.nasa.gov Jet Propulsion Lab, Pasadena, California
sanders@peyote.cactus.org (Tony Sanders) (02/11/91)
In article <635@uswnvg.UUCP> gbarnet@uswnvg.UUCP (Gary Barnette) writes: >Request for open discussion: >[question about having system files as an oracle database] I didn't quite understand your exact situation but here are some of my thoughts on various ways of doing what you proposed. For the record I'm a system administrator. Method 1: Hard It would be nice if you could implement this with watchdogs or something similar. You of course want to be able to "vi /etc/passwd" and have the result written back into the database, with locking such that only one person could open /etc/passwd or the database "rw", then "grep foo /etc/passwd" works and everyone is happy (maybe). This way you get some of the benefits of using a database and a text file all rolled into one. Of course, it would be nice if the watchdog could keep a local copy of what it thinks should be in this file in case the network server is down. Method 2: Easy Write programs that extract the data from the database and distribute it at some interval (nightly) to all the systems under it's control. You can either set this up such that each client requests the data on demand or the server force updates on the client. Or a mixture of both. This method requires a lot less code and from my experience updating nightly is sufficient. It makes certain aspects of system administration easier to have a central database and an EASY way to add/delete user/hosts/etc. One big problem is that a central database scheme just won't scale up forever. How big will your network of systems be in 5 years? 10? 20? How big were systems 5 years ago? 10? 20? In my experience we were the ones that maintained the database and that certainly changes some of the questions (if sysadm people are responsible for security you don't want people who don't know anything about security maintaining the database that controls all access to machines on your network). BTW: It's not an unreasonable request for (some of) the system administration people to learn oracle. -- sanders@peyote.cactus.org First rule of software: Throw the first one away. and so on... I am not an IBM representative and I speak only for myself.
adeboer@gjetor.geac.COM (Anthony DeBoer) (02/12/91)
In article <11367@jpl-devvax.JPL.NASA.GOV> brad@huey.Jpl.Nasa.GOV writes: >I think there is another side to the coin, too. I don't know that >much about Oracle, but I know that Oracle is trying to provide a >product to people that works across systems made up of diverse >hardware and software. If it isn't the case already, it will someday >be the case that your Sun, PC, IBM, etc can all be on the same network >running Oracle, accessing the same database. Think about trying to >provide a consistent interface between Unix and something like Pick, >which is so different I've never wanted to try to understand it. It's >no wonder the Oracle people chose to take over administration rather >than requesting it of the OS/administrator. It makes sense for a big >installation where database use is the big thing. > >In the sense that Oracle runs on all these different platforms and is >the one constant in a diverse computing environment, maybe it is >Oracle that is the OS and the lone Unix machine on the end of an IBM >mainframe network is the add-on. I think it is reasonable for a large application that will be the only thing running on a lot of people's boxes to provide a set of (for example, in the case of Oracle) Oracle "look-and-feel" tools for maintaining the system files that a lot of users can't be bothered with learning about. That kind of hand-holding does have a market. Not every site has someone like us available, and a lot of people would like to not have to ever think about Unix, just take their box out of the box and go in and use Oracle. This creates the demand for turnkey systems with all the sysadmin functions automated. The other, equally important, side of the coin, is that such tools should be optional, in the case of an installation that does have the luxury of Unix gurus on staff. If you have a big system and run a lot of applications, you're not going to let one of them take over the whole system. The application should have documentation of exactly what it needs set up for it, but it should not have any requirement of ever being root itself, except for perhaps an install script that the sysadmin can review and ensure it won't break his/her system (see C-news' doit.root script, for example). So while such tools are a good idea for single-application boxes, they should not force you to use them. -- Anthony DeBoer NAUI#Z8800 | adeboer@gjetor.geac.com | Programmer (n): One who Geac J&E Systems Ltd. | uunet!geac!gjetor!adeboer | makes the lies the Toronto, Ontario, Canada | #include <disclaimer.h> | salesman told come true.
hotte@sunrise.in-berlin.de (Horst Laumer) (02/12/91)
tensmekl@infonode.ingr.com (Kermit Tensmeyer) writes: >In article <237@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >>gbarnet@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@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@sunrise.in-berlin.de ! for Autorouters -- me -- UUCP: ..unido!fub!geminix!sunrise.in-berlin.de!hotte
rmwise@jjmhome.UUCP (Robert M. Wise) (02/13/91)
In article <237@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >gbarnet@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 Well, I do too! People who want to hear about the disaster that the DB approach can be should read comp.unix.aix. IBM decided to create this monster from heck called SMIT that uses the database approach. It's rather appalling. I won't summarize here. Go read the group and weep (or laugh). -Bob Wise rmwise@jjmhome.uucp
mike (02/14/91)
In an article, jjmhome.UUCP!rmwise (Robert M. Wise) writes: >Well, I do too! People who want to hear about the disaster that the >DB approach can be should read comp.unix.aix. IBM decided to create >this monster from heck called SMIT that uses the database approach. >It's rather appalling. I won't summarize here. Go read the group and >weep (or laugh). 'Tis a rarity for me to leap to IBM's defense, but in this case, you're not quite correct. What you are refering to is _not_ SMIT, but rather ODM. SMIT (System Management Interface Tool) is quite the slick little program that does _absolutely nothing to the system_ itself. It simply invokes tools like mkdev, rmuser, etc. It is quite the boon to those who don't want to read through 3 thick command references, or spend half the day having fun with InfoExplorer. :-) And insofar as /etc/passwd, /etc/group, etc. they are not part of the ODM; they are traditional flat files. -- Michael Stefanik | Opinions stated are not even my own. Systems Engineer, Briareus Corporation | UUCP: ...!uunet!bria!mike ------------------------------------------------------------------------------- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
scharf@public.BTR.COM (Jerry Scharf scharf@btr.com) (02/16/91)
There seem to be two issues here that can be separated. One is should there be a relational database for users and the other is who updates /etc/passwd. The reason I separate them is it let's me present an alternative that I fovor. Tracking users on a group of Unix machines is a pain. "When did a user's account get disabled" is a favorite question. So is which machines does user x have an account on, and which of those have some root access. This is stuff that is well kept by a database, and if someone else will set it up for you, that's one major pain out of the way. Make sure you are involved in specifying the contents of the database so you get all the information you want and all the reports your boss will want. One security scare will pay for all the effort in setting it up. As for the "automagic update" of the passwd files, I would tend to err on the side of caution. Remember who's butt goes in the meat grinder if it breaks. If they create a new file that is what they think the passwd file should be, then let you examine it and move it into the system as you wish, this allows you to maintain local hacks and check for mistakes. I think their solution wuold work about %98 of the time, which is not acceptable to me. My personal experiences with Oracle are as bad as the others I've seen. Do they still fail to catch the shutdown signal, and leave the database corrupted when the system is shut down without first stopping Oracle. Jerry -- Jerry Scharf scharf@btr.com, ...!decwrl!btr!scharf
prc@erbe.se (Robert Claeson) (02/18/91)
In article <1777@public.BTR.COM> scharf@public.BTR.COM (Jerry Scharf scharf@btr.com) writes: >My personal experiences with Oracle are as bad as the >others I've seen. Do they still fail to catch the shutdown signal, and >leave the database corrupted when the system is shut down without first >stopping Oracle. I think so. One site I know (okay, it's one of Oracle's own offices) has all their terminals and other async devices connected to Annex II terminal servers from Xylogics. They have the logout timer enabled, so when a user is logged in and types nothing for three hours, the terminal server resets the serial port and terminates all network connections leading to/from it. The problem is, the user's Oracle processes doesn't terminate. All their other, non-Oracle applications (like wordprocessors) gets terminated. Sadly, they think that the terminal server, not Oracle, is at fault. -- Robert Claeson Disclaimer: I represent myself and not my employer.
jmm@eci386.uucp (John Macdonald) (02/19/91)
In article <1991Feb11.181656.1496@gjetor.geac.COM> adeboer@gjetor.geac.COM (Anthony DeBoer) writes: |I think it is reasonable for a large application that will be the only thing |running on a lot of people's boxes to provide a set of (for example, in the |case of Oracle) Oracle "look-and-feel" tools for maintaining the system files |that a lot of users can't be bothered with learning about. That kind of |hand-holding does have a market. Not every site has someone like us |available, and a lot of people would like to not have to ever think about |Unix, just take their box out of the box and go in and use Oracle. This |creates the demand for turnkey systems with all the sysadmin functions |automated. | |The other, equally important, side of the coin, is that such tools should be |optional, in the case of an installation that does have the luxury of Unix |gurus on staff. If you have a big system and run a lot of applications, |you're not going to let one of them take over the whole system. The |application should have documentation of exactly what it needs set up for it, |but it should not have any requirement of ever being root itself, except for |perhaps an install script that the sysadmin can review and ensure it won't |break his/her system (see C-news' doit.root script, for example). | |So while such tools are a good idea for single-application boxes, they should |not force you to use them. Well put. Even if you don't have gurus on staff, there is the possibility that you might want to run *two* applications on the same system. If they both had the same high-handed approach to subverting system administration they could get into some interesting situations. And as another point... it is totally asinine to build an unnecessary system dependency into an application - system dependencies mean that platform specific releases are required, with concomitant porting delays for every upgrade and release, and the danger of getting support dropped if your platform becomes obsolete. There are enough *system* suppliers working hard at making system administration inconsistent from platform to platform (Is it *value added* to have to remember yet another way to do simple admin tasks, and to not be able to just use previously working scripts?) without the application providers getting into the act too. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
rad@genco.bungi.com (Bob Daniel) (02/22/91)
>In article <1777@public.BTR.COM> scharf@public.BTR.COM (Jerry Scharf scharf@btr.com) writes: > >>My personal experiences with Oracle are as bad as the >>others I've seen. Do they still fail to catch the shutdown signal, and >>leave the database corrupted when the system is shut down without first >>stopping Oracle. There is a simple solution to this. You can easily setup a shutdown oracle script and place it in /etc/rc0.d and to auto startup oracle, place a startup script in /etc/rc2.d. This works very well for me. When unix performs a shutdown, the oracle database(s) will be properly shutdown. When unix comes up, the database(s) come up. The concept is exactly the same as starting up/shutting down the lp scheduler and cron. If anyone wants the scripts to do this, I'll email them.