Monday Oct 15, 2007

Free SGD licenses for partners

A little known fact is that Partners of Sun that want to set up their own SGD server for demonstrations or internal use, can request free NFR (Not for Resale) license keys to do so.

If this is you, contact your local Sun partner manager to get a license key


Wednesday Sep 19, 2007

SGD Portlet released into the wild

For those portal types amongst you that would like your portal to be able to offer applications as well as information, you might be interested in the newly released SGD Portlet.

This is a JSR-168 Portlet that was developed by the SGD and Sun Portal Server team.

We've made available the war file and the source code too.



Sunday Aug 19, 2007

There can be only one (port in a firewall)

In the last blog we explored how to make the connections secure, which is essential if you want to use SGD in a secure, remote environment where users are outside and apps are inside the corporate network boundary. But an equally important pre-requisite is to work "nicely" with firewalls.

Many organizations have a policy which allows ports 80 and 443 (http/https) to remain open. So can SGD operate over these ports or do we need to spend weeks with the Security guys convincing them to open up other ports?

The answer is that SGD can work entirely over a single port and this blog explains how.

SGD, or a component thereof, is made to sit on the external 443 port as shown in this diagram

Thru a magical technique, SGD can discover if the traffic arriving on the port is AIP or https traffic, without needing to decrypt the traffic, and is then able to forward the stream to the web server or the SGD server as it deems fit. In this way only one port needs to be opened in the firewall.

Here's how to set up SGD in this way:

  1. Set up the webserver to listen on localhost:443
  2. You'll need to edit the webserver configuration file /opt/tarantella/webserver/apache/\*/conf/httpd.conf and change the port it listens on from:
    Listen 443

  3. Set up SGD to listen on external-dns:443
  4. # /opt/tarantella/bin/tarantella config edit --array-port-encrypted 443
  5. Tell SGD where to send non-AIP traffic
  6. # /opt/tarantella/bin/tarantella config edit --security-firewallurl 
  7. Finally, restart the web server and the SGD server
  8. # /opt/tarantella/bin/tarantella webserver restart --ssl 
    # /opt/tarantella/bin/tarantella restart

And now you're only using one port. Voila!


Saturday Aug 18, 2007

Securing the connections between the client and SGD server

When you initially install SGD (at least all versions up to the time of writing which is 4.31) the SGD webserver listens on port 80 and the SGD server listens on port 3144. And the traffic between the client and the SGD server, both http and AIP is unencrypted.

So how do we secure the communications between client and server?

  1. First we need an X.509 certificate
  2. Normally you have to go can buy an X.509 certificate from people like Verisign. Being tight, Fat Bloke uses a little known feature of SGD, which is a "self-signed certificate". This certificate is useless in a production environment as it certifies nothing, but it is free :-) . To get a self-signed certificate you create a CSR (certificate signing request) as usual:
    # /opt/tarantella/bin/tarantella security certrequest --country US --state CA --orgname "Acme Widgets Ltd"
    ...and follow the instructions. But instead of sending this request off to Verisign, keep your money in your pocket and type:
    # /opt/tarantella/bin/tarantella security selfsign 
    ignore the warnings and move on...

  3. Start the SGD server in secure mode
  4. The self signed certificate has automatically been placed in the /opt/tarantella/var/tsp directory and is used by SGD when you start it up using secure connections:
    # /opt/tarantella/bin/tarantella security start 
    So now we have secure AIP connections on port 5307. But what about the web server connections?

  5. Start the web server in secure mode
  6. The webserver that is bundled with SGD (apache) has a preconfigured httpd.conf file that looks for certificates in the same place that SGD uses to store certificates. So all we need to do is start the webserver with ssl enabled:
    # /opt/tarantella/bin/tarantella webserver restart --ssl

So now our web traffic and AIP traffic are using ssl on ports 443 and 5307 respectively.

In the next blog, we'll see how we can refine this deployment to work wholly over 443.


Friday Jul 06, 2007

Command line configuration of the array

Just as the command line equivalents of Object Manager are ...

/opt/tarantella/bin/tarantella object ...
... the command line equivalent of the Array Manager is the family of ...
/opt/tarantella/bin/tarantella config ...
commands which control the configuration of the SGD server itself.

One of the most common things FB does after a clean install of an SGD server, is to configure the array to use LDAP authentication against the corporate directory. And with the command line, this is as simple as these 2 commands:

/opt/tarantella/bin/tarantella config edit --login-ldap-url "ldap://,dc=sun,dc=com"
/opt/tarantella/bin/tarantella config edit --login-ldap 1

The first command informs SGD of which Directory Service to use, and the second simply enables the LDAP login authority. Simple eh? Some may say that FB could be replaced by a script one day :-)


Command line interrogation of the array

Once you have created some objects and the array is in production, as an administrator, you may want to know some stuff, such as "who's logged in to SGD?", or "who is running what applications", etc, so I find these 2 commands very useful:

  1. Who is logged on? -
    /opt/tarantella/bin/tarantella webtopsession list 
  2. Who is doing what? -
    /opt/tarantella/bin/tarantella emulatorsession list 
Wonder at the richness of the output :-) or pipe it thru your favorite stream editor (sed | grep | wc | awk) to find what you really want.


Thursday Jul 05, 2007

Command line manipulation of objects

Up to version 4.31 SGD has had 2 GUI sysadmin tools:

  1. Object Manager - configuration of apps, servers and users;
  2. Array Manager - configuration of the SGD software itself.

In this blog we'll look at Object Manager equivalent command lines, and in later blogs we'll cover the Array Manager equivalents.

Manipulation of objects is all via the /opt/tarantella/bin/tarantella object command. There are 2 types of objects:leaf objects and container objects; and objects can be created, deleted, edited and listed.

As a simple example here's how you can browse the SGD datastore: A default datastore starts off with a root container called "o=organization" and you can list the contents of containers using the list_contents command.

/opt/tarantella/bin/tarantella object list_contents --name "o=organization"

Doing this you get output like this:

cn=konsole (servername)
cn=xclock (servername)

And then you can examine the leaf objects, so:

/opt/tarantella/bin/tarantella object list_attributes --name "o=organization/cn=xclock (servername)"
Attributes for .../_ens/o=organization/cn=xclock (servername):
Name: "xclock (servername)"
app: /usr/bin/X11/xclock
appserv: "o=organization/cn=Tarantella server servername"
args: "-bw 1 geometry 198x198+0+0"
clipboardlevel: 3

You can change the object's attributes from the command line too. For example, let's make the clock bigger...

/opt/tarantella/bin/tarantella object edit --name "o=organization/cn=xclock (servername)" --width 1000 --height 1000 --args "-bw 1 -geometry 1000x1000+0+0"

Notice how we changed 3 attribute values at once here.

Finally for now, the more observant amongst you may realize that when you run a command line, SGD starts up a jvm instance. And so running a script of multiple command lines may take some time as jvm's start up and close down. So we recommend in this instance that you use the

/opt/tarantella/bin/tarantella object script"

Fat Bloke uses this command in this simple script to provision his servers after install.


Wednesday Jun 27, 2007

Simple Server tasks from the command line

OK so let's start with some simple command line stuff:

What is the status of the server?/opt/tarantella/bin/tarantella status
Start/Stop the SGD server/opt/tarantella/bin/tarantella start
/opt/tarantella/bin/tarantella stop
Start/Stop the SGD webserver (Apache/Tomcat)/opt/tarantella/bin/tarantella webserver start
/opt/tarantella/bin/tarantella webserver stop
Which version are we running?/opt/tarantella/bin/tarantella version

We'll move on to some meat in the coming posts.

Tuesday Jun 26, 2007

Real men use the command line

There are some nifty and good-looking admin tools out there for software products nowadays. But many sysadmins prefer the raw, unadulterated power of the good old command line interface.

The SGD command line interface is a powerful tool and it all begins with the "tarantella" command located under <install_dir>/bin.
The way it works is that there is a hierarchy of commands available from this top-level command.
At each level you can append "--help" to get a usage of the command at that level.

e.g. The top level command is:

[root@servername ~]# /opt/tarantella/bin/tarantella

Usage: tarantella <command> [<command-specific args>]

  Available commands:

  archive            Archives the server's log files
  array              Creates and manages arrays of Secure Global Desktop servers
  config             Edits array-wide and server-specific configuration
  emulatorsession    Lists and controls emulator sessions
  help               Displays this list of commands
  license            Adds, lists and removes Secure Global Desktop license keys
  object             Manipulates objects in the datastore
  passcache          Manipulates the password cache
  print              Controls Secure Global Desktop printing services
  query              Examines the server's log files
  restart            Restarts Secure Global Desktop services
  role               Configures role occupants and their extra webtop links
  security           Controls security services, manages certificates
  setup              Changes Setup options, restores original objects
  start              Starts Secure Global Desktop services
  status             Shows the current status of Secure Global Desktop array members
  stop               Stops Secure Global Desktop services
  tokencache         Manipulates the token cache
  tscal              Lists, frees and returns Terminal Services CALs
  uninstall          Uninstalls Secure Global Desktop from this host
  version            Displays versions of installed Secure Global Desktop packages
  webserver          Controls the Secure Global Desktop Web Server
  webtopsession      Lists and controls webtop sessions

  Use "tarantella  --help" to get help on a command.

Over the next few blog entries, Fat Bloke will share how he, as a real man, uses the SGD command line.

Friday May 11, 2007

4.31 is released!

A new updated release of SGD is now available!
Version 4.31 contains bug fixes and these new features:
- Support for UNIX audio apps
- Support for Vista as a server (think VDI)
- Support for Ubuntu as a client OS
- Changes to work better with ssh launches (should work out of box without needing ssh_config changes)
- The Mac OS X client is now a universal binary (native Power and Intel exe's)


Cleanly uninstalling SGD

Just a quick tip on uninstalling and cleaning up an SGD server...
To uninstall SGD you can use the native packaging mechanisms
Solaris - pkgrm tta
Linux - rpm -e tta

or you can use:

/opt/tarantella/bin/tarantella uninstall

This leaves configuration data behind which may be useful if you spent time configuring lots of objects.
But if you want a really clean uninstall use:

/opt/tarantella/bin/tarantella uninstall --purge

Also don't forget to remove any Enhancement Modules that you may have installed either on the application servers or the SGD server if you used that as an app server too.
pkgrm tem
rpm -e tem

And finally, to remove all trace, you may want to get rid of the ttaserv, ttasys users and group.


Wednesday Apr 18, 2007

Speeding up LDAP authentication

Lots of people use SGD with Directory Servers and it's easy to setup.
In the Array Manager simply enable the LDAP login authority and point SGD at the Directory Server.
Here's an example:

Now out of the box the LDAP login authority is very thorough in checking the supplied username against all of these searchAttributes:
{ cn, uid, mail, userPrincipalName, sAMAccountName }

And so for large directories this may take some time and lead to a slow login process.

So here's a tip:
Trim the list of search attributes down to say { cn, mail }.
The command to do this is:

/opt/tarantella/bin/tarantella config edit cn mail

Hopefully you'll see that this makes searches much faster and consequently the login process too.


Tuesday Apr 17, 2007

Using a Domain Name when caching credentials for UNIX application servers

Here's a tip which makes life easier for users logging in to multiple UNIX backends...

Imagine you have a large number of UNIX or Linux application servers.
And you use the same credentials to login to all of them. (e.g. they may be using a central LDAP server,or NIS+)

Normally, when you launch an app on one of these servers and SGD doesn't have a cached set of credentials, the user is prompted for a username/password. In this scenario, where there are a lot of servers, this can become tedious for the user.

So here are 2 suggestions:

1. If you use the same credentials on the SGD server and on the UNIX app servers you can enable the "Try SGD password". This is enabled in the Array Manager thus:

2. If the SGD server uses different credentials from all the 3rd tier UNIX app servers, label the app server objects as being in the same domain. You do this by setting the inappropriately named "Windows NT Domain" attribute on all your app servers, to the same thing, e.g. "DatacenterServers"

Now the credentials are cached against the domain rather than a single app server.
So when your users launch a UNIX app now, on any other UNIX server in the same domain, they won't get prompted.


Monday Apr 16, 2007

#1 - Best thing about SGD 4.3 is Performance

The Fat Bloke doesn't believe all he reads. So when he read that the 4.3 release reportedly is both faster and uses less bandwidth, he decided to test for himself the performance of SGD 4.3 against the previous release SGD 4.2. Here's what he found...

First here's FB's Test Bench:

And here's what was done:
In the setup above the WinBench Business Graphics benchmark was run on the Windows server against:
- SGD 4.2 on Linux (RHEL4) and Solaris 10 x64
- SGD 4.3 on Linux (RHEL4) and Solaris 10 x64

We measured
- the Benchmark score;
- the bytes transferred between the SGD client and server during each run
- the elapsed time to complete the full test.

And the scores were:

LinuxBytes Transferred12755965944532642
WinBench Score108216
Elapsed Time106 secs51 secs
Solaris x86Bytes Transferred12607832444970456
WinBench Score112210
Elapsed Time105 secs81 secs

Pictorially the Network improvements look like this:

And the benchmark improvements look like this:

So the upshot is that there really is something behind the performance claims and that's why Improved Performance is my favorite feature in the SGD 4.3 release.


Thursday Mar 08, 2007

#2 - Controllable copy and paste

One of the motivations for adopting a server-based computing model is that you want to keep your applications and data secure in your datacenter. SGD extends this idea to allowing the administrator to control whether users can map drives and print. But one area that wasn't addressed is data leakage via Copy and Paste operations.

So it's great to see this being address in 4.3.

Here's how it works:
1. the administrator assigns a "security level" to the apps he cares about in Object Manager.
Local applications can also be assigned a security level.

2. When a user tries to copy and paste data from a higher to a lower security level application, SGD prevents the operation by replacing the copied data like this.

Copy the Top Secret stuff...

Now try and Paste it to a local application...

Now I know a lot of people who will also think this is neat. But I can't tell you who they are ;-)



Fat Bloke


« July 2016