Software

Lately we are looking at groupware options, and have been looking at Scalix and Zimbra. We may need the features in the proprietary versions of these products, unfortunately.

So I downloaded an evaluation copy of Scalix.

They say they support RedHat and SuSE. Fine, I think, I'll just alien the RPMs to debs and be happy.

Not so fast. They have a whole proprietary install system. They check for /etc/redhat_release or /etc/SuSE_release (or something like that) and do different things depending on what is there. Ugh. Why can't these proprietary vendors just target LSB? The differences seem mostly related to init anyway.

So I touch /etc/SuSE_release into existence, run the installer again. It complains that DISPLAY is not set. UGH. I log in with ssh forwarding, to root (sigh), and run it again.

Now it complains that the SuSE_release file doesn't contain a valid release. I google a bit, but the file format doesn't seem to be documented anywhere. I extract it from an RPM somewhere, but no luck.

So, I figure at this point, let's try an actual RPM distro. I'm running this in a Xen domain anyway, so it should be no big deal, right?

I think CentOS will be a good choice. It's RHEL with the non-free stuff stripped out. And they support RHEL and don't need any non-free stuff. I google, and find instructions for installing via rpmstrap for Xen uses.

Let me say, rpmstrap is not nearly the nice tool that cdebootstrap is. rpmstrap totally hosed the networking on the Xen host machine, requiring me to reboot to get it back to proper state. The resulting install wouldn't boot, either -- I later found out that, even though I listed explicit devices in /etc/fstab like usual, it requires labels on all my partitions to boot. Ugh. There are a host of other problems with the rpmstrap-installed chroot, and it's broken beyond my ability to repair due to problems with the rpm database.

So then I downloaded the "Server" CD for CentOS, which is supposed to have just the stuff a person would need for a server, and leave off all the graphical tools, multimedia, etc. I fired up VMware and did an install. Then I booted Debian From Scratch in VMware and used tar and netcat to copy the installed image over to Xen.

I got it booting fairly easily. But now I start to remember why I had this instinctive gag reflex last time I used RHEL.

First off, the network configuration, by default, is tied to the MAC address of your ethernet card. So if you replace your Ethernet card, your network is broken by default.

Then, there's the way the network is brought up. It uses arping as part of its procedure to bring up a NIC. If it sees a reply anywhere on the network with the IP you're trying to assign, it leaves the NIC half-up -- it's been ifconfig'd up, but without an IP. So that's right, if somebody happens to have a rogue device plugged in at the moment your server boots, your server will come up without a network configured. This is *Enterprise* Linux and it's pulling this sort of thing. Terrible design.

Next, there's the way the network is *configured*. There are commands such as system-config-network-tui, -gui, -cmd, -druid, etc. I go for -tui. to start with. It's a dialog-like interface, and asks the basics like IP address, etc. It doesn't have any way to configure more than one Ethernet card that I can tell. And some of the settings -- like nameserver -- apparently require you to press F12 to visit. But the program doesn't recognize F12 as sent by an xterm, so it doesn't work.

All the other options require X. So, I reluctantly ssh -X into it as root and run system-config-network-gui. It doesn't work -- complains it can't find DISPLAY. Strange, I think; DISPLAY is set properly to localhost:whatever. It turns out that /etc/hosts is empty by default, so the thing can't resolve localhost! Argh. I add a line to /etc/hosts and it fires up.

This tool works decently. I save, uncheck the tie to a MAC address box, and exit. I then think it might be good to fire it up again and see what it did. I try running it again, and get the same error about DISPLAY. The stupid tool blew away /etc/hosts and replaced it with an empty file! This is NOT what I would expect from an Enterprise Linux. You don't blow away a config file the administrator touched without asking, EVER.

Next, I figure, let's try installing the XFS tools so I can switch the root filesystem to xfs. I start with "yum update", which doesn't quite do what I expect. (It is more like apt-get update && apt-get -u dist-upgrade) So I hit Ctrl-C, but -- surprise -- IT DOESN'T WORK. I press it a few more times, and it seems to just make the downloader cycle through mirrors because of a "download error". So I hit Ctrl-Z and kill %1. I have my prompt, but it's STILL DOWNLOADING STUFF and spewing all over my console. Ugh.

I finally use ps and kill -9 and eventually get it killed off. Stupid thing.

