2. System Requirements and Support
SGD Server Requirements and Support
Supported Installation Platforms for SGD
Operating System Modifications
Red Hat Enterprise Linux and Oracle Enterprise Linux
Retirements to Supported SGD Installation Platforms
Supported Authentication Mechanisms
Client Device Requirements and Support
Retirements to Supported Client Platforms
SGD Gateway Requirements and Support
Supported Installation Platforms for the SGD Gateway
Retirements to Supported Gateway Installation Platforms
SGD Server Requirements for the SGD Gateway
Supported Cipher Suites for SSL Connections
Application Requirements and Support
Supported Installation Platforms for the SGD Enhancement Module
Retirements to Supported Installation Platforms for the SGD Enhancement Module
Microsoft Windows Terminal Services
This section contains the following topics:
Use the following hardware requirements as a guide and not as an exact sizing tool. For detailed help with hardware requirements, contact an Oracle sales office.
The requirements for a server hosting SGD can be calculated based on the total of the following:
What is needed to install and run SGD
What is needed for each user that logs in to SGD on the host and runs applications
The following are the requirements for installing and running SGD:
2 gigabytes of free disk space
2 gigabyte of random-access memory (RAM)
1 gigahertz processor
Network interface card (NIC)
This is in addition to what is required for the operating system itself and assumes the server is used only for SGD.
The following are the requirements to support users who log in to SGD and run applications:
Minimum 50 megabytes for each user
50 megahertz for each user
![]() | Caution - The actual central processing unit (CPU) and memory requirements can vary significantly, depending on the applications used. |
The following table lists the supported installation platforms for SGD.
|
You might have to make some operating system modifications. Without these modifications, SGD might not install properly or operate correctly.
The libXm.so.3 library is required to support 5250 and 3270 applications. This library is available in the OpenMotif 2.2 package.
You must install at least the End User Solaris OS distribution to get the libraries required by SGD. If you do not, SGD does not install.
The TCP Fusion feature of Solaris 10 OS can cause problems with some local socket connections used by SGD. Disable the TCP Fusion feature before you install SGD, as follows:
Add the following line at the bottom of the /etc/system file.
set ip:do_tcp_fusion = 0x0Reboot the server.
The default /etc/hosts file for Red Hat Enterprise Linux and Oracle Enterprise Linux contains a single entry, which incorrectly maps the host name of the SGD host to the local loopback address, 127.0.0.1.
Edit the /etc/hosts file to remove this mapping, and add a new entry that maps the name of the SGD host to the network Internet Protocol (IP) address of the SGD host. The SGD host name must not be mapped to the local loopback IP address.
The supported installation platforms for SGD are supported on a Type 1 (bare metal) hypervisor or a Type 2 (hosted) hypervisor, for example Oracle VM VirtualBox, VMWare, or Oracle VM Server for SPARC (previously called Sun Logical Domains or LDoms).
Installation in zones is supported for Solaris 10 OS. SGD can be installed either in the global zone, or in one or more non-global zones. Installation in both the global zone and a non-global zone is not supported.
On Solaris 10 OS Trusted Extensions platforms, you must install SGD in a labeled zone. Do not install SGD in the global zone.
The following table shows the SGD installation platforms that have been retired.
|
The following table shows the JDK versions included with SGD.
|
To install SGD, you must have superuser (root) privileges.
The system must have ttaserv and ttasys users and a ttaserv group before you can install SGD.
The ttasys user owns all the files and processes used by the SGD server. The ttaserv user owns all the files and processes used by the SGD web server.
The SGD server does not require superuser (root) privileges to run. The SGD server starts as the root user and then downgrades to the ttasys user.
If you try to install the software without these users and group in place, the installation program stops without making any changes to the system and displays a message telling you what you need to do. The message includes details of an install script that you can run to create the required users and group.
If you need to create the required users and group manually, the following are the requirements:
The user names must be ttaserv and ttasys.
The group name must be ttaserv.
You can use any user identification number (UID) or group ID (GID) you want. The UID and GID can be different.
Both users must have ttaserv as their primary group.
Both users must have a valid shell, for example /bin/sh.
Both users must have a writable home directory.
For security, lock these accounts, for example with the passwd -l command.
One way to create these users is with the useradd and groupadd commands, for example:
# groupadd ttaserv # useradd -g ttaserv -s /bin/sh -d /home/ttasys -m ttasys # useradd -g ttaserv -s /bin/sh -d /home/ttaserv -m ttaserv # passwd -l ttasys # passwd -l ttaserv
To check whether the ttasys and ttaserv user accounts are correctly set up on your system, use the following commands.
# su ttasys -c "/usr/bin/id -a" # su ttaserv -c "/usr/bin/id -a"
If your system is set up correctly, the command output should be similar to the following examples.
uid=1002(ttaserv) gid=1000(ttaserv) groups=1000(ttaserv) uid=1003(ttasys) gid=1000(ttaserv) groups=1000(ttaserv)
You must configure your network for use with SGD. The following are the main requirements:
Hosts must have Domain Name System (DNS) entries that can be resolved by all clients.
DNS lookups and reverse lookups for a host must always succeed.
All client devices must use DNS.
When you install SGD, you are asked for the DNS name to use for the SGD server. The DNS name must meet the following requirements:
In a network containing a firewall, use the DNS name that the SGD host is known as inside the firewall.
Always use fully-qualified DNS names for the SGD host. For example, boston.example.com.
The Oracle Secure Global Desktop 4.6 Administration Guide has detailed information about all the ports used by SGD and how to use SGD with firewalls. The following information lists the common ports used.
Client devices must be able to make Transmission Control Protocol/Internet Protocol (TCP/IP) connections to SGD on the following TCP ports:
80 - For Hypertext Transfer Protocol (HTTP) connections between client devices and the SGD web server. The port number can vary depending on the port selected on installation.
443 - For HTTP over Secure Sockets Layer (HTTPS) connections between client devices and the SGD web server.
3144 - For standard (unencrypted) connections between the SGD Client and the SGD server.
5307 - For secure connections between the SGD Client and the SGD server. Secure connections use Secure Sockets Layer (SSL).
Note - The initial connection between an SGD Client and an SGD server is always secure. After the user logs in to SGD, the connection is downgraded to a standard connection. When you first install SGD, TCP ports 3144 and 5307 must be open to connect to SGD. You can configure SGD to always use secure connections.
To run applications, SGD must be able to make TCP/IP connections to application servers. The types of applications determine the TCP ports that must be open, for example:
22 – For X and character applications using Secure Shell (SSH)
23 – For Windows, X, and character applications using Telnet
3389 – For Windows applications using Windows Terminal Services
6010 and above – For X applications
In SGD, an array is a collection of SGD servers that share configuration information. As the SGD servers in an array share information about user sessions and application sessions, it is important to synchronize the clocks on the SGD hosts. Use Network Time Protocol (NTP) software or the rdate command to ensure the clocks on all SGD hosts are synchronized.
The SGD web server consists of an Apache web server and a Tomcat JavaServer Pages (JSP) technology container preconfigured for use with SGD.
The SGD web server consists of the following components.
|
The Apache web server includes all the standard Apache modules as shared objects.
The minimum Java Virtual Machine (JVM) software heap size for the Tomcat JSP technology container is 256 megabytes.
The following are the supported mechanisms for authenticating users to SGD:
Lightweight Directory Access Protocol (LDAP) version 3
Microsoft Active Directory
Network Information Service (NIS)
Microsoft Windows Domains
RSA SecurID
Web server authentication (HTTP/HTTPS Basic Authentication), including public key infrastructure (PKI) client certificates
Active Directory authentication and LDAP authentication are supported on the following versions of Active Directory:
Windows Server 2003
Windows Server 2003 R2
Windows Server 2008
Windows Server 2008 R2
SGD supports version 3 of the standard LDAP protocol. You can use LDAP authentication with any LDAP version 3-compliant directory server. However, SGD only supports the following directory servers:
Oracle Directory Server Enterprise Edition version 6.3.1 and 7.0 (formerly Sun Java Directory Server Enterprise Edition)
Microsoft Active Directory on Windows Server 2003, 2003 R2, 2008, and 2008 R2
Novell eDirectory version 8.8
Other directory servers might work, but are not supported.
SGD works with versions 4, 5, 6, and 7 of RSA Authentication Manager (formerly known as ACE/Server).
SGD supports system-generated PINs and user-created PINs.
SGD supports TLS version 1.0 and SSL version 3.0.
SGD supports Privacy Enhanced Mail (PEM) Base 64-encoded X.509 certificates. These certificates have the following structure:
-----BEGIN CERTIFICATE-----...certificate...-----END CERTIFICATE-----SGD supports the Subject Alternative Name (subjectAltName) extension for SSL certificates. SGD also supports the use of the * wildcard for the first part of the domain name, for example *.example.com.
SGD includes support for a number of Certificate Authorities (CAs). The /opt/tarantella/etc/data/cacerts.txt file contains the X.500 Distinguished Names (DNs) and MD5 signatures of all the CA certificates that SGD supports. Additional configuration is required to support SSL certificates signed by an unsupported CA. Intermediate CAs are supported, but additional configuration might be required if any of the certificates in the chain are signed by an unsupported CA.
SGD supports the use of external hardware SSL accelerators, with additional configuration.
SGD supports the following cipher suites:
RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_RC4_128_SHA
RSA_WITH_RC4_128_MD5
RSA_WITH_DES_CBC_SHA
SGD supports two types of printing: PDF printing and Printer-Direct printing.
For PDF printing, SGD uses Ghostscript to convert print jobs into Portable Document Format (PDF) files. At least version 6.52 of Ghostscript must be installed on the SGD host. Your Ghostscript distribution must include the ps2pdf program. For best results, install the latest version of Ghostscript.
SGD supports Printer-Direct printing to PostScript, Printer Command Language (PCL), and text-only printers attached to the user’s client device. The SGD tta_print_converter script performs any conversion needed to format print jobs correctly for the client printer. The tta_print_converter script uses Ghostscript to convert from Postscript to PCL. To support this conversion, Ghostscript must be installed on the SGD server. For best results, download and install the additional fonts.
Ghostscript is not included with the SGD software.