home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / vmsnet / misc / 726 < prev    next >
Encoding:
Internet Message Format  |  1992-08-18  |  3.0 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!mccall!tp
  2. Newsgroups: vmsnet.misc
  3. Subject: Re: How to boot VMS from a failed AUDIT writing
  4. Message-ID: <1992Aug18.094524@mccall.com>
  5. From: tp@mccall.com (Terry Poot)
  6. Date: Tue, 18 Aug 1992 09:45:24 CST
  7. Reply-To: tp@mccall.com (Terry Poot)
  8. References: <1992Aug10.142728.4397@mic.ucla.edu> <1992Aug11.123003.247@winkle.bhpese.oz.au>
  9. Organization: The McCall Pattern Co., Manhattan, KS, USA
  10. Nntp-Posting-Host: mis1
  11. Nntp-Posting-User: tp
  12. Lines: 46
  13.  
  14.  
  15. In article <1992Aug11.123003.247@winkle.bhpese.oz.au>,
  16. robbie@winkle.bhpese.oz.au writes:
  17. >In article <1992Aug10.142728.4397@mic.ucla.edu>, shinn@agsm.ucla.edu
  18. >(Shinn-Tzong Wu) writes:
  19. >> Hi, we just encounteded one of our worst nightmare, the VAXStation 3100
  20. >> (running VMS 5.3) died probably because it ran out of disk space for  
  21. >> the AUDIT process.  Since the AUDIT process tried to write into the
  22. >> full disk in the process of rebooting, there seemed to be no way that we
  23. >> can bring the system up.  We tried to boot it from a stand alone tape but
  24. >> it won't access to any of the disks.  Can anyone suggest any help? 
  25. >Thanks...
  26.  
  27. Don't ya' love it? What could be more secure than a system that won't run, even
  28. after a reboot? Let's see someone hack it now! It has an even better mode that
  29. will cause the system to crash when this happens, including right after reboot.
  30. I suppose that's designed as a boot block exerciser...
  31.  
  32. >...
  33. >Once you have fixed it up, I beleive there is a way of setting up the audit
  34. >server so that the machine simply suspends anything which is waiting on the
  35. >audit server. You can then log in and cleanup the system disk and then do
  36. >a SET AUDIT/SERVER=RESUME and everything will carry on as if nothing had
  37. >happened.
  38.  
  39. A much more effective command which will prevent the problem from reoccuring is
  40. set audit/server=stop, preferably in the system startup procedure. If you do
  41. anything else, I recommend you read the VMS security manual from cover to cover
  42. and find out what else the system will do to you if you aren't very careful.
  43.  
  44. The department I support lost 5 man-days of production work when this happened
  45. to us. I strongly object to a system being delivered with the default
  46. configuration one that will prevent the system from running when an otherwise
  47. easily correctable system management problem occurs. I had to solve this by
  48. dictating commands over the phone to a user who knew nothing about DCL, VMS
  49. system management, etc.
  50.  
  51. People who want this level of security will read the security manual and learn
  52. how to turn it on. They have a lot of other things to set up, and this one isn't
  53. a big deal. People who don't shouldn't be forced to read the security manual to
  54. turn it off, especially since they won't even know the problem is there until it
  55. happens.
  56. --
  57. Terry Poot <tp@mccall.com>                   The McCall Pattern Company
  58. (uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
  59. (800)255-2762, in KS (913)776-4041           Manhattan, KS 66502, USA
  60.