I noted in an earlier post that Linksys were ceasing production of the NSLU2. There are now a variety of NAS systems coming onto the market which might make good replacements – but most of them look expensive when compared to the slug. However I’ve just seen a review of a box which looks as if it might be just up my street – the oddly named CherryPal PC, based on Freescale’s MPC5121e mobileGT processor.

The specs look very interesting – indeed, if the press release at Marketwatch.com is to be believed, the box has “256GB of DDR2 DRAM” to go with the 800 MIPS Freescale’s MPC5121e processor.

Methinks this may be a typo.

An apt-get dist-upgrade (to bring the kernel up to date and install some new patches) on the slugs killed the webcam. Of course I should have remembered that the gspca module was built against the old kernel and might fail. One quick “m-a auto-install gspca” later and all is working again.

Of course the kernel update required a reboot so my uptime is now back to zero, but security is more important than a long running time.

Jim Buzbee, of batbox fame and one of the original NSLU2 hackers, apparently gave a presentation about the history of slug hacking at the Boulder Linux Users Group. A PDF copy of his presentation can be found on his batbox.org site.

Jim also notes that Linkys are ending production of the NSLU2 after four years of life. Better get your hands on a few now before they all disappear – or end up at twice the price on ebay.

You could regard this as another pointless entry to go alongside the webcam. But hey – so what.

I had cause to check the uptime on my slugs a little while ago now that they are largely stable and providing the services I want. After doing so I thought it would be good to be able to check this from a web page and a short search later came across Matthew Trent’s UD daemon. I’ve now made my webcam slug uptime public. Let’s see how high this will get.

I have written about how I use one of my slugs to backup my internal files via rsync over ssh. Well it turns out I made a pretty silly mistake in my rsync options. I thought I’d been careful in specifying the files I specifically wanted excluded from the backup (ephemeral stuff, thumbnail images, some caches such as my browser cache etc.) but I missed one crucial directory and it bit me – and sent the slug’s load average through the roof.

GNOME 2.22 introduced GVFS, a new network-transparent virtual filesystem layer. GVFS is a userspace virtual file system with backends for protocols like SFTP and FTP. GVFS creates a (hidden) directory called .gvfs in your home directory and uses this as a mount point when you open a connection via SSH, FTP, SMB, WebDAV etc from the “Places -> Connect to Server” menu option. So if you open an SFTP connection to a server called “slug”, it will mount that connection in .gvfs. Try it yourself.

Now guess what I had mounted on my desktop at the time my rsync cron job ran. The slug spent some frantic time copying itself to itself until I noticed that it seemed to be inordinately busy, diagnosed the problem and managed to kill the rsync and clear up the mess.

Sadly it appears that the once useful linuxdoc.org website has been hijacked by one of those awful domain squatters who seem to want to sell mortgages, holidays and houses. I tried today to check out an old “howto” I had bookmarked and was greeted by a completely new site – as below:

At first I thought that they had simply redesigned the site because most of the links appeared to be in place. Unfortunately, none of the old LDP documents appear to be there. I also noticed that all the links are referred to a new site on www.kolmic.com. So, none of my old linuxdoc bookmarks are any use now. RIP friend.

Fortunately, however, the original and best TLDP site is still up and running as is the (similarly named) linuxdocs.org site. So, update your bookmarks and stay away from the hijacker. Such a shame that so many printed references in places like the O’Reilly books are no longer valid.

A recent email exchange with the friend who originally suggested that I take a look at the NSLU2 got me thinking about the machines we currently take for granted. In his email he outlined that he had consolidated a set of services previously run on a couple of old desktops (a Dell and a Shuttle) onto his slug – thereby making a big saving in power consumption. His slug now runs ssh, DNS, IMAP and SMTP mail and a couple of other services – a typical slug user’s profile. The phrase that got me thinking however, was his statement that “I’m quite amazed that it can do all this within 32MB memory”.

Now, not so long ago, 32 Meg of RAM was considered quite a lot. We seem to have become so used to desktop home machines equipped with multi GHz CPUs, 2 or 3 Gig of RAM and anywhere from 160 Gig to three quarters of a terabyte of disk that we are surprised that an apparently humble 266 MHz, 32 Mb RAM machine can do so much. But why? As recently as 10 years ago I was running a large public facing network on which the main DNS/mail and syslog server was a single processor Sun SPARC5 with only 32Mb of RAM. And I recall only 15 years ago (OK, so I’m old) running a network of ICL DRS 6000s providing full office system functions to over 1200 users. So I dug out the specs of the machines I was running at that time for comparison. It made interesting reading.

The smallest (in capacity terms) machine on my network 15 years ago was a DRS6000 L440 – which had a single 40 MHz CPU, 32 Mb of RAM and 2 x 660 Mb disks. That machine served 30 users. I also had a mixture of DRS6000s with older 25Mhz and 33MHz CPUs but with more RAM and disk store (typically 96 Mb and 4 x 660 Mb disks) each of those would support around a hundred users (the office application was memory not CPU dependent). The really interesting point is the pricing. I found a note with the following on it:

Item — Price (UKP)

DRS6000 L440 40MHz CPU — £15,000
(inc. 1 * 660 Mb disk)

64 Mb memory board — £11,000

32 Mb memory board — £6.550

SCSI daughter board — £800
(to support additional disks)

3 * 660 MB disks — £8,850

16 port asynch controller board — £1,500

ethernet LAN controller board — £2,660

external exabyte tape drive — £4,000

console and keyboard — £500

sundry cables — £200

hardware sub-total — £51,060

to which I had to add:

128 user licence for Unix 6, TCP and OSLAN — £11,000

(Thankfully, we had a site licence for the application software…)

So, for just over £62,000 I had a 40 MHz machine with 96Mb of RAM and 2.6 Gig of disk. Not bad.

Oh, I forgot VAT.

I bought myself another slug recently so that I could have one dedicated to internal work and the other used for public facing webs. I wasn’t really comfortable with having my network backup and apt-get mirror on the same beast as a public web. I know from experience that public facing systems are vulnerable and I have to assume that my webcam slug is disposable.

However, it seems that I picked exactly the wrong time to build a new slug because I fell foul of a previously undocumented bug in the new initramfs-tools (version 0.92) in Debian testing. This version generated a ramdisk that made the slug unbootable. This bug was particularly irritating because it only manifested itself at the end of the complete Debian install – i.e at the point when the installer had flashed the new initramfs and rebooted. Because I had been so successful with the earlier slug only weeks before, I thought at first that either I had made a mistake, or, worse, I had bought a problem slug which I could not return having voided the warranty. So I wasted some more time reflashing first with unslung and later with the original Linksys image – just to satify myself that I had a working beast. Then I checked the debian-arm mailing list. A couple of other users reported similar problems and the cuplprit – initramfs-tools – was quickly identified and rapidly fixed (see bug #478236).

When researching the problem, I picked up a useful tip from the mail list on a quick way of backing up a working slug image which is not documented in the how-to section of the slug website. This tip enabled me to take a copy of the image from the known good working slug and flash it to the non-working new slug at the end of (yet another) complete Debian install.

On a working system, do “cat /dev/mtdblock* > backup.img”, and copy that backup image off to a safe place. Use that image with upslug2 to flash to a non-working (or corrupted) slug thus: “upslug2 -i backup.img”.

The problem I encountered is now fixed with the release of 0.92a of initramfs-tools which is now in the Lenny tree.

Following a recommendation from a friend of mine, I have recently been playing with a Linksys NSLU2. This device is no larger than a paperback book yet packs some remarkable capabilities. It was originally designed by Linksys (Cisco) to act as a “Network Storage Link for USB 2.0 Disk Drives” (hence NSLU2).

Externally, the rear of the box offers two USB 2.0 ports and a 10/100 ethernet RJ45 port for connectivity and sports front panel based LEDs for power, disk and ethernet status. Internally it has an XScale-IXP42x CPU (Intel’s implementation of ARM) running at 266 MHz (early versions were apparently underclocked to 133 Mhz) 8Mb of flash memory and 32Mb of SDRAM. Most interesting, at least from my point of view, is that the OS in flash is a version of Linux. Better yet, that can be changed for a full blown OS such as Debian so long as that OS is installed to external disk and the NSLU2 firmware is reflashed with an image which tells it to look for a bootable kernel on disk. Too good an opportunity to be missed – so I bought one and attached a 500 Gig Lacie USB disk so that I’d have room to play.

There is extensive documentation on-line about reflashing and upgrading the slug (as they are affectionately known by their users). My experience is documented here. My own slug now runs Debian Lenny (kernel 2.6.24-1-ixp4xx) and acts as the local apt-mirror for my home network. That mirror is run out of cron overnight so that I save on my bandwidth allowance. Having a local mirror speeds up software installs and security updates and I know that I can run local downloads to any of my machines at any time without impacting on either my monthly allowance or my external access speed. The slug runs lighttpd (changed from Apache) to give me internal virtual webservers as well as access to the mirror and I also backup my internal files to it via rsync over ssh. For example, my primary desktop machine runs a cron job to rsync to the slug.

Oh, and it also runs a webcam – just for fun.

A web search for “webcam on slug” led me to the deliciously bizarre “Slug Racing online” site. Quote – “Slug racing is an exciting and cheap alternative to other racing forms. Slugs are available almost everywhere, often in abundance. Seen as a pest by many people, they can be a great pleasure in cultivated slug racing.” Unquote.

Some people have the strangest hobbies.

A google search for “loadlin” produces a sponsored link for “Inflatable lilos”. Strangely no references to insects or food however.