This section describes the SGD datastore, how to monitor user activity, and how to configure logging.
This section includes the following topics:
The SGD servers in an array share information. Each SGD server knows:
What applications are configured and the applications servers on which they run
Which users have access to applications
Who is logged in to SGD
Which applications users are running
The collection of information is known as the datastore.
Information about users, applications, application servers, and webtops is stored on disk in the local repository. Information about user and application sessions is stored in memory.
The datastore is organized into namespaces which are displayed
and used on the command line and log files. The general
structure is
.../namespace/name-within-namespace
. The
...
indicates the root of the datastore. The
namespace indicates the source of the information, such as DNS.
After the namespace, names are written using whichever naming
scheme is appropriate to the namespace. Names are written like
file system paths (slash-separated and top-down).
The following are some commonly used namespaces.
Namespace | Description | Example |
---|---|---|
Local | SGD objects in the local repository |
|
LDAP | Objects in an LDAP directory |
|
DNS | Machines on the network |
|
This section describes the differences between user sessions and application sessions in SGD. Using the Administration Console and the command line to monitor and control user and application sessions is also covered.
This section includes the following topics:
A user session begins when a user logs in to SGD and ends when a user logs out of SGD. User sessions are hosted by the SGD server the user logs in to. The user name and password they type determine the type of user they are. See Chapter 2, User Authentication for more details about user authentication.
If a user logs in and they already have a user session, the user session is transferred to the new SGD server and the old session ends. This is sometimes called session moving, or session grabbing.
User sessions can be standard sessions or secure sessions. Secure sessions are only available when SGD security services are enabled. See Section 1.5, “Secure Connections to SGD Servers” for more details.
In the Administration Console, you can list user sessions as follows:
The Sessions tab, in Navigation View, shows all the user sessions that are running on all SGD servers in the array
The User Sessions tab for an SGD server shows all the user sessions that are hosted by that SGD server
The User Sessions tab for a user profile shows all the user sessions associated with the user profile
The Sessions tab and User Sessions tab enable you to select and end user sessions. The User Sessions tab enables you to view further details about the user session. For example, the information that the SGD Client detects about the client device.
On the command line, you use the tarantella webtopsession command to list and end user sessions.
You can configure an idle timeout period for inactive user sessions. User sessions are ended automatically if there has been no activity on the AIP connection between the SGD Client and the SGD server for the specified period. The timeout is disabled by default for an SGD array.
Activity on the following devices has no effect on the idle timeout period:
Serial ports
Smart cards
Audio
To specify the idle timeout attribute, go to the Global Settings → Communication tab of the Administration Console and type a value in the User Session Idle Timeout field.
Alternatively, use the following command:
$ tarantella config edit --webtop-session-idle-timeout secs
Replace secs
with the timeout
value, measured in seconds. A setting of 0 turns off the
user session idle timeout feature. This is the default
setting.
Do not configure an idle timeout that is less than 300 seconds (five minutes).
You must restart every SGD server in the array for changes to this attribute to take effect.
An application session begins when a user starts an application and ends when the application exits. Each application session corresponds to an application currently running through SGD.
An application session can be hosted by any SGD server in the array. This might not be the same SGD server that the user logged in to, see Section 7.1, “Arrays”.
Each application session has a corresponding Protocol Engine process. The Protocol Engine handles the communication between the client device and the application server. The Protocol Engine also converts the display protocol used by the application to the AIP, which is understood by the SGD Client running on the client device.
You can use application session load balancing to spread the load of the Protocol Engines among the SGD servers in the array. See Section 7.2.2, “Application Session Load Balancing” for more details.
Some applications can be configured to keep running, even when they are not displayed. These are called resumable applications.
Resumable applications are useful for the following reasons:
Applications that take a long time to start can be left running, even after users have logged out of SGD
Mobile users can leave applications running while they travel
Users can easily recover from browser or other crashes
Each application object has an Application Resumability attribute that determines the application's resumability behavior. Applications can have one of the following Application Resumability settings.
Setting | Description |
---|---|
Never | The application exits when the user logs out of SGD. You cannot suspend or resume applications that are non-resumable. |
During the User Session | The application continues to run until the user logs out of SGD. While they are logged in, the user can suspend and resume these applications. |
General | The application continues to run even after the user has logged out of SGD. When the user logs in again, they can click the Resume button to display the running application again. |
If an application is resumable, it is resumable for a period of time, specified by a timeout. If the SGD Client exits unexpectedly or the connection to the SGD server is lost, the timeout period is the configured timeout plus 20 minutes.
The 20 minute connection timeout enables the SGD server to reestablish the connection with the SGD Client. After this time period, the user session ends. To change the value of the connection timeout, use the following command:
# tarantella config edit --tarantella-config-array-restartconnectiontimeout mins
where mins
is the connection
timeout period, in minutes.
Table 7.1, “Application Resumability Scenarios” describes application resumability behavior for some typical scenarios.
Table 7.1. Application Resumability Scenarios
Scenario | Description |
---|---|
User logs out from SGD | The user session ends immediately. The application session behavior then depends on the Application Resumability setting for the application object as follows:
|
Connection to the SGD server is lost | SGD detects that the connection between the SGD Client and the SGD server is lost, and a timeout period of 20 minutes begins. If the connection is restored within 20 minutes, the application session can be resumed. After 20 minutes have expired, the user session ends. The application session behavior then depends on the Application Resumability setting for the application object as follows:
|
SGD Client exits unexpectedly | SGD detects that the SGD Client has exited unexpectedly, and a timeout period of 20 minutes begins. If the application has an Application Resumability setting of Never, the application session is ended immediately. Otherwise, the application session can be resumed within the 20 minutes timeout period. After 20 minutes have expired, the user session ends. The application session behavior then depends on the Application Resumability setting for the application object as follows:
|
In the Administration Console you can list application sessions as follows:
The Application Sessions tab for an SGD server shows all the application sessions that are hosted by that server
The Application Sessions tab for a user profile shows all the application sessions associated with the user profile
The Application Sessions tab for an application server shows all the applications that are running on that application server
The Applications Sessions tab enables you to view details about each application session. You can also end and shadow application sessions. Shadowing a session enables you and the user see and interact with the application at the same time.
See Section 4.9.9, “Using Shadowing to Troubleshoot a User's Problem” for more details about shadowing application sessions.
You can only shadow Windows applications and X applications. The application sessions must not be suspended.
On the command line, you use the tarantella emulatorsession command to list and end user sessions.
There are two special cases, as follows:
Anonymous users. These are users that log in without typing a user name and password. See Section 2.3, “Anonymous User Authentication”.
Shared users. Also called guest users. These are users that log in with the same user name and password. See Section 2.9.5, “Using Shared Accounts for Guest Users”.
To be able to distinguish between these users, SGD assigns shared users and anonymous users a temporary user identity when they log in. This has the following effects:
User sessions do not transfer if the user logs in to SGD more than once
Application sessions end as soon as the user session ends, regardless of the application's Application Resumability setting
If the user does not log out, server resources are consumed
When you first install SGD, the default log filters log all errors on the SGD server. If you want to obtain more detailed information, for example to troubleshoot a problem, you can set additional log filters.
You can set additional log filters in the following ways:
Type the filter in the Log Filter field on the Global Settings → Monitoring tab in the Administration Console. Each filter must be separated by a Return key press.
Use the following command:
$ tarantella config edit --array-logfilter filter
...
Separate multiple filter
entries
with a space and enclose in double quotation marks
("
"
).
Each log filter has the form:
component/subcomponent/severity:destination
The options for each part of the filter, and how you view the log output, are described in the following sections.
Log filters can create large amounts of data. It is good practice to set as specific a filter as possible and then remove the filter when you have finished with it.
Selecting a component and subcomponent enables you to choose the area of information you want to log from the SGD server.
The following table shows the available component/subcomponent combinations and an explanation of the kind of information produced.
Component and Subcomponent | Information Provided |
---|---|
| Audit of changes made to the SGD server configuration, or to your local repository configuration, and who made the changes. For example, you can use this to find out who made changes to a user profile object. |
| Starting and stopping user sessions and application sessions. For example, you can use this to find out how long a user had a running application session. |
| Authorization of SGD user for client drive mapping (CDM) purposes. For example, you can use this to find out whether a user's credentials are causing CDM to fail. |
| Information about CDM services. For example, you can use this to find out whether a client connection error is causing CDM to fail. |
| How SGD server configuration is stored and copied across the array. For example, you can use this to find out why a global setting configuration change is not being applied to an SGD server. |
| Memory and timings. For example, you can use this to find out how long it took to run an SGD command. |
| The SOAP component of Tomcat's SOAP proxy. For example, you can use this to trace how long it took a SOAP request to finish. |
| SGD billing services. For example, you can use this to find out why billing data is being lost. |
| General SGD information. For example, you can use this to troubleshoot DNS errors. |
| Changes to SGD server configuration. For example, you can use this to log changes to SGD server configuration or to find out if the configuration has become corrupt. |
| The SGD client session handler. For example, you can use this to find out why a user can not restart an application session. |
| Mapping of users to accessible device data. For example, you can use this to find out why a user can not access client drives. |
| Connections to Active Directory or LDAP. For example, you can use this to find out why an Active Directory or LDAP user cannot log in. |
| Information about the local repository. For example, you can use this to get information about corrupt objects or inconsistencies in the local repository. |
| Information about array failover. For example, you can use this to troubleshoot problems with an SGD array where the primary server is unavailable. |
| The protocol used for communication between SGD servers. For example, you can use this to find out why SGD servers cannot communicate. |
| Installation and upgrades. For example, you can use this to investigate problems with an installation. |
| Windows Kerberos authentication. For example, you can use this to find out why an Active Directory user cannot log in. |
| Starting or resuming applications. For example, you can use this to find out why a user cannot start an application. |
| User session and application load balancing. For example, you can use this to find out why an SGD server is not selected to host application sessions. |
| Logging. For example, you can use this to find out why log messages are not being written to a file. |
| Log in to SGD. For example, you can use this to find out which authentication mechanism authenticated a user and the user profile used. |
| The SGD MUltiplePlexing Protocol (MUPP) protocol. Only use this filter if Support ask you to. |
| SGD printing services. For example, you can use this to find out why print jobs are failing. |
| Copying data between SGD servers in an array. For example, you can use this to find out why data has not been copied between array members. |
| Connections to SecurID RSA Authentication Manager. For example, you can use this to find out why SecurID authentication is not working. |
| Secure SSL-based connections. For example, you can use this to find out why the SSL Daemon is not running. |
| The SGD server component. For example, you can use this to troubleshoot SGD server failures, such as Java™ technology runtime exceptions which are not logged elsewhere. |
| Internal SGD server services. For example, you can use this to find out why a service is failing. |
| User sessions. For example, you can use this to find out why a session failed to suspend. |
| SOAP bean interface. For example, you can use this to diagnose problems with the SOAP beans. |
| SOAP requests. For example, you can use this to log the SOAP requests received. |
| Application server load balancing. For example, you can use this to find out why an application server is not being selected to run an application. |
| Windows Remote Desktop Services Client Access Licenses (CALs) for non-Windows clients. For example, you can use this to find out why a non-Windows client does not have a CAL. |
| Webtop content, if you are using Directory Services Integration. For example, you can use this to find out why an application is not appearing on a user's webtop. |
You can select one of the following levels of severity for each log filter.
Severity | Description |
---|---|
| Logs information on fatal errors. Fatal errors stop the SGD server from running. When you first install SGD, all fatal errors are logged by default. |
| Log information on any errors that occur. When you first install SGD, all errors are logged by default. |
| Log information on any warnings that occur, for example if system resources are running low. When you first install SGD, all warnings are logged by default. |
| Informational logging. Useful for problem solving and identifying bugs. |
| Verbose informational logging. |
| Logs selected events for auditing purposes, for example changes to SGD server configuration. For details see, Section 7.4.4, “Using Log Filters for Auditing”. |
The fatalerror
severity level produces the
least amount of information. The moreinfo
severity level produces the most information.
Selecting a severity level is not cumulative. For example,
selecting info
does not mean you also see
warningerror
or
fatalerror
log messages.
To log more than one level of severity, use a wild card.
You can use a wildcard (*) to match multiple components, subcomponents, and severities.
For example, to log all warning, error, and fatal error
messages for printing, you can use a
server/printing/*error
log filter.
If you use a wildcard on the command line, you must enclose the filter in straight quotation marks, to stop your shell from expanding them.
When selecting a destination for the logs, you can specify that the output goes to one of the following destinations:
A log file
A log handler
These destinations are described in the following sections.
If you direct the output to a log file, you can output to the following types of file:
filename
.log
SGD formats this log output so that it is easy to read.
This format is required by the tarantella query
errlog command. This command only searches log
files that have names that end
error.log
.
filename
.jsl
SGD formats this log output for automated parsing and searching.
This format is required by the tarantella query audit command.
The file extension of the destination file controls the format of the file.
You can also create a separate log file for each process ID,
by including the %%PID%%
placeholder in
the file name.
The log files are output in the
/opt/tarantella/var/log
directory. You
cannot change the location of the log files, but you can use
a symbolic link to redirect the logs to a different
location. Alternatively, you can use the
syslog
log handler described in
Section 7.4.3.3.2, “Using Log Handlers”.
A log handler is a JavaBeans component used as the destination for the log messages. When specifying a log handler, you must use its full name. SGD provides the following log handlers:
ConsoleSink. The ConsoleSink log handler writes log messages in a easy-to-read format to standard error. This log handler is enabled by default and logs all fatal errors.
The full name of this log handler is:
.../_beans/com.sco.tta.server.log.ConsoleSink
SyslogSink. The
SyslogSink log handler writes log messages to the UNIX
or Linux platform syslog
facility.
The full name of this log handler is:
.../_beans/com.sco.tta.server.log.SyslogSink
The following are some examples of commonly used log filters:
To debug user logins:
server/login/*:login%%PID%%.log server/login/*:login%%PID%%.jsl
To troubleshoot CDM:
cdm/*/*:cdm%%PID%%.log cdm/*/*:cdm%%PID%%.jsl server/deviceservice/*:cdm%%PID%%.log server/deviceservice/*:cdm%%PID%%.jsl
To troubleshoot printing problems:
server/printing/*:print%%PID%%.log server/printing/*:print%%PID%%.jsl
To get timing measurements for server performance:
metrics/*/*info:metrics.log metrics/*/*info:metrics.jsl
To send all warnings, errors, and fatal errors to syslog:
*/*/*error:.../_beans/com.sco.tta.server.log.SyslogSink
To view the log output, you can do either of the following:
Open the .log
files in a viewer or text
editor
Use the tarantella query command
If you use the tarantella query command, use the following command options:
tarantella query errlog – To see only the errors and fatal errors for specific SGD server components
tarantella query audit – Searches the logs for any messages relating to a person, an application, or an application server
You can only use these commands to view the log output until the logs are archived. You configure archiving when you install SGD, but you can change the settings at any time by running the tarantella setup command.
SGD enables you to set log filters to provide an audit of the following system events:
Starting and stopping an SGD server
Starting and stopping SGD security services
Changes to object configuration in the local repository
Changes to global and SGD server configuration
Unsuccessful attempts to log in to an SGD server
Logging in and out of SGD
Starting and stopping an application session
To audit these events, you must set a
*/*/*auditinfo
log filter.
You can use any of the standard destinations as a destination
for the output, but you must direct the output to a
.jsl
file if you want to view the audit
information from the command line.
See Section 7.4.3, “Using Log Filters to Troubleshoot Problems With an SGD Server” for more information about setting log filters.
Log output is only created while an SGD server is actually running. If an SGD server is stopped, only the UNIX system root user can perform any of the auditable events.
For each of the events, the log filter records following:
The date and time of the event
The type of event
The result of the event, whether it was successful or it failed
The identity of the user responsible for the event
Any other relevant information about the event, for example what was changed and to what value
You can use any of the standard methods for viewing the log output. However, the following command is the most useful:
# tarantella query audit --format text|csv|xml --filter "filter
"
If you select the text
format,
SGD formats the log output so that it is easy to
read on screen, but it does not show every detail logged.
Using the csv
format shows every detail
logged, but it is only suitable for outputting to a file.
The "filter
" is an
RFC2254-compliant
LDAP search filter. The command searches the log fields in the
log files for matching entries to display. For auditing
purposes, the most useful log fields are shown in the
following table.
Log Field | Description |
---|---|
|
For auditing purposes, the log-category is always
|
| The system date and time when the event took place.
The format is |
| The name of the event. |
| The IP address of a client or server associated with an event. |
| The keyword identifier for the auditable event. |
| The peer DNS name of the SGD server where the event took place. |
| The process ID of the event. |
|
The type of security used on a connection,
|
| The system Coordinated Universal Time (UTC) time, in milliseconds, when the event took place. |
| The full name of an object associated with an event. For example, starting an application session might record the name of the user, the application, and the application server. |
A complete list of all the log fields is available in the
/opt/tarantella/var/serverresources/schema/log.at.conf
schema file.
The following table below shows all the log-keywords, and their corresponding log-events, together with a description of the event.
Log-Keyword | Log-Event | Description |
---|---|---|
|
| A user tried to create an object in the local repository but failed. |
|
| A user created an object in the local repository. |
|
| A user tried to delete an object in the local repository but failed. |
|
| A user deleted an object in the local repository. |
|
| The SGD server requested the client to reconnect on a different port. |
|
| None of the enabled authentication mechanisms authenticated the user. |
|
| User was denied a login by a login filter. For example, this might be because logins are currently not enabled for that particular server, or because the user is currently not allowed to log in. |
|
| The SGD server is not currently accepting connections. |
|
| An ambiguous login failed because the SGD server does not support ambiguous logins. |
|
| An ambiguous login failed because the user did give enough disambiguation information. |
|
| An anonymous login failed because the SGD server does not support anonymous logins. |
|
| Login failed because the user requires a secure connection, but the connection was made to the standard port. |
|
| Login failed because the SGD server was unable to resolve which user had logged in. |
|
| Login failed because the SGD server was unable to process an unexpected login result. |
|
| Started a user session for a user. |
|
| Stopped a user session for a user. |
|
| A user tried to change an object in the local repository, to change global settings, or to change the configuration of an SGD server but failed. |
|
| A user changed an object in the local repository, changed global settings, or changed the configuration of an SGD server. |
|
| A user tried to rename an object in the local repository but failed. |
|
| A user renamed an object in the local repository. |
|
| The SGD server was started. |
|
| The SGD server was stopped. |
|
| Stopped an application session for a user. |
|
| Started application session for a user. |
|
| Started SGD security (SSL) services. |
|
| Stopped SGD security (SSL) services. |
To search for failed log in attempts, use the following filter:
--filter "(&(log-category=*auditinfo)(log-keyword=loginFailure))"
To search for changes to made to the SGD server configuration by the Administrator Bill Orange, use the following filter:
--filter "(&(log-category=*auditinfo)(log-keyword=modifySuccess) (log-tfn-name=.../ens/o=Example/ou=IT/cn=Bill Orange))"
When you first install SGD, the default log filters record all errors for protocol engines (PEs). To obtain more information about PE activity, you can set additional PE log filters.
PE log filters can be set for individual PEs, and for the Protocol Engine Manager (PE Manager) process. You configure a PE log filter by setting one of the attributes shown in the following table.
PE Filter Attribute | Protocol Engine |
---|---|
| PE Manager |
| Execution Protocol Engine |
| X Protocol Engine |
| Character Protocol Engine |
| Print Protocol Engine |
| Channel Protocol Engine |
You can only set a PE log filter from the command line. Use the following command:
$ tarantella config edit--PE-filter-attribute
filter...
where PE-filter-attribute
defines the
PE filter attribute you want to configure, and
filter
defines the log filter. For
multiple log filter definitions, use straight quotation marks to
separate each filter parameter.
Each log filter has the form:
component/subcomponent/severity
The following table shows the available component names for PE logging.
Protocol Engine | Component |
---|---|
PE Manager |
|
Execution Protocol Engine |
|
X Protocol Engine |
|
Character Protocol Engine |
|
Print Protocol Engine |
|
Channel Protocol Engine |
|
For subcomponent, type *
to include
information on all subcomponents.
You can select the following levels of severity:
*
– Includes all error and warning
messages.
*info
– Includes
info
, moreinfo
, and
auditinfo
messages.
*error
– Includes
error
, fatalerror
, and
warningerror
messages. This is the
default severity.
Changes to the Execution, X, Character, Print, and Channel PE log filters take effect when a new PE is started.
Changes to the PE Manager log filters require an SGD server restart.
Log filters can create large amounts of data. It is good practice to set as specific a filter as possible and then remove the filter after you have finished with it. See Section 7.4.5.4, “Resetting a PE Log Filter” for details of how to do this.
The following are some examples of how to use a PE log filter.
To troubleshoot CDM for X and Windows applications:
--tarantella-config-xpeconfig-logfilter "xpe/cdm/*"
To troubleshoot problems with X and Windows applications:
--tarantella-config-xpeconfig-logfilter "xpe/*/*" "pem/*/*"
To troubleshoot application launches, you must first enable debugging in the SGD login scripts, as shown in Section 4.9.1, “An Application Does Not Start”. Then, configure the Execution Protocol Engine log filter as follows:
--tarantella-config-execpeconfig-logfilter "execpe/*/*"
For the execpe
, xpe
,
tpe
, ppe
, and
cpe
log filters, using the
pem/*
filter shows relevant PE Manager
messages for the Protocol Engine.
PE log files have the file name extension
.log
. SGD formats this type
of log output so that it is easy to read.
PE log file names include the name of the PE component and the
process ID. For example, messages for a PE Manager running
with process ID 4512 are stored to a file named
pemanager4512.log
.
Error messages with a severity of error
,
fatalerror
, or
warningerror
are stored to a PE log file
with a name that ends error.log
. For
example, error messages for a Character Protocol Engine
running with process ID 2256 are stored to a file named
cpe2256_error.log
. Files such as this are
used by the tarantella query errlog
command, which only searches log files that have names that
end error.log
.
PE log filter output is directed automatically to log files in
the /opt/tarantella/var/log
directory on
the SGD host. You cannot change the location of
the log files, but you can use a symbolic link to redirect the
logs to a different location.
To view the PE logs, do either of the following:
Open the .log
files in a viewer or
text editor.
On each SGD server in the array, the
.log
files contain messages for PEs
running on that specific SGD server.
Use the tarantella query errorlog command to show error messages for PEs.
This command can be used to search all PE error logs in the array.
For example, to display X Protocol Engine error messages for all SGD servers in the array, use the following command:
$ tarantella query errlog xpe
For example, to display X Protocol Engine error messages for the SGD server boston.example.com, use the following command:
$ tarantella query errlog xpe --server boston.example.com
You can only use these commands to view the log output until the logs are archived. You configure archiving when you install SGD, but you can change the settings at any time by running the tarantella setup command.
As log filters can create large amounts of data, it is good practice to reset the filter to its default configuration after you have finished with it.
The default PE log filter configuration sets a severity level
of *error
for all subcomponents of the PE
component. The following table shows the default configuration
for each log filter.
Protocol Engine | Default Log Filter Configuration |
---|---|
PE Manager |
|
Execution Protocol Engine |
|
X Protocol Engine |
|
Character Protocol Engine |
|
Print Protocol Engine |
|
Channel Protocol Engine |
|
For example, to reset an X Protocol Engine log filter use the following command:
$ tarantella config edit \ --tarantella-config-xpeconfig-logfilter "xpe/*/*error" "pem/*/*error"
SGD web server messages are recorded in the following logs:
Tomcat JSP technology container logs
Apache web server logs
Log messages for the Tomcat JSP technology container component
of the SGD web server are written to the
following files in the
/opt/tarantella/webserver/tomcat/
directory on the SGD host:
tomcat-version
/logs
catalina.out
– This log file is
rotated when full, or when the Tomcat JSP technology
container is restarted, and the contents are appended to
catalina.out.sav
.
localhost_log.
– This is a daily log file, where
date
.txtdate
is the date that messages
were recorded.
You can read these log files with a text editor.
The Tomcat JSP technology container log files can be used to diagnose problems with the following:
Starting and stopping the Tomcat JSP technology container
Starting the AJP 1.3 Connector
Loading the SGD webtop web application
Webtop JSP software exception errors
Logging properties for the Tomcat JSP technology container are
configured in the
/opt/tarantella/webserver/tomcat/
file. See the
Tomcat
documentation for details of how to configure logging
for a Tomcat JSP technology container.
tomcat-version
/conf/logging.properties
Log messages for the Apache web server component of the
SGD web server are written to the following files
in the
/opt/tarantella/webserver/apache/
directory on the SGD host:
apache-version
/logs
errors_log
– Logs error
messages for the Apache web server
access_log
– Logs all access
requests processed by the Apache web server
You can read these log files with a text editor.
The Apache web server log files can be used to diagnose problems with the following:
Starting and stopping the Apache web server
Client requests for SGD webtop pages
Web authentication
See the Apache documentation for more details about these log files.
By default, log messages for the SGD Client are stored to the following locations on the client device:
Microsoft Windows client
devices. A file called
tcc.txt
in a user-specific writeable
directory.
On Microsoft Windows XP platforms, for example:
C:\Documents and
Settings\
username
\Local
Settings\Application Data\Sun\SSGD
On Microsoft Windows 7 platforms, for example:
C:\Users\
username
\AppData\Local\Temp\Sun\SSGD
The actual location depends on the user's privileges, the operating system, and the version of the Java Plug-in software being used.
Users can view the contents of the
tcc.txt
file with a text editor.
UNIX, Linux, or Mac OS X platform client devices. The system log location for the client device.
On Oracle Linux platforms, for example:
/var/log/messages
On Oracle Solaris platforms, for example:
/var/adm/messages
On Mac OS X platforms, for example:
/var/log/system.log
The system log on the user's client device might be in a different location from those listed. On some client platforms, users might need privileges to view the system log.
Users can override the default log directory by using the
-logdir
command line
argument when the SGD Client is started manually.
In this case, a tcc.txt
file is created in
the specified directory location.
The default log directory is used if the
-logdir
argument is not
specified when starting the SGD Client manually.
The SGD Client log file can be used to diagnose problems with the following:
Starting the SGD Client and the SGD Client Helper
Loading the SGD webtop page
Client devices, such as CDM, printing, and smart card services
Connections between the SGD Client and the SGD server
Users configure the logging level for SGD Client messages by changing the Logging Level setting in their client profile. The available logging levels, arranged in increasing level of verbosity, are:
No Logging – Turns off SGD Client logging.
Errors only – Records error messages. This is the default setting.
Errors and Warnings only – Records error messages and warning messages.
All – Records all messages, including error messages, warning messages, and information messages.
Client device information is shown on the Info → Detailed Diagnostics page of the user's webtop.
Administrators can use the Administration Console to view client device information for a user session. Select the user session in the User Session List table and click the View Details button to show more details.