sun.com | docs.sun.com |  | How To Buy | My Sun | Worldwide Sites |

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Maintenance Commands | nhadm(1M)

- NAME
- SYNOPSIS
- DESCRIPTION
- OPTIONS
- COMMANDS
- EXTENDED DESCRIPTION
- EXAMPLES
- ATTRIBUTES
- SEE ALSO

## NAME

> nhadm - cluster administration tool

## SYNOPSIS

> `/opt/SUNWcgha/sbin/nhadm [ -d data-file ] copy [ file ... ]`
> `/opt/SUNWcgha/sbin/nhadm [ -f file ] [ -s ] [ -v ] check [ stage ]`
> `/opt/SUNWcgha/sbin/nhadm [ -f file ] [ -s ] [ -v ] display`
> `/opt/SUNWcgha/sbin/nhadm -h`
> `/opt/SUNWcgha/sbin/nhadm [ -s ] [ -v ] confshare [ shared_package_directory ]`
> `/opt/SUNWcgha/sbin/nhadm [ -s ] [ -v ] [ -y file ] synccheck`
> `/opt/SUNWcgha/sbin/nhadm [ -s ] [ -v ] [ -y file ] syncgen`
> `/opt/SUNWcgha/sbin/nhadm [ -z ] [ html | text ]`

## DESCRIPTION

> The `nhadm` tool provides a suite of tools to check the installation and configuration of the Foundation Services software and its prerequisite products. You must log in as superuser to use this command.

## OPTIONS

> The options that you can use with the `nhadm` tool are as follows:

> -d `| --data`

>   Specifies the name of the file that lists the files to be copied

> -f `| --fsconf`

>   Specifies the name of the Foundation Services configuration file. If this option is not used, the default file is `/etc/opt/SUNWcgha/nhfs.conf`. For information on this file, see the `nhfs.conf`(4) man page.

> -h

>   Displays a help screen.

> -s `| --silent`

>   Runs in silent mode. When using the `nhadm check` command in this mode, the tests being run are not displayed. Only the errors encountered by these tests are displayed.

> -v `| --verbose`

>   Runs in verbose mode. In this mode, traces are displayed when performing operations. The level of detail provided in the traces increases every time this option is added.

> -y `| --syncfile`

>   Specifies the name of the file that lists the nonreplicated files that you want to compare. The default is `/SUNWcgha/remote/etc/nhadmsync.conf`. For more information on this file, see the `nhadmsync.conf`(4) man page.

> -z `| --err [ html | text ]`

>   Prints messages corresponding to all the error scenarios tested by `nhadm` and provides explanations for these errors in html or text form (html is the default). You can use this command to help understand error messages generated by `nhadm` when you test a node or cluster.

## COMMANDS

> The commands and stages available with the `nhadm` tool are the following:

> `check`

>   Verifies that the prerequisite software and hardware are correctly installed and configured, that your cluster has started correctly, and that all peer nodes are accessible. The tests run by `nhadm check` are broken down into the following stages. You can run an individual stage that suits the task you are performing by typing `nhadm check` stage or you can run all three stages by typing `nhadm check`.

>   - `installation`

>     Checks that the correct version of the Solaris operating system is installed. This command also checks that the Foundation Services packages and necessary patches are present and installed correctly.

>   - `configuration`

>     Checks that the configuration files required before starting up the Foundation Services are present and of the correct format. Also checks that the configuration has been performed successfully.

>   - `starting`

>     Tests the node accessibility and disk replication on a running cluster.

>   Note – If a stage is not specified, all the stages are run.
> `confshare`

>   A file is required for patching shared packages installed on the cluster. The `confshare` command creates this file by copying `/var/sadm/system/admin/INST_RELEASE`, the file for local packages, to the shared package repository. By default, `confshare` creates the `/var/sadm/system/admin/INST_RELEASE` file in the `/SUNWcgha/local/export/services` shared package directory.

>   If your shared packages are not installed in `/SUNWcgha/local/export/services`, you must alter the location where `/var/sadm/system/admin/INST_RELEASE` is created to match your shared package repository. For example:

