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® and
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.
- Log on to the Windows VOB server host as the VOB owner
or privileged user.
- Lock the VOB. No new VOB objects can be created while
you complete Step 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:
ccase-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.
- 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.
- 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:\ClearCaseStorage\VOBs>net use E: \\vobsvr2\vobstg
C:\ClearCaseStorage\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.
- Restart Rational® ClearCase® 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.
- 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:\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
- Replace the VOB object and tag with new ones that reference the
new VOB storage directory. Use the Rational ClearCase Administration
Console or the following commands (which assume that C:\ClearCaseStorage is
shared as \\vobsvr-nt\ClearCaseStorage):
cleartool register –vob –replace \\vobsvr-nt\ClearCaseStorage\VOBs\libpub.vbs cleartool mktag –vob –tag \libpub \\vobsvr-nt\ClearCaseStorage\VOBs\libpub.vbs
- 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.
- Create a map file. Open the SID file
generated in Step 3 of
this procedure (\\vobsvr-nt\ClearCaseStorage\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.
- 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.
ccase-home-dir\etc\utils\vob_sidwalk –map \\vobsvr-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 for
all users except yourself (cleartool lock –nusers you).
You must have write access to the VOB to complete this procedure.
- 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:
ccase-home-dir\etc\utils\vob_sidwalk –execute –map \\vobsvr-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 \\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.
ccase-home-dir\etc\utils\vob_sidwalk –recover_filesystem \libpub recov.csv
vob_sidwalk logs changes made during this step to the file recov.csv
- Verify that all clients in the region can access the VOB. Unlock the VOB if it is still locked.
- Verify that all Rational ClearCase 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 Rational ClearCase administrators
group).