Chapter 3 Working With the Oracle Java Web Console (Tasks)

This chapter describes the Oracle Java Web Console, which is used to administer web-based Sun system management applications that are installed and registered on your system.

The following is a list of the information that is in this chapter:

• What's New in Administering the Oracle Java Web Console?

• Oracle Java Web Console (Overview)

• Getting Started With the Oracle Java Web Console

• Managing the Console Service

• Configuring the Oracle Java Web Console

• Troubleshooting the Oracle Java Web Console Software

• Oracle Java Web Console Reference Information

For information about the procedures that are associated with using the Oracle Java Web Console, see Getting Started With the Oracle Java Web Console (Task Map) and Troubleshooting the Oracle Java Web Console Software (Task Map).

What's New in Administering the Oracle Java Web Console?

This section includes features that are new in this Oracle Solaris release. For a complete listing of new features and a description of Oracle Solaris releases, see Oracle Solaris 10 9/10 What’s New.

Oracle Java Web Console Server Management

Solaris 10 11/06: The Oracle Java Web Console server is managed as a service by the Service Management Facility (SMF). For more information about SMF, see Chapter 18, Managing Services (Overview).

Applications That Are Available to the Oracle Java Web Console

Solaris 10 6/06: The Oracle Solaris ZFS web-based management tool is available in the Oracle Java Web Console. This tool enables you to perform much of the administration tasks that you can perform with the command-line interface (CLI). These capabilities include setting parameters, viewing the various pools and file systems, and making updates to them.

The following are examples of typical procedures that you might perform with the tool:

• Create a new storage pool.

• Add capacity to an existing pool.

• Move (export) a storage pool to another system.

• Import a previously exported storage pool, to make it available on another system.

• View tables of information about storage pools.

• Create a file system.

• Create a zvol (virtual volume).

• Take a snapshot of a file system or a zvol volume.

• Roll back a file system to a previous snapshot.

For more information about using the Oracle Solaris ZFS web-based management tool, see Oracle Solaris ZFS Administration Guide.

The Java Enterprise System software includes several management applications that run in the Oracle Java Web Console.

Oracle Java Web Console (Overview)

The Oracle Java Web Console provides a common location for users to access web-based system management applications. You access the web console by logging in through a secure https port with one of several supported web browsers. The single entry point that the web console provides eliminates the need to learn URLs for multiple applications. In addition, the single entry point provides user authentication and authorization for all applications that are registered with the web console.

All web console-based applications conform to the same user interface guidelines, which enhances ease of use. The web console also provides auditing of user sessions and logging service for all registered applications.

What Is the Oracle Java Web Console?

The Oracle Java Web Console is a web page where you can find the Sun system management web-based applications that are installed and registered on your system. Registration is automatically a part of an application's installation process. Thus, registration requires no administrator intervention.

The Oracle Java Web Console provides the following:

• A single point of entry for login and the launching of browser-based system management applications

  The console provides a central location from which you can start browser-based management applications simply by clicking the application names. No compatibility exists between the Oracle Java Web Console and the Solaris Management Console. The Oracle Java Web Console is a web application that you access through a browser, and Solaris Management Console is a Java application that you start from a command line. Because the consoles are completely independent, you can run both consoles on the same system at the same time.

• Single sign-on through a secure https port

  Single sign-on in this context means that you do not have to authenticate yourself to each management application after you authenticate yourself to the web console. You enter your user name and password just once per console session.

• Dynamically organized and aggregated applications

  Applications are installed and displayed on the console launch page under the category of management tasks that is most applicable.

  Categories include the following:

  • Systems

  • Storage

  • Services

  • Desktop applications

  • Other

• A common look and feel

  All web console applications use the same user interface (UI) components and behavior, thereby reducing the learning curve for administrators.

• Standard, extensible authentication, authorization, and auditing mechanisms

  The Oracle Java Web Console supports Pluggable Authentication Module (PAM), role-based access control (RBAC) roles, and Basic Security Module (BSM) auditing.

Oracle Java Web Console Management Commands

The Oracle Java Web Console includes the following management commands:

• smcwebserver – This command starts and stops the console's web server.

• wcadmin – Starting with the Solaris 10 11/06 release, this command is used to configure the console, and to register and deploy console applications. For more information, see the wcadmin(1M) man page.

• smreg – In the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 OS, this command is used to register all console applications.

  Starting with the Solaris 10 11/06 release, use this command only to register legacy applications that were created for a version of the console that is not at least Oracle Java Web Console 3.0.

The commands are used to perform various tasks that this chapter describes.

