Migrating OpenVMS User Accounts Over to x86?

OpenVMS x86 Field Test questions, reports, and feedback.

Topic author
biri
Newbie
Posts: 3
Joined: Thu Jun 29, 2023 4:17 pm
Reputation: 0
Status: Offline

Migrating OpenVMS User Accounts Over to x86?

Post by biri » Wed Feb 07, 2024 1:00 pm

On my Itanium cluster I have a fairly long list of user accounts and groups (hundreds or maybe thousands?) and I'm wondering what would be the easiest, most straight forward way to migrate all of the AUTHORIZE user account/group data over to an x86 node.

The user directories are managed by a logical so I can point that over to some new storage disk on the VM, copy userdisk data etc with no issues. The tricky part is bringing over usernames, passwords, groups etc.

Anyone have any advice, tips, thoughts on what might be the best way to easily migrate that all over?

Maybe I can just flat out copy and paste some sort of AUTHORIZE file(s) or something? Then just copy the user disk files via FTP/SCP/DECNET or something?

User avatar

arne_v
Master
Posts: 347
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Online
Contact:

Re: Migrating OpenVMS User Accounts Over to x86?

Post by arne_v » Wed Feb 07, 2024 1:06 pm

I don't think there are any changes to file formats so you should be able to just copy SYSUAF.DAT and RIGHTSLIST.DAT over.

Added in 3 minutes 21 seconds:
If you want to truly recreate users then there were another thread about tools to access SYSUAF data.

The following Python could easily be extended to dump all relevant SYSUAF data:

Code: Select all

from vms.sysuaf import SYSUAF

uaf = SYSUAF('sys$system:sysuaf.dat')
for usr in uaf.fetchall(0):
    print('add %s /uic=[%o,%o] /dev=%s /dir=%s /wsext=%d /pgflq=%d' % (usr.username, usr.grp, usr.mem, usr.defdev, usr.defdir, usr.wsextent, usr.pgflquota))
Dump on Itanium to file, move file to x86-64 and run AUTHORIZE with file as input.
Arne
arne@vajhoej.dk
VMS user since 1986


Topic author
biri
Newbie
Posts: 3
Joined: Thu Jun 29, 2023 4:17 pm
Reputation: 0
Status: Offline

Re: Migrating OpenVMS User Accounts Over to x86?

Post by biri » Wed Feb 07, 2024 1:17 pm

Thank you, both solutions were exactly what I were looking for.
Probably I'll have go to with the scripted approach since there's already SAMBA accounts setup with their own IDs and such.

Thank you very much!
arne_v wrote:
Wed Feb 07, 2024 1:10 pm
I don't think there are any changes to file formats so you should be able to just copy SYSUAF.DAT and RIGHTSLIST.DAT over.

Added in 3 minutes 21 seconds:
If you want to truly recreate users then there were another thread about tools to access SYSUAF data.

The following Python could easily be extended to dump all relevant SYSUAF data:

Code: Select all

from vms.sysuaf import SYSUAF

uaf = SYSUAF('sys$system:sysuaf.dat')
for usr in uaf.fetchall(0):
    print('add %s /uic=[%o,%o] /dev=%s /dir=%s /wsext=%d /pgflq=%d' % (usr.username, usr.grp, usr.mem, usr.defdev, usr.defdir, usr.wsextent, usr.pgflquota))
Dump on Itanium to file, move file to x86-64 and run AUTHORIZE with file as input.

User avatar

m_detommaso
Valued Contributor
Posts: 75
Joined: Thu Jun 06, 2019 6:57 am
Reputation: 0
Location: Brindisi (Italy)
Status: Offline
Contact:

Re: Migrating OpenVMS User Accounts Over to x86?

Post by m_detommaso » Wed Feb 07, 2024 2:31 pm


Try taking a look at the procedure in the "VSI OpenVMS Cluster Systems" manual - Appendix B (pag 271):

https://docs.vmssoftware.com/docs/vsi-o ... ystems.pdf

I have always used it successfully even when I performed technological refresh projects of stand alone VMS systems.

/Maurizio

---
Appendix B. Building Common Files

This appendix provides guidelines for building a common user authorization file (UAF) from computer-specific files. It also describes merging RIGHTSLIST.DAT files.

B.1 Building a Common SYSUAF.DAT File