I don't understand why anybody would want to use RedHat Enterprise Linux in an enterprise. It seems more suited to a hobbyist system at home. From reading some forums, it seems there are quite a few people out there using Debian for enterprise systems for similar reasons.

So now, maybe I'll have the chance to actually try Scalix.

(BTW, our intern got Zimbra installed on Debian just fine, so that's a plus for it.)

Yesterday, we got multipath working with our HP MSA1500cs SAN. We have a fully redundant setup with redundant controllers, fibre channel switches, and two FC controllers per host.

We had been having a lot of trouble getting things to work right with active/passive controllers. We could get failover to work in some cases, but getting everything to communicate correctly in the event of a failure was difficult, since every machine would have to flip over to the passive controller simultaneously.

With a firmware upgrade, the MSA 1500cs can support active/active controllers. With the dual-active setup, both controllers are active simultaneously and both are valid paths.

Despite HP support's indications to the contrary, HP does have information on using built-in multipathd in Linux instead of their proprietary multipath solution. It's document c00635587, part AA-RW8RA-TE.

We've configured multipathd.conf like this:

      path_grouping_policy  multibus

      path_checker              tur

      failback                  immediate

      no_path_retry             60

      path_selector             "round-robin 0"

Just put that in your default block and it should work.

Today I'm finally announcing hpodder.

I've been trying different podcatchers in Linux, and have been generally unhappy. ipodder looked nice at first, but turned out to be horribly buggy.

bashpodder/podracer looked like a nice idea. However, it didn't have enough flexibility for me, its XML parser has some well-known failures (it's not a real XML parser, after all), etc.

So I wrote hpodder. hpodder is a command-line podcast downloader for Linux. It features:

• Extensive manual (installed as manpage, or you can view the PDF versoin). Documents all command-line options, the config file, a quick start, plus some basic information about the internal database


• Database of seen URLs (in Sqlite3) -- for use both for downloads and when processing feeds


• Graceful handling of Ctrl-C, shutdowns, network troubles, etc -- including ability to resume downloads later, plus the ability to detect servers that don't handle download resuming properly (libsyn)


• Automatic setting of ID3 tags based on the episode title and podcast title from the podcast's feed (as iTunes does) -- dramatically helps with viewing of all sorts of podcasts on the iPod and your PC


• Support for download rate limits, progress bars, etc. via Curl


• Seems to be stable for me


• Command-line tools to: add new podcasts, remove podcasts, update podcast feed URLs, scan podcast feeds, list known podcasts & status, list known episodes & status, alter episode status (mark for downloading or not), "catch up" podcasts, etc.


• Automatic retry of downloads that failed due to transient errors

You can download a source tarball, or apt-get install hpodder if you run Debian sid.

hpodder is written in Haskell, and calls the curl and id3v2 binaries. It uses the Sqlite3 library and my HDBC database interface for Haskell.

But you'd never need to know or care about that unless you're a programmer.

In future hpodder versions, I intend to improve the download status display, add last-seen date tracking, and add multithreaded downloading.

Today I was listening to Gary McGraw on Frontline Security talking about software security. One of his points was that a large part of security trouble is poor design.

That reminds me how I've been meaning to rant a bit about the really terrible security I've seen in proprietary software lately. Some of this is very expensive software that people pay lots of money for.

• World-writable installations. In one case, the documentation for the software directed users to mark the entire program's directory tree world-writable, including all files and directories within it. In a whole host of additional cases, consultants or support people tasked with installing the software make everything world-writable as a matter of routine. And some of these are programs specifically designed to be used on Unix shell hosts.


• Overuse of telnet. There's telnet use everywhere. One program actually telnets to a server to start their own server-side component and then send XML to it. So we have to have an account for the server-side component, put the password in plain text on the client side, and maintain *telnet* for the application. Have we never heard of, say, CGI, people???


• Overuse of root. Again, I've seen this even in documentation -- "run everything as root" or "if you have trouble, just run this as root." I've seen installers actually check to see if they're running as root, and fail if they're not, even though they have no need for root privileges.

Sigh. Although I've seen some poor code out there in the Free Software community, I've never seen anything that even approaches this level of insanity.

Why is the most expensive software the least secure? And what can we do about it when the vendor doesn't care?