Saving Effort and Time is Hard Work

As both my regular readers well know, I've been using a couple of Macs1 as my main systems for some time now. As many (if not most, these days) Web developers do, I run different systems (Windows and a raft of Linuxes) using VMWare Fusion so that I can do various testing activities.

Many Linux distributions come with some form of automation support for installation and updates2. Several of these use the (generally excellent) Red Hat Anaconda installer and its automation scheme, Kickstart. Red Hat and the user community offer copious, free documentation to help the new-to-automation system administrator get started.

If you're doing a relatively plain-vanilla installation, this is trivially easy. After installing a new Fedora system (image), for example, there is a file named anaconda-ks.cfg in the root user's home directory, which can be used to either replay the just-completed installation or as a basis for further customisation. To reuse, save the file to a USB key or to a suitable location on your local network, and you can replay the installation at will.

Customising the installation further, naturally, takes significant additional effort — almost as "significant" as the effort required to do the same level of customisation manually during installation. The saving grace, of course, is that this only needs to be done once for a given version of a given distribution. Some relatively minor tinkering will be needed to move from one version to another (say, Fedora 13 to 14), and an unknowable-in-advance amount of effort needed to adapt the Kickstart configuration to a new, different distribution (such as Mandriva), since packages on offer as well as package names themselves can vary between distros3.

It's almost enough to make me pull both remaining hairs out. For several years, I have had a manual installation procedure for Fedora documented on my internal Wiki. That process, however, leaves something to be desired, mainly because it is an intermixture of manual steps and small shell scripts that install and configure various bits and pieces. Having a fire-and-forget system like Kickstart (that could then be adapted to other distributions as well), is an extremely seductive idea.

It doesn't help that the Kickstart Configurator on Fedora 13, which provides a (relatively) easy-to-use GUI for configuring and specifying the contents of a Kickstart configuration file, works inconsistently. Using the default GNOME desktop environment, one of my two Fedora VMs fails to display the application menu, which is used for tasks such as loading and saving configuration files. Under the alternate (for Fedora) KDE desktop, the menu appears and functions correctly.

One of the things I might get around to eventually is to write an alternative automated-installation-configuration utility. Being able to install a common set of packages across RPM-based (Red Hat-style) Linuxes such as Fedora, Mandriva and CentOS as well as Debian and its derivatives (like Ubuntu), and maybe one or two others besides, would be a Very Handy Thing to Have™.

That is, once I scavenge enough pet-project time to do it, of course. For now, it's back to the nuances of Kickstart.

Footnotes:

1. an iMac and a MacBook Pro. (Return)

2. Microsoft offer this for Windows, of course, but they only support Vista SP1, Windows 7 and Windows Server 2008. No XP. Oops. (Return)

3. Jargon. The term distro is commonly used by Linux professionals and enthusiasts as an abbreviation for "distribution"; a collection of GNU and other tools and applications built on top of the Linux kernel. (Return)

Protecting Yourself and Others from Yourself and Others

Nowadays, there's simply no excuse for any computer connected to the Internet, regardless of operating system, not to have both a hardware firewall (usually implemented in your router/broadband "modem") and a software firewall, monitoring both incoming and outgoing traffic.

The software firewall I've been recommending to those "unable"/unwilling to leave the hypersonic train wreck that is Windows has been ZoneAlarm's free firewall. Users of modern operating systems should start off by enabling and configuring the firewall built into their OS (either ipfw on Mac OS X/BSD Unix, or netfilter for Linux). That can be tricky to manage; fortunately there are several good "front end" helper packages out there, such as WaterRoof. Another excellent, popular Mac tool is Little Snitch; the latter two work quite well together.

However, no matter which tools you use to secure your system's Net connection, one of the main threats to continued secure, reliable operation remains you, the user. This has a habit of popping up in unexpected but obvious-in-hindsight ways.

For instance, I recently changed my Web/email hosting service. Long prior to doing so, I had defined a pair of ipfw rules that basically said "Allow outgoing SMTP (mail-sending) connections to my hosting provider; prevent outgoing mail-sending connections to any other address." Thus, were any of the Windows apps I ran inside a VMware Fusion VM to become compromised (as essentially all Windows PCs in Singapore are), they couldn't flood spam out onto the Net – at least not using normal protocols. This didn't do anything to protect the Net from other people's Windows PCs that might sometimes legitimately connect to my network, but it did ensure that the Windows VM (or anything else) running on the Mac was far less likely to contribute to the problem.

A few days after I made the change, I noticed that my outgoing mail server configured in my email client wasn't changed over to the new provider, so I fixed that. And then, I couldn't send mail anymore. It took an embarrassingly long time (and a search of my personal Wiki) to remember "hey, I blocked all outgoing mail except to (the old provider) in my software firewall." Two minutes later, WaterRoof had told ipfw to change the "allowed" SMTP connection, and I soon heard the "mail sent" tone from my client.

Mea culpa, indeed. But why bother blogging about this? To reinforce these ideas to my reader(s):

1. First, that if you aren't already using a software firewall in addition to the hardware one you probably have (especially if you're not aware of it), you should be. It will make you a better Net citizen; and

2. Use a Wiki, either a hosted one like PBworks or one running on your own system. (I use Dokuwiki; this page on Wikipedia has a list of other packages for the host-it-yourselfer.)

3. Use your Wiki to record things that you'd previously think of writing in a dead-tree notebook or a bajillion Post-it® notes stuck to all available surfaces. This specifically and emphatically includes details of your system configuration(s).

Of course, if using a public, hosted wiki, you'll want to make sure that you can secure pages with sensitive data, like system configurations; why make Andrei Cracker's job easier than it already is?

This whole rant is basically a single case of the age-old warning, "if you don't write it down (in a way that it can be found again at need), it never happened." As the gargantuan information fire-hose that is the Internet continually increases the flow of information as well as increasing the rate of increase, this becomes all the more critical for any of us.

Mac OS X is BSD Unix. Except when it's Different.

One of the things that a BSD Unix admin learns to rely on is the "ports" collection, a cornucopia of packages that can be installed and managed by the particular BSD system's built-in package manager: pkgsrc for NetBSD, pkg_add for FreeBSD, and so on. In nearly all BSD systems, the port/package manager is part of the basic system (akin to APT under Debian Linux).

Mac OS X is BSD Unix "under the hood," specifically Darwin and, indirectly, FreeBSD.

This provides the Mac user who has significant BSD experience with a nice, comfy security blanket. This blanket has a few stray threads, however. One of these is the package-management system and ports.

Software is customarily installed on Mac OS X systems from disk images, or .dmg files. When opened, these files are mounted into the OS X filesystem and appear as volumes, equivalent to "real" disks. The window that the Finder opens for that volume customarily contains an icon for the application to be installed and a shortcut to the Applications folder. Installation usually consists of merely dragging the application icon onto the shortcut (or into any other desired folder). Under the hood, things are slightly more complex, but two points should be borne in mind.

First, there is no true Grand Unified Software Manager in Mac OS that is comparable to APT under Debian Linux, or even the "Add or Remove Programs" item in Microsoft Windows' Control Panel. Uninstalling a program ordinarily consists of dragging the program icon to the Trash or running a program-specific uninstaller (usually found on the installation disk image).

Second, while there is a "ports" implementation for Mac OS X (MacPorts), it isn't a truly native part of the operating system. More seriously, the versions of software ports which are maintained in its ports list are not always the most recent version available from their respective maintainer. Installing an application via MacPorts, installing a newer version through the customary method, and attempting to use MacPorts to maintain the conflated software can quite easily introduce confusing disparities into the system, with potentially destabilizing effect.

Go back and read that last paragraph again, especially the final sentence. Mac OS X, meet BSD Unix. Touch gloves, return to your corners, and wait for the bell.

Most users will never run into any problems, simply because most Mac users make little or no use of MacPorts (or any other command-line-oriented system management tool). MacPorts users are (almost by definition) likely to be experienced Unix admins who pine for the centralized simplicity of their workhorse software-management system. Informal research suggests that many, if not most, MacPorts users are active developers of Unix and/or Mac software. In other words, we're all expected to be grown-ups capable of managing our own systems, trading away the soft, easy-to-use graphical installation for a wider variety of nuts-and-bolts-level packages.

So why is any of this a problem for me? Why am I consuming your precious time (and mine) blathering on about details which most interested people already know, and most who don't, probably aren't? As a bit of a public mea culpa and a warning to others to pay attention when mixing installation models.

I had previously installed version 8.2 of the PostgreSQL database server on my Mac via MacPorts. Returning to it later, I realized that the installation had not completely succeeded: the server was not automatically starting when I booted the system, and the Postres tools were not in my PATH. After a bit of Googling, I came across a few links recommending the PostgreSQL 8.3.6 disk images on the KyngChaos Wiki. The server failed to start as expected.

Remembering that I had previously installed 8.2 the "ports" way, I first uninstalled the newly-installed and -broken 8.3.6. I then ran port uninstall postgresql82 && port clean postgresql82 in an apparently successful attempt to clean up the preexisting mess, after which the KyngChaos disk images installed correctly and (thus far) work properly.

This once again points out the usefulness of keeping a personal system-management Wiki as a catchall for information like this — both to help diagnose future problems, and (especially) to avoid them altogether. These can be dirt simple; I use Dokuwiki, and have for over a year now. Forewarned (especially by yourself) is forearmed, after all.

Just thought I'd get this off my chest.