To build a common SYSUAF.DAT file, follow the steps in Table B–1.

1- Print a listing of SYSUAF.DAT on each computer. To print this listing, invoke AUTHORIZE and specify the AUTHORIZE command LIST as follows:

$ SET DEF SYS$SYSTEM
$ RUN AUTHORIZE
UAF> LIST/FULL [*,*]



2- Use the listings to compare the accounts from each computer. On the listings, mark any necessary changes. For example:

• Delete any accounts that you no longer need.
• Make sure that UICs are set appropriately:
• User UICs

Check each user account in the cluster to see whether it should have a unique user identification code UIC. For example, OpenVMS Cluster member VENUS may have a user account JONES that has the same UIC as user account SMITH on computer MARS. When computers VENUS and MARS are joined to form a cluster, accounts JONES and SMITH will exist in the cluster environment with the same UIC. If the UICs of these accounts are not differentiated, each user will have the same access rights to various objects in the cluster. In this case,you should assign each account a unique UIC.

• Group UICs

Make sure that accounts that perform the same type of work have the same group UIC. Accounts in a single-computer environment probably follow this convention. However, there may be groups of users on each computer that will perform the same work in the cluster but that have group UICs unique to their local computer. As a rule, the group UIC for any given work category should be the same on each computer in the cluster. For example, data entry accounts on VENUS should have the same group UIC as data entry accounts on MARS.

Note: If you change the UIC for a particular user, you should also change the owner UICs for that user's existing files and directories. You can use the DCL commands SET FILE and SET DIRECTORY to make these changes. These commands are described in detail in the VSI OpenVMS DCL Dictionary.


3- Choose the SYSUAF.DAT file from one of the computers to be a master SYSUAF.DAT. (in your case the sysuaf.dat of x86-64 box)


4- Merge the SYSUAF.DAT files from the other computers to the master SYSUAF.DAT by running the Convert utility (CONVERT) on the computer that owns the master SYSUAF.DAT. (See the OpenVMS Record Management Utilities Reference Manual for a description of CONVERT.) To use CONVERT to merge the files, each SYSUAF.DAT file must be accessible to the computer that is running CONVERT.

Syntax: To merge the UAFs into the master SYSUAF.DAT file, specify the CONVERT command in the following format:

$ CONVERT SYSUAF1,SYSUAF2,...SYSUAFn MASTER_SYSUAF

Note that if a given user name appears in more than one source file, only the first occurrence of that name appears in the merged file.

Example: The following command sequence example creates a new SYSUAF.DAT file from the combined contents of the two input files:

$ SET DEFAULT SYS$SYSTEM
$ CONVERT/MERGE [SYS1.SYSEXE]SYSUAF.DAT, -
_$ [SYS2.SYSEXE]SYSUAF.DAT SYSUAF.DAT


The CONVERT command in this example adds the records from the files [SYS1.SYSEXE]SYSUAF.DAT and [SYS2.SYSEXE]SYSUAF.DAT to the file SYSUAF.DAT on the local computer. After you run CONVERT, you have a master SYSUAF.DAT that contains records from the other SYSUAF.DAT files.

5- Use AUTHORIZE to modify the accounts in the master SYSUAF.DAT according to the changes you marked on the initial listings of the SYSUAF.DAT files from each computer.

...



B.2 Merging RIGHTSLIST.DAT Files

If you need to merge RIGHTSLIST.DAT files, you can use a command sequence like the following:

$ ACTIVE_RIGHTSLIST = F$PARSE("RIGHTSLIST","SYS$SYSTEM:.DAT")
$ CONVERT/SHARE/STAT ’ACTIVE_RIGHTSLIST’ RIGHTSLIST.NEW
$ CONVERT/MERGE/STAT/EXCEPTION=RIGHTSLIST_DUPLICATES.DAT -
_$ [SYS1.SYSEXE]RIGHTSLIST.DAT, [SYS2.SYSEXE]RIGHTSLIST.DAT RIGHTSLIST.NEW
$ DUMP/RECORD RIGHTSLIST_DUPLICATES.DAT
$ CONVERT/NOSORT/FAST/STAT RIGHTSLIST.NEW ’ACTIVE_RIGHTSLIST’


