Article View: vmsnet.misc
Article #115Re: How to boot VMS from a failed AUDIT writing
From: Terry Poot
Date: Tue, 18 Aug 1992 15:45
Date: Tue, 18 Aug 1992 15:45
46 lines
3134 bytes
3134 bytes
In article <1992Aug11.123003.247@winkle.bhpese.oz.au>, robbie@winkle.bhpese.oz.au writes: >In article <1992Aug10.142728.4397@mic.ucla.edu>, shinn@agsm.ucla.edu >(Shinn-Tzong Wu) writes: >> Hi, we just encounteded one of our worst nightmare, the VAXStation 3100 >> (running VMS 5.3) died probably because it ran out of disk space for >> the AUDIT process. Since the AUDIT process tried to write into the >> full disk in the process of rebooting, there seemed to be no way that we >> can bring the system up. We tried to boot it from a stand alone tape but >> it won't access to any of the disks. Can anyone suggest any help? >Thanks... Don't ya' love it? What could be more secure than a system that won't run, even after a reboot? Let's see someone hack it now! It has an even better mode that will cause the system to crash when this happens, including right after reboot. I suppose that's designed as a boot block exerciser... >... >Once you have fixed it up, I beleive there is a way of setting up the audit >server so that the machine simply suspends anything which is waiting on the >audit server. You can then log in and cleanup the system disk and then do >a SET AUDIT/SERVER=RESUME and everything will carry on as if nothing had >happened. A much more effective command which will prevent the problem from reoccuring is set audit/server=stop, preferably in the system startup procedure. If you do anything else, I recommend you read the VMS security manual from cover to cover and find out what else the system will do to you if you aren't very careful. The department I support lost 5 man-days of production work when this happened to us. I strongly object to a system being delivered with the default configuration one that will prevent the system from running when an otherwise easily correctable system management problem occurs. I had to solve this by dictating commands over the phone to a user who knew nothing about DCL, VMS system management, etc. People who want this level of security will read the security manual and learn how to turn it on. They have a lot of other things to set up, and this one isn't a big deal. People who don't shouldn't be forced to read the security manual to turn it off, especially since they won't even know the problem is there until it happens. -- Terry Poot <tp@mccall.com> The McCall Pattern Company (uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA
Technical Details
Message-ID:
<1992Aug18.094524@mccall.com>Path:
arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!mccall!tpReferences:
<1992Aug10.142728.4397@mic.ucla.edu> <1992Aug11.123003.247@winkle.bhpese.oz.au>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!deimos.cis.ksu.edu!mccall!mccall!tp Newsgroups: vmsnet.misc Subject: Re: How to boot VMS from a failed AUDIT writing Message-ID: <1992Aug18.094524@mccall.com> From: tp@mccall.com (Terry Poot) Date: Tue, 18 Aug 1992 09:45:24 CST Reply-To: tp@mccall.com (Terry Poot) References: <1992Aug10.142728.4397@mic.ucla.edu> <1992Aug11.123003.247@winkle.bhpese.oz.au> Organization: The McCall Pattern Co., Manhattan, KS, USA Nntp-Posting-Host: mis1 Nntp-Posting-User: tp Lines: 46