Multiple SYSUAF

[LM_2]

Does anyone know if it is possible to have two seperate sysuaf's on a VMS cluster? I am merging two clusters into one cluster and I would like to keep the sysuaf's seperate. VMS version 7.3-2

[John Yu_1 · Accepted solution]

Yes, it can be as simple as pointing the system logical SYSUAF to different devices for each instance.

[Uwe Zessin]

Sure. It is no technical problem. Even if you have one common disk, you can give each node its own SYSUAF.

Whether you will be lucky if you start maintaining it is another question. You can easily merge two SYSUAF files, provided that UICs and/or usernames are unique.

[Jan van den Ende]

LM,

_IF_ that is what you want, it is fully supported.

And in migration trajects, it is often used.

_BUT_ be aware of the extra complexity involved.
Especially if you have UICs that in one SYSUAF belong to an account different from that same UIC value in the other UAF, be aware that owner ships and access rights belonging to USER1 from SYSUAF1, simply BELONG to USER2 from SYSUAF2.
Under water, the UIC is the _ONLY_ value that DEFINES those ISs!!

But if you are aware of that, and at your site that does not pose a problem, you are OK to go, and it is fully supported.

Proost.

Have one on me.

jpe

[LM_2]

I know about the sysuaf system logical - but how would it know which user uses what sysuaf - this is confusing on how to type it out - but how would I assign the one sysuaf to a certain group of user's and have the other group use the second one...or would it look at both sysuafs when someone logs in......???

[Uwe Zessin]

The operating system uses a single SYSUAF for authorization. You cannot have multiple active SYSUAF files within a single OpenVMS instance. If the user is not present in the active SYSUAF, (s)he cannot login on that node.

[Hein van den Heuvel]

NO can do.

WHY do you want this? Maybe there are better ways to achieve your goals.

Are you concerned about username or UIC duplicates? You just HAVE to deal with those before joining, no escape.

For reporting purposes? I think your best bet is to construct something recognizable for each 'group'.
- It could be part of the account name,
- the logical names for the default device
- a set of UIC groups, or application private data in the USERDATA portion of the SYSUAF record.

Later on you can report based on that.

hth,
Hein.

[LM_2]

So pretty much what I need to do if I wanted this to happen - is have each node have a seperate sysuaf file - and then have one set of user's log into the first node - and the other set of user's log into the second node. Not sure this would be a good scenerio to do. Something I will need to think about.

[Jess Goodman]

Logins will use whichever SYSUAF is pointed to by the SYSUAF system logical on the node the user is logged in on.

So if you have two groups of users defined in two different SYSUAFs that will be logging in on overlapping nodes I'm afraid there's no easy solution. (It's possible you could program a solution using LOGINOUT
callouts but this would be very convoluted).

If you can restrict access to each group of users to non-overlapping nodes then you can use two SYSUAFs. You can manage both SYSUAFs from any node by defining SYSUAF as a process logical.

[LM_2]

To clarify what I am doing is currently we have two seperate divisions who are running on two different clusters. One division is moving over to my cluster - so we have two seperate sysuaf files and we have not looked into it yet - but I am sure we will have duplicate uic's/usernames - I have over 700 vms accounts and they have over 300. So my goal was to see if we could keep our same sysuaf's - I didn't think it could be done - but it was kind of wishful thinking.

[Uwe Zessin]

I agree that this separation is not a good one - why merge the cluster if users are restricted to one node?

By the way: this not only includes interactive logins - it also limits the use for batch jobs, network tasks and (I think) print jobs.

[Jan van den Ende]

LM,


but how would it know which user uses what sysuaf