The commands in this example add the RIGHTSLIST.DAT files from two OpenVMS Cluster computers to the master RIGHTSLIST.DAT file in the current default directory. For detailed information about creating and maintaining RIGHTSLIST.DAT files, see the security guide for your system.


Topic author
biri
Newbie
Posts: 3
Joined: Thu Jun 29, 2023 4:17 pm
Reputation: 0
Status: Offline

Re: Migrating OpenVMS User Accounts Over to x86?

Post by biri » Wed Feb 07, 2024 3:53 pm

I tried running the Python Script but probably there's some sort of additional Python library/package/something that hasn't been installed yet. (Could have sworn I did though)

It complained about the import statement not being found/installed:

Code: Select all

from vms.sysuaf import SYSUAF
Interactively responds with:

Code: Select all

>>> from vms.sysuaf import SYSUAF
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'vms.sysuaf'
>>>
I have Python, Pip and PYTHWHEELS installed so not sure what's up.

As for the SYSUAF.DAT file, any advice for how to backup or copy the latest file in use by production without downtime? When I try to backup or copy the file, it responds with:

Code: Select all

$ backup $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5 SYSUAF.DAT;5
%BACKUP-E-OPENIN, error opening $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5 as input
-SYSTEM-W-ACCONFLICT, file access conflict
%BACKUP-W-NOFILES, no files selected from $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5
The only solution I can think of is to power down one of my cluster nodes, boot it up with the install disc, and copy the file that way to some other disk the node has access to (internal or SAN, whichever) -- but I'd really prefer not to resort to that method unless absolutely necessary.


sms
Master
Posts: 349
Joined: Fri Aug 21, 2020 5:18 pm
Reputation: 0
Status: Offline

Re: Migrating OpenVMS User Accounts Over to x86?

Post by sms » Wed Feb 07, 2024 5:33 pm

Code: Select all

> $ backup $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5 SYSUAF.DAT;5
> %BACKUP-E-OPENIN, error opening $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5 as input
> -SYSTEM-W-ACCONFLICT, file access conflict
> %BACKUP-W-NOFILES, no files selected from $1$DGA3:[SYS1.SYSCOMMON.][SYSEXE]SYSUAF.DAT;5

   See who's using the file (and guess how much trouble it might cause)?

      pipe show devi /file $1$DGA3: | search sys$pipe SYSUAF.DAT

   Add conflict tolerance to BACKUP?

      BACKUP /IGNORE=INTERLOCK

   HELP /MESSAGE ACCONFLICT suggests that that will make the conflict
less fatal.

        User Action:  None. However, the saved copy of the file may be
      inconsistent.

   So, make multiple copies, and see how inconsistent?
Last edited by sms on Wed Feb 07, 2024 5:36 pm, edited 2 times in total.

User avatar

arne_v
Master
Posts: 347
Joined: Fri Apr 17, 2020 7:31 pm
Reputation: 0
Location: Rhode Island, USA
Status: Online
Contact:

Re: Migrating OpenVMS User Accounts Over to x86?

Post by arne_v » Wed Feb 07, 2024 7:09 pm

biri wrote:
Wed Feb 07, 2024 3:53 pm
I tried running the Python Script but probably there's some sort of additional Python library/package/something that hasn't been installed yet. (Could have sworn I did though)

It complained about the import statement not being found/installed:

Code: Select all

from vms.sysuaf import SYSUAF
Interactively responds with:

Code: Select all

>>> from vms.sysuaf import SYSUAF
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'vms.sysuaf'
>>>
I have Python, Pip and PYTHWHEELS installed so not sure what's up.
I used a JFP Python build not a VSI Python build for testing that code. VSI must not have included that.
Arne
arne@vajhoej.dk
VMS user since 1986


craigberry
Contributor
Posts: 23
Joined: Fri Nov 17, 2023 11:27 am
Reputation: 1
Status: Offline

Re: Migrating OpenVMS User Accounts Over to x86?

Post by craigberry » Wed Feb 07, 2024 9:32 pm

When migrating from Alpha to Itanium in 2009, I used the Perl script below to take records from source uaf, rightslist, and mail profile files and merge them into target files. It use the VMS::IndexedFile extension which is available on CPAN at https://metacpan.org/release/BHUGHES/VM ... dFile-0_02 . You need to have the three files from your original system in the same directory as the script with "source_" in the name like so:

