Archive for the 'UNIX' Category

Fit-ting In

Here at TAF, we currently run a mix of generic Linux PCs and thin client netstations as X terminals for our AIX production box. The netstations have long been unsupported, but we’re also interested in something more robust and less power-hungry than the PCs we’re currently running. One of my tasks recently was evaluating a Fit-PC2 for use as a replacement.

Out of the box, the Fit comes with Linux Mint installed. For those not familiar with it, Linux Mint is based on Ubuntu. In this case, we’re talking Linux Mint 9, “Isadora”, which corresponds to Ubuntu’s 10.04, or “Lucid Lynx” release. This isn’t a bad thing as it’s a long-term support release, but Ubuntu and friends are problematic for the use we have intended for these machines.

In order to connect to AIX, we rely on XDMCP. We also rely on xfs to provide certain fonts for use by the programs running in AIX. The Ubuntu distributions have removed this support by default, and made it an extreme challenge to put it back in. I spent a day or two fighting the Fit to re-enable this support before giving up.

My next step was to take the brain-dead approach of installing Red Hat Linux using the same install CD and kickstart script we’ve used for our other Linux installations. This actually worked, although disk and video performance weren’t outstanding.

The Fit is based on Intel’s Poulsbo chipset, which isn’t natively supported in our version of Red Hat. Some research in the Fit-PC2 forums yielded a kernel module that provided a working driver, but given the somewhat informal source and the fact that it was for a different distribution, I was reluctant to recommend it for production. However, I did try it on our little box, and was pleasantly surprised. Everything seems to be working as expected, and we will be throwing the box into a production test sometime in the near future.

As a longer term solution, we need to upgrade to a more modern version of Linux along with a configuration tool such as Puppet. RHEL 6 seems to be headed in the same direction as Ubuntu in terms of XDMCP support, so we have some work in store for us.


An Alarming Requirement

A little while back, one of my colleagues at TAF came to me with an interesting challenge. He had been assigned the task of making a production application raise a visual and audible alarm in response to invalid actions on the part of the user. It doesn’t seem like that hard a problem until one realizes that our applications are actually running in XWindows sessions on an AIX server. This means that the running application thinks that its environment is the AIX server, and it knows nothing about the machine actually displaying the user interface.

In the past, this sort of requirement was handled by using a Programmable Logic Controller (PLC), and running conduits and wires from the PLC to the location where the output was wanted. This gets the job done, but it’s expensive to install and move, and requires a lot of lead time if a change in location is needed. On top of that, one also has to involved the services of a PLC programmer, and it may even require the acquisition of an additional PLC if a free port is unavailable on one of the existing alarm-capable PLCs. We needed to come up with a cheaper, more flexible solution.

At first, it was a bit of a head scratcher, but, as it turns out, an application running under XWindows can get one vital piece of information about its environment: the IP address of the machine actually providing the display. In VA Smalltalk, the command “‘DISPLAY’ abtScanEnv” will give you a response of the form ‘’ where anything up to the colon (:) is a host name or IP address, and anything after is the XWindows display number. In our case, we’re only concerned with the host name or IP address. If the XWindows display is actually running on the same machine, the host name will be blank, and you’ll get back something like “:0.0”.

Knowing how to get to the physical computer, we can now think about what to do there. While I have complete control over how the client machines are loaded, it’s generally preferable to keep the installed software to a minimum. Everything I needed to do could be done from a UNIX shell prompt, so using some shell scripts seemed the best answer. Modern Linux implementations make it easy to set up TCP daemons using xinetd, so I set up a listener on a TCP port that invoked a simple script.

My Smalltalk program opens the port on the client machine using Totally Objects SocketSet, writes a value to the port, and closes it again. On the client machine, the script reads a line of input from STDIN, and uses that input to invoke an appropriate alarm script. You could do the same thing with VA Smalltalk’s socket support, but if you value your time at all you’ll quickly come to appreciate the benefit of Totally Objects’ product.

This has been working quite well, but a new curve was thrown at me recently. Instead of just firing off an audible alarm, the users wanted the computer to send a voice instruction. Since the number of instructions was fairly small, it wouldn’t have been impractical to record sound files and play the correct one based on an alarm number, but it wouldn’t scale well and keeping clients up-to-date would start to become a challenge.

