Configuring the Java Web Console
The 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 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 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, 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 Java Web Console Properties
- 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.
- Depending on which Solaris release you are running, change the selected property value
as follows:
- (Optional) Reset a console property to its default value.
Example 3-1 Changing the 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 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 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 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 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
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
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
If you are not running at least the Solaris Express 5/06 release, use
this command:
For the 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
. 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 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"
If you are not running at least the Solaris Express 5/06 release, use
this command:
# smreg list -p | grep "debug.trace.level"
