Sun Management Center Change Manager 1.0.1 Administration Guide

- Previous: Chapter 5 Installing Solaris Flash Archives on Managed Hosts (Tasks)
- Next: Chapter 7 Monitoring Jobs (Tasks)

# Chapter 6 Auditing Software Configurations (Tasks)

This chapter provides step-by-step instructions for gathering status about managed hosts.

The following topics are covered in this chapter:

- Using Audit Software

- Change Manager Audit File Types

- Auditing Software Configurations by Using the Browser Interface (Task Map)

- Auditing Software Configurations by Using the Browser Interface

- Auditing Software Configurations by Using the Command-Line Interface (Task Map)

- Auditing Software Configurations by Using the Command-Line Interface

For descriptions of the audit-related file formats, see Chapter 11, Audit Tool File Formats (Reference).

# Using Audit Software

Change Manager provides users with the ability to validate the contents of deployed software stacks. Stack validation is accomplished by comparing the contents of a managed host's file systems over time with those of a baseline configuration. The baseline configuration is known to be good. The audit features are implemented by using the `bart` command. See the bart(1MCM) man page.

The audit rules file enables you to track files and directories on managed hosts that are installed with a software stack. The audit tool enables you to determine which files were added to and deleted from managed hosts. You can also use the audit rules file to specify which file attribute changes you want to flag.

When an audit rules file is applied to one or more managed hosts configured with the same software stack, the results should be nearly identical. Note that the properties of some files might change legitimately across installed machines (`/etc/nodename`). Other files should not have properties that change (`/usr/bin/ls`). The author of the audit rules file must ensure that only relevant files are members of the stack definition.

The state of a file is described by the associated file attributes, such as file size, creation date, modification date, and access control list (ACL). Optionally, the state is described by a cryptographic checksum of the file's contents and most of the values retrieved by the `stat` system call. See the stat(2) man page.

The description of a software stack yields a list of files and associated attributes in a manifest. The manifests represent the software stacks on each managed host. Pairs of manifests can be compared to yield a manifest comparison report, which lists file-by-file differences.

Review the comparison report to determine whether the two manifests are “similar enough.” Also, the review can determine whether the stack has changed so much as to no longer be valid.

Use the audit tool to perform a file-level check of the software contents of a managed host. Change Manager compares a baseline manifest against manifests generated for each managed host selected. The baseline manifest represents a baseline state of the managed host, which might match the original state of the software stack.

- Build manifests for managed hosts – Build a manifest for a managed host. The manifest is a list of files and associated file attributes for a managed host.

- Audit managed hosts – Audit managed hosts by comparing their manifests against a baseline manifest. The output of the comparison is a comparison report.

- Get software status – Get information about the patches and packages running on the managed host.

# Change Manager Audit File Types

Change Manager uses files as input and output for audit jobs.

You can use folders to create a hierarchy in which to organize these Change Manager files. These files and folders are stored in the repository. You can organize the folders and files in any way that you want.

Access the repository in the browser user interface by clicking the Set Up Files tab. Access the repository with the command-line interface by using the file management subcommands of the `changemgr` command.

You might organize the folders and files in the following ways:

- Group like file types – For example, store all the Solaris Flash archives in a single folder. Do the same for Solaris boot images, shared profiles, and manifests.

- Group files related to a particular set of managed hosts – Create a folder to hold all the files associated with a particular service's servers.

  For example, a server farm provides web services. Therefore, create a folder named `WebServer`. In the `WebServer` folder, store the files used by the web server, such as the archives, boot images, shared profiles, and manifests. Create a separate folder to hold files associated with a mail server.

- Group by user name – Store all files in folders owned by specific users. For example, store all of Joe's files in a folder named `joe`. Then, Joe can organize his folders and files in the way he wants.

- Group all files associated with a particular archive – Store all files associated with each archive in folders. For example, the archive and associated files for the Apache web server are stored in a folder named `apache-web-server`. Store the archive, boot image, and shared profile in the same folder.