>   `/opt/SUNWcgha/sbin/nhadm confshare [` shared_package_directory`]`

> `copy`

>   Copies files from the master node to the vice-master node. Files listed can be passed as an argument or listed in the data-file file.

> `display`

>   Prints information to the console of the node on which it is run. The displayed information includes local and shared packages installed, node and cluster IDs, network interface information, local and mounted file systems, mount points, and shared partition information. This command can help you diagnose problems by listing the current node configuration.

> `synccheck`

>   Uses the Solaris `diff` command to compare the files listed in `/SUNWcgha/remote/etc/nhadmsync.conf` and prints a warning on the console when the files are not identical on the master-eligible nodes. You must include files in `/SUNWcgha/remote/etc/nhadmsync.conf` that are on the master and the vice-master but are not replicated on a shared file system. The compared files can include Solaris files and Foundation Services files. For more information on the `diff` command, see `diff`(1).

> `syncgen`

>   Accepts the differences between the two nodes found by `synccheck` for each file listed in `/SUNWcgha/remote/etc/nhadmsync.conf`.

## EXTENDED DESCRIPTION

> The `nhadm` tool enables you to verify the status of your cluster. You should use the `nhadm` tool as part of regular maintenance or after you change a cluster configuration in any way.

> The `nhadm display` command prints the current status of a node to the console. Further cluster status information can be obtained by running the `nhcmmstat` command, as described in `nhcmmstat`(1m).

> The `nhadm` tool displays an `ok` message for every check that passes. If any of the tests performed by `nhadm check` fail, an error message is displayed on the console. The error message describes the error and identifies the command that has failed, or the likely problem area. For an explanation of the possible error messages, use the `nhadm -err` option.

> In a correctly functioning cluster, replicated files are the same on the master node and the vice-master node. Some system files cannot be placed on shared file systems but must contain the same information on both master-eligible nodes. You can list the differences between nonreplicated files and manage the differences between these files using the `nhadm synccheck` and `nhadm syncgen` commands.

> The list of nonreplicated files compared by `nhadm synccheck` is shared between the master node and the vice-master node. A template for this file is installed at `/opt/SUNWcgha/config.standard/adm/nhadmsync.conf.template`. The default location of this shared file is `/SUNWcgha/remote/etc/nhadmsync.conf`. For further information on the `nhadmsync.conf` file, see the `nhadmsync.conf`(3) man page.

## EXAMPLES

> This section gives examples of how to use the `nhadm` tool and its commands.

> ### Using `nhadm check`

> > This section contains examples of using `nhadm check installation`, `nhadm check conf` and `nhadm check starting`.

> > Note that the checking stages might vary, depending on the node configuration. For example, the disk check mechanism changes if you are using the Solaris Volume Manager. Therefore, the following examples are guidelines only.

> > Example 1. To Verify Software Installation

> > > After installing the hardware and software, log in to the machine you want to examine and run the `nhadm check installation` command:

> > > >     # nhadm check installation

> > > The `nhadm` tool verifies that:

> > > - All required software packages and patches are installed

> > > - The Solaris operating system and patches have the correct version

> > > - The same MAC address is not used twice

> > Example 2. To Verify Software Configuration

> > > When the Foundation Services software has been configured, log in to the peer node you want to examine, and run the `nhadm check configuration` command. This command checks that the configuration files that are required before starting the Foundation Services have been correctly configured.

> > > >     # nhadm check configuration

> > > This command tests the following:

> > > - The cluster definition files are present and in the correct format.

> > > - The network configuration is correctly defined in `/etc/hostname` and `/etc/hosts`.

> > > - The boot-device is configured to be `disk` for master-eligible nodes and `net` for other peer nodes.

> > >   For a Netra 20 peer node, boot-device is `*disk*` where `disk` in this case cannot match `disk` for the OpenBoot PROM.

> > > - The auto-boot option is set to `true`.

> > > - The local-mac-address for this node is set to `true`.

> > > - The root file system is defined in `/etc/vfstab` and the partitions listed in `/etc/vfstab` exist.

> > > - The `/etc/inet/dhcpsvc.conf` file is present. This test is optional and is only run if the Reliable Boot Service package has been installed.

> > Example 3. To Verify Cluster Network and Disk Replication

> > > Use `nhadm check starting` to list any cluster network, or disk replication problems, by logging in to a peer node in a running cluster and typing:

> > > >     # nhadm check starting

> > > The `nhadm` tool verifies that:

> > > - Each node interface exists and is functioning correctly

> > > - Each peer node is accessible from the current node

> > > - The shared file systems are replicated

> > Example 4. To Verify the Cluster Node Table Configuration When the Master Node Disk and Vice-Master Node Disk Are Not Synchronized

> > > Log in to a master-eligible node on which you want to verify the file and create the `/etc/opt/SUNWcgha/not_configured` file on the node. Boot the node and type:

> > > >     # nhadm -c /SUNWcgha/local/export/data/etc/cluster_nodes_table check

> > > By default, `nhadm` uses the shared file system to access the `cluster_nodes_table` file. When Reliable NFS is not running, as in this case, the file system containing the `cluster_nodes_table` file is not mounted and exported. By specifying the option -c and the local path to the `cluster_nodes_table` file, you are forcing `nhadm` to use the local path.

> > > The target `check` can be replaced by `check installation`, `check configuration`, or `check starting`.

> ### Comparing Nonreplicated Files

> > This section provides examples for using the `nhadm synccheck` and `nhadm syncgen` commands.

> > To use these commands, both master-eligible nodes must have remote access to each other. To enable this, make sure that the CGTP address of the other master-eligible node is set in the `.rhosts` file on each master-eligible node. For example:

> > On node `cgtp10` the `/.rhosts` file must contain the CGTP address of the other master-eligible node, `cgtp11`:

> > >     cgtp11 root

> > On node `cgtp11`, the `/.rhosts` file should contain the CGTP address of the other master-eligible node, `cgtp10`:

> > >     cgtp10 root

> > This enables Reliable NFS to perform `rsh` between the master eligible nodes.

> > To use the `nhadm synccheck` command, you must specify the nonreplicated files that you want to compare. By default, you specify the list of files in `/SUNWcgha/remote/etc/nhadmsync.conf`. The `nhadm synccheck` command compares the copies of these files on the master and the vice-master nodes, printing any differences to the console. You can accept the differences using `nhadm syncgen`. Accepted differences are not printed to the console when you run `nhadm synccheck` again.

> > You can change the name and location of the file that stores the list of nonreplicated files to be compared. You can also have several files containing different lists of nonreplicated files.

> > Example 1. To Specify the Nonreplicated Files to be Compared

> > > Create the `/SUNWcgha/remote/etc/` directory. Copy the template file `/opt/SUNWcgha/config.standard/adm/nhadmsync.conf.template` to `/SUNWcgha/remote/etc/nhadmsync.conf`.

> > > Add the names of the files to be compared to the `nhadmsync.conf` file. The files that you add should have the following criteria:

> > > - The files exist on both master-eligible nodes

> > > - The files are not replicated on a shared file system

> > > Use the following syntax for all entries in the file:

> > > >     FILE=filename

> > > For further information on the `nhadmsync.conf` file see the `nhadmsync.conf`(4) man page.

> > Example 2. To Determine the Differences Between Nonreplicated Files

> > > Type:

> > > >     # nhadm synccheck

> > > This command compares the differences between the files listed in `nhadmsync.conf`, and displays a list of the files that differ. For each file name displayed to the console, the difference that exists between the two copies of the same file is also given.

> > Example 3. To Accept the Differences Between Nonreplicated Files

> > > If you decide that the differences between the nonreplicated files displayed by `nhadm synccheck` are not detrimental to your cluster, update `nhadmsync.conf` with the differences by typing:

> > > >     # nhadm syncgen

> > > If the nodeid of the master node and vice-master node were not entered in the `nhadmsync.conf` file by a previously run `nhadm syncgen` command, a `NODEID` parameter is generated at the top of the file using the `nodeid` of the master and the vice-master nodes in the following format.

> > > >     NODEID=node1  node2

> > > Where node1 and node2 are the nodeids of the master and vice-master nodes, respectively, when `nhadm syncgen` is first run.

> > > The nodeid can be preceded by a blank line or a comment. This nodeid defines the order of the comparison performed by `synccheck`. The order will remain the same even if a switchover or failover occurs.

> > > Any differences displayed on the console are written to the `nhadmsync.conf` file. The differences for a specific file are printed under the entry for that file in the following format:

> > > >      =BEGIN
> > > >      ...
> > > >       =END

> > > For example, if the `nhadmsync.conf` file contained the following files:

> > > >     FILE=/etc/ethers
> > > >     FILE=/etc/hosts
> > > >     FILE=/etc/netmasks

> > > After a `syncgen` the `nhadmsync.conf` file might contain the following information:

> > > >     NODEID=10 20
> > > >     FILE=/etc/ethers
> > > >     FILE=/etc/hosts
> > > >     =BEGIN
> > > >     5c5,6
> > > >     < 10.250.1.10   MEN-C250-N10    loghost
> > > >     ---
> > > >     > 10.250.1.20   MEN-C250-N20    loghost
> > > >     > 10.250.1.10 MEN-C250-N10
> > > >     8d8
> > > >     < 10.250.1.20 MEN-C250-N20
> > > >     =END
> > > >     FILE=/etc/netmasks

> > > The differences printed to the `nhadmsync.conf` file are the differences that would be found by running `diff` -b on the files listed in `nhadmsync.conf`. For more information on the `diff` command, see the `diff`(1) man page.

> > > For further information on the `nhadmsync.conf` file, see the `nhadmsync.conf`(4) man page.

> > Example 4. To Check for New Differences Between Nonreplicated Files

> > > Log in to one of the master-eligible nodes and type:

> > > >     # nhadm synccheck

> > > For nonreplicated files listed in `nhadmsync.conf`, any differences that are not already stored in `nhadmsync.conf` are displayed to the console.

> > Example 5. To Change the Location of the File Listing the Nonreplicated Files Compared by `nhadm synccheck`

> > > The `nhadmsync.conf` file is shared by the master and vice-master nodes. To change the name or location of the `nhadmsync.conf` file, use the -y option as follows:

> > > >     # nhadm -y pathname syncgen

> ### Copying Local Files

> > This section provides an example for using the `nhadm copy` command to copy local files from the master node to the vice-master node.

> > >     # nhadm [-d data-file ] copy [ file ]

> > where:

> > data-file

> >   a list of files to be copied; one file per line

> > file

> >   additional files to be copied, for example files that you want to copy once only. You can include the files to be copied repeatedly in the data-file file.

> > The `/.rhosts` files must be correctly configured on both nodes to enable remote access via `rcp`.

> > Example 1. To Copy Local DHCP Configuration Files

> > > This example shows how to copy the local DHCP configuration file, `dhcp.dat` from the master node to the vice-master node. The contents of a DHCP configuration file such as `dhcp.dat` could be as follows:

> > > >     /var/dhcp/SUNWrbs1_10_1_1_0
> > > >     /var/dhcp/SUNWrbs1_10_1_2_0
> > > >     /var/dhcp/SUNWrbs1_dhcptab

> > > To copy `dhcp.dat` from the master node to the vice-master node, log on to the master node and use the `nhadm` command as follows:

> > > >     # nhadm -d dhcp.dat copy

> > > The vice-master node now has a copy of the files listed in the `dhcp.dat` file.

## ATTRIBUTES

> See `attributes`(5) for descriptions of the following attributes:

> ATTRIBUTE TYPE | ATTRIBUTE VALUE
> --- | ---
> Architecture | SPARC
> Availability | SUNWnhadm
> Interface Stability | Evolving

## SEE ALSO

> `diff`(1), `nhcmmstat`(1M), `nhadmsync.conf`(4)

Netra HAS FS 2.1 | Go To Top | Last Changed September 2004

Company Info | Contact | Copyright 2004 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms.