The Advisory Boar

By Abhijit Menon-Sen <>

Installing CentOS 5.3 remotely


While moving a client's moderately complex mail and web setup to a new machine, I discovered that it ran an older version of CentOS than the existing server (4.8 vs. 5). I got all the relevant software installed, but major-version differences in packages like Apache and MySQL made me feel less than confident about putting the result into production right away.

The client and I agreed that it would be best to run CentOS 5.x on the new server, so I started looking for a way to upgrade. GigeNET support suggested “yum update” and “yum upgrade -y”, but those commands are analogous to Debian's “apt-get upgrade” and I wanted something like “apt-get dist-upgrade”. In fact, there doesn't seem to be any recommended way to remotely upgrade CentOS. Fair enough. I wouldn't want to mess with a running server either, but this was a special case.

After a little research, I found this blog post about remotely reinstalling CentOS by booting the PXE installer images via grub and connecting to the running installer using VNC. It sounded promising, if a bit risky. I decided to try it, based on an endorsement of the method by #centos, because I saw no other realistic options. The crux of the technique is to boot from an entry like the following in /boot/grub/menu.lst:

title CentOS installer
    root (hd0,0)
    initrd /initrd-pxe
    kernel /vmlinuz-pxe vnc vncpassword=whatever headless ip=A.B.C.D netmask=N.N.N.N gateway=N.N.N.N dns=N.N.N.N ksdevice=eth0 method= lang=en_US keymap=us

The server took forever to come up after I rebooted (I suspect that it runs a slow self-test on 4GB of RAM, and I foresee many panic-filled moments in my future in which I wonder if the machine is ever going to come back up), but I was able to connect to it afterwards using a VNC client (xvnc4viewer, which I installed while waiting). To my surprise, the entire experience was quite pleasant. The installer was much more responsive than I had expected based on my experience, many years ago, of remotely installing Oracle 8i using the (then shiny new) Java installer via X forwarded over SSH on a 14.4k PPP link. I grabbed a quick nap while the installer downloaded packages.

When I woke up, the installer had reached the "Click Reboot to finish installation" stage, but the VNC session was unresponsive because my PPPoE link went down and came back up with a different IP sometime during the night. I restarted xvncviewer, but it claimed the server was in use (even after an hour) and wouldn't let me reconnect. I took a chance and rebooted the server using the hosting provider's web-based administration interface, hoping that the installer wasn't lying about having no more work to do.

After another heart-stopping wait, however, the shiny new CentOS 5.3 server came up just fine.

Virtual hosting with Ejabberd


I have been running Ejabberd from the default Debian packages on for some time now, with just enough bells and whistles to serve my own rather modest needs. Recently, some friends asked me if I would serve Jabber for their domains too, and I was pleased to find that relatively easy to do.

Let's suppose I want to serve The first step is to add to the list of hostnames in ejabberd.cfg:

{hosts, ["", ""]}

Next, I have to restart Ejabberd to make it accept the new hostname.

Then I use ejabberdctl to register the new JID, while soothing irate users whose connection to the server was dropped during the previous step, and wishing that the server could just accept arbitrary hostnames in JIDs and do the necessary magic internally without needing to be restarted.

ejabberdctl register foo somepassword

Now the new user should be able to login to the server using their favourite Jabber client.

Finally, the following SRV records must be added to the zone in order to delegate XMPP/Jabber service to my server.      SRV 0 0 5222 SRV 0 0 5222 SRV 0 0 5269

Once the world can see these records, anyone trying to contact someone at will talk to my server (that is, unless it is an unpatched Net::XMPP client).

Life with two PPP links


We have DSL service from two ISPs: MTNL (purchased in 2006, when they were the only provider in the area) and Airtel (purchased in 2009 during a week-long outage on the MTNL line). By coincidence, both ISPs gave us UT Starcom UT-304R2 modems (but with different packaging and firmware); these are configured as bridges, and I have two PPPoE interfaces set up on my Linux gateway.

