The Fat Bloke Sings: Thoughts from a Fat Bloke

Seems that a lot of people are interested in using Web Server Authentication.

A new article that concerns Basic HTTP Authentication and SGD has been posted to the SGD Wiki. Even if Basic HTTP authentication is not what you want, this article illustrates the principles around configuring SGD.

There's also a handy debugging tool (environment.jsp) that you can drop into the SGD webapp directory (/opt/tarantella/webserver/tomcat/*/webapps/sgd) to find out what the web environment looks like.

Another article specifically about Sun Access Manager is also in the works.

 -FB

Part of the graphics subsystem of SGD is based on the X.org 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 X.org 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.

-FB 

Some time back we discussed how to speed up LDAP authentication when logging into SGD. In this tip, we simply recommended reducing the user attributes that we search in order to authenticate a user given the provided credentials.

Well, nice tip as it was, it only works when you are logging in directly to SGD (using built-in authentication) and doesn't help if you are using Web Server Authentication. e.g. you're using something to protect the /sgd URI for example, a simple mechanism like Apache basic http authentication (.htaccess), or something powerful like Sun's Java System Access Manager to protect access to the /sgd URI.

If you're doing this, you need to configure an additional bean in the SGD system. And, to preserve your sanity, Fat Bloke recommends always keeping them in step by configuring them together:

/opt/tarantella/bin/tarantella stop
/opt/tarantella/bin/tarantella config edit --thirdpartyldaploginauthority.properties-searchAttributes cn mail
/opt/tarantella/bin/tarantella config edit --searchldapla.properties-searchAttributes cn mail
/opt/tarantella/bin/tarantella start

Sorry not to have mentioned this earlier

-FB

Fat Bloke was recently asked about hiding, or really protecting, the new SGD administration console so that administration could only be done from say certain locations.

Well, I guess one of the advantages of making the Administration Console a web application is that we can use the power of the web server to help with this.

There are a couple of ways of doing this but I guess a simple way is to use the Apache Location directive:

<Location /sgdadmin>
    Order Deny,Allow
    Deny from all
    Allow from 129.156.4.240
</Location> 

For more info on how to drive this check the Apache doc.

-FB 

One of the major differences between version 4.4 and previous versions is the new web-based Administration Console.
Hopefully this is easier to use than the older Object Manager and Array Manager whose functions have now been coalesced into the one new tool.

Fat Bloke's readers are smart enough to find their own way around this tool so there's no tour here, but here are a few little known facts about the new tool:

1. The SGD Administration Console is a pure web application which runs under the bundled Apache Tomcat and is located in the filesystem at

   /opt/tarantella/webserver/tomcat/5.0.28_axis1.2/webapps/sgdadmin.war

2. It uses a Sun standard UI style shared by many other Sun infrastructure apps such as Directory Server, Identity Server, Sun Ray Server, etc.
3. It picks up your locale from the browser. e.g. on Firefox this is set in the Preferences...General...Language box. (Hmmm, wonder why the webtop (/sgd) doesn't do this?)
4. The underlying datastore layout changed to support the separation of:
   • applications
   • application servers
   • user information
   which means that when you upgrade to SGD 4.4 the install script reorganizes your ENS tree. To check this out, use a command line like this:
   

   /opt/tarantella/bin/tarantella object list_contents --name ""

   to traverse the ENS tree.
   Note that this also means that if you have scripts that create objects via the command line, their locations should be below the above top level OUs. e.g.

   /opt/tarantella/bin/tarantella object new_windowsapp --name "o=applications/cn=notepad" --width 800 --height 768 --depth 24 
   --appserv "o=appservers/cn=Windows Server 1" --icon notepad.gif --displayusing seamless

5. It was developed using Netbeans and uses only the public web service interfaces (so you could build your own replacement if you don't like it )

Do you ever get that spooky feeling when you visit a place you've been before, but something is slightly different, and you can't put your finger on what has changed?
That's a bit like the login procedure for SGD 4.4.

In versions leading up to SGD 4.4, simply by hitting the http://servername/sgd URL you were delivered the SGD client in the form of a Java archive. This was before you had logged in.
Now with 4.4, you have to successfully login before you get the client.

If any of you have web applications that talk to SGD using its web services, this subtle change may mean you have to switch around a couple of calls. but this is covered on the SGD wiki

News about the latest release.[Read More]

Sun is publishing a series of Desktop Virtualization Podcasts which are basically chat shows with different guests, talking about new developments in the space.

Check 'em out.

-FB

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

-FB

Most of you may know this already but for those that don't, I thought I'd take a minute to explain a little about SGD and its place in the new VDI market....

Server Based Computing (SBC)

SGD was originally designed to allow people to run local and remote apps side by side in a hybrid desktop model. The remote applications were made to look like local ones (seamless windows), and behave like local ones (printing, filesystem access, audio, etc) but they were actually running on back end server platforms. And most SGD customers use multiple local and remote apps simultaneously, e.g. they'll have several windows open running a mix of Windows, Solaris, Linux, etc. apps

This approach solves issues of data security (lost laptops), manageability (apps live on servers in datacenter) and mobility (use any client from any network location). So administrators can decide which apps should be centrally located and which local on the users PC.

But what if you wanted to deliver not just the apps, but the whole desktop environment too? Well, some SGD users do this today when they publish a full Windows desktop or Gnome-session, say. But traditionally, these have been desktops delivered from Windows Terminal Servers or Solaris/Linux Servers. And the problem with Windows Terminal Server has been that some apps just don't work in a Windows server environment (e.g. they expect a unique IP address or global access to the registry/filesystem, because they were designed to run on a PC).

Virtual Desktop Infrastructure (VDI)

So what is usually meant by VDI is that the desktop environments (usually Windows desktop environments) are not running on servers, but running on Windows *client* OSes which are themselves running in individual virtual machines on a server. e.g. Windows XP or Windows Vista instances on, say, VMware ESX Servers.

This is interesting because those misbehaved apps now have a better chance of working because they are running on the platform for which they were designed, a Windows PC.

Now all we have to do is provide secure access to these desktops, and that's what SGD has been doing for years just like this...

So hopefully you can see that SGD is equally applicable for SBC and VDI.

One more thing: if the value you derive from SGD is proportional to the number of apps you access via it, should I pay as much when I use SGD in a VDI environment? After all I'm just delivering a single app - the Windows desktop.

Thankfully, those smart guys in Sun Marketing have delivered a new product for exactly this use case.

When you buy licenses for Sun xVM VDI Software you are allowed to use SGD or Sun Ray Software to deliver a single desktop environment per user.

-FB

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.

Enjoy!

-FB

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

to...

Listen 127.0.0.1:443

2. Set up SGD to listen on external-dns:443

# /opt/tarantella/bin/tarantella config edit --array-port-encrypted 443

3. Tell SGD where to send non-AIP traffic

# /opt/tarantella/bin/tarantella config edit --security-firewallurl https://127.0.0.1:443 

4. Finally, restart the web server and the SGD server

# /opt/tarantella/bin/tarantella webserver restart --ssl 
# /opt/tarantella/bin/tarantella restart

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

-FB

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
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...
2. Start the SGD server in secure mode
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?
3. Start the web server in secure mode
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.

-FB

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.

-FB

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://sun-ds.uk.sun.com/ou=people,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

-FB