regarding SYSUAF.DAT (further clarifications required)

[nipun_2]

Hi,
Thank you all for your replies and encouragements. I got lot of important information and procedures that I am still evaluating.

I had a question regarding my role in relation to OpenVMS. The answer to that is I will be reponsbile for handling OpenVMS system (2 machines setup as simple clusters). Hence I am getting on track with OpenVMS system as I have no experience in this area.

Now regarding AUTHORIZE utility I still need a few clarification.Can you please go through my procedure and see my question.

I had set up an account "NEW" with sysprv.

I did the following
RUN SYS$SYSTEM:AUTHORIZE
the following was the output
%UAF-E-NAOFIL, unable to open SYSUAF.DAT
-RMS-E-FNF file not found.
Do you want to create a new file?
YES

So a new file was created SYSUAF.DAT

My question:
I alreay have 4 accounts running.
Now that file (SYSUAF.DAT) will be created(or have information) only for my account "NEW". Do I have to login as SYSTEM ADministrator and do the above process all over again?

IMPORTANT ASSUMPTION
making SYSUAF.DAT only means gathering login information of user accounts not deleting or modifying them.

Is the above assumption true?
Please let me know

Thanks in advance

[Volker Halle]

Nipun,

please have a look at the chapter about the AUTHORIZE utility in the OpenVMS documentation:

http://h71000.www7.hp.com/doc/732FINAL/6048/6048pro.html#authorize_part

For ease of use - when adding new user accounts to an OpenVMS system - you could use the @SYS$EXAMPLES:ADDUSER command procedure.

SYSUAF.DAT on an OpenVMS system resides - by default - in SYS$SYSTEM, so whenever you want to make modifications, you want to set your default directory to SYS$SYSTEM: first or define a logical to point to that file: $ DEFINE SYSUAF SYS$SYSTEM:SYSUAF.DAT

Volker.

[Jan van den Ende · Accepted solution]

Nipun,

the file you CREATED is _NOT_ the file that will be used to identicate users logging in!!!!

You _MUST_ follow the instructions by Volker:
do a
$ SET DEF SYS$SYSTEM
_BEFORE_ you run AUTHORIZE.
(like discussed in your previous question, there ARE exceptions, but, given your info, those do _NOT_ apply for you)

And, hey, VMS is not that difficult once you get to know it a bit!! It is always a pleasure to see new faces (or, up here, new names at least).
Be welcome, make good friends with the HELP command, and ask any questios you may run into in this forum!

Success!

Proost.

Have one on me.

Jan

[Hein van den Heuvel]

>> I alreay have 4 accounts running.
>> Now that file (SYSUAF.DAT) will be created(or have information) only for my account "NEW". Do I have to login as SYSTEM ADministrator and do the above process all over again?

To be extra clear about it, the "NEW" account only happened in a test file and needs to be redone. The prior 4 accounts are still active.

You don't have to log in a SYSTEM, but you do have to set default to SYS$SYSTEM, or define a logical name for SYSUAF to point to SYS$SYSTEM:SYSUAF.DAT.

You could 'merge' the current NEW accoutn record from the test file into the real file, but that really is asking for trouble. Just redo that one.

Free advice: Rarely type something directly. Always stick it in a file first such that you can tweak and re-execute.. because you will :-).

Hein.

[nipun_2]

thank you for your reply,
I will try to fill some more gaps of information.
The Account "NEW" was created using @SYS$EXAMPLES:ADDUSER.COM

Now I had gone in NEW Account and used AUTHORIZE and thereby (as stated in the earlier e-mail) created a SYSUAF.DAT file. I understood from the responses where exactly I should look for SYSUAF.DAT file. So I looked in SYS$SYSTEM and found SYSUAF.DAT;2

When I gave DIR SYS$SYSTEM:SYSUAF.DAT /FULL

It showed that I this was "updated" today and was actually created in AUG 1999? Which is really confusing for me

If they system first stated unable to find "sysuaf.dat" and create a new one, how could it locate and update the existing sysuaf.dat file.

