Guidelines for merging two VMSECURE systems

Products

• VM:Secure for z/VM

Issue/Introduction

Guidelines for merging two VMSECURE systems.

 

Environment

Release : 3.2

Component : CA VM:Secure

Resolution

Guidelines For Merging Two VM:Secure Systems
-------------------------------------------------------------------
 
Because merging two VM:Secure systems is complex, no utilities exist to perform this function.  Each occurrence must be dealt
with on a case by case basis.
 
The following are guidelines for merging two systems.
 
This document makes the following assumptions:

 
1.  The EXACT SAME encryption is being used on both the 'old' system and the 'new' VM:Secure system.  This is imperative.
2.  VM:Secure 1B3 minidisk is not being used.
3.  VM:Secure Rules is being used.
4.  The NORULE record in the SECURITY CONFIG file is the same on both systems.
5.  There is one VM:Secure system that is going away (the 'old' system for the purpose of this document) and an existing 'new'
    VM:Secure system that will be increased in size to hold the userids/dasd/etc. from the old system.
 
 
 
1.  Merging the VM:Secure CONFIG files:
    
VM:Secure has five config files.  They are PRODUCT CONFIG, DASD CONFIG, SECURITY CONFIG, SFS CONFIG, AUTHORIZ
CONFIG.  All of these files are located on the VMSECURE 191 minidisk of both the 'old' and 'new' system.
 
    1A.  PRODUCT CONFIG - compare the two PRODUCT CONFIG files and decide what records you want to keep.
Decide if you want to use userexits used in the 'old' system on the 'new' system.  Do NOT change the DIRECT record on the 'new' system, if it is a functioning VM:Secure system.

    1B.  DASD CONFIG - compare the two DASD CONFIG files and decide what records you want to keep.
Do not delete any SUBPOOL records.  Determine what DASD will exist on the new VM:Secure system that you
want VM:Secure to manage and combine the DASD and EXTENT records into one file on the new system.

    1C.  AUTHORIZ CONFIG - compare the two DASD CONFIG files and decide what records you want to keep.
If you want to delete any userids from the 'old' system (that is you are not going to move these userids to the new system), then ensure that there are not any authorizations for the userids that will not be moved.

  1D.  SECURITY CONFIG - compare the two SECURITY CONFIG files and decide what records you want to keep.   

The NORULE record MUST be the same on both systems.     All ACIGROUP records must be merged (i.e. do not delete any).

    1E.  SFS CONFIG - keep the SFS CONFIG file on the system that will become the merged system.  Reenter all
         VM:Secure commands for the SFS authorizations on the system that is going away.  There is no way to manually
         XEDIT these files to combine them.

 
2.  VM:Secure Directory Maintenance of VM:Secure Minidisks:
   

Increase the size of the VM:Secure 1B0, 1B1, 1B2, 1B4 and 1D0 on the 'new' system to be large enough for the combined system.  Ensure that the 1B0 and 1B1 are not on the same pack.  Ensure that the 1B0 and 1B1 are both the same size and blocking factor.
 
3.  Deal with Userids on HOLD:
     
On the 'old' system, the VMSECURE 1B2 minidisk contains all userids that are on HOLD by VM:Secure.  Decide if you want   these userids moved from the 'old' VM:Secure system to the 'new' VM:Secure system.  If you want to move them, remove them from hold with the VM:Secure MANAGE command.

If you decide not to move the userids that are on HOLD, keep a list of the userids that will not be moved to the new system.
 
4.  Combine the VMSECURE MANAGERS File:
    
    On the VMSECURE 191 minidisk of both systems, there is a VMSECURE MANAGERS file.  These two files must be combined.
    We recommend that you do not delete any directory managers or skeletons or subpools.
 
If you have to delete any directory managers, the userids that they manage must be reassigned to another existing
VM:Secure directory manager FIRST, or VM:Secure will fail to initialize.

5.  Move the USEREXIT Source Code:    

The VMSECURE 191 minidisk contains any userexits that VM:Secure will use.  If needed, move userexits from the 'old' system to the  'new' system.
 
6.  Move all SKELETON Files:
    
The VMSECURE 191 minidisk contains any SKELETON files that VM:Secure uses.  Move all files with a filetype of SKELETON
from the VMSECURE 191 minidisk on the 'old' system to the VMSECURE 191 minidisk on the 'new' system.  If duplicate
skeleton files exist, decide which one will be used on the new system.
 
7.  Move the LOGMSG Files:

The VMSECURE 191 minidisk contains any LOGMSG files that VM:Secure uses.  Move all files with a filetype of LOGMSG
from the VMSECURE 191 minidisk on the 'old' system to the VMSECURE 191 minidisk on the 'new' system.

**  If there are no files with this filetype, do not be concerned.  These are not required.
 
8.  Deal with the VM:Secure Audit Data on the OLD System:
    
    Issue the VMSECURE AUDITEXT command to get the VMSECURE AUDIT data, if desired from the 'old' system.

9.  Merge the VM:Secure Source Directories:
    
    The VMSECURE 1B0 contains the source directory on both systems.  It contains the individual directory entries,
    directory profiles, etc.  End VM:Secure on the 'old' system.  LOGOFF VMSECURE and do not bring it up again.
    The reason for the END/LOGOFF is to ensure that no other directory maintenance is done.
 
Copy all of the files from the VMSECURE 1B0 minidisk on the 'old' system to the VMSECURE 1B0 minidisk on the 'new'
system.  If there are duplicate files, then you must determine what which one will be used or if the two duplicate userids can be combined.
 
 If there are files with duplicate filenames, one must be erased.  A filename is equal to a userid on the 1B0 and a
 userid cannot exist twice.  You can combine two directory entires into one, as long as a valid directory entry
 is created.  Bottom line:  there cannot be two files with the same userid on the 1B0, as this represents duplicate userids.
 
The filetypes of the userids on the 1B0 represents the VM:Secure directory manager userid that manages the userid.
All filetypes on the 1B0 MUST exist in the VMSECURE MANAGERS files, or VM:Secure will fail to initialize.
 
Keep a list of userids that are not moved from the 'old' to the 'new' system, if any.

 

10. Merge the VM:Secure Rules Database:
   

The VMSECURE 1B4 contains the VM:Secure RULES database.  Copy all of the files from the VMSECURE 1B4 minidisk on the
'old' system to the VMSECURE 1B4 minidisk on the 'new' system.  If there are duplicate files, decide which one should be deleted or if they should be combined.
 
Important note:  If there are any rules which refer to any userids that no longer exist, VM:Secure will fail to initialize.
Ensure that there are not rules that refer to a userid that no longer exists on the VMSECURE 1B0 minidisk.  The easiest way to do this is to use a tool that can perform a string search.  Search for all userids identified in steps 3 and 9 above.
 
11. Re-synch VM:Secure with the SFS Filepools:

If VM:Secure manages any filepools on either systems, it would be a good idea (not required) to run the RESYNCH
option on the new system after ALL source directory changes are made.  Use the VMSECURE CONFIG SFS command to do this.
    Then select option number 4.
 
    Note:  This is a very long running command and will tie up the issuer's userid for a period of time.