I acquired a Pogoplug device awhile back, and on the whole I find it a neat little gadget. The user interface is okay, but not great; but really I don't need another web-based storage location. I've already got Dropbox and Ubuntu One accounts that I hardly use, so being able to store more data online -- albeit on hardware I control -- just isn't that useful. What I would like, though, is a small, low-power Linux server that I can use for a variety of useful tasks.
The Pogoplug has 256 megabytes of RAM, so anything I might do with it needs to have minimal system requirements. I decided to try to install Habari, mostly just to see if I could. Habari can use SQLite as its datastore rather than a complex relational database server, and requires only an http process that can handle PHP. This means it can use lighttpd or nginx rather than Apache. Using SQLite severely restricts the potential performance and scalability of Habari, but with only 256MB RAM I'm already severely limited in how much I might be able to scale.
It was trivially easy to install Debian on the Pogoplug device. I booted from a USB stick which contains the root filesystem. I added a 500GB external drive, and gave it three partitions: swap, /var and /home. The Debian install had basically no services running other than sshd -- no syslog, no cups, no avahi, no nothing. I installed nginx and PHP. In order to get nginx to handle the PHP processes, I needed to install the spawn-fcgi package.
Then I just followed the Habari nginx instructions, and I had a blog running! With nginx, spawn-fcgi and a screen session connected to IRC, I still have 7 megs of unused memory, and I haven't dipped into swap at all!
skippy@debian:~$ free -m
total used free shared buffers cached
Mem: 249 242 7 0 11 205
-/+ buffers/cache: 25 224
Swap: 2047 0 2047
skippy@debian:~$ vmstat -a
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free inact active si so bi bo in cs us sy id wa
0 0 0 7328 197228 37972 0 0 0 25 36 39 0 0 99 0
Of course this little blog isn't actually handling any traffic, but it's nice to know that I have a self-contained, self-hosted Habari environment on which I can hack.
I've been using GNU/Linux as my primary operating system for many years. At my last job I used Microsoft Windows as my desktop operating system for about the first year, but was able to gradually convince my boss that I'd be more productive using GNU/Linux. When I started at OSU, I used Microsoft Windows for the first couple of months, because that's what I was given, before installing GNU/Linux onto my machine. On the whole, I do think I'm more productive using GNU/Linux as my desktop client: it's been super reliable for me, and largely problem free through all the upgrades I've performed.
When I first started using Linux, way back in the mid-1990s, I used Red Hat 5.2. Almost everyone I knew used Red Hat, except for a few show-offs who used Slackware. I dutifully upgraded to 6.0, and then 6.2, and then 7.0 and 8.0. Somewhere right around there, Red Hat decided to focus exclusively on Red Hat Enterprise Linux. Like many disgruntled users, I decided that Red Hat was no longer the distribution for me, and I switched almost overnight to Debian. It was a rocky transition -- at the time the Debian way and the Red Hat way of doing the same tasks were very different, and I wasn't exactly an expert user. I managed to muddle through, though, and found myself liking Debian an awful lot. I stuck with Debian until I found Ubuntu.
I've been using Ubuntu on my computers exclusively ever since. I really like it. It offers all that I've grown to love from Debian with a more aggressive release cycle, so that I get more recent releases of software more often. I haven't had any real complaints about Ubuntu in all the time that I've been using it.
At work we have a Microsoft Windows Active Directory. It is possible to join GNU/Linux clients to an Active Directory infrastructure, so that a user can use a single account to log onto both Windows and Linux client machines. This is important at work because we plan to dedicate one of our computing labs to Linux computers, but we don't want to unduly increase our administrative overhead. Using the Active Directory allows us to have a single user account for all our students, but still allow them to use the platform of their choice.
Until recently, my Linux workstation had been a standalone system to which I logged on using a local user account. After upgrading my workstation to Ubuntu 8.04, I joined it to the Active Directory so that I could log onto it using my domain account. In many ways, I think it's important that the IT support staff "walk the walk" by using the services they provide. This is an important sentiment that will surface again later in this post. Joining my machine to the domain wasn't terribly difficult, and I had quickly migrated all my data from my old standalone account to my domain account. Shortly thereafter, the trouble began.
While doing the normal things I do with my computer -- launching applications, opening files, browsing directories on my hard drive -- my system would spontaneously lose all of the theme configuration I had applied. It's somewhat of a challenge to accurately describe the problem to someone who hasn't used Linux. Basically, all the widgets and buttons on my desktop and in my applications would lose their style and revert to the ugly default. Worse, I was unable to change these settings back to the way I wanted them unless I logged out or rebooted the computer. Neither solution is acceptable. I discovered several other problems when this would happen: sometimes I would be unable to see the contents of my home directory! This would happen in the Nautilus graphical file manager, as well as in "File Open" dialog boxes. This was absolutely catastrophic: it meant I couldn't attach files to emails, or navigate to sub-directories in my home directory. (I could still access things from the command line, which was only a modest relief to the problem.)
I narrowed my problem down to the fact that the gnome-settings-daemon was failing. Searching revealed that a number of other people experienced the same problem, and a variety of solutions and work-arounds were put forward. I tried most of them, but had not lasting success: gnome-settings-daemon kept terminating, resulting in a mostly unusable desktop for me. I found, and commented upon, bug 138277, but no replies have been made. I started a thread on the Ubuntu forums, but it's seen no action yet. I readily accept that I may have done a poor job describing my problem in a way that folks can understand.
One troubleshooting step would be to perform a complete re-installation of Ubuntu 8.04. I had originally installed 6.10, and then upgraded to 7.04 and then 7.10 before finally upgrading to the latest 8.04. I'm not entirely keen on this, but it would help identify whether the problem is a glitch introduced during my upgrade, or whether it's a substantive problem with Ubuntu 8.04.
As I said previously, though, I think it's important for IT folks to walk the walk. In our computer labs, we won't be running Ubuntu. We'll be running Red Hat Enterprise Linux Desktop. Many of the scientific and engineering applications our students use are only available for Red Hat or SuSE. I suppose I could try CentOS, but our college has brokered a deal with Red Hat. We have plenty of available licenses for their offering, so that's what we'll use. I am strongly considering taking this opportunity to configure my workstation in an identical fashion as all the lab computers. This would be good practice, and would help me to provide better support to the labs because I'd be clued in to the particular nuances of the distribution. This has its own set of problems, as you might expect.
I admit that I've been spoiled by Ubuntu with fresh new versions of most software. Red Hat Enterprise Linux does not offer the same new versions of all software. For example, Red Hat still ships Firefox 1.5, whereas Ubuntu is now shipping Firefox 3 beta 5! This might be a non-issue, though: many of the servers and devices we have in our network (fiber channel switches, Ethernet switches, security cameras, IP KVM, etc) use Java applets served through a web page. Java applets do not run on 64-bit GNU/Linux systems. My system is a 64-bit system. I found it extremely annoying using Ubuntu to have to make a Remote Desktop connection to a Windows computer just to launch Microsoft Internet Explorer in order to execute a Java applet. So, if I install Red Hat, I could install the 32-bit version of a newer Firefox and enjoy native Java applets (and native Flash to boot! YouTube, I've missed you!).
The purpose of this post has been, primarily, to get myself to think about the pros and cons of using Ubuntu and Red Hat. Each has definite strengths and weaknesses, and neither is demonstrably superior for this situation. Switching back to Red Hat will invoke a bit of a learning curve, but I think it's probably the best choice for my work computer. Besides, if I take the time to re-install Ubuntu and the problems with gnome-settings-daemon persist I'll be installing Red Hat anyway!
My home network consists of two Linksys WRT54G wireless routers, a Linksys NSLU2 network storage device, a Mac Mini running MythTV, and laptops for each member of the house. All but one of these devices use 802.11 wireless networking.
One of the WRT54G routers lives in my bedroom, connected to the DSL modem there. This router runs the wonderful OpenWRT firmware, providing me a good old fashioned Linux command line with which to administer the router. I use iptables rules to enact network address translation, allowing all the computers in my house to have access to the internet.
The NSLU2 is the only device in my network that lacks built-in wireless networking. I could purchase a USB wireless adapter, but these aren't as cheap as I'd like, and the NSLU2 only has two USB ports, both of which I would prefer to use to connect to USB hard drives (though currently only one is in use). The NSLU2 instead connects to my other WRT54G, which in turn is running the dd-wrt firmware. This router acts solely as a wireless bridge, allowing wired-only devices to access my network and the internet, and provides no other services. I run Debian on the NSLU2, giving me a fully featured operating system on an itty bitty platform.
All of these Linksys products run Linux, and can be classified as "embedded systems" because they have very specific limitations with respect to storage and memory. As such, certain tradeoffs need to be made. The WRT54G routers have 16 and 8 megabytes of RAM, respectively, and they run the entire system in memory so there's no room left for extraneous services or wasted space. The routers, for example, all use Busybox to provide basic UNIX utilities without using a lot of space. The default installation of OpenWRT provides the Dropbear SSH daemon, which is a substantially smaller package than the more traditional OpenSSH. Dropbear works great, though, and provides everything I need to connect to and administer the routers.
The NSLU2 isn't as limited when it comes to storage, since I can (and do) use a USB hard drive to store an entire Debian installation; and it has (by comparison) a whopping 32 megabytes of RAM. Still, I need to be careful about memory usage so as not to cause the system to thrash swap space or have the kernel OOM killer forcibly terminate services. Taking a cue from the OpenWRT installation, I replaced the standard OpenSSH server on the NSLU2 with Dropbear, in order to free up more RAM. I also installed dash instead of bash as my primary shell, in order to eek out a little extra memory. dash lacks all of the handy features I like from bash, but I use the NSLU2 for pretty specific backup purposes so I don't miss the features all that much. I disabled all the unnecessary (for my use) services, like nfs-common, portmap, openbsd-inetd, etc. I replaced Exim4 with SSMTP. Finally, I installed thttpd. My intent with this is to use the NSLU2 to store large media files I might like to link from my blog without having to worry about bandwidth usage on my blog's server: serving the files from my home DSL line has no bandwidth cap, whereas the VPS hosting my blog does have a bandwidth cap.
For the past little while I've been contemplating OpenVPN on one or more device in my network. I find myself growing more and more uncomfortable using unencrypted wireless networks at coffee shops and hotels, and would like to be able to tunnel my connections through a secured channel to a host under my control. I've had tremendous success with OpenVPN at my previous job, and I advocate it all the time to people looking for VPN solutions. Its set up, while not hard, is non-trivial, and truthfully I worried about the resource drain the OpenVPN daemon might put on my limited resource Linksys devices.
During a conversation with Matt in #habari, I provided the link to using SSH as a SOCKS proxy. Duh! There was the answer I was looking for! So last night, I installed the full-blown OpenSSH daemon onto one of my WRT54G routers. I configured it to listen on TCP port 443, so that it wouldn't interfere with the currently running dropbear (should something have gone wrong, I still wanted to be able to access the system!) and because the proxied traffic will largely look like requests to an HTTPS website to the casual eye (and most firewalls). The two applications I most frequently use (Firefox and XChat) both support SOCKS proxies, so I was quickly in business. I defined the SOCKS proxy in XChat, established an ssh connection to the router, and watched as XChat reported
* Looking up irc.freenode.net
* Looking up localhost
* Connecting to localhost (127.0.0.1) port 2600...
* Connected. Now logging in...
I installed the FoxyProxy Firefox extension, and added my localhost proxy to its configuration. It was hard to test with certainty from home, but this morning at work there was no doubt: after selecting the localhost proxy from the FoxyProxy menu, I visited WhatIsMyIP and saw my home IP address displayed! Success!
Not every application I'll ever use supports SOCKS, so this might not be as robust a long-term solution as OpenVPN would have been, but it allows me to minimize the number of running services while re-using familiar applications.
I've been eyeing the Linksys NSLU2 for a little while, contemplating its use as a file server for the house. I'm attracted to the (extremely!) small form factor, the low power consumption, and the fact that Debian is fully supported on it (see Debian on the Linksys NSLU2). I'm not keen on actually buying it, though, especially since I still own a Shuttle XPS small form factor PC. I'm also worried that the NSLU2 will ultimately prove to be underpowered for my goals.
I want a low-profile file server for two basic reasons:
- I want to be able to keep convenient, centralized backups of the various computers in the house
- I want a repository of music files accessible to all computers in the house
The MVix MX-760HD can play music files but its support for playlists is extremely lacking, and it doesn't expose the collection of music to other devices on the network. So I want to move all the music from the MVix to somewhere else. The MVix could still access the music from the network server, though I doubt I'd use it much for audio playback. (Incidentally, I'm still delighted with the MVix: it's been a great addition to our entertainment center: not having to shuffle DVDs to watch some of our favorite programming is a real treat.)
Having the music files in a central location is only one piece of the solution, though. I'd like to allow all our laptops to listen to different playlists in different rooms at the same time. I suppose we could all mount a network share, and simply have our local music clients parse the share contents. That's not quite the solution I'd like to pursue, though.
I looked at the SlimServer, the script that powers the Slim Devices product line. It looks neat, and should be easy to use. There is documentation for the SlimServer on the OpenSlug firmware, so it ought to work on Debian-on-NSLU2 just as well. The comments on that page, and in some Google searches for "nslu2 slimserver" made me a little concerned about whether the NSLU2 would be up to the task of serving media. We have 8000+ MP3 files, with more CDs yet to rip. A slow media solution is probably worse than the current configuration.
A little more investigation suggested a DAAP solution, the protocol used by iTunes. There is a iTunes Server for NSLU2, which uses the mt-daap package. There is a mt-daapd package for Debian, and I quickly found a Linux.com article about mt-daapd. Since Carina has been using iTunes of late to manage and play her media, the mt-daapd solution seemed like a good choice: she could move all her media to the file server, and continue to access all of it through her preferred client. I was pleased to learn that RhythmBox, the default GNOME media player, supports DAAP, too!
So last night I installed Debian Etch onto my Shuttle XPS. I executed
apt-get install mt-daapd, and was quite surprised to see "Shuttle" show up in the sidebar of RhythmBox! I moved the collection of music from the MVix to the Shuttle, and restarted the mt-daapd process, which triggered it to re-index the music collection. This took several minutes on the Shuttle -- I can only imagine it would take considerably longer on the NSLU2. Clicking "Shuttle" in my RhythmBox client showed me that more than 8,000 songs were available!
I think my worries about the speed of the NSLU2 are largely misplaced: (re-)indexing the music collection isn't an everyday occurrence, so it's not something that will hamper every day music playing. If you're using the NSLU2 with mt-daapd, do please share your experiences!