And more important for me is will it affect any user accounts when they try to log in(I tried logging in as one or two users fortunately it didn't but want to make sure). I am confused as to should keep the file as it is or do anything to it. I tried to see the file using
EDIT sysuaf.dat /tpu as well as
EDIT sysuaf.dat /teco
but everything came jumbled up (I guess owing to ASCII)

I apologize for finer details, but it is very important that the system doesn't shut down especially because of me.

Thanks again
I have been referring to System Managers Manual and Utilities Manual at HP website however, I cannot seem to put the pieces together

[Lawrence Czlapinski]

nipun,
1. do
$MCR AUTHORIZE
or
$$AUTHORIZE
not RUN (RUN uses your default directory setting)

2. If you want, you can create a symbol in your LOGIN.COM such as:
$ auth*orize :== $authorize

3. Your SYSUAF.DAT should be in SYS$COMMON:[SYSEXE]SYSUAF.DAT or other file that is on the same disk for all nodes of your cluster.

4. As previously suggested it is good practice to define the logical SYSUAF in SYLOGICALS.COM. Again the DEFINE must be the same disk and file for all nodes of the cluster. For instance:
$ DEFINE/SYSTEM/EXEC SYSUAF SYS$COMMON:[SYSEXE]SYSUAF.DAT

Lawrence

[Lawrence Czlapinski]

nipun, You use $AUTHORIZE to look at the file. Do not use EDIT. If you would use EDIT and accidentally insert characters and do a write you could screw up your authorize file.
After $AUTHORIZE (or MCR AUTHORIZE), you get an AUTH> prompt. At AUTH> prompt you can do HELP.
AUTH> HELP

You may want to start with ADD, MODIFY and SHOW commands. You may want to use a different SYSUAF.DAT to play with. You could make a symbol for using that dummy sysuaf.dat.
Lawrence

[Mobeen_1]

Nipun,
I think you are getting confused here, the file in SYS$SYSTEM was probably the file that was there prior.

If you could tell us what exactly you are trying to do, we can give you help.

I would suggest that you follow Clarence's recommendation so that it will simplyfy things for you.

Following are some answers to your queries


Now I had gone in NEW Account and used AUTHORIZE and thereby (as stated in the earlier e-mail) created a SYSUAF.DAT file. I understood from the responses where exactly I should look for SYSUAF.DAT file. So I looked in SYS$SYSTEM and found SYSUAF.DAT;2
When I gave DIR SYS$SYSTEM:SYSUAF.DAT /FULL
It showed that I this was "updated" today and was actually created in AUG 1999? Which is really confusing for me

If they system first stated unable to find "sysuaf.dat" and create a new one, how could it locate and update the existing sysuaf.dat file.

Whats happening here is, when you first ran authorize you were not in SYS$SYSTEM as a result it was asking you for creation of the new SYSUAF file. Once you set default to SYS$SYSTEM, it has found the SYSUAF.DAT file there and is using it.


And more important for me is will it affect any user accounts when they try to log in(I tried logging in as one or two users fortunately it didn't but want to make sure). I am confused as to should keep the file as it is or do anything to it. I tried to see the file using
EDIT sysuaf.dat /tpu as well as
EDIT sysuaf.dat /teco
but everything came jumbled up (I guess owing to ASCII)

I would suggest that you don't do anything to that file SYSUAF.DAT at sys$system and just live it alone :)
You are not supposed to edit the SYSUAF file, the only way you can modify the contents of this file is by using the following
$ MC AUTHORIZE
SYSUAF> MOD ACCNAME/PASS=111111
SYSUAF>exit
$
You cannot use EDIT for this file.


I apologize for finer details, but it is very important that the system doesn't shut down especially because of me.

YOu are most welcome and do let us know if we could help you any way....

rgds
Mobeen

[Jan van den Ende]

Nipun,

one more little answer to one of your questions:


It showed that I this was "updated" today


Yes, and that is fully normal.
SYSUAF also registers things like "Last login".
That means, EVERY time ANYBODY logs in to the system, the file is updated.

Proost.

Have one on me.

Jan

[nipun_2]

Hi Everyone,
Thanks for your replies. I have some updates and some answers (I am still working on it slowly).

My objective was to get comfortable with Authorize utility so that I can use it to manage accounts in future.

I was successful in making accounts using the @SYS$EXAMPLES:ADDUSER example (that Mobeen stated as well). So now I wanted to see using AUTHORIZE utility how I can manage the accounts previosuly created (e.g no of user accounts made, quotas, priveleges etc.). That is the reason I tried to use AUTHORIZE and the whole issue of SYSUAF.DAT started.

Lawerence has given an important tip about MCR that is really helpful. So I think I will leave the SYSUAF.DAT for now (unless some problems are created :) ).

Please feel free to give me any suggestions regarding managing account (whether authorize utility or some other utility is better)

I am referring System Managers Mannual as well as System Managers Utility Mannual.

[Martin Vorlaender]

Nipun,

>>>
Please feel free to give me any suggestions regarding managing account (whether authorize utility or some other utility is better)
<<<

For those of us having to live with MS desktops: there's a client/server utility named OpenVMS Management Station (aka TNT nee Argus) that can be used (among other things) to manage user accounts. See http://h71000.www7.hp.com/openvms/products/argus/

But: please *do* learn to use AUTHORIZE properly; TNT is just a convenience tool.

cu,
Martin

[Doug Phillips]

nipun,

A bit of further clarification: You should only use MCR to execute authorize if you have defined SYSUAF & related files as logicals. In systartup_vms.com, or sylogicals.com if you wish, you would have something like this:

$ define/system/exec SYSUAF SYS$SYSROOT:[SYSEXE]SYSUAF.DAT;
$ define/system/exec RIGHTSLIST SYS$SYSROOT:[SYSEXE]RIGHTSLIST.DAT;
$ define/system/exec NETPROXY SYS$SYSROOT:[SYSEXE]NETPROXY.DAT;

and if you type SHOW LOGICAL SYSUAF you would see the full file spec.

If you use MCR to execute authorize and your default directory is not sys$system (same as sys$sysroot:[sysexe]) then authorize will not access the proper sysuaf file. That's why I do NOT use MCR to execute authorize unless I've first checked to see if SYSUAF is defined. And, if you have set your default directory to sys$system you don't need to use MCR, you can just use R.

The "HP OpenVMS System Manager's Manual, Volume 1: Essentials" explains how the login process works and Volume 2 gets into it in greater depth.

Doug