| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2513.1 | dir/title="merge" | AIMTEC::BUTLER_T | | Thu Apr 01 1993 22:27 | 11 |
| While I am no expert, note 1449 in this conference looks like a good
place to start.
Also, doing a dir/title="merge" will give you lots of info.
While it deals with 2.4, Tony's book:" A Technical Odyssey " has
a good write-up starting on page 93.
HTH,
Tim
|
| 2513.2 | Things to watch for in v3.0? | RTOEU::RTOEU::DEGERTON | Dagmar Egerton @RTO, DTN 865-3553 | Fri Apr 16 1993 16:06 | 11 |
| Tony's book describes the process for merging ALL-IN-1 systems very well, but
as you said, it is for version 2.4 and under.
We are also looking at merging two systems here in Munich. What additional
things do we need to consider under ALL-IN-1 v3.0?
Does anyone have any experience with merging v3.0 systems?
Thanks for any help!
Dagmar
|
| 2513.3 | The author notes... | SIOG::T_REDMOND | Thoughts of an Idle Mind | Mon Apr 19 1993 19:20 | 34 |
| Well, I haven't had the chance to merge two V3.0 systems (yet), but it
strikes me that the three areas of most concern are:
-- Access Control
-- Groups
-- Rights held by various ALL-IN-1 accounts
-- ACLs on drawers
-- MAIL_ACCESS.DAT (SMU)
-- System Partition File
-- File Cabinet Server configurations
The other bits that were important in V2.* (SDAFs, etc.) are still to
the fore and shouldn't be forgotten.
If you have two V3.0 systems that have not yet implemented shared
drawers then the problems of ACLs and the Partition file might not be
too big. For instance, you could blow away the Partition file, merge
the profiles, and then reseed a new partition.
A system that has had widescale use of sharing is, of course, much more
difficult to deal with. I think the problems of fixing up the ACLs
have already been mentioned, and a fair case could be made for asking
users to reset the sharing on a drawer after the merge has been
performed. I think this would probably be easier in the long run than
attempting to match up all the identifiers within the ACLs, unless
you'd been very careful and had managed to arrive at a unique set of
UICs on both systems. I somehow doubt that this happens in the real
world.
Have fun,
Tony
|
| 2513.4 | Has anyone merged two V3 systems yet? | GIDDAY::JOYCE | Okay, who moved the goalposts? | Mon Nov 08 1993 01:57 | 20 |
|
Has anyone actually done (or attempted to do) a merge between to V3.0 systems
yet?
It seems to me that PARTITION is not the problem - I'm assuming that it can be
$CONVERT/MERGEd (taking care of duplicates of course) and a script written to
fix up the DIRECTORY field if the disk names have changed.
I see the main problem, as Tony has pointed out, being the rights identifiers
and ACLs which are now used extensively through ALL-IN-1 (Drawers, groups etc.)
- Is it possible to merge the two SYSUAF and rights database files I wonder
(again, taking care of duplicates)? I suspect that there will be too many
clashs of UICS and rights id numeric values for this to be practical. Does
anyone has any other suggestions?
Are there any other pitfalls I should be aware of?
Thanks, Andy
|
| 2513.5 | Merge V3 systems - some ideas... | GIDDAY::JOYCE | Okay, who moved the goalposts? | Wed Nov 10 1993 01:34 | 113 |
|
Okay, here's some ideas for doing the merge. PLEASE give feedback...
First off, the majority of the merge is as it was for V2.4 and is therefore
adequately covered in Tony's book (ALL-IN-1: A Technical Odyssey. EY-H952E-DP).
I regard the problem areas of V3.0 as;
1) PARTITION.DAT
2) Drawer access
3) Groups
4) Mail access
I'll take these in turn;
1) PARTITION.DAT
As I see it this is simply another RMS fixed-length indexed file and as
such can be $CONVERT/MERGED. Prior to this checking has to be done (as
with any other datafile being merged e.g. PROFILE.DAT) for duplicates.
If a drawer with the same UNIQUE_NAME exists on both systems then
PRIOR to the merge one has to be "renamed" - the easiest way to do this
is to create another drawer, then copy the whole directory structure
and files from the old drawer to the new (use $BACKUP).
Obviously sharers of the drawer will need to be informed that this
has taken place.
Another issue with drawers (As with PROFILE) is that it is unlikely
that the drawer will reside on a disk with the same name when it is
moved/merged onto the target system. Device-independent logicals *may*
have been used in which case we're okay but if not then the DIRECTORY
field of PARTITION will have to be changed. I would do this immediately
PRIOR to the merge (after my system backup!) with a script along these
lines...
FOR PARTITION WITH .DIRECTORY = "DUA1:" DO -
GET #DIR = FN$ELEMENT(1,":",.DIRECTORY) \\ -
GET #NEW = "DUA2:" #DIR \\-
WRITE CHANGE PARTITION %KEY=.%KEY,DIRECTORY=#NEW
Same again for other disks...
2) Drawer access
User's uics (and possibly) VMS usernames may have to change if there
are duplicates. This will result in the rights identifiers used in
ACLs on drawers/documents no longer being valid.
There are likely to be far to many drawers/documents to manually fix
up and I don't believe that you can expect users to re-grant access to
their drawers after the merge as has been suggested; what will happen
if the owner/controller of a business critical drawer is not available
on the day after the merge?
I think the way to go (although I haven't figured out the details yet)
is as follows;
i) PRIOR to the merge, for each drawer, create a file containing
each sharers access keyed on the ALL-IN-1 username or Group.
(This could be done by cannablising the script used by the
Edit Drawer Access option - OA$DO:FC_SIMPLE_SHARE.SCP)
ii) Do the merge - fixing up duplicate UICs/VMS usernames etc.
iii) Fix up groups as described in 3) below.
iv) For each drawer, run a tool (also created from
FC_SIMPLE_SHARE.SCP) that reads the files created in step i)
and re-grants the ACLs using the correct identifer for the
given ALL-IN-1 user/Group.
3) Groups
As you all know an ALL-IN-1 Group has a system generated rights
identifier of the form OA$G_Zxxxxxxxx associated with it. Each member
of the group (or a subgroup) will have this id granted in their UAF
entry. The Zxxxxxxxx part is system generated from the system date and
therefore stands a good chance of being unique over both systems.
However, the hexidecimal value of the ids in generated sequentially by
the system starting at %X80010001. It is therefore inevitable that
these will clash.
Details of the group members are stored in a datafile,
OA$GROUP_SHARE:OA$G_Zxxxxxxxx.DAT keyed on their ALL-IN-1 user/group
name.
The OA$G_Zxxxxxxxx ids should not be transferred to the target system.
After the merge, new ids (same OA$G* names, different numeric values)
should be generated for these ids. A script/com file could be written
to automate this (possibly based on a list generated BEFORE the merge).
Then, the ids need to be revoked/re-granted to the members of the
group (listed in the file mentioned above). Possibly one of the GROUP
functions could do this?
Obviously, care would need to be taken to deal with duplicate Group
names - in some cases these groups should themselves be merged.
4) Mail access
The access to a user's mail account (Grant Mail Access/Set Mail User)
is controlled by an ACL on a file MAIL_ACCESS.DAT in the user's MAIN
drawer - this is very similar to how drawer access is controlled and
the merge issues are the same. Thus, a similar appraoch to that used
in 2) above could be used.
Any comments? I have a large customer waiting to be told how to do this...
Andy
|
| 2513.6 | Merging V3 systems - some guidelines | GIDDAY::JOYCE | Okay, who moved the goalposts? | Mon Dec 20 1993 01:08 | 225 |
|
What follows is our response to the customer concerning merging two
IOS V3 systems. It is a set of very loose guidelines ONLY and has not
been tested.
As I say numerous times in our response this is not supported. The
supported method is to transfer the users from one system to the other
using the options provided.
Unbeknown to us the customer was actually transferring users for two
weeks while we were working on the solution - nice of him to tell us!
So, for what it's worth, here it is... (feel free to pick holes etc.)
(Thanks to Martin Cook and Caroline Croft for all their help)
Andy
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Peter,
Thank you for your enquiry on how to merge two ALL-IN-1 IOS V3.0
Systems. After considerable research into this matter I have the
following answer for you.
The SUPPORTED way to "merge" two ALL-IN-1 IOS V3 systems is to transfer
the users from one system to the other using the following options
which can be found under the ALL-IN-1 Manager's MUA (Manage User
Accounts) menu;
PTN Prepare account copy for transfer over the network
PTT Prepare account copy for transfer by tape
CSN Copy account onto system over the network
CST Copy account onto system from tape
DAC Delete account copy from transfer area
This procedure is fully documented in Chapter 8 of the ALL-IN-1
Management Guide.
As you are aware there are some drawbacks with this method. These
include;
* the time involved to transfer the accounts
* the potential increase in disk usage
* membership of groups and access to drawers is lost
As you have stated you are considering "merging" the two systems.
While this has significant advantages over transferring the users, it
is NOT SUPPORTED by Digital. Merging V2.3 and V2.4 systems has been
successfully done and is documented in such places as Tony Redmond's
book "ALL-IN-1: A Technical Odyssey". However, I reiterate that this
process is NOT SUPPORTED by Digital.
As far as I have been able to ascertain, to date, merging of two V3.0
systems has been attempted only once. As a result, there no definitive
proven method exists as there does with V2.3 and V2.4. The documented
methods for these versions can be adapted for merging V3.0 systems;
however, there are additional considerations with a V3.0 system such as
drawer access and group membership. Once again, this is NOT SUPPORTED
by Digital.
If you wish to proceed with a merge of your two ALL-IN-1 IOS V3.0
systems, any problems that may occur as a result can only be addressed
by Digital Customer Support Centre on a paid consultancy basis.
However, we wish you success with this venture and submit the following
V3.0-specific guidelines to assist you.
PLEASE NOTE THESE HAVE NOT BEEN FULLY TESTED AND ARE UNSUPPORTED BY
DIGITAL.
* User accounts
There are two ways to merge the user accounts. In both cases it is
important to resolve any username duplicates prior to the upgrade by
renaming one of the accounts.
* If there are a large number of duplicate UICs then it is best to
create new VMS/ALL-IN-1 accounts on the target system (System-A)
for users on the disappearing system (System-B). If possible try
to create these all on the same disk as it will make the task of
updating the System Partition file (Drawers) easier.
* If there are NOT a significant number of UIC duplicates then the
PROFILE.DAT files can be merged using the DCL CONVERT utility.
Prior to this, duplicate ALL-IN-1 usernames (such as A1$SCRIPT,
MANAGER, POSTMASTER and X400) should be removed from PROFILE.DAT
on System-B. The disk name will also have to be updated for the
ex-System-B users to reflect their new location on System-A. It
may be easiest to do this immediately prior to the merge if there
are duplicate disk names on the two systems. This could be
achieved using ALL-IN-1 Script or DATATRIEVE. New VMS accounts
will have to be created on System-A for the System-B users. This
could be done manually, using a DCL command procedure generated
from the System-B PROFILE or by merging the SYSUAF files. Disk
quota entries will also have to be merged.
* Drawers/System Partition
The datafile OA$DATA:PARTITION.DAT contains details of every drawer
on the system. These details include the VMS directory where the
drawer's files can be found.
The PARTITION.DAT files are RMS indexed files are can be merged
using the DCL CONVERT utility. However the following need to be
considered;
* Resolve any duplicate drawer names ([username]drawer) prior to
the merge. (e.g. remove [MANAGER]MAIN from PARTITION B)
* If you have created new accounts on System-A for System-B users
then remove the MAIN drawer entries for those users from
PARTITION B prior to the merge. Any other drawers owned by those
users can be left as they will not exist in PARTITION A.
* The DIRECTORY field of PARTITION should be updated to reflect the
new disk location of the System-B users on System-A. It may be
best to do this immediately prior to the merge. This could be
achieved using ALL-IN-1 Script or DATATRIEVE.
* Drawer/Document access
Drawer access is controlled by ACLs on a file ACCESS.DAT in the
drawer subdirectory. These ACLs use VMS rights identifiers which
are either the users' VMS account names OR resource ids allocated
for groups (OA$G_Zxxxxxxxx). In the process of moving from one
system to another and potentially changing UICs or numeric value
these ids and therefore the ACL's could become "corrupted" or lost.
One method of preserving drawer/document access is as follows;
* Create a DCL command procedure/ALL-IN-1 script that loops through
the System-B PARTITION and for each drawer records the ACL set on
the ACCESS.DAT and DOC0.DIR files. For ADVANCED shared drawers,
you would also have to record the ACL set on each .WPL file
(document).
* Create a DCL command procedure that reads this file and reapplies
the ACLs appropriately (the ACL on DOC0.DIR will have to be
applied to all DOCn.DIR and MSG.DIR sub-directories). You would
run this on System-A AFTER the user accounts have been moved.
* In the System-A ALL-IN-1 Manager account, create a UDP which
loops through all REGULAR shared drawers and does an "Edit drawer
access". Don't change any access details but do a GOLD FILE to
exit the Edit Drawer Access screen. This reads the ACL on the
ACCESS.DAT and DOC0.DIR and reapplies it to all .WPL files
(documents) in the drawer sub-directories. As this uses an image
it is faster than doing it using DCL. This should be done for
REGULAR shared drawers only as in ADVANCED shared drawers each in
.WPL file may have a different ACL. Reapplying these ACLS should
be done by the DCL command procedure created in the previous
step.
* File Cabinet Server configuration/tuning
Ensure that your File Cabinet Servers on System-A are adequately
configured to cope with the additional users. See Chapters 9 and 15
in the ALL-IN-1 Management Guide. You may wish to create an
additional server on each node.
* Groups
As ALL-IN-1 Groups depend largely on system generated rights
identifiers, and these ids have numeric values which are allocated
sequentially starting from %X80010008 it is inevitable that these
will clash. Duplicate group names should be resolved before the
merge.
Write a script (to be run on System-B) which does the following;
* Loops through the Groups dataset, GROUPS$MASTER, and records the
name, id name (OA$G_Zxxxxxxxx) and description of each group.
* Records the members of each group.
* Removes the members from the group.
Write a script (to be run on System-A AFTER the user accounts
have been merged) which reads this file and does the following;
* Re-creates the group (this will generated a new unique id).
* Re-adds the members to the group.
This may have to be an iterative process to cope with sub-groups.
You can use the GROUP set of functions documented in the ALL-IN-1
Application Programmers Reference Manual Volume II,
p310-317.
NOTE: The Groups should be re-built BEFORE drawer access is
re-granted.
* Mail access
In V3.0 it is possible for a user to grant another user, users or
group permission to read and process his mail and (optionally) also
send mail on his behalf. This is controlled by an ACL on the file
MAIL_ACCESS.DAT in the user's ALL-IN-1 directory. As with drawer
access this ACL will probably be invalidated by the merge and a
similar approach could be taken to resetting it once the user
accounts have merged (i.e. write a DCL command procedure to reset
the ACLs based on a list created prior to the merge).
I hope that this information will be of use to you. Once again I
reiterate that these guidelines have not been tested and are NOT
SUPPORTED by Digital, and are given to you with NO COMMITMENT from
Digital that they will work. We would of course like to know how you
get on.
Good Luck!
Andy Joyce
Customer Support Centre
Digital Equipment Corporation (Australia) Pty. Ltd.
|
| 2513.7 | Has anybody merged two v3.0 systems | STKAI2::HAGBERG | | Wed Apr 06 1994 09:47 | 13 |
| Hello
I'm about to merge two ALL-IN-1 v3.0A systems and I wonder if
there is anyone who actually has done a merge yet?
If you have, please let me know if you discovered some
problems that isn't described in .6 ,and thats different from
a v2.4 merge.
Regards,
P�r Hagberg
IS Stockholm
|
| 2513.8 | TLC? | AIMTEC::WICKS_A | Atlanta's Most (In)famous Welshman | Wed Apr 06 1994 17:35 | 7 |
| Par,
is this a plain v3.0A system or one with the TLC on?
regards,
Andrew.D.wicks
|
| 2513.9 | TLC!! | STKAI2::HAGBERG | | Fri Apr 08 1994 08:48 | 7 |
| Hello Andrew
Yes TLC is installed on both of our systems,
will that make it more difficult merge?
regards,
P�r
|
| 2513.10 | You tell me! | AIMTEC::WICKS_A | Atlanta's Most (In)famous Welshman | Fri Apr 08 1994 15:29 | 11 |
| par,
I don't know you asked whether the earlier guidelines were applicable
and they covered release up to v3.0-1. you may be the first person
to merge v3.0A so the AIDA server is one other thing to look out
for. keep an eye on the aIDA config file, the MNQ file and the OA$AIDA
images out on the system disk and let us know what happens.
regards,
Andrew.D.Wicks
|