| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
This is regarding ALL-IN-1 V3.0 and the DECInspect issue with the
OAFC$SERVER and OAFC$DEFAULT accounts.
Our Inspect person stopped by with a potention "fix" for the Inspect
issue with the OAFC accounts. The fix was the following:
1. Remove the DISUSER flag from the UAF for both accounts
2. Add Full Network Access to both accounts
This will supposedly fix the problem of Inspect flagging these
accounts. It also may help avoid them from being deleted since Inspect
flags them and they are disusered, some VMS sys managers think it's ok to
delete them!
My question is, is this the "right" thing to do for these accounts and
are there any implications in doing this? The Inspect person would
like to publish the above as a fix for the DECInspect issues with the
OAFC accounts, so I'd like to know if I should encourage or discourage
the use of this fix.
I've read note #1851 which also refers to this problem and noticed it
mentions a program run through the scheduler which will update the batch
access date of the account. Has anyone else used this method with
success and would this be a better fix that modifying the UAF records
as mentioned above?
I need to respond to our Inspect person with what we should do about
this Inspect issue and would like feedback/suggestions/comments on
which way to go and what to recommend.
Any feedback would be appreciated.
Thanks,
Lee
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3401.1 | leave them disusered | CHRLIE::HUSTON | Fri Oct 15 1993 18:04 | 11 | |
The accounts come as disusered mostly becuase they are priv'd account,
well the OAFC$SERVER account is, it has the privs to run the FCS and
as such, we wanted to keep people from logging into it (it has
sysprv and cmkrnl for instance).
Network access is not there since the account should never be logged in
to, just used as the uic for starting a detached process.
--Bob
| |||||
| 3401.2 | Go for UAF_HACK.EXE ... | ZUR01::KURTH | Peter Kurth @RLE, R�mlang (Switzerland) | Tue Oct 19 1993 11:46 | 4 |
Hi Use the image mentioned in note 1851.7. This is a fix for about 25 server accounts (*$SERVER). Regards, Peter | |||||
| 3401.3 | HOW ABOUT REMOVE/NOREMOVE_IDENTIFIER OAFC$SERVER? | ICS::DARCANGELO | Thu Nov 04 1993 14:43 | 32 | |
RE: 3401.1
If this is the case, that the UIC is used to start detached
processes, why can't the fix given in the DECinspect notes-
file be employed by the system manager? And to take it one
step further, why can't the developers use this technically
feasible fix at the time of the installation, saving manual
labor across the corporation, which continues to down-size?
Would the developers please comment on this and offer their
opinion as to the fix suggested in the DECinspect notesfile.
Would it work? ... would/might there be any adverse effects?
From the DECinspect notesfile, a fix for server accounts...
{This note has been edited to apply to "ALL-IN-1" UAF server
accounts.}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the *only* thing that OAFC$SERVER account (and OAFC$DEFAULT) is being used
for is a UIC specification in RUN/DETACH, then you can issue:
UAF> REMOVE/NOREMOVE_IDENTIFIER OAFC$SERVER
UAF> REMOVE/NOREMOVE_IDENTIFIER OAFC$DEFAULT
... to get rid of the account but keep the UIC identifier around.
Make sure you keep output (i.e. UAF> LIST OAFC$SERVER) before removing
the account, in case things stop working and you have to create it
again.
| |||||