In a cluster of more than one nodes (let's forget for the moment that it _IS_ also valid to have single-node clusters) any user-proces) is always active on _ONE_ node.
Your different nodes _CAN_ have different SYSUAFs by using different definitions of SYSUAF, OR, by using the default, the SYSUAFs in the SYS$SYSTEMs on the different system disks, OR, by locating (some of) the SYSUAFs in SYS$SPECIFIC:[SYSEXE] instead of SYS$COMMON:[SYSEXE].
Whichever mechanism you use (if you really want to make it confusing, you can even mix them!), each process derives its SYSUAF info from the currently governing SYSAUF _ON THAT NODE_.
So, which SYSUAF is used, is determined by the node that the user logs in to.

hth

Proost.

Have one on me.

jpe

[Hein van den Heuvel]

Just try your merge with convert /excep
See how much trouble there is

Extract clean records with
$convert/share sysuaf.dat sysuaf_node_1.dat
$convert/share sysuaf.dat sysuaf_node_2.dat
$convert/stat/merge/excep=sysuaf_problems.dat sysuaf_node_1.dat sysuaf_node_2.dat
Make the smaller node node_1

Similar for rightslist.

Now at least you'll know the scope of the problem.

fwiw,
Hein.

[Jan van den Ende]

LM,

I see you point now.

What can be done (and I HAVE done this more than once) is to start out the way you plan.

But after that, as soon as you can reasonably manage, you disentangle the conflicts.

Start by merging the non-conflicting accounts (the easiest, and hopefully the largest part)

Then change UICs (and the corresponding ownerships) one at a time.
Copy the changed account at that time from the "smaller" SYSUAF the "bigger" one.

When you are done, have all systems point to your now integrated SYSUAF.

--THIS is the time that you need to prepare the helpdesk for, and warn the users, because the 'small" SYSUAF passwords will now no longer be valid.
(unless you want to do some trickery on the records of the SYSUAF-to-be-deserted, and selectively merge them into the surviving one. Can also be done, but requires some delicate programming).

hth

Proost.

Have one on me.

jpe

[John Yu_1]

If you only need two instances of SYSUAF.

For nodes on each of the orig clusters
"SYSUAF" = "CLUSTER1_NODES:SYSUAF.DAT"
or
"SYSUAF" = "CLUSTER2_NODES:SYSUAF.DAT"

whichever sysuaf they get would depend on the node they log into.

[Ian Miller.]

When you are ready Merging UAF's has been described here before and its in the sysman utility manual.

[Arch_Muthiah]

LM,

>I know about the sysuaf system logical - >but how would it know which user uses what >sysuaf - this is confusing on how to type >it out - but how would I assign the one >sysuaf to a certain group of user's and >have the other group use the second >one...or would it look at both sysuafs when >someone logs in......???

This is from our cluster manual....

1) Keep your two sets system common files in two different non system disks. dka700 & dka800.

That is one set of SYSUAF.DAT, NETPROXY.DAT, SYS$SYSTEM:RIGHTSLIST.DAT and SYS$SYSTEM:VMSMAIL_PROFILE.DATA.

2) Modify SYS$COMMON:[SYSMGR]SYLOGICALS.COM on each system disk and define the logical names that points to the two setsts of system common files which are on dka700 and dka800.
ex:
$ DEFINE/SYSTEM/EXEC SYSUAF -
dka700:[VMS$COMMON.SYSEXE]SYSUAF.DAT

$ DEFINE/SYSTEM/EXEC SYSUAF -
dka800:[VMS$COMMON.SYSEXE]SYSUAF.DAT

3) make sure the system disks are mounted correctly with each reboot by Copying the SYS$EXAMPLES:CLU_MOUNT_DISK.COM file to the
[VMS$COMMON.SYSMGR] and Edit SYLOGICALS.COM and include commands to mount, with the appropriate volume label, the system disk containing the shared files.
Example: If the system disk is $1$DJA16, include the following command:
$ @SYS$SYSDEVICE:[VMS$COMMON.SYSMGR]CLU_MOUNT_DISK.COM $1$DJA16: volume-label

And make sure Disks holding common files must be mounted early in the system startup
procedure (SYLOGICALS.COM) and that the disks are mounted with each OpenVMS Cluster
reboot.


Archunan

[John Gillings]

LM,

>if it is possible to have two
>seperate sysuaf's on a VMS cluster?

You really don't want to do this. The same username in two different UAFs will have different passwords. Users will have to know which node they're logging into to know which password to use.

If the UICs and identifiers are not in synch, it's total CHAOS. Even if they are in synch, you'll be guaranteed that things like new mail counts will always be wrong, no matter which node you login to.