For more information about each command, see the smcwebserver(1M), wcadmin(1M), and the smreg(1M) man pages.

Supported Web Browsers

The Oracle Java Web Console can be used in any of the following browsers while running Oracle Solaris:

• Mozilla (at least Version, 1.4)

• Netscape (at least Version, 6.2)

• Firefox (at least Version, 1.0)

Getting Started With the Oracle Java Web Console (Task Map)

Getting Started With the Oracle Java Web Console

The Oracle Java Web Console's launch page lists the registered system management applications that you have permission to use, and displays a brief description of each application. You connect to a specific application by clicking its application name, which is a link to the actual application. By default, the selected application opens in the web console window. You can choose to open applications in separate browser windows by clicking the Start Each Application in a New Window check box. When you open applications in separate windows, the web console launch page remains available, so you can return to it and launch multiple applications under a single login.

To access the console launch page, type a URL of the following format in the web location field:

https://hostname.domain:6789

where the following applies:

• https specifies a Secure Socket Layer (SSL) connection

• hostname.domain specifies the name and domain of the server that is hosting the console

• 6789 is the console's assigned port number

The first time you access the Oracle Java Web Console from a particular system, you must accept the server's certificate before the web console's launch page is displayed.

If RBAC is enabled on the system, and your user identity is assigned to a role, you are prompted for a role password after you have successfully logged in. If you assume a role, authorization checks are made for the assumed role. You can opt out of assuming a role by selecting NO ROLE, and then authorization checks are made against your user identity. Following a successful authorization check, the web console launch page is displayed.

How to Start Applications From the Oracle Java Web Console's Launch Page

1. Start a web browser that is compatible with the Oracle Java Web Console, such as Mozilla 1.7 or Firefox 1.0.

   See Supported Web Browsers for a list of supported browsers.

2. Type the console's URL in the web browser's location field.

   For example, if the management server host is named sailfish, and the domain is sw, the URL is https://sailfish.sw:6789. This URL takes you to the web console login page.

3. Accept the server's certificate.

   You only have to accept the server's certificate once per browser session, not each time you login to the console or start an application.

   The login page is displayed as shown in the following figure.

   Figure 3–1 Oracle Java Web Console Login Page

   
   

4. Enter your user name and password, and optionally your RBAC role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

   The console services check your credentials to authenticate them, and ensure that you are authorized to use the console and registered applications.

5. If you want to run the application in a new window, click the Start Each Application in a New Window check box.

   If you do not select this option, the application will run in the default window, replacing the launch page.

6. Click the link for the application that you want to run.

   ---

   Tip –

   You can also launch an individual application directly and bypass the launch page by using the following syntax:

   https://hostname.domain:6789/app-context-name

   where app-context-name is the name that is used when the application is deployed.

   To find the application context name, you can do one of the following:

   • Read the application's documentation.

   • Run the wcadmin list -a or the smreg list -a command to see a list of deployed web applications and their context names.

   • Run the application from the web console's launch page and note the URL that is displayed in the address location field. You can type the URL directly the next time you use the application. Or, you can bookmark the location and access the application through the bookmark.

   ---

Managing the Console Service

Solaris 10 11/06: The Oracle Java Web Console service is managed through the Service Management Facility (SMF). You can start, stop, enable, and disable the console service by using SMF commands, or by using the smcwebserver script. The FMRI used in SMF for the console is system/webconsole:console.

How to Start the Console Service

This procedure starts the server temporarily. If the server was disabled from starting when the system boots, it will continue to be disabled. If the server was enabled, it will continue to be enabled.

Starting with the Solaris 10 11/06 release, the running enabled state displays as true (temporary), if the server is running while disabled.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Start the server now, without changing the enabled state.

   # smcwebserver start

How to Enable the Console Service to Run at System Start

This procedure enables the console service to run each time the system starts. The console is not started in the current session.

Starting with the Solaris 10 11/06 release, this procedure sets the general/enabled property to true in SMF, so that the server is started at the time the system boots.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Enable the server to be started at system boot.

   # smcwebserver enable

   Solaris 10 11/06: Alternatively, if you want to both start the server now, and enable the server to start when the system boots, use the command:

   # svcadm enable system/webconsole:console

   ---

   Note –

   If you are running the Solaris 10 11/06 release, you cannot enable the console by using the smcwebserver command. You must use the svcadm command.

   ---

How to Stop the Console Service

This procedure stops the server temporarily. If the server is disabled from starting when the system boots, it will continue to be disabled. If the server was enabled, it will continue to be enabled.

Starting with the Solaris 10 11/06 release, the running enabled state displays as false (temporary) if the server is stopped while enabled.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Stop the server now, without changing the enabled state.

   # smcwebserver stop

How to Disable the Console Service

When the console server is disabled, the server does not start when the system boots.

Starting with the Solaris 10 11/06 release, this procedure sets the console's general/enabled property to false in SMF, so that the console server does not start when the system boots.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Disable the server from starting when the system boots.

   # smcwebserver disable

   Solaris 10 11/06: Alternatively, if you want to both stop the server now, and disable the server from starting when the system boots, use the command:

   # svcadm disable system/webconsole:console

   ---

   Note –

   If you are running the Solaris 10 11/06 release, you cannot disable the console with the smcwebserver command. You must use the svcadm command.

   ---

Configuring the Oracle Java Web Console

The Oracle Java Web Console is preconfigured to run without administrator intervention. However, you might choose to change some of the web console's default behavior by overriding the console's configuration properties.

Starting with the Solaris 10 11/06 OS, you must use the wcadmin command to change these properties. Previously, the smreg command was used. For more information about the wcadmin command, see the wcadmin(1M) man page.

Properties in the console's configuration files control the behavior of the console. To change the behavior, you define new values for properties to override the default values. The default values of most properties should not be overridden unless there is a specific need that the default values do not provide, such as specifying your own login service.

In general, the property values that you might consider changing are the following:

• Console session timeout

  The web console's session timeout period is controlled by the session.timeout.value property. This property controls how long a web console page can be displayed without user interaction before the session times out. After the timeout is reached, the user must log in again. The default value is 15 minutes. You can set a new value, in minutes, to conform to your own security policy. However, keep in mind that this property controls the timeout period for all console users and all registered applications.

  See Example 3–1 for an example of how to change the session timeout.

• Logging level

  You use logging properties to configure the logging service. The console log files are created in the /var/log/webconsole/console directory. The logging.default.level property determines which messages are logged. The console logs provide valuable information for troubleshooting problems.

  The logging level applies to any messages that are written through the logging service, which by default uses syslog in the Oracle Solaris release The syslog log file is /var/adm/messages. The file /var/log/webconsole/console/console_debug_log contains log messages written when the debugging service is enabled. This is done by setting the debug.trace.level property as described in Using the Console Debug Trace Log. Although the default logging and debug logging services are separate, all Oracle Java Web Console logging messages to syslog are also written to the console_debug_log to aid in debugging. Generally, the logging service, set with logging.default.level, should be always enabled for logging by console applications. Debug logging, set with debug.trace.level, should only be enabled to investigate problems.

  The following property values are available for logging.default.level :

  • all

  • info

  • off

  • severe

  • warning

  See Example 3–2 for an example that shows how to change the logging level.

• Auditing implementation

  Auditing is the process of generating and logging security-related management events. An event signifies that a specific user has updated the management information on a system. The auditing implementation is used by services and applications that generate audit events.

  The following audit events are defined by the web console:

  • Login

  • Logout

  • Role assumption

  When audit events occur, a record of the event is made in an audit log. The location of the audit log varies with the auditing implementation that is in use. The web console's auditing service uses an auditing implementation that is provided by the underlying operating system.

  The web console supports three auditing implementations: Solaris, Log, and None. You can select an auditing implementation by specifying one of these keywords for the value of the audit.default.type configuration property. Only one auditing implementation is in effect at a time.

  The supported auditing implementation types are:

  • Solaris

    The Solaris implementation is the default. This implementation supports the BSM auditing mechanism. The auditing mechanism writes audit records into a system file in the /var/audit directory.

    You can display the records with the praudit command. For events to be captured, you must enable the BSM auditing mechanism on the system. In addition, the /etc/security/audit_control file must contain entries that indicate which events should be generated. You must set the lo event as the flag option to see login and logout events for each user. For more information, see the praudit(1M) and bsmconv(1M) man pages and Part VII, Oracle Solaris Auditing, in System Administration Guide: Security Services.

  • Log

    You can configure this implementation to write to the system's syslog service. Audit messages are written to the console log if the logging service has been enabled at the info level. See Example 3–2 for more information.

  • None

    No audit events are generated. Audit messages are written to the debug trace log, if enabled.

See Example 3–5 for an example of specifying the auditing implementation.

How to Change Oracle Java Web Console Properties

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Depending on which Oracle Solaris release you are running, change the selected property value as follows:

   • If you are running at least the Solaris 10 11/06 release, use this command:

     # wcadmin add -p -a console name=value

     -p

     Specifies that the object type is a property.

     -a console

     Specifies that the property changes are for the application named console. The -a console option must always be used when you are changing console properties.

     name=value

     Specifies the property name and the new value for that property.

   • For the Oracle Solaris 10, Solaris 10 1/06, and the Solaris 10 6/06 releases, use this command:

     # smreg add -p -c name

3. (Optional) Reset a console property to its default value.

   • If you are running at least the Solaris 10 11/06 release, use this command:

     # wcadmin remove -p -a console name=value

   • For the Oracle Solaris 10, Solaris 10 1/06, and the Solaris 10 6/06 releases, use this command:

     # smreg remove -p -c name

     -p

     Specifies that the object type is a property.

     -c

     Specifies that the property changes are for the console application. The -c option must always be used when you are changing console properties.

     name

     Specifies the property name and the new value for that property.

Example 3–1 Changing the Oracle Java Web Console's Session Timeout Property

This example shows how to set the session time out value to 5 minutes.

# wcadmin add -p -a console session.timeout.value=5

Example 3–2 Configuring the Oracle Java Web Console Logging Level

This example shows you how to set the logging level to all.

# wcadmin add -p -a console logging.default.level=all

Example 3–3 Resetting the Oracle Java Web Console Logging Level to the Default Value

This example shows how to reset the logging level to the default.

# wcadmin remove -p -a console logging.default.level

Example 3–4 Specifying a Java Version for the Oracle Java Web Console

This example shows how to set the Java version for the console.

# wcadmin add -p -a console java.home=/usr/java

Example 3–5 Choosing an Auditing Implementation for the Oracle Java Web Console

This example shows you how to set the auditing implementation to None.

# wcadmin add -p -a console audit.default.type=None

The valid auditing types are:

None

No auditing

Log

Audit messages to syslog

Solaris

Audit messages to BSM

Oracle Java Web Console User Identity

By default, the web console runs under the user identity, noaccess. However, some system configurations disable the noaccess user, or set the login shell for the noaccess user to an invalid entry to make this user identity unusable.

When the noaccess user is not usable, the web console server cannot be started or configured, so an alternative user identity must be specified. Ideally, the user identity should be changed only once, before the console server is configured at initial startup.

You can configure the web console to run under an alternative non-root user identity by using either of the following commands before the console starts:

# smcwebserver start -u username

This command starts the web console server under the specified user identity. The web console server runs under this identity each time the server is subsequently started if the command is issued before the first console start.

If you are running at least the Solaris 10 11/06 release, you can also use this command:

# wcadmin add -p -a console com.sun.web.console.user=
username

Starting with the Solaris 10 11/06 release, when the system initially starts, the console also starts and is automatically configured to run under noaccess. Consequently, the user identity is set to noaccess before you are able to change the user identity. Use the following commands to reset the console to its initial unconfigured state. Then, specify a different user identity when you restart the console.

# smcwebserver stop
# /usr/share/webconsole/private/bin/wcremove -i console
# smcwebserver start -u new_user_identity

For the Oracle Solaris 10, Solaris 10 1/06, Solaris 10 6/06 releases, use this command:

# smreg add -p -c com.sun.web.console.user=username

This command causes the web console server to run under the specified user identity the next time the server starts, and each time the server is started.

Using the Console Debug Trace Log

By default, the console does not log debug messages. You can turn on debug logging to help troubleshoot console service problems.

Use the debug.trace.level property to turn on debug logging by setting the property to a value other than 0.

Available choices include the following:

• 1 - Use this setting to record potentially severe errors.

• 2 - Use this setting to record important messages, as well as error messages of the 1 level.

• 3 - Use this setting to record all possible messages with full details.

By default, the debug trace log is created in the /var/log/webconsole directory for the Oracle Solaris 10, Solaris 10 1/06, and the Solaris 10 6/06 releases. Starting with the Solaris 10 11/06 release, the log is created in the /var/log/webconsole/console directory. The log file is named console_debug_log. Historical logs, such as console_debug_log.1 and console_debug_log.2 might also exist in this directory. There can be up to five (default setting) historical logs stored in this directory before the earliest log is deleted and a new log is created.

Example 3–6 Setting the Console Debug Trace Log Level

Use the following command to set the debug trace log level to 3.

For the Solaris 10 11/06 release, use this command:

# wcadmin add -p -a console debug.trace.level=3

For the Oracle Solaris 10, Solaris 10 1/06, and the Solaris 10 6/06 releases, use this command:

# smreg add -p -c debug.trace.level=3

Example 3–7 Checking the Status of the debug.trace.level Property

