It was busy in June and July over at $WORK, so I didn’t get a chance to write any entries here. Some of the work I’ve been doing include turning off all legacy servers (among the legacy servers are only 2 FreeBSD boxes and a handful of HP/UX dinosaurs, but the rest of the production environment is SUSE Linux Enterprise), shepherding the BlueArc storage upgrade through (a huge pallet containing disks, controllers, disk shelves, and a replacement Fibre Channel switch arrived last week), and, of course, planning our upgrade to a modern Apache/Java environment. This will consist of Apache 2.x with a Tomcat 5.5 back end — a far cry from our current Apache 1.x and Tomcat 3.x setup.

One of the major challenges is getting Tomcat 5.5 running on SLES 9 under a Java 1.5.x virtual machine. Actually, it’s not so much the “running” part — I’m sure that since it’s Java, it would just run if I did the old tar zxvf tomcat-5.5.tar.gz && make && make install dance. But we’re after sensible package management here, and that means trying to make SLES 9 behave the standard way. SLES 9 is missing a lot of the “standard” tools that folks use to manage Java apps; it has no jpackage-utils built-in, it doesn’t use the alternatives system, and it can’t talk to Yum repositories out of the box. The work instructions I developed here hack up the base OS a bit to bolt on these tools, but ultimately do the job.

The long-term solution, of course, is to move to either SLES 10 or RedHat Enterprise Linux 5. SLES 10 ships Tomcat 5.0.x out of the box (just like SLES 9) so on the surface, it doesn’t seem like much of an improvement. But they have moved to the alternatives system; jpackage-utils is bundled with the base system, and ZMD (for what it’s worth) will talk to Yum repositories. (Of course, that’s in theory: in practice, as with many Novell tools, it’s broken.) RHEL 5 seems like the obvious answer, since it ships Tomcat 5.5 right out of the box.

On June 16th, SDF Public Access UNIX system will celebrate its 20th anniversary!

