- Log on to the Windows VOB server host as the VOB owner
or privileged user.
- Lock the VOB. This ensures that no new VOB objects
are created while you complete Step 3.
- 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
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 15.
- Dump the VOB database. Use the cleartool reformatvob command:
cleartool reformatvob –dump C:\ClearCaseStorage\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 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:\ClearCaseStorage\VOBs> net use E: \\vobsvr2\vobstg
C:\ClearCaseStorage\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.
- Restart Rational® ClearCase® 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.
- Log on to the VOB server host that runs Linux or the UNIX system.
- 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:
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.
# cleartool reformatvob –load /vobstg/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:
cleartool register –vob –replace /net/vobsvr2/vobstg/libpub.vbs
cleartool mktag –vob –replace –tag /vobs/libpub /net/vobsvr2/vobstg/libpub.vbs
- Create a map file. Open the SID file
generated in Step 3 (/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.
- 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 /vobstg/libpub.vbs/libpub-map.csv /vobs/libpub /libpub-test.csv
- 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).
- 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 11:
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 . Run vob_sidwalk with
the –recover_filesystem option:
ccase-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
- Verify that all clients can access the VOB at the new location. Unlock the VOB if it is still locked.
- Verify that all Rational ClearCase 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.