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

Before you begin

If the VOB has remote storage pools, you must first consolidate those pools under the VOB root directory. Symbolic links that are supported on Linux or the UNIX system are not supported on Windows®, so the entire VOB storage directory must reside on a single partition on the Windows® host. See Consolidating remote pools for the procedure.
Note:
This procedure entails use of the reformatvob command, which updates the database schema version.

About this task

To move a VOB from Linux or the UNIX system to Windows®:
  • The current location of the VOB storage directory to be moved, on the source host running Linux or the UNIX system, is /vobstg/libpub.vbs,vobsvr2. The VOB tag for this VOB is /vobs/libpub.
  • The new location of the VOB storage directory, on the target host, is C:\VersionVaultStorage\VOBs\libpub.vbs on the Windows® host vobsvr-nt. The VOB tag \libpub is created for this VOB.

Procedure

  1. Log on to the Linux or the UNIX system or Windows ® VOB server host as the VOB owner or privileged user.
  2. Lock the VOB.
    No new VOB objects can be created while you complete Step 3.
  3. Generate a SID file that lists the names and UIDs/GIDs of users and groups associated with objects in /vobs/libpub.
    Run vob_siddump utility as shown in this example:

    versionvault-home-dir/etc/utils/vob_siddump /vobs/libpub /vobstg/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 will need this file in Step 15.
  4. Dump the VOB database.
    Use the cleartool reformatvob command:

    cleartool reformatvob -dump /vobstg/libpub.vbs

    reformatvob -dump marks the VOB database as not valid. It cannot be used until it is processed by a reformatvob -load command.
  5. Copy the VOB storage directory.
    Use any file-system copy utility to copy the entire VOB storage directory to the Windows® host. This example assumes that the host vobsvr2 is running an SMB server and has shared its \vobstg partition. On the Windows® host, run these commands:

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

    Note: Because ACLs are not supported on hosts running Linux or the UNIX system, you can use xcopy or another copy utility that does not preserve ACLs for this step.
  6. Restart HCL VersionVault on the VOB server host.
    You do not need to rename the old VOB storage directory first. It has been dumped and is no longer accessible.
  7. Fix the VOB storage directory protections.
    Log in to the Windows® VOB server host as the VOB owner of \libpub or as a privileged user and run the fix_prot utility. In this example, vobadm is the name of the new VOB owner, ccusers is the name of the VOB's new principal group, and C:\VersionVaultStorage\VOBs\libpub.vbs is the host-local pathname of the VOB storage directory:

    versionvault-home-dir\etc\utils\fix_prot -root -r -chown vobadm -chgrp ccusers C:\VersionVaultStorage\VOBs\libpub.vbs

  8. Re-create the VOB database from the dump files.
    Use the cleartool reformatvob command:

    cleartool reformatvob -load C:\VersionVaultStorage\VOBs\libpub.vbs

  9. 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 (which assume that C:\VersionVaultStorage is shared as \\vobsvr-nt\VersionVaultStorage):

    cleartool register -vob -replace \\vobsvr-nt\VersionVaultStorage\VOBs\libpub.vbs cleartool mktag -vob -tag \libpub \\vobsvr-nt\VersionVaultStorage\VOBs\libpub.vbs

  10. Lock the VOB.
    Although the VOB is now registered and has a tag, it cannot be used until you complete this procedure. If you are concerned that users might try to access the VOB before it is ready, lock it now.
  11. Create a map file.
    Open the SID file generated in Step 3 of this procedure (\\vobsvr-nt\VersionVaultStorage\VOBs\libpub.vbs\libpub.csv). It may 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.
    Old-name Type Old-SID New-name Type New-SID Count
    akp USER UNIX®:UID-1247 IGNORE USER 137
    For each line in the file, replace the string IGNORE in the New-name field with a domain-qualified name of the user or group to which the old name should be mapped; then delete the last three fields (Type, New-SID, and Count).
    Old-name Type Old-SID New-name Type New-SID Count
    akp USER UNIX®:UID-1247 NEW\akp
    Although this example shows a user name that is the same on Windows® as it was on Linux or the UNIX system, this procedure can also be used to map a user or group name on Linux or the UNIX system to a different user or group name on Windows®. After you have edited 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:

    akp,USER,UNIX:UID-1247,NEW\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 can 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.
  12. 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 \\vobsvr-nt\VersionVaultStorage\VOBs\libpub.vbs\libpub-map.csv  \libpub libpub-test.csv

  13. Unlock the VOB.
    If you are concerned that users may try to access the VOB before this procedure is complete, lock the VOB for all users except yourself (cleartool lock -nusers you). You must have write access to the VOB to complete this procedure.
  14. Update user and group identities stored in the VOB.
    When you are satisfied that the map file is correct, run vob_sidwalk with the -execute option. In this example, libpub-map.csv is the map file you created in Step 11:

    versionvault-home-dir\etc\utils\vob_sidwalk -execute -map \\vobsvr-nt\VersionVaultStorage\VOBs\libpub.vbs\libpub-map.csv \libpub libpub-exec.csv

    vob_sidwalk remaps ownership as specified in the map file and records the changes that were made in a new SID file, libpub-exec.csv.
  15. Recover file system ACLs.
    Finally, while you are still logged in to \\vobsvr-nt as the VOB owner or privileged user, use vob_sidwalk with the -recover_filesystem option to apply the correct ACLs to the VOB storage directory.

    versionvault-home-dir\etc\utils\vob_sidwalk -recover_filesystem \libpub recov.csv

    vob_sidwalk logs changes made during this step to the file recov.csv
  16. Verify that all clients in the region can access the VOB.
    Unlock the VOB if it is still locked.
  17. Verify that all HCL VersionVault users on Windows® can access objects in the VOB.
    Users must be able to create objects and to change or remove objects they own.
    Note: If the user's name on Windows® is not the same as it was on Linux or the UNIX system, the user loses rights (for example, the right to remove a version that you created) associated with the creator of a version or a branch. These operations can still be run by a more privileged user (VOB owner, member of the HCL VersionVault administrators group).