Twenty years ago, SDF-1 was a 300 bps dialup BBS running on an Apple ][e computer system, and has evolved over time into a twelve node DEC Alpha cluster running the NetBSD operating system. SDF users, of which I am one (keymaker@), pride themselves on the fact that theirs is one of the last bastions of “the real INTERNET”, out of the reach and scope of the commercialism and advertising of the DOT COM entities. I recall fondly the days before commercial traffic was permitted on the NSFNet, and oftentimes wish that we could return to those days when everyone knew their proverbial neighbours.

If you’re interested in SDF, lifetime membership is very affordable at $36. You can find out more information about SDF here. You won’t find any fancy Web 2.0 widgets, but you can definitely still use Gopher 1.0!

I just upgraded to Fedora (no longer “Core”) 7 and decided to finally install Adobe Acrobat Reader for Linux. Normally I’ve used the built-in “Document Viewer”, but I needed to fill in a PDF form, and only Reader will allow you to do that.

Upon installing Reader, I found it would loop forever, printing expr: syntax error on the screen. Fortunately, someone has already solved this problem:

I also had to perform an upgrade using Yum instead of booting off the installation CD and doing a binary upgrade, because my system has a Highpoint 1740 SATA RAID adapter and a driver disk is not yet available from Highpoint for this. My procedure for upgrading using Yum and keeping the system functional was as follows:

Upgrade using the procedure described in the Yum Upgrade FAQ as above. This involved a lot of manual dependency munging, specifically me having to massage an upgrade of mkinitrd and nash manually.

Build the Highpoint rr174x driver for the new kernel and install it into the initrd. This involved a magic incantation of the sort cd /usr/src/rr174x-linux-src-1.02/product/rr174x/linux/ && make install KERNELDIR=/usr/src/kernels/2.6.21-1.3194.fc7-x86_64.

Fix up /boot/grub/grub.conf to make sure the new kernel is there (for some reason it wasn’t)

Comment out old /dev/hd*-format devices in /etc/fstab because Fedora has switched to using libata entirely, so even old PATA devices now use the /dev/sd* notation.

Reboot and cross fingers.

Fix up disk device names in /etc/fstab with the new sd* name.

Reconfigure samba so girlfriend can access MP3s again. 🙂

Altogether, not the most painful upgrade I’ve done, but I would have preferred to do the binary upgrade using the installer CD. Only if Highpoint would release its drivers as open source and then they could be incorporated into the kernel tree…

As some of you know, I run SUSE Linux Enterprise Desktop (SLED) on my CBC-issued desktop. CBC.ca also uses a combination of SUSE Linux Enterprise Server 9 and 10 systems to produce and host the website, and most of the corporate infrastructure is Novell-based (Novell Groupwise is the corporate e-mail system, the file servers are all Netware, etc.) I use SLED because it gives me the right balance of being a UNIX-like operating system, and giving me access to corporate file shares through eDirectory. But let me be clear: I use SLED because it’s UNIX-like, just as we use SLES on the servers because it’s UNIX-like. One element of SLED/SLES that is distinctly not UNIX-like is the package management toolchain, ZenWorks Linux Management (ZLM). And that really bothers me.

On the other end of the spectrum from my last post, I decided this evening to install NetBSD 3.1 on the SGI Indy that fellow BSD user Jeff Buan gave me a few months ago. This system would have cost an obscene amount of money back in the day (1993) but now, it’s probably worth about $10. These boxes are pretty close to as rock-bottom as you can get these days:

Speaking of challenges (pun intended), the last time I tried to install anything on an SGI server, the victim box was an SGI Challenge L — a 200kg fridge-sized monster that my friend Naveen had muscled from the Department of Astrophysics at U of T. It required a 220V power converter that he ended up buying from the House of 220, and a custom-soldered RS-422 serial cable to get on the console. I hoped the Indy would be easier to set up.

I’m writing this entry under SuSE Linux Enterprise Desktop (SLED) 10, which I recently installed on my CBC-issued ThinkPad T42. The laptop came with Windows XP installed, which I decided to retain in a dual-boot configuration, because there are still certain tools at CBC (like our antiquated Visual Basic-based â€œGuests & Boardroomsâ€ booking system) that still require Windows. I did manage to get Remedy ARS to run properly under Wine, however (the latest version, 0.9.28, that is; earlier versions had weird problems rendering dropdowns).

I decided to evaluate SLED because of a number of reasons:

I am fairly satisfied with my OpenSuSE-based CBC-issued desktop, and wanted to see what a â€œvendor-supportedâ€ branch of OpenSuSE would look like;

Novell Client for Linux is only officially supported under SLED, although I have it installed under OpenSuSE, with some hackery (like --force and --nodeps manual installation of RPMs);

There is a rumour flying about the IT grapevine that in the not-too-distant future, CBC will be converting many of its desktops to run SLED.

My expectations for SLED were somewhat low. Although I fully expected everything to work as advertised in the product literature, I worried that the feature set would lag behind the cutting-edge by at least twelve months, as is the norm with RedHat Enterprise Linux (RHEL). For example, I was surprised to see a 2.6.16.x Linux kernel; had I installed RHEL, I would probably be running a 2.4.x kernel.

I decided to put SLED through the paces by trying out a few things that it advertises as working, but with which I’ve had problems in the past:

Evolution connectivity to Groupwise servers using the Groupwise SOAP interface

On-board Intel modem

Finally, I wanted to play around with the Xgl display effects, and to see how well that worked (and whether it looks as nifty as my colleagues claim)

I have to say that after a couple of weeks of using SLED that I’m very impressed. This is perhaps the nicest-looking Linux distribution I’ve ever used, and everything does â€œjust workâ€. Wireless networking is stable and functional, which is absolutely unprecedented for me under Linux. The NovellVPN client does in fact talk to CBC’s Contivity VPN with no problems. And all the problems that have plagued NetworkManager in the past seem to have disappeared. Connection profile switching is as seamless as Mac OS X, which is more than can be said for the IBM Access Connections hackery that is required under Windows.

There’s only one challenge remaining for me, and that’s to see if I can get PPTP working under SLED. This is because the CBC in-building wireless network requires it; association to the AP requires no authentication or encryption, but in order to get onto the BAN, a PPTP VPN connection through a Bluesocket concentrator must be made. I’ll keep you all posted as to my progress!

And yes, the Xgl desktop effects are very nifty — but my laptop’s video card is woefully underpowered, so sometimes X fails to start with Xgl turned on. However, on a desktop machine with a decent video card, I’m sure they would perform perfectly.

I finally took an evening to upgrade my aging Compaq AP550 fileserver (FreeBSD 4.11-STABLE) to FreeBSD 6.x. Even with some good planning (as any good IT person should do), there were still a few problems. Continue reading →

I decided to format my CBC-issued desktop and install SuSE Linux 10.1. You will recall that back in January I tried to install SuSE 10.0 on a Thinkpad T42, with very poor results. So why did I decide to try again? There are a number of reasons:

CBC is a Novell shop internally; they use GroupWise for email and make extensive use of NDS, ZENworks Desktop Management, iPrint, and many other Novell technologies. SuSE, as you probably know, is a division of Novell.

I despise GroupWise but I am hoping at some point in the future to be able to use Ximian Evolution’s Groupwise connector to talk to our Groupwise servers. This probably won’t happen until corporate IT upgrades to Groupwise 7, though (or at least until they turn on the web services interface in Groupwise)

CBC.ca runs SuSE Linux Enterprise Server 9 on all of its production web and Java servers, so having a similar environment on my desktop for development purposes makes sense.

After a few weeks of using SuSE Linux 10.1, I’m generally happy with it. Part of that is due to the fact that I’m not using it on a laptop, so my original beef about WPA being broken is a non-issue in my use case. (That doesn’t mean that the problems have been solved, though; 10.1 still doesn’t support WPA properly.) I still have a couple of complaints:

The successor to Red Carpet, Zen Updater, is horribly broken out of the box. In order to “fix” it I still needed to run YaST to upgrade to the latest versions of libzypp and all that jazz. Still, YaST and Zen Updater are both far, far slower than any other package management tool I’ve ever used.

SaX2, SuSE’s X Server configuration tool, is still extremely buggy. This would be only slightly annoying if you could hack the xorg.conf yourself, but SaX puts all kinds of proprietary directives in there (such as Option "SaXDualHead") and prefaces the file with a warning to not hand-edit it. So what are you supposed to do when SaX fails you, e.g. it refuses to properly configure my Matrox G450 in dual-head mode?

There are some positive aspects to SuSE Linux though, namely its integration with NDS (I guess they call this "eDirectory" now). I was able to successfully install the Novell Client for Linux 1.2 and log onto eDirectory. There’s a nice fancy QT GUI and GNOME tray icon for managing Novell connections and for the most part it works flawlessly, just like Novell Client for Windows. This is a huge improvement over the awful NovelClient (sic) that I used to use before during my first term at CBC.

As I said, I’m generally happy with SuSE Linux. My one remaining complaint is this: why does Novell have so many confusing names for its Linux products, and why do they seem to change them every 6 months? We have SuSE Linux Enterprise Server (SLES), Novell Linux Desktop (NLD), OpenSuSE, SuSE Linux Enterprise Desktop (SLED), SuSE Linux Enterprise OpenExchange Server (SLEOS? SLOS???), Open Enterprise Server (which I gather isn’t even really Linux but some form of Netware?), and so on. Even SuSE Linux 10.1 has two versions: a so-called “retail” version that comes with support, and a downloadable “community” edition (that I’m using) with no support and missing a bunch of non-GPL packages like RealPlayer, Flash, Adobe Reader, etc. but which you can install later. Worse still, Novell refers to SuSE Linux 10.1 as “created by the openSuSE project”, but the next version of SuSE Linux, 10.2, is going to be called openSuSE 10.2 …?!

All of this SLES, SLOS, and SLED nonsense makes my head spin — makes me want to give the Novell marketing monkeys a SLAP.