Conference noted::hackers_v1

    The problem you are having is due to OPCOMs having problems with
    your sys$command stream.
    
    Should you wish to close the operator log file from batch, you will
    have to do something of the following:
    
    $ DEFINE /USER_NODE SYS$COMMAND _OPA0:
    $ REPLY /LOG
    
    Note, that you did not have to enable yourself as an operator terminal
    as the console is already so.  If you attempted the REPLY/ENABLE,
    or other functions from BATCH, what else would you define as the
    terminal to get the OPCOM messages?  Use the one that is always
    on your system, OPA0:.
    
    Note, Mailboxes can not be set to receive OPCOM messages also. 
    I know, as I tried, but hacked something more elegant, although
    when you go for elegancy, who cares about supportability!
    
    -- nestor
    

    You could take a snapshot of the operator's log with the
    backup/ignore=interlock command. You don't need to close the file
    to do this. This is the way SECURPACK does it.

    Ed

    re: .-1
    
    Sure, but if you don't clean up OPERATOR.LOG doesn't it get larger
    and larger every day, making scanner type programs (usually written
    in DCL) less and less efficient as time goes by?
    
    I know, you can write scanner programs in a higher level language.
    Same rule applies, more unneccessary I/O.
    
    /pjh

    RE: .-1
    
    You get a new OPERATOR.LOG each time the system is booted, unlike
    ACCOUNTNG.DAT, which keeps growing.  So, unless your system stays
    up a long time, the size shouldn't be a problem.
    
    -Bob

    
    Our systems all have battery backup and powerfail restart. We
    experience uptimes greater than 18 days - couple that with the fact
    that it's a cluster and you get OPERATOR.LOG files greater than
    3500 blocks - BTW powerfail restarts are not cold boots - OPCOM
    never shuts down so no new logs. SECpack isn't exceedingly intelligent
    about searching through logs, you should see how long it takes after
    a week of poking through the same log over and over and over....
    
    /pjh
    

.0>    	... Whenever I invoke [reply/enable] from my account (Operator
.0>    privs) with  reply/enable "enabled"...
.0>    I get an "Illegal Operator Request" message. If I so it from the
.0>    SYSTEM account I get the same message.
.0>    
.0>    	Do the manuals lie (again :-)     ?)
.0>    
.0>    	Im trying to close the operator.log file so that I can construct
.0>    a batch .COM file to mail SECURITY info to me.
    

    This probably doesn't have anything to do with your problem, but
    you mentioned the right things ("illegal operator request" and
    "security") in your note which made me think of this.  I hope it
    turns out to be useful for someone.

    In order to enable a terminal as a SECURITY terminal, you need both
    OPER and SECURITY privs.  [Try it -- give yourself OPER and type
    REPLY/ENABLE -- you'll be enabled for everything *except* SECURITY.]
    This is something the manuals don't tell you.   I QARed this a long
    time ago (over a year).

				JENelson

    Actually the information is in the manual, it just doesn't explicitly
    state that you have to have "both OPER and SECURITY enabled to do
    a REPLY/ENABLE=SECURITY". I know our operators wouldn't want SECURITY
    enabled all the time, it's awfully verbose.
    
    The concept I believe the manual ("Guide to VMS Security") is trying
    to impart is that there is a "security manager" for a system. This
    seems to imply that large systems should be set for security auditing,
    it really doesn't get realistic about uVAXen. The "security manager"
    is the one who has the SECURITY priv, and on a large installation
    it makes sense. 
    
    What this has to do with workstations is moot. Do you want everything
    audited on your single-user system? I think not. You want your RD53
    or RD54 system disk filled up with "security alarms" about JOBCTL
    deleting files using it's BYPASS privilege? Up to you, I guess.
    What about those pesky PASSWORD changes? On a workstation? Why?
    
    /pjh
    

    $ @sys$manager:SECAUDIT /out=secaudit.tmp   sys$manager:OPERATOR.LOG
    $ Mail   secaudit.tmp   toyou /subject="Security Info"
    $ Delete secaudit.tmp;


    Also P2 to P5 can be specified to extract security info depending on
    username, starting date, ending date and event class.


	*Jaume