10.2; cvtrgy (convert_registry), revision 1.0, 89/09/14
cvtrgy (convert_registry) - convert registry between SR9.x and SR10 formats
usage: cvtrgy [-from9to10 | -from10to9 [ -invalidate_unixids] ] -readonly |
-owner pgo | -first | -nq | -from source_rgy -to dest_rgy
DESCRIPTION
The cvtrgy command allows the system administrator to generate an SR10
format registry database from SR9.7 registry files, or generates SR9.7
registry files with data from the SR10 registry. The tool operates on
SR9.7 nodes only. Both the rgyd and llbd servers must be running on the
SR10 node, except when the -first option is used. Run cvtrgy the first
time when you add SR10 nodes to your network, and periodically thereafter
to keep the pre-SR10 and SR10 registry information synchronized.
You must specify either -from9to10 or -from10to9. By default, cvtrgy
creates a read-only registry of the destination type. That is, cvtrgy
-from9to10 creates a read-only SR10 format master registry, while cvtrgy
-from10to9 creates a read-only SR9.x format master registry. You can
then propagate the information to replica registries in the appropriate
way.
Whenever the conversion from SR10 to SR9 occurs, if the registry files
exist at the destination node specified in the command line, the tool
quits without updating. This means that before running cvtrgy
-from10to9, you should rename (or move) the SR9.x registry database on
the destination node.
The cvtrgy tool assigns UNIX identifiers automatically during the
conversion process if you prefer. However, if your pre-SR10 node runs
Domain/OS, you should preserve the identifiers associated with accounts
in your current (pre-SR10) /etc/passwd and /etc/group files. In normal
operation, cvtrgy looks for the /etc/passwd and /etc/group files and
assigns identifiers from them, if they exist. Therefore, you should run
cvtrgy on a 9.7 node that either contains your master /etc/passwd and
/etc/group files or has a link to them.
If cvtrgy doesn't find the /etc/passwd and /etc/group files and an /etc
directory exists, it queries you before assigning new UNIX identifiers,
unless the -nq (no query) flag is turned on, in which case cvtrgy exits
with an error.
In order to add or change accounts and other registry data, you must edit
the writable registry with the tool appropriate to the registry's format
(i.e., with edrgy on SR10, edacct and edppo on SR9.x) on a node running
the same software release as the format of the writable registry. Thus,
if your SR9.x registries were writable, you'd have to edit them using
edacct and edppo, from a node running SR9.7. Once your SR10 registry is
the writable one, use edrgy.
The cvtrgy tool resides in the /install/tools/cvtrgy after an SR10
installation and must be copied to an SR9.7 node before you run it.
After running cvtrgy, you must also run the crpasswd command on an SR9.x
node to update the /etc/passwd and /etc/group files. The SR10 directory
/install/tools contains a new version of crpasswd which you should copy
to all SR9.7 nodes that need to run crpasswd. (You can rename or replace
the old version of crpasswd.) See the SR10 Transition Guide for further
details on running cvtrgy.
OPTIONS
-from9to10 Convert SR9.x registry files to SR10 registry format
-from10to9 Convert SR10 registry data to SR9.7 format and place in
SR9.7 registry files
-from source_rgy
Specify source for registry data to be converted. For
-from9to10, must be in the form
//node_name/registry/rgy_site. For -from10to9, must be
//node_name. Either or both registry sites may be remote
from the node running cvtrgy.
-to dest_rgy Specify destination for converted registry data. For
-from9to10, must be in the form
//node_name/registry/rgy_site. For -from10to9, must be
//node_name. Either or both registry sites may be remote
from the node running cvtrgy.
-owner pgo Specify SR10 registry owner, in the SID form p.g.o, where
all pgo names and the pgo account already exist in the
SR9.7 registry. pgo is a string of the form
pers.group.org. You must specify with every invocation of
-from9to10. This option is meaningful only with the
-from9to10 option.
-first Specify that this is the first invocation of cvtrgy. In
this case only, cvtrgy runs without rgyd and llbd servers
running. Use only once. Only meaningful with -from9to10.
-readonly Make SR9.7 registries read-only, permanently. Only
meaningful with -from9to10. Can only be run in this mode
once; after running, cannot use -from9to10 again.
-nq No query. Silent mode. Don't query before assigning new
UNIX identifiers (cvtrgy quits). Don't query for owner
(cvtrgy quits).
-invalidate_unixids
If you've edited UNIX IDs (numbers) in the SR9.7
/etc/passwd or /etc/group after you've already run cvtrgy
at least once, you should propagate the new numbers to the
SR10 registry. Running cvtrgy with this option, in the
-from9to10 direction, invalidates the UNIX IDs stored
within the SR9.7 registry files. After running cvtrgy
with this option, you then need to rerun crpasswd followed
by cvtrgy -from9to10 as you normally would. Finally, you
must also run /etc/syncids on all SR10 disks. Only
meaningful with -from9to10.
CONVERTING FROM SR9.7 TO SR10
You must be root to run cvtrgy. Use the following command line. The
node_name1 is the SR9.7 node.
$ cvtrgy -from9to10 -from //node_name1/registry/rgy_site
-to //node_name2 -owner pgo -first
CONVERTING FROM SR10 TO SR9.7
The person who runs the tool must be logged in as root or locksmith. Use
the following command line. The node_name1 is the SR10 node.
$ cvtrgy -from10to9 -from //node_name1 -to //node_name2/registry/rgy_site
EXAMPLE
The following is a sample transcript from a cvtrgy session that converts
SR9.x registry data files to an SR10 format registry database. This is
the first time cvtrgy has been run on the network. A single collision is
shown to illustrate cvtrgy's warning message format; you may see more
warnings at your site.
$ cvtrgy -from9to10 -from //dog/registry/rgy_site1 -to //cat -first -owner %.sys_admin.%
Phase 1 - opening registry files:
Phase 2 - modifying SR9 registry files:
Converted person file saved in registry
//dog/registry/rgy_site1
Converted project file saved in registry
//dog/registry/rgy_site1
Converted org file saved in registry
//dog/registry/rgy_site1
Phase 3 - converting person file:
?(cvtrgy) Warning - unix id collision:
person bin_sr9 reassigned from 3 to 10002
Converted person file saved in registry
//dog/registry/rgy_site1
Phase 4 - converting project file:
?(cvtrgy) Warning - unix id collision:
project backup reassigned from 1001 to 3
Converted project file saved in registry
//dog/registry/rgy_site1
Phase 5 - converting org file:
Converted org file saved in registry
//dog/registry/rgy_site1
Phase 6 - converting accounts:
Phase 7 - adding default accounts:
Converted account file saved in registry
//dog/registry/rgy_site1
Phase 8 - closing the sr9 registry files:
Phase 9 - writing conversions to sr10 registry:
Conversion completed successfully: