jbn@glacier.STANFORD.EDU (John B. Nagle) (06/30/87)
It strikes me that problems that were solved with immense effort in
other operating systems are generally ignored in UNIX, with amazingly
little effect. Consider the recent discussion on backing up "live" file
systems. Let me summarize the UNIX atttude.
File system integrity: "Sometimes the dump tapes will be bad, and
sometimes restore will crash, but a guru can fix up the damaged
file system."
Spoolers: "Well, sometimes the spoolers hang up, but just become
the super-user, kill all the spool processes, and start the spoolers
again".
Locking: "Aren't lock files good enough? Even under NFS they almost
always work."
Security: "Well, it isn't the system's fault if the users aren't
very careful about the protection modes on all their files."
System administration: "Of course it's complicated. What did you
expect?"
Recognize that solutions are known for all these problems and there
have been operating systems in which they were adequately addressed.
UNIX addresses all of these problems inadequately. Somehow this bothers me.
John Nagleron@topaz.rutgers.edu (Ron Natalie) (07/01/87)
Give me a break. Just because some users are complacent about
programming, doesn't mean to characterize all UNIX programmers
that way. I work right next to VMS programmers and MVS programmers
and you'll find good ones and bad ones in the same group.
File system integrity: "Sometimes the dump tapes will be bad, and
sometimes restore will crash, but a guru can fix up the damaged
file system."
Nearly every system from MS-DOS to UNIX to DEC-20 has some program
for assuring file systems. Careful use of DUMP and RESTORE without
trying to use them in ways they weren't intended (like level 0's on
active machines) will not cause you any problem. I don't think at
BRL I was ever not able to get files back from systems that were actually
dumped. When we lost 26 CDC 300MB disk drives due to manufacturing problems
dump/restore was real important to us, and we never had any problems.
I can't tell you the number of unusable TOPS-20 archives we've had.
Spoolers: "Well, sometimes the spoolers hang up, but just become
the super-user, kill all the spool processes, and start the spoolers
again".
Using MDQS, it is rare that the spoolers themselves ever get hung up.
Usually, the peripherals themselves crap out.
System administration: "Of course it's complicated. What did you
expect?"
You ever been an administrator? Surely UNIX is more complicated than
running MS-DOS, but not any worse than TOPS-20, VMS, MVS, VM, or any
other REAL operating system.
UNIX addresses all of these problems inadequately.
UNIX has solutions for these problems for people who aren't too lazy
to do things right. None of your comments are UNIX specific problems,
but the fault of hack system administrators and programmers, which UNIX
does not have a monopoly on.
-Ronjoe@auspyr.UUCP (Joe Angelo) (07/01/87)
in article <17108@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU says: > > ... Let me summarize the UNIX atttude. Let me comment on your ''summary'' ... > > File system integrity: "Sometimes the dump tapes will be bad ... > Not to insult you, but I've NEVER had a problem with dump/restore, tar/cpio, or even with "dd if=/dev/maindisk of=/dev/auxdisk" in 6 years UNIX Admin'ng. And, of course, 98% of those backups were done on live file systems. > Spoolers: "Well, sometimes the spoolers hang up, ... > What spoolers hang? You mean the line printer spooler? Could it be because the printer went haywire or someone unplugged it? Could the spooler had been ''waiting'' on an event such as ^Q or DTR? On BSD, lpc can solve that problem. On SYSV, lpadmin/lpstart/lpshut can do the same. I'll give in a bit ... once in about 45 days I need to restart SYSV printer spoolers because of a minor IOCTL problem with the serial printers; never once had to restart the daemons on // printers. What does TOPS do with serial printers? > Locking: "Aren't lock files good enough? > What's wrong with lock files? Well, they lack some things and I wouldn't use them for serious applications. Ever hear of flock(), semctl(), msgget(), popen(), socket() and tons of vendor-supplied locking schemes? Sure, the older version of UNIX lack advanced file/record locking... but that was then is this is now. > > Security: "Well, it isn't the system's fault if the users aren't > very careful about the protection modes on all their files." > You should add: "if the user isn't careful assigning his/her password!" Do me a favor, name just one OS that is ''secure''. But what about file protections? A good admin might add "umask=022" or whatever in standard login startup scripts for a bit more default security. You sure can do that under UNIX; and VMS as well. Actually, with the exception of a few known but not public domain bugs, I find UNIX security very well suited. Nothing in your article sounded UNIX specific to me; locking, spoolers, security, & backups are a FEW of the things that make an OS. UNIX has these things; and with a good understanding of them (as with anything: a car, your body, etc.) they can be used rather effectively without problem. If you think you have better solutions to the above (there is ALWAYS a better solution), perhaps you can suggest some and let the UNIX world digest them. Hey! Maybe you can even jbn spoolers -- ones that keep printing even if the printer is off; least they don't hang, eh? No more kill -9's, eh? It sounds to me as if, one day, out of the blue of the sky, you "chmod 777 $HOME" while two NFS printer spoolers were accessing the same printer (they didn't see the NFS lock file and both became hung) then someone ''walked'' over to your directory and typed in "rm -rf ." while the admin was making a level 0 dump on last weeks backup tapes. After confronting the admin for a directory restoral, he said, "Of course it's complicated... -- "Need input. Joe Angelo, Sr. Sys. Engineer @ Austec, Inc., San Jose, CA. More input. ARPA: auspyr!joe@lll-tis[-b].arpa PHONE: [408] 279-5533 Ahhh, input!" UUCP: {sdencore,cbosgd,ptsfa,dana}!aussjo!joe UUCP: {amdahl,lll-tis,imagen,necntc,dlb,sci,altnet}!auspyr!joe
jmc@ptsfa.UUCP (Jerry Carlin) (07/01/87)
In article <17108@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > It strikes me that problems that were solved with immense effort in >other operating systems are generally ignored in UNIX, with amazingly >little effect. Consider the recent discussion on backing up "live" file >systems... > >Recognize that solutions are known for all these problems and there >have been operating systems in which they were adequately addressed. >UNIX addresses all of these problems inadequately. Here we go again. UNIX addresses these problems well. All OS's depend on people to implement the solutions. The real point of much of the discussion is actually how ROBUST UNIX is and how many things the OS will let you do without catastropic results. Also, the administration practices on a university/research computer is VERY different than those on a business computer where very valuable corporate data is kept. On those machines a lot more care is taken. To answer some of the specific points: >File system integrity: Again, the solution depends on people (and $$) DBMS's have transaction logging, UNIX (at least V.3) has an ordered write. You need to spend money for adequate backup hardware and hire operators to do dumps off-hours or buy a computer with mirrored disks (like the new Tandem UNIX box). >Spoolers: Any program including the spooler can and does die. The real question is how often and how much trouble to restart. >Locking: see lockf(3) etc. This is really a dead issue for a stand alone system and has been for quite a while. Locking across a network and deciding what to do when one computer (with ANY os) goes down is non-trivial. 'rfs' now addresses this and 'nfs' is supposed to. >Security: security always depends on people to implement. Gould has a C-2 secure port. See the UNIX System Security book, Wood and Kochan, Hayden. There are scripts that enforce security considerations in the book. >System administration: I've worked with many OS's. If you think UNIX is complicated try MVS; try writing OS JCL to do admin tasks. AT&T and other vendors have very nice system admin menu systems. Many of us like UNIX because it is malleable. Its a little like a camera that has an automatic mode and a manual mode that allows over exposure and double exposure. You don't have to use the manual mode but its there when you need it. -- voice: (415) 823-2441 uucp: {ihnp4,lll-crg,ames,qantel,pyramid}!ptsfa!jmc Where am I? In the village. Whose side are you on? That would be telling.
jfh@killer.UUCP (John Haugh) (07/03/87)
In article <17108@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > > It strikes me that problems that were solved with immense effort in > other operating systems are generally ignored in UNIX, with amazingly > little effect. Consider the recent discussion on backing up "live" file > systems. Let me summarize the UNIX atttude. > > File system integrity: "Sometimes the dump tapes will be bad, and > Spoolers: "Well, sometimes the spoolers hang up, but just become > Locking: "Aren't lock files good enough? Even under NFS they almost > Security: "Well, it isn't the system's fault if the users aren't > System administration: "Of course it's complicated. What did you > > Recognize that solutions are known for all these problems and there > have been operating systems in which they were adequately addressed. > UNIX addresses all of these problems inadequately. Somehow this bothers me. At my site, I like to be able to make live backups, fix the spoolers by hand, not have to fight file locking that doesn't realize I am root, and let users share files. As far as system administration being complicated, far from it. I've been administrating unix systems for years and never thought it was that hard. What bothers me is how other systems are so complex that mistakes are made as a result of their complexity. My favorite example is VMS. If I remember correctly, adding users was handled by a program named AUTHORIZE. The number of entries required to add a single user was large enough that it was impracticle to add more than two or three users at a time. So when it came time to add the CSCI students, they created a big .COM file, and ran that. Of course, VMS had clear-text passwords entered when users were added, so all it took was finding the right location for this file. (Which had the suggestive name ADD.COM) Unix is not a megalithic operating system like OS/360. Everything is not included. I remember reading something by Dennis, or Ken or one of those guys that said something to the effect that Unix was an I/O multiplexor more than a typical operating system. (Dennis, feel free to jump in now ...) There is a way to do what VMS or PRIMOS does within Unix. (Well, most of it anyway, some of the stupid things can only be done in VMS :-). - John.
cray@ssvs.gsfc.nasa.gov (Robert Cray) (07/05/87)
In article <1089@killer.UUCP>, jfh@killer.uucp (John Haugh) writes: > >What bothers me is how other systems are so complex that mistakes are >made as a result of their complexity. My favorite example is VMS. If >I remember correctly, adding users was handled by a program named >AUTHORIZE. The number of entries required to add a single user was >large enough that it was impracticle to add more than two or three >users at a time. So when it came time to add the CSCI students, they Let's not get carried away. Most VMS utilities do have a large number of parameters, however most of them are left off most of the time. In the case of AUTHORIZE, about all you need is a username, home directory, and maybe a group. Also, every VMS site I have seen has some front end to authorize which automatically sets up groups, directories, etc. >created a big .COM file, and ran that. Of course, VMS had clear-text >passwords entered when users were added, so all it took was finding >the right location for this file. (Which had the suggestive name ADD.COM) How do you propose to set initial passwords without having them in the clear at some point in time? As for finding the file, presumably it is protected from read access by normal users, that combined with the fact that by default initial passwords on VMS are preexpired (the user must change the password the first time he/she logs on) does not make this seem like a serious problem. As for all the weird privileges, if they are not specified, they take on the values held by the user "USER", so you could say something like: add fred/default=user:[fred] Doesn't seem too complicated to me. I think you can specify the default... As for unix, there does not seem to be any standard way to add accounts, some use vipw and do it by hand, some have programs like nu(1), I think DEC supplies something with ULTRIX, etc, etc. --robert -- cray@mpp.gsfc.nasa.gov
mouse@mcgill-vision.UUCP (der Mouse) (07/06/87)
In article <17108@glacier.STANFORD.EDU>, jbn@glacier.STANFORD.EDU (John B. Nagle) writes: > It strikes me that problems that were solved with immense effort in > other operating systems are generally ignored in UNIX, with amazingly > little effect. I wouldn't say they are ignored, just that they are addressed differently. The UNIX attitude to problems such as > File system integrity: > Spoolers: > Locking: > Security: > System administration: is one of making it easy for people to handle things. For example, let's compare printer spoolers on VMS and UNIX. Under VMS, the print symbiont works fine, most of the time, just as it does on UNIX. Under UNIX it fails somewhat more often. But under UNIX it is vastly easier to fix when it does fail. When the print symbiont gets hung on VMS what can you do? Guess we gotta reboot.... Let's look at filesystems. VMS has code analgous to UNIX fsck, which is run automatically when a possibly-corrupted filesystem is seen at mount time. Normally this will repair anything that's wrong, just as fsck will under UNIX. The difference is in what happens when the automatic repair fails. Under each system, someone who knows what they're doing can repair the filesystem. The point is that the UNIX filesystem is simpler and better documented, hence the necessary skill is commoner. The necessary support programs (eg, clri) come with UNIX instead of on a diagnostic kit available only to field circus engineers. Why not admit that UNIX and, say, VMS are targeted at different environments and therefore handle problems in different ways - and let it go at that? UNIX is not all things to all people, nor can it ever be. It is foolish to complain because it isn't. der Mouse (mouse@mcgill-vision.uucp)
ken@rochester.arpa (Ken Yap) (07/06/87)
|How do you propose to set initial passwords without having them in the clear |at some point in time? As for finding the file, presumably it is protected I once used a student registration system in which a student would meet their TA, who verified their student ID. The TA then started a registration program and handed the keyboard to the student. This program prompted the student for info and asked for a suitable password which was then immediately encrypted. The password existed in cleartext only in the student's head and while being entered. Later the collected info was merged into the password file. I don't know why online registration isn't used more. It would reduce password leaks and provide a guided first encounter with the machine. Ken
levy@ttrdc.UUCP (Daniel R. Levy) (07/07/87)
In article <1089@killer.UUCP>, jfh@killer.UUCP (John Haugh) writes: < What bothers me is how other systems are so complex that mistakes are < made as a result of their complexity. My favorite example is VMS. If < I remember correctly, adding users was handled by a program named < AUTHORIZE. The number of entries required to add a single user was < large enough that it was impracticle to add more than two or three < users at a time. So when it came time to add the CSCI students, they < created a big .COM file, and ran that. Of course, VMS had clear-text < passwords entered when users were added, so all it took was finding < the right location for this file. (Which had the suggestive name ADD.COM) See Summary: . -- |------------dan levy------------| path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, | an engihacker @ | vax135}!ttrdc!ttrda!levy | at&t data systems division | disclaimer: i am not a yvel nad |--------skokie, illinois--------|