Boggle.org: Corporate Linux

Introduction

I wrote this article almost six months ago with the expectation that at least some of it would become outdated fairly quickly -- particularly the problems around automated installation and VMware licensing -- but much to my (unpleasant) surprise, these seem to still be current issues.

There will almost certainly be a followup article to this. The whole issue of making Linux suitable for use as a corporate desktop OS is one I've become quite interested in, and I'm sufficiently disappointed by the lack of interest in or understanding of this market shown by the Linux vendors that doing something about it has gone on to my big list of Things To Do in my Copious Free Time.

The reader should note that the author has been spoilt by the relative sanity of Solaris on Sun hardware as a workstation platform. He does not want to go back to the horror of interactive installs and carting boot media around.

The article is not entirely satisfactory, but I believe that the issues it raises are important enough to outweigh my embarassment over some of the prose. So here it is.

The Joys of Corporate Linux

As is the case in many organisations, there has been pressure to find ways of reducing the cost of computing infrastructure. In a primarily-Sun shop the obvious area for savings is workstations -- Sun's lower-end machines (like the Ultra 5) don't really have any performance advantages over PCs, and cost a heap more.

In addition, we are a small Unix fish in a largely Windows ocean. Corporate standards for calendaring, e-mail, and document production are set with little or no reference to the availability of compatible tools for Unix users. I suspect that this is not an unusual situation for Unix sysadmins in large corporations.

So clearly there's a need to find some way to fit our organisation into such a scheme. The major issue is calendaring and forms -- these run on Exchange, and the only client which works with these is Outlook. Outlook Web Access isn't really a good tool for these tasks -- fine, perhaps, for a marketing guy on the road who needs to quickly check his calendar, but frustrating to use on a day-to-day basis.

The "simplest" approach would be to replace workstations with Windows machines. There are several X servers available now, and they mostly don't suck too much.

The difficulty, of course, is that Windows is a high-maintenance platform. Even NT is notoriously flakey and -- particularly when your users are quite technical -- it's not uncommon for the administrator to have to give local Administrator access to the user -- opening up a huge can of worms best left untouched.

So when VMware 1.0 became available, we were jubilant. Here, we thought, may be a way of providing access to Windows applications without having to deal directly with the ickiness which is Windows -- run an untrusted Windows system in a VM, which is easy to reset to a known-good state, running on top of a reasonably solid Unix-alike.

The first problem we came across was performance. VMware is a pretty nifty tool, and it's fine for a user who just needs occasional access to Word. But unless you can give it a lot of memory and a grunty machine it can get painfully slow running applications like Rose or Frame. And Outlook, for some funny reason. 128Mb in the machine is not enough.

The second issue is the VMware licensing scheme. For each user you place a license file in ~/.vmware. This is fine for one or two users, but quickly becomes a pain in the neck for many more. To their credit, VMware do seem willing to negotiate an alternate licensing arrangement, but only if you're going to buy the product in bulk -- which is not really an option during a trial period.

The final difficulty is the VMware installation procedure. It can almost certainly be automated, but as provided it requires manual intervention. No problem for a few installs, and if you're doing thirty or so then you're going to have some serious motivation to find some way of automating it, but for the smaller trial of ten users that we ran it's annoying without being annoying enough to provide motivation to reverse-engineer the installer.

That said, VMware isn't a bad product. Throw enough grunt at it and it's quite usable. Just don't try running Windows98 under it.

Where the real pain comes in is Linux on name-brand PC hardware.

Yes, that's right. The darling of the industry press is a pain in the arse in a corporate setting. It's not the politics, either. To be fair it's not entirely the operating system's fault -- corporate purchasing practises are also a significant factor.

The major problem is fairly simple. All of the Linux distributions currently available make certain assumptions. The biggest of these is that the person sitting in front of the box is going to have root, and that nobody is going to be trying to maintain 100+ Linux desktop machines. Or if they are, they've been herding Windows boxes for years and are willing to put up with the sorts of idiocies inherent in that.

I looked at pretty much all of the distros. Debian (which, when running Linux, is my preferred distro) does not yet handle automated installs. They're working on it, but the release version does not do this. So installing a system involves a fair bit of manual intervention, which simply isn't acceptable in this sort of environment.

The only distribution I could find which came even close to Solaris is Redhat. Once you've got the install infrastructure in place all you need to do to put a new box in is to add it to your DHCP server, insert the boot floppy, and type "linux ks" at the boot prompt.

Or at least that's the theory. Oddball hardware (in our case HP Vectras) can get in the way. The first problem we discovered was that the installer can't talk to the DHCP server. Well, not on the first try, anyway. When it complains that it's getting no response (which, by the way, it should be -- the dhcpd logs look fine up until the client should be sending it's final ack), tell it to have another go. That fixes it. Usually. But not always, even though the hardware is allegedly identical from one machine to the next.

When you do finally get it to discover it's IP, the install proceeds without much fuss. Although for some unknown reason we've been unable to convince the post-install script to install xntpd, despite the same commands working just fine after the box comes back up. Minor issue, almost certainly resolvable.

Once you've got the machine up and running, the long-term issues come into play. Maintaining a couple of boxes with locally-installed applications isn't a major drama -- at worst you're only going to have to install each extra app a couple of times, and provided your record-keeping is up to scratch you can rebuild a box without too much hassle.

Now make that 10 machines. Or, worse, 100. Now it gets very time-consuming. And if you don't install every app on every machine, you run into problems with users moving from one machine to another and not finding the apps they use.

The fix for this, of course, is to place apps in a central repository. Whether you simply mount this on workstations or use a scheme like rdist to push it out to local disk is mostly a question of preference and infrastructure.

There is, however, a hitch. Some Linux-specific applications (such as ALSA) take some serious work until you can beat them into submission and have them work in such a scheme. By an amusing coincidence, VMware is one such application.

Now we get to the hardware. My advice to you is this: if you can't control exactly what hardware you're going to get, or your supplier can't or won't commit to providing the same equipment for an extended period (six months is an extended period in the PC hardware world), then forget it. Seriously.

If you can control the hardware, then you can probably save yourself some time by doing a Linux-equivalent of ghosting machines. I haven't tried this, as we can't control the hardware.

The other option to consider (particularly if you're coming from the Sun camp) is Solaris/x86. It's a lot easier to make the result feel the same as a Sun workstation this way, and unless you're scrapping all your workstations at once that's fairly important.

What it all comes down to, I guess, is that going from Windows to Linux is going to seem like a step up. Solaris to Linux (especially if we're talking Sun hardware to PC hardware at the same time) feels like a retrograde step. From the sysadmin point of view, anyway.

So. When your non-technical manager comes to you after reading the latest analyst's reports about how great Linux is, approach the whole issue with extreme caution. It may be a good move for your organisation, but that's nowhere near as clear-cut as some advocates might like you to believe.


© 2004 Matt McLeod, All Rights Reserved
This page was last updated Sunday, 13-Oct-2002 07:42:02 UTC
webmonster@boggle.org