Merging SysUAF & RightsLists from 3 nodes

[Aaron Sakovich]

Hi all,

Got a simple task to do -- take my 3 individual nodes and turn them into a cluster. To make life easy on the users, I want to extract the UAF & RightsLists entries for the users dependent upon which host they most frequently use and make that their "new" account. This keeps quotas and passwords the same and optimized for their work environment.

So I went and got copies of the SysUAF.dat and RightsLists.dat from each of the 3 hosts and stuck them into a scratch directory for testing my procedure. I wrote scripts to modify the files, removing users from each that wouldn't be in the final cut from that system, and modifying the account info for the accounts that remained. To make sure I was working on the right file pairs, I defined process logicals for SYSUAF and RIGHTSLIST prior to running AUTHORIZE to make the mods. This was all hardcoded in the script (so I know I didn't just forget and fat-finger the process!)

I ran the command procedures to test this out, and saw a few problems that I corrected. Then I called it quits for the night.

Tried to log in this morning, and SSH was dead. I snuck in through the MP COnsole, and quickly found that TCPIP$AUX and TCPIP$SSH IDs were gone. And then I found quite a few others were missing, too! I got SSH going again, but now I'm really scratching my head...

Why didn't defining RIGHTSLIST to point to my scratch test area files do the job? I'm trying to figure out what I missed, not just so I can run another test, but so that when I do the task for real, it really works!

And incidentally, how can I restore the backup version of RightsList.dat that I've got? Just copy it back to the Sys$System dir as ;2 and reboot? I hate rebooting, but in this case, it looks like it might be the only recourse.

And yes, I was following the instructions in Appendix A of the OpenVMS Cluster Systems manual...

[Robert Gezelter]

Aaron,

Do you have more details? Did the same rightslist identifiers on the different systems have different values?

Which UAF(s) were actually being used by the different machines?

It is hard to diagose this from afar, I have seen different ways that this can happen.

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

[Hoff · Accepted solution]

Some stuff opens up the I/O channels to some the primary authentication files once up front, and then holds it open. Rightslist is one. It's also possible that there was a case where a logical name wasn't present for some operations, or when a privileged image is presented with a non-privileged logical name. With a copy of a file, the local copy and the non-trusted logical name would be silently skipped -- and you'd end up in the live file.

FWIW, some of the details on adding or removing nodes from a cluster are available here http://64.223.189.234/node/169
There are twenty-some files involved. Identifiers are among the most gnarly, as they get attacked all over.

And if one of the boxes here is an Itanium, ensure your TCP/P Services quotas are set sufficiently high, as the classic OpenVMS Alpha quotas are too low. A list is here http://64.223.189.234/node/141

You can reload the file as ;2, yes. Now as to what else might be skewed from what gets reloaded, that's hard to say. Testing this sort of system-level stuff on a live system -- particularly one where you hate rebooting, even seeking to redirect to other files -- would not be my first choice.

Stephen Hoffman
HoffmanLabs LLC

[Dean McGorrill]

Hi Aaron,
you can probably get yourself back
copying the files back. As bob said, you'll
have to see how common the sysuaf, rightslist etc are. esp do the have the same
uic style rightslist id. I've done it before, usually pick one system that has
the most users on it, make its files the
master if you will. then you can fetch
other users records, typically I'll do

sear/format=passall sysuaf.dat "USER1 ","USER2 "/out=sysuaf.temp
then conv/merge the temp file to the master
sysuaf. same for rightslist.

theres a lot of details that can be missed,
at one point I had some handy dcl scripts
to do the work that I have not been able to
find. hope this helps Dean

[Art Wiens]

Perhaps one way to avoid some of the pitfalls seen would be to do this operation on a test system running in a "MIN" mode so less of VMS is active?

Another idea might be if you could choose one of the rights files as "master" and put that in place as "live" on your test system, you might be able to do your assembly so that this file will be what you want it to look like in the end.

Cheers,
Art

[Aaron Sakovich]

I think Hoff pegged it -- if you look at the open files on Sys$SysDevice, RightsList.dat is held by a lot of processes, and I'm sure they picked up on my changes with the logical as it was defined when those processes were started. Changing the logical in my process had no effect on those open channels.

A couple additional data points: the 3 node cluster is a pure Itanium cluster. The system I did the testing on was a development host, and the only reason I'm averse to rebooting is due to the purist in me: it's VMS, and you shouldn't have to reboot in 99% of the cases. There's almost always a way to "fix" any problems without reboots that would cause lesser OS's to have to resort to a 3-finger salute...

This may fall into that 1% just from a convenience perspective for me. I could go back and manually recreate all the existing RIDs from the data in my saved file. Or reload the file and then restart the servers; we're talking about the security server, audit server, queue manager, and others holding this file open.

I'll probably just reboot.

Thanks folks!

[Robert Gezelter]

Aaron,

I would recommend, if for nothing else, attempting to restart those server processes manually.

Certainly, you can shut down and restart the queue manager.

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