Archive for April, 2008

Zeroshell: network services distro

I love it when, almost by chance, I find something new. I decided yesterday to look at FLOSS-based router distributions. I’ve been using IPCop for a while, as an easy way to create a VPN to another location. Unfortunately, IPCop failed my latest requirement: 802.1Q VLAN support. So I went surfing and found an absolute ripper in Zeroshell, but I didn’t find him straight away…

First I found pfSense, a FreeBSD-based distro that seemed to fit the bill–indeed the very first question the Live-CD asked me on bootup was “do you want to use VLANs?”. It also promised a very extensive set of additional packages that extend it’s capability into areas like file/print, WWW proxying, and a host of other features. However, even though it has a very nice web-based configuration facility, due to what looks like a problem on their web site I was unable to even look at what packages are available. Since some of the basic function I would like is provided by these packages, I’ve had to move on–but pfSense gets an honourable mention because of its easy installation and excellent configuration interface.

I looked again at Smoothwall, but soon remembered why I discounted it at the time I chose IPCop. For me, the level of function I think I’d use is a bit too close to the threshold of function in the “community” (read, “free”) version. Astaro would go in this category too, except that I was too dense to be able to even find much clear information about the level of function you get in their community version. So no recommendation on either of these, as I’ve never used either–I do work with a fellow who happily uses Smoothwall though.

Then, I came across Zeroshell. The lead developer describes it as “a small Linux distribution for servers and embedded devices aimed at providing the main network services a LAN requires”. And does it ever! It’s a veritable Alladin’s Cave of features and functions. It certainly does everything I was looking for, from VLAN tagging through QoS to VPNs, from an SPI firewall to multi-zone DNS and multi-subnet DHCP servers, but also has Certificate Management (using a self-signed CA certificate or one you import), a RADIUS server, WiFi access-point capability with multiple SSID and VLAN mapping, captive portal or “normal” HTTP proxying, 802.1d bridging, clients for Dynamic DNS, a Kerberos 5 server, plus a raft of other capabilities. Zeroshell–named because the author wanted to provide a system that was extremely flexible and powerful yet did not require users to access a shell prompt–is remarkably feature rich, and yet the download for the ISO image is only around 100MB (a bit beefier than pfSense, admittedly, which weighed in at around 60MB).

There are a couple of downsides, however. Until very recently, installing to a hard disk was not supported. The distro is designed to boot from a CD only, but can use an installed hard disk (if available) for what it calls “databases”, where configuration and other data is kept. With the latest release, however, the developers have created a “1GB USB drive” download (the size of the download isn’t 1GB), which is designed to be copied to a USB pendrive or hard disk.

The other downside (and it’s not fair to say that, as will become clear) is the web interface. Not because it’s ugly or not functional: it is neither of those. It’s clean and well laid out, and fairly consistent. It’s very technical, however. Where other distros tackle the “SOHO divide” by hiding details such as protocol numbers or port ranges, Zeroshell uncovers all this stuff in its gory detail. So it’s great for someone like me, who looks at the interfaces on other systems and pines for the knobs I can’t fiddle with, but it’s not for newcomers.

It looks to be a fairly new project (current release is 1.0beta9), but the forums look good and there does seem to be a bit of activity around it. I’m running Zeroshell in a VMware guest at the moment while I kick the tyres–the VMware download is also available from the project’s mirrors–but I reckon this one will be a keeper!

Tags: ,

ORDB: "If I go down, I’ll bring you down with me"

Okay, I’m sure it’s not really like that. I’m ashamed to admit this one bit me, though: ORDB, which 16 months ago called it quits but has still been online and more-or-less functional, decided last week to false-positive all queries (a mailing list thread on the issue can be seen here. Harsh, but fair–I do stuff-all email through this site but it still has been costing someone bandwidth to bounce my silly queries back to me. Multiply that up by all the part-time-sysadmins like me that don’t pay close-enough attention, follow old wiki articles, or get bad advice, and pretty soon you’re talking about a HEAP of bandwidth wasted to NOT provide a service any more. Shame it had to end like this though.

MythTV fun and games

Bad things don’t always come in threes. For my MythTV setup, four bad things all happened at once. First was that the governments of the Australian states that run Daylight Savings Time (DST) decided to jump on the energy-saving bandwagon and change the end-time for DST this year. Second was that the OzTivo folks changed the API for connecting to their program guide data, and closed the old API interface on the same weekend that DST was originally due to finish. Third, for some reason that I’m still investigating, my run-an-emerge-world-at-least-every-fortnight MythTV backend had an old timezone-data package, so any times it handled that should have still been DST weren’t. Fourth, Shepherd isn’t quite as smart as I thought it was, and I didn’t find out until too late…

Let me get something straight: Shepherd is the bees-knees of EPG grabbers for Australian MythTV users. If you’re a MythTV user in .au and not running Shepherd, stop reading this right now and go and update your system to use it–you’ll be glad you did. If I had just looked at some of the output it has been generating since OzTivo announced it’s changes, most of the agro I’ve suffered the last few hours would have been avoided.

In a nutshell, Shepherd is a “meta-grabber”. It includes code that can get program data from a dozen or so sources, and keeps looking up sources until it fills your listings with data goodness. It automatically updates these individual source grabbers as well, so you should never need to worry about its up-to-date-ness (more on that later though). It also fetches extra program data from IMDB and TVDB, and can even automatically grab station icons for you. Highly, highly recommended.

I could see that some of my EPG data was coming from OzTivo because I had seen the notes that they had put in the program data advising of the API change. The weird thing I saw was that for a program I was recording in the same timeslot each day, sometimes the message would be there and other times not. While I thought that this was a little strange, I figured that the OzTivo folks were just being overly cautious and trusted Shepherd to do all the updates it needed.

Then, ever since Sunday morning when the southern states *didn’t* switch back from DST, I’ve had recording times out by an hour–programs trying to record an hour early. So as I mentioned, I had ye-olde timezone data on the backend, which can’t have helped depending on the data source (although I’m trying to work out if this actually is a contributor as I would have thought it would send the recordings an hour late… plus, others who have confirmed their timezone data have had the same problems). For a couple of programs, I actually had double entries: one an hour too early, then a second one at the right time. This was weird, and I still can’t explain it!

A manual run of mythfilldatabase showed why I was getting the repeated OzTivo API messages. Shepherd had downloaded the updated grabber alright, but the new version has a Perl dependency that wasn’t satisfied and it couldn’t run. Rather than bail out, Shepherd elected just to keep running with the old grabber. Given the circumstances, I’m still deciding how I feel about that. :-

So once I was confident that the grabbers were working okay again, I decided to get the EPG straight. I remembered that mythfilldatabase will not replace any existing data it thinks is valid, which is why only data post-April-5-or-so looked nice again. So, with a mailing list post or two as encouragement, I truncated (database-admin-speak for “deleted all the data from”) the “program” and “programrating” fields in the mythconverg database and ran mythfilldatabase. After about 20 minutes, voila, fixed guide data!

So now I’m thinking of how I can alert myself to a problem with Shepherd. I used to just check the result of the last mythfilldatabase run through Information Centre or mythweb, but since Shepherd ends cleanly so does mythfilldatabase. Looks like I might have to come up with something hackish to look for Perl runtime errors in the mythfilldatabase log and do a Nagios passive service check or something… Sigh, as if I needed another little project to keep me busy… :)

Tags: