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.


Thursday Jul 12, 2007

Migrating the SGD ENS Datastore

If you read the previous blogs about using the command line, you may think that by using the "tarantella object list_contents" and "tarantella object list_attributes" commands then you can simply walk the ENS datastore tree and archive the contents. And then use the "tarantella object new" commands to import them into a new SGD server. Well, you could but here's another way:
  1. Stop the SGD server
    # tarantella stop; sleep 30; tarantella stop --kill
  2. Create an archive of the desired ENS.
    # cd /<install-dir>/var
    Note: <install-dir> Is a placeholder, indicating the installation directory. The default for SGD is /opt/tarantella. CPIO implementations differ based upon version and platform. Below are two example commands. Please choose the one most appropriate with your environment, and verify correctness via man page.
      LINUX   # find ens | cpio -ocv -C 1024 -F /tmp/sgd_ens.cpio
      Solaris # find ens | cpio -ocv -C 1024 -O /tmp/sgd_ens.cpio
    This file, '/tmp/sgd_ens.cpio' may now be copied to the target server that you'd like to restore it on.
  3. If you are planning to restore or migrate this ENS over a 'fresh' SGD install that maintains the default application objects, it may be beneficial to save the existing DNS for future troubleshooting. To do so:
              # cd <install-dir>/var
              # mv ens ens.<SGD version>.default
  4. With the original ENS archived, and the SGD server stopped, you will now want to restore the archive in the same <install dir>/var/ directory
              # cd <install-dir>/var 
      LINUX   # cpio -icdumv < /tmp/sgd_ens.cpio
      Solaris # cpio -icdumv < /tmp/sgd_ens.cpio
  5. Once the transplanted ENS has been restored on the server, it is necessary to remove ens/.object file. This forces SGD to 'reindex' the ENS on it's next startup.
        # rm <install dir>/var/ens/.object 
  6. Start the server:
              # tarantella start
It may be useful to someone.


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 ;-)


Friday Feb 09, 2007

#3 Pricing

OK this isn't a feature but it is a change that happened with version 4.3 and something that has "lowered the barrier" as they say;-)

Compared with earlier versions, the price of 4.3 is roughly 30% less!

That's all.

Thursday Feb 08, 2007

#4 - Windows XP as a "server"

So now we're getting to some new "features" which are really making an impact to the SGD business.

But what is this one all about? When would you want to connect to Windows XP Pro as a "server"?

Well, as it happens, there are a couple of compelling situations when you might.

  1. Connecting to your traditional fat client

    Many organisations that haven't yet seen the light, are running the traditional desktop architecture of a windows PC on the desk and all applications installed locally on it.
    This model has served us well but is creaking a little with new demands.
    You see, in this model the work environment is heavily dependent on that good old PC sitting in the office.
    So what happens when the inevitable happens?
    What will it mean to your organization when 60% of the guys can't get to the office, can't get to that good old PC?

    So one solution is to deploy SGD in a configuration where employees can reach their desktop PC from home.

  2. Connecting to a Windows XP Pro instance running on a Virtual Server

    Desktop Virtualization is hot! We're seeing people now deploying XP Pro on VMware or Xen Servers and using SGD to access them in a secure, controlled way. This delivers the benefits of server based computing (security, mobility, manageability, device choice, etc) by delivering a familiar environment. Not a bad idea eh?

So in the words of a famous European beer manufacturer, SGD 4.3 can now refresh the parts other products can't reach.
And that's why this feature is in at #4


Fat Bloke


« August 2016