Posts

Showing posts with the label home server

Yet Another New Home Server

This year has seen me doing more in the way of little tech projects at home than I have done for a while, perhaps due to covid lock downs so if that's the case then I'll take this small positive from an otherwise rubbish situation.  Typically for me, these projects have focused around open source projects and some IoT.  More on those in some separate blog posts when I get around to writing them up.  But for now, I wanted to make some notes on my new home server set up.

I've had an array of different low powered home servers of the years that I've previously written about, namely the NSLU2, TinyTuxBox, Joggler and for the past many years a simple ReadyNAS box that I specifically bought for the Intel processor as it made compiling different bits and pieces a whole lot easier back in the day.  However, I have recently relegated the ReadyNAS box from home serving duties, keeping it only for its native NAS services because using it for other things has become increasingly difficult without updating the entire base OS (which is possible by I'm reluctant to do) due to down level software libraries like an ancient version of openssl.

In with the new then and I moved away from Intel architecture as it's now so much easier to compile for Arm chips and went with the, wait for it, drum roll, rather obvious choice of a Raspberry Pi 4.  Specifically, a Pi 4 Model B, 4GB.  I've paired it with the official Pi case power supply, micro HDMI cable and shoved in an A2  SanDisk Extreme 64GB SDXC card.

And so to the notes, my initial target for this new box would be as follows:

The Lounge

IRC might be a bit old hat but tons of open source project still use it for their more synchronous communications.  ZNC is the choice of old for staying connected to your IRC channels.  For those not familiar, it acts as a relay to the IRC servers you want to connect to.  Effectively, it connects as your IRC client to the servers and presents your local IRC client with an endpoint through which you can connect.  This allows you never to miss any messages and see the IRC conversation even when you're not actually online.  Matrix seems to be taking some of the old IRC community's attention with various projects setting up bridges between Matrix and IRC.  However, the relative newcomer project called The Lounge shows just how far web technologies and web sockets have come.  It's a darned site (pun intended) easier to install configure and use than ZNC so I'm a massive convert and big fan of the project.

The project is relatively stable in the master branch and doesn't release particularly often so I've open for the run from source approach to take advantage of all the latest development.  Other than that, I've only made 3 changes to the default configuration prior to starting up my The Lounge server:
  1. host: "127.0.0.1"
  2. reverseProxy: true
  3. theme: "morning"
As you can see, these are all pretty simple and somewhat trivial changes.  The host setting binds the listener to the localhost interface, thus making it suitable for use with a reverse proxy and not exposing the service outside of the Pi 4.  The reverseProxy setting tells the server it's expecting to run behind a reverse proxy (the clue is in the name I guess).  Finally, I've switched to using a dark mode theme rather than the default light mode.  That's it, the remainder of the configuration is all about which IRC servers and channels to connect to along with the usual IRC bits of registering your nick and logging into the nick server.

Mosquitto

This is even simpler to get going than The Lounge due to the fact it's bundled with Raspbian so you can just apt-get install it.  I've created a configuration based on the bundled example config file but changing:
  1. pid_file (probably just because I'm old fashioned like that)
  2. user (to drop privileges)
  3. listener (to specify a port number)
  4. certfile and keyfile (for SSL)
  5. log_dest (create a specific log file for the broker)
  6. clientid_prefixes (a bit of added security to only allow certain client IDs to connect to the broker)
  7. allow_anonymous (quite an important one!)
  8. password_file (so that connections are authenticated)
Hopefully, that gives me something secure as well as providing me with the broker functionality that I need.

Node Red

Again, simple to install as it's bundled with Raspbian.  It does like to run under the default "pi" user though, which is a bit of a shame security wise.  All I've done to the configuration is ensure it's listening only on the local interface and enable the adminAuth section such that I'm required to enter a user name and password to access the user interface.

NGINX
 
Another simple install due to using the bundled version that comes with Raspbian.  However, this time around there's a lot more configuration to do since I'm using it to front a reverse proxy onto The Lounge and Node Red.  This gives me a few advantages such as being able to restart NGINX in order to load new SSL certificates without interrupting the underlying services i.e. something like IRC can stay connected even though new certs are loaded.  Both The Lounge and Node Red support SSL in their configuration so this also means I only need to configure certificates in one place and have a single route through which I can access all my home services.  The idea and bulk of the configuration for doing this comes directly from one of the guides available for The Lounge.

server {
    # redirect HTTP traffic to HTTPS
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    return 301 https://$host$request_uri;
}

server {
    # SSL configuration
    #
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_certificate /path/to/your/server.crt;
    ssl_certificate_key /path/to/your/server.key;

    server_name your.server.name.com;
 
    # Add this if you want to do web serving as well
    root /var/www/html;
    index index.html index.htm;
 
    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
 
    # Configure reverse proxy for The Lounge
    location ^~ /YOUR_PREFERRED_IRC_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:9000/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }

    # Configure reverse proxy for Node Red
    location ^~ /YOUR_PREFERRED_NODERED_URL_GOES_HERE/ {
        proxy_pass http://127.0.0.1:1880/;
        proxy_http_version 1.1;
        proxy_set_header Connection "upgrade";
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;

        # by default nginx times out connections in one minute
        proxy_read_timeout 1d;
    }
}
 
Let's Encrypt
From Wikipedia: "Let's Encrypt is a non-profit certificate authority run by Internet Security Research Group that provides X.509 certificates for Transport Layer Security encryption at no charge."

The model for using letsencrypt is pretty simple.  They sign your SSL certificates, free of charge, but their signing expires within 90 days.  Hence, they're encouraging a high turnover of certificates by regular renewals.  This means that realistically you need to automate the process of certificate signing.  To do this I'm using the getssl script which makes life extremely easy when coupled with a cron job to kick off the script on a regular basis.  I'm running it every day and the script decides whether to replace my existing certificates.  It all sits there quite nicely running in the background and doesn't get in the way at all, restarting NGINX only when a new certificate is put in place.  Due to the fact that NGINX is decoupled from the services it is proxying the other services aren't interrupted.

Another New Home Server

Those of you following this blog over the past couple of years will know I've already had several low power home servers including an NSLU2, tinytuxbox and Joggler.  The NSLU2 and tinytuxbox are both history but we've still got the Joggler at home.  After finding it was grinding to a halt with the stuff I was running on it while trying to use it interactively it became clear we needed something else at home too.  Since I was also running out of storage space on my home PC a NAS solution seemed like the obvious choice so I went for a Netgear ReadyNAS Ultra Plus 2 (RNDP200U).

I opted for the ReadyNAS Ultra series because I run a SqueezeBox Duet for my music and Netgear are the only partner directly supported by Logitech for their music devices.  After spending huge amounts of time hacking the NSLU2, tinytuxbox and Joggler I felt it was about time I had a device that "just worked" so the option of simply downloading and installing stuff and having it work is really quite attractive.  Of course, other NAS devices can run SqueezeCenter but whether the community supported versions work well and are kept up to date is another matter which I didn't investigate thoroughly.  Another good reason for choosing the Ultra series is they're based on x86 hardware so some of the code and plugins I know I want to run which had previously not worked (or been possible) on the slug for example would be fine, a lot of NAS boxes are still running ARM processors.

The Ultra 2 comes in 2 flavours and I went for the more powerful of the two (the Ultra 2 Plus).  They are exactly the same except the Ultra 2 Plus has a dual core processor vs a single core on the Ultra 2.  Given I'm fully intending to run what is probably more than average on the NAS the chance of getting a more powerful processor was well worth the extra few quid it costs.

On the subject of price, the NAS solution is probably one of the more expensive ways to get yourself a home server.  Again though, the "it just works" factor comes heavily in to play here as I'm not responsible for installing the O.S. and setting up a raft of different services on the box, they're all just there, working!  Probably the most competition for a NAS would be the Asus Revo running Linux, possibly with FreeNAS on it too.  The Revo with the same processor as the Ultra 2 Plus I bought is around 60% of the price.  The Revo isn't able to support the amount of storage you can get with a NAS device though, doesn't (easily) support RAID and if I did want to do those things it would have to be with ugly USB attached disks which are hard to spin down when not in use.

It took just a matter of hours to unpack, boot and setup the device in the way I wanted.  The array has been formatted and exports a share to Linux and Windows boxes, all my data has been copied on there with plenty of room for expansion and user management is sorted.  After that, updating SqueezeCenter to the latest version was simple and installing other additional software (whether official or community supported) is also really easy.  So far I've set up transmission (for bit torrents) and enabled ssh access.  Hardware management is all done through a web interface so the option of automatically powering on/off the device on a schedule or setting up disk spin down is merely just a box tick away.

I've got it connected to a 10/100 switch which is fine for streaming music to the SqueezeBox or sharing pictures with the Joggler but for access from my PC and to large amounts of data I figured that throughput wouldn't be enough.  Fortunately, the NAS has 2 Gigabit Ethernet ports so I've used the second one to direct attach it to my PC and enabled Jumbo frames.  The performance over that link has been absolutely fine whether measured simply by the subjective feel of how long it takes to do certain tasks or via a more rigorous iozone test.

With the tasks of device and software management all taken care of the the thing up and running in no time at all, I'm looking forward to having more time on my hands to do some even more interesting hacking with the box instead.

ReadyNAS Ultra 2 Plus

I recently bought a Netgear ReadyNAS Ultra Plus 2 (RNDP200U) Network Attached Storage (NAS) device and before buying found it hard if not impossible to find out the finer technical details of the hardware specification.  In a similar way to some of my previous posts I thought I'd list out some of the key specs as found under Linux running on the device.

It appears to be running a distribution based from Debian Etch which Netgear have modified to make what they call their Raidiator operating system.  It shipped with Raidiator version 4.2.15 and this is upgradeable when they release new versions.

The kernel version is 2.6.33.7.RNx86_64.2.2 and (surprisingly) is x86_64 rather than the 32 bit OS I would have expected.

The tech specs list the RAM as 1GB DDR2 SODIMM and I can happily report free sees all 1GB available, there's around 500MB of swap space too.

They seem to carve out some sort of virtual storage on the disks you put into the box too.  I've not quite worked this out yet but df reports the following
/dev/md0              4.0G  572M  3.3G  15% /

The CPU is pretty beefy for this type of hardware, Linux sees one processor and two hyperthreaded cores so you get four lots of the following in /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 28
model name : Intel(R) Atom(TM) CPU D525   @ 1.80GHz
stepping : 10
cpu MHz : 1800.215
cache size : 512 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe lahf_lm
bogomips : 3600.43
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

The other hardware in the system is pretty much covered by the output of lspci
Host bridge: Intel Corporation Unknown device
VGA compatible controller: Intel Corporation Unknown device
Display controller: Intel Corporation Unknown device
PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2
PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3
USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1
USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #2
USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #3
USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #4
USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller
PCI bridge: Intel Corporation 82801 Mobile PCI Bridge
ISA bridge: Intel Corporation Unknown device 27bc
SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA Storage Controller AHCI
SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller
Ethernet controller: Marvell Technology Group Ltd. Unknown device 4380
USB Controller: NEC Corporation Unknown device 0194
Ethernet controller: Marvell Technology Group Ltd. Unknown device 4380

The hardware Specs from the ReadyNAS site are

Physical Specifications
Intel® Atom 1.8 GHz Dual-core CPU (Ultra 2 Plus)
1GB DDR2 SODIMM
Two (42) Serial ATA II channels
Hot swappable and lockable trays
Two (2) 10/100/1000 Ethernet ports
One (1) USB 3.0 port
Two (2) USB 2.0 ports
Embedded 128 MB Flash Memory for OS
Kensington Lock security hole
Software controlled 80 mm chassis cooling fan
Dimension (H x W x D): 101 x 142 x 220 mm (3.98 x 5.59 x 8.66 in)
Weight: 2.07 kg (4.56 lb), without hard disks
Electrical
60W External AC power supply
Input: 100-240V AC~ 50-60Hz 5A(Max)
Power Consumption
34W typical with 2 x 2TB disks
32W idle, 19W with disk spin-down
Environmental Compliance
0 to 40 C (32 to 104 F)
20% to 80% Humidity (non-condensing)
FCC, UL, CE, RoHS, C-tick, VCCI, CCC, KCC compliance
Available Configurations
Diskless
Half-populated

Getting a Joggler, the how and the why?

Buying a Joggler is pretty simple, you can just go to the O2 shop and get one for one hundred of our UK pounds, or fifty if it's on sale.  The reason for putting "the how" in this isn't to teach you how to buy stuff on the net.  No no, more to say you can get it for less than fifty quid if you're careful!  Those of us who work for IBM have been buying them through a money saving web site we have access to as IBMers such that you buy the Joggler and a PAYG Mobile Internet USB dongle (which you're not obliged to use) for a total of £60 and get £25 cashback for doing so.  That's £35 for a Joggler and mobile Internet, bargain!  I would think this sort of offer must be out there in the wider world too if you look carefully enough.

So why do I, or you for that matter, want one?  There's lots of different uses for it.  Even if you look at it as a dumb wireless digital photo frame then it's far cheaper than other wifi frames out there.  The neat thing about it is it runs a version of Linux internally, has a USB port and is also capable of booting from USB.  This means you can run pretty much anything you like on there instead of the default O2 interface.  So, it's the ideal hacking toy and can become a fully fledged computer system disguised as a photo frame if you choose to do so.  The sky is the limit.

For me, I use it as a low power home server running:
  • remote login to home (ssh)
  • music streaming (squeezebox server)
  • internet connected photo frame (gphotoframe)
  • trivial internet browsing (chrome + touchscreen addon)
  • file server (nfs, http, ftp, smb, etc as required)
  • backup server (rsync) 

I've also found it very useful to have a computer connected to my printer for wifi print serving from my laptop in the past.  Currently the Joggler isn't located next to my printer so I'm not doing this but it's definitely an option for the future.  Similarly I may eventually reconnect my current cost meter for home power monitoring, sending daily electricity bill via email, graphing and storing stats.  Another use I could put it to is as a WOL client so wake up other machines in the house remotely so I don't leave them powered on all day (not that I do this anyway), but I haven't configured WOL yet.

Not investigated yet but it seems to me it should be possible to run the OpenPeak apps on Linux too.  These are just flash applications so I should be able to run them on the Linux desktop without any issues which would provide me with the same functionality I would get from the original O2 interface under my own Linux.

You can find a lot more of my information about the Joggler at my Joggler Index post. I also have a list of Joggler Bookmarks.

Joggler Index

This post will be kept up to date serving as an ordered index to my notes about the O2 Joggler; essentially a glorified digital picture frame with a touch screen.  All posts will use the joggler tag too but these may appear in any order.

The very brief tech spec is:
  • Intel Atom Z520 with GMA 500 chipset
  • 512MB RAM
  • 1GB Internal Storage (to run the O2 operating system and interface)
  • 7 inch touch screen
  • USB port, audio jack, wired Ethernet and wireless network
I have a list of Joggler bookmarks.

    Byebye Ubuntu, Hello Fedora

    My recent experiments with installing Ubuntu on my little home server came to an end this weekend. I'm working hard to debug problems with my media streamer software, SqueezeCenter. After finding tons of forum posts and various problems with installing SqueezeCenter on Hardy Heron I decided to try another approach so I'm now running Fedora 9 at home instead. Both Hardy and Fedora 9 are supposed to be supported by Slim Devices for their Squeeze-stuff. However, it appears neither of these work but I'll save that rant for another day once I've worked out what's wrong (I have my suspicions about Slim Devices testing against Perl 5.10).

    I'm actually quite relieved to be back in my comfort zone with Fedora at home again. I really enjoyed the experience of playing with Ubuntu but it's just not for me for various reasons...

    I've met quite a few Canonical guys in my professional role and they've all been great; helpful, very approachable and in the case of some, such as Jono Bacon very decent techies too. That's not my experience with non-Canonical Ubuntu contributors though. I found if the Ubuntu documentation (which is excellent for pretty much everything before Hardy Heron right now) failed me, then talking to the community was not a good experience. I found I was met with an abrupt RTFM attitude in most instances, where the assumption of the community is that people asking questions are dumb. Personally, I blame this on the typical Ubuntu user being non-technical where Linux is concerned so I guess the community receive lots of silly questions which must get annoying at times. All that said, I still believe Ubuntu is really important and plays an extremely valuable role in trying to bring Linux to a more mass audience.

    I also found Hardy to be down level in various instances compared with the packages available in Fedora 9. The big one for me here, on my little server, is the OpenChrome drivers for the graphics chipset. Fedora have the version that supports my chipset, but when I asked about inclusion in Ubuntu there was no interest in updating the down level version in their repositories. I also enquired about the broken Via proprietary driver in Ubuntu which resulted in the Via driver being marked for removal! So rather than update the open drivers or fix the package for the proprietary drivers, the response was to remove the proprietary one and not update the open driver which left me in a position of manually maintaining my own graphics driver until the next major Ubuntu release.

    I've used RPM and yum way more than I have deb and apt so I sway towards the former simply through familiarity. Having the chance to play with debs again recently has been great too, there's some nice additional touches you don't get with RPM such as the suggested packages and the ability to remove dependencies installed with a certain package, etc. Ubuntu have done a nice job of packaging this all up with Synaptic too. Aside from those few nice-to-haves I don't really see any other advantages to the Ubuntu system, yum and RPM would do exactly the same job when fronted by Synaptic but as ever in the world of open source having choice and competition is good.

    Hiding root from the general user is a decent idea too, no need for that confusion in a simple desktop environment, and makes it feel a little closer to what people expect from a Windows box.

    Gnome is the desktop of choice for both mainstream Ubuntu and for Fedora so I've been going with that recently instead of my usual choice of KDE. I've been really impressed with Gnome too, for a simple desktop environment it's fantastic but I know if I were to use it every day there would be some features and tools I use regularly under KDE that I would dearly miss. However, I think I've been converted for home use over to Gnome, particularly as KDE is going through turbulent times with their version 4 releases right now. Having everything written in one toolkit is really nice, you can't avoid running GTK and QT apps under KDE but at least under Gnome you have the option of not running QT and sticking with the same look and feel everywhere.

    I hope I managed to stabalise on one distribution soon so SqueezeCenter actually works, I get the feeling that will likely be Fedora 8 in the short term until Slim Devices get their act together for Perl 5.10 if my current thoughts are correct. So for now at least it's goodbye to Ubuntu until the next time I give it a run somewhere.

    What Ubuntu Thinks of a TinyTuxbox

    I've been meaning to log some, I think I'll call it... Linux type stuff, to do with the TinyTuxbox for a while. Here's my attempt to look at what Ubuntu makes of this little box.

    First, the CPU (from /proc/cpuinfo):
    processor : 0
    vendor_id : CentaurHauls
    cpu family : 6
    model : 13
    model name : VIA Eden Processor 500MHz
    stepping : 0
    cpu MHz : 498.706
    cache size : 128 KB
    fdiv_bug : no
    hlt_bug : no
    f00f_bug : no
    coma_bug : no
    fpu : yes
    fpu_exception : yes
    cpuid level : 1
    wp : yes
    flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 xtpr rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
    bogomips : 998.77
    clflush size : 64


    The interestingness here comes from the fact we have a 500MHz Via Eden with 128k cache and just under 1000 bogomips which (although it shouldn't be) is often used as a trivial performance metric of a processor. Next, lets have a look at what's on the PCI bus (courtesy of lspci):
    00:00.0 Host bridge: VIA Technologies, Inc. CX700 Host Bridge (rev 03)
    00:00.1 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
    00:00.2 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
    00:00.3 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
    00:00.4 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
    00:00.7 Host bridge: VIA Technologies, Inc. CX700 Host Bridge
    00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
    00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
    00:0f.0 IDE interface: VIA Technologies, Inc. CX700M2 IDE
    00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
    00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 90)
    00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 90)
    00:11.0 ISA bridge: VIA Technologies, Inc. CX700 PCI to ISA Bridge
    00:11.7 Host bridge: VIA Technologies, Inc. CX700 Internal Module Bus
    00:13.0 PCI bridge: VIA Technologies, Inc. CX700 Host Bridge
    01:00.0 VGA compatible controller: VIA Technologies, Inc. CX700M2 UniChrome PRO II Graphics (rev 03)
    02:01.0 Audio device: VIA Technologies, Inc. VIA High Definition Audio Controller (rev 10)


    Highlights here come from the Realtek Ethernet which is well catered for out of the box by pretty much any major Linux these days. There are also two IDE controllers, USB controllers and an audio controller that are all well supported. It's interesting that most of the PCI devices are provided by the single CX700M2 chipset which I believe is built onto the processor board for the Via Eden's. The one thing from this list that has been a pain in the back side is the graphics controller. It works out of the box both in frame buffer mode and via the open source via unichrome driver called Openchrome. However, Openchrome don't support the CX700M2 board yet (not officially anyway, the code is still in SVN according to the guys I spoke to on their IRC channel) so graphics processing was eating lots of CPU. Fortunately, I found a link to later via drivers at linux.via.com.tw than are available through the official Via driver site where they're still only supporting Ubuntu 7.04 and 7.10. Seems I'm caught in the middle for now, the Via drivers work nicely but will be a pain to maintain until the Openchrome drivers find their way into Ubuntu and I switch back over to them.

    Then there's the memory. For a small box this one has a relatively generous helping of 512MB RAM, some of which is stolen by the CX700M2 for graphical shared memory. Free is currently showing 439MB total memory, 390MB used and 49MB available; swap is 100% free. That's not bad at all considering I'm running Xorg with Gnome, SSH, SqueezeCenter, 2 instances of MySQL (SqueezeCenter starts its own instance), and a Nanobroker with some Perl code to log my Current Cost data. It'll be running Apache soon too as I move towards writing some more web based Current Cost facilities.

    Just in case anyone is interested, here's the list of modules currently loaded into Ubuntu's 2.6.24-19-generic kernel: drm af_packet ipv6 cpufreq_powersave cpufreq_conservative cpufreq_ondemand cpufreq_stats freq_table cpufreq_userspace sbs container sbshc video output dock battery iptable_filter ip_tables x_tables ac parport_pc lp parport loop snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore serio_raw evdev psmouse pl2303 usbserial pcspkr button i2c_viapro i2c_core shpchp pci_hotplug via_agp agpgart ext3 jbd mbcache sg sd_mod pata_acpi pata_via ata_generic 8139cp ehci_hcd uhci_hcd libata usbcore 8139too mii scsi_mod thermal processor fan fbcon tileblit font bitblit softcursor fuse

    I'll spare the full dmidecode output but from this information I can determine it has an AMI Bios version 8.14 released on 03/28/2008. The CPU is listed with, amusingly, Family "out of spec" and 128K L1 parity cache and 128K L2 ECC cache. A single soldered 512MB Dimm.

    I'm still surprised at just how well it matches up to being a standard x86 box, providing all the interfaces you would expect of such a box given its size. Clearly it's never going to be the fastest or have the most memory, but it really does stack up nicely for all but the most intense home serving tasks or gaming. It certainly shows me we can fill most of our computing needs with such a small box and only 8 watts of power. Ubuntu seems no problem for it and it's reported to run Windows XP too. I'll definitely be bearing it in mind next time someone asks me to recommend a box simply for browsing the web, e-mail or a bit of word processing!

    <Edit>
    Memtest86+ shows the processor as a Via C3 Samuel 2 clocked at 498.7MHz, 128K L1 cache @ 2035MB/s, it doesn't detect L2 cache, and shows 447MB RAM @ 367MB/s.
    </Edit>

    Installing Ubuntu On A TinyTuxbox

    With my new toy now in hand the time soon came to get it installed with Linux. At first glance it might appear to be tricky to install given the lack of CD or Floppy drives. However, it boots from just about anything you attach to it whether that's USB, Compact Flash or Network Boot. Setting up a one-time PXE server seemed a little over the top so I was planning to boot from a USB stick until I found someone at work with a USB CDROM.

    Ubuntu IconUsually I like to run Fedora at home, it's the thing I'm most comfortable with having spent my career tinkering with Red Hat and SUSE based distributions so one of the things I wanted to do with this box was install the much hyped Ubuntu distribution. This wasn't to see what all the fuss is about (I'm familiar with Ubuntu having tried it a couple of times before but always gone back to Fedora) but really just so I can get to know it even better. This machine is going to be part desktop and part server so Ubuntu kind of makes sense too.

    I installed the hard disk into the box myself and once I got over some initial hardware niggles (that I caused I should add) the installation was simple. Boot from USB CDROM with the Hardy Heron CD in it and the rest is history. It's amazing how such a small box can run a full whack desktop operating system and do all that on just 8 watts.

    In these early days, I have three things in mind for the box. The primary use will be to serve my music collection to my stereo; next is to connect my current cost meter to allow some more in-depth analysis of our power usage at home; then there's simply using it as a desktop for the simpler day-to-day computer usage i.e. browsing the web.

    Setting up the music streaming was pretty easy after transferring my collection to the hard disk. I added the apt sources for the SqueezeCenter software that operates with my SqueezeBox Duet, did an apt-get update and an apt-get install squeezecenter and job done. The TinyTuxbox can much better cope with running the MySQL server this is based on along with the web front end and the music collection scanning services associated with the software than the SLUG I tried previously. All in all, couldn't have been much easier.

    I've not tried hooking up my current cost meter yet, ironically I've run out of power sockets near the computer with only a six-way adapter and plugs for the PC, TinyTuxbox, Printer, Monitor, ADSL Modem Router, and speakers although it shouldn't be a hard problem to rectify.

    Last of all, one of the additional benefits of this low-power box is every day usage. It can easily run a web browser so instead of starting up a large PC just for this, we can switch to the TinyTuxbox desktop and browse there. This should add to our power saving, even though it's likely the TinyTuxbox will be run all the time soon to serve the current cost data. That reminds me, I really should discuss batch-uploading of current cost data so I can save even the 8 watts the TinyTuxbox uses most of the time too.

    Introducing the TinyTuxbox

    My second choice of home media server arrived on my doorstep last week after my unwillingness to maintain the painfully slow and awkward slug. This time around I've plumped for a TinyTuxbox Series 8 which seems to be a UK resold version of the e-Box 4300. It fits the extra requirements I made after parting with the SLUG, that is it's an x86 based machine and has lots more memory. I'm not the only one at work with one of these types of boxes either, James Taylor has the Netvoyager re-badged version of the previous box to my one, the e-Box 2300.

    It is, in fact, a fully functional x86 PC but just a really small one, even smaller than the pretty tiny Fit-PC which I was also seriously considering and probably would have gone for were it not for the excellent pre-sales support of one of the TinyTuxbox staff over e-mail. That said, the excellent pre-sales was balanced with painfully slow delivery. It took 28 days to get it to my door which for a delivery cost of nearly £20 I consider poor. I've been left with a upward feeling though, post-sales support has been promising too as I initially had some problems installing the box, which it turned out were my fault and I solved quickly enough anyway. I'm not going to talk software here though, that's a story for another day. So how does my TinyTuxbox look and spec up....?

    The workhorse of the TinyTuxbox is the 500MHz Via Eden ULV processor which provides a 32-bit x86 processor along with a built-in graphics processor with hardware MPEG decoding. The processor is an impressive bit of kit, it runs all that from just 1 watt of power, see the link for the full specs! Away from the processor we have 512MB RAM (some of which is shared for the video output), on-board Ethernet, 3 USB ports, VGA output, a PS/2 connector (supplied with PS/2 Y-Splitter cable to connect both keyboard and mouse), a compact flash slot, sound in and out, power button, and hard disk and power LEDs. The box is also fitted with an IDE connector and can house a 2½" laptop type hard disk in it. I ordered it without the hard disk and fitted my own as the supplied ones were not good value for money probably due to the services incurred from the fitting itself.

    The TinyTuxbox site advertises the unit as consuming a maximum of 8 watts and I'm pleased to report that was absolutely accurate. According to my current cost meter, it uses 8 watts with the hard disk spinning so once I get it to spin down on idle it should use very little juice. Click the various images for a link to my Flickr page and some more notes.

    SqueezeCenter on the SLUG

    At first glance, installing slimserver (now SqueezeCenter) on the SLUG is very straight forward as it's nicely packaged into an ipkg and made available via Optware. However, as indicated on the slimserver application page on the nslu2-linux wiki, things aren't as simple as they first appear. Unfortunately, something is very broken with slimserver and its dependency chain in Optware as things stand at this moment in time. As a result installing slimserver with a view to upgrading to squeezecenter at a later date becomes much more problematic. I need at least SqueezeCenter version 7.0 to operate with the SqueezeBox Duet.

    My first target was to run slimserver 6.5.4 which is the latest version from the version 6 line and the version packaged for the SLUG in optware. I tracked the problem down to the mysql dependency for slimserver, it seems since the last update of slimserver in optware, mysql has also been updated and since that time slimserver has been reported as broken on the SLUG. Unfortunately, rolling back versions in optware is not trivial since they only make available the latest version with no access to previously packaged programs. My only option was to check out the mysql build environment from SVN at the previous level and compile up the package from source. This is reported to take in the region of 18 hours natively on the SLUG so I set up a cross-compilation environment on my Fedora 8 box at home. MySQL compiled in about 10-15 minutes and I now had a package to install. The reports were correct, slimserver 6.5.4 was now running on my SLUG, excellent!

    The next challenge was to get SqueezeCenter running, and this worked in a similar way to getting slimserver going. There are a few oddities with getting all your ducks in a row while running this stuff on a SLUG, SqueezeCenter is very particular about file permissions, and the newer software introduces a whole bunch of Perl dependencies not present in the earlier slimserver versions. Fortunately, I'm very familiar with Perl as well as Linux (one of the reasons for choosing a squeezebox) and I've managed to compile up the minimum dependencies to get SqueezeCenter going. It seems Slim Devices as a company test against x86 and PPC architectures to the extent they even supply their Perl dependencies for these from CPAN. I'm running on ARM on the SLUG though which introduces a whole world of dependency problems as it seems SqueezeCenter is also pretty sensitive to the version of each Perl module used, it's not just a case of grabbing the latest and greatest from CPAN, a further bind for getting it going nicely. One other thing, CPAN doesn't seem to run at all well on the SLUG, it's far faster to download the tarred packages and compile manually!

    I eventually got SqueezeCenter 7.0.1 running on the SLUG, it consumes at least twice the 32MB RAM available so runs pretty slowly while spending a lot of time paging to the USB disk. I set up an additional swap file on disk as well, thinking about it perhaps I should have used the rest of the 8MB flash as swap too! All in all, running SqueezeCenter on a machine with so little memory and on an architecture not supported by Slim Devices has equated to a slow response time and a maintenance headache.

    In conclusion, it's been a good experience getting a SLUG and setting up SqueezeCenter on it. But I already need a more powerful box so less than 1 week after the SLUG arrived at my house it's time to sell already. Fortunately, I've found a buyer at work who wants something low power for some really trivial services so the SLUG is ideal for them. For me though, it's a case of getting back to scratching my head over which low power home server solution to try next. Whatever I choose will be more expensive than the SLUG, it's possible I could equal its low power usage, and I definitely now know I need more memory and ideally an x86 architecture.

    Unslinging the SLUG

    Having recently purchased the Linksys NSLU2 (commonly called a SLUG) for use in a hacked form as a low power home server, I've been playing around with it a little to customise it towards my needs. The eventual aim is to run SqueezeCenter on it to power my new SqueezeBox Duet. The most commonly used hacked version of Linux provided by the SLUG hacking community is known as uSLUnG, hence hacking the SLUG with this being called unslinging.

    The process of unslinging is made very simple, thanks to the great instructions developed over the years by the community, and with such a large community the amount of testing on these instructions is pretty complete too. First step is to download the firmware binaries as described on the SLUG Firmware site. I used firware version 6.10 Beta which is considered the latest stable version in spite of having a beta tag. Then simply followed the instructions in this README file and I was done. The whole process takes no more than 10 minutes or so.

    Now I have a nice little low power Linux box sitting on my network raring to run some services for me. Pretty much anything you can think of has been done on the SLUG, Apache, MySQL, etc, etc, etc. So the list and choice of what to do is very complete. For now though, I've just installed a few basic utilities (coreutils), Perl (I know I'll need that later), GCC, and SSH for remote access.

    I'll quickly mention the SLUG specs in passing too. It has a 266Mhz ARM based Intel XScale processor, some of the early models were under clocked at 133Mhz but all the recent editions run at full speed; 8MB flash; 32MB RAM; 2 USB 2.0; 10/100 Ethernet; runs from 5V DC power and measures just 2 x 9 x 13cm. With one USB disk attached my Current Cost meter reads it at about 5 watts power usage which I guess may rise a watt or two under load.

    Choosing the media server

    The decision of which media server to go with has easily been the longest and most agonising while putting together new audio solution at home. I'm not the only one at work having recently been looking in this area either, James Taylor has also been looking at home servers with similar requirements in mind to myself. Namely, cheap and low power (low electrical power for always-on as opposed to a slow processor).

    In no particular order, options on the list for me were:
    EDIT (suggestions from comments, with my thanks):END EDIT

    All have clear advantages and weaknesses I wont go into in detail for each box. However, they can roughly be grouped into cheaper solutions as provided by a hacked NAS box, or more expensive PC style systems. Some go straight out of the list on price alone, such as the relatively expensive Mac (I don't understand the Mac fad, single vendor lock-in, haven't we seen that somewhere before?).


    I decided to plump for the cheapest of all the options, the SLUG. I figure that even though it has a slow processor and only 32MB memory it does have a fighting chance of running SqueezeCenter to power the Squeezebox Duet based on the reports of other users running SlimServer on it. If all else fails, there are plenty of people at work looking for low power solutions who may be willing to buy a 2nd hand SLUG should I want to upgrade anyway.

    The SLUG is a very well-known device in the land of hackery. It can easily be modified to run any one of several different versions of Linux that maintain different levels of compatibility with the original Linksys firmware and interface. It's purpose in life when released (back in 2004 I think) was as a cheap NAS box that simply provides a USB to Ethernet interface. The idea being you plug a cheap USB hard disk into it, configure via the simple web interface, and you have storage you can access from anywhere on your home network. Because Linksys made the device cheap, naturally their choice of operating system was a free one, Linux. The Linux license dictates Linksys had to make their source code available, hence it's easy to modify the original software for your own purposes. The rest follows from there really!