11.2 Moving a VOB on Windows

This section describes procedures for the following types of VOB moves involving Windows platforms:

• moving a VOB to another host in the same domain. This procedure also applies when moving a VOB from one partition to another on a host.

• moving a VOB to a host in another domain

Moving a VOB Within a Domain

The following procedure describes how to move the VOB \libpub from storage directory C:\ClearCaseStorage\VOBs\libpub.vbs on VOB server host \\sol to a storage directory shared as vobstg on VOB server host \\ccsvr01. The procedure to move the VOB to a new partition on \\sol would be similar.

1. Log on to the VOB's current server as the VOB owner or privileged user. In this example, the VOB's current server is \\sol.

2. Lock the VOB.

3. Stop ClearCase on the VOB server host.

4. Copy the VOB storage directory, preserving all ownership information. You must use a copy utility that preserves ownership information contained in the VOB storage directory ACLs. Typical Windows file system copy utilities like copy and xcopy do not preserve this information. We recommend using the ClearCase utility ccase-home-dir\etc\utils\ccopy for this purpose.

C:\ClearCaseStorage\VOBs> net use E: \\ccsvr01\vobstg
C:\ClearCaseStorage\VOBs> ccopy libpub.vbs E:\libpub.vbs

NOTE: Although ccopy copies all of the ownership information required by ClearCase, it does not copy the full security descriptor of an object, and therefore effectively grants the user who executes this step full access to the copy of the VOB storage directory. If this step is not executed by the VOB owner, you may want to use a different copy program, such as scopy /s /o from the Windows NT Resource Kit or xcopy /o on Windows 2000 or Windows XP, that copies the VOB storage directory but does not grant the user additional rights to it.

5. Restart ClearCase if you have copied the VOB storage directory to a new location on the same VOB server host.

6. Replace the VOB object and tag with new ones that reference the new VOB storage directory. Use the ClearCase Administration Console, or the following commands (this example applies to the destination on server ccsvr01):

cleartool register -vob -replace \\ccsvr01\vobstg\libpub.vbs
cleartool mktag -vob -replace -tag \libpub \\ccsvr01\vobstg\libpub.vbs

NOTE: If you are registering a Unified Change Management project VOB, you must supply the -ucmproject option to the register command.

7. Unlock the VOB.

8. Verify that all clients can access the VOB at the new location.

Moving a VOB to a Different Domain

On Windows, VOBs formatted with schema version 54 store Windows security identifiers (SIDs) to represent users, groups, and resources (hosts). When you move a VOB to a different domain, these SIDs become invalid and must be changed (mapped) to ones that are valid in the new domain. ClearCase LT includes a utility program, vob_sidwalk, that provides a flexible means of mapping SIDs when you move a VOB to a different domain. We strongly recommend that you review the reference page for vob_sidwalk before continuing with this procedure.

The following procedure describes how to move the VOB \libpub from storage directory C:\ClearCaseStorage\VOBs\libpub.vbs on VOB server host \\sol, which is in the OLD domain, to a storage directory shared as vobstg on VOB server host \\ccsvr-new, which is in the NEW domain. To execute this procedure, you must be able to log in to both the OLD and NEW domains as the VOB owner of \libpub or as the privileged user.

1. Be sure the VOB has been formatted with schema version 54. Earlier schema versions do not support moving a VOB across domains. You can use the ClearCase Administration Console or the cleartool describe command to determine a VOB's schema version. If the VOB is not formatted with schema version 54, reformat it using reformatvob. (All VOBs on a server must be formatted with the same schema version.)

2. Log on to the VOB server host as the VOB owner or privileged user. In this example, the VOB server host for this step is \\sol.

3. Lock the VOB. This ensures that no new VOB objects will be accidentally created while you are performing Step #4 of this procedure.

4. Generate a SID file that lists the names of users and groups associated with objects in \libpub. Run vob_siddump as shown in the following example to generate a SID file in comma-separated-value (csv) format:

ccase-home-dir\etc\utils\vob_siddump \libpub ^
C:\ClearCaseStorage\VOBs\libpub.vbs\libpub.csv

We suggest creating the SID file in the VOB storage directory so that it will be available on the new VOB host after the storage directory has been moved. You will need it Step #10 of this procedure.

5. Stop ClearCase on the VOB server host \\sol.

6. Copy the VOB storage directory to the new location.