Code: Select all

source_sysuaf.dat
source_rightslist.dat
source_vmsmail_profile.data
Then define logical names for the target files like so (these should be up-to-date copies of the files on the target system):

Code: Select all

$ define target_sysuaf sys$disk:[]target_sysuaf.dat
$ define target_rightslist sys$disk:[]target_rightslist.dat
$ define target_vmsmail_profile sys$disk:[]target_vmsmail_profile.data
Then just run the script with:

Code: Select all

$ perl merge_user.pl
Then move the target files to their canonical names and locations. You can optionally pass a single username as a parameter to merge only that user. There is an `%exclude_list` hash in the script containing a list of account names to exclude from conversion; that should be modified to identify any users you do not want to bring over. Use at your own risk and test the results before deploying.

And the script itself:

Code: Select all

use strict;
use VMS::IndexedFile;

my (%uaf_source, %uaf_target, %rights_source, %rights_target, %mailpro_source, %mailpro_target);
my (%rights_source_by_id, %rights_source_by_holder);
my %exclude_list = ('APACHE$WWW'      => 1,
			'CML$SERVER'      => 1,
			'DCE$SERVER'      => 1,
			'DEFAULT'         => 1,
			'FIELD'           => 1,
			'IADMIN'      => 1,
			'IDE$SERVER'      => 1,
			'NET$MANAGE'      => 1,
			'SAMBA$GUEST'     => 1,
			'SAMBA$NMBD'      => 1,
			'SAMBA$SMBD'      => 1,
			'SAMBA$TMPLT'     => 1,
			'SYSTEM'          => 1,
			'SYSTEST'         => 1,
			'TCPIP$FTP'       => 1,
			'TCPIP$LPD'       => 1,
			'TCPIP$NTP'       => 1,
			'TCPIP$SNMP'      => 1,
			'TCPIP$SSH'       => 1,
			'TCPIP$TELNET'    => 1);



tie(%uaf_source, 'VMS::IndexedFile', 'source_sysuaf.dat', 0, O_RDONLY)
  or die "Can't open source SYSUAF file: $!\n";

tie(%uaf_target, 'VMS::IndexedFile', 'target_sysuaf', 0)
  or die "Can't open target SYSUAF file: $!\n";

tie(%rights_source, 'VMS::IndexedFile', 'source_rightslist.dat', 2, O_RDONLY)
  or die "Can't open source RIGHTSLIST file: $!\n";

tie(%rights_target, 'VMS::IndexedFile', 'target_rightslist', 2)
  or die "Can't open target RIGHTSLIST file: $!\n";

tie(%rights_source_by_id, 'VMS::IndexedFile', 'source_rightslist.dat', 0, O_RDONLY)
  or die "Can't open source RIGHTSLIST file by identifier: $!\n";

tie(%rights_source_by_holder, 'VMS::IndexedFile', 'source_rightslist.dat', 1, O_RDONLY)
  or die "Can't open source RIGHTSLIST file by holder: $!\n";

tie(%mailpro_source, 'VMS::IndexedFile', 'source_vmsmail_profile.data', 0, O_RDONLY)
  or die "Can't open source VMSMAIL_PROFILE file: $!\n";

tie(%mailpro_target, 'VMS::IndexedFile', 'target_vmsmail_profile', 0)
  or die "Can't open target VMSMAIL_PROFILE file: $!\n";

if (defined $ARGV[0] and length($ARGV[0])) {
    my $user = uc($ARGV[0]);
    do_merge($user);
}
else {
    for my $user (keys %uaf_source) {

        $user =~ s/\s+\z//;
        if (exists($exclude_list{$user})) {
            print "Skipping $user\n";
            next;
        }
        do_merge($user);
    }
}

untie(%uaf_source);
untie(%uaf_target);
untie(%rights_source);
untie(%rights_target);
untie(%rights_source_by_id);
untie(%rights_source_by_holder);
untie(%mailpro_source);
untie(%mailpro_target);

exit;


sub do_merge {
    my $user = shift;
    merge_rights($user);
    merge_mail_profile($user);
    $uaf_target{$user} = $uaf_source{$user};
}