To check the status of the debug.trace.level property, use the wcadmin list or smreg list command.

Solaris 10 11/06:

# wcadmin list -p | grep "debug.trace.level"

For the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 releases, use this command:

# smreg list -p | grep "debug.trace.level"

Troubleshooting the Oracle Java Web Console Software (Task Map)

Troubleshooting the Oracle Java Web Console Software

The following information is provided to help you troubleshoot any problems that you might encounter when using the Oracle Java Web Console software.

Checking Console Status and Properties

You can use the smcwebserver, wcadmin, and svcs commands to get different types of information about the console, which might be useful for troubleshooting problems.

How to Check if the Console is Running and Enabled

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Check the server status.

   # smcwebserver status Sun Java(TM) Web Console is running

3. Solaris 10 11/06: Check the console's SMF status and enabled state.

   # svcs -l system/webconsole:console

   If you start and stop the server with smcwebserver commands without enabling and disabling, the enabled property might display as false (temporary) or true (temporary).

How to List Console Resources and Properties

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. List the console's resources and properties.

   If you are running at least the Solaris 10 11/06 release, use this command:

   # wcadmin list Deployed web applications (application name, context name, status): console ROOT [running] console com_sun_web_ui [running] console console [running] console manager [running] legacy myapp [running] Registered jar files (application name, identifier, path): console audit_jar /usr/lib/audit/Audit.jar console console_jars /usr/share/webconsole/lib/*.jar console jato_jar /usr/share/lib/jato/jato.jar console javahelp_jar /usr/jdk/packages/javax.help-2.0/lib/*.jar console shared_jars /usr/share/webconsole/private/container/shared/lib/*.jar Registered login modules (application name, service name, identifier): console ConsoleLogin userlogin console ConsoleLogin rolelogin Shared service properties (name, value): ENABLE yes java.home /usr/jdk/jdk1.5.0_06

   ---

   Note –

   This ENABLE property is ignored because SMF uses its own enabled property, which is shown in the previous procedure. The ENABLE property is used on older systems where the console server is not managed by SMF.

   ---

   For the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 releases, use this command:

   # smreg list The list of registered plugin applications: com.sun.web.console_2.2.4 /usr/share/webconsole/console com.sun.web.ui_2.2.4 /usr/share/webconsole/com_sun_web_ui com.sun.web.admin.example_2.2.4 /usr/share/webconsole/example The list of registered jar files: com_sun_management_services_api.jar scoped to ALL com_sun_management_services_impl.jar scoped to ALL com_sun_management_console_impl.jar scoped to ALL com_sun_management_cc.jar scoped to ALL com_sun_management_webcommon.jar scoped to ALL com_iplanet_jato_jato.jar scoped to ALL com_sun_management_solaris_impl.jar scoped to ALL com_sun_management_solaris_implx.jar scoped to ALL The list of registered login modules for service ConsoleLogin: com.sun.management.services.authentication.PamLoginModule optional use_first_pass="true" commandPath="/usr/lib/webconsole"; com.sun.management.services.authentication.RbacRoleLoginModule requisite force_role_check="true" commandPath="/usr/lib/webconsole"; The list of registered server configuration properties: session.timeout.value=15 authentication.login.cliservice=ConsoleLogin logging.default.handler=com.sun.management.services.logging.ConsoleSyslogHandler logging.default.level=info logging.default.resource=com.sun.management.services.logging.resources.Resources logging.default.filter=none logging.debug.level=off audit.default.type=None audit.None.class=com.sun.management.services.audit.LogAuditSession audit.Log.class=com.sun.management.services.audit.LogAuditSession audit.class.fail=none authorization.default.type=SolarisRbac authorization.SolarisRbac.class= com.sun.management.services.authorization.SolarisRbacAuthorizationService authorization.PrincipalType.class= com.sun.management.services.authorization.PrincipalTypeAuthorizationService debug.trace.level=0 . . . No environment properties have been registered.

Problems Accessing the Console

Problems with console access might indicate that the console server is not enabled, or security settings are restrictive. See Checking Console Status and Properties and Oracle Java Web Console Security Considerations for more information.

Problems with Application Registration

This section contains information about solving possible registration problems with console applications. For information about a particular console application, you should refer to the application's documentation.

Console applications typically are registered as part of their installation process, so you should not normally need to register an application yourself.

Starting with the Solaris 10 11/06 release, the web console has changed the approach to application registration but can still support applications that were developed for earlier versions of the console. Current applications are registered and deployed with a single command while the console server is running. Applications that were developed for the earlier console are known as legacy applications, and require the console server to be stopped during registration. If you need to register or unregister an application, you must first determine if the application is a legacy application, as described in the following procedure.

How to Determine if an Application is a Legacy Application

1. View the application's app.xml file.

   The app.xml file is located in the application's WEB-INF directory.

2. Examine the registrationInfo tag in the app.xml file.

   For a legacy application, the registrationInfo tag is a version 2.x. For example, registrationInfo version="2.2.4".

   For a current application, the version in the registrationInfo tag is at least 3.0. For example, registrationInfo version="3.0".

How to List Deployed Applications

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. List the deployed applications.

   If you are running at least the Solaris 10 11/06 release, use this command:

   # wcadmin list -a Deployed web applications (application name, context name, status): console ROOT [running] console com_sun_web_ui [running] console console [running] console manager [running] legacy myapp [running]

   The command lists all the registered and deployed applications. Legacy applications are listed with the application name legacy. See How to Determine if an Application is a Legacy Application. All other listed applications are current applications, and would be registered as described in How to Register a Current Application With the Oracle Java Web Console.

   Typically, the status that is shown for the applications contains either running or stopped. If the status is running, the application is currently loaded and available. If the status is stopped, then the application is not currently loaded and is unavailable. Sometimes an application registers and deploys successfully, but does not load because of a problem in the application. If so, the application's status is stopped. Check the console_debug_log to determine if there is an error with a traceback from the console's underlying web container, Tomcat, when attempting to load the application. For more information about the console_debug_log, see Using the Console Debug Trace Log.

   If all the applications show stopped (including the console application), this usually means the console's web container is not running. The list of applications in this case is obtained from the static context.xml files registered with the web container.

   For the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 releases, use this command:

   # smreg list -a The list of registered plugin applications: com.sun.web.console_2.2.4 /usr/share/webconsole/console com.sun.web.ui_2.2.4 /usr/share/webconsole/com_sun_web_ui com.sun.web.admin.yourapp_2.2.4 /usr/share/webconsole/yourapp

How to Register a Legacy Application With the Oracle Java Web Console

This procedure applies to all console applications in the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 releases. Starting with Solaris 10 11/06 release, this procedure also applies only to those applications that are identified as legacy applications. See How to Register a Current Application With the Oracle Java Web Console for the registration procedure for current applications. See also How to Determine if an Application is a Legacy Application.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Stop the web server.

   # smcwebserver stop

3. Register the application.

   # smreg add -a /directory/containing/application-files

   The smreg command manages the information in the Oracle Java Web Console's registration table. This script also performs some additional work to deploy the application. For additional options to this command, see the smreg(1M) man page.

4. Restart the web server.

   # smcwebserver start

Example 3–8 Registering a Legacy Application

This example shows how to register a legacy application whose files are located in the /usr/share/webconsole/example directory. Notice that for legacy applications, the console server must be stopped before the application is registered, and started after the application is registered. A warning given by smreg can be ignored because this application is a legacy console application.

# smcwebserver stop
# smreg add -a /usr/share/webconsole/example

    Warning: smreg is obsolete and is preserved only for
    compatibility with legacy console applications. Use wcadmin instead.

    Type "man wcadmin" or "wcadmin --help" for more information.

Registering com.sun.web.admin.example_version.

# smcwebserver start

How to Unregister a Legacy Application From the Oracle Java Web Console

This procedure applies to all console applications in the Oracle Solaris 10, Solaris 10 1/06, and Solaris 10 6/06 releases. Starting with Solaris 10 11/06 release, this procedure applies only to those applications that are identified as legacy applications. See How to Unregister a Current Application from the Oracle Java Web Console for the procedure that describes how to unregister current applications.

If you do not want a particular legacy application to display in the web console's launch page, but you do not want to uninstall the software, you can use the smreg command to unregister the application. See How to Determine if an Application is a Legacy Application.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Unregister an application.

   # smreg remove -a app-name

Example 3–9 Unregistering a Legacy Application From the Oracle Java Web Console

This example shows how to unregister a legacy application with the app-name com.sun.web.admin.example.

# smreg remove -a com.sun.web.admin.example

 Unregistering com.sun.web.admin.example_version.

How to Register a Current Application With the Oracle Java Web Console

Solaris 10 11/06: This procedure is for updated console applications that can be registered and deployed without stopping and starting the console server. See How to Register a Legacy Application With the Oracle Java Web Console for the registration procedure for legacy applications and all console applications that are in the Oracle Solaris 10, Solaris 10 1/06, Solaris 10 6/06 releases. See also How to Determine if an Application is a Legacy Application.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Register and deploy the application.

   wcadmin deploy -a app-name -x app-context-name /full path/to/app-name

Example 3–10 Registering Current Applications

This example shows how to register and deploy an application that has been developed or updated for the current web console.

# wcadmin deploy -a newexample_1.0 -x newexample /apps/webconsole/newexample

How to Unregister a Current Application from the Oracle Java Web Console

Solaris 10 11/06: This procedure is for updated console applications, which can be unregistered and undeployed without stopping and starting the console server. See How to Unregister a Legacy Application From the Oracle Java Web Console for the unregistration procedure for legacy applications and all console applications that are in the Oracle Solaris 10, Solaris 10 1/06, Solaris 10 6/06 releases. See How to List Deployed Applications and How to Determine if an Application is a Legacy Application to determine if an application is a legacy or updated application.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Undeploy and unregister the application.

   # wcadmin undeploy -a newexample_1.0 -x newexample

Oracle Java Web Console Reference Information

This reference section includes the following topics:

• Oracle Java Web Console Security Considerations

• Specifying Authorizations With the authTypes Tag

Oracle Java Web Console Security Considerations

There are several security considerations to keep in mind when you use applications that are in the Oracle Java Web Console.

These security considerations include the following:

• Access to the Oracle Java Web Console – Whether you can connect to the console through a browser.

• Access to applications – Whether you can see a particular application in the Oracle Java Web Console's launch page.

• Application permissions – The levels of permissions that you must have to run parts or all of an application.

• Application access to remote systems – How security credentials relate to remote systems.

• Internal passwords used in the console - Changing the default passwords that are used internally in the console, starting with the Solaris 10 11/06 release.

Access to the Oracle Java Web Console

Permissions to the web console launcher application are usually open so that any valid user can log in. However, you can restrict access to the console by specifying the rights in the authTypes tag in the web console's app.xml file, which is located in the /usr/share/webconsole/webapps/console/WEB-INF directory. For more information, see Specifying Authorizations With the authTypes Tag.

Some system configurations are set up to be very secure, so that attempts to connect from a remote system to the URLs of the console or registered applications are refused. If your system is configured to prevent remote access, when you try to access the console as https://hostname.domain:6789, your browser displays a message such as:

Connect to hostname.domain:6789 failed (Connection refused)

The SMF profile in effect on the system might be restricting access. See SMF Profiles for more information about profiles. See Enabling Remote Access to the Oracle Java Web Console for a procedure to allow access to the console from remote systems.

Access to Applications in the Oracle Java Web Console

After you successfully log in to the web console, you might not automatically have access to all of the applications that are registered in that console. Typically, applications are installed so that all users can see them in the console launch page. As an administrator, you can grant and restrict access to applications.

To restrict access to an application, specify the rights in the authTypes tag, which is in the application's app.xml file. You can find the application's app.xml file in the installation-location/WEB-INF/ subdirectory. Typically, this directory would be located in /usr/share/webconsole/webapps/ app-context-name/WEB-INF.

If the application files are not in the usual location, you can locate the files by using the following command:

wcadmin list --detail -a

This command lists each deployed application, showing when it was deployed and the path to the application's base directory. The app.xml file is located in the subdirectory WEB-INF within the base directory.

For more information, see Specifying Authorizations With the authTypes Tag.

Application Privileges

If you can see an application's link on the Oracle Java Web Console's launch page, you can run that application. However, an application might make additional authorization checks based upon the authenticated user or role identity. These checks are not controlled by the authTypes tag, but are explicitly coded into the application itself. For example, an application might grant read access to all authenticated users, but restrict update access to a few users or a few roles.

Application Access to Remote Systems

Having all the appropriate credentials does not guarantee that you can use an application to manage every system within the application's scope of operation. Each system that you administer by using the Oracle Java Web Console application has its own security domain. Having read-and-write permissions on the web console system does not guarantee that those credentials are automatically sufficient to administer any other remote system.

In general, access to remote systems depends on how the security is implemented in the web application. Typically, web applications make calls to agents that perform actions on behalf of the applications. These applications must be authenticated by the agents based on their web console credentials and the credentials by which they are known on the agent system. Depending upon how this agent authentication is done, an authorization check might also be made on the agent itself, based upon this authenticated identity.

For example, in web applications that use remote WBEM agents, authentication typically uses the user or role identity that initially authenticated to the Oracle Java Web Console. If this authentication fails on that agent system, access to that system is denied in the web application. If authentication succeeds on that agent system, access might still be denied if the agent makes an access control check and denies access there. Most applications are written so that the authentication and authorization checks on the agent never fail if you have been successfully authenticated on the web console and assumed the correct role.

