- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Multiple SYSUAF
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 06:42 AM
07-20-2006 06:42 AM
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 06:54 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 06:55 AM
07-20-2006 06:55 AM
Re: Multiple 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 06:56 AM
07-20-2006 06:56 AM
Re: Multiple SYSUAF
_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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:02 AM
07-20-2006 07:02 AM
Re: Multiple SYSUAF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:08 AM
07-20-2006 07:08 AM
Re: Multiple SYSUAF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:11 AM
07-20-2006 07:11 AM
Re: Multiple SYSUAF
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:13 AM
07-20-2006 07:13 AM
Re: Multiple SYSUAF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:17 AM
07-20-2006 07:17 AM
Re: Multiple SYSUAF
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:17 AM
07-20-2006 07:17 AM
Re: Multiple SYSUAF
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:19 AM
07-20-2006 07:19 AM
Re: Multiple SYSUAF
By the way: this not only includes interactive logins - it also limits the use for batch jobs, network tasks and (I think) print jobs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:22 AM
07-20-2006 07:22 AM
Re: Multiple SYSUAF
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:28 AM
07-20-2006 07:28 AM
Re: Multiple SYSUAF
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:38 AM
07-20-2006 07:38 AM
Re: Multiple SYSUAF
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 07:44 AM
07-20-2006 07:44 AM
Re: Multiple 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 09:06 AM
07-20-2006 09:06 AM
Re: Multiple SYSUAF
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 09:55 AM
07-20-2006 09:55 AM
Re: Multiple SYSUAF
>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
Archie
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2006 01:19 PM
07-20-2006 01:19 PM
Re: Multiple SYSUAF
>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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2006 04:27 AM
07-21-2006 04:27 AM
Re: Multiple SYSUAF
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-21-2006 05:35 AM
07-21-2006 05:35 AM
Re: Multiple SYSUAF
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