I used to let pppd set a default route through whichever link happened to come up first at boot, and would switch the route by hand when that link went down. That strategy proved remarkably short-sighted when I found myself unable to access my home network from the outside because the gateway lacked a functioning default route. Last weekend, I spent a few minutes making sure I wouldn't be left stranded ever again. Here's a quick summary.

When a PPP link is established, I want to add a default route through it if there isn't a default route already. When a link goes down and takes the default route with it, I want to switch the route to the other link. (If both links are down, there's nothing to do but wait for one to come up and establish a new default route). In both cases, I want to do a dynamic DNS update when I add a new default route. To this end, I created a /etc/ppp/defaultroute script.



# If there's a default route, exit.
/sbin/ip route list|grep -q "^default " && exit

# If we can't establish a new default route, exit.
/sbin/ip route add default dev $IF || exit

/etc/ppp/dynamic-dns $IF

On my Ubuntu system, pppd(8) runs /etc/ppp/ip-up and /etc/ppp/ip-down after a PPP link is brought up or torn down and they, in turn, run the scripts in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d respectively, with the interface name as the first argument. I told pppd to keep its hands off the default route ("nodefaultroute" in /etc/ppp/options) and created /etc/ppp/ip-up.d/00link and /etc/ppp/ip-down.d/00link to call my script.

/etc/ppp/defaultroute $1

if [ $1 = "ppp0" ]; then

/etc/ppp/defaultroute $OF

(It's worth noting that ip-down.d/00link is called when the interface is already down, so no "does the default route point to us?" test is necessary. If it did, the route went down with the interface.)

Someday I will set up policy routing so that I can use both links together. But, for now, I am satisfied with having the correct default route set without my intervention.

OpenWRT and DD-WRT on the Linksys WAP54G 3.1


We bought a Linksys WAP54G "Wireless-G Access Point" in August 2008.

This flat blue-and-grey device is a basic 802.11b/g access point with a single Ethernet port and little besides: two adjustable rear antennae and a front panel with some blinking lights. A sticker below the panel says "Model No: WAP54G ver 3.1", and it shipped with firmware version 3.05, dated 2005-12-28. It has a 200MHz Broadcom BCM5352 CPU, 4MB of Flash memory, and 8MB of RAM.

This page is about my experience with installing, using, hating, breaking, bricking, reviving, and reconfiguring this device.

Read more…

PostgreSQL Installation Guide


Update, 2009-05-10 This page is meant for PostgreSQL 7.4.x, which is now ancient (8.3 being the current version, with 8.4 in beta). These instructions may still help you get an idea of what is needed, but some details will certainly vary.

This web page is meant to help you to set up PostgreSQL for the first time. It tries to focus on important steps in the process, to complement the level of detail in the Postgres documentation.

Read more…

Eeebuntu on the Asus EeePC 4G


We bought an Asus EeePC 4G (701) in October 2008 as an inexpensive, temporary replacement for my beloved Lifebook, whose motherboard had died some months ago, after nearly five years of none-too-gentle use.

The machine came with a customised version of Xandros installed. It was much better than I had expected. It booted extremely fast, and gave me access to an xterm. That, and the fact that other EeePC distributions all had one problem or the other, was enough to keep me using it for some months.

The one big problem I had was with the package repositories. I followed various instructions (which I no longer remember), but a couple of hours wasn't enough to get vim installed, and I gave up. This inability to install things kept annoying me at inopportune moments.

Eventually, I decided to install an Ubuntu derivative. This page is all about my (surprisingly pleasant) experience.

Read more…

Hosting at Hetzner.DE


In July 2005, I ordered a "root server" at Hetzner.DE, to host mail, web, and DNS services for myself and a few friends. I used that machine for five years, then retired and replaced it with a new Hetzner server. This is a brief summary of my experience.

Read more…

Managing DNS (from Red Hat Linux 7.2 Unleashed)


This chapter was commissioned by SAMS Publishing for "Red Hat Linux 7.2 Unleashed" in 2001. They graciously allowed me to reproduce the text here (with minor changes to the original).

Read more…