SYSUAF

[Peter Clarke]

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

[Martin Vorlaender]

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

[Martin Vorlaender]

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

[Jim_McKinney]

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.

[Wim Van den Wyngaert]

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

Wim

[Peter Clarke]

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

[Hein van den Heuvel · Accepted solution]

Backup / ignore = interlock

THat tends to fine.

Better would be

$CONVERT/STAT/SHARE sysuaf sysuaf.copy

Hein.

[Robert Gezelter]

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

[Peter Clarke]

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

[Peter Clarke]

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.

[The Brit]

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

[Steven Schweda]

> 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".

[Hoff]

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.

[Peter Clarke]

the command i ran was:

define/sys $1$dka6: dra2:

[Steven Schweda]

> 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.

[Robert Gezelter]

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

[Joseph Huber_1]

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" .

[Paul Jerrom]

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

[Paul Jerrom]

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

[AEFAEF]

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

[Steven Schweda]

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

As I said, I'd add /EXECUTIVE_MODE.

My notes (older than 11 October 1999, in the
procedure I use to define users' home
devices) say:

(Executive mode is required for use by
utilities like MAIL and PHONE.)

I haven't tested this in the past decade, but
it might still be true, and might be relevant
here.

[Jim_McKinney]

> (Executive mode is required for use by
> utilities like MAIL and PHONE.)

and LOGINOUT.

[AEFAEF]

Steven Schweda is right. I neglected to add /EXECUTIVE. This is what HP recommends for public volumes.

Thanks for catching my goof!

[Richard W Hunt]

The correct solution has already been offered. This post is to corroborate and confirm that it works.

I have a bunch of moderatly small disks as the result of a complex history. Not required to understand that part. BUT what you need to know is that every one of those disks has a logical name defined /EXEC on the system.

On the failover system, I have the same number of same-sized disks but for technical reasons, the physical names are different. Doesn't matter. The logical names of all disks on the primary also exist on corresponding disks on the standby system.

And the crowning jewel is that SYSUAF devices are the logical names. So if I have to switch from primary to standby system, I just copy the SYSUAF.DAT and other files to the standby system's system disk. We do SAN-style replication on a regular basis. When we have to switch hosts, we only have the last 24 hours worth of incremental changes to apply and we can then reboot in the other site. So if you are in any situation even slightly similar to this, save yourself a major headache. NEVER use a physical device name except in your reboot scripts or from the system console when in console mode.

[Joseph Huber_1]

Just as an addendum:
If You happen to have Joe Meadows UAF program (VMS freeware), then You can get a list of users with home directories on a specific disk simply by
$ uaf/select=device=thedisk:/display=(user,device)

And UAF displays the disk also for Disusered users, other than AUTHORIZE show /BRIEF.