Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Basic Administration Oracle Solaris 10 1/13 Information Library |
1. Oracle Solaris Management Tools (Road Map)
2. Working With the Solaris Management Console (Tasks)
3. Working With the Oracle Java Web Console (Tasks)
What's New in Administering the Oracle Java Web Console?
Oracle Java Web Console Server Management
Applications That Are Available to the Oracle Java Web Console
Oracle Java Web Console (Overview)
What Is the Oracle Java Web Console?
Oracle Java Web Console Management Commands
Getting Started With the Oracle Java Web Console (Task Map)
Getting Started With the Oracle Java Web Console
How to Start Applications From the Oracle Java Web Console's Launch Page
How to Start the Console Service
How to Enable the Console Service to Run at System Start
How to Stop the Console Service
How to Disable the Console Service
Configuring the Oracle Java Web Console
How to Change Oracle Java Web Console Properties
Troubleshooting the Oracle Java Web Console Software (Task Map)
Troubleshooting the Oracle Java Web Console Software
Checking Console Status and Properties
How to Check if the Console is Running and Enabled
How to List Console Resources and Properties
Problems Accessing the Console
Problems with Application Registration
How to Determine if an Application is a Legacy Application
How to List Deployed Applications
How to Register a Legacy Application With the Oracle Java Web Console
How to Unregister a Legacy Application From the Oracle Java Web Console
How to Register a Current Application With the Oracle Java Web Console
How to Unregister a Current Application from the Oracle Java Web Console
Oracle Java Web Console Reference Information
Oracle Java Web Console Security Considerations
Access to the Oracle Java Web Console
Access to Applications in the Oracle Java Web Console
Application Access to Remote Systems
Internal Passwords That Are Used in the Console
Specifying Authorizations With the authTypes Tag
Enabling Remote Access to the Oracle Java Web Console
How to Enable Remote Access to the Oracle Java Web Console
Disabling Remote Access to the Oracle Java Web Console
How to Disable Remote Access to the Oracle Java Web Console
Changing Internal Passwords for Oracle Java Web Console
How to Change the Console's Internal Passwords
4. Managing User Accounts and Groups (Overview)
5. Managing User Accounts and Groups (Tasks)
6. Managing Client-Server Support (Overview)
7. Managing Diskless Clients (Tasks)
8. Introduction to Shutting Down and Booting a System
9. Shutting Down and Booting a System (Overview)
10. Shutting Down a System (Tasks)
11. Modifying Oracle Solaris Boot Behavior (Tasks)
12. Booting an Oracle Solaris System (Tasks)
13. Managing the Oracle Solaris Boot Archives (Tasks)
14. Troubleshooting Booting an Oracle Solaris System (Tasks)
15. x86: GRUB Based Booting (Reference)
16. x86: Booting a System That Does Not Implement GRUB (Tasks)
17. Working With Oracle Configuration Manager
18. Managing Services (Overview)
20. Managing Software (Overview)
21. Managing Software With Oracle Solaris System Administration Tools (Tasks)
22. Managing Software by Using Oracle Solaris Package Commands (Tasks)
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.
Note - 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, Auditing in Oracle Solaris, 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.
Roles contain authorizations and privileged commands. For more information about roles, see Configuring RBAC (Task Map) in System Administration Guide: Security Services.
# wcadmin add -p -a console name=value
Specifies that the object type is a property.
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.
Specifies the property name and the new value for that property.
# smreg add -p -c name
# wcadmin remove -p -a console name=value
# smreg remove -p -c name
Specifies that the object type is a property.
Specifies that the property changes are for the console application. The -c option must always be used when you are changing console properties.
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:
No auditing
Audit messages to syslog
Audit messages to BSM
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
Note - 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.
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"