Conference iosg::all-in-1_v30

3581.0. "Moving/Changing VMS names; effect on ACLs/PARTITION" by GANTRY::HULL (Digital Consulting [Delivery]/Motown) Wed Nov 24 1993 21:24

In a nutshell:

moving/renaming VMS accts under same A1 acct names as part of a system move
to a new site/hardware.

How to resolve all grief with Shared Drawers and PARTITION changes, etc??

The gory details:

Customer is running A1V3.0 (-1??).  They are moving the A1 system to a new
VAX at a new site which already has established users.  There is no A1
system there, so this is a MOVE not a MERGE.  500+ accounts to move.  They
did an install of a claen, unmodified A1 kit there so far.  So we can just
drop things like [.SITE...] into place...

In the process of moving the system, all the VMS acct names for the old
system are being renamed, and the new target directories for those A1 accts
will be placed on a different drive than the actual VMS acct, but the A1
usernames will stay the same. [intent is to eventually throw away A1, so
they want a simple "re-init the disk" scenario.]   For instance,

old:
A1name = HULL	 VMS = HULL  disk = DISK$1:[HULL.OA]
				sys$login = DISK$1:[HULL] (same tree)

A1name = HULL    VMS=HULL_AD disk = DISK$A1:[HULL_AD.OA]
				sys$login = usr$diskb:[hull_ad] (split locs.)

I have written some scripts to dump out all the current profile items that
we need to change as a text file.  Another script will go through and just
rewrite (write change) the profil fields VMSUSR, DIRECT and DELETE_FROM
with the new info.

Here's the MAJOR headache.  All the ACLs on ACCESS.DAT for the Shared
Drawers owned by these folks will be garbage after the move, since the
correct VMSnames won't exist.  I have a script to go through and clean out
PARTITION.  Then we'll run OAFC$PART_SEED.SCP to load the MAIN drawers up,
and I have yet another script to add in the (old) other drawer info
(non-MAIN).  But all the ACLs on the sharing info are toast.

SM MUA RNA (Rename Account) REQUIRES a new A1 username.  So I can't just
run that.  We have over 500 accts to process, so automation by script is
required.  Move deadline is 11-Dec (Sat).

CSC says if we do use RNA on the old system first, and just change the A1
name slightly (enough to make it a valid action), RNA should go through and
resolve ALL changes across the system.  And as long as the "new" VMS names
agree with the target system VMS names, the Identifiers on the ACLs will
synch up ok.  So apparently even if HULL = [320,4] on oldsys, and is
renamed to HULL_AD on oldsys, as long as HULL_AD text identifier value is
on the newsys, ACLs will still work, even if the UIC is now different. They
tried this out and said it does work.  But that still forces the customer
to manually run changes for over 500 users before even moving them.

When I tried to SEARCH all the OA$LIB:*RENAME*.* scripts/coms, I found NO
references to ACL-anything.  How does the system normally fix these up?

To avoid dealing with the ACL mess, customer says its okay with them to
just let the sharing info get lost and let the users reset them as needed
via menu options, etc.  That is the most expedient way.  But not a good
way.

What alternatives do we have?

	Al