This section contains the following subsections:
Section 16.3.1, "How do I reset the password for the administration server user?"
Section 16.3.3, "How do I access the administration console?"
Section 16.3.7, "Why is the "Deployment Pending" message displayed in the administration console?"
Section 16.3.9, "Why does the administration console session end abruptly?"
Section 16.3.13, "How do I find out the short names for the options of a CLI command?"
Section 16.3.14, "Can I configure the CLI to not prompt for a password every time I access it?"
Section 16.3.18, "How do I enable SSL/TLS for an Oracle Traffic Director instance?"
Section 16.3.19, "How do I find out which SSL/TLS cipher suites are supported and enabled?"
Section 16.3.20, "How do I view a list of installed certificates?"
Section 16.3.26, "Why does Oracle Traffic Director return a 405 status code?"
Section 16.3.27, "What is the minimum supported JDK version, and JAVA_HOME variable?"
Run the reset-admin-password CLI command as described in the "Changing the Administrator User Name and Password Using the CLI" section.
A configuration, in Oracle Traffic Director terminology, is a collection of configurable elements (metadata) that determine the run-time behavior of an Oracle Traffic Director instance.
For more information, see Section 1.4, "Oracle Traffic Director Terminology."
The browser displays a warning because the administration server has a self-signed certificate. To proceed, you should choose to trust the certificate.
The files in the configuration store are updated automatically when you edit a configuration by using either the administration console or the CLI. Unless otherwise instructed in the Oracle Traffic Director documentation, DO NOT edit the files in the configuration store manually.
For the configuration changes to take effect, you should deploy the configuration to the instances as described in Section 4.3, "Deploying a Configuration."
If you inadvertently edit a configuration file of an instance, and if you want to retain the change and replicate it in all the instances of the configuration, you can pull the configuration from the instance to the administration server, as described Section 4.5, "Synchronizing Configurations Between the Administration Server and Nodes."
When you save a configuration, the changes you made are saved in the configuration store on the administration server. For the changes to take effect in the instances of the configuration, you must deploy the configuration as described in Section 4.3, "Deploying a Configuration."
The Deployment Pending message is displayed in the administration console when you change a configuration and save it on the administration server. It indicates that the changes are yet to be copied over to the instances of the configuration.
If you have finished making the required configuration changes, you can deploy the changes to all of the instances by clicking Deploy Changes in the administration console or by running the deploy-config CLI command, as described in Section 4.3, "Deploying a Configuration."
The Instance Configuration Deployed message is displayed in the administration console when you manually edit the configuration files of an instance. It indicates that the configuration files of one or more instances are different from the corresponding configuration files stored in the configuration store on the administration server. For information about what you should do in this situation, see Section 4.5, "Synchronizing Configurations Between the Administration Server and Nodes."
If an administration console session remains inactive for 30 minutes, it ends automatically. You should log in again.
For the specified CLI subcommand to be executed, it must precede all the options, including the common options like --user and --host. Otherwise, the CLI assumes that you attempting to invoke the shell mode.
The CLI connects to the SSL port of the administration server. The administration server has a self-signed certificate. The message that you see when you connect to the administration server for the first time is a prompt to choose whether you trust the certificate. Make sure that you are connecting to the correct server and port, and enter y to trust the certificate. For subsequent invocations of the CLI, the warning message is not displayed.
See help for the command, by running the command with the --help option.
Yes. Store the password in a file in the format, tadm_password=password. When you run a CLI command, specify the full path to the password file by using the --password-file option.
When dynamic discovery is enabled, Oracle Traffic Director needs to send, at a specified interval, an HTTP request containing specific headers to determine whether the origin servers specified in the pool are Oracle WebLogic Server instances and whether the servers belong to a cluster. The response to a TCP health-check request would not provide the necessary information to determine the presence of Oracle WebLogic Server instances. So when dynamic discovery is enabled, the health-check protocol must be set to HTTP.
If dynamic discovery is enabled, when the Oracle Traffic Director instance starts, it determines whether or not the configured origin server is an Oracle WebLogic Server instance.
So if you initially configured, say, an Oracle GlassFish Server instance as the origin server, then at startup, Oracle Traffic Director determines that the origin server is not an Oracle WebLogic Server instance. Subsequently, if you replace the origin server with an Oracle WebLogic Server instance, then for Oracle Traffic Director to determine afresh that the origin server is now an Oracle WebLogic Server instance, you must either restart the Oracle Traffic Director instances or reconfigure them.
If you want to change the origin servers from Oracle WebLogic Server instances to other servers, or vice versa, without restarting the instances, do the following:
Create a new origin-server pool with the required origin servers, and delete the old pool. For more information, see Chapter 6, "Managing Origin-Server Pools."
Update the appropriate routes to point to the new pool, as described in Section 8.4, "Configuring Routes."
Reconfigure the Oracle Traffic Director instances by using the reconfig-instance CLI command, as described in Section 5.4, "Updating Oracle Traffic Director Instances Without Restarting."
You can enable logging of the request and response headers in the server log by modifying the appropriate route, using either the administration console or the CLI.
Using the administration console
Log in to the administration console, as described in Section 2.3.2, "Accessing the Administration Console."
Click the Configurations button that is situated at the upper left corner of the page.
A list of the available configurations is displayed.
Select the configuration for which you want to configure routes.
In the navigation pane, expand Virtual Servers, expand the name of the virtual server for which you want to configure routes, and select Routes.
The Routes page is displayed. It lists the routes that are currently defined for the selected virtual server.
Click the Name of the route that you want to configure.
The Route Settings page is displayed.
Go to the Advanced Settings section of the Route Settings page, and scroll down to the Client Configuration for Connections with Origin Servers subsection.
Select the Log Headers check box.
Click Save.
Click Deploy Changes.
Using the CLI
Run the set-route-prop command, as shown in the following example:
tadm> set-route-prop --config=soa --vs=soa.example.com --route=default-route log-headers=true
This command enables logging of the headers that Oracle Traffic Director sends to, and receives from, the origin servers associated with the route named default-route in the virtual server soa.example.com of the configuration soa.
For the updated configuration to take effect, deploy it to the Oracle Traffic Director instances by using the deploy-config command.
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the commands with the --help option.
The headers are logged in the server log as shown in the following example:
[2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11008] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: request headers sent to origin server(soa.example.com:1900) :[[ OPTIONS / HTTP/1.1 Proxy-agent: Oracle-Traffic-Director/11.1.1.7 Surrogate-capability: otd="Surrogate/1.0" Host: dadvma0178:1900 Proxy-ping: true X-weblogic-force-jvmid: unset Via: 1.1 net-test Connection: keep-aliv e ]] [2011-11-11T03:45:00.000-08:00] [net-test] [NOTIFICATION] [OTD-11009] [] [pid: 8184] for host 10.177.243.152 trying to OPTIONS / while trying to GET /favicon.ico, service-http reports: response headers received from origin server(soa.example.com:1900) :[[ HTTP/1.1 200 OK date: Fri, 11 Nov 2011 11:45:00 GMT server: Apache/2.2.17 (Unix) allow: GET,HEAD,POST,OPTIONS,TRACE content-length: 0 keep-alive: timeout=5, max=100 connection: Keep-Alive content-type: text/html]
See Section 11.2, "Configuring SSL/TLS Between Oracle Traffic Director and Clients."
See Section 11.2.4, "Configuring SSL/TLS Ciphers for a Listener."
Run the following command:
$ openssl s_client -host hostname -port portnumber -quiet
If you omit the -quiet option, information about the SSL/TLS connection—such as the server DN, certificate name, and the negotiated cipher suite—is displayed.
For testing with a specific cipher, specify the -cipher option.
After the SSL/TLS connection is established, enter an HTTP request, as shown in the following example.
GET /
For more information, see the s_client man page.
Several tools are available to observe request and response data over SSL/TLS connections. One such tool is ssltap, which serves as a simple proxy between the client and the Oracle Traffic Director and displays information about the connections that it forwards.
Run the following command:
$ ssltap -l -s otd_host:otd_port
For example, to observe the communication between clients and the SSL/TLS-enabled Oracle Traffic Director listener soa.example.com:1905, run the following command:
$ ssltap -l -s soa.example.com:8080
The following messages are displayed:
Looking up "localhost"... Proxy socket ready and listening
By default, ssltap listens on port 1924. Connect to https://localhost:1924 by using your browser.
You will see an output similar to the following:
Connection #1 [Tue Oct 25 04:29:46 2011]
Connected to localhost:8080
--> [
(177 bytes of 172)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type = 22 (handshake)
version = { 3,1 }
length = 172 (0xac)
handshake {
type = 1 (client_hello)
length = 168 (0x0000a8)
ClientHelloV3 {
client_version = {3, 1}
random = {...}
session ID = {
length = 0
contents = {...}
}
cipher_suites[29] = {
(0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV
(0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA
(0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA
(0x0039) TLS/DHE-RSA/AES256-CBC/SHA
(0x0038) TLS/DHE-DSS/AES256-CBC/SHA
(0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA
(0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA
(0x0035) TLS/RSA/AES256-CBC/SHA
(0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA
(0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA
(0xc011) TLS/ECDHE-RSA/RC4-128/SHA
(0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA
(0x0033) TLS/DHE-RSA/AES128-CBC/SHA
(0x0032) TLS/DHE-DSS/AES128-CBC/SHA
(0xc00c) TLS/ECDH-RSA/RC4-128/SHA
(0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA
(0xc002) TLS/ECDH-ECDSA/RC4-128/SHA
(0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA
(0x0004) SSL3/RSA/RC4-128/MD5
(0x0005) SSL3/RSA/RC4-128/SHA
(0x002f) TLS/RSA/AES128-CBC/SHA
(0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA
(0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA
(0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA
(0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA
(0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0x000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
compression[1] = {
(00) NULL
}
extensions[55] = {
extension type server_name, length [29] = {
0: 00 1b 00 00 18 64 61 64 76 6d 61 30 31 37 38 2e | .....soa.
10: 75 73 2e 6f 72 61 63 6c 65 2e 63 6f 6d | example.com
}
extension type elliptic_curves, length [8] = {
0: 00 06 00 17 00 18 00 19 | ........
}
extension type ec_point_formats, length [2] = {
0: 01 00 | ..
}
extension type session_ticket, length [0]
}
}
}
}
This is the SSL/TLS client hello sent from the browser to the Oracle Traffic Director instance. Note the list of cipher suites sent by the browser. These are the cipher suites that the browser is configured to handle, sorted in order of preference. The server selects one of the cipher suites for the handshake. If the server is not configured any of the cipher suites indicated by the client, the connection fails. In the above example, the session ID is empty, indicating that the browser does not have any cached SSL/TLS session with the specified server.
The Oracle Traffic Director instance's response would be similar to the following output:
<-- [
(823 bytes of 818)
SSLRecord { [Tue Oct 25 04:29:46 2011]
type = 22 (handshake)
version = { 3,1 }
length = 818 (0x332)
handshake {
type = 2 (server_hello)
length = 77 (0x00004d)
ServerHello {
server_version = {3, 1}
random = {...}
session ID = {
length = 32
contents = {...}
}
cipher_suite = (0x0035) TLS/RSA/AES256-CBC/SHA
compression method = (00) NULL
extensions[5] = {
extension type renegotiation_info, length [1] = {
0: 00 | .
}
}
}
type = 11 (certificate)
length = 729 (0x0002d9)
CertificateChain {
chainlength = 726 (0x02d6)
Certificate {
size = 723 (0x02d3)
data = { saved in file 'cert.001' }
}
}
type = 14 (server_hello_done)
length = 0 (0x000000)
}
}
]
--> [
The server selected the cipher suite, TLS/RSA/AES256-CBC/SHA and a session ID, which the client will include in subsequent requests.
The server also sent its certificate chain for the browser to verify. ssltap saved the certificates in the file cert.001. You can examine the certificates with any tool that can parse X.509 certificates. For example, run the following command:
$ openssl x509 -in cert.001 -text -inform DER
Note:
ssltap is a single threaded proxy server. So if you issue multiple requests through it, the requests will get serialized. If you need to analyze a specific problem with your application that only occurs on concurrent requests through SSL/TLS, try running multiple ssltap instances.Configure SSL debugging for the Oracle WebLogic Server instance by adding the -Dssl.debug=true system property in the start script of the serve. For more information, see "SSL Debugging" in the Oracle Fusion Middleware Securing Oracle WebLogic Server.
Increase the verbosity of the Oracle Traffic Director server log by setting the log level to TRACE:32, as described in Section 12.3, "Configuring Log Preferences."
This error can occur for the following origin servers:
SSL/TLS-enabled origin servers that are configured in the origin-server pool by using IP addresses instead of host names.
Dynamically discovered, SSL/TLS-enabled Oracle WebLogic Server origin servers. Oracle Traffic Director refers to them using their IP addresses rather than the host names.
While Oracle Traffic Director refers to such origin servers by using their IP addresses, the certificates of the origin servers contain the servers' host names. So, in response to health-check requests, when the origin servers present certificates, Oracle Traffic Director attempts, unsuccessfully, to validate them. The SSL/TLS handshake fails. As a result, the health checks show such origin servers to be offline. Note that server-certificate validation is enabled by default.
If you set the server-log level to TRACE:32, you can view the message logged for this failure, as shown in the following example:
[2011-11-21T09:50:54-08:00] [net-soa] [TRACE:1] [OTD-10969] [] [pid: 22466] trying to OPTIONS /, service-http reports: error sending request (SSL_ERROR_BAD_CERT_DOMAIN: Requested domain name does not match the server's certificate.)
To solve this problem, disable validation of the origin-server certificates for the required virtual-server routes, by running the set-route-prop CLI command, as shown in the following example:
tadm> set-route-prop --config=soa --vs=vs1 --route=route1 validate-server-cert=false
For the updated route to take effect, deploy the configuration by running the deploy-config command, as shown in the following example:
tadm> deploy-config soa
For more information about the CLI commands mentioned in this section, see the Oracle Traffic Director Command-Line Reference or run the command with the --help option.
The default behavior of Oracle Traffic Director is to rewrite the source IP address. However, Oracle Traffic Director does send the client IP address in an additional request header Proxy-client-ip. You can set up Oracle Traffic Director to block or forward Proxy-client-ip and other request headers by configuring the appropriate route as described in Section 8.4.
Note that Oracle Traffic Director cannot maintain case sensitivity of the HTTP request headers while forwarding them to origin servers.
If an HTTP request does not meet the conditions specified in any of the defined routes and there is no default (=unconditional) route in the configuration, then Oracle Traffic Director returns the 405 status code. This error indicates that Oracle Traffic Director did not find any valid route for the request. This situation can occur only if the default route, which is used when the request does not meet the conditions specified in any of the other routes, is deleted manually in the obj.conf configuration file. To solve this issue the administrator must create a valid route.
Note:
The default (=unconditional) route cannot be deleted through the administration console and the CLI, and should not be deleted manually.Oracle Traffic Director Release 11.1.1.9 mandates JDK 7 u60 as the minimum supported JDK version. Oracle Traffic Director 11.1.1.6 bundled JDK for its own administration purposes. Oracle Traffic Director 11.1.1.9 bundles JDK 7.
Review the status of your JDK installation as follows:
If you did not use your own JDK at the time of installing Oracle Traffic Director 11.1.1.6/7, then you do not need to consider JDK version while upgrading to Oracle Traffic Director 11.1.1.9.
If you did use your own JDK while installing Oracle Traffic Director 11.1.1.6/.7, then you will need to now provide JDK version 7 Update 60 or above as the JDK version while upgrading to Oracle Traffic Director 11.1.1.9.
You must also have a correctly set JAVA_HOME variable. If you have JAVA_HOME set to JDK 6 in your environment. and run an Oracle Traffic Director CLI command, then you may see the following error:
$ORACLE_HOME/bin/tadm configure-server --user=user1 --instance-home=$INSTANCE_HOME/instance1 --server-user=root
Exception in thread "main" java.lang.UnsupportedClassVersionError: com/sun/web/admin/cli/shelladapter/WSadminShell : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: com.sun.web.admin.cli.shelladapter.WSadminShell. Program will exit.
Workaround: remove the JAVA_HOME in your environment.