🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: vmsnet.misc
Article #115

Re: How to boot VMS from a failed AUDIT writing

#115
From: Terry Poot
Date: Tue, 18 Aug 1992 15:45
46 lines
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!tp
References: <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