Implementation Impact on the Environment

The following sections describe the changes that are made to various types of system during the implementation process:

All Systems With An Agent Deployed

The following changes are made to every system on which an agent is deployed:

  • An entry is added to the /etc/hosts file for the Gateway.
  • A new group is created on the operating system (OS) of the monitored server. The default group name is orarom.
  • A new user is created on the ILOM of the monitored server (if applicable). The default username is orarom.
  • A new user is added on the operating system (OS) (orarom) of the monitored server.

Note:

The password for the orarom account is typically set to expire after 90 days. You can manage the password on OASP. If access is needed for troubleshooting and the account is expired, Oracle will reset the orarom password. For further information about password management, see How to update the Credentials in OASP portal (KB 389239).
  • The new OS user is added to the group that owns the Oracle Inventory.
  • A new user is added into the group that owns the database diag directories that are listed in the oratab file (required for monitoring databases and generating ADR packages).
  • The Oracle Inventory directory is updated for group read/write permissions.
  • The Database diag directories are updated for group read/write permissions.
  • A directory (/opt/OracleHomes) is created for the agent information based on the information provided in the System Install flow or discussion with your implementation engineer.
  • If permission to retain root privileges is given in the installation options during the Manage Systems request, the sudoers files are updated to allow the new OS user to execute commands as root.
  • For Linux systems, the group of the /var/log/messages file is changed to the new group (orarom) if the group owner is root.
    • This allows the agent user to be part of a group that can read the file and the group read permission is granted. The agent user can then monitor the messages file. If the messages file is already owned by a different group, the new user is added to that group instead.
  • For Linux systems, the /etc/security/limits.conf file is updated to add the required settings for the new user (orarom) to meet the agent requirements.
  • Agents are pushed from the Gateway to the server using the new user. The storage requirement for the agent is initially around 5GB.
  • Once the agents have been installed, the root.sh script for the agent is executed.
    • Root.sh creates or updates /etc/oragchomelist, creates /etc/init.d/gcstartup, creates /etc/init.d/lockgcstartup, and creates /etc/init.d/lockgcstartup.
  • ILOMs are configured to send SNMP traps to the Gateway for all ILOM detected faults of level minor or above for ASR.

    Note:

    For Exadata Nodes, the ILOM rules are configured on the operating system of the node using the Exadata CLIs (cellcli and dbmcli) rather than directly on the ILOM.
  • Install or upgrade the Oracle Autonomous Health Framework (AHF) to a minimum version of 26.1.
    • The storage requirement for AHF is 2GB of space in /opt and a minimum of 6GB (with a recommendation of 10GB) on /u01.
  • Configure Oracle Autonomous Health Framework (AHF) to auto-update from the Gateway when a new version is available.
  • A monitoring sudoers profile is added to allow the monitoring of the system and a restart of the agents by the monitoring user:
    /usr/sbin/dmidecode, /sbin/ethtool, /usr/bin/ipmitool, /usr/ sbin/imageinfo, /usr/local/bin/imageinfo, /opt/oracle/bda/bin/ imageinfo, /usr/bin/systemctl stop oracle-oasgagent.service, /usr/ bin/systemctl start oracle-oasgagent.service, /usr/bin/systemctl restart oracle-oasgagent.service, /usr/bin/systemctl status oracle-oasgagent.service, /sbin/service oasgagent start, /sbin/service oasgagent stop, /sbin/service oasgagent restart, /sbin/service oasgagent status

Engineered Systems Storage Cells

An Engineered System storage cell has strict policies not to allow the creation of new users or the deployment of agents on the OS.

The changes that are made to these systems are performed in three stages:

  • Create a user on the ILOM of the system to allow Oracle to access the ILOM and the console of the system during troubleshooting. The default username is orarom.
  • Create a monitoring role and user in the Cell Management service to enable the monitoring of the cell via the rest api. The new role will grant list and diagpack privileges to the userUpdate the snmpsubscribers in the cell software to send the traps to the Gateway for ASR and the Enterprise Manager Agents. This removes any current subscribers that have a type of ASR.
  • Update the notificationpolicy in the cell software to include "critical,warning,clear".
  • Update the notificationmethod in the cell software to include snmp.

Engineered System Cisco Switches

The Cisco switch that is installed in the racks of an Engineered System is updated to send traps to the Gateway, and the SNMP server is enabled to send traps. A new snmp user is created and set with an access list. For the Cisco switches that support the Oracle ASR functionality, this is configured to send alerts to the Gateway.

Note:

If the ASR Module is not installed on the Cisco switch it will not be configured and only SNMP traps will be configured.

Engineered System InfiniBand Switches

The InfiniBand switches that are installed in the racks of an Engineered System are updated to send traps to the Gateway and a set of SSH/SCP keys is created to allow password-less login from the monitoring agent to the ilom-operator on the switch.

The SSH/SCP keys for Exadata and SuperCluster systems are configured at discovery time. For the other systems, these are created manually by the installation engineer during the implementation prior to the target discoveries.

Engineered System PDU's

The PDU modules within the racks of an Engineered System are updated to send traps to the Gateway, and the PDU thresholds are set to generate alerts based on the values from Oracle Engineering teams.

Engineered Systems Compute Nodes (Physical Implementation) and Virtual Machines

A user (orarom) will be granted the following privileges in the sudoers file:

<user>
ALL= NOPASSWD: /usr/sbin/dmidecode, /sbin/ethtool, /usr/ bin/ipmitool, /usr/sbin/imageinfo, /usr/local/bin/imageinfo, /opt/oracle/bda/ bin/imageinfo, /usr/bin/systemctl stop oracle-oasgagent.service, /usr/bin/systemctl start oracle-oasgagent.service, /usr/bin/systemctl restart oracle-oasgagent.service, /usr/bin/systemctl status oracle-oasgagent.service, /sbin/ service oasgagent start, /sbin/service oasgagent stop, /sbin/service oasgagent restart, /sbin/service oasgagent status

Note:

The profile may be updated if the option for Oracle to retain sudo privilege is granted.

OVS Compute Nodes

  • Install or upgrade the Oracle Autonomous Health Framework (AHF) to a minimum version of 26.1.
    • The storage requirement for AHF is 2GB of space in /opt and a minimum of 6GB (with a recommendation of 10GB) on /EXAVMIMAGES.
  • Install oasg-agent software.
  • Configure Oracle Autonomous Health Framework (AHF) to auto-update from the Gateway when a new version is available.
  • Configure Oracle Autonomous Health Framework (AHF) to communicate to all KVM Nodes via socket for data collection.

The Oracle Virtual Server operating system that is used within an Engineered System that is running the virtualized stack has strict policies that do not allow the installation of Oracle Enterprise Manager (EM) agents on to the systems. These nodes will have the ILOMs

configured to send traps to the Gateway for ASR. A user (orarom) will be created on the OVS Server and granted the following privileges in the sudoers file:

<user>
ALL= NOPASSWD: /usr/sbin/xentop, /usr/sbin/dmidecode, /sbin/ ethtool, /usr/bin/xenstore-ls, /usr/bin/xenstore-read, /usr/bin/ xenstore-list, /usr/sbin/xl, /usr/bin/ipmitool, /usr/sbin/xm, /usr/sbin/imageinfo, /usr/local/bin/imageinfo, /opt/oracle/bda/bin/imageinfo, /usr/ bin/systemctl stop oracle-oasgagent.service, /usr/bin/systemctl start oracle-oasgagent.service, /usr/bin/systemctl restart oracle-oasgagent.service, /usr/ bin/systemctl status oracle-oasgagent.service, /sbin/service oasgagent start, /sbin/service oasgagent stop, /sbin/service oasgagent restart, /sbin/ service oasgagent status

This list of commands is used by the Oracle Virtual Platform and Oracle Server target types to read information about the system, relay the information to EM, and manage the oasg_agent.

Note:

The profile may be updated if the option for Oracle to retain sudo privilege is granted.

KVM Compute Nodes

  • Install or upgrade the Oracle Autonomous Health Framework (AHF) to a minimum version of 26.1.
    • The storage requirement for AHF is 2GB of space in /opt and a minimum of 6GB (with a recommendation of 10GB) on /EXAVMIMAGES.
  • Install oasg-agent software.
  • Configure Oracle Autonomous Health Framework (AHF) to auto-update from the Gateway when a new version is available.
  • Configure Oracle Autonomous Health Framework (AHF) to communicate to all KVM Nodes via socket for data collection.

The Oracle Linux 7 Server used within an Engineered System that is running the virtualized stack has strict policies that do not allow the installation of Oracle Enterprise Manager (EM) agents on to the systems. These nodes will have the ILOMs configured to send traps to the Gateway for ASR. A user (orarom) will be created on the KVM Server and granted the following privileges in the sudoers file:

<user>
ALL= NOPASSWD: /usr/bin/virsh list*, /usr/bin/virsh dominfo*, /usr/ bin/virsh nodememstats*, /usr/bin/virsh domstats*, /usr/bin/virsh capabilities, /usr/bin/virsh domblklist*, /usr/bin/virsh domiflist*, /usr/ bin/virsh domifstat*, /usr/bin/virsh vcpupin*, /bin/virsh cpu-stats*, /bin/ virsh domblkstat*, /bin/virsh dommemstat*, /bin/virsh nodeinfo, /sbin/dmsetup info, /sbin/service --status-all, /usr/sbin/dmidecode, /sbin/ethtool, /usr/ bin/ipmitool, /usr/sbin/imageinfo, /usr/local/bin/imageinfo, /opt/oracle/ bda/bin/imageinfo, /opt/exadata_ovm/vm_maker, /usr/sbin/brctl, /sbin/fdisk -l*, /bin/virsh domblkinfo*, /usr/bin/lvs*, /usr/bin/smartctl*, /usr/sbin/ibnetdiscover, /usr/sbin/sminfo, /sbin/dmsetup info*, /bin/cat /etc/iscsi/iscsid.conf, /usr/bin/systemctl stop oracle-oasgagent.service, /usr/bin/systemctl start oracle-oasgagent.service, /usr/bin/systemctl restart oracle-oasgagent.service, /usr/bin/systemctl status oracle-oasgagent.service, /sbin/service oasgagent start, /sbin/service oasgagent stop, /sbin/service oasgagent restart, /sbin/service oasgagent status

This list of commands is used by the Oracle Enterprise Manager (OEM) targets to read information about the system, relay the information to OEM, and manage the oasg_agent.

Note:

The profile may be updated if the option for Oracle to retain sudo privilege is granted.

ZFS Storage Array Storage Heads

The ZFS arrays are appliances that cannot have agents installed on them. Consequently, they are monitored from another agent using a specific monitoring user. The changes that are carried out on both of the storage heads in a cluster are as follows:

  • Execute the workflow “Configure for Oracle Enterprise Manager”. This always has the recreateWorksheet setting enabled. If the oracle_agent user and role are already created, then the recreateUser setting is not enabled. Otherwise it is enabled. If the user is set to be recreated, the password used is a strong, randomly generated, 16-character password.

    Note:

    The customer can change the password on the oracle_agent user without affecting the Oracle monitoring solution.
  • Create a new user for the Oracle monitoring solution using the role oracle_agent created by the above workflow. The default username is orarom, but the name is customizable from the Service Implementation Worksheet (SIW).
  • Enable advanced_analytics for the new user created above.