OpenVMS clusters are designed to share a common security domain, which includes the UAF, RIGHTSLIST, password history, mail profile, audit settings, queue manager, license data base and more (see SYLOGICALS.TEMPLATE for a list of files). Although it's (too!) easy to build a cluster where these files are NOT shared, all manner of strange and unsafe behaviours occur.

If you're going to build a cluster, it's far far better to put in the effort to configure it correctly up front, rather than try to puzzle out what's wrong later. Read the cluster configuration guide and follow Hein's advice to merge your existing UAFs and RIGHTSLISTs.

[Robert Gezelter]

LM,

I agree with John Gillings, this is not a particularly safe situation.

It is not only a matter of SYSUAF, it is also a matter of RIGHTSLIST and a variety of other things.

Not to write a long-winded post, but there are several mileposts that must be checked off:

- you must ensure that the UIC ranges are disjoint
- you must ensure that the Identifiers are disjoint
- if anybody needs a change of UIC or identifier, this should be done BEFORE attempting to merge the clusters
- You should create a Rights Identifier for each of the two divisions, and grant it to each user, as appropriate (Systems staff will probably need BOTH identifiers).
- Modify SYLOGIN.COM to execute a file which will setup the base environment for each company AND whether they can log into a particular node (some of this could be done by LOGINOUT callbacks).

If I thought about it for a bit, there are probably other issues that need be taken care of. I have done this type of merge in the past for clients, and it can be complex. In the end, the result is generally worth the effort.

I have presented some issues relating to this in the "Inheritance Based Environments for OpenVMS Systems and OpenVMS Clusters" (published in the OpenVMS Technical Journal, Volume 3, PDF reprints are available at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ), and "OpenVMS User Environments", a seminar about the resulting multi-organization environment at HP World 2004 (a summary presentation from this session is at http://www.rlgsc.com/hpworld/2004/N227.html ).

I hope that the above is helpful.

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

[Jim Lahman_1]

I have a two node cluster that shares a sysuaf file. The sysuaf file is stored on the a shadow disk, $1$DGA100:, located on a MSA drive that is connected to both nodes.

I created a directory $1$DGA100 calling it cluster_share, $1$DGA100:[CLUSTER_SHARE]. I mount $1$DGA100: in sylogicals.com and define a logical clghd$share that points to $1$DGA100:[CLUSTER_SHARE].

Here's my sylogicals.com:

$ mount/cluster $1$dga100: hdgldat1 hdgldat1
$ define/system/executive cglhd$share $1$dga100:[cluster_share]
$ @cglhd$share:cglhd_sylogicals.com

Looking closely at sylogicals.com, you'll notice that the last thing it executes is another command procedure: cglhd_sylogicals.com. This command procedure redefines all the system logicals to point to the new location of system files.

Here's cglhd_sylogicals.com:

$ DEFINE/SYSTEM/EXECUTIVE SYSUAF cglhd$share:SYSUAF.DAT
$ DEFINE/SYSTEM/EXECUTIVE SYSUAFALT cglhd$share:SYSUAFALT.DAT
$ DEFINE/SYSTEM/EXECUTIVE SYSALF cglhd$share:SYSALF.DAT
$ DEFINE/SYSTEM/EXECUTIVE RIGHTSLIST cglhd$share:RIGHTSLIST.DAT
$ DEFINE/SYSTEM/EXECUTIVE NETPROXY cglhd$share:NETPROXY.DAT
$ DEFINE/SYSTEM/EXECUTIVE NET$PROXY cglhd$share:NET$PROXY.DAT
$ DEFINE/SYSTEM/EXECUTIVE NETOBJECT cglhd$share:NETOBJECT.DAT
$ DEFINE/SYSTEM/EXECUTIVE VMS$OBJECTS cglhd$share:VMS$OBJECTS.DAT
$ DEFINE/SYSTEM/EXECUTIVE VMS$AUDIT_SERVER cglhd$share:VMS$AUDIT_SERVER.DAT
$ DEFINE/SYSTEM/EXECUTIVE PASSWORD_HISTORY cglhd$share:VMS$PASSWORD_HISTORY.DATA
$ DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_DICTIONARY cglhd$share:VMS$PASSWORD_DICTIONARY.DATA