sub merge_rights {
    my $user = shift;

    my $rights_record = $rights_source{$user};
    my $uic = substr($rights_record, 0, 4);
    my ($uid, $gid) = unpack("SS", $uic);
    printf "Merging %s [%04.4o,%04.4o]\n", $user, $gid, $uid;
    $rights_target{$user} = $rights_record;

    my $holder = pack("Ix4", unpack("I", $uic));
    my $rights = $rights_source_by_holder{$holder};
    my $next_holder = substr($rights, 8, 8);
    while ($next_holder eq $holder) {
        my $rights_name = substr($rights_source_by_id{substr($rights, 0, 4)}, 16, 32);
        print "$user also holds $rights_name\n";
##        $rights_target{$rights_name} = $rights_source{$rights_name};
##        $rights_target{''} = $rights unless already_got_it($rights_name, $holder);
        $rights = $rights_source_by_holder{''};
        $next_holder = substr($rights, 8, 8);
    }
}

sub merge_mail_profile {
    my $user = shift;

    my $mail_record = $mailpro_source{$user};

    return unless defined $mail_record;
    $mailpro_target{$user} = $mail_record;
}

sub already_got_it {
    my $rights_name = shift;
    my $holder = shift;

    my $got_it = 0;

    my $rights = $rights_target{$rights_name};
    my $rights_id = substr($rights, 0, 4);
    my $next_rights_id = $rights_id;
    while ($next_rights_id eq $rights_id) {

        $rights = $rights_target{''};
        if (substr($rights, 8, 8) eq $holder) {
            $got_it = 1;
            last;
        }
        $next_rights_id = substr($rights, 0, 4);
    }

    return $got_it;

}
Last edited by craigberry on Wed Feb 07, 2024 9:34 pm, edited 1 time in total.

User avatar

imiller
Master
Posts: 147
Joined: Fri Jun 28, 2019 8:45 am
Reputation: 0
Location: South Tyneside, UK
Status: Offline
Contact:

Re: Migrating OpenVMS User Accounts Over to x86?

Post by imiller » Thu Apr 04, 2024 9:55 am

copying a subset of users from one SYSUAF to another can be done simply enough in DCL.
Here's a bit of DCL I used recently

Code: Select all

$!
$! COPYUSERS - copy users in USERLIST.DATA from SYSUAF1 to SYSUAF2
$!
$ OPEN/READ/SHARE/ERROR=OU1 U1 SYSUAF1.DAT
$ OPEN/READ/WRITE/SHARE/ERROR=OU2 U2 SYSUAF2.DAT
$ OPEN/READ/ERROR=OUL ULIST USERLIST.DATA
$!
$L1:
$ READ/END=DONE/ERROR=RUERR ulist user
$ user = F$EDIT(user,"TRIM")
$ WRITE SYS$OUTPUT "Copying ''user'"
$ READ/KEY='user'/ERROR=RERR U1 urecord
$ WRITE/SYMBOL/ERROR=WERR U2 urecord
$ GOTO L1
$DONE:
$ CLOSE ulist
$ CLOSE U1
$ CLOSE U2
$END:
$ EXIT
$RERR:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error reading user ''user'"
$ WRITE SYS$ERROR F$MESSAGE(ss)
# GOTO L1
$WERR:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error writing user ''user'"
$ WRITE SYS$ERROR F$MESSAGE(ss)
$ GOTO L1
$RUERR:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error reading user list"
$ WRITE SYS$ERROR "''F$MESSAGE(ss)'"
$ GOTO DONE
$OU1:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error opening source SYSUAF"
$ EXIT 'ss'
$OU2:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error opening target SYSUAF"
$ EXIT 'ss'
$OUL:
$ ss = $STATUS
$ WRITE SYS$ERROR "Error opening user list"
$ EXIT 'ss'
Ian Miller
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].


craigberry
Contributor
Posts: 23
Joined: Fri Nov 17, 2023 11:27 am
Reputation: 1
Status: Offline

Re: Migrating OpenVMS User Accounts Over to x86?

Post by craigberry » Thu Apr 04, 2024 10:49 am

imiller wrote:
Thu Apr 04, 2024 9:55 am
copying a subset of users from one SYSUAF to another can be done simply enough in DCL.
Here's a bit of DCL I used recently
<snip>
That works more or less, but you then have missing identifiers and mail profiles, which may or may not have much of an impact depending on how those things were (or were not) being used.

Post Reply