Scott Lowe's Blog

One of my projects over the recent holiday was to rebuild the home network. Working on a home network is a different sort of beast than working on a network for a company. There are different challenges to be addressed. After research, I settled on the use of Ubuntu 8.04 LTS (”Hardy Heron”) for the server build.

My primary goals for this “home network rebuild” were the following:

1. Rebuild the home server with a newer version of Linux, and possibly switch to a different distribution.
2. Continue to provide DNS, DHCP, HTTP, and HTTP proxying/content filtering services to the home network.
3. Continue to provide file sharing services via Server Message Block/Common Internet File System (SMB/CIFS) for Windows-based systems on the home network.
4. Continue to have a shared music library available via Digital Audio Access Protocol (DAAP, aka iTunes) available to all systems on the home network.
5. Provide file sharing services to Macs on the network via AppleTalk Filing Protocol (AFP) over TCP.

Ideally, I also wanted to enable Time Machine backups from my Mac laptop to the home server.

After doing a fair amount of research, I settled on the use of Ubuntu 8.04 LTS (”Hardy Heron”) for the server build. I didn’t go with Ubuntu 8.10 (”Intrepid Ibex”) simply because a) I already had 8.04.1 downloaded and burned to a CD; and b) Hardy Heron is an LTS release, so I should have better support over the long term.

I won’t bore readers with the details of the rebuild, but it took about a day or two to get a larger hard drive installed, Ubuntu installed and configured, and services running like DHCP (including some static reservations for certain computers, like my laptop and my iPhone), DNS (using MaraDNS, much easier to figure out than BIND), Apache, and Squid with SquidGuard. At this point, I’d completed tasks #1 and #2.

On to task #3. This was pretty simple and straightforward and easily accomplished via Samba, with nothing really unique to document here. The one interesting thing that I did find was a way to map the long usernames that Mac OS X uses (like “Bob Jones”) to a short username (like “bjones”). I used this command in the /etc/samba/smb.conf file:

username map = /etc/samba/usermap.conf

In this file, I simply placed lines that mapped the long usernames to the short usernames. Since Mac OS X defaults to the long username when connecting to the server, this allows me to simply type in a password and connect. I searched for hours trying to find a way to have Mac OS X supply my current password to the Samba server so that I wouldn’t get prompted, but could not find any information. If anyone knows the trick, I’d love to hear about it. After configuring a few shares, setting Linux permissions and the umask, and then testing from both my Mac laptop and a Windows laptop, task #3 was finished.

Task #4, providing an iTunes-compatible music server, was also really straightforward and easy. For this, I again selected Firefly Media Server, formerly mt-daapd, which I’d used before with great success. Again, nothing unusual or unique to document here, except for the potential interaction with Avahi (more on that later).

The final task was installing Netatalk to provide AFP over TCP file sharing services for Macs on the network. Fortunately for me, one of the sites I’d been using to help in my project pointed me to this blog post, which had a prebuilt package for Netatalk that included the necessary SSL support that Mac OS X requires. That saved me the trouble of compiling Netatalk from source. Following the steps in the Kremalicious article as well as information from this guide, I configured Netatalk to present a volume to use for Time Machine backups. It was at this point that I noticed a strange interaction with Avahi.

Avahi is a multicast DNS (what Apple calls Bonjour) server for Linux. It’s responsible for advertising services to multicast DNS-enabled systems, such as other Linux systems running Avahi or Macs. I’d installed Avahi earlier and used some service definitions from this article and this blog post to advertise Samba and HTTP. In addition, after installing Firefly, I’d noticed that Firefly starting advertising its presence automatically through Avahi with no service definition required.

Upon installing Netatalk, I also noticed that Netatalk started advertising automatically via Avahi as well, but using the IP address of the server. In order to be able to control how Netatalk advertises via Avahi, I had to change this line in /etc/avahi/avahi-daemon.conf:

enable-dbus=no