4 Managing Your Oracle ASR Environment

This chapter contains all procedures and other information required to manage the ASR environment.

Note:

To enter the ASR prompt (asr>) as root, type asr on the command line. See Installing ASR Manager Software for instructions for setting the PATH environment variable.

The following topics are discussed.

4.1 ASR Manager Auto Update

Beginning with ASR 4.3.2, Oracle ASR, by default, checks the ASR software update server for any software updates. If there is a newer version, it will:

  • Automatically download the latest Oracle ASR software bundle.

    See Verifying Your Network Connection for details on how to test your connection.

  • Install the new version of the software.

  • Send an e-mail notification that installation is complete or if a problem was encountered.

  • Store the previous version of Oracle ASR to the /var/opt/asrmanager/backup/asrm/ directory.

Note:

If using an ASR Manager Relay, starting with ASR 5.4, Auto Update will work for the ASR Manager behind the relay (see Enabling HTTP Receiver for ASR Manager Relay, Solaris 11, and SDP2). This feature does not work for ASR Managers running versions earlier than 5.4. Both ASR Managers, the one behind the relay and the one facing transport.oracle.com, need to be at ASR 5.4 or later.

The following topics are presented:

4.1.1 Disabling and Enabling ASR Auto Update

If necessary, you can disable the Auto Update feature:

asr> disable_autoupdate

To enable ASR Auto Update:

asr> enable_autoupdate

4.1.2 Using Auto Update to Manually Upgrade ASR Manager Software

Note:

Using Auto Update to upgrade to ASR 5.x: Auto Update is available to upgrade to ASR 5.x, depending on your currently installed ASR version:
  • If your installed version is ASR 4.9:

    Then Auto Update will automatically upgrade your ASR Manager software to version 5.x. If Auto Update is disabled, then you can manually run Auto Update by following the instructions in this section.

  • If your installed version is ASR 4.3.2 through ASR 4.8.1:

    Then Auto Update must first upgrade your ASR Manager software to ASR 4.9. Once successfully upgraded to ASR 4.9, you must run Auto Update again to upgrade to ASR 5.x. Follow the instructions in this section to run Auto Update manually.

Run the following command to determine the version of your installed ASR Manager software:

asr> show_version

WARNING:

ASR Auto Update will not work for ASR Managers using either of these two end points:

  • transport.sun.com (141.146.156.47)

  • transport.sun.co.uk (141.146.156.48)

You may need to update your configuration to use transport.oracle.com (141.146.1.169).

Instructions for how to determine if this change is needed and how to make the change is provided in My Oracle Support (MOS) Doc ID 1954819.1:

https://support.oracle.com/rs?type=doc&id=1954819.1

If Auto Update is disabled, you will need to upgrade Oracle ASR manually. You can use the Auto Update feature to download and install future versions of Oracle ASR manually:

asr> autoupdate

Output of the autoupdate command will look like this:

asr> autoupdate

This command will update the ASR Manager software with the latest bundles available on Oracle ASR Infrastructure. Auto Update process will take up to 5 minutes to complete. During this time, assets attached to ASR Manager will not be monitored. Do you want to proceed with Auto Update? [y/n]

Enter y to proceed. The upgrade continues with the following output:

New SWASR package 5.0.0.0.0 is available for update.
 
Started ASR Manager software Auto Update.
Autoupdate process will take approximately 5 - 10 minutes to complete. You may run "asr show_version" to view the Auto Update status.
Please wait until you receive the Auto Update complete status email before running any other asr commands.
An email notification will be sent to asr-contact@mycompany.com with completion status.

Note:

For Linux, the environment variable SELINUX can be set to Enforcing mode which will not allow the automatic update of RPM packages. If you try the Auto Update feature with this environment variable set to Enforcing, the following warning message will display:
Warning: SELINUX environment variable is set to "enforcing" mode on this server. ASR Manager Auto Update functionality will not work unless the SELINUX enviornment variable is set to "permissive"

4.1.3 Other ASR Auto Update Commands

Auto Update commands include:

  • show_version: Shows ASR Manager and rules version information. See ASR Auto Update show_version Examples for sample output of the show_version command.

  • autoupdate: Executes the Auto Update feature to update the ASR Manager and rules bundle software.

  • enable_autoupdate: Enables the ASR Auto Update feature.

  • disable_autoupdate: Disables the ASR Auto Update feature.

4.1.4 ASR Auto Update show_version Examples

You can run the ASR show_version command any time. There are several possible output examples, depending on your configuration:

Auto Update Enabled

When the ASR Auto Update feature is enabled, the output of the show_version command includes information about the installed ASR software versions, Auto Update statistics and status, and a history of Auto Update activity (such as, ASR Manager updates and rules definitions updates).

When you run the show_version command, you should expect to see output like this:

asr> show_version

ASR Manager version: 5.0.0

Rules definitions version: 5.0.0.0

Auto Update Statistics
==========================
Last Run Time: 2014-09-14 16:48:13.064
Last Run Status: ASR Manager software up to date and running the latest version.
Next Run Time: 2014-09-15 16:48:13.064
 
There are no updates available on Oracle ASR Infrastructure.

Auto Update Status
==========================
Auto Update functionality is enabled.

Auto Update History
==========================
ASR Manager Auto Update history
-------------------------------------
ASR Manager Auto Update started at: 2014-09-15 10:14:08.908
ASR Manager Auto Update completed at: 2014-09-15 10:14:08.913
ASR Manager Auto Update result: COMPLETE_SUCCESS
ASR Manager updated from version: 5.0.0
ASR Manager updated to version: 5.0.0

ASR Manager Services
--------------------
ASR Notification Trap is disabled.
Remote Request feature is enabled.

Auto Update Disabled

Even though the ASR Auto Update feature is disabled, you can still use the show_version command for information about the installed ASR software, including statistics and status.

When you run the show_version command, you should expect output like this:

asr> show_version

ASR Manager version: 4.4

Rules definitions version: 4.4.0

Auto Update Statistics
==========================
Last Run Time: 2013-04-03 11:21:11.283
Last Run Status: Auto Update functionality is disabled.
Next Run Time: 2013-04-03 11:23:11.283

Auto Update Status
==========================
Auto Update functionality is disabled.
Please refer to the My Oracle Support Doc Id: 1503107.1 for instructions on Auto Update of ASR Manager software.

ASR Manager Services
--------------------
ASR Notification trap is disabled.
Remote Request feature is disabled.

Auto Update Enabled, ASR Manager Unregistered

For ASR to function properly, the ASR Manager must be registered. See Registering the ASR Manager for more information. You can still use the show_version command to view limited information about ASR software versions and Auto Update status.

If your ASR Manager is unregistered and you run the show_version command, the output should look like this:

asr> show_version

Software Versions
=================
ASR Manager version: 4.4

Rules definitions version: 4.4.0
 
Oracle ASR Infrastructure is not available.
 
Auto Update Status
==================
Auto Update functionality is enabled.

New Software Available

If a new software download is available (including any new rules definitions), you can use the show_version command to review the versions. Output should look like this:

asr> show_version

Software Versions
=================
ASR Manager version: 4.4

Rules definitions version: 4.4.0

New asrmanager package 4.4.0.0.0 is available for update.

Auto Update Status
==================
Auto Update functionality is enabled.

4.2 Manually Upgrading ASR Manager Software

Note:

As part of the ASR 5.0 release, the following directories have changed:
  • The /opt/SUNWswasr directory is replaced by the /opt/asrmanager directory.

  • The /var/opt/SUNWsasm directory is replaced by the /var/opt/asrmanager directory.

Follow the steps below to upgrade the ASR Manager software manually:

  1. Uninstall ASR. Refer to Uninstalling ASR Manager for details.

  2. Obtain the new ASR package. Refer to Verifying Software Requirements for download instructions.

  3. Install the new ASR package. Refer to Installing ASR Manager Software. Be sure to register and activate the ASR Manager, as explained in the referenced instructions.

4.3 ASR Manager Registrations

Beginning with ASR 4.8, the list_registration command provides a list of all registered ASR Manager hosts. Use this command to verify that your installed ASR Manager is registered with Oracle ASR Infrastructure or ASR Manager relay. To generate the information, run:

asr> list_registration

The following examples show a sample output of the list_registration command:

Sample 1

This ASR Manager is registered with Oracle ASR Infrastructure.
The following ASR Manager(s) are registered with this ASR Manager Relay:
ASR Manager Host : 10.12.12.11
ASR Manager Host : 10.12.12.13

Sample 2

This ASR Manager is registered with Oracle ASR Infrastructure.

Sample 3

This ASR Manager is registered with ASR Manager relay http://host123.test.com:8928/asr

4.4 ASR Audit Logging

When the ASR Manager sends or attempts to send a message about an ASR Asset, that message and its corresponding status is included in an audit log in the following directory:

/var/opt/asrmanager/log/auditlog

Each day, a new audit log file is created to collect all unique activity from the ASR Manager. By default, a maximum of 30 days of log files are maintained. After 30 days, the oldest log file is deleted.

You can use these logs to perform troubleshooting analysis on your qualified ASR Assets. A typical log file summarizes all ASR activity for any ASR Asset associated with the ASR Manager. Duplicate activity for a single asset is not recorded. For example, if a message from the ASR Manager fails to be sent to the Oracle ASR Infrastructure, then each retry attempt will not be recorded in the log.

By default, ASR Audit Logging is enabled. Use the following commands from the ASR Manager to configure and modify the ASR Audit Logging feature:

ASR Command Description
asr> enable_audit_log
Enable audit logging. Messages are written to audit log in the /var/opt/asrmanager/log/auditlog directory.
asr> disable_audit_log
Disable audit logging. Messages are not written to audit log.
asr> set_audit_log_days [1-30]
Set how many days of audit logs to keep before rolling over (accepts any number between 1 and 30).
asr> get_audit_log_days
Get how many days of audit logs are kept.
asr> enable_asr_manager
Enable ASR Manager. Messages are sent to the Oracle ASR Infrastructure. By default, the ASR Manager is enabled.
asr> disable_asr_manager
Disable ASR Manager. Messages are not sent to Oracle ASR Infrastructure, but are logged in the /var/opt/asrmanager/log/auditlog directory.

Note:

ASR Audit Logging is enabled by default, regardless if your ASR Manager is disabled or unregistered.

4.5 ASR Asset Management Overview

This section provides a variety of commands and procedures for managing ASR Assets. Figure 4-1 shows the status transition of ASR Asset:

Figure 4-1 ASR Asset Status Transition

Surrounding text describes Figure 4-1 .

4.6 ASR E-mails

This section describes the types of e-mails generated by ASR. For examples of the e-mails generated by ASR, see Auto Service Request (ASR) Email Examples (Doc ID 1963725.1) available (Chinese, Japanese, and Korean versions of this document are available) in My Oracle Support (https://support.oracle.com):

https://support.oracle.com/rs?type=doc&id=1963725.1

E-mail generated by ASR is sent to:

  • The e-mail address of the My Oracle Support account associated with the ASR installation.

  • The contact assigned to the asset in My Oracle Support.

  • A distribution list assigned to the asset in My Oracle Support (optional)

Table 4-1 shows the various recipients of the typical ASR e-mail, depending on the reason for sending it, where:

  • Registration user: The e-mail address used to register the asset. For the ASR Manager, this is the e-mail address entered for the asr register command.

  • My Oracle Support Contact: The My Oracle Support (MOS) user assigned to the asset as the contact.

  • MOS Dist List: a comma-separated distribution list of e-mail addresses in My Oracle Support.

  • Support Identifier Administrators: The My Oracle Support users who are administrators of the Support Identifier associated with the asset.

Table 4-1 ASR E-mail Types and Recipients

Notification Type ASR E-mail Recipient
Registration User Contact MOS Dist List Support Identifier Admins Other

Auto Update

Yes

Yes

   

Auto Update user SSO (typically the same as activation SSO)

Heartbeat failure

Yes

Yes

Yes

 

Registration SSO (if applicable)

ASR rules out of date

Yes

       

ASR Manager out of date

Yes

       

SR create delayed

Yes

Yes

Yes

   

SR create

Yes

Yes

Yes

   

SR create (partner)

No

Yes

Yes

No

 

SR failed

Yes

Yes

Yes

Yes

 

SR test (non-Pillar)

Yes

Yes

Yes

   

SR test (Pillar)

Yes

Yes

Yes

Yes

 

SR update

Yes

Yes

Yes

   

Status Pending MOS

Yes

Yes

Yes

Yes

 

Status Pending Contract

Yes

Yes

Yes

Yes

 

Status Change

Yes

       

Activation failed

Yes

       

The types of e-mail generated by ASR include:

  • ASR Activation E-mail and Status of ASR Assets

    An e-mail indicating success or failure of ASR activation is sent. Instructions for any user action is included as needed. ASR Asset status is available in My Oracle Support.

  • ASR Service Request E-mail

    Service Request e-mails are generated whenever a Service Request is created at Oracle that results from a hardware fault detection on any of your ASR-enabled systems. Failure e-mails indicate what issues may have prevented a Service Request from being created upon receipt of a hardware fault from ASR.

    All Service Request e-mails are sent to the Primary and Preferred Technical Contact associated with the system reporting a potential fault. For more on how this contact is established or changed, refer to View Status from My Oracle Support.

    Note:

    Any e-mail sent from Blade ASR Assets have a different e-mail format.
  • Heartbeat Failure Notification

    If the ASR Heartbeat detects a communications error to Oracle, an e-mail is sent.

  • Fault Rules Out of Date E-mail

    This e-mail is sent if ASR detects that its fault rules are out of date.

4.6.1 Create Test Alert

You can test the end-to-end functionality of ASR by simulating a hardware fault. The end result is an e-mail sent to the e-mail address of the My Oracle Support account associated with the ASR installation.

Note:

A test alert should be run only after the asset has been enabled in My Oracle Support. See Approve ASR Assets in My Oracle Support for more information.

4.6.1.1 Create Test Alert - ILOM

Note:

Only valid for ILOM 3.0 or later.

To generate a test alert from ILOM:

  • From the ILOM GUI: In the Alert Settings page, select the alert you want to test and then click the Send Test Alert button. ILOM generates a test event for the selected alert. If configured properly, you will receive a test Service Request e-mail.

  • From the ILOM CLI: Type one of the following command paths to set the working directory:

    • For a rack-mounted server SP, type: cd /SP/alertmgmt/rules

    • For a Blade server SP, type: cd /CH/BLn/SP/alertmgmt/rules

    • For a chassis CMM, type: cd /CMM/alertmgmt/CMM/rules

    Type the following command to generate a test alert:

    ->set testalert=true

4.6.1.2 Create Test Alert - Solaris 11

To send a test e-mail on an ASR Asset for Solaris 11, run the following command:

asradm send test email.address@mycompany.com

Note:

The ASR Asset Menu (asrassetmenu.sh) is not available on ASR Assets running Solaris 11.

4.6.1.3 Create Test Alert - Solaris 10

To send a test e-mail on an ASR Asset for Solaris 10:

  1. Execute the asrassetbundle shell script:

    • If on an ASR Asset:

      cd /untar_location_of_assetbundle/asrassetbundle

      ./asrassetmenu.sh

      Note:

      If you have issues finding the asrassetbundle directory, go to "Installing the ASR Asset Bundle - Solaris 10 Only" for more information.
    • If on the ASR Manager system:

      cd /opt/asrmanager/asrassetbundle/asrassetbundle
      ./asrassetmenu.sh
      
  2. From the ASR Asset Menu, type 8.

  3. Whether you are on an ASR Asset or the ASR Manager, enter the IP address of the ASR Manager.

  4. Enter the SNMP port used to send hardware telemetry to the ASR Manager. The default port is 162.

  5. When the test alert is sent, check the e-mail contact of the My Oracle Support account associated with the ASR installation.

Note:

If this test fails on Solaris 10, be sure that the /usr/sfw/bin/snmptrap exists and Solaris netsnmp library is installed on the asset.

4.7 Add/Remove Telemetry Traps from ASR Asset(s)

The procedures in this section explain how to enable or disable telemetry trap destinations on ASR Asset(s). A trap destination is where the telemetry data is sent. During ASR installation, each asset is configured by setting trap destinations from the asset system. In all cases, the trap destination specified is the ASR Manager system, which centrally collects the telemetry data sent from ASR Asset(s). Even if the ASR Manager itself is configured to send telemetry data, its trap destination must be this same ASR Manager.

Reasons for enabling traps include:

  • Traps were not enabled during installation.

  • Traps need to be enabled as part of troubleshooting tasks.

Reasons for disabling traps include:

  • IP address of ASR Manager changed. If this situation occurs, you need to disable the traps, then re-enable the traps with the new IP information.

  • Stopping the use of ASR and/or you want to minimize telemetry traffic.

Before continuing, be mindful of the following:

4.7.1 Add/Remove Telemetry Traps from Solaris 10 FMA Systems

Follow the procedure below to add or remove a trap destination for systems using Solaris 10 FMA telemetry.

  1. To add a Solaris FMA telemetry trap, go to "Enabling FMA Telemetry for Solaris 10 ASR Assets".

  2. To remove a trap destination, make sure you are logged in as root on the system whose telemetry trap you wish to remove. This could be either an ASR Manager or an ASR Asset system. Keep in mind that this process stops telemetry from being sent to the ASR Manager. It does not remove the telemetry software itself nor disables its operation (for example, FMA).

  3. Go to the directory where you previously untarred the ASR Asset Bundle file, and then go to the specific ASR Asset Bundle directory, if needed. For example:

    • If on an ASR Asset:

      cd /file_copy_location/asrassetbundle

    • If on the ASR Manager system:

      cd /opt/asrmanager/asrassetbundle/asrassetbundle

    Note:

    Refer to "Installing the ASR Asset Bundle - Solaris 10 Only" if you have issues locating the asrassetbundle directory and/or asrassetmenu.sh script (below).
  4. Launch the ASR Asset Menu:

    ./asrassetmenu.sh
    
    Welcome to the ASR asset menu
    ----------------------------------------------
    1) Add a trap-destination to FMA agent
    2) Remove a trap-destination from FMA agent
    3) List FMA agent trap-destinations
    4) Test event to verify ASR connectivity
    5) Exit
     
    Please enter your selection [1-5]
    
  5. Select 5 to remove the FMA trap destination.

  6. When prompted, ”. . . enter the number of the trap-destination to remove,” enter the list number of the IP address of the ASR Manager.

    Note:

    If you are removing an FMA trap, enter the listed IP address with the port number (for example, 192.20.77.192:162).
  7. The trap is then removed from the system and all telemetry sent from Solaris FMA to the ASR Manager is stopped.

4.7.2 Add/Remove Telemetry from Solaris 11 FMA Systems

Follow the procedure below to add or remove registration for systems using Solaris 11 FMA telemetry.

  1. To add Solaris FMA telemetry, see "Enabling FMA Telemetry for Solaris 11 ASR Assets".

  2. To delete the ASR Manager registration, run:

    asradm unregister
    

4.7.3 Add/Remove Telemetry Traps from ILOM Systems

To add or remove an ILOM trap, refer to "Enabling ILOM Telemetry". This referenced procedure can be used to add or remove traps. If removing a trap, use the following parameters:

  • If using the ILOM GUI interface, either remove the entire alert rule destination or set the Level parameter to Disable.

  • If using the command line interface, set the Level parameter to Disable. Also, be sure to specify the correct alert rule (1 to 15) to disable.

4.7.4 Add/Remove Telemetry Traps from M-Series Systems (XSCF)

To add or remove telemetry traps on systems that have XSCF telemetry (Sun M-Series), refer to "Enabling M-Series XSCF Telemetry". This referenced procedure can be used to add or remove traps.

4.8 ASR Backup and Restore

ASR Backup

  1. Verify all information is in the database that is activated:

    asr> list_asset
    
  2. Stop ASR Manager so that data does not change in middle of backup:

    • For Solaris, run: svcadm disable asrm

    • For Linux, run: service asrm stop

  3. Back up the database directory. Run:

    tar -cvf db.tar.bz /var/opt/asrmanager/db
    
  4. Create a backup of the ASR configuration. Run the following commands for your installed version of ASR:

    • For ASR 5.0 and later:

      tar -cvf configuration.tar.bz /var/opt/asrmanager/configuration
      
    • For ASR 4.9 and earlier:

      tar -cvf configuration.tar.bz /var/opt/SUNWsasm/configuration
      
  5. Copy both db.tar.bz and configuration.tar.bz files to their proper backup destination.

  6. Restart ASR Manager. Run:

    • For Solaris, run: svcadm enable asrm

    • For Linux, run: service asrm start

ASR Restore

  1. Install the ASR Manager:

    • For Solaris, run:

      pkgadd -d <asrmanager-version-timestamp>.pkg
      
    • For Linux, run:

      rpm -i <asrmanager-version-timestamp>.rpm
      

    Note:

    Download and install the latest packages to upgrade to the latest version of the ASR Manager. See Verifying Software Requirements for more information.
  2. Stop ASR Manager to restore files:

    • For Solaris, run: svcadm disable asrm

    • For Linux, run: service asrm stop

  3. Restore the files from backup:

    1. Remove files /var/opt/asrmanager/configuration and /var/opt/asrmanager/db

    2. Copy backup data to /var/opt/asrmanager/

    3. Extract the tar files (both Solaris and Linux):

      tar -xvf configuration.tar.bz
      tar -xvf db.tar.bz
      
  4. Verify the files have been correctly extracted. Run:

    ls /var/opt/asrmanager/

  5. Restart ASR Manager. Run:

    • For Solaris, run: svcadm enable asrm

    • For Linux, run: service asrm start

  6. Register the backup configuration:

    asr> register
    

    Note:

    If you are running the latest version of ASR and if host name of the restored ASR Manager and My Oracle Support account) login have not changed, then you can stop here. Steps 7 and 8 are not required.
  7. Remove old entries from the My Oracle Support backend to associate correctly:

    asr> send_deactivations -a
    
  8. Add new entries to the My Oracle Support backend:

    asr> send_activations -a
    
  9. List ASR Assets. Run:

    asr> list_asset
    

4.9 Unregister ASR

When you installed ASR, you registered it with the transport server (transport.oracle.com) using your My Oracle Support username. The registration is performed on the ASR Manager system, as is an unregister if required. Reasons for unregistering ASR can include the following:

  • If your current My Oracle Support account is no longer valid, as in a case when the e-mail contact is no longer associated with the company. The e-mail address associated with the My Oracle Support login is used by ASR to send a variety of ASR notifications, such as status reports. In this case, ASR should be unregistered and then re-registered with the new account information.

  • If the server and ASR handshake becomes corrupted.

To unregister ASR:

  1. From the ASR Manager system, run:

    asr> unregister
    
  2. Once unregistered, ASR cannot send hardware fault telemetry to Oracle's backend systems.

To register ASR, refer to "Registering the ASR Manager" for instructions.

4.10 Starting and Stopping ASR Manager

This section explains how to stop and start your complete ASR environment. There are several reasons why you may want to do this, as listed below:

  • Telemetry rules or other image upgrade to ASR.

4.10.1 Stop ASR Manager

Follow the procedure below to stop ASR Manager:

  1. Open a terminal window and log in as root on the ASR Manager system.

  2. Run the following commands:

    • For Solaris:

      svcadm disable asrm  (stops ASR Manager)
      
    • For Linux:

      service asrm  stop (stops ASR Manager)
      
  3. Once ASR is stopped, you can perform the desired maintenance tasks. Once complete, continue to the next section to restart ASR.

4.10.2 Start ASR Manager

Follow the procedure below to restart ASR Manager:

  1. Open a terminal window and log in as root on the ASR Manager system.

  2. Run the following commands:

    • For Solaris:

      svcadm enable asrm (starts ASR Manager)
      
    • For Linux:

      service asrm start (starts ASR Manager)
      
  3. Be sure that ASR can send information to the transport.oracle.com servers by running the following command:

    asr> test_connection
    

4.11 Enable/Disable ASR Manager

Starting with Oracle ASR 5.4, you can disable the ASR Manager for a specific amount of time. For example, if you need to perform maintenance on assets that are attached to the ASR Manager, then any faults from these systems would not be sent to Oracle.

While ASR Manager is in this disabled status, heartbeat events, fault events, and test events will not be sent to Oracle.

Run the following command to disable the ASR Manager for a specified amount of time:

asr> disable_asr_manager <1 to 48 hours>

Where <hours> is the number of hours that the ASR Manager is to be disabled.

Select a time between 1 and 48 to disable the ASR Manager from sending fault and heartbeat events to Oracle.

For example:

asr> disable_asr_manager 3
Disabling ASR for 3 hours.

After this period expires, the ASR Manager will be enabled automatically.

To disable ASR Manager indefinitely, run the command without specifying a time:

asr> disable_asr_manager

Note:

If you run the disable_asr_manager command without any parameters, then the following message appears:
asr> disable_asr_manager

Please enter a value between 1- 48 hours to disable ASR Manager for a specific period. After this period expires, ASR Manager will be enabled automatically. If no value is provided then ASR Manager will be disabled until it is enabled manually by running the asr [y/n]:"

If you disable the ASR Manager without any parameters, then you must enable it manually.

To enable ASR Manager that has been disabled, run the following command:

asr> enable_asr_manager
ASR Manager is enabled.

Note:

While ASR Manager is disabled, the Auto Update process will not proceed.

4.12 Enable/Disable ASR Assets

Follow the procedures below to enable or disable ASR Asset(s). Regardless of which asset you wish to enable or disable, this action is always performed on the ASR Manager system. The most common reasons to disable ASR Asset(s) are for system maintenance or if an asset is "noisy" in terms of sending an excess of telemetry data. Disabling an ASR Asset stops the ASR Manager from sending fault telemetry to Oracle for that asset.

4.12.1 Disable ASR Assets

  1. Open a terminal window and log in to the ASR Manager system as root.

  2. Run any one of the following commands depending on your circumstance. Use the IP address or the host name of the asset you wish to disable. If you disable the ASR Manager itself, only its telemetry will be stopped. All enabled ASR Asset(s) that send telemetry to this ASR Manager will continue, and the ASR Manager will continue to forward fault telemetry to Oracle's backend systems.

    • asr> disable_asset -i IP_address

    • asr> disable_asset -h host name

    • asr> disable_asset -s subnet
      (used to disable a group of assets within the subnet)

4.12.2 Enable ASR Assets

After you have disabled an ASR asset, you can re-enable it when you are ready for ASR to begin transmitting telemetry data.

  1. Open a terminal window and log in to the ASR Manager system as root.

  2. Run any one of the following commands depending on your circumstance. Use the IP address or the host name of the asset you wish to enable. Once enabled, the asset will send hardware telemetry data to the ASR Manager and faults will be sent to Oracle's backend systems.

    • asr> enable_asset -i IP_address

    • asr> enable_asset -h host name

    • asr> enable_asset -s subnet
      (used to enable a group of assets within the subnet)

  3. Once complete, a successfully enabled message is displayed.

  4. To confirm the asset is enabled, you can generate a test event using either one of the following command options:

    • asr> send_test -i IP_address

    • asr> send_test -h host name

    Note:

    The send_test command validates the ASR Manager connection to Oracle and the ASR activation status of the asset.

    It does not validate the network connection from the asset to the ASR Manager.

  5. The status of the test event is sent to the e-mail address of the My Oracle Support account associated with the ASR installation.

4.13 Deactivate/Activate ASR Assets

Deactivating an ASR Asset is done when you are replacing the asset or removing it entirely from the ASR system. When you deactivate an ASR Asset, ASR can no longer transmit telemetry data from this asset to Oracle.

Note:

If you need to unregister your ASR Asset for Solaris 11, run:
asradm unregister

This command unregisters and disables your ASR Asset.

The following topics are described:

4.13.1 Deactivate/Activate ASR Assets from My Oracle Support

  1. In the "Assets" dashboard, click on the serial number of the asset you wish to deactivate/activate. The last column (ASR Status) will show the status of the asset (Active, Inactive, or Pending).

    Note:

    You must have either CUA or Asset Admin roles to update/approve ASR activation requests.
    Surrounding text describes assets.gif.
  2. In the Asset's Details pane, click the "Deactive" button to deactivate the asset. If the asset is already deactivated, click the "Activate" button to activate it.

  3. If necessary, you can update details about the asset (for example, change the Contact Name).

4.13.2 Deactivate/Activate ASR Assets from the ASR Manager

Follow these instructions to deactivate/activate an ASR Asset from the ASR Manager:

  1. Open a terminal window and log in to the ASR Manager system as root.

  2. Run any one of the following commands depending on your circumstance. Use the IP address or the host name of the asset you wish to deactivate.

    • asr> deactivate_asset -i IP_address

    • asr> deactivate_asset -h host name

    • asr> deactivate_asset -s subnet (used to enable a group of assets within the subnet)

    Note:

    When you deactivate an ASR Asset, you cannot re-enable it. If you want to enable it again for ASR, you must re-activate it. Refer to "Activating ASR Assets".
  3. Once an asset is deactivated, you should also stop the hardware telemetry from being sent from the asset (even though the telemetry data is ignored by ASR once sent).

4.13.3 Reactivate/Deactivate All ASR Assets Associated with an ASR Manager

If you have multiple ASR Assets reporting to an ASR Manager, you can activate them all with one command:

asr> send_activations -a

Note:

Activations are resent for all the previously activated assets only.

Likewise, if you need to deactivate all of the ASR Assets associated with an ASR Manager, you can deactivate them all with one command:

asr> send_deactivations -a

4.14 Uninstalling ASR Manager

In some cases, you may need to remove or uninstall ASR Manager. For example, if you want to decommission your ASR Manager hardware or if you need to perform a manual update, then ASR Manager software must be removed. The following procedures explains how to remove ASR completely or partially for the purpose of a manual upgrade:

4.14.1 ASR 5.0 and Later: Removing ASR as Part of an Upgrade

  1. Remove the ASR 5.0 or later package from the ASR Manager system:

    • For Solaris: pkgrm asrmanager

      Note:

      To remove the ASR package from a Solaris machine in "silent" mode, run:
      /opt/asrmanager/pkg/solaris/uninstall_silent_mode.sh
      
    • For Linux: rpm -e asrmanager

  2. As part of the uninstall process, you will be asked the following question:

    Will you be upgrading to a newer version of ASR Manager [y,n,q]:
    

    Enter y to continue the process.

4.14.2 ASR 4.9 and Earlier: Removing ASR as Part of an Upgrade

  1. Remove ASR 4.9 and earlier package from the ASR Manager system:

    • For Solaris: pkgrm SUNWswasr

      Note:

      To remove the ASR package from a Solaris machine in "silent" mode, run:
      /opt/SUNWswasr/pkg/uninstall_silent_mode.sh
      
    • For Linux: rpm -e SUNWswasr

    As part of the uninstall process, you will be asked the following question:

    Will you be upgrading to a newer version of ASR Manager [y,n,q]:
    

    Enter y to continue the process.

  2. Remove the Oracle Automated Service Manager (OASM) package from the ASR Manager system. Removing this package is optional and is often done to reduce system overhead. If you have other applications (for example, Secure File Transport) running under OASM, then do not remove it.

    • For Solaris: pkgrm SUNWsasm

    • For Linux with OASM 1.5 or later: rpm -e SUNWsasm

    • For Linux with OASM 1.4.2 or earlier: rpm -e --noscripts SUNWsasm

      Note:

      There is a known issue when uninstalling OASM 1.4.2 (or earlier) on Linux using the rpm -e SUNWsasm command. Using this command to remove OASM 1.4.2 (or earlier) completely removes the crontab entries for OASM.

      This uninstallation issue has been resolved with OASM 1.5. To prevent losing any crontab entries, you can uninstall OASM 1.4.2 (or earlier) with the following command:

      rpm -e --noscripts SUNWsasm
      

4.14.3 ASR 5.0 and Later: Removing ASR Completely

  1. For all ASR Asset systems, remove telemetry traps that send hardware telemetry to the ASR Manager. Follow these steps:

  2. Deactivate all ASR Asset(s). Refer to Deactivate/Activate ASR Assets.

  3. Unregister ASR. Refer to Unregister ASR.

    Important:

    If you are using other OASM plug-ins (for example SFT), the OASM transport service used by these plug-ins will be unregistered as part of this process. Consult your plug-in documentation to re-register the OASM transport service, if needed.
  4. Remove the ASR package from the ASR Manager system:

    • For Solaris:

      pkgrm asrmanager
      rm -rf /var/opt/asrmanager/
      
    • For Linux:

      rpm -e asrmanager
      rm -rf /var/opt/asrmanager/
      
  5. As part of the uninstall process, you will be asked the following questions (for all ASR versions):

    1. The first question is whether or not you are upgrading the ASR Manager:

      Will you be upgrading to a newer version of ASR Manager [y,n,q]:
      

      Enter n to continue the process.

    2. The next question is to initiates the removal of ASR Manager and the deactivation of ASR Assets:

      Do you want to uninstall ASR Manager completely and deactivate all assets [y,n,q]:
      

      Enter y to continue the process. Because the removal is for a complete uninstall, you will be asked to confirm the removal:

      You are going to deactivate all assets. Please confirm [y,n,q]
      

      Enter y to continue the process.

After completing the steps above, the uninstall of ASR is complete.

4.14.4 ASR 4.9 and Earlier: Removing ASR Completely

  1. For all ASR Asset systems, remove telemetry traps that send hardware telemetry to the ASR Manager. Follow these steps:

  2. Deactivate all ASR Asset(s). Refer to Deactivate/Activate ASR Assets.

  3. Unregister ASR. Refer to Unregister ASR.

    Important:

    If you are using other OASM plug-ins (for example SFT), the OASM transport service used by these plug-ins will be unregistered as part of this process. Consult your plug-in documentation to re-register the OASM transport service, if needed.
  4. Remove the ASR package from the ASR Manager system:

    • For Solaris:

      pkgrm SUNWswsar
      pkgrm SUNWsasm
      rm -rf /var/opt/SUNWsasm
      
    • For Linux:

      rpm -e SUNWswsar
      rpm -e SUNWsasm                <-- for OASM 1.5
      rpm -e --noscripts SUNWswsam   <-- for OASM 1.4.2
      rm -rf /var/opt/SUNWsasm
      

      Note:

      There is a known issue when uninstalling OASM 1.4.2 (or earlier) on Linux using the rpm -e SUNWsasm command. Using this command to remove OASM 1.4.2 (or earlier) completely removes the crontab entries for OASM.

      This uninstallation issue has been resolved with OASM 1.5. To prevent losing any crontab entries, you can uninstall OASM 1.4.2 (or earlier) with the following command:

      rpm -e --noscripts SUNWsasm
      
  5. As part of the uninstall process, you will be asked the following questions (for all ASR versions):

    1. The first question is whether or not you are upgrading the ASR Manager:

      Will you be upgrading to a newer version of ASR Manager [y,n,q]:
      

      Enter n to continue the process.

    2. The next question is to initiates the removal of ASR Manager and the deactivation of ASR Assets:

      Do you want to uninstall ASR Manager completely and deactivate all assets [y,n,q]:
      

      Enter y to continue the process. Because the removal is for a complete uninstall, you will be asked to confirm the removal:

      You are going to deactivate all assets. Please confirm [y,n,q]
      

      Enter y to continue the process.

  6. Remove the OASM package from the ASR Manager system. Removing this package is optional and is often done to reduce system overhead. If you have other applications (for example, Secure File Transport) running under OASM, then do not remove it.

    • For Solaris: pkgrm SUNWsasm

    • For Linux: rpm -e SUNWsasm

  7. If you never intend to use ASR and OASM again, run the following command to remove leftover artifacts (OASM log files, ASR asset database, configuration files, etc.):

    Warning:

    This command will remove all asset activation, configuration, and ASR log file data. Only remove these files if you want to permanently remove ASR from the system or node.

    rm -r /var/opt/SUNWsasm

  8. After completing the steps above, the uninstall of ASR is complete.

4.15 ASR Network Parameters Management

This section provides the instructions for networking-related tasks for ASR operations.

4.15.1 ASR Port Usage

The following table explains the network ports used by ASR:

Source Destination Protocol Port Description
ASR Asset ASR Manager http/https user defined For sending Solaris 11 ASR telemetry to the ASR Manager.
ASR Manager ASR Backend (Oracle)

transport.oracle.com

https 443 For sending telemetry messages to the transport.oracle.com ASR backend system at Oracle.
ASR Manager ASR Asset http 6481 Service Tags listener for Asset activation
ASR Asset ASR Manager snmp

udp

162 For sending telemetry messages to the ASR Manager.
ASR Manager ASR Asset snmp (get)

udp

161 FMA enrichment for getting additional diagnostics information (Solaris 10 only).
ASR Manager ASR Manager tcp 6666 Local port used by ASR Manager Service, and it is accessible only from the ASR Manager host. ASR Manager service only listens on the local host (127.0.0.1).

WARNING:

ASR Auto Update will not work for ASR Managers using either of these two end points:

  • transport.sun.com (141.146.156.47)

  • transport.sun.co.uk (141.146.156.48)

You may need to update your configuration to use transport.oracle.com (141.146.1.169).

Instructions for how to determine if this change is needed and how to make the change is provided in My Oracle Support (MOS) Doc ID 1954819.1:

https://support.oracle.com/rs?type=doc&id=1954819.1

4.15.2 Changing the Default SNMP Port for ASR

You can change the default SNMP port on the ASR Manager by setting or updating the following properties listed below:

  1. Set the SNMP port:

    asr>  set_property snmp.receiver.port <port_number>
    

    For example:

    asr>  set_property snmp.receiver.port 1162
    
  2. Verify that the SNMP port is set correctly:

    asr>  get_property snmp.receiver.port
    
  3. Restart ASR Manager:

    • For Solaris: svcadm restart asrm

    • For Linux: service asrm restart

This command will return the new port value that you entered.

4.15.3 Configure ASR to Send HTTPS Traffic Through a Proxy Server

This procedure should be used to enable network communications in cases where you have a SOCKS proxy server mediating network traffic between the ASR Manager and the internet. For other proxy server types, you need to re-register ASR to set-up the proxy server information, as discussed in Registering the ASR Manager.

  1. Open a terminal window and log in as root to the ASR Manager system.

  2. Run the following commands:

    asr> set_property socksProxyHost host_name
    asr> set_property socksProxyPort port_number
    asr> set_property java.net.socks.password password
    asr> set_property java.net.socks.username username
    
  3. Restart ASR Manager:

    • For Solaris: svcadm restart asrm

    • For Linux: service asrm restart

4.15.4 Test Connectivity from the ASR Manager to Oracle

The following procedure can be used to confirm proper communication between the ASR Manager and Oracle's ASR backend systems.

  1. Complete one of the following steps from the ASR Manager to verify connectivity to Oracle's ASR backend infrastructure systems:

    • Using telnet:

      telnet transport.oracle.com 443
      
    • Using a web browser:

      https://transport.oracle.com/v1/
      

      The web page should indicate that the Data Transport Service is operating.

    • Using the wget utility:

      • For Solaris:

         /usr/sfw/bin/wget https://transport.oracle.com/v1/
        
      • For Linux:

        wget https://transport.oracle.com/v1/
        

      Note:

      "Unable to locally verify the issuer's authority" is an expected error.

    WARNING:

    ASR Auto Update will not work for ASR Managers using either of these two end points:

    • transport.sun.com (141.146.156.47)

    • transport.sun.co.uk (141.146.156.48)

    You may need to update your configuration to use transport.oracle.com (141.146.1.169).

    Instructions for how to determine if this change is needed and how to make the change is provided in My Oracle Support (MOS) Doc ID 1954819.1:

    https://support.oracle.com/rs?type=doc&id=1954819.1
    
  2. If the results of the above commands do not indicate the Data Transport Service is operating, you must resolve your network connection issue. Listed below are possible resolutions:

    • Determine if your network's DNS configuration is able to resolve transport.oracle.com. You may need to configure your firewall to enable outbound Internet access to transport.oracle.com.

      If DNS is not available on the ASR Manager host, you may need to manually add an entry for transport.oracle.com and its IP address to the /etc/hosts file. Use any DNS lookup service on the Internet to determine the IP address for transport.oracle.com.

    • You may need to contact your network administrator for assistance. Refer to Verifying Your Network Connection for the specific ASR network requirements.

    • If you use a proxy server, the issue could be that the proxy information has not yet been configured to ASR. This is done by registering ASR, as discussed in the following procedure.

4.16 ASR Integration with Enterprise Monitoring Systems

Other environments are set up to use different enterprise monitoring systems (e.g., IBM Tivoli, HP OpenView, etc.). Beginning with ASR 3.0, integration with My Oracle Support allows sending ASR service-request information to these systems. Once installed and properly configured, ASR provides the following integration features with enterprise monitoring systems:

  • Ability to configure SNMP trap destination from ASR Manager to enterprise monitoring systems.

  • Send case creation and test alert messages to enterprise monitoring systems.

  • ASR MIB that provides the data model of ASR case creation notification.

Examples of enterprise-monitoring systems include:

  • IBM Tivoli

  • HP OpenView

  • BMC Patrol

  • Unicenter

  • Any monitoring tool that can receive an SNMP v2c trap

During installation of the ASR software package, the SNMP trap destination can be configured from the ASR Manager host to monitoring systems. Once the ASR-capable assets are activated, ASR is designed to generate a service request after specific fault events are detected. Once the service request is opened, the Oracle Support coverage and response times are delivered in accordance with your Oracle Premier Support or Warranty Contract.

Note:

Because of ASR 3.0 integration with My Oracle Support, there are changes in the Service Request format. The service request number format in the notification trap is not correct if you are using any version older than ASR 3.0 manager. See "Using Auto Update to Manually Upgrade ASR Manager Software" for instructions on upgrading to the latest version of ASR.

The ASR Manager polls the ASR backend whenever a fault event or test alert occurred and updates its local database with service request or test alert information.

Note:

The ASR Manager SR notification SNMP trap is sent after the Service Request is opened. If additional faults occur while the Service Request is open, then notes are added to the Service Request, but additional SR notification SNMP traps are not sent.

Once the service request/test alert information is available to the ASR Manager, it sends an SNMP v2c trap to the enterprise monitoring systems and includes the following service request/test alert data defined in the ASR MIB:

  • Host name
  • IP address

  • Serial number

  • Platform type

  • Fault information (one line description)

  • Fault information knowledge link

  • Service Request number

  • Link to Service Request number
  • Service Request status information (for "unable to create SR" problems)

  • Severity of Service Request

  • SR creation time

  • Fault detection time

  • Customer Contact information


4.16.1 Managing SNMP Trap Destinations for Service Request Notifications

Follow the procedure below to configure SNMP trap destinations for ASR Service Request notifications. You can create up to 10 notification trap destinations.

  1. Set ASR notification trap destination:

    asr> set_notification_trap [-i ipAddress -p port -c community] [-h hostname -p port -c community]
    

    For example:

    asr> set_notification_trap -i 127.0.0.1 -p 162 -c public
    

    Note:

    Port "162" in the example is the destination port on your monitoring system. The notification trap will be sent only when a new service request (SR) is created successfully, and also when the test SR (test SNMP alert from the ASR asset menu) is successful
  2. Show ASR notification trap destination:

    asr> show_notification_trap

  3. Delete ASR notification trap destination:

    asr> delete_notification_trap -i 127.0.0.1

  4. Test the ASR notification trap:

    asr> send_test [-i ipAddress] [-h hostname]
    

    Check that the Enterprise Monitoring System has received the SNMP trap.

4.16.2 MIB Location and Data Elements

The SUN-ASR-NOTIFICATION-MIB file is located at:

/var/opt/asrmanager/configuration/mib/SUN-ASR-NOTIFICATION-MIB.mib

The MIB defines several notification types; however, only sunAsrSrCreatedTrap is used at this time.

Data Element Description
sunAsrSrHostname Host name of the system for which the Service Request was created.
sunAsrSrIpAddress IP address of the system for which the Service Request was created.
sunAsrSrSerialNumber Product serial number of the system for which the Service Request was created. For chassis and blade systems, chassis serial number is used.
sunAsrSrPlatformType Product Type of the system for which the Service Request was created.
sunAsrSrCreationDateTime Date and time when the Service Request was created.
sunAsrSrFaultDetectionDateTime Date and time when the fault was generated.
sunAsrSrCreationStatus Status indicating the processing of Service Request creation.
sunAsrSrAdditionalInfo Additional information associated with the fault can be added as name/value pairs. For example:

<additional-information name=chassis_host_name>chassisHostName</additional-information>

<additional-information name=chassis_serial_number>chassisSerial</additional-information>

sunAsrSrFaultSummary Brief summary of the fault for which the Service Request was created.
sunAsrSrKnowledgeLink Link to a knowledge article for the fault that was reported.
sunAsrSrNumber Service request number
sunAsrSrLink URL for accessing the Service Request information.
sunAsrSrSeverity Severity of the Service Request opened for the reported fault.
sunAsrSrName
  • Customer contact information associated with the device reporting the fault.
  • Name of Customer Contact associated with the Serial Number of the Device for which the Service Request was created.

sunAsrSrTelephone Telephone number of Customer Contact associated with the Serial Number of the Device for which the Service Request was created.
sunAsrSrEmail E-mail address of Customer Contact associated with the Serial Number of the Device for which the Service Request was created.

4.17 Restore to Previous ASR Database Backup

If you encounter a situation (such as a corrupt database issue), then you can restore your ASR database to a previous version. To restore to a previous ASR database from a backup:

  1. Stop the ASR Manager so that data does not change in middle of the restore operation:

    • For Solaris, run: svcadm disable asrm

    • For Linux, run: service asrm stop

  2. Back up the current database directory. Run:

    tar -cvf /var/opt/asrmanager/tmp/db_datetime.tar.bz /var/opt/asrmanager/db
    
  3. Locate the <latest-db-backup-file-name>. Run:

    ls -t /var/opt/asrmanager/backup/db | head -1
    
  4. Copy the latest database backup file to the ASR Manager database directory:

    cp -pr /var/opt/asrmanager/backup/db/<latest-db-backup-file-name>/sw-asr/ /var/opt/asrmanager/db/
    
  5. Restart ASR Manager:

    • For Solaris, run: svcadm enable asrm

    • For Linux, run: service asrm start