topic Re: SYSUAF in Operating System - OpenVMS

SYSUAF

Peter Clarke — Tue, 31 Mar 2009 09:52:34 GMT

Hi,

I have two ES40 server one is used as a standalone failover and i need to update it so that the users and passwords are the same on both machines.I have copied over the sysuaf.lis file but it still doesn't let me log in on the backup server with the same password as the live server.
Any ideas?

Thanks

Re: SYSUAF

Martin Vorlaender — Tue, 31 Mar 2009 09:58:14 GMT

Peter,

the .LIS file is a text listing of the SYSUAF data. The file used by the system is SYS$SYSTEM:SYSUAF.DAT.

cu,
Martin

Re: SYSUAF

Martin Vorlaender — Tue, 31 Mar 2009 09:58:57 GMT

... or the file the logical name SYSUAF points to, if it is defined.

Re: SYSUAF

Jim_McKinney — Tue, 31 Mar 2009 10:11:56 GMT

In addition to the SYSUAF.DAT that Martin has already noted, you'll likely want its friends; RIGHTSLIST.DAT, NETPROXY.DAT, and/or NET$PROXY.DAT.

Re: SYSUAF

Wim Van den Wyngaert — Tue, 31 Mar 2009 10:45:33 GMT

And do ucx sho prox and verify if the usernames are the same.

Wim

Re: SYSUAF

Peter Clarke — Tue, 31 Mar 2009 11:07:27 GMT

I am getting a message that the file is locked.. Do i need to take the system down to get this file?

Re: SYSUAF

Hein van den Heuvel — Tue, 31 Mar 2009 11:13:48 GMT

Backup / ignore = interlock

THat tends to fine.

Better would be

$CONVERT/STAT/SHARE sysuaf sysuaf.copy

Hein.

Re: SYSUAF

Robert Gezelter — Tue, 31 Mar 2009 11:19:16 GMT

Peter,

The file may be locked because someone is accessing it. A quick test on two of my systems reveals that a simple COPY can work (although admittedly those two systems are not heavily active with other users).

SHOW DEVICE/FILES will display all open files together with the process that has the file opened on the device. It can be a chore to go through, so I recommend routing the output to a file and using either SEARCH or an editor to search through the output.

One can also use CONVERT to copy SYSUAF. As a last resort, one can use BACKUP/IGNORE=INTERLOCK, but one must then take steps to ensure that one has a good copy (if someone was updating the file at the time the BACKUP was being taken, there may be inconsistencies).

Also, remember that RIGHTSLIST and the various proxy files need to be synchronized with SYSUAF.

- Bob Gezelter, http://www.rlgsc.com

Re: SYSUAF

Peter Clarke — Tue, 31 Mar 2009 11:26:55 GMT

That worked thanks....
However now when i login i get the command line instead of the user menu that i had before... whats changed?

Re: SYSUAF

Peter Clarke — Tue, 31 Mar 2009 11:35:56 GMT

Seems to be the device it is $1$dka6: on live system but the home directory is on dra2: on the backup machine.
I changed it on one login and it worked.
Is there any way to change all users to point to this device? (easily)
I set up a logical pointing $1$dka6: to dra2: but this didn't work.

Re: SYSUAF

The Brit — Tue, 31 Mar 2009 11:46:46 GMT

Check that your SYLOGIN.COM is the same on both systems, it can be found in Sys$Common:[SYSMGR].

Also check your account in SYSUAF.DAT. At the top on the left, there is a field called "LGICMD" which will normally indicate the name of the User's Login File. If this file exists on your production side, it must also exist on your standby node, and must contain the same stuff.

I should mention that if your "standby" is really a standby, then there are many other files which need to be kept synchronized - startup files for example, Queue Manager DB files, etc.

Dave

Re: SYSUAF

Steven Schweda — Tue, 31 Mar 2009 11:52:42 GMT

> Is there any way to change all users to
> point to this device? (easily)

Define "easily".

