Migrating OpenVMS User Accounts Over to x86?
Migrating OpenVMS User Accounts Over to x86?
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?
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?
-
- Senior Member
- Posts: 531
- Joined: Fri Apr 17, 2020 7:31 pm
- Reputation: 0
- Location: Rhode Island, USA
- Status: Offline
- Contact:
Re: Migrating OpenVMS User Accounts Over to x86?
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:
Dump on Itanium to file, move file to x86-64 and run AUTHORIZE with file as input.
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))
Re: Migrating OpenVMS User Accounts Over to x86?
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!
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 pmI 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:
Dump on Itanium to file, move file to x86-64 and run AUTHORIZE with file as input.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))
-
- Master
- Posts: 114
- Joined: Thu Jun 06, 2019 6:57 am
- Reputation: 1
- Location: Brindisi (Italy)
- Status: Offline
- Contact:
Re: Migrating OpenVMS User Accounts Over to x86?
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.
Re: Migrating OpenVMS User Accounts Over to x86?
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:
Interactively responds with:
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:
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.
It complained about the import statement not being found/installed:
Code: Select all
from vms.sysuaf import SYSUAF
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'
>>>
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
Re: Migrating OpenVMS User Accounts Over to x86?
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.
-
- Senior Member
- Posts: 531
- Joined: Fri Apr 17, 2020 7:31 pm
- Reputation: 0
- Location: Rhode Island, USA
- Status: Offline
- Contact:
Re: Migrating OpenVMS User Accounts Over to x86?
I used a JFP Python build not a VSI Python build for testing that code. VSI must not have included that.biri wrote: ↑Wed Feb 07, 2024 3:53 pmI 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:Interactively responds with:Code: Select all
from vms.sysuaf import SYSUAF
I have Python, Pip and PYTHWHEELS installed so not sure what's up.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' >>>
-
- Active Contributor
- Posts: 34
- Joined: Fri Nov 17, 2023 11:27 am
- Reputation: 1
- Status: Offline
Re: Migrating OpenVMS User Accounts Over to x86?
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:
Then define logical names for the target files like so (these should be up-to-date copies of the files on the target system):
Then just run the script with:
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
source_sysuaf.dat
source_rightslist.dat
source_vmsmail_profile.data
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
Code: Select all
$ perl merge_user.pl
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.
-
- Master
- Posts: 170
- 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?
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
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 ].
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
-
- Active Contributor
- Posts: 34
- Joined: Fri Nov 17, 2023 11:27 am
- Reputation: 1
- Status: Offline
Re: Migrating OpenVMS User Accounts Over to x86?
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.