User(s) transfer from 7.2 to 8.3

[Niall76]

Hi,

We are in the process of going from OpenVMS 7.2 to 8.3. Rather than having to create all new users again on 8.3, is it possible to copy over all the users (or selected users) to the new OpenVMS 8.3 system?

Regards and Thanks,
Niall

[Kris Clippeleyr · Accepted solution]

Hi,
You're talking about 2 separate systems?
If so, you could just copy the SYSUAF file from the 7.2 system to the 8.3 one; or if you have to selectively move the user accounts, have a look at QUAI (to be found on our website: http://www.quadratrix.be/quai.html )

Greetz,
Kris (aka Qkcl)

[Ian Miller.]

copy the SYSUAF and the RIGHTSLIST - no compatibility issues.

Take the opportunity to rationalise.

[Jan van den Ende]

Niall,

>>>
We are in the process of going from OpenVMS 7.2 to 8.3.
<<<

As in, UPGRADE or NEW INSTALLATION ?

If upgrade, you are there already. Well, nearly. Carefully read through the Release Notes for any instruction for new minimum values, then check and, if necessary, adjust. It usually pays to regard MINIMUM as scrappy, and be a bit more generous.

If new install, like Ian said, just copy.
But that is only one part.
You also have to get the user directories in place, with the right ownership and protection.
Best, and least error-prone, method would be to restore (BACKUP/OWN=ORIG) the thevice that held the user dirs of the old system.
( keep an eye on optimising the device params. First INITing with params more approprite to modern device, like /CLUSTER=(multiple of 16), and then BACKUP/NOINIT)

hth

Proost.

Have one on me.

jpe

[Craig A Berry]

If you copy SYSUAF.DAT and RIGHTSLIST.DAT, you'll also potentially need VMSMAIL_PROFILE.DATA and NETPROXY.DAT, depending on whether you use those on your old system.

There are potential gotchas to either merging records or copying the files in toto.

Be careful not to clobber accounts on the new system that you may need. For example, if the new system is already up and running and you're using TCP/IP Services to telnet in, then you probably have a TCPIP$TELNET account that was automatically created when you enabled the service. If you have such an account on the old system, it may not have appropriate quotas or the correct (auto-generated) UIC to function on the new system. If you don't have such an account on the old system, a complete copy of SYSUAF.DAT effectively removes the account from the new system. Any software you've installed on the new system might have one or more associated accounts that could run into the same problem.

When we moved from Alpha v7.1 to Itanium v8.3-1H1 about a year and a half ago, I dealt with this by writing a Perl script that merged records but maintained an exclusion list specific to our environment so the relevant accounts on the target system would not be touched. The advantage of a merge rather than copy was that I could do a preliminary conversion for testing and then a final merge that picked up any new or changed accounts.

Be sure to rethink quotas. The DEFAULT account on your new system probably comes with quotas that are too small. If you replace it with the DEFAULT account from the old system, then the quotas will be really, really too small. Each new account you create on the new system will then inherit the tiny quotas from the old system. And all the existing account quotas that you move across may need revisiting. I handled this by creating a template account and then writing a program that upgrades quotas on a target account based on the template. The program is available here:

http://labs.hoffmanlabs.com/node/49#comment-1654

QUAI looks interesting, especially if you're just migrated a small number of selected accounts. Wish I'd known about it.

I also made extensive use of Joe Meadows' UAF utility. It doesn't merge anything but is very useful for rooting around and seeing what you've got. You may find you have some accounts that you really don't want to bring forward to the new system, or you may find accounts that are in active use that you didn't know you had and might otherwise miss in the migration. I recently updated UAF and made it available at:

http://code.google.com/p/jmuaf/

[John Gillings]

Niall,

The files are compatible. Make sure you check ALL the system "personality" files, and consider interdependencies (like SYSUAF and RIGHTSLIST). See SYLOGICALS.TEMPLATE for the most complete list.

One thing to beware of when migrating UAFs between systems - changes over time in quota costs and requirements. Too often UAFs which were compiled in the dim and distant past have quotas which were appropriate at the time, but have gone out of date.

For example, a UAF originating on a small VAX in the early 1990's now in use on a modern Itanium system with orders of magnitude more resources, may unnecessarily constrain users with inappropriatly small WSQUOTA and/or PGFLQUOTA.

It's worth dumping out a UAF list and eyeballing the quotas to see if anything needs increasing for the new environment.

[Andy Bustamante]

Upgrade or new installation?

An upgrade will preserve your existing user files. You could also restore a backup of your present system and upgrade in place to 8.3, assuming your're going from Alphaserver to Alphaserver.

[Robert Gezelter]

Niall76,

In essence I agree with John.

For sites with more than a handful of accounts, I tend to move the existing UAF, RIGHTSLIST, and other files to the new system. However, I save the corresponding files created during the installation process and verify that the automatically created accounts are either the same on both systems, or the quotas have been updated to the new values.

(Note to OpenVMS Engineering: It would be a good idea for the various startup scripts to verify quotas and related settings and issuing appropriate messages, rather than creating obscurities at later points.)

When necessary, I use command procedures that from a UAF listing to bring quotas up to date using the AUTHORIZE MODIFY command.

Temporarily, one can use process minimums on a system-wide basis, but there are dangers in that approach.

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

[John Gillings]

Bob,

> Note to OpenVMS Engineering

I've been trying for years to convince OpenVMS Engineering that OpenVMS should have a lot of sanity checks on reboot. Things like cluster configuration, queue configuration, quotas, etc... so many things that can be silently wrong until the worst possible time, and would be so trivially easy to check.

Big bruise in middle of forehead from banging my head against that brick wall.

I suppose it keeps support folk in jobs :-(

[Shriniketan Bhagwat]

Hi,

Along with the above recomendations from others, refer the below link for upgrading/installing the V8.3 OS.


http://h71000.www7.hp.com/doc/83final/ba322_90045/ch01s06.html


Regards,
Ketan