Instead, a little research turned up the fact that our preferred Linux distribution, Red Hat, includes a speech synthesis system, Festival, with text-to-speech capabilities. Even better, Festival can be run as a daemon that listens on a TCP port. A little bit of shell programming later, and Festival was wrapped as a Linux service. Another bit of Smalltalk code using Totally Objects SocketSet was used to pass text to that service, and we now have generic text-to-speech capability in our application.

Certainly Smalltalk could have been used to implement most of the daemon side of these alarms as well, but some scripting would still have been required. Using the approach we did allows us to keep the installation package light and minimize the skill set required to maintain it in the future. Moreover, testing, troubleshooting and modifications can be done easily from a command prompt the client machine which has a lot of value when you’re trying to fix a problem in a factory a long way from your development environment!

A Little Samba

A friend approached me for some Linux help the other day. He wanted to access an SMB/CIFS share on his network attached storage device (NAS) from his Fedora Linux box. I’d actually done something similar in a former life, so it seemed like a relatively simple problem. I assured him that spending some time learning about autofs would quickly get him to where he wanted to be.

In my case, I set up an offsite Linux laptop to make an hourly connection to the company network via VPN, and mount a Windows share. The script would rsync the contents of the Windows share to a local directory, and disconnect. This setup ran happily for a few years with only minor changes for password updates and such.

My friend was less fortunate than I’d hoped. He found a website with some instructions to create a /etc/auto.cifs file that would automagically connect the necessary shares on reference to a dynamically-created directory hierarchy. It sounded great, but, unfortunately, just didn’t work. I poked at it a little while, but, in the end, went with the technique I knew would work. I document it here for posterity. In some cases, where I say I did something, it had actually already been done in the unsuccessful attempt to get things working.

First, I yum install samba-client. The autofs service had already been installed, or else I would have had to do that, too. Then, I make sure that the NAS device was in the Linux machine’s /etc/hosts file (he doesn’t run a Bind server). I create a directory to act as the base for CIFS shares, /cifs (it could be any new directory, arbitrarily deep in the hierarchy.

Let’s assume that the NAS device is named nas, we’re interested in the SMB share myshare on the device, the username we’ll use to access the share is guido, and guido’s password is sarducci. I create a file named /etc/nas.password with two lines:


and after saving it, chmod it to 0600.

I then create, or modify, /etc/auto.master to read

/net -hosts
/cifs /etc/auto.nas --ghost –timeout=60

The --ghost parameter causes any shares mentioned to show in a directory listing even when they’re not actually connected.

The file /etc/auto.nas looks like this:

myshare -fstype=cifs,rw,credentials=/etc/nas.password ://nas/myshare

The above should be on a single line. Additional shares could be added with the same or different credentials. Make sure that this file and all credentials files are chmoded to 0600.

Once the autofs service has been reloaded, you should be able to see files in /cifs/myshare.

Part 5: The X Factor

As I said before, this installment is optional for anyone not building in UNIX.  You’ve been warned!

By its nature, VA Smalltalk requires X-Windows to run in the UNIX environment.  When you’re working interactively, this isn’t a problem.  You’re logged into a nice Gnome, KDE or CDE environment that’s already graphical, or, if you’re an unreconstructed curmudgeon like me, you’re using SSH and forwarding X to a local X server.  The problem arises when you want to have VA Smalltalk do its thing unattended.

Tasks that are run via cron, the usual scheduler for UNIX, execute without the benefit of an X server.  As a result, your nice little script to start VA Smalltalk and do some brilliant unattended task that worked so well when you tested it is going to fail because the Smalltalk VM won’t be able to connect to the X server.  Luckily, there is a solution:  the X Virtual Frame Buffer, or xvfb.

Xvfb is available for all the environments on which VA Smalltalk runs, although I’ve only used it on Ubuntu Linux and AIX.  In the case of Ubuntu, you should install the package ‘xvfb’, either via apt-get or Synaptic.  For AIX, IBM has a useful page with installation information.

Once installed, Ubuntu includes the script xvfb-run.  All you need to do is pass your desired command line along as a parameter to xvfb-run, and it will create a fake X environment in which to run that command.  For AIX, you just need to export a DISPLAY environment variable specifying the display number assigned by your system administrator to the virtual frame buffer; e.g. export DISPLAY=:1.0.  The remainder of your build script can remain unchanged.

RPM-based Linux distributions have xvfb available, but they don’t include xvfb-run.  I haven’t looked into what would be required in those cases, nor have I looked into Solaris at all.

With the next installment, we return to our platform-independent discussions.