Internal Passwords That Are Used in the Console

Starting with the Solaris 10 11/06 release, the Oracle Java Web Console uses several password-protected internal user names to perform administrative tasks on the underlying web server, and to encrypt key store and trust store files. The passwords are set to initial values to enable the console to be installed. To reduce the possibility of a security breach, you should change the passwords after installation. See Changing Internal Passwords for Oracle Java Web Console

Specifying Authorizations With the authTypes Tag

While most system management web applications do not require any administrator intervention to use the authTypes tag, in some cases, you might need to change the values of this tag. The authTypes tag contains a set of information that describes the level of authorization that is required for a user to view an application in the Oracle Java Web Console. The web console determines if a user is authorized to see a particular application, based on the authorization requirements in the application's app.xml file. Each application can determine whether a user must have proper authorization to run the application. This determination might be made as part of the application installation process. Or, you might need to supply the information, depending on your own security requirements. The product documentation for the application should contain the information that is necessary to determine whether you need to specify a particular permission.

You can nest several authType tags within the authTypes tag.

The authTypes tag must contain at least one authType tag that provides the following necessary information:

• Type of authorization check to perform

• Permission subclass name

• Parameters that are required to instantiate the Permission subclass

In the following example, the authType tag has one attribute, name. The required name attribute is the name of the authorization service type. Different authorization types might require different values for the classType and permissionParam tags.

<authTypes>
	<authType name="SolarisRbac">
	    <classType>
	      com.sun.management.solaris.RbacPermission
	    </classType>
	    <permissionParam name="permission">
	      solaris.admin.serialmgr.read
	    </permissionParam>
	</authType>
</authTypes>

The following table shows the tags that can be nested within an authType tag.

The authTypes tag and nested authType tags are required elements in the app.xml file. If you want to register an application that is available to anyone, specify the authType tag with no content, as shown in the following example.

<authTypes>
        <authType name="">
            <classType></classType>
            <permissionParam name=""></permissionParam>
        </authType>
</authTypes>

Enabling Remote Access to the Oracle Java Web Console

If you can only connect to the console by logging into the system that is running the console, and then using the URL, https://localhost:6789, the system is using a configuration that prevents remote access. Starting with the Solaris 10 11/06 release, you can enable remote access only to the console, while leaving the other access restrictions in place, by using the following procedure:

How to Enable Remote Access to the Oracle Java Web Console

1. Become superuser or assume an equivalent role on the system where the console is running.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Set a property to allow the console server to respond to network requests and restart the console server.

   # svccfg -s svc:/system/webconsole setprop options/tcp_listen = true # smcwebserver restart

Disabling Remote Access to the Oracle Java Web Console

You can prevent users from connecting to the console from remote systems. Starting with the Solaris 10 11/06 release, you can disable remote access only to the console, while leaving the other access permissions in place, by using the following procedure:

How to Disable Remote Access to the Oracle Java Web Console

1. Become superuser or assume an equivalent role on the system where the console is running.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Set a property to prevent the console server from responding to network requests, and restart the console server.

   # svccfg -s svc:/system/webconsole setprop options/tcp_listen = false # smcwebserver restart

   After the restart the console now only responds to a browser on the same system as the console server process. You cannot use a proxy in the browser, only a direct connection. You can also use the https://localhost:6789/ URL to access the console.

Changing Internal Passwords for Oracle Java Web Console

Starting with the Solaris 10 11/06 release, the console uses some internal user names and passwords. The console's internal user names and passwords are used only by the console framework, and are never used directly by a user or system administrator. However, if the passwords were known, a malicious user could potentially interfere with the console applications. To reduce the possibility of such a security breach, you should change the passwords. You do not need to remember the new passwords, because the software uses them invisibly.

How to Change the Console's Internal Passwords

The passwords are known as the administrative password, keystore password, and truststore password. You do not need to know the default initial values in order to change the passwords. This procedure explains how to change all three passwords with separate commands.

1. Become superuser or assume an equivalent role.

   Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.

2. Change the administrative password.

   # wcadmin password -a

   You are prompted to enter the new password twice. The password should be 8 to 32 characters.

3. Change the key store password.

   # wcadmin password -k

   You are prompted to enter the new password twice. The password should be 8 to 32 characters.

4. Change the trust store password.

   # wcadmin password -t

   You are prompted to enter the new password twice. The password should be 8 to 32 characters.