C:\ClearCaseStorage\VOBs> net use E: \\ccsvr-new\vobstg
C:\ClearCaseStorage\VOBs> ccopy libpub.vbs E:\libpub.vbs

NOTE: Because the existing VOB storage directory ACLs will be meaningless in the new domain, you can use xcopy or a similar utility instead of the ClearCase utility ccase-home-dir\etc\utils\ccopy in this procedure.

7. Fix the VOB storage directory protections. Log on to the VOB server host in the new domain (\\ccsvr-new in our example) as the VOB owner for \libpub or as a privileged user. Run the fix_prot utility as shown in the following example, where vobadm is the name of the new VOB owner, ccusers is the name of the VOB's new principal group, and V:\vobstg\libpub.vbs is the host-local pathname of the VOB storage directory on \\ccsvr-new.

ccase-home-dir\etc\utils\fix_prot -root -r -chown vobadm -chgrp ccusers ^
V:\vobstg\libpub.vbs

8. Replace the VOB object and tag with new ones that reference the new VOB storage directory. Use the ClearCase Administration Console, or the following commands:

cleartool register -vob -replace \\ccsvr-new\vobstg\libpub.vbs
cleartool mktag -vob -replace -tag \libpub \\ccsvr-new\vobstg\libpub.vbs

If \\ccsvr-new is not in the same registry region as \\sol, you do not need to use the -replace option to cleartool register and cleartool mktag, but you should remove the old registration and tag for \libpub, which will be invalid after the move.

NOTE: If you are registering a Unified Change Management Process VOB, you must supply the -ucmproject option to the register command.

9. Lock the VOB. Although the VOB is now registered and has a tag, it will not be usable until this procedure is complete. If you are concerned that users may try to access the VOB before it is ready, lock it now.

10. Create a map file. Open the SID file you generated in Step #4 of this procedure (\\ccsvr-new\vobstg\libpub.vbs\libpub.csv). Editing this file may be simplified if you use a spreadsheet program that can read the comma-separated-value format. This example shows one line of such a file. We've added a header row for clarity and truncated the SID string to save space.

    Old-name	Type	Old-SID	New-name	Type	New-SID	Count
    OLD\akp	USER	NT:S-1-2-21-532...	IGNORE	USER		137

    
    

For each line in the file, replace the string IGNORE in the New-name field with a string made up of the new domain name and the user name from the Old-name field; then delete the last three fields (Type, New-SID, and Count). In this example, old domain's name is OLD and the new domain's name is NEW, so the line would change as shown here:

Old-name	Type	Old-SID	New-name	Type	New-SID	Count
OLD\akp	USER	NT:S-1-2-21-532...	NEW\akp




Although this example shows a user name that is the same in the old and new domains, the procedure can also be used to map a user or group name from the old domain to a different user or group name in the new domain.

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 would look like this in .csv form:

OLD\akp,USER,NT:S-1-2-21-532...,NEW\akp

NOTE: You may 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.

11. Test the map file. Run vob_sidwalk without the -execute option. The list of mappings prescribed by the map file libpub-map.csv is written to the SID file (libpub-test.csv in this example), but no changes are made to the VOB.

ccase-home-dir\etc\utils\vob_sidwalk -map ^
\\ccsvr-new\vobstg\libpub.vbs\libpub-map.csv \libpub libpub-test.csv

12. Unlock the VOB. If you are concerned that users may try to access the VOB before this procedure is complete, lock the VOB again for all users except yourself.

13. Update user and group identities stored in the VOB. When you are satisfied that the map file is correct, run vob_sidwalk as shown in the following example, where libpub-map.csv is the map file you created in Step #10 of this procedure:

ccase-home-dir\etc\utils\vob_sidwalk -execute -map ^
\\ccsvr-new\vobstg\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 libpub-exec.csv.

14. Recover file system ACLs. Finally, while you are still logged in to \\ccsvr-new 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.

ccase-home-dir\etc\utils\vob_sidwalk -recover_filesystem \vobstore2\libpub

15. Verify that all clients in the new domain can access the VOB. Unlock the VOB if it is still locked.

16. Verify that all ClearCase users in the new domain can access objects in the VOB. Users should be able to create new objects as well as change or remove objects they own.

NOTE: If the user's name in the new domain is not the same as in the old domain, the user ill loses rights associated with the creator of a version or a branch. For example, the user would not be able to remove a version even though the user had created that version. These operations can still be executed by a more privileged user (VOB owner, member of the ClearCase administrators group).