SSGD, external/peer dns names and IP-addresses

When looking at the documentation and the configuration of Sun Secure Global Desktop it can be confusing to see several references to DNS names and sometimes IP-addresses. I hope this post will bring some light on which is which and help to understand when to use which name or IP-address.

The following picture shows the naming of the different Network Interfaces. The "External" refers to the connection between the client and the SGD server and the "Peer" to the connection between the SGD server and the other SGD server within the SGD Array.


First the DNS names. There are two important DNS-entries, the Peer DNS Name and the External DNS Name. These can be the same in a simple installation, but mostly they will be different.

• Peer DNS Name
  

  "A Peer DNS Name is the DNS name that the Secure Global Desktop servers in the array use to identify themselves and each other."

  
  This is the main DNS entry of the SGD server and specified during installation. This DNS-entry is also used during the communication with other SSGD servers in a SSGD Array. (Both forward and reverse DNS-entries should be available on all SSGD Servers in the SSGD Array). The Peer DNS name can not be changed after installation.
  
  
• External DNS Name
  

  "An external DNS name is the DNS name that the client devices use."

  
  The External DNS name is used at the client, therefor the client must be able to resolve the external DNS name. This is also the name for the SSL certificate (when using secure connections). The External DNS name is not used at the SSGD server or within the SSGD Array.
  
  The external DNS name can be changed via the Array Manager or via the command:
  

  /opt/tarantella/bin/tarantella config edit \
    --server-dns-external "*:<external dns name>"

  
  

Besides the Peer DNS name and External DNS name there are also the Peer Bind IP-Address and the External Bind-IP-Address. After installing the Sun Secure Global Desktop the Peer Bind IP-Address and the External Bind-IP-Address is set to all available IP-Addresses ("*") of the system. For complex installations it is advisable to change this to the IP-addresses of the different Network Interfaces.

• Peer Bind IP-Address
  This IP-address is the IP-address of the Secure Global Desktop server. When the Peer DNS Name is resolved it should resolve to this IP-address and visa versa. It is possible to bind the SSGD software to multiple IP-addresses, one of these addresses should resolve to the Peer DNS Name. Use the following command to change the Peer Bind IP-Address:
  

  /opt/tarantella/bin/tarantella config edit \
    --tarantella-config-server-bindaddresses-peer \
    <Peer Bind-IP-Address>

  
  
  
  
• External Bind-IP-Address
  The SGD software will listen on this IP-address(es) for the client connections. This IP-address can be different from the IP-address after resolving the external-dns-name, since there might be a Load Balancer or SSL-offloader between the client and the SGD server. To change the External Bind-IP-Address use the following command:
  

  /opt/tarantella/bin/tarantella config edit \
    --tarantella-config-server-bindaddresses-external 
    <External Bind-IP-Address>

  
  

When using the SGD Server in Firewall Forwarding Mode a good practice is to change the External Bind-IP-Addresses with the following command:

/opt/tarantella/bin/tarantella config edit \
  --tarantella-config-server-bindaddresses-external 
  "!127.0.0.1"

The SGD Web erver tries to bind to port 443 (the array-portencrypted) on localhost as well. Excluding this 127.0.0.1:443 for the SGD server changes the dependency of the web server being started before the SGD server.

I hope this enlightens the different DNS names and IP-Addresses a bit, if not let me know :)

Sun released SGD 4.4 Documentation.

SUN has released the documentation of the new Sun Secure Global Desktop 4.4.

Besides some small neat new features (like 'Automatic Timeout of Idle User Sessions' and 'Support for Solaris 10 OS Trusted Extensions') the biggest change will be the Administration Console. Up till version 4.3 management of SSGD is done with the Object Manager and the Array Manager. Version 4.4 has the new Web based Console.

The SGD Administration Console is now a single point of administration and is dynamic. For instance, when logging in to the SGD Administration Console you can directly see which servers are up and running and how many webtop and application sessions are running on each server.

More on the new SSGD version in later posts. Look at the release notes of SGD 4.4 if you can't wait :)

The new documentation be found here.

Sun Ray and SSGD locations

The Thin Guy started a user map using Frappr! This is a nice way to see who is using Sun Ray or Sun Secure Global Desktop or both :)

http://www.frappr.com/sunraysgd

Add yourself and see both products are being used from New Zealand till Hawaii :)

Organize objects with Groups

Configuring Sun Secure Global Desktop Applications in small environments (like at home) is very simple. It is easy to see which application is linked to which user and will run at which host.

When the amount of applications, host and/or users grow it can become quite a mess and rather unmanageable. For example adding an extra application server to run the same applications as an other application server (for load balancing purposes) the new application server needs to be added to all the applications.

Fortunately SSGD has Group objects. Group objects can be used to group all different types of SSGD objects (hosts, applications, application servers, profiles and groups). The SSGD groups can be seen as a container to put the objects in and it does not look at the type. It is possible to create a group with different types objects. However to keep everything easy try add only objects of the same type to the group and add the object type to the group name (like WinTermServGrp, FinanceApps or HelpdeskUsers).

Looking at the example above and the knowledge of having groups the example can be made easier to manage and keep everything well organized.

1. First create a group (ie: AppServGrp)
2. Add the 'old' application server to the group
3. Replace the link from all the applications to the 'old' application server with the group (AppServGrp)

If you want to add a new application server to all same the applications running on the 'old' application server the only step to take is:

1. Add the 'new' application server to the group (AppServGrp)

Because it is possible to group different types of objects a lot of possibilities are available to organize the objects well ordered, manageable and very easy :)

Don't forget to use the Organizational Units (OU) to organize the Objects as well.