|
|
When you move a VOB from a Windows host to a UNIX host or vice versa, all user identity information stored in the VOB storage directory and VOB database must change. The binary data format of the VOB database must change as well. To accommodate these requirements, you must take a number of additional steps beyond those required in most other VOB move scenarios, including the following:
Run vob_sidwalk before the move to capture information about ownership of objects in the VOB.
Use reformatvob to dump the VOB database into a portable ASCII form.
Copy the VOB storage directory, which includes the dumped database, to the new host.
Use reformatvob to load the VOB database in the proper binary format.
Reset the file system protections on the VOB storage directory after the move.
Remap the SIDs (or, on UNIX, UIDs and GIDs) of owners of objects in the VOB.
These steps, along with other ones that are typical of all VOB moves, are detailed in the procedures described in this section.
NOTE: You can move a VOB between Windows and UNIX only if both hosts are configured to support schema version 54.
vob_sidwalk and vob_siddump are not compatible with VOB schema version 53. vob_sidwalk is installed only on hosts that are configured to support local VOBs and views and to support VOB schema version 54. vob_siddump, which is not restricted to operating on local VOBs, is installed on all hosts.
Before a VOB formatted with schema version 54 can be moved from Windows to a UNIX host, the UNIX host must be configured to support VOB schema version 54. Not all UNIX hosts have this capability. You cannot reformat a VOB from schema version 54 to schema version 53. You cannot move a VOB formatted with schema version 53 from a UNIX host to a Windows host that supports schema version 54.
For clarity, the procedures in this section use an example:
The current location of the VOB storage directory to be moved is C:\ClearCaseStorage\libpub.vbs on Windows host ccsvr-nt. The VOB-tag for this VOB is \libpub.
The new location for the VOB storage directory is /vobstg/libpub.vbs on UNIX host ccsvr-ux. VOB-tag /vobs/libpub will be created for this VOB.
To move a VOB from Windows to UNIX:
Log on to the Windows VOB server host as the VOB owner or privileged user. In this example, the VOB server host for this step is \\ccsvr-nt.
Lock the VOB. This ensures that new VOB objects are not created while you are performing Step #3 of this procedure.
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:
ccase-home-dir\etc\utils\vob_siddump -raw_sid \libpub ^
C:\ClearCaseStorage\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 the SID file in Step #15 of this procedure.
Dump the VOB database using the cleartool reformatvob command:
cleartool reformatvob -dump C:\ClearCaseStorage\libpub.vbs
reformatvob -dump marks the VOB database as invalid. It cannot be used by clients until it is processed by a reformatvob -load command.
Copy the VOB storage directory. Use any file system copy utility to copy the entire VOB storage directory to the UNIX host. This example assumes that the target UNIX host ccsvr-ux is running an SMB server and has shared its \vobstg partition.
C:\ClearCaseStorage\VOBs> net use E: \\ccsvr-ux\vobstg
C:\ClearCaseStorage\VOBs> ccase-home-dir\etc\utils\ccopy libpub.vbs E:\libpub.vbs
NOTE: Because the existing VOB storage directory ACLs will be meaningless on the UNIX host, you can use xcopy or another copy program instead of the ClearCase ccopy utility in this case.
Terminate the VOB's server processes on Windows. Stop and restart ClearCase on the Windows VOB server host (\\ccsvr-nt in our example).
Log on to the UNIX VOB server host as root.
Update VOB owner identity information. Use the fix_prot utility as shown here to create a new .identity directory for the VOB. This example sets the VOB's owner to user vobadm and the VOB's primary group to ccusers:
ccase-home-dir/etc/utils/fix_prot -root -recurse -chown vobadm -chgrp ccusers ^
/vobstg/libpub.vbs
Re-create the VOB database from the dump files. Use the cleartool reformatvob command:
# cleartool reformatvob -load /vobstg/libpub.vbs
Create a tag for the VOB. Use the ClearCase Administration Console, or the following command:
cleartool mktag -vob -tag /vobs/libpub /net/ccsvr-ux/vobstg/libpub.vbs
NOTE: You do not need to register the VOB, because reformatvob -load registers the VOB after the reformat is complete.
Create a map file. Open the SID file generated in Step #3 of this procedure (/vobstg/libpub.vbs/libpub.csv). Editing this file may be easier 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 | 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 UNIX 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 UNIX 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 UNIX.
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:
OLD\akp,USER,SID:3.0105037...,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
Test the map file. Run vob_sidwalk without the -execute option. The list of mappings prescribed by 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.
ccase-home-dir/etc/utils/vob_sidwalk -map /vobstg/libpub.vbs/libpub-map.csv \
/vobs/libpub /libpub-test.csv
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.
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 created in Step #11 of this procedure:
ccase-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.
Update the VOB's group list and container protections. Use the vob_sidwalk program as shown in the following example:
ccase-home-dir/etc/utils/vob_sidwalk -recover_filesystem /vobs/libpub libpub.csv
Verify that all clients can access the VOB at the new location. Unlock the VOB if it is still locked.
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.
For clarity, the procedures in this section use an example:
The current location of the VOB storage directory to be moved is /vobstg/libpub.vbs on UNIX host ccsvr-ux. The VOB-tag for this VOB is /vobs/libpub.
The new location of the VOB storage directory is C:\ClearCaseStorage\VOBs\libpub.vbs on Windows host ccsvr-nt. VOB-tag \libpub will be created for this VOB.
To move a VOB from UNIX to Windows:
Log on to the VOB server host as the VOB owner or root. In this example, the VOB server host for this step is ccsvr-ux.
Lock the VOB. This ensures that new VOB objects are not created while you are performing Step #3 of this procedure.
Generate a SID file that lists the names and UIDs/GIDs of users and groups associated with objects in /vobs/libpub. Run the vob_siddump utility as shown in this example:
ccase-home-dir/etc/utils/vob_siddump /vobs/libpub /vobstg/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 in Step #15 of this procedure.
Dump the VOB database using the cleartool reformatvob command:
cleartool reformatvob -dump /vobstg/libpub.vbs
reformatvob -dump marks the VOB database as invalid. It will be unusable by clients until it is processed by a reformatvob -load command.
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 UNIX host ccsvr-ux is running an SMB server and has shared its \vobstg partition. From the Windows host, run these commands:
C:\ClearCaseStorage\VOBs> net use E: \\ccsvr-ux\vobstg
C:\ClearCaseStorage\VOBs> ccase-home-dir\etc\utils\ccopy E:\libpub.vbs libpub.vbs
NOTE: Because the existing VOB storage directory ACLs are not supported on the UNIX host, you can use xcopy or a similar utility instead of the ClearCase utility ccase-home-dir\etc\utils\ccopy in this case.
Terminate the VOB's server processes on UNIX. You may either stop and restart ClearCase on the VOB server host or search the process table for the vob_server and vobrpc_server processes that service the old VOB. Use ps -ax or ps -ef, and search for the VOB storage directory name (libpub.vbs in our example), then use kill(1) to terminate any such processes.
Fix the VOB storage directory protections. Log in to the Windows VOB server host (\\ccsvr-nt in our example) as the VOB owner of \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 C:\ClearCaseStorage\VOBs\libpub.vbs is the host-local pathname of the VOB storage directory.
ccase-home-dir\etc\utils\fix_prot -root -r -chown vobadm -chgrp ccusers ^
C:\ClearCaseStorage\VOBs\libpub.vbs
Re-create the VOB database from the dump files. Use the cleartool reformatvob command:
cleartool reformatvob -load C:\ClearCaseStorage\VOBs\libpub.vbs
Create a tag for the VOB. Use the ClearCase Administration Console, or the following command (assuming that C:\ClearCaseStorage is shared as \\ccsvr-nt\ClearCaseStorage):
cleartool mktag -vob -tag \libpub \\ccsvr-nt\ClearCaseStorage\VOBs\libpub.vbs
NOTE: You do not need to register the VOB, because reformatvob -load registers the VOB after the reformat is complete.
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.
Create a map file. Open the SID file generated in Step #4 of this procedure (\\ccsvr-nt\ClearCaseStorage\VOBs\libpub.vbs\libpub.csv). Editing this file may be easier 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.
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 UNIX, this procedure can also be used to map a UNIX user or group name 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 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.
Test the map file. Run vob_sidwalk without the -execute option. The list of mappings prescribed by 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.
ccase-home-dir\etc\utils\vob_sidwalk -map^
\\ccsvr-nt\ClearCaseStorage\VOBs\libpub.vbs\libpub-map.csv ^
\libpub libpub-test.csv
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.
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-nt\ClearCaseStorage\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.
Recover file system ACLs. Finally, while you are still logged in to \\ccsvr-nt as the VOB owner or privileges 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 \libpub libpub.csv
Verify that all clients in the region can access the VOB. Unlock the VOB if it is still locked.
Verify that all ClearCase users on Windows 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 on Windows is not the same as on UNIX, the user 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).
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
