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.
Starting with the Solaris Express 5/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 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
Authorization
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 Solarisimplementation 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:
If you are running at least the Solaris Express 5/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.
If you are not running at least the Solaris Express 5/06 release, use this command:
# smreg add -p -c name=value
Reset a console property to its default value.
If you are running at least the Solaris Express 5/06 release, use this command:
# wcadmin remove -p -a console name
If you are not running at least the Solaris Express 5/06 release, 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=value
Specifies the property name and the new value for that property.
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
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. While the identity can be changed after configuration is completed,
the changes that then must be made to the console infrastructure are complex
and time consuming.
You can configure the web console to run under an alternative non-root user identity by using either of the following commands:
# smcwebserver -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 you are running at least the Solaris Express 5/06 release, use this command:
# wcadmin add -p -a console com.sun.web.console.user=username
If you are not running at least the Solaris Express 5/06 release, 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 and 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 Express 5/06 release, use this command:
# wcadmin add -p -a console debug.trace.level=3
If you are not running at least the Solaris Express 5/06 release, 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 Express 5/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"