 |
The Question is:
Greeting, and thanks for helping the VMS community. I have two alphas, and am
not able to run VMS on either of them (the axppci33 because of it's AT
keyobard, and my PC164 because compaq was unaware what 64 bit pci scsi
controller is recognnized bt vms,
and SRM 5.5-1) However I was recently given a MicroVAX 3100-80 which is now
running OpenVMS 6.2. I have been greatly enjoying learning VMS, but have run
into a problem.. Somehow I've ended up with sysuaf.dat and sysuaf_old.dat, and
am trying to figure out
what changed my UAF, and how to fully and cleanly replace the old one as
sysuaf.dat.
I was attempting to add some accounts with ADDUSER.COM, and at first the
accounts were simply incapable of logging in. So I ran AUTHORIZE ANd removed
the offending accounts and rad more documentation, and successfully added four
accounts. They were flag
ged DISUSER at creation, so I removed that via AUTHORIZE.
Soon after the SYSTEM account was not logging in, and my VT340+ would not
recover it's session. users could log in, however i decided shutting down
would be prudent, but was unable to do so cleanly. (I let the machine idle a
day to be sure all buffers s
ynced to disk)
On reboot, opcom did not background properly, and my UCX services did not
start properly. System however was capable of logging in, so I ran AUTHORIZE
to check the status of the accounts. I founf only 5 accounts; SYSTEM, DEFAULT,
and the three inoperabl
e accounts from the first invocation of adduser (recognized them by the UICs)
However all of the other accounts including the ones for UCX services were
gone. I soon disvoered that the sysuaf.dat I expected to be there was now
sysuaf_old.dat (type was pro
bably not the right tool, but it worked)
I want to make the sysuaf_old.dat not only the default, but sysuaf.dat again.
I know you can define a SYSUAF logical, and also that one is not supposed to
rename sysuaf.dat in any way.
How do i properly and cleanly return sysuaf_old.dat to being called
sysuaf.dat, and completely remove the new sysuaf.dat that came from parts
unknown? Also, why was a new sysuaf.dat created? All the same account (from
the second invocation of adduser) a
re present in sysuaf_old.dat, and I never recieved a prompt for the creation of
a new sysuaf.. So I am rather confused at how this happened. I rather want to
get the system back to it's state before I fouled up (however I fouled up)
so all the accounts necessary for secondary sofware packages to run; I also
want to be sure I don't have more than one sysuaf.dat so this problem does
not occur again.
Thank you for your help, I have been using/administering my VAX for about a
week. I am really enjoying VMS, and hope to install VMS on my PC164 (if I can
ever find a scsi controller) via the VMS hobbyist program. Again, Thank you.
Buck Rekow
The Answer is :
The OpenVMS Wizard would tend to recreate the RIGHTSLIST and SYSUAF
from scratch or from a distribution -- and would probably simply
reinstall a more recent verison of OpenVMS VAX and would start over.
Resolving odd configuration problems is possible, but the effort of
reverse engineering how the system got into the state or how to
resolve a particular state is far more difficult to describe.
Using a cleanly-installed distribution means your configuration
far more closely follows the OpenVMS documentation, obviously.
The OpenVMS Wizard would strongly encourage review of the OpenVMS
System Management Essentials documentation, particularly around the
use of AUTHORIZE and the various AUTHORIZE logical names -- such as
SYSUAF, RIGHTSLIST, NETPROXY, NET$PROXY and others.
You can set these and other logical names in SYLOGICALS.COM, but your
current OpenVMS release is sufficiently old that it lacks various
helpful comments around these and other logical names -- see existing
topics of SYLOGICALS.TEMPLATE such as topic (60) for related details.
(The cited comments were implemented in this file in OpenVMS V7.2.)
The DISUSER flag is probably set on the DEFAULT account, which is
the template from which otherwise unspecified settings are acquired.
|
|
|
|
|