For information about naming conventions for file objects, see Change Manager Naming Conventions.

Files stored in the Change Manager repository have a standard set of properties associated with them. The following properties are shared by all files:

`Description`

  User-supplied string that describes the file.

`Owner`

  Read-only property that names the owner of the file.

`State`

  Read-only property that indicates the state of the file.

Note –

When using the browser interface, you must perform the operations on the File Actions drop-down menu while in the appropriate folder.

For example, to create a folder inside an existing folder, go to that folder before choosing New Folder from the File Actions menu.

When using the browser interface, you can select items from a list. To select an item from a list, click the checkbox next to the item name. Then, choose the action to perform from the File Actions drop-down menu.

## Audit Rules File

An audit rules file determines what files and file attributes to audit on a managed host. The audit rules file serves two purposes:

- To specify which files and directories to catalog when building a manifest for a managed host

- To specify which files, directories, and file attributes in the manifests to compare when auditing managed hosts

For example, you might want to ignore the directory modification time for files. The modification time changes each time a file is created or deleted in the directory. You might also want to ignore `core` files or `.o` files.

The format of the audit rules file is described in Audit Rules File Format. The audit rules file name must use the `.brul` suffix.

To create or import a rules file from another system, see the appropriate section:

- How to Create an Audit Rules File (Web Browser)

- How to Import an Audit Rules File to the Change Manager Repository (Web Browser)

- How to Import Audit Rules Files to the Change Manager Repository (Command Line)

To import a manifest to the repository, see the appropriate section:

- How to Import a Manifest to the Change Manager Repository (Web Browser)

- How to Import Manifests to the Change Manager Repository (Command Line)

To build manifests of managed hosts, see the appropriate section:

- How to Build Manifests for Managed Hosts (Web Browser)

- How to Build Manifests for Managed Hosts (Command Line)

To audit managed hosts, see the appropriate section:

- How to Audit Managed Hosts (Web Browser)

- How to Audit Managed Hosts (Command Line)

## Manifest

A manifest is a file that describes all the files on the managed host and the file attributes for each file. The audit feature uses this manifest to determine how the managed host's software has changed over time. The files described in the manifest are based on the audit rules.

The format of a manifest is described in the Manifest File Format. The manifest is output for the Build Manifests action or the `changemgr manifest` command. The manifest can be used as input for the Audit action or `changemgr audit` command. The manifest file name must use the `.bmft` suffix.

In addition to the general file properties, a manifest is associated with the following property:

`RulesFile`

  Read-only property that names the audit rules file used to build the manifest.

To import an existing manifest to the Change Manager repository, see the appropriate sections:

- How to Import a Manifest to the Change Manager Repository (Web Browser)

- How to Import Manifests to the Change Manager Repository (Command Line)

To build manifests of managed hosts, see the appropriate section:

- How to Build Manifests for Managed Hosts (Web Browser)

- How to Build Manifests for Managed Hosts (Command Line)

To audit managed hosts, see the appropriate section:

- How to Audit Managed Hosts (Web Browser)

- How to Audit Managed Hosts (Command Line)

## Report

A report is a file that is created by two jobs: Audit and Get Software Status.

To audit or get software status of managed hosts, see the appropriate sections:

- How to Audit Managed Hosts (Web Browser)

- How to Get the Software Status of Managed Hosts (Web Browser)

- How to Audit Managed Hosts (Command Line)

- How to Get the Software Status of Managed Hosts (Command Line)

See a description of the Comparison Report Format.

The report file name must use the `.txt` suffix.

## Folder

A folder is a container that can hold files and other folders. Click a folder name to go into that folder. Then, view the folder's contents. Change Manager files can be the following:

- Solaris Flash archive

- Solaris boot image

- Shared profile

- Manifest

- Audit rules file

- Report

Perform the following actions from the folder page:

- Create folders, shared profiles, and audit rules files.

- Import Solaris Flash archives, Solaris boot images, shared profiles, audit rules files, and manifests to the Change Manager repository.

