Moving a VOB from Windows® to Linux or the UNIX system

About this task

In the following procedure to move a VOB from Windows® to Linux or the UNIX system:
  • The current (source) location of the VOB storage directory to be moved is C:\VersionVaultStorage\libpub.vbs on Windows® host vobsvr-nt. The VOB tag for this VOB is \libpub.
  • The new (target) location for the VOB storage directory is /vobstg/libpub.vbs on the host running Linux or the UNIX system, vobsvr2. VOB tag /vobs/libpub is created for this VOB.
Note:
This procedure entails use of the reformatvob command, which updates the database schema version.

Procedure

  1. Log on to the Windows® VOB server host as the VOB owner or privileged user.
  2. Lock the VOB.
    This ensures that no new VOB objects are created while you complete Step 4.
  3. Unmount the VOB from the current host and ask all clients to unmount it.
  4. Generate a SID file that lists the names of users and groups associated with objects in \libpub.
    Run the vob_siddump utility as shown in this example:

    versionvault-home-dir\etc\utils\vob_siddump –raw_sid \libpub C:\VersionVaultStorage\libpub.vbs\libpub.csv  

    Create the SID file in the VOB storage directory so that it is available on the new VOB host after the storage directory is moved. You need the SID file in Step 17.
  5. Dump the VOB database.
    Use the cleartool reformatvob command:

    cleartool reformatvob –dump C:\VersionVaultStorage\libpub.vbs

    reformatvob –dump marks the VOB database as not valid. It cannot be used until it is processed by a reformatvob –load command.
  6. Remove the VOB tag (rmtag -vob) and unregister the VOB (unregister -vob).
  7. Copy the VOB storage directory.
    Use any file system copy utility to copy the entire VOB storage directory to the host running Linux or the UNIX system. This example assumes that the target host vobsvr2 is running an SMB server and has shared its \vobstg partition.

    C:\VersionVaultStorage\VOBs> net use E: \\vobsvr2\vobstg
    C:\VersionVaultStorage\VOBs> xcopy libpub.vbs E:\libpub.vbs /s

    Note: Because ACLs are not supported on hosts running Linux or the UNIX system, you may use xcopy or another copy utility that does not preserve ACLs for this step.
  8. Restart HCL VersionVault on the Windows® VOB server host
    (\\vobsvr-nt in our example). You do not need to rename the old VOB storage directory first. It has been dumped and is no longer accessible.
  9. Log on to the VOB server host that runs Linux or the UNIX system.
  10. Update VOB owner identity information.
    Use the fix_prot utility as shown here to create a new .identity directory for the VOB. (You must be root to run fix_prot in this way.) This example sets the VOB's owner to vobadm and the VOB's primary group to ccusers:

    versionvault-home-dir/etc/utils/fix_prot –root –recurse –chown vobadm –chgrp ccusers /vobstg/libpub.vbs

  11. Re-create the VOB database from the dump files.

    # cleartool reformatvob –load /vobstg/libpub.vbs

  12. Replace the VOB object and tag with new ones that reference the new VOB storage directory.
    Use the HCL VersionVault Administration Console or the following commands:

    cleartool register –vob –replace /net/vobsvr2/vobstg/libpub.vbs

    cleartool mktag –vob –replace –tag /vobs/libpub /net/vobsvr2/vobstg/libpub.vbs

  13. Create a map file.
    Open the SID file generated in Step 4 (/vobstg/libpub.vbs/libpub.csv). It might be easier to edit this file if you use a spreadsheet program that can read the comma-separated-value format. This example shows one line of such a file. It includes a header row for clarity. The SID string has been truncated to save space.
    Old-name Type Old-SID New-name Type New-SID Count
    OLD\akp USER SID:3.0105037... IGNORE USER 137
    For each line in the file, replace the string IGNORE in the New-name field, with a user or group name that is valid on the new VOB server host; then delete the last three fields (Type, New-SID, and Count).
    Old-name Type Old-SID New-name Type New-SID Count
    OLD\akp USER SID:3.0105037... akp
    Although this example shows a user name that is the same on Linux or the UNIX system as it was on Windows®, the procedure can also be used to map a Windows® user or group name to a different user or group name on Linux or the UNIX system. After you edit all the rows of the SID file, save it as a comma-separated-value file and use it as the mapping file required when you run vob_sidwalk –map. Each line of the mapping file must have exactly four fields, separated by commas. The example row created in this step looks like this in CSV format:

    OLD\akp,USER,SID:3.0105037...,akp

    Note: You can reassign ownership of any object in a VOB to the VOB owner by placing the string DELETE in the New-name field. You may also reassign ownership of all objects in a VOB to the VOB owner without creating a mapping file. See Reassigning ownership to the VOB owner.
  14. Test the map file.
    Run vob_sidwalk without the –execute option. The list of mappings in the file libpub-map.csv is written to the SID file (libpub-test.csv in this example), but no changes are made to the VOB.

    versionvault-home-dir/etc/utils/vob_sidwalk –map /vobstg/libpub.vbs/libpub-map.csv /vobs/libpub /libpub-test.csv

  15. Unlock the VOB if it is still locked.
    If you are concerned that users may try to access the VOB before you complete this procedure, lock the VOB again for all users except yourself (cleartool lock –nusers you).
  16. Update user and group identities stored in the VOB.
    When you are satisfied that the map file is correct, run vob_sidwalk. In this example, libpub-map.csv is the map file created in Step 13:

    versionvault-home-dir/etc/utils/vob_sidwalk –execute –map /vobstg/libpub.vbs/libpub-map.csv /vobs/libpub /libpub-exec.csv

    vob_sidwalk makes the changes specified in the map file and records the changes that were made in a new SID file, libpub-exec.csv.
  17. Update the VOB's group list and container protections.
    Run vob_sidwalk with the –recover_filesystem option:

    versionvault-home-dir/etc/utils/vob_sidwalk –recover_filesystem /vobs/libpub recov.csv

    vob_sidwalk logs changes made during this step to the file recov.csv
  18. Verify that all clients can access the VOB at the new location.
    Unlock the VOB if it is still locked.
  19. Verify that all HCL VersionVault users in the new domain can access objects in the VOB.
    Users must be able to create new objects and change or remove objects they own.