More nails in the coffin of big, proprietary systems.

While I was going through the backlog of unread stuff in my feedreader, I came across two interesting items that I see as quasi-related. The first is a blog post from Allan Packer entitled “Are Proprietary Databased Doomed?”. In the post, Allan talks about a number of reasons why the big proprietary databases from vendors like Oracle, IBM, and Microsoft are doomed, which basically boils down to (IMHO) to 2 big things:

  • Proprietary databases are more expensive
  • Open source databases have gotten “good enough” to be feature equivalent to the more expensive databases for 80-90% of uses.

The second item that caught my eye was an article about the NYSE’s decision to replace it’s proprietary Unix server with commodity X86 servers running Linux.

What’s interesting to me about these two articles juxtaposed together is that, although they’re talking about two different product categories, databases in one case, operating systems in the other, the arguments in each case are virtually interchangeable. And in both cases, they paint a pretty bleak picture for the future of big, expensive, proprietary systems.

Software installation on Linux Desktops

There was a discussion today on Slashdot entitled “The Future of Packaging Software in Linux”, which was actually more about the future of installing software on Linux desktops.  As usual for Slashdot, most of the participants missed the real problem with the current state of installing software on Linux.  The problem isn’t whether apt is better than yum, how many packages are in each distributions repository, etc.

The problem is the whole idea of having to rely on a repository at all.  No matter how good the repository (or network of repositories), it still means that someone is setup as a gatekeeper between the user and the software they want.

Upstream proxy authentication with squid

Thanks to this hint Macosxhints.com, I’ve finally found a way to get programs that don’t support proxy authentication (like Ruby’s Gem, Perl’s CPAN, etc) to work behind the authenticating proxy at work. The article is for MacosX, but it works just as well under Linux. The short summary is that you can install a local Squid proxy, then configure Squid to forward all request to the upstream proxy. Squid handles the authentication, just configure your applications to use the local Squid proxy (without authentication). I tried it this evening with Gem, and it works great!

One caveat: This works with proxies that use HTTP basic authentication, I don’t think it’ll work with NTLM authentication (MS-Proxy).

How to activate and de-activate a scsi drive under Linux

I came across these commands because I wanted to add a new drive (not replace, add) to a Linux system that has hot-swap scsi drives. When I put the new drive in the OS couldn’t see it. I finally found out the command below to “activate” the drive so that you can use it.

Activate the drive:

echo "scsi add-single-device    " > /proc/scsi/scsi

for example:

echo "scsi add-single-device 0 00 01 00" > /proc/scsi/scsi

Deactivate the drive:

echo "scsi remove-single-device    " /proc/scsi/scsi

for example:

echo "scsi remove-single-device 0 0 1 0" /proc/scsi/scsi

See what drives are active:

cat /proc/scsi/scsi
for example:
[root@hostname root]# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: COMPAQ   Model: MAB3091SC        Rev: 0814
  Type:   Direct-Access                    ANSI SCSI revision: 02

Remote Upgrading Redhat Servers

I’ve figured out a decent way to remotely upgrade Redhat/Fedora systems without requiring anyone to physically touch the remote system (ie, no boot disk, etc). I came up with this procedure to upgrade some DNS servers at work. They’re in several different cities, and any on site support staff is usually busy with their own work, and seldom have any Linux knowledge.

I’ve tested this procedure upgrading several different versions of Redhat to Fedora Core2:

1) Mirror all of the files from the the Fedora CD (or appropriate directory of the Fedora FTP site) to a local file server. Share those file via anonymous FTP.

2) The files used to boot the version of linux for the installer are in the directory /isolinux of the install tree. Copy the kernel file (vmlinuz) and the initial ramdisk (initrd.img) to the /boot directory of the target machine (the one you’ll be trying to upgrade).

3) create a kickstart file to automate the upgrade. The kickstart file is necessary to tell the install program (anaconda) where to find the RPMS, whether to use DHCP, etc. Copy the kickstart file to the /boot directory of the target machine.
A sample kickstart file can be found here.

4) edit the /etc/grub.conf file on the target machine to tell it to boot from the kernel and initial ramdisk that we copied from the install media. The lines to append to grub.conf will look something like this:

title Upgrade
root (hd0,0)
kernel /boot/upgrade-vmlinuz ks=hd:hda1:/boot/ks.cfg vnc vncconnect= ramdisk_size=8192
initrd /boot/upgrade-initrd.img

In the above example, I copied the vmlinuz file to /boot/upgrade-vmlinuz and the initrd.img to /boot/upgrade-initrd.img. I’ve also passing some command line arguments to the kernel that will be passed to the install program. The first of these, “ks=hd:hda1:/boot/ks.cfg” tells the installer to load our kickstart file from /boot/ks.cfg on hard drive partition hda1. The commands “vnc vncconnect=” tells the installer to use VNC to connect back to my workstation to display the progress of the installation. This part isn’t strictly necessary, but I find it handy to be able to watch the progress of the install. It’ll also allow you to see a lot of possible errors (like not enough diskspace). The ramdisk command may or may not be necessary. I read some newsgroup postings that recommended it.

5) Tell grub to use the “Upgrade” config we just created at the next reboot. The grub boot configurations are numbered from the top of the config to the bottom, starting at 0. So if our config is the second one in the file, it would be config #1. Enter the grub command line by typing “grub”. Then at the grub prompt type “savedefault –default=1 –once” substituting the appropriate grub config number for 1. This tells grub to boot our new config, config #1, as the default on the next reboot, but *to return to the old default for every reboot after that*! This is important, because it means that if the installer has problems (maybe our kickstart is fubarred?) we can reboot back to our original config.

On older versions of Redhat you may get an error message from grub when you type the above command. The “–once” option to savedefault seems to be a patch that Redhat has applied to grub in their more recent distributions. If you’re using an older distribution, you may need to compile and install a more recent grub. I’ve recompiled the latest Fedora grub to work on Redhat 7.2, it may work on other versions. If you want to try it, you can download it here. Install it with “rpm -U grub-0.94-5.i386.rpm”, then run “grub-install “, ie. “grub-install hda”.

6) Start the vncviewer on your workstation “vncviewer –listen”.

7) Reboot the server. Wait nervously for it to connect to your VNC viewer.

LVM and upgrading to Fedora Core 2

If you’re running the Linux LVM (Logical Volume Manager) and planning to upgrade to Fedora Core 2, I found a couple of caveats to watch out for.

First, LVM allows you to make physical volumes out of hard drive partitions or out of a whole hard drive. Make sure your physical volumes are all partitions. I tried upgrading a machine this morning that had a whole disk as one of its physical volumes. The Fedora Core 2 install program, Anaconda, complained that it couldn’t read the partition table on the drive.

Second, in your /etc/fstab file, specify any logical volumes by full path name (ie. /dev/vg1/var) and not by label (ie. LABEL=/var). Otherwise Anaconda can’t seem to find the volume to mount it. Note that volume labels work fine for normal partitions, just not for LVM volumes.