This chapter explains the steps to enable Application Dependency and Performance in the Enterprise Manager Grid Control environment. Information includes:
The following list summarizes the steps used to install the ADP Agent (Agent). For details of the installation, refer to the chapters in this manual.
Before you install the ADP Agent, ensure you have installed the Enterprise Manager Grid Control software. See the Oracle Enterprise Manager Grid Control Basic Installation Guide for details.
Create a user for the ADP Manager in a database. Each ADP Manager requires its own user which needs the CONNECT and RESOURCE roles. Use the following SQL:
CREATE USER adp1 IDENTIFIED BY adp1; GRANT CONNECT, RESOURCE to adp1;
Collect the following application server information:
admin server host
admin server port
admin user name
admin password
admin connect protocol (for example, t3 or t3s)
Install ADP from Management Service (OMS) home directory. The default location is: <ORACLE_HOME>/Middleware/oms11g/ocamm
Locate the ocamm.zip file. You can either unzip the file on this machine or copy the ocamm.zip file to another machine where you want the ADP Manager to reside.
The ADP Manager should be installed as a non-root user (that is, "oracle") and be the same as the Management Agent install user.
Because of size, Oracle recommends that you install the ADP Manager (2 GB RAM), the OMS (2 GB RAM), and the ADP database (3 GB RAM) on different machines. This recommendation does not apply if the machine that houses the Management Service has enough CPUs (at least 1 per server) and RAM, for both the Management Service and the ADP Manager.
Run Disk1/InstData/<platform>/VM/install.bin. For Windows, use install.exe
Select the location to install into when prompted, do not create links. In the following steps, <ADP_HOME> is used to refer to the location you selected for the installation.
Start the configuration console by running <ADP_HOME>/bin/config.sh
This may bring up an applet login window if it is run on Windows or on UNIX with X-windows. Ignore the UI and proceed to Step 8.
To access the Configuration tab from the Grid Control Home page, click Targets, then click Middleware. On the Middleware page, in the Related Links section, click Application Dependency and Performance. Go to the Registration tab, select Manager.
Enter in the IP address for the machine where you installed the ADP manager in step 4. Use 51099 as the default port. Click Add and then verify your configuration by clicking Test Connection.
Click Configuration and select the Database Configuration node. Edit the existing default database configuration MyOracle
Enter your database access credentials
Click Test Connection to verify database connection and then click OK
Shut down the configuration console by running <ADP_HOME>/bin/acshut.sh
Wait about 30 seconds after acshut.sh exits for the shutdown to complete
If you are monitoring a WebLogic server, deploy (from the ADP/OCAMM install directory) <ADP_HOME>/deploy/HttpDeployer.ear to your admin server. This step is optional for OC4J.
Start the ADP Manager by running <ADP_HOME>/bin/acsera.sh (for example, nohup ./acsera.sh &")
Return to the ADP UI, click Configuration tab, and then select Resource Configuration node.
Click Create New Resource
Enter resource name Product and Version. (NOTE: For WebLogic versions 10.3.2 and higher, use version "11.1", which corresponds to the Oracle Fusion Middleware version number.) Click Continue.
Click Configure and enter your application server access information For an Oracle WebLogic Server, the fields listed are the following:
Protocol: Either t3 or t3s, depending on the protocol used to access JMX MBeans and EJBs on the monitored domain
Host: DNS name or IP address of the WebLogic Admin server for the monitored domain. (Note: If a <listen-address> is specified for the admin server, the name listed here must match that parameter.
Port: Port which the WebLogic Admin server is listening for t3 connections.
Http Host: DNS name or IP address of WebLogic server where the HttpDeployer.ear has been deployed (usually the admin server).
Http Port: Port where the Weblogic server where the HttpDeployer.ear has been deployed is listening for connections
Http Protocol: Either http or https depending on the configuration of the WebLogic server where the HttpDeployer.ear has been deployed
Admin Server User ID: User name to access the WebLogic admin server
New Password: Password for the username used to WebLogic admin server
Retype New Password: Repeated password for the username used to access the WebLogic admin server
BPEL JNDI Factory: Only used for SOA Suite 10g (Not used for 11g). Ignored in all other cases. For SOA Suite 10g, the BPEL JNDI factory used to access the BPEL API. Typically, leave at the default value.
BPEL JNDI URL: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases.
JNDI URL used to access the SOA Suite 10g BPEL API. Typically, follow the pattern of the default value and change the host and port to match.
BPEL Console User Name: Only used for SOA Suite 10g (not used for 11g). Ignored in all other cases. Username used to access the BPEL console.
BPEL Console Password: Only used for SOA Suite 10g (not used for 11g). Ignored in all other cases. Password associated with the username used to access the BPEL console.
ESB protocol: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases. URL used to access the SOA Suite 10g ESB API. Either http or https depending on the configuration of the ESB.
ESB Host: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases. DNS name or IP address used to access the SOA Suite 10g ESB API.
ESB Port: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases. Port used to access the SOA Suite 10g ESB API.
ESB Console User Name: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases. User name used to access the ESB console.
ESB Console Password: Only used for SOA Suite 10g (NOT used for 11g). Ignored in all other cases. Password associated with the user used to access the ESB console
Agent Keystore Password: DO NOT change this value unless you have installed a custom agent keystore into the ADP Manager.
Agent Truststore Password: DO NOT change this value unless you have installed a custom agent truststore into the ADP Manager.
Provider Home: Typically, this field is left blank and the ADP Manager will auto-detect the provider home. If there are deployment problems, this field may be used to manually override the root path where WebLogic client jars are downloaded from the WebLogic admin server. If such a manual override is necessary, enter in an absolute path to the WebLogic home (WL_HOME) on the admin server specified.
Click OK to return to the previous screen
Click Test Connection. If you are monitoring a WebLogic server, wait for the <ADP_HOME>/lib/bea/<version>_runtime directory to be created and populated with jar files. This could take a few minutes. If nothing happens, check log/manager-log#.csv for exceptions.
Click Back to return to the previous screen and then click Deploy
On the subsequent screen, select Deploy from the Command menu and then select the servers/cluster you want to deploy the Agent to. Ensure that the admin server is always selected.
Note: In the case of WebLogic Portal, AdminServer is always selected. Please unselect / select Nodemanager in case of weblogic based on how do configure the Weblogic manager to start.
Click Continue
Wait for deployment to complete. Verify that the UI reports Deployment Successful; if not, check for exceptions in <ADP_HOME>log/manager-log#.csv
To view the status on the same page, click Refresh. Note that you might have to click Refresh a few times as it my take a while to deploy and update the status. Depending on the number of managed servers in your domain, it could take several minutes (up to 60 seconds per managed server) for this operation to complete. Stay on this page and monitor the manager log until some status is returned.
Click Back to return to the previous screen and then click Save
Close the browser-based console
Shut down the ADP Manager by running <ADP_HOME>/bin/acshut.sh
Wait about 30 seconds after acshut.sh exits for the shutdown to complete
Restart the application servers you deployed the Agent to. The ADP installer adds jar files to the system classpath and adds parameters to the Java options when deployed. An application server restart is required for those to take effect.
Start the ADP Manager by running <ADP_HOME>/bin/acsera.sh (for example, nohup ./acsera.sh &")
Wait for discovery to occur. You can check that discovery is happening by looking to see if <ADP_HOME>/darchive/server_archive is created and growing, and then that <ADP_HOME>/darchive/app_archive is created and growing. If you think something is going wrong, you can check log/manager-log#.csv for exceptions, but this process can take several minutes.
To return to the ADP pages from the Grid Control Home page, click Targets, then click Middleware. On the Middleware page, in the Related Links section, click Application Dependency and Performance. Go to the Monitoring tab.
Verify that all servers to which you deployed the ADP Agent are up and running. Click the CAMM node in the Monitoring tab. The Agent information is available n the Main Display window.
For metrics to be reported, the agent status must be in the REPORTING state. (If Agent Installed is true, the Agent Status will start in the DEPLOYED state, then go to CONNECTED, and then become REPORTING.) Check the manager and agent logs for exceptions if this is not the case.
Prior to installing ADP, install the Oracle Management Service.
To save yourself time during the installation and configuration processes, check compliance with the following dependencies. The following list uses examples of environment dependencies for WebLogic 8.1, 9.2, 10.0, and 10.3.2.
Check Support Hardware
CPU - At least 1 CPU (2 Ghz Intel-equivalent or better) for the ADP Manager
RAM - At least 2GB RAM for the ADP Manager
Free HD Space - At least 20 GB free disk for the ADP Manager
Check Supported OS
OS
Patch Level
JRE - Clients must have the Java 1.6 Plugin installed
Check Network
No Firewalls (same subnet)
If Firewalls - ports are open The CAMM manager must be able to communicate to the monitored application servers on their t3 (or t3s if enabled) ports directly. The monitored application servers must be able to communicate with the CAMM manager on ports 51099 and 55003 directly.
No multi-homing interface conflicts
IP interfaces are static
Check browsers
The following browsers are supported:
Mozilla Firefox 3.0 and higher
Internet Explorer 7 and higher
Safari 4.0 and higher
Check Web Logic configuration
WebLogic 8.1, 9.x, 10.x
One cluster per WLI domain
Applications deployed and running
There is process load
t3 channels are enabled
Check Database
Check availability of Oracle database - Ensure that the schema has been created for ADP data and that connectivity is available from the ADP Manager.
Consider the following environment considerations:
Determine whether you have access and connections to the monitored application platform, network, and DHCP.
With respect to the target application platform to be monitored, ADP requires the following level of access:
System Access to the Oracle SOA Suite/Oracle WebLogic/IBM WebSphere Application domain environment (such as ability to deploy to the domain and restart the domain)
System Administration capabilities to modify WebLogic/WebSphere startup files.
Note that ADP accesses the target application platform as application users created with administrative privileges. Creating an operating system user (such as a UNIX user) is not necessary other than securing the ADP installation and configurations.
The Oracle SOA Suite/Oracle WebLogic/IBM WebSphere Administration domain server and the Managed Servers must be accessible from the machine where ADP is being installed.
Firewalls provide security for networks and applications by preventing certain connectivity between machines, servers, and applications. ADP is remotely monitoring performance and availability of the Oracle SOA Suite/Oracle WebLogic/IBM WebSphere runtime environment. If firewalls or proxies are present in the network topology, they must be configured to allow communication traffic between ADP and the Oracle SOA Suite/Oracle WebLogic/IBM WebSphere runtime environment.
Oracle recommends that the ADP dedicated machine be deployed into the same subnet, within the firewall perimeter.
If a firewall is unavoidable, ensure that the ADP port is open and that t3 and RMI traffic is allowed. The ADP Manager communicates with the monitored application server with JMX and EJB/T3 calls. The ADP Agent communicates back to the ADP Manager using Sun RMI.
If you are using ipv6 addressing:
Install the application domain environment and ADP in the ipv6 machine, and
Comment out the following line in the config.sh and acsera.sh files:
java.net.preferIPv4Stack=true
Ensure that the ADP database is properly installed and configured.
ADP can store application metadata, performance and availability metrics in either a dedicated database or a schema located in the Management Repository. The database and schema must be accessible by ADP. Currently, ADP supports Oracle 10g, Oracle 11g, and MySQL database platforms for the repository.
For an Oracle or MySQL database installation, a dedicated user database and schema should be created with adequate access rights and connectivity restrictions. Setup and configuration for the MySQL database are covered in Configuring MySQL DBMS for ADP.
Application domain is a logical/administrative context for a collection of resources, such as a WebLogic cluster (or WebSphere cell) and/or standalone server instances. A single ADP Manager instance can also monitor mixed application domains of different vendor platforms. Thus, with a single Manager instance, a human operator can have a single, consistent view into a large, heterogeneous environment where, for example, WebLogic domains and WebSphere cells co-exist.
Because of this flexibility, a single instance of ADP is best dedicated to a single environment - as in production, or QA. Within each environment, application server platforms may be heterogeneous, based on different vendors (WebLogic/WebSphere) or different versions (WLS 9.2 versus 10.0), and have diverse deployment configurations (such as standalone servers, Oracle SOA Suite, WLS clusters and/or WebSphere cells).
Mixing environments within a single ADP instance (such as domains from production and from QA) is technically feasible but not recommended, since traffic patterns from the different environments tend to be different (live versus load testing) and can complicate advanced data analyses. In this case, deploying multiple instances of ADP would be the correct solution, where a dedicated ADP instance monitors each specific environment (Production, Staging, QA, and so on). You can find details about multiple ADP instances support in Deploying ADP Components.
WebLogic clustering includes clusters and the Node Manager.
ADP supports the monitoring of performance and availability across any number of servers, clusters, and machine configurations across multiple WebLogic domains. It will automatically detect application clustered deployments and dependencies and build metrics that relate to this deployment architecture. There are no limitations for the number of domains, clusters, machines, and servers a single ADP instance can monitor.
Node Manager is used by the WebLogic Admin server to remotely start and stop WebLogic Managed Server instances. The ADP Agent Deployment makes some changes to startup parameters of a Managed Server. When using Node Manager, the ADP Agent Deployment detects that Node Manager is running and make those changes to the Node Manager server JVM startup parameters.
To save time during the installation and configuration of the ADP Manager and ADP Agent, get the privileges and field information you need before you start the process.
Contact the Database Administrator (DBA) for the information needed to fill in the fields in the Resource section of the installation. You need the following values for the Oracle database instance:
Database SID (service identifier)
Database host and port
Database user with CONNECT and RESOURCE roles
Contact the WebLogic Administrator (WebLogic Admin) for the following values:
Admin Console host and port
WebLogic administrator username and password
If using the Oracle SOA Suite: BPEL and ESB console username, password, host, and port
This section describes the ADP installation process in detail. For generic installation information, refer to Quick Steps for Installing and Configuring the ADP Manager.
Topics include:
Perform the following steps to install ADP on Windows. Note that at any time during the installation, you can click Cancel to cancel the installation, or click Previous to go back a screen.
Install ADP from the OMS home directory. The default location is: <ORACLE_HOME>/Middleware/oms11g/ocamm
The installation automatically starts. Choose the language in which you want the installation instructions.
The Introduction screen appears.
Read the introduction text and click Next.
The Choose Install Set screen appears.
The Install Folder screen appears.
Click Next. On the Choose Install Folder screen, indicate which folder will contain the installation. Either type the folder's location or accept the default C:\oracle\em11g folder.
Click Next. On the Choose Shortcut Folder screen, choose a Shortcut Folder in which to copy the ADP product icons. If desired, select the Create Icons for All Users box.
Click Next. The Pre-Installation Summary screen lists the options to be installed. If an option is not correct, click Previous to move back and correct the option. When the summary is correct, click Next.
Perform the following steps to install ADP on your UNIX environment. Note that at any time during the installation, you can type back to go back, and can cancel the installation by typing quit.
Install ADP from the OMS home directory. The default location is: <ORACLE_HOME>/Middleware/oms11g/ocamm.
In the ocamm directory, unzip the camm.zip file and execute the install.bin program:
unzip camm.zip ./install.bin
Note: Ensure that install.bin has execution privileges and, if necessary, use chmod a+x install.bin command to make it executable.
The Introduction screen appears. Choose the language in which you want the installation instructions.
Read the introduction text and press the <ENTER> key to continue.
Click Next. From the Install Folder text, indicate which folder will contain the installation. Either type the folder's location or accept the default $HOME/oracle/em11g.
Choose Install Folder --------------------- Where would you like to install? Default Install Folder: /root/oracle/em11g ENTER AN ABSOLUTE PATH, OR PRESS <ENTER> TO ACCEPT THE DEFAULT :
Choose the directory in which to install ADP and press the <ENTER> key. You will be prompted of where to install the ADP product icons.
Click Next. Indicate which directory will contain the Link locations.
Choose Link Location
--------------------
Where would you like to create links?
->1- Default: /root
2- In your home folder
3- Choose another location...
4- Don't create links
ENTER THE NUMBER OF AN OPTION ABOVE, OR PRESS <ENTER> TO ACCEPT THE DEFAULT
:
Choose the desired directory and press the <ENTER> key. You will be shown a summary of your installation choices
Choose option 4 - Don't create links. Run startup scripts out of the bin directory as the install location.
Verify that your installation choices are correct. If they are not, type back to go back and make choices. If you are satisfied, press the <ENTER> key to begin the installation.
Press <ENTER> to finish after the installation completes.
ADP requires an RDBMS be setup as the data repository for runtime metrics collection. Oracle 10g, Oracle 11g, and MySQL RDBMS are supported for this purpose. Details for manual installation and configuration of the Data Repository are described in Installing and Configuring ADP Data Repository.
Deploying ADP components involves the following steps:
Configuring ADP with information about the target application platform. For each monitoring environment, a single instance of ADP can monitor multiple application servers or clusters.
Deploying the ADP Agent components to the target application server instances or clusters (for example, managed servers in a cluster of a domain, and so on).
To deploy ADP components, refer to Configuring ADP.
In ADP, a monitored target application platform, whether it is an individual application server instance or a cluster in a management domain, is called a Resource.
Oracle highly recommends that you register and update the configuration of your server resources through the ADP Manager.
Start the ADP Manager.
Windows: From the Start menu, select Oracle, then select ADP.
UNIX: In the /bin directory, invoke the following command:
nohup ./config.sh &
On the Grid Control Home page, click Targets, then click Middleware. On the Middleware page, select Application Dependency and Performance in the Related Links section.
Select the Configuration tab and select Resource Configuration.
Click the Create New Resource button in the main pane.
Name your resource and select your application server product and version.
Click Continue.
Click Configure in the middle of the main pane.
Type in your application server details. Ignore the BPEL and ESB related options if you do not have the Oracle SOA Suite.
Important:
DO NOT modify the fields for Agent Keystore Password and Agent Truststore Password.Click OK.
Click Save. (If you omit this step, your configuration will be lost.)
The following sections describe how to deploy ADP Agents on the WebLogic platform.
Use the WebLogic Admin console to deploy the em11g/deploy/HttpDeployer.ear application.
Using the GUI-based deployer as documented in the Quick Steps for Installing and Configuring the ADP Manager is recommended.
Deployment of ADP Agent for WebSphere platform is a two-phase process. First you need to install ADP IBM Deployer application responsible for ADP Agent libraries deployment initial handshake between ADP and ADP Agent, then deploy the Agent libraries on the target system. There are two options to achieve this:
Automatic deployment using ADP websphereDeployer script
Manually installing all the supporting artifacts
Once WebSphere is registered via the ADP Administration UI, the libraries required by ADP to connect to WebSphere must be defined in the actual classpath. This is done through the Resource Configuration UI.
Note that an installation must be available directly on the machine or via a NFS/SMB mount. The following property would need to be modified to mirror the absolute path to the WebSphere Application Server (WAS) home directory. The necessary libraries will then be loaded on the classpath accordingly.
Example of wsHome setting:
<ns1:configParameter>
<ns1:key>wsHome</ns1:key>
<ns1:value>C:/Progra~1/IBM/WebSphere/AppServer</ns1:value>
</ns1:configParameter>
The following sections explain how to automatically deploy the ADP Agent for the WebSphere platform.
Deploying WebSphere File Transfer Application
If you are using a network deployment manager (dmgr), you should skip this step. Otherwise (if running a standalone WAS server), ensure the WebSphere File Transfer Application is installed and running. If not, deploy filetransfer.ear to the WebSphere application server. This is required to enable the ADP Agent automatic deployment process. If the ADP Agent is being installed manually, the file transfer application is not required.
Deploying ADP Java Agent for WebSphere Platform
Using the GUI-based deployer as documented in the Chapter 10, "Quick Steps for Installing and Configuring the ADP Manager" is recommended.
Use the GUI-based deployer as documented in Quick Steps for Installing and Configuring the ADP Manager.
There will always be a default instance of the ADP (the installed instance). For each additional Manager instance needed, first create an instance directory underneath ACSERA_HOME. (ACSERA_HOME is the directory that ADP was installed into, for example, C:\oracle\em11g.) Copy the installed config, mccconfig, and schema directories under the new instance directory.
In INSTANCE_DIR/config/Acsera.properties, set the following properties to unique, instance-specific values:
RMI.Registry.Port = other than the original one (51099 by default)
RMI.RemoteServiceController.ServerPort= other than the original one (55000 by default)
RMI.JavaProvider.ServerPort= set the port to be more than 100 counts greater than the original new instance. For example, if the original port is 55003, increase the RMI.JavaProvider.ServerPort to 55103.
The default value for RMI.Registry.Port is 51099. It is recommended that additional Manager instances use values counting down from the default (51098, 51097, and so on.)
Update dbconfig.xml for the target database (use a different database schema for the instance).
If there is a JDK installed under the ACSERA_HOME directory, then the scripts will use that JDK. Otherwise, JAVA_HOME must be set to the directory of the installed JDK.
The following commands may be used to control non-default Manager instances:
| Windows | Linux/AIX/Solaris/HP-UX |
|---|---|
| bin/acsera.bat | bin/acsera.sh |
| bin/acshut.bat | bin/acshut.sh |
| bin/deployer.bat | bin/deployer.sh |
| bin/standalone.bat | bin/standalone.sh |
The acsera.*, acshut.* and standalone.* scripts take an instance name as the first argument. Leaving out the instance name causes the script to target the default instance.
The configure new ports, perform the following steps:
From the Grid Control Home page, click Targets, then click Middleware. On the Middleware page, select Application Dependency and Performance in the Related Links section.
On the ADP page, click the Registration tab and register a new manager using a new port.
ADP maintains a database (can be Oracle or MySQL) of information collected on the system it is monitoring. This database can be contained on the same machine on which ADP is running. It can also be hosted on a remote machine. The following paragraphs describe how to configure the ADP Data Repository.
The following sections describe procedures that may be performed by the ADP administrator to customize the database configuration.
ADP currently supports the Oracle 11g database for its runtime repository. In order to set this up, the following steps are necessary in order to setup and configure the Oracle DBMS for ADP. ADP will initialize the database upon connecting to it and generate the required tables.
Install Oracle DB: 11g on a separate machine
Create a new user in database (preferably "ADP" or something distinct)
Set the System Global Area to have at least 1 GB (1275068416 bytes)
Increase the number of processes in database from 150 to 300 (optional; this is primarily for an OracleXE database).
Execute the following commands using Oracle SQL*Plus:
connect / as sysdba; (this will connect to the database as DBA)
show parameter processes;
| NAME | TYPE | VALUE |
|---|---|---|
| aq_tm_processes | integer | 0 |
| db_writer_processes | integer | 1 |
| gcs_server_processes | integer | 0 |
| job_queue_processes | integer | 10 |
| log_archive_max_processes | integer | 2 |
| processes | integer | 150 |
alter system set processes=300 scope=spfile; (Run this to increase the number of processes. You can set it to a higher number if you want.)
shutdown immediate (for shutdown the server)
startup (startup the server)
show parameter processes; (run this to verify the changes took effect)
Use of the GUI-based configuration tool described in the Quick Steps for Installing and Configuring the ADP Manager at the beginning of this manual is recommended. For manual database configuration, fields in dbconfig.xml may be modified.
ADP currently supports MySQL 4.1 database and higher for its runtime repository. The following steps are necessary to setup and configure the Oracle DBMS for ADP. ADP initializes the database upon connecting to it and generates the required tables.
Install MySQL 4.1 or higher on a separate machine
Create a new user in the database (preferably "Oracle" or something distinct) and grant the user the appropriate privileges
Tune memory for performance as indicated below:
On a 1 GB server shared by ADP and MySQL, the following parameter should be set in the my.ini file to increase database subsystem performance:
set-variable=key_buffer=128M
On a 2 GB server shared by ADP and MySQL or on a dedicated to MySQL 1GB server, the parameter should be set as:
set-variable=key_buffer=256M
Oracle recommends that regular backups be made of the database utilized as a runtime repository for ADP. The Oracle database provides the EXP and IMP tools that allow you to quickly backup and restore the database if necessary. The most convenient method for backing up the MySQL database is using the mysqldump command. By default, this is found in c:\mysql\bin on Windows, or /mysql/bin on UNIX.
This section explains the following post-installation requirements:
Configuring Oracle WebLogic Server or Oracle WebLogic Portal (WLP) for Secure Connectivity
Configuring the ADP Agent When WebLogic Is Installed As a Windows Service
Note:
You must register the CAMM Manager with the Oracle Management Service. Otherwise, the ADP UI will not be available.The following post-deployment requirements are specific to ADP deployments on IBM WebSphere Application Server.
The main goal is to add the signer certificate of each administration server to ADP's truststore, which is needed by each resource to connect to the server. This allows ADP to trust the server when making secured (SSL) connections to the server. Without this trust, the SSL handshake will fail.
When using the default ADP truststore, the server's signer certificate would be added to AcseraManagerTrust.jks. This procedure assumes that the customer is using the default key.p12 and trust.p12 keystores for their security support. If a different trust store is being used, refer to that trust store instead.
Exporting the administration server's signer certificate for resource.
If the administration server is the deployment manager in a WebSphere Application Server ND, export signer certificate from trust.p12 of the deployment manager located at path
<WAS_HOME>\profiles\Dmgr01\config\cells\<CellName>\trust.p12
If the administration server is a standalone server, export the signer certificate from trust.p12 of the standalone server located on the following path:
<WAS_HOME>\profiles\AppSrv01\config\cells\<CellName>\nodes\<NodeName>\trust.p12
To export, run the following command:
JAVA_HOME/bin/keytool -export -keystore <trust path> -storepass WebAS -storetype PKCS12 -alias default_signer -file servercert
Note: When exporting a PKCS12 store type, run keytool from an IBM JDK since it has support for this format type.
Import the administration server's signer certificate into the ADP truststore.
Import the exported certification according to the information in Importing a Certificate into the Manager's Keystore.
To run ADP against WebSphere with enabled Global Security, perform the following steps:
Identify the com.ibm.ssl.keyStore and com.ibm.ssl.trustStore files in soap.client.props and sas.client.props in [WAS_HOME]/properties as follows:
Copy the indicated keystore and truststore files to the ADP Manager.
Import the files following the instructions in Importing a Certificate into the Manager's Keystore.
If you encounter security exceptions in the ADP EJB when the application server starts, you may need to update the [WAS_HOME]/properties/server.policy file and append the configuration that follows.
// Allow the Acsera Agent all permissions
grant codeBase "file:${was.install.root}/AcseraAgent/lib/-" {
permission java.security.AllPermission;
};
// Allow the Acsera Deployer EJBs all permissions
grant codeBase "file:${was.install.root}/installedApps/[node]/[Acsera app name].ear/-" {
permission java.security.AllPermission;
};
Normally, using the websphereDeployer command, the ADP deployer EJBs would be deployed in the WebSphere server environment with the application name of the form:
Acsera_<node name>_<server name>
For example, this is an application name of a deployer deployed on node a6-7 and server WebSphere_Portal.
Acsera_a6-7_WebSphere_Portal
The Oracle SOA Suite may be configured to support RMIS (RMI over SSL) connectivity. In this case, ADP can be configured to use this secure connection. To configure ADP to do this, perform the following steps:
On the Oracle SOA Suite install, look at ORACLE_HOME/j2ee/<instance>/config/rmi.xml, locate the <ssl-config> element, and identify the path in the keystore attribute.
Copy the keystore file indicated to ADP manager's config directory (for example, em10/config)
Import this keystore file following the instructions in Importing a Certificate into the Manager's Keystore.
To configure Oracle WebLogic Server 10.0 to handle connectivity using t3s, the location of the keystore files needs to be updated through the console.
Log in to the WebLogic Server console and select the servers under the Environment Servers list that is displayed which you plan to manage with ADP.
Select a server from the server list.
Select the keystores tab click Load & Edit to update the Keystore
Make the following changes. Identify the keystore and truststore file paths from the following properties:
Identity
Custom Identity Keystore
Trust
Custom Trust Keystore: location of the trust file
Repeat steps 2 through 4 for additional server instances that will be managed.
Copy the identified keystore and truststore files to the ADP manager.
Copy the BEA_HOME/license.bea to the ADP manager's config directory (for example, em11g/config)
Import the keystore and truststore files following the instructions in Importing a Certificate into the Manager's Keystore
Locate the following properties in the Acsera.properties file and set them as follows:
weblogic.security.TrustKeyStore=CustomTrust weblogic.security.CustomTrustKeyStoreFileName=AcseraManagerTrust.jks weblogic.security.CustomTrustKeyStorePassPhrase=acseramanager
To import entries from a keystore or truststore, perform the following steps, replacing ServerStoreFile.jks with the keystore or truststore from your application server. (Skip steps 1 and 2 if you are importing certificate files from WAS 6.1 as described in Configuring ADP for WebSphere Application Server 6.1 Secured Connections.) You will generally need to complete these steps twice, once for the keystore and once for the truststore.
List the key aliases in the keystore/trustfile file from the server
keytool -list -keystore ServerStoreFile.jks –storepass DemoIdentityKeyStorePassPhrase
Output:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 1 entry:
demoidentity, Wed Nov 19 13:34:56 PST 2008, keyEntry, Certificate fingerprint
(MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
Export a key entry to an intermediate file
keytool -export -alias demoidentity -keystore ServerStoreFile.jks -storepass DemoIdentityKeyStorePassPhrase -file demo103
Output:
Certificate stored in file <demo103>
Import the key into the ADP store file (either AcseraManagerKey.jks or AcseraManagerTrust.jks in the ADP manager's config directory)
keytool -import -alias demoidentity1 -keystore AcseraManagerKey.jks -storepass acseramanager -file demo103
Output:
Owner: CN=b91, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Issuer: CN=CertGenCAB, OU=FOR TESTING ONLY, O=MyOrganization, L=MyTown, ST=MyState, C=US
Serial number: 510fb3d4b2872e3a093d436fcbe9b24b
Valid from: Tue Nov 18 13:34:47 PST 2008 until: Sun Nov 19 13:34:47 PST 2023
Certificate fingerprints:
MD5: 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
SHA1: BB:85:6D:4C:0B:4A:92:63:CA:5E:E9:A8:54:42:80:2D:0D:BE:7C:91
Trust this certificate? [no]: yes
Certificate was added to keystore
Verify that the key was imported successfully
keytool -list -keystore AcseraManagerKey.jks -storepass acseramanager
Output:
Keystore type: jks
Keystore provider: SUN
Your keystore contains 3 entries:
demoidentity1, Wed Apr 01 13:03:21 PST 2009, trustedCertEntry,
Certificate fingerprint (MD5): 36:06:C2:44:31:0A:28:FC:06:19:F7:AB:C0:7D:27:6A
demoidentity, Fri Mar 13 15:15:06 PST 2009, trustedCertEntry,
Certificate fingerprint (MD5): 0B:11:02:B5:44:0D:2A:CC:7F:C5:30:5C:1A:C9:A1:6C
mykey, Thu May 19 16:57:36 PDT 2005, keyEntry,
Certificate fingerprint (MD5): 5D:B0:EC:28:14:33:26:1F:44:F5:BE:DD:A8:50:15:9D
Repeat steps 2 through 4 for each key entry listed in step 1.
At present with ADP running with a bundled Sun HotSpot JDK, it is not possible for ADP to configure with PKCS12 type key/trust stores for secured connections. IBM JDK has built-in enhancements that allow it to work with PKCS12 key/trust stores, such as WebSphere 6.1's default key.p12 and trust.p12 stores. Also, there is a WebSphere 6.1 automatic function that is enabled with the property com.ibm.ssl.enableSignerExchangePrompt=true that allows a client connecting to a secure WebSphere port that allows automatic download of server's signer certificate and update of client's truststore. However, this automatic function is only available when ADP is running with an IBM JDK which is not the case at present. This is the reason why we need to follow the above procedure to connect with a secured WebSphere 6.1.
When the monitored WebLogic server is installed as a Windows Service, the automatic startup changes to deploy the ADP Agent need to be manually applied to the registry entries that control WebLogic startup.
The parameters which need to be changed are in the Windows registry key:
HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\$ServiceName\Parameters
Users should then consult the file on the ADP Manager:
deploy/agent/bea/bin/agentoptions.bat (for WebLogic 8.1.x) deploy/agent/bea9/bin/agentoptions.bat (for WebLogic 9.x and higher)
Inspect this file and resolve the net results of its execution as Parameters in the registry.
Note that the beaaj.jar named on the %EXT_POST_CLASSPATH% variable needs to be placed on the server's classpath.