Linux

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.