Pointless Circuits

Programming, Electronics and Breaking Things

Nov 12, 2014 - Comments - Linux igel

Small Home Server on my Igel

As the progress on my other project Natoblaster is pretty slow, I decided to make a write-up of my small home server on my “igel Thin Client”, which does some quite useful and some less useful but interesting things.

First, for all you uninformed people out there, an “igel” is a simple thin client. The specs itself were pretty decent once (for a thin client) and are enough for my use case:

  • IGEl ¾ Thin Client
  • VIA C6 600 MHz CPU
  • S3 Unichrome Pro Graphics Chip
    • officially Full HD capable
  • 512 MB DDR2-RAM
    • more is unfortunately not possible, and swap on a CF is … unwise
  • 8GB CF Card as primary Hard Disk

I bought it some years ago, when things like a Raspberry Pi were not standard at all and small ARM Linux devices were rather expensive and very low spec even compared to that. Additionally, it featured some very interesting possibilities, as it had an internal USB-Port, where a SmartCard-Reader was connected, that is already salvaged and loaned to Jonas (At that occasion: Lad, where is that thing? What ATM are you skimming right now?). Also, it has a (in the beginning not populated) internal IDE header. I might add a hard disk there, which would unfortunately render the CF Card non-functional. Which additionally made it very interesting, as i was searching for a dedicated workbench machine, were the “legacy” ports on its backside. Try to find a device with parallel, RS232 and PS/2 today!

When i scrubbed that plan, i needed another use case, and as I wasn’t willing to dedicate my Raspberry Pi to such a boring task (I mean, it has GPIO), I dusted off the igel and hammered Linux on it. Easier said than done, as the igel doesn’t want to boot from a flash drive. So I had to burn a CD (whoa, they still exist?) and boot with an external USD drive, which strangely worked.

So after installing a bare bone Arch Linux (everyone confused should use this pretty good step by step explanation) it was time to find suitable software for all intended use cases. Here a shout out to the great Arch Linux Wiki, best maintained and most informative wiki of any Linux distribution I have ever seen! But back to the topic. As one of the standard tools on all arch systems for me is yaourt, it was more or less the first thing I installed from archlinuxfr that way:

After adding

SigLevel = Optional TrustAll
Server = http://repo.archlinux.fr/$arch

to your /etc/pacman.conf, you can simply install it with

pacman -Syu yaourt

After that, I set to work on my targets:

  1. syncing software for file sync with Workstation, laptop and mobile to phase out Dropbox
  2. audio server to play songs from said devices on my phonograph/amplifier via Network/Bluetooth
  3. maybe additional functions, yet to be determined

For the first point, i wanted a full sync solution, not only a network drive and some shell script. After some research, the best candidate was OwnCloud, as it planned to replace Dropbox which in turn i wanted to reaplace too. After some trying, i was shocked by the abysmal performance - I mean, this is by far the biggest resource hog I have ever encountered - and the added difficulty for syncing over the internet. So I followed the advice of a friend and tried BTSync. And I am absolutely hooked. Blazingly fast, lightweight and syncing over Internet with encryption and no necessity to have a static IP. As btsync is a package in the AUR, it was pretty straightforward with a simple

yaourt btsync

After that, you just need to start/enable it with

systemctl start btsync
systemctl enable btsync

and you can use it via the web interface. Even though btsync doesn’t need a or has server, you can simply “abuse” an always-on client to be a kind of makeshift server. Surely, I am not saving on the 8GB CF, I just added an external USB HD to the system as mass storage.

The audio server proved to be more difficult, so I settled for Apples “Airtunes” protocol on my Windows/Android devices, and pulseaudio on my Linux machines.

As Airtunes-server, the two implementations I found were “shairport” and “shairplay”. Fortunately, both were in the AUR, so I could simply test them. During those tests, I determined by long and complex measurements, that “shairport” would be my solution of choice. (Basically, it has no 2 sec delay between pressing play and the music finally starting).

Finally, I wanted to monitor my server over time, but “standard” applications like nagios are … well made for real servers, not that anaemic thing I have here. So I did a bit of pretty advanced googling and found Monitorix which does exactly the thing I want it to, in a lightweight manner. Setting it up was easy, trusty yaourt did most of the work. Only additional thing to do was to change in


the integrated http-server block to this

        enabled = y <-- has to be changed from n to y
        host =
        port = <-- your port here, standard is 8080
        user = nobody
        group = nobody
        log_file = /var/log/monitorix-httpd
        hosts_deny =
        hosts_allow =
                enabled = n
                msg = Monitorix: Restricted access
                htpasswd = /var/lib/monitorix/htpasswd

and you are good to go with your small monitoring solution and I am with my small server for the moment.