- Rename folders and files.

- Export files.

- Create a copy of a shared profile or an audit rules file in the current folder.

- Move folders and files to another folder.

- Delete folders and files.

To create folders, see How to Create a Folder (Web Browser) or How to Create a Folder (Command Line).

# Auditing Software Configurations by Using the Browser Interface (Task Map)

The following table identifies the procedures you need to audit managed hosts.

Task | Description | For Instructions
--- | --- | ---
Create an audit rules file. | Create an audit rules file to determine which files and directories to list in the manifest. | See How to Create an Audit Rules File (Web Browser).
Import an audit rules file to the Change Manager repository. | Import an existing audit rules file to the Change Manager repository. | See How to Import an Audit Rules File to the Change Manager Repository (Web Browser).
Import manifests to the Change Manager repository. | Import existing manifests to the Change Manager repository. These manifests can be used in comparisons. | See How to Import a Manifest to the Change Manager Repository (Web Browser).
Build manifests for managed hosts. | Build manifests for managed hosts. Each manifest includes a list of entries, an entry per file cataloged. Each file entry includes the file name and several file attribute values. | See How to Build Manifests for Managed Hosts (Web Browser).
Audit managed hosts. | Audit managed hosts by comparing them against a baseline manifest. The existence of files, as well as file attribute values are compared. | See How to Audit Managed Hosts (Web Browser).
Get software status of managed hosts. | Get information about the packages and patches installed on the managed hosts. | See How to Get the Software Status of Managed Hosts (Web Browser).

# Auditing Software Configurations by Using the Browser Interface

This section describes how to use the browser interface to audit managed hosts.

To learn how to create folders and perform management tasks in the Change Manager repository, see Chapter 8, Maintaining the Change Manager Repository (Tasks). The procedures described in Chapter 8, Maintaining the Change Manager Repository (Tasks) are not required to perform audit tasks. However, you might want to create a hierarchy of folders in the repository.

To learn how to create host groups and perform management tasks on the Sun Management Center topology, see Chapter 9, Maintaining the Sun Management Center Topology (Tasks). The procedures described in Chapter 9, Maintaining the Sun Management Center Topology (Tasks) are not required to perform audit tasks. However, you might want to create a hierarchy of host groups in the topology.

To learn how to navigate through the browser interface, see Appendix A, Change Manager Browser Interface Navigation (Reference).

## How to Access the Set Up Files Section and Appropriate Folder (Web Browser)

Note that the top of the Set Up Files section hierarchy is a folder.

1. To go to the Set Up Files section, click the Set Up Files tab in the general links area.

   The top-level Set Up Files page shows a table, which can contain files and folders. The table is a file manager.

2. Drill down to the appropriate folder.

   Click a folder name to go into that folder. Then, view the folder's contents. Continue to click folder names until you reach the folder or file you want.

## How to Create an Audit Rules File (Web Browser)

You create an audit rules file so that you can do the following:

- Build a manifest for a managed host

- Audit managed hosts by comparing manifests against a baseline manifest

1. If you are not already in the appropriate folder, see How to Access the Set Up Files Section and Appropriate Folder (Web Browser).

2. From the File Actions menu, choose New Audit Rules.

3. Supply the following information:

   - Choose a meaningful audit rules file name. For example, choose a name that describes the rules, `usr-only`. Add the `.brul` suffix to complete the audit rules file name, `usr-only.brul`.

   - Customize the sample rules in the Contents field. For more information about creating the rules file, see Audit Rules File Format.

4. When the audit rules are complete, click Save to create the audit rules file.

   Click Cancel to return to the previous page.

## How to Import an Audit Rules File to the Change Manager Repository (Web Browser)

Import an audit rules file to the Change Manager repository. The audit rules file is used to build manifests and audit managed hosts.

The time required to import a file to the Change Manager repository depends on the size of the file and the speed of the network.

