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

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.


Tuesday Dec 19, 2006

#7 - PDF Printing. Now to Mac OS X, Linux and Solaris

Previous versions of SGD support that cool PDF Printing feature if you had a Windows client.
This is where the SGD client sees if the client understands PDFs and if so creates a synthetic printer on the app server.
When the user prints to that printer, a PDF file is sent to the client where the PDF viewer is used to print it.
Quite cool because it saves installing printer drivers on the servers, and the resultant print job is hi-fidelity.

Well, in SGD 4.3, we Mac users and our cousins that use Linux and Solaris, can also use this cool feature.
The SGD client knows that if it finds a Mac PDF viewer ( or UNIX viewers (like gview) then the client is "pdf-aware" and the magic begins...

Friday Dec 15, 2006

#8 - A global server

I understand that 4.3 is now Internationalized and Localized to English, French, Korean, Japanese as well as Traditional and Simplified Chinese, but so are lots of other products.
What I think is quite cool is the fact that the same server instance supports these locales at the same time.
So this makes it in there at Number 8.


Fat Bloke


« July 2016