• Aucun résultat trouvé

Running in -compare Mode

Dans le document Administering the Domain/OS Registry (Page 66-70)

Handling Network Reconfigurations

5.3 Joining Networks

5.3.4 Running in -compare Mode

You should first run rgy_merge in compare mode with the -compare option. In this mode, rgy_merge simulates the results of a processing run showing all conflicts. When rgy _merge is run without the -compare option, it halts and exits whenever it encounters an error. You must use edrgy to fix the error and then re-execute rgy_merge.

Eliminating conflicts in advance will save you time.

To run rgy_merge in compare mode, follow the procedures described in Section 5.3.5, with one exception. When you enter the command, enter it in the form:

rgy_merge -from IIsource_site -compare

5.3.5 Using rgy_merge

You must execute rgy_merge from the node that has the registry that will become the new master registry. This registry is called the target of the merge. The master registry named in the -from IIsource_site argument is the source for the merge. After you run

rgy _merge, a source is no longer a master; it becomes a slave of the target.

For example, if you select IImusic as the target (by executing rgy_merge at IImusic) and name lIart in the -from Ilsource_site argument, IImusic becomes the master registry and lIart becomes a slave registry.

If you are merging more than one source registry, you must complete the merge in steps, one target-source pair at a time.

Requirements to Use rgy _merge

To use rgy_merge, you must be able to log in to the target node as root and log in to each source node as the owner of the source registry.

Invoking rgy _merge

1. Identify the nodes that run master registry servers and select one node as the node to run the master registry server (called the target in these procedures).

2. Log in to the target node as root.

3. Invoke rgy_merge, specifying the source site in the -from option. In the example below, dds:llmusic is the source site.

I

%$rgy_merge -from dds:llmusic

rgy_merge prompts you to log in with an account that owns the source registry.

4. Enter the log-in name and password of the account that owns the source registry:

Source Registry Login: root Password:

Source registry has been made read-only.

Placing master registry in maintenance mode ...

5-6 Handling Network Recon/igurations

5. What happens next depends on whether or not rgy _merge finds conflicts between the target and source databases.

If there are no conflicts, rgy_merge asks to merge the source with the target.

Answer affirmatively, as shown below:

I

Merge successful; update registry? y

rgy_merge then completes the merge and exits. The source registry becomes a slave replica of the target registry. If there are more registries to merge, repeat these procedures.

If there are conflicts, follow the steps in "Resolving Registry Conflicts," below.

Resolving Registry Conflicts

If rgy_merge finds conflicts, it will display them. The following example shows the information displayed when rgy_merge finds that both the source and target database contain a person named smith.

Source registry has been made read-only.

Placing master registry in maintenance mode ...

Collision on person:

Source: name

=

"smith" uid

=

3c2b6022.60001ed4 unix id

=

99 Dest: name

=

"smith" uid

=

3c2b7ea2.90012edf unix id

=

101 Merge failed; 1 errors.

Since merged registry was not updated, source registry has been reenabled for updates.

%

To resolve the conflict, use the edrgy command to eliminate the conflict by changing the conflicting name or UNIX 10, as appropriate, in either the source or target database.

Then begin the merge process again, following the instructions described in "Invoking rgy_merge." Using the edrgy command is described in Chapter 2.

If you make any changes to UNIX IDs, you must run the letc/syncids tool on every registry-controlled node in your network. This tool ensures that the changes are

synchronized with the UNIX IDs stored on disk. On nodes that have more than one disk volume, you must run syncids on each volume.

If the registry is a slave replica, before you run syncids, you should use the Irep -state command in the letc/rgy_admin tool to verify that all slave replicas are up-to-date. This command shows the timestamps of the most recent changes to each replica . You should not run syncids until the timestamps for all replicas match the timestamp for the master.

See the online manual pages for information about syncids.

Keeping Track of Changes

You should keep track of the names you change so that you can inform users of the changes. You can use the form shown in Figure 5-2 to keep a list of names you change.

Current Name Changed Name Current Name Changed Name

Figure 5-2. Changed Names

Updating the Master Registry Replica List

After you've merged all sources into the target, use the rgy_admin Irep command to examine the rgyd replica list at the new master registry site. Ensure that all slave registries are in the master's replica list and that they are listed with the correct network numbers.

If necessary, use the rgy_admin chrep command to update them.

---88---5-8 Handling Network Recon/igurations

Chapter 6

Dans le document Administering the Domain/OS Registry (Page 66-70)

Documents relatifs