Around here, users (mostly I) have SYSUAF
settings like this:

Default: HOME_SMS:[SMS]

where HOME_user-name is a logical name:

ALP $ show logical /full home_sms
"HOME_SMS" [exec] = "ALP$DKA0:" (LNM$SYSTEM_TABLE)

which is defined at system start-up, in a
node-specific command procedure, so it can be
anything one might like, anywhere one might
like it.

> I set up a logical pointing $1$dka6: to
> dra2: but this didn't work.

That's what you _think_ did. Now, perhaps
you could disclose what you _actually_ did,
and how you decided that it "didn't work".

Re: SYSUAF

Hoff — Tue, 31 Mar 2009 12:10:13 GMT

Other folks have discussed the direct approach here; replicating the SYSUAF file and setting up the logical name for SYSUAF.

Here are some variations to what has been discussed in other replies, and some background on how some of these pieces work, and work together. And sometimes don't work.

If you're just looking to synchronize passwords, you can trump the whole password replication and synchronization discussion using LDAP on V8.3 or with one of the other external authentication mechanisms; your passwords can be sitting in a remote Active Directory or Open Directory store. Intro:

http://64.223.189.234/node/359

SYSUAF is just one part of the authentication environment. If you're not (also) keeping the UICs lined up, you can end up with access incorrectly blocked or incorrectly not blocked. See the section on merging here:

http://64.223.189.234/node/169

If you're replicating, you need be aware of UICs and identifiers, too. Tool:

http://64.223.189.234/node/426

Regardless, the best approach here is to cluster. That gets you the selective use of your hot-spare as part of your production environment, and both hosts are continuously current. Yes, the cluster licenses are expensive.

And by coincidence, I'm writing some C code in this same basic area this week, and have code that replicates the SYSUAF data over into another database.

Re: SYSUAF

Peter Clarke — Tue, 31 Mar 2009 12:43:55 GMT

the command i ran was:

define/sys $1$dka6: dra2:

Re: SYSUAF

Steven Schweda — Tue, 31 Mar 2009 13:07:45 GMT

> the command i ran was:
>
> define/sys $1$dka6: dra2:

That's a start. I'd probably start with
something more like:

define /system /executive_mode $1$dka6 dra2:

and then I might consider answering the part
about:

> [...] how you decided that it "didn't
> work".

Showing actual commands with their actual
output is often more helpful than vague
descriptions and/or interpretations.

Re: SYSUAF

Robert Gezelter — Tue, 31 Mar 2009 13:56:57 GMT

Peter,

There is almost never a good reason to use an actual device name, except in an actual MOUNT command.

In this case, the most probable best answer is to use the DISK$xxx name created when the disk is MOUNTed.

- Bob Gezelter, http://www.rlgsc.com

Re: SYSUAF

Joseph Huber_1 — Wed, 01 Apr 2009 11:17:11 GMT

Since this rerouting of devices should only be a temporary solution, change all users home device to use the same logical name on both systems.
To answer Your question
>> Is there any way to change all users to point to this device? (easily)

Well, since $getuai has no way to use wildcard user names,
the simplest is to use the output of
Authorize list/brief (->sysuaf.lis), and process with a command procedure like this:

$! record position of authorize list/brief:
$ _S_owner = 0
$ _L_owner = 19
$ _S_username = 20
$ _L_username = 15
$ _S_uic = 36
$ _L_uic = 12
$ _S_account = 49
$ _L_account = 8
$ _S_privs = 59
$ _L_privs = 7
$ _S_pri = 67
$ _L_pri = 2
$ _S_devdir = 69
$ _l_devdir = 20
$!
$ open/error=exit uaf sysuaf.lis
$ read/end=done uaf line
$LOOP:
$ read/end=done uaf line
$ owner=f$edit(f$extract(_S_owner,_L_owner,line),"TRIM")
$ username=f$edit(f$extract(_S_username,_L_username,line),"TRIM")
$ uic=f$edit(f$extract(_S_uic,_L_uic,line),"TRIM")
$ account=f$edit(f$extract(_S_account,_L_account,line),"TRIM")
$ privs=f$edit(f$extract(_S_privs,_L_privs,line),"TRIM")
$ pri=f$edit(f$extract(_S_pri,_L_pri,line),"TRIM")
$ devdir=f$edit(f$extract(_S_devdir,_L_devdir,line),"TRIM")
$ if f$edit(devdir,"UPCASE,COMPRESS").eqs."DISUSER"
$ then
$ write sys$output "User ",username," is disabled: no dev:[directory]!"
$ dev=""
$ dir = ""
$ else
$ dev=f$parse(devdir,,,"DEVICE","SYNTAX_ONLY")
$ dir=f$parse(devdir,,,"DIRECTORY","SYNTAX_ONLY")
$ endif
$ if dev.eqs.p1 then authorize mod 'username'/device='p2'
$ goto loop
$DONE:
$ close uaf
$EXIT:
$ exit

Assuming AUTHORIZE :== $AUTHORIZE
Call this as "@thisone olddevice newdevice" .

Re: SYSUAF

Paul Jerrom — Wed, 01 Apr 2009 19:43:32 GMT

Howdy,

The reason the DEFINE didn't work is because you have it the wrong way around! You are wanting to set up a logical called DRA2, not a logical called $1$DKA6 (or whatever your value is).
Format is DEFINE/SYSTEM logical-name value
so you want define/sys dra2 $1$dka6
(make sure you deassign/sys the logical name you erroneously set up otherwise you'll have a logical name translation loop)

BTW, all my systems do NOT have the user's login device hardcoded, all use logical names - ie USERDISK.

Have fun,

PJ

Re: SYSUAF

Paul Jerrom — Wed, 01 Apr 2009 19:45:00 GMT

Oopsie, re-reading the thread shows it was me that got the define around the wrong way - sorry!!

But comment re. logicals cf device names still applies.

PJ

Re: SYSUAF

AEFAEF — Thu, 02 Apr 2009 11:58:59 GMT

Paul wrote

"Format is DEFINE/SYSTEM logical-name value
so you want define/sys dra2 $1$dka6"

No! Always use a colon in the equivalence name if it is a device or another logical name that is DEFINE-ed to be part of a file-spec. (OTOH, omit the colon for queue names, forms, and characteristics; mail addresses; data [as in "$ DEFINE EVE$KEYPAD EDT" and such[; etc.)

$ DEFINE/SYSTEM DRA2 $1$DKA6:

or $ DEFINE/SYSTEM $1$DKA6 DRA2: ! whichever it is !

Omitting the colon causes problems in certain cases.

For example:

$ SH DEV DSA0

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
DSA0: Mounted 0 OPENVMS062 837135 197 1
$1$DKA0: (IDS15) ShadowSetMember 0 (member of DSA0:)
$
$ DEFINE BLAH DSA0
$ SET DEFAULT BLAH:[SYS0]
%RMS-F-DIR, error in directory name
$ DEFINE BLAH DSA0:
%DCL-I-SUPERSEDE, previous value of BLAH has been superseded
$ SET DEFAULT BLAH:[SYS0]
$ SHOW DEFAULT
BLAH:[SYS0]
$

"BTW, all my systems do NOT have the user's login device hardcoded, all use logical names - ie USERDISK."

I agree. The only place you should use a physical disk name is when you MOUNT the device and define a /SYSTEM logical name in your startup procedures that points to the device.* If you then reference this disk only via the logical name, changing the disk name is easy: you just redefine the logical name to point to the new disk name. This saves you the trouble of changing all disk references in all your code, command proceudres, databases (SYSUAF.DAT, e.g.), and such. You need only redefine one logical name in your startup procedures.

* Alternatively, you can reference DISK$volume_label instead of defining your own logical name. This way the volume label is your core reference.

AEF