1. If you are not already in the appropriate folder, see How to Access the Set Up Files Section and Appropriate Folder (Web Browser).

2. From the File Actions menu, choose Import Audit Rules.

3. Supply the following information:

   - Choose a meaningful audit rules file name. For example, choose a name that describes the type of rules or audit coverage, such as `usr-only`. Add the `.brul` suffix to complete the audit rules file name, `usr-only.brul`.

   - Path name of the rules file to import. Click Browse to find the rules file.

4. When the information is complete, click Import to copy the rules file to the Change Manager repository.

   Click Cancel to return to the previous page.

## How to Import a Manifest to the Change Manager Repository (Web Browser)

The manifests are created by the Build Manifests command.

The time required to import a file to the Change Manager repository depends on the size of the file and the speed of the network.

1. If you are not already in the appropriate folder, see How to Access the Set Up Files Section and Appropriate Folder (Web Browser).

2. From the File Actions menu, choose Import Manifest.

3. Supply the following information:

   - Manifest name. Choose a meaningful name. For example, choose a name that describes the audit rules used, the managed host's name, and the date and time of the audit. Add the `.bmft` suffix to complete the manifest name, `usr-only.host12.may122002.bmft`.

   - Path name to the manifest file to import. Click Browse to find the manifest.

4. When the information is complete, click Import to copy the manifest to the Change Manager repository.

   Click Cancel to return to the previous page.

## How to Access the Set Up Hosts & Jobs Section and Appropriate Administrative Domain and Host Group (Web Browser)

1. To go to the Set Up Hosts & Jobs section, click the Set Up Hosts & Jobs tab in the general links area.

   - If more than one administrative domain exists, you go to a page showing a table that lists the available administrative domains. Go to Step 2.

   - If only one administrative domain exists, the page shows a table that lists managed hosts and host groups in the default domain. Go to Step 3.

2. (Optional) Click the name of the administrative domain to use.

   Note –

   Use Sun Management Center to create a new administrative domain. See “Using Sun Management Center Administrative Domains” in Sun Management Center 3.5 User's Guide.

3. Drill down to the appropriate host group.

   Click a host group name to go into that host group. Then, view the host group's contents. Continue to click host group names until you reach the host group or managed host you want.

## How to Build Manifests for Managed Hosts (Web Browser)

1. If you are not already in the appropriate host group, see How to Access the Set Up Hosts & Jobs Section and Appropriate Administrative Domain and Host Group (Web Browser).

2. Select the managed hosts and host groups for which you want to build manifests.

   For example, select `host1` and `host2` by clicking the checkbox next to `host1` and `host2`.

3. From the Host Actions menu, choose Build Manifests.

4. Supply a meaningful job name.

   For example, the job name might be `Build manifests for host1 and host2`.

5. Determine when you want to run the job, either now or at another time.

   - To initiate the job immediately, click the Start Now radio button.

   - To run the job at a later time, specify the start date and start time.

     - Start date. Click the date or specify the date in the mm/dd/yyyy format.

       mm and dd are two-digit forms for the month and day. yyyy is the four-digit form for the year.

     - Start time. Choose the start time from the hour and minute pull-down menus.

6. Specify the path name of the audit rules file to use.

   Click Browse to open a file chooser to help in the search for the audit rules file in the Change Manager repository.

   To add an audit rules file to the Change Manager repository, see the following sections:

   - How to Create an Audit Rules File (Web Browser)

   - How to Import an Audit Rules File to the Change Manager Repository (Web Browser)

   See the description of the Audit Rules File Format.

   For example, the audit rules file is `/files/web-server/usr-only.brul`.

7. Specify the path name of the folder in which to store the manifest.

   For example, store the resulting manifests in the `/files/web-server` folder.

8. Supply the prefix for the manifest file name.

   The prefix helps identify the manifest.

   For example, the prefix name might be `usr-only` to indicate the rules file used to generate the manifests. The resulting manifest file name for `host1` might look like `usr-onlyhost1.brul`.

9. Click Submit to build the manifests, or click Cancel to return to the previous page.

   This operation takes some time to complete.

10. When the operation completes, view the manifests.

    1. Click the Set Up Files tab at the top of the web page to go to the Set Up Files section.

    2. Drill down to the folder where you stored the manifests.

    3. Click the manifest name to go to its property page.

       You can view one manifest at a time.

       If the manifest is very large, use the Prev and Next buttons to navigate between pages.

    4. To return to the folder that holds the manifests, click Back.

       Repeat Steps 10c and 10d to view more manifests.

For example, Suzi can schedule a job to build manifests for the `/hosts/web-server/apache/host1` and `/hosts/web-server/apache/host2` managed hosts. The manifests will be stored in the `/files/web-server` folder. Each file name will use `usr-only` as the prefix. The audit rules file to be used is called `/files/web-server/usr-only.brul`. The operation is scheduled to start on June 27th at 3:00 a.m.

## How to Audit Managed Hosts (Web Browser)

Audit managed hosts by comparing them to a baseline manifest.

1. If you are not already in the appropriate host group, see How to Access the Set Up Hosts & Jobs Section and Appropriate Administrative Domain and Host Group (Web Browser).

2. Select the managed hosts and host groups to compare.

   For example, select `host1` and `host2` by clicking the checkbox next to `host1` and `host2`.

3. From the Host Actions menu, choose Audit.

4. Supply a meaningful job name.

   For example, the job name might be `Compare host1 and host2`.

5. Determine when you want to run the job, either now or at another time.

   - To initiate the job immediately, click the Start Now radio button.

   - To run the job at a later time, specify the start date and start time.

     - Start date. Click the date or specify the date in the mm/dd/yyyy format.

       mm and dd are two-digit forms for the month and day. yyyy is the four-digit form for the year.

     - Start time. Choose the start time from the hour and minute pull-down menus.

6. Specify the path name of the audit rules file to use.

   Click Browse to open a file chooser to help in the search for the audit rules file in the Change Manager repository.

   To add an audit rules file to the Change Manager repository, see the following sections:

   - How to Create an Audit Rules File (Web Browser)

   - How to Import an Audit Rules File to the Change Manager Repository (Web Browser)

   See the description of the Audit Rules File Format.

   For example, the audit rules file is `/files/web-server/usr-only.brul`.

7. To specify the baseline manifest, do one of the following:

   - Specify the path name of the baseline manifest.

   - Click Browse to find the baseline manifest.

   For example, the baseline manifest is `/files/web-server/usr-only.baseline.bmft`.

8. To specify the report file, do one of the following:

   - Specify the path name of the report file.

   - Click Browse to choose the report file in which to store the results.

   For example, the report file is stored in `/files/web-server/host1-host2.usr-only.compare.txt`.

9. Click Submit to initiate the manifest comparison, or click Cancel to return to the previous page.

   The compare operation takes some time to complete.

10. When the operation completes, view the generated comparison reports.

    1. Click the Set Up Files tab at the top of the web page to go to the Set Up Files section.

    2. Drill down to the folder where you stored the comparison reports.

    3. Click the comparison report name to go to the property page.

       You can view one comparison report at a time.

       If the comparison report is very large, use the Prev and Next buttons to navigate between pages.

    4. To return to the folder that holds the comparison reports, click Back.

       Repeat Steps 10c and 10d to view more comparison reports.

## How to Get the Software Status of Managed Hosts (Web Browser)

1. If you are not already in the appropriate host group, see How to Access the Set Up Hosts & Jobs Section and Appropriate Administrative Domain and Host Group (Web Browser).

2. Select the managed hosts and host groups for which you want to get the software status.

   For example, select `host1` and `host2` by clicking the checkbox next to `host1` and `host2`.

3. From the Host Actions menu, choose Get Software Status.

4. Supply a meaningful job name.

   For example, the job name might be `Get Software Status for host1 and host2`.

5. Determine when you want to run the job, either now or at another time.

   - To initiate the job immediately, click the Start Now radio button.

   - To run the job at a later time, specify the start date and start time.

     - Start date. Click the date or specify the date in the mm/dd/yyyy format.

       mm and dd are two-digit forms for the month and day. yyyy is the four-digit form for the year.

     - Start time. Choose the start time from the hour and minute pull-down menus.

6. To specify the report file, do one of the following:

   - Specify the path name of the report file.

   - Click Browse to choose the report file in which to store the results.

   For example, the report file is stored in `/files/web-server/host1-host2.software.status.txt`.

7. Click Submit to get the software status, or click Cancel to return to the previous page.

   The software status operation takes some time to complete.

8. When the operation completes, view the generated software status reports.

   1. Go to the Set Up Files section.

      Click the Set Up Files tab at the top of the page.

   2. Drill down to the folder where you stored the software status reports.

   3. Click the name of the software status report to go to the property page.

      You can view one software status report at a time.

      If the software status report is very large, use the Prev and Next buttons to navigate between pages.

   4. To return to the folder that holds the software status reports, click Back.

      Repeat Steps 8c and 8d to view more software status reports.

# Auditing Software Configurations by Using the Command-Line Interface (Task Map)

The following table identifies the procedures you need to audit managed hosts. See the changemgr(1MCM) man page.

Task | Description | For Instructions
--- | --- | ---
Import an audit rules file to the Change Manager repository. | Import an existing audit rules file to the Change Manager repository. | See How to Import Audit Rules Files to the Change Manager Repository (Command Line).
Import manifests to the Change Manager repository. | Import existing manifests to the Change Manager repository. These manifests can be used in comparisons. | See How to Import Manifests to the Change Manager Repository (Command Line).
Build manifests for managed hosts. | Build manifests for managed hosts. Each manifest includes a list of entries, an entry per file cataloged. Each file entry includes the file name and several file attribute values. | See How to Build Manifests for Managed Hosts (Command Line).
Audit managed hosts. | Audit managed hosts by comparing them against a baseline manifest. The existence of files, as well as file attribute values are compared. | See How to Audit Managed Hosts (Command Line).
Get software status of managed hosts. | Get information about the packages and patches installed on the managed hosts. | See How to Get the Software Status of Managed Hosts (Command Line).

# Auditing Software Configurations by Using the Command-Line Interface

This section describes how to use the command-line interface to audit managed hosts.

To learn how to create folders and perform management tasks in the Change Manager repository, see Chapter 8, Maintaining the Change Manager Repository (Tasks). The procedures described in Chapter 8, Maintaining the Change Manager Repository (Tasks) are not required to perform audit tasks. However, you might want to create a hierarchy of folders in the repository.

To learn how to create host groups and perform management tasks on the Sun Management Center topology, see Chapter 9, Maintaining the Sun Management Center Topology (Tasks). The procedures described in Chapter 9, Maintaining the Sun Management Center Topology (Tasks) are not required to perform audit tasks. However, you might want to create a hierarchy of host groups in the topology.

## How to Import Audit Rules Files to the Change Manager Repository (Command Line)

The audit rules file is used to build manifests and audit managed hosts.

The time required to import a file to the Change Manager repository depends on the size of the file and the speed of the network.

1. Determine where the audit rules file exists and where to store it.

   For example, copy the audit rules file from `/net/test1/home/suzi/usr-only.brul` to the `web-server` folder.

2. Import an audit rules file to the Change Manager repository by using one of these `changemgr import` commands.

   - The following command line imports one file at a time. You can also use this command line to rename the file.

         $ changemgr import [ -u username ] [ -p file ] filepath[.type] \
         relfilepath.type

   - The following command line imports several files to a folder simultaneously.

         $ changemgr import [ -u username ] [ -p file ] filepath.type ... \
         reldirpath

   `-u` username

     Specifies the user name to authenticate. If this option is not specified, the user is the current UNIX user.

   `-p` file

     file consists of a single line, which contains the password. If file is `-`, then the user can supply the password as standard input.

     If the `-p` option is not supplied, then the `changemgr` command prompts the user for his password.

   filepath

     Specifies an absolute or relative path to a file. This file path is not within the Change Manager repository.

   reldirpath

     Specifies the path to a folder that is relative to the top of the Change Manager repository.

   relfilepath

     Specifies the path to a file, not including a folder, that is relative to the top of the Change Manager repository.

   .type

     Specifies the file name suffix that represents the file type. An audit rules file uses the `.brul` suffix.

   Choose a name that indicates the type of audit specified by the audit rules file. Use the `.brul` suffix. For example, create an audit rules file named `usr-only.brul`, which indicates that only files from `/usr` are cataloged.

### Example—Importing an Audit Rules File to the Change Manager Repository

Suzi copies the audit rules file called `/net/test1/home/suzi/usr-only.brul` to the `web-server` folder of the repository. She renames the file to be `usr_only.brul`.

    $ changemgr import /net/test1/home/suzi/usr-only.brul \
    /web-server/usr_only.brul

### Example—Importing Audit Rules Files to the Change Manager Repository

Suzi copies the audit rules files called `/net/test1/home/suzi/usr-only.brul` and `/net/test1/home/suzi/opt-only.brul` to the `/` folder of the repository.

    $ changemgr import /net/test1/home/suzi/usr-only.brul \
    /net/test1/home/suzi/opt-only.brul /

## How to Import Manifests to the Change Manager Repository (Command Line)

The manifests are created by the `changemgr manifest` command, which performs a per-file audit of a managed host.

The time required to import a file to the Change Manager repository depends on the size of the file and the speed of the network.

1. Determine where the manifest exists and where to store it.

   For example, copy the manifest from `/net/test1/home/suzi/host1-usr-only.bmft` to the `web-server` folder.

2. Import a manifest to the Change Manager repository by using one of these `changemgr import` commands.

   - The following command line imports one file at a time. You can also use this command line to rename the file.

         $ changemgr import [ -u username ] [ -p file ] filepath[.type] \
         relfilepath.type

   - The following command line imports several files to a folder simultaneously.

         $ changemgr import [ -u username ] [ -p file ] filepath.type ... \
         reldirpath

   For descriptions of the options, see How to Import Audit Rules Files to the Change Manager Repository (Command Line).

   Choose a name that indicates the name of the audited managed host and the type of audit specified by the audit rules file. Use the `.bmft` file suffix. For example, copy a manifest named `host1-usr-only.bmft`, which indicates that only files from `/usr` are cataloged for the `host1` managed host.

### Example—Importing a Manifest to the Change Manager Repository

Suzi copies the manifest called `/net/test1/home/suzi/host1-usr-only.bmft` to the `web-server` folder. She renames the file to be `host1_usr_only.bmft`.

    $ changemgr import \
    /net/test1/home/suzi/host1-usr-only.bmft \
    /web-server/host1_usr_only.bmft

### Example—Importing Manifests to the Change Manager Repository

Suzi copies the manifests called `/net/test1/home/suzi/host1-usr-only.bmft` and `/net/test1/home/suzi/host1-opt-only.bmft` to the `/` folder.

    $ changemgr import \
    /net/test1/home/suzi/host1-usr-only.bmft \
    /net/test1/home/suzi/host1-opt-only.bmft /

## How to Build Manifests for Managed Hosts (Command Line)

1. Determine which managed hosts you want to audit.

   For example, audit the `/web-server/host1` and `/web-server/host2` managed hosts.

2. Build manifests for the managed hosts.

       $ changemgr manifest [ -u username ] [ -p file ] [ -d domain ] \
       -o relfilepathprefix [ -r relfilepath.brul ] topopath ...

   `-u` username

     Specifies the user name to authenticate. If this option is not specified, the user is the current UNIX user.

   `-p` file

     file consists of a single line, which contains the password. If file is `-`, then the user can supply the password as standard input.

     If the `-p` option is not supplied, then the `changemgr` command prompts the user for his password.

   `-d` domain

     Specifies the administrative domain on which to operate. In the context of a session, the default is the domain specified for the session. If no domain is specified, domain is the user's home domain. By default, domain is the user's home domain.

   `-o` relfilepathprefix

     Specifies the prefix to be used when creating the output inventories. The name of the managed host and the `.bmft` suffix are appended to the prefix specified to form the name of the resulting manifest.

   `-r` `relfilepath.brul`

     Specifies the audit rules file to use to create the manifest.

   topopath

     Specifies the path to a managed host or host group that is relative to the top of the selected administrative domain.

### Example—Building Manifests for Managed Hosts

Suzi builds manifests for the `/web-server/host1` and `/web-server/host2` managed hosts. She stores the files in the `/web-server` folder with a manifest file prefix of `usr-only`. The resulting file names are `/web-server/host1.bmft` and `/web-server/host2.bmft`.

    $ changemgr manifest -o /web-server/ -r usr-only.brul \
    /web-server/host1 /web-server/host2

Note –

If the argument to `-o` is a folder, terminate the argument with a slash. For example, if the argument to `-o` is `/web-server/baseline`, then `baseline` is prefixed to manifests created in the `/web-server` folder. If you use this prefix, you might see a manifest with a name like `/web-server/baselinehost1.bmft`.

## How to Audit Managed Hosts (Command Line)

The baseline manifest does not need to be built on the managed host. You can build a baseline manifest on a master system before creating the Solaris Flash archive.

1. Determine which managed hosts you want to audit.

   For example, audit the `/web-server/host1` and `/web-server/host2` managed hosts.

2. Audit managed hosts.

       $ changemgr audit [ -u username ] [ -p file ] [ -d domain ] \
       -o relfilepath.txt [ -r relfilepath.brul ] relfilepath.bmft topopath ...

   `-o` `relfilepath.txt`

     Specifies where to write the report on manifest differences.

   `-r` `relfilepath.brul`

     Specifies the audit rules file to use to create the manifest.

   `relfilepath.bmft`

     Specifies the path to the manifest file that is relative to the top of the Change Manager repository.

   topopath

     Specifies the path to a managed host or host group that is relative to the top of the selected administrative domain.

   For descriptions of the other options, see How to Build Manifests for Managed Hosts (Command Line).

### Example—Auditing Managed Hosts

Suzi audits the `/web-server/host1` managed host. She stores the report in the `/web-server/usr-only.txt` file. She audits the managed host by comparing its manifest against the baseline manifest called `/web-server/baseline.bmft`.

    $ changemgr audit suzi \
    -o /web-server/usr-only.txt -r usr-only.brul \
    /web-server/baseline.bmft /web-server/host1

To understand how to interpret the report results, see Comparison Report Format.

## How to Get the Software Status of Managed Hosts (Command Line)

1. Determine the managed hosts for which you want to get the software status.

   For example, get the software status for the `/web-server/host1` and `/web-server/host2` managed hosts.

2. Get the software status for a managed host.

       $ changemgr info [ -u username ] [ -p file ] [ -d domain ] \
       -o relfilepath.txt topopath ...

   `-o` `relfilepath.txt`

     Specifies the path of the file that contains the software status report.

   topopath

     Specifies the path to a managed host or host group that is relative to the top of the selected administrative domain.

   For descriptions of the other options, see How to Build Manifests for Managed Hosts (Command Line).

### Example—Getting the Software Status of Managed Hosts

Suzi gets the software status for the `/web-server/host1` managed host. She stores the report in the `/web-server/software-status.txt` file.

    $ changemgr info -o /web-server/software-status.txt \
    /web-server/host1

- Previous: Chapter 5 Installing Solaris Flash Archives on Managed Hosts (Tasks)
- Next: Chapter 7 Monitoring Jobs (Tasks)

- © 2010, Oracle Corporation and/or its affiliates