This chapter describes how to plan an installation and then how to configure the software so that you use the software securely.
This section outlines the options for a secure installation and describes several recommended deployment topologies for the systems.
The simplest deployment architecture is a single-system deployment in which the Enterprise Controller and a Proxy Controller are installed on the same system. Although the simplicity is appealing, this type of deployment creates a single point of failure and cannot provide high availability because all components are stored on the same computer.
The High Availability configuration uses multiple Enterprise Controllers with Oracle Clusterware and a remote database. The active Enterprise Controller is used for all operations. The standby Enterprise Controllers are configured as backups. If the active Enterprise Controller must be taken offline, make another Enterprise Controller active. One of the standby Enterprise Controllers is also activated if the active Enterprise Controller fails.
Each asset is managed by a specific Proxy Controller. If a Proxy Controller fails or is uninstalled, Oracle Enterprise Manager Ops Center gives you the option to migrate the failed Proxy Controller's assets to another Proxy Controller. At any time, move an asset from one functional Proxy Controller to another Proxy Controller. The destination Proxy Controller must either be connected to the networks of the assets being moved, or be associated with those networks and have them enabled.
Use two or more systems of the same model and configured identically:
Processor class
Operating system
Oracle Enterprise Manager Ops Center software version, including updates
Network interfaces that are cabled identically to the same subnets
Use the Edit Asset action to add an asset tag that identifies the active Enterprise Controller and distinguishes it from the standby Enterprise Controller.
Maintain the standby Enterprise Controller's system in the same way as the active Enterprise Controller. The active and standby Enterprise Controllers must use the same version of Oracle Enterprise Manager Ops Center software.
User accounts and data that are not associated with Oracle Enterprise Manager Ops Center are not part of the relocate process. Only Oracle Enterprise Manager Ops Center data is moved between the active and standby Enterprise Controllers.
Any customizations of the PAM configuration on the primary node must be repeated on the standby node. Oracle Enterprise Manager Ops Center does not replicate PAM configuration.
UI sessions are lost in a relocation.
The Enterprise Controller HA configuration applies only to the Enterprise Controller and not to Proxy Controllers.
See the Oracle Enterprise Manager Ops Center Administration Guide for instructions in configuring and maintaining an High Availability installation.
Network connections are needed for data operations, for management operations, and for provisioning operations. The minimum configuration, but least secure, is to combine all operations on one network. Separate networks, as shown in Figure 2-1, provide the highest security and the lowest number of points of failure. However, additional network interface cards (NIC) are needed to support this configuration.
Figure 2-1 Separate Management, Provisioning, Data Networks
Oracle Enterprise Manager Ops Center manages and monitors assets in multiple locations and on multiple platforms. The responsibility for securing the network, hardware, and operating system of the server that runs the Enterprise Controller is that server's system administrator. The responsibility for securing the hardware, network, and operating system of Proxy Controllers and all assets falls on various sites' system administrators.
Oracle Enterprise Manager Ops Center stores its data and metadata in Software and Storage Libraries. These libraries can reside in local file systems or on the shares of an NFS server. Because the Enterprise Controller does not mount the NFS share, install the NFS server on a system that is close to the systems that will use the NFS share, that is, the systems that host global zones and Oracle VM Servers.
This version of the product software provides the capability to use a remote, customer-managed database. The Enterprise Controller interacts with the remote, customer-managed database using the Oracle*Net protocol over TCP/IP.
Oracle Enterprise Manager Ops Center provides scripts to create the database schema and users. Before you install Oracle Enterprise Manager Ops Center, your database administrator creates the database and then runs the createOCSchema_remote.sql
script to create the Ops Center Schema and to grant the CREATE DATABASE privilege. The database administrator provides the database credentials and the connection information to you and you create the remoteDBCreds.txt
file. The file can be located in a directory of your choice on the system that hosts the Enterprise Controller.
When you install the Oracle Enterprise Manager Ops Center software, you use the -remoteDBprops
flag and provide the location of the remoteDBCreds.txt
file. During installation, the connection between the Enterprise Controller and the remote database is created.
Figure 2-2 shows a deployment running the product software in Connected mode and with two Proxy Controllers.
Install the Enterprise Controller component only on a system where root access is controlled tightly because a root-privileged user must modify or create system services as part of the installation. To install the product on Linux systems, disable the SELINUX setting.
When installing a Proxy Controller that is not co-located with the Enterprise Controller, do not use the Proxy Controller Deploy action from the browser interface. Instead, copy the Proxy Controller bundle to the target system and then log in as root to install the software. This method removes the need to provide root credentials to the Proxy Controller's system and eliminates the need to enable ssh
access from the Enterprise Controller's system to the Proxy Controller's system.
A privileged user must be enabled for the Oracle Enterprise Manager Ops Center software. Log in as the privileged user to configure the software.
Connection modes provide a way to keep the product software and all of the asset software current. However, Connected mode requires Internet access and if this access cannot be made secure or if a site's policy does not enable Internet access, the alternative is to run Oracle Enterprise Manager Ops Center in Disconnected mode. Although Disconnected mode might seem to provide the most secure environment, its use relies on manual procedures that can are error-prone without rigorous compliance to procedures and policies. Table 2-1 shows how operations are affected by the connection mode.
Table 2-1 Comparison of Functions in Different Connection Modes
Operation | Connected Mode | Disconnected Mode |
---|---|---|
Use the Oracle Ops Center Downloads action to create a job that obtains the latest version. |
|
|
Upgrade the product software |
Use the Upgrade Enterprise Controller action. For each Proxy Controller, use the Update to Latest Available Version action. |
For the Enterprise Controller and each Proxy Controller:
|
Provision an OS and update an existing OS, using the latest image. |
Download the operating system software from |
Obtain the image. Use a CD or DVD to load the operating system software. Log in to an Internet-facing system and download the operating system software from Then use the Upload ISO Images action and the Import Images action to update the contents of the Enterprise Controller's software library. |
Provision firmware and update existing firmware, using the latest image. |
Download firmware from |
Use a CD or DVD to load the software. Then use the Upload ISO Images action, the Upload Firmware action, and the Import Images actions to update the contents of the Enterprise Controller's software library. |
Use Automatic Service Requests (ASR) |
After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, you have the option to create a service request whenever an incident is reported. In an Automated Service Request, the following information is sent from the Enterprise Controller to My Oracle Support: serial number FRU data IP address site location hardware SNMP trap |
Contact My Oracle Support to request service. |
Create a Services Request |
After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, select the Open Service Request action. |
Contact My Oracle Support to request service. The Open Service Request action is disabled. |
Verify warranties |
After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, view the warranty of a specific asset or all assets. |
Contact My Oracle Support to coordinate warranty records with your own records. |
All installation and upgrade log files remain in place to assist in diagnosing any problems with the installation or upgrade. Because their content can be considered sensitive, archive them securely and remove the files after a successful installation or upgrade.
The product installs a diagnostic program,OCDoctor
, that gathers logged data, analyzes an installation for common errors, and responds to inquiries. To remove the program at any time, delete its files and directories.
The installation logs are found in the following locations:
Log of a successful installation: /var/tmp/installer.log.latest
Log of a specific installation:
/var/opt/sun/xvm/oracle/app/oraInventory/logs/silentInstall<YYYY-MM-DD-HH-MM-SSPM>.log
Log of previous installation or uninstallation operations: /var/tmp/installer.log.
xxxx
Log of an agent installation: /var/scn/install/log
The log of upgrade actions for the Enterprise Controller and its co-located Proxy Controller is in the file: /var/opt/sun/xvm/update-saved-state/update_satellite_bundle_12.1.
n.xxxx
/updatelog.txt
The log of upgrade actions for a Proxy Controller that is not co-located is in the file: /var/opt/sun/xvn/update-saved-state/update_proxy_bundle_12.1.
n.xxxx
/updatelog.txt
Oracle Enterprise Manager Ops Center has self-signed certificates that it uses for authentication between its web container and a browser client.
Oracle Glassfish Server is the web container in the current version of the product.
Apache Tomcat is the web container used in versions of the product prior to Version 12.1.
Self-signed Certificates are site-generated Certificates that have not been registered with any well-known Certificate Authority (CA), and are therefore not guaranteed. These certificates issue a warning when connecting with a browser and require users to accept the certificate.
Java's standard keystore format is JKS, the format created by the keytool
command-line utility. This tool is included in the JDK and creates the self-signed certificates. The Oracle Enterprise Manager Ops Center keystore for the browser certificates is located in:
/var/opt/sun/xvm/bui/conf/keystore
The keystore has a password that cannot be configured. The keystore is protected by filesystem permissions.
To ensure that the data being transmitted and received is private and not vulnerable to eavesdropping, a self-signed certificate is sufficient. However, to ensure that connections are authentic, replace the self-signed certificates with Class A or B certificates from an third-party Certificate Authority such as Verisign.
Identify the Certificate Authority you want to use.
Submit a request for a certificate to the Certificate Authority, according to their instructions. The Certificate Authority returns a certificate to you.
Download a Chain Certificate from the Certificate Authority, according to their instructions.
Verify the certificates' fingerprints. When you add a certificate to the keystore, any transactions using that certificate become trusted. You must be certain that the certificates you received are authentic before you import them. Use the keytool's print
command to see the fingerprints and then communicate with the Certificate Authority to compare the fingerprints. To see a certificate's fingerprint, use the following command:
keytool -printcert -file <path/filename>
Replace the self-signed certificate with the CA certificate, as described in the following sections.
To replace the self-signed certificate with a certificate from a Certificate Authority, use the following procedure:
Import the Chain Certificate in the Oracle Enterprise Manager Ops Center keystore:
keytool -import -alias root -keystore /var/opt/sun/xvm/bui/conf/keystore -trustcacerts -file <chain_certificate>
At the prompt for the password to the keystore, enter the following:
trustpass
Confirm the certificate's authenticity.
Import the certificate that the CA sent to you into the keystore:
keytool -import -alias <hostname>-ca -keystore /var/opt/sun/xvm/bui/conf/keystore -trustcacerts -file <your_certificate>
where <hostname>
is the name of the system on which the Enterprise Controller is running and <your_certificate>
is the name of the file containing the certificate sent from the Certificate Authority.
At the prompt, enter the password to the keystore and verify the certificate's authenticity.
To replace the self-signed certificate with certificates from a Certificate Authority, use the following procedure on systems running Oracle Solaris 10 and Oracle Linux.
Note:
Do not attempt this procedure on systems running Oracle Solaris 11 because it will affect the communication between the agent and the Enterprise Controller.The procedure is not available for Oracle Solaris 11.
Stop the Enterprise Controller and Proxy Controllers.
Copy the Certificate Authority certificate files to a directory on your server. This is a temporary location.
Rename the Certificate Authority certificate file to server.crt
Rename the Certificate Authority key file to server.key
Navigate to the location of the self-signed certificate and key files for the Apache Tomcat web container:
Oracle Solaris 10: /var/opt/sun/xvm/uce/etc.opt/server/uce_server/ssl.crt
Linux: /var/opt/sun/xvm/uce/etc/uce_server/ssl.crt
Move the current server.crt
file and server.key
file from the ssl.crt
directory to an alternate, secure location.
Copy the CA files from the temporary location to the ssl.crt
directory.
Change the permissions so that the files can be ready by only root:
chown uce-sds:uce-sds <filename> chmod 400 <filename>
The files now have these permissions:
-r-------- 1 uce-sds uce-sds 1751 Jun 13 13:05 server.key -rw-r--r-- 1 uce-sds uce-sds 1220 Jun 13 13:05 server.crt
If the server.key
file is encrypted and requires a passphrase, edit the following file to change the echo output to the passphrase.
Oracle Solaris 10: /var/opt/sun/xvm/uce/etc.opt/server/uce_server/.sslphrase
Linux: /var/opt/sun/xvm/uce/etc/uce_server/.sslphrase
Use a script or the command line to define these variables:
SDS_KEYS=/path/to/your_certificate SMSF_STORE=/var/opt/sun/xvm/security/jsse/smsfacade/jssecacerts SMSF_PASS=`cat /var/opt/sun/xvm/persistence/scn-satellite/satellite.properties | grep engine.installcert.passphrase |awk -F= '{print $2}'`
In addition, define these OS-specific variables:
Oracle Solaris 10:
TRUST_STORE=/etc/cacao/instances/oem-ec/security/jsse/truststore TRUST_PASS=`cat /etc/cacao/instances/oem-ec/private/cacao.properties | grep com.sun.cacao.ssl.truststore.password |awk -F= '{print $2}'`
Linux:
TRUST_STORE=/etc/opt/sun/cacao2/instances/oem-ec/security/jsse/truststore TRUST_PASS=`cat /etc/opt/sun/cacao2/instances/oem-ec/private/cacao.properties | grep com.sun.cacao.ssl.truststore.password |awk -F= '{print $2}'`
Remove the old alias from the cacao
and smsfacade
truststores and import the new certificates:
$LATEST_JDK/bin/keytool -delete -alias sds -keystore $TRUST_STORE -storepass $TRUST_PASS -noprompt $LATEST_JDK/bin/keytool -importcert -file $SDS_KEYS -alias sds -keystore $TRUST_STORE -storepass $TRUST_PASS -noprompt $LATEST_JDK/bin/keytool -delete -alias 127.0.0.1-1 -keystore $SMSF_STORE -storepass $SMSF_PASS -noprompt $LATEST_JDK/bin/keytool -importcert -file $SDS_KEYS -alias 127.0.0.1-1 -keystore $SMSF_STORE -storepass $SMSF_PASS -noprompt
Start the Enterprise Controller and Proxy Controllers.
Database passwords are encrypted in /var/opt/sun/xvm/dbpw.properties
, using AES 128-bit encryption. The Advanced Encryption Standard (AES) specification defines one key for both encrypting and decrypting electronic data.
Access to the local database is restricted to processes on the Enterprise Controller. To allow an external host to get access to the database, you must modify the Oracle*Net Listener configuration, as described in Getting Access to the Database Data.
You must protect the properties file for the database, /var/opt/sun/xvm/db.properties
, because it contains schema names and passwords. Use the most restrictive permission: read-only by file owner.
You must protect the compressed file created when you use the ecadm backup
command, as described in Backing Up and Restoring the Enterprise Controller. This tar file contains the dump of the local database. You must also ensure that the backup file is moved to an alternate location.
You must remove the remoteDBCreds.txt
file after installation. The file contains unencrypted credentials for the schema on the customer-managed database, used to configure the connection between the Enterprise Controller and the remote database. The file is located on the system that hosts the Enterprise Controller in a directory chosen by the administrator who installed the software.
If you are upgrading from product version 12c Release 1 (12.1.0.0.0) to a later version and use a remote database, you must also execute the refactorOCPrivs_12.1.x.0.sql
script as described in the following section to further tighten security for the schema owner on the remote database.
/You must protect the properties file for the database, var/opt/sun/xvm/db.properties
, because it contains schema names and passwords. Use the most restrictive permission: read-only by file owner.
You must ensure that a remote database is included in your site's routine backup plan so that the Oracle Enterprise Manager Ops Center data can always be recovered.
Using the refactorOCPrivs_12.1.x.0.sql Script
Use a database administrator account for this procedure.
To obtain the schema names for the remote database, view the /opt/sun/xvm/db.properties
file and search for the mgmtdb.appuser
and mgmtdb.roappuser
values.
Copy the refactorOCPrivs_12.1.x.0.sql
script from the Enterprise Controller's system to the Oracle account on the server where the customer-managed database instance is installed. The script is located in the following location of the Enterprise Controller's system:
On Oracle Solaris: /opt/ORCLsysman-db/sql/update/delta-update1/oracle/refactorOCPrivs_12.1.x.0.sql
On Linux: /opt/orcl-sysman-db/sql/update/delta-update1/oracle/refactorOCPrivs_12.1.x.0.sql
Log in as the database administrator and execute the SQL script, using the following command:
sqlplus / as sysdba @refactorOCPrivs_12.1.1.0.sql
At the prompts for Ops Center database login and Read-Only Ops Center database login, enter the schema names created when the remote database was created.
Verify the new roles and privileges by running the following SQL statement in a privileged database administrator account:
set pages 0 Select lpad(' ', 2*level) || Granted_Role "User, his roles and privileges" From ( -- THE USERS Select null Grantee, UserName Granted_Role From Dba_Users Where UserName Like Upper('&_OC_SYSTEM_SCHEMA%') -- ROLES TO ROLES RELATIONS Union Select Grantee, Granted_Role From Dba_Role_Privs -- THE ROLES TO PRIVILEGE RELATIONS Union Select Grantee, Privilege From Dba_Sys_Privs ) Start With Grantee is null Connect By Grantee = Prior Granted_Role / Enter the value for the OC System Database Login (i.e the value for mgmtdb.appuser) at the prompt: Enter value for _oc_system_schema: OC <cr>
The following are the new roles and privileges, in addition to those granted when the original schema was created such as CREATE DATABASE LINK
.
CREATE TABLE CREATE VIEW OC_SYSTEM_ROLE CREATE CLUSTER CREATE INDEXTYPE CREATE OPERATOR CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION CREATE TRIGGER CREATE TYPE
The following are the Read Only roles and permissions.
CREATE SESSION CREATE SYNONYM
You can change the database password for the Oracle Enterprise Manager Ops Center user on an embedded or customer-managed database. The Enterprise Controller's services must be restarted to use the new password.
Use this procedure to change the credentials:
Create a temporary file containing the new password and use the most restrictive permissions for the file. For example:
# vi /tmp/password newpassword # chmod 400 /tmp/password
Use the ecadm
command with the change-db-password
subcommand and the -p <password file>
option to change the database password. At the prompt, confirm that you want the Enterprise Controller to restart. For example:
# ./ecadm change-db-password -p /tmp/password The Enterprise Controller will be restarted after the database password is changed. Continue? (y/n) y ecadm: --- Changed database password, restarting. ecadm: shutting down Enterprise Controller using SMF... ecadm: Enterprise Controller services have stopped ecadm: Starting Enterprise Controller with SMF... ecadm: Enterprise Controller services have started #
If you have a high availability configuration, the ecadm
command copies the new database properties to each standby cluster node. Enter the root password for each standby cluster node. For example:
ecadm: --- Changed database password, restarting. The DB configuration file must now be copied to each remote cluster node. You will be prompted for the root password for each node to perform the copy. Copying to node OC-secondary Password: password <output omitted> ecadm: --- Enterprise Controller successfully started HA #
Delete the temporary file containing the new password.
# rm /tmp/password
You can change the database password for the read-only user on an embedded or customer-managed database. The Enterprise Controller's services must be restarted to use the new password.
Use this procedure to change the credentials:
Create a temporary file containing the new password and use the most restrictive permissions for the file. For example:
# vi /tmp/password newpassword
Use the ecadm
command with the change-db-password
subcommand and the -p <password file>
and -r
options to change the database password. When prompted, confirm the Enterprise Controller restart. For example:
# ./ecadm change-db-password -r -p /tmp/password The Enterprise Controller will be restarted after the database password is changed. Continue? (y/n) y ecadm: --- Changed database password, restarting. ecadm: shutting down Enterprise Controller using SMF... ecadm: Enterprise Controller services have stopped ecadm: Starting Enterprise Controller with SMF... ecadm: Enterprise Controller services have started #
If you have a high availability configuration, the ecadm
command copies the new database properties to each remote cluster node. Enter the root password for each remote cluster node. For example:
ecadm: --- Changed database password, restarting. The DB configuration file must now be copied to each remote cluster node. You will be prompted for the root password for each node to perform the copy. Copying to node OC-secondary Password: password <output omitted> ecadm: --- Enterprise Controller successfully started HA #
Delete the temporary file containing the new password.
# rm /tmp/password
Oracle Enterprise Manager Ops Center provides a Data Model Navigator to allow Oracle support personnel to gather detailed information about the state of the system from a model view of the system. This diagnostic interface is enabled by default and requires user authentication for access. Because it represents an internal view of the system, disable the interface and enable it only when in communication with Oracle support personnel.
Disable the interface using the following procedure:
Log in to the Enterprise Controller as the root
user.
For an Oracle Solaris system, copy /etc/cacao/instances/oem-ec/modules/restfuladaptor.xml
to /etc/cacao/instances/oem-ec/modules/restfuladaptor.xml.orig
For a Linux system, copy /etc/opt/sun/cacao/instances/oem-ec/modules/restfuladaptor.xml
to /etc/opt/sun/cacao/instances/oem-ec/modules/restfuladaptor.xml.orig
Edit the new file and locate the line: ignored-at-startup="No"
Change the value so that the line is: ignored-at-startup="Yes"
Save the file.
Repeat the procedure on each Proxy Controller:
For an Oracle Solaris system, copy the file /etc/cacao/instances/scn-proxy/modules/com.sun.hss.proxy.restfuladaptor.xml
For a Linux system, copy the file /etc/opt/sun/cacao/instances/scn-proxy/modules/com.sun.hss.proxy.restfuladaptor.xml
Edit the file to change the value and save it.
Stop and restart the Proxy Controller:
/opt/SUNWxvmoc/bin/proxadm stop /opt/SUNWxvmoc/bin/proxadm start
Stop and restart the Enterprise Controller:
/opt/SUNWxvmoc/bin/satadm stop /opt/SUNWxvmoc/bin/satadm start
To encrypt the credentials used to get access to the Agent Controller of an asset:
Check the status of the agent:
/var/opt/sun/xvm/OCDoctor/OCDoctor.sh --update /var/opt/sun/xvm/OCDoctor/OCDoctor.sh --troubleshoot
Check the prerequisites for encryption and then encrypt the agent password:
/var/opt/sun/xvm/OCDoctor/OCDoctor.sh --troubleshoot --fix
To implement transactions securely, Oracle Enterprise Manager Ops Center supports specific communications and security standards and methods such as HTTP, SSL, x.509 certificates, and Java. Most browsers support several of these features but users must configure their browsers properly to take advantage of security capabilities.
Information sent to and from a browser is transmitted in the clear so any intermediate site can read the data and potentially alter it in transit. Oracle Enterprise Manager Ops Center's browsers and servers address this problem in part by using the Secure Sockets Layer to encrypt HTTP transmissions (referred to as HTTP/SSL or HTTPS). This ensures the security of data transmitted from the client to the server. However, because browsers do not ship with client certificates, most HTTP/SSL transmissions are authenticated in only one direction, from server to client. The client does not authenticate itself to the server.
The browser interface uses JavaScript extensively. Take care to protect against JavaScript-based attacks.
Note:
Some locales do not allow the use of strong ciphers. Use this type of encryption only if local legislation allows it.If you modify an asset's sshd
daemon to use a strong cipher such as AES-256 encryption, you must also configure the Proxy Controller to manage the asset. To determine if the sshd
daemon has been modified, view the /etc/ssh/sshd_config
file, in the Ciphers section, to see if it contains content such as this:
Ciphers aes256-cbc
To discover and manage assets that use a strong cipher suite configuration, you must download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files and move them to the Proxy Controller systems.
Configuring Proxy Controllers to Use a Strong Cipher Suite Configuration
On an Internet-facing system, navigate to http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html
.
Select Accept License Agreement.
Click the UnlimitedJCEPolicyJDK7.zip
link and download the file.
Unzip the UnlimitedJCEPolicyJDK7.zip
file.
Move the local_policy.jar
and US_export_policy.jar
files to the /usr/jdk/jdk<latest version>/jre/lib/security/
directory on the Proxy Controller.
Restart the Proxy Controller system.
To view the Enterprise Controller's configuration, select the Enterprise Controller in the Administration section of the Navigation pane, then click the Configuration tab. Select one of the following subsystems to display its settings.
Agent Provisioning – Manages the provisioning of Agent Controllers.
Automated Service Requests – Manages the Automated Service Request (ASR) settings.
Database – Manages the database used by Oracle Enterprise Manager Ops Center.
EC Manager – Manages the Enterprise Controller.
Firmware – Manages firmware downloads.
Job Manager – Manages the way that jobs are run.
My Oracle Support (MOS) – Manages Oracle Enterprise Manager Ops Center's communications with MOS.
Network/Fabric Manager – Manages networks and fabrics.
OCDoctor – Manages the OCDoctor location and updates.
OS Provisioning – Manages network and fabric settings.
Permission Cache – Manages cache sizes.
Power – Manages energy cost settings.
Proxy Manager – Manages the interactions between the parts of the infrastructure.
Quartz Scheduler – Manages the quartz scheduler.
Role Preferences – Manages role settings.
Update – Manages the location of update libraries.
Zone Controller – Manages the zone management settings.
Use roles to control access to the Enterprise Controller's configuration after installation. The Ops Center Admin role is the only role that can modify the configuration properties. Use care in assigning this role to a user.
Note:
Editing configuration properties can have an adverse affect on the stability and performance of the product and is done only if directed by My Oracle Support.The information in this section is also in Oracle Enterprise Manager Ops Center Accessing Core Product Data in the How To library.
This section describes how to view the core product data stored in the Oracle Enterprise Manager Ops Center database using Oracle SQL Developer or SQL*Plus. Use this information to integrate this product with other applications such as Oracle Enterprise Manager Cloud Control, or to pull data from the Oracle Enterprise Manager Ops Center datastore for analytical applications. To use Oracle SQL Developer, you need the following information:
Database host name – The name of the database host is listed in the mgmt.dburl
property of the /var/opt/sun/xvm/db.properties
file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName>
.
Read-Only User Name – The Read-Only User name is a schema on the Oracle Enterprise Manager Ops Center Repository that is configured to access Oracle Enterprise Manager Ops Center data using read-only views. When the Enterprise Controller uses an embedded database, the username is OC_RO
. When the Enterprise Controller uses a customer-managed database, the schema name is included in the mgmtdb.roappuser
property of the /var/opt/sun/xvm/db.properties
file.
Read-Only Password – When your Enterprise Controller is configured with the embedded database, the password is randomized at installation. If you do not know the embedded database password, see the Database Management chapter in the Oracle Enterprise Manager Ops Center Administration Guide for information about changing the password. If you are using a customer-managed database and you do not know the password, ask your database administrator for assistance.
Listener Port – The listener port number for the database is listed in the mgmt.dburl
property of the /var/opt/sun/xvm/db.properties
file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName>
.
Oracle Service Name – For embedded databases, the service name is OCDB.us.oracle.com
. For customer-managed databases, the service name is listed in the mgmt.dburl
property of the /var/opt/sun/xvm/db.properties
file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName>
.
Using Oracle SQL Developer, you can connect to the database using a read-only account and view the schema structures and data.
To allow an external host to get access to the database, you must modify the Oracle*Net Listener configuration on the Enterprise Controller:
Change to Oracle Enterprise Manager Ops Center's user environment:
$ su - oracleoc
Edit the sqlnet.ora
file:
vi $ORACLE_HOME/network/admin/sqlnet.ora
Disable valid node checking by commenting the following lines:
#tcp.validnode_checking = yes #tcp.invited_nodes = (localhost,x4150-brm-04)
Save the file and exit.
To use the new version of the file, either restart all services on the Enterprise Controller, or reload the Oracle*Net Listener configuration from the oracleoc
user environment.
/opt/SUNWxvmoc/bin/satadm stop -w /opt/SUNWxvmoc/bin/satadm start -w
OR
$ lsnrctl reload OCLISTENER
If you are using the embedded database, you must open Oracle*Net to enable external access before you can connect to the database.
Log in to the Enterprise Controller system.
Change to the user that owns the Oracle software. For example:
$ su - oracleoc
Modify the sqlnet.ora
file to comment out the two lines beginning with tcp.validnode_checking
and tcp.invited_nodes
. For example:
$ vi $ORACLE_HOME/network/admin/sqlnet.ora #tcp.validnode_checking = yes #tcp.invited_nodes = (localhost,<EnterpriseControllerHostname>)
Use the lsnrctl reload
command to reload the listener configuration without stopping the Enterprise Controller services. For example:
$ lsnrctl reload OCLISTENER
You must create a connection to the Oracle Enterprise Manager Ops Center database in Oracle SQL Developer.
In Oracle SQL Developer, click the New Connection icon in the Connections tab.
Enter the connection information, then click Save:
Connection Name – Enter a name. This name is only used in Oracle SQL Developer.
Username – Enter the schema name for the read-only user.
Password – Enter the password for the read-only user.
Host name – Enter the name of the database host.
Port – Enter the Oracle*Net Listener port number.
Service Name – Select the service name option and enter the service name. For embedded databases, the service name is OCDB.us.oracle.com
. For customer-managed databases, the service name is included in the mgmtdb.dburl
property in the /var/opt/sun/xvm/db.properties
file.
After you create the connection, view product data:
Select the connection you created in the previous procedure. The contents of the target database are displayed.
Within the database hierarchy, expand the Other Users section, then select the application user and expand the Views section. If you are using an embedded database, the application user is OC. If you are using a customer-managed database, the application user is included in the mgmtdb.appuser
property of the /var/opt/sun/xvm/db.properties
file.
The database columns visible to the application user are displayed.
View the comment column to find the location of the Javadoc for each column, which explains the usage of the column.
Note:
TheSUNWxvmoc-sdk.pkg
package, which is included with the product installation media, installs Javadoc. If this package is not installed on your system, use the pkgadd
command to install it for Oracle Solaris systems, or the rpm
command to install it for Linux systems.After you get access to the product data, you can integrate the data with other applications, run analytics on the product data, or take other actions that require the data.
If you have access to the Enterprise Controller system, you can access the database from the command line.
Log in to the Enterprise Controller system.
Run the ecadm sqlplus
command. Use the -r
option to access the database in read-only mode.
You are connected to the database using the SQL*Plus interface.
Invoke commands using the SQL*Plus syntax.
To see a list of views:
select view_name from user_views where (view_name like 'V_VMB%' or view_name like 'V_VDO%')
To see comments on a specific view:
select comments from user_tab_comments where table_name='<view name from the above list>'
To see comments on all columns of a specific view:
select column_name, comments from user_col_comments where table_name='<view name from the above list>'