This section contains information about the web server that is included with SGD and the SGD Administration Console..
This section includes the following topics:
When you install SGD, the SGD web server is also installed. The SGD web server is preconfigured for use with SGD. The components included with the SGD web server are listed in the Oracle Secure Global Desktop Platform Support and Release Notes for Release 4.7 available at http://www.oracle.com/technetwork/documentation/sgd-193668.html.
If you have an existing web server on the SGD host, this is not affected by the SGD web server, as the SGD web server listens on a different port.
You can configure the SGD web server using standard Apache directives. See the Apache documentation for details.
You can control the SGD web server independently of the SGD server, using the tarantella start webserver, tarantella stop webserver, and tarantella restart webserver commands.
By default, the SGD web server is configured to be a secure HTTPS web server and to share the SGD server SSL certificate used for SGD security services.
Directory indexes are disabled by default for the SGD web server. This means that users cannot browse the directories on the SGD web server.
If you require enhanced security, a more secure version of the
httpd.conf
Apache configuration file used
by the SGD web server is supplied. See
Section 7.3.2.1, “The httpd.conf.secure File” for more details about
this file.
The httpd.conf.secure
file is an Apache
server configuration file that configures the SGD
web server for enhanced security. The file is included with
the SGD distribution, at
/opt/tarantella/webserver/apache/
on the SGD host.
apache-version
/conf/httpd.conf.secure
The httpd.conf.secure
file provides the
following additional security features, compared to the
standard httpd.conf
file used by the
SGD web server:
Apache modules that are not used by SGD are disabled
Access to the /cgi-bin
directory on
the SGD web server is not allowed
To use httpd.conf.secure
on an
SGD server that has previously been secured, you
must first disable security on the SGD server,
before installing the httpd.conf.secure
file. You can then enable security services for the
SGD server, as described in
Section 1.5, “Secure Connections to SGD Servers”.
Do not use httpd.conf.secure
if you
have used the tarantella security enable
command to configure security automatically on the
SGD server.
This section describes how to run the Administration Console. It also includes details of how to avoid some common problems when using the Administration Console.
To display the Administration Console, you can use a supported browser. The browser must have the JavaScript programming language enabled. The supported browsers are listed in the Oracle Secure Global Desktop Platform Support and Release Notes for Release 4.7 available at http://www.oracle.com/technetwork/documentation/sgd-193668.html.
When using the Administration Console, do not use the browser's Back button. Instead, use the Jump to Object View and Jump to Navigation View links, or the Object History list, to navigate through the Administration Console pages.
The Administration Console works best when you run it on the primary SGD server in the array.
You can start the Administration Console in the following ways:
Click the Administration Console link on the webtop of an SGD Administrator.
Click the Launch the Oracle Secure Global Desktop Administration
Console link on the SGD web server Welcome
Page at
https://
,
where server.example.com
server.example.com
is the
name of an SGD server.
Go to the
https://
URL.
server.example.com
/sgdadmin
The Administration Console is for SGD Administrators only. To use the Administration Console you must log in as, or be logged in as, an SGD Administrator.
The Administration Console is only supported when used with the SGD web server.
The Administration Console ships with a web application
archive (WAR) file, sgdadmin.war
. Using
this file to redeploy the Administration Console on another
web application server is not supported.
You can perform operations on the SGD datastore, such as creating new objects and editing object attributes, using the Administration Console from any SGD server in the array.
When you edit the SGD datastore, the changes you make are sent to the primary SGD server. The primary SGD server then replicates these changes to all secondary servers in the array.
By running the Administration Console from the primary SGD server, you can avoid problems due to the following:
Slow network. If the network is slow, “Object not found” or “Object not created” errors can be returned. Also, problems with stale data can occur, where configuration changes are not shown correctly.
Primary down. If the primary server is down, or unavailable, SGD datastore changes are not applied.
The following limitations apply when using the Administration Console to perform array operations, such as array joining or array detaching:
Use the primary SGD server. Running the Administration Console on the primary server avoids data replication problems. See also Section 7.3.3.4, “Avoiding SGD Datastore Update Problems”.
All servers involved in an array operation must be up. For example, you cannot use the Administration Console to detach a secondary server that is down. Instead, use the tarantella array detach command.
Clocks must be synchronized on all servers involved in an array operation. For example, you cannot add a secondary server if its clock is out of synchronization by more than a minute. You can use NTP software or the rdate command to ensure the clocks on all SGD hosts are synchronized.
The deployment descriptor for the Administration Console web application contains settings that control the operation of the Administration Console. The deployment descriptor is the following file:
/opt/tarantella/webserver/tomcat/tomcat-version
/sgdadmin/WEB-INF/web.xml
This section describes the settings in the deployment descriptor
that you might want to configure. Most of the settings are
context parameters, contained in
<context-param>
elements. You must not
change any other settings in the web.xml
file.
When working with deployment descriptor settings, note the following:
Only change web.xml
if you understand
what you are doing.
Always create and keep a backup of the original
web.xml
, in case you need to revert to
a previous version. See
Section 7.6.2, “Backing Up and Restoring an SGD Installation” for advice
on how to do this.
After changing web.xml
, you must always
restart the SGD web server for the changes to
take effect.
Changes to web.xml
only apply for the
server that is hosting the Administration Console.
You must not change the order of the Extensible Markup
Language (XML) elements contained in
web.xml
.
The com.sun.tta.confmgr.DisplayLimit
context parameter enables you to configure the maximum number
of search results you can display in the Administration
Console. The default is 150
. If there are
more results than the display limit, the Administration
Console displays a message. Increasing the display limit can
have an effect on performance. Set the display limit to
0
to see unlimited search results.
The com.sun.tta.confmgr.ArraySyncPeriod
context parameter is only used if you are running the
Administration Console from a secondary server, and you create
or edit objects in the SGD datastore. This
parameter enables you to configure the period of time, in
milliseconds, that the Administration Console waits for
changes to be copied across the array before proceeding. The
default value is 250. The Administration Console waits for
twice this setting, a default of 0.5 seconds, before
proceeding.
By default, SGD uses a query class of ANY for DNS lookups. Some firewall configurations might block this class of DNS lookups. This can lead to problems, for example when configuring Active Directory authentication using the Administration Console.
To configure the Administration Console to use a query class
of IN for all DNS lookups, set the
sgd.naming.dns.in_class_only
context
parameter to true
.
The com.sun.tta.confmgr.LdapSearchTimeLimit
context parameter enables you to configure the maximum time,
in milliseconds, to allow for a search of a Lightweight
Directory Access Protocol (LDAP) directory. The default is
0
, which means the search time is
unlimited. Only change this context parameter if you have
particularly slow LDAP directory servers.
The following context parameters are used to filter the display of LDAP data, when you select Local + LDAP in the Repository list in the Administration Console:
Filters used by the navigation tree. These are the following context parameters:
com.sun.tta.confmgr.LdapContainerFilter
com.sun.tta.confmgr.LdapUserFilter
com.sun.tta.confmgr.LdapGroupFilter
Filters used when you search an LDAP directory. These are the following context parameters:
com.sun.tta.confmgr.LdapContainerSearchFilter
com.sun.tta.confmgr.LdapUserSearchFilter
com.sun.tta.confmgr.LdapGroupSearchFilter
Filters used when you load the LDAP assignments on the
Assigned Applications tab for a user profile. This is the
com.sun.tta.confmgr.LdapMemberFilter
context parameter.
These context parameters contain the definitions of what the Administration Console considers as LDAP containers, users, and groups. You might want to change these filters to improve performance, or to change the definition of these LDAP object types to match those used in your LDAP directory.
For example, if your LDAP directory uses the
computer
object class edit the
com.sun.tta.confmgr.LdapUserFilter
context
parameter to remove the
(!(objectclass=computer))
entry.
To avoid inconsistencies, if you change a filter for the navigation tree, you might also need to change the filter used for the LDAP search.
The session-timeout
setting defines the
period of time after which the user is logged out if there is
no activity, meaning no HTTP requests, in the Administration
Console. The default setting is 30 minutes, to ensure
unattended Administration Console sessions are not left open
indefinitely.
The session-timeout
setting is
independent of the timeout attribute for inactive user
sessions,
tarantella-config-array-webtopsessionidletimeout
.
Because the Administration Console is a web application, you can
control which client devices are allowed to access it.For
example, you can do this by configuring the SGD web
server to use the Apache <Location>
directive, as in the following example:
<Location /sgdadmin> Order Deny,Allow Deny from all Allow from 129.156.4.240 </Location>
In this example, only client devices with an IP address of
129.156.4.240
are allowed to access the
/sgdadmin
directory on the SGD
web server. The /sgdadmin
directory
contains the home page of the Administration Console.
For more information on how to configure the
<Location>
directive, check the
Apache
documentation.