Monday Jan 28, 2008

SGD 4.40.917

Part of the graphics subsystem of SGD is based on the project. Well because of a security vulnerability there is a re-released version of SGD now available.

Version 4.40.917 is now available and includes 2 significant additions:

  1. The security fixes.
  2. Support for Windows Terminal Services Session Directory.

This second is a feature that wasn't due to arrive until the next release but the team took the opportunity to include it as part of this rebuild.

This is good news, especially for people using a mixture of Sun Ray and non-Sun Ray clients.


Monday Nov 19, 2007

SGD 4.4 just released.

News about the latest release.[Read More]

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.



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 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.

Friday May 11, 2007

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.


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.


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.

Tuesday Jan 30, 2007

#5 - Client Drive Mapping for UNIX apps

Out of the box, SGD is pre-configured so that any remote apps you run cannot touch the drives on your client device, e.g. your Windows PC.
Reasons for this may be to protect against "contamination-in", where viruses, malware etc may be uploaded to your protected server-side apps.
Another reason may be to protect against "data leakage-out", where you don't want sensitive data leaking out of the internal network.

But at other times you really, really do want to open or save files to your local drives.
So it was great to see yet another cool feature appearing in the SGD 4.3 release, Client Drive Mapping for UNIX apps.

This means that I can run an app on a Solaris or Linux server, say StarOffice, and have that application "see" my local client's filesystem.

It works like this:

And here's how you set it up on the application server:

  1. Create a mount point:
     mkdir /smb
    chmod 755 /smb

  2. Export it:
    On Solaris you can add a line like this to /etc/dfs/dfstab
     share -F nfs -o rw -d "UNIX Drive Mapping" /smb 

  3. Restart NFS
    On Solaris 10:
    svcadm enable network/nfs/server

  4. Install the SGD Enhancement Module (tem) on the Solaris server:
    download it from http://yourservername/tarantella/cgi-bin/modules.cgi
  5. And start the drive mapping component:
    /opt/tta_tem/bin/tem startcdm 

The Administration Guide tells you how to set up the SGD server and how to control which users can/cannot use client drive mapping.

So the end result allows me to see something like this:

...which is me running StarOffice on Solaris 10 accessing files on my Mac OS X Desktop.
Pretty cool huh?
So it makes it into my Cool List at #5.

Wednesday Jan 03, 2007

#6 - Integrated Client Mode

Resuming my personal countdown of cool features in SGD 4.3.....

I guess the fact that you are reading these ramblings of Fat Bloke means that we share some knowledge of the world of server-based/thin client/virtual display computing. And you already know that by deploying your users' apps on servers it makes for a more secure, more manageable, more agile desktop approach. But what about the end-user experience?

End users can be demanding but on the whole they're a fairly simple bunch. They don't care about architectures, or security of the system, or load balancing, or even the platform of the applications they need to use. They simply want to be able to run their applications as if it were local.

And whilst previous versions of SGD addressed usability demands such as opening/saving docs to local disks, printing to local printers, and displaying windows in a seamless way, just like local apps, the new version takes integration with the client to a new level.

You see, in SGD 4.3, users can choose to have their remote apps appear in the Start Menu alongside their local apps.

And as these Start Menu items are simply links, they can be dragged onto the desktop for quick access too....

So that's why this feature makes it into my Top 10.



Fat Bloke


« February 2017