1000umbrellas.com

Michael Descy's Personal Website

Browsing Posts published by Mike

Using the configuration file shown in my Transmission-Daemon setup post, Transmission will download files into the “downloading” folder until the download hits 100%. At that point, the downloaded files will be moved to the “seeding” folder. The torrent will remain active, seeding to other users, until it hits the seeding ratio, or until you pause or remove the torrent.

Left alone, these completed torrents will not be removed from the server, and will accumulate as you download more torrents over time. There is no automated way to remove these torrents. Also, there is no automated way to move files to a new folder after seeding is complete, only after downloading is complete.

My ultimate goals are to complete seeding up until my seeding ratio is hit, to move torrents out of the seeding folder once seeding is complete, and to use the TVNamer Python script to automatically move any TV episodes I have downloaded to my media server’s TV folder.

Because I want to use TVNamer to move and rename most of my downloads automatically, but I want them to be seeded up to the ratio I set, I cannot use TVNamer on my “seeding” folder. If I did so, there’s a big chance that files would be removed from my “seeding” folder before seeding was complete. To solve that, I decided to move all completed torrent downloads to another folder, “complete”, and set TVNamer to run on that folder. To move completed torrents, I created a Transmission queue management script, which performs the following actions every 15 minutes:

  1. Check for completed downloads that have either been paused manually or have seeded until the seeding ratio.
  2. Move the downloaded files to another folder (“complete”).
  3. Remove the torrent from the Transmission server.

Removing Completed Torrents Using a Script

Here is the script, which is based on my previous version. Compared to my last script, this one’s largest difference is the elimination of the netrc argument in the transmission-remote calls. I noticed that I did not need to send credentials to the Transmission daemon, presumably because my user account has all the privileges it needs to run transmission-remote.

A commenter on my previous post of this script informed me that Transmission 2.x uses “Finished” instead of “Stopped” to indicate completed torrents. I incorporated that change into the script, so that it will work with the old or the new verbiage.

Be sure to change the value of the MOVEDIR to the path you wish to move the downloads to. If you set it to “%1”, you can specify the path as a command-line argument.

Script file: /home/mjdescy/bin/removecompletedtorrents

#!/bin/sh

# script to check for complete torrents in transmission folder, then stop and move them

# either hard-code the MOVEDIR variable here…
MOVEDIR=/home/mjdescy/media # the folder to move completed downloads to
# …or set MOVEDIR using the first command-line argument
# MOVEDIR=%1

# use transmission-remote to get torrent list from transmission-remote list
# use sed to delete first / last line of output, and remove leading spaces
# use cut to get first field from each line
TORRENTLIST=`transmission-remote –list | sed -e ’1d;$d;s/^ *//’ | cut –only-delimited –delimiter= ” ” –fields=1`

# for each torrent in the list
for TORRENTID in $TORRENTLIST
do
echo “* * * * * Operations on torrent ID $TORRENTID starting. * * * * *”

# check if torrent download is completed
DL_COMPLETED=`transmission-remote –torrent $TORRENTID –info | grep “Percent Done: 100%”`

# check torrent’s current state is “Stopped”, “Finished”, or “Idle”
STATE_STOPPED=`transmission-remote –torrent $TORRENTID –info | grep “State: Stopped\|Finished\|Idle”`

# if the torrent is “Stopped”, “Finished”, or “Idle” after downloading 100%…
if [ "$DL_COMPLETED" != "" ] && [ "$STATE_STOPPED" != "" ]; then
# move the files and remove the torrent from Transmission
echo “Torrent #$TORRENTID is completed.”
echo “Moving downloaded file(s) to $MOVEDIR.”
transmission-remote –torrent $TORRENTID –move $MOVEDIR
echo “Removing torrent from list.”
transmission-remote –torrent $TORRENTID –remove
else
echo “Torrent #$TORRENTID is not completed. Ignoring.”
fi

echo “* * * * * Operations on torrent ID $TORRENTID completed. * * * * *”

done

After creating the script file, be sure to make it executable.

$ sudo chmod u+x /home/mjdescy/bin/removecompletedtorrents

Scheduling the Script

Schedule execution of the script using cron.

$ crontab -e

I run the script every 10 minutes, with a 1-minute offset from the top of the hour. I redirect output to /dev/null so cron will not send me emails regarding the script’s output.

1,11,21,31,41,51 * * * * /home/mjdescy/bin/removecompletedtorrents > /dev/null 2>&1

Note: This article is an update to the Transmission daemon install instructions which reflects what I did when I rebuilt my media server. I now show the location of the configuration file in the “normal” place, /etc/transmission-daemon/, which did not work for me originally, but worked for me after a fresh install. I also improved the organization of torrents by setting up separate download, watch, and incomplete download folders. I hope these new instructions are more comprehensive, and better written, than the old ones.

This article explains how to install, configure, and run the Transmission daemon on a headless Ubuntu Lucid Lynx (10.04) server. Transmission, specifically transmission-daemon, is a BitTorrent client that can be accessed via a web browser and other front-ends, including a desktop app called trasmission-remote-gui and Android apps, including Transdroid (my favorite) and Torrent-Fu.

Installation

First, install the Transmission daemon using apt-get.

$ sudo apt-get install transmission-daemon

This installs the app and starts the daemon. The daemon runs under the user “debian-transmission”, which belongs to a group of the same name.

Preparation of File System and Group Permissions

I wanted all torrent files to be stored somewhere within my home folder (/home/mjdescy), which debian-transmission does not, by default, have access to. That means that I had to create folders for Transmission to use, and then grant debian-transmission read/write/execute access to them (execute is necessary to create folders), while ensuring that my user account (mjdescy) still had full control of the folders and their contents as well.

To do so, first create the folders for downloading and seeding torrents, completed torrents (i.e., seeding complete), and a watch folder to put new torrent files into. These three folders will be used by Transmission directly.
$ mkdir -p ~/dl/downloading # incomplete downloads
$ mkdir ~/dl/seeding # completed downloads/seeding torrents
$ mkdir ~/dl/watch

I also create a folder to move downloaded files to after seeding is complete. Transmission does not use this folder directly; I manipulate it via a cron job.
$ mkdir ~/dl/complete

Then, add your user account to the group debian-transmission. (I’m using my account name, mjdescy, in this example.) Now your user account and the debian-transmission user account are in the same group.

$ sudo usermod -a -G debian-transmission mjdescy

Next, change the group ownership of the folders Transmission will use to debian-transmission (the group, not the user).

$ chgrp debian-transmission ~/dl/downloading
$ chgrp debian-transmission ~/dl/seeding
$ chgrp debian-transmission ~/dl/watch

Finally, modify the permissions on each folder to allow full access (read, write, and execute) for both user (me) and group (debian-transmission, in this case).

$ chmod 770 ~/dl/downloading
$ chmod 770 ~/dl/seeding
$ chmod 770 ~/dl/watch

Doing so grants the debian-transmission group read/write access to that folder, preserves read/write/execute access for your user account, and prevents access to all others.

These changes also require me to “umask” setting in Transmission’s configuration file from the default of 18 to 2. That means transmission-daemon will create files with read/write permissions set at both the user and group level. Not changing the umask will make Transmission create files that your user account cannot delete or access completely.

Configuring Transmission

Configuring Transmission is a little unusual, compared to other daemons such as Samba, due to the daemon’s method of saving (overwriting) its configuration file on exit. Restarting the daemon, if it is already running, will result in it saving the configuration file, and overwriting any changes you might have made to it. Instead of restarting the service after editing the configuration file, you should reload the service. The following code sends a SIGHUP signal to transmission-daemon, which causes it to reload its configuration file. Importantly, it does not stop the the daemon, which would cause it to write over the configuration file.

$ sudo service transmission-daemon reload

After Transmission is installed, the daemon will be started automatically. Without changing the configuration, however, Transmission will not be accessible from other machines, which would pose a problem on a headless server. You must edit the configuration file using the command below, set the proper configuration options, then reload the daemon, to get Transmission going the way you want it to.

$ sudo nano /etc/transmission-daemon/settings.json

Here is my settings.json file, which I recommend that you use as a starting point. It configures Transmission to be available to clients other than localhost, to use separate folders for incomplete and complete (seeding) downloads and for the watch folder.

You have to edit the rpc-whitelist setting to connect to the server from anything other than the local host (and that’s nearly useless on a headless server). You should also edit the paths (download-dir, watch-dir, incomplete-dir) and peer ports as you see fit. Be sure to set the rpc-password, too!

{
"alt-speed-down": 500,
"alt-speed-enabled": true,
"alt-speed-time-begin": 480,
"alt-speed-time-day": 127,
"alt-speed-time-enabled": true,
"alt-speed-time-end": 0,
"alt-speed-up": 10,
"bind-address-ipv4": "0.0.0.0",
"bind-address-ipv6": "::",
"blocklist-enabled": false,
"dht-enabled": true,
"download-dir": "/home/mjdescy/dl/seeding",
"download-limit": 100,
"download-limit-enabled": 0,
"encryption": 2,
"incomplete-dir": "/home/mjdescy/dl/downloading",
"incomplete-dir-enabled": true,
"lazy-bitfield-enabled": true,
"max-peers-global": 200,
"message-level": 2,
"open-file-limit": 32,
"peer-limit-global": 240,
"peer-limit-per-torrent": 60,
"peer-port": 20500,
"peer-port-random-high": 20599,
"peer-port-random-low": 20500,
"peer-port-random-on-start": true,
"peer-socket-tos": 0,
"pex-enabled": true,
"port-forwarding-enabled": false,
"preallocation": 1,
"proxy": "",
"proxy-auth-enabled": false,
"proxy-auth-password": "",
"proxy-auth-username": "",
"proxy-enabled": false,
"proxy-port": 80,
"proxy-type": 0,
"ratio-limit": 0.2500,
"ratio-limit-enabled": true,
"rename-partial-files": true,
"rpc-authentication-required": true,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": “password”,
"rpc-port": 9091,
"rpc-username": "transmission",
"rpc-whitelist": "127.0.0.1,*.*.*.*",
"rpc-whitelist-enabled": true,
"speed-limit-down": 1500,
"speed-limit-down-enabled": true,
"speed-limit-up": 50,
"speed-limit-up-enabled": true,
"umask": 2,
"upload-limit": 100,
"upload-limit-enabled": 0,
"upload-slots-per-torrent": 4,
"watch-dir": "/home/mjdescy/dl/watch",
"watch-dir-enabled": true
}

After saving any changes, tell the daemon to reload its configuration file, which applies all the changes you have made.

$ sudo service transmission-daemon reload

Note that if you change the rpc-password to a plaintext value (which is the easiest way to do it), the password will remain unencrypted until transmission-daemon closes and it rewrites its settings file. To ensure that happens, and that the password is encrypted, restart (instead of reload) the service after you have reloaded it to apply the configuration changes. Once transmission-daemon saves its configuration file, the password will be converted from plaintext to a SHA1 encrypted format. You should only have to do this when you are changing the password.

$ sudo service transmission-daemon restart

That finishes configuration. Note that you will likely have to set up port forwarding on your router to access the web app from outside your network, and to seed properly.

Port Forwarding

Be sure to set up port forwarding on your router to expose the Transmission daemon to the outside world. You will have to forward the peer port range in order to upload properly. You can also forward the 9091 port (or whatever you set the RPC port to be) to your server. This is especially handy if you also run a dynamic DNS service, because then you can access your server from anywhere using a URL and a port number. I use Transdroid on my Android phone to check up on my torrents, or add them via an excellent search interface.

Web Access

To access the server, point your web browser to http://your.server.ip.address:9091. (9091 is the default port, which can be changed, under “rpc-port”, in the settings file.) The web interface is pretty simple. Note that you can adjust some settings, such as transfer speed and download directory, by clicking the gear on the lower right of the page. The open dialog supports URLs to torrent files, magnet links, and uploading a torrent file from your computer.

The Watch Folder

Simply move torrent files to the watch folder to start a download. If your watch folder is accessible via Samba share, SFTP, WebDAV, or what have you, you can add torrents to it while on the go, without a browser.

I prefer to use Samba shares to serve my media files to my front-end player, the WD TV Live. That said, not all front-ends work with Samba shares; my TV and my iPod Touch come to mind as products that work with media servers, not with file shares. There are several media servers on the market that work well with TVs and PlayStation 3’s. I prefer MediaTomb, a uPnP-compliant server, because it is simple to install and configure. MediaTomb works flawlessly with my WD TV Live, and allows me to stream video (mostly AVI files), audio (mostly AAC files with .m4a extensions), and photos from my server to my TV.

Install MediaTomb

MediaTomb is simple to install on Ubuntu Server because a Debian package for it is in the repositories. To install MediaTomb, simply install the mediatomb package.

$ sudo apt-get install mediatomb

The MediaTomb daemon will start automatically after installation.

Configure Port Number

By default, MediaTomb will pick the first available port starting with 49152. When restarting the server, it may pick a different port, such as 49153. I prefer to lock MediaTomb down to a certain point, so my bookmarks for the web interface are always correct, and so I can set firewall and networking rules consistently.

To lock MediaTomb to a single port, simply edit the XML configuration file.

$ sudo nano /etc/mediatomb/config.xml

Find the  <name> element in the configuration file. (You can rename its contents if you wish to. Personally, I don’t like the word “tomb” displayed on my TV, so I rename the service “MediaServer”.) Underneath the element, insert a
element, as follows:

<port>49152</port>

Save the configuration file, and restart the service.

$ sudo service mediatomb restart

Now MediaTomb will be locked down to port 49152. You can now set up your firewall to allow traffic on that port.

Add Media Files to MediaTomb’s Library

MediaTomb needs to be told where your media files reside in order to serve them. For simplicity, I prefer to keep all my media files in one folder tree, with high-level subfolders corresponding to media type. My media folder tree is within my home directory; your media may be spread out over your hard drive. MediaTomb doesn’t really care; you simply need to add each folder your media is in to the media library.

  • media
    • movies
    • music
    • photos
    • tv

Add Media to MediaTomb

To add my media folder to MediaTomb, I use MediaTomb’s web interface. I point my browser to my server’s IP address, plus the port it is running on, as follows: http://serverip:49152.

MediaTomb’s sparse web user interface will appear. You will want to click on the Filesystem link, then browse the file system tree to find your media folder. Click on the media folder you wish to add, then click the icon that looks like a plus sign with two sync arrows, as in (+). This button calls up a form that allows you to add that folder to the media library, and set up automatic updating.

Set the scan mode to Inotify, the initial scan to Full, and check the Recursive checkbox. Then click Set, and you have added the folder. MediaTomb will scan the folder for media files to serve. Because we selected the Inotify scan mode, MediaTomb will monitor this folder tree for file changes, and update the media library accordingly. This allows you to add and remove media using Samba or the command line.

Repeat this process for each media folder on your server. Note that Inotify will not work with media served from remote file shares; you will need to set scanning to a timed interval.

Note: It is possible to add media via the command line, but it does not work well for the packaged Ubuntu install.

Connect to your Server

After setting up the server and adding media to it, you are essentially done. Your front-end device should automatically discover MediaTomb on the network.

I use the WD TV LIVE as a HTPC front-end. Because of latency problems with my wireless network, I attached a USB stick to the WD TV LIVE to use for video storage. The player allows me to expose that USB stick to the network via “Windows” (Samba) file sharing. I would push video to it from my media server after hours, so it would be ready to watch the following day. I tended to move the files via shell scripts kicked off by cron jobs (or other triggers), or via SSH.

Now I have a new wifi network (802.11n), and I can stream almost all content to the WD TV LIVE directly from the media server. Bandwidth and latency are a problem, however, with very large files, such as 1080p video and Blu-Ray rips. To handle this content, I still have to transfer it to local storage on the WD TV LIVE front-end.

Install Samba File System

The most transparent way to connect to a samba share it to mount it to a mount point on your filesystem. To do so, you need to install the Samba File System (smbfs).

$ sudo apt-get install smbfs

Mount the Samba Share

You mount the samba share like any other hard drive. First, create the mount point, which is simply a folder.

$ mkdir ~/wdtvlive

Next, mount the share to the mount point. Note that I’m using the host name, instead of the IP address. You can use the IP address, or configure your server to allow the use of host names. Note the use of options following the -o argument. Your security needs may differ.

$ sudo smbmount //WDTVLIVE/32GB_STICK ~/wdtvlive -o guest,rw

Now you can use the folder ~/wdtvlive to browse the fire share. The file share is now part of the file system, so utilities such as rsync will work with it as it it was a local folder.

You can unmount the share via the following command:

$ sudo smbumount ~/wdtvlive

Optional: Permanently Mount the Samba Share

To mount a Samba share permanently, you have to add a line to the server’s file system table. First, edit the FSTAB:

$ sudo nano /etc/fstab

Next, add a line, as follows. Note that the file system type is “cifs”, for “Common Internet File System”. The other options essentially set security wide open on the drive, which is acceptable for my use case, but certainly not for every one.

//WDTVLIVE/32GB_STICK /home/mjdescy/wdtvlive cifs guest,rw,iocharset=utf8,file_mode=0777,dir_mode=0777 0 0

Then, save and close the file. Finally, remount all drives.

$ sudo mount -a

Now your file share will be mounted in the file system, and it will be persistent between server reboots.

I want my Ubuntu media server to be able to push content to my WD TV Live, which I use to view content on my TV. My WD TV Live is on my wireless network, but I found that the network is not fast or reliable enough to stream 1080p content, or even 720p content under certain conditions. For this reason, I purchased a flash drive to act as local storage on the player, and enabled file sharing on it. I wish to push content from my media server to it (manually or with Bash scripts), so I decided to mount it to my server’s file system using smbfs, the Samba file system package. To make it easier to mount the shares, I first set up the server to allow the use of Windows host names to identify file shares.

Doing so is quick but not entirely intuitive.

Install WinBind

First, you will need winbind installed. It is one of Ubuntu Lucid’s default packages, so I did not need to install it. If don’t have that package installed for some reason, simply run:

$ sudo apt-get install winbind

Edit Name Server Switch Configuration

Next, edit the name server switch configuration file, which lists the databases the networking interface will use to resolve host names.

$ sudo nano /etc/nsswitch.conf

Under the “hosts” heading, add “wins” prior to “dns”. my file looks like this:

hosts:          files wins dns

Restart Networking

Finally, restart networking. I found that I could do this even while logged in under SSH.

$ sudo /etc/init.d/networking restart

After that, you’ll be able to use host names to connect to Windows/Samba shares.

For simplicity, I tend to stream from my media server to my TVs and computers using Samba shares. Samba shares implement the standard CIFS file-sharing protocol, are accessible from every major operating system, and work just fine with most media front-ends (for example: XBMC, Boxee, Windows Media Center, and my WD TV LIVE set-top box).

Create Folder Tree to Share

First, create the folder tree you wish to use for most of the file operations on the server. I created, under my home directory, a dl folder for downloads, and a media folder for all types of media.

I created subfolders under “dl” for Transmission to use for torrents that are downloading, seeding, complete (that is, seeding is complete), and a watch folder for incoming torrent files. I created subfolders under “media” for different types of content the HTPC front-ends expect to see. I share the entire home folder for general file maintenance, and the media folder, separately, as a read-only share for guests (the HTPCs.

  • dl
    • complete
    • downloading
    • seeding
    • watch
  • media
    • movies
    • music
    • photos
    • tv

$ mkdir -p ~/dl/complete
$ mkdir  ~/dl/downloading
$ mkdir  ~/dl/seeding
$ mkdir  ~/dl/watch
$ mkdir -p ~/media/movies
$ mkdir ~/media/music
$ mkdir ~/media/photos
$ mkdir ~/media/tv

Install Samba

Ubuntu Server’s installer offers you the option of installing Samba. If you did not elect to do so, it is simple to invoke the exact same install process from the command line. It happens that apt-get isn’t the command you use here. Instead, you use tasksel, which is meant to install groups of software packages based on tasks (such as file sharing, in this case).

$ tasksel install samba-server

Configure Samba

To use Samba shares, you need to configure the daemon. The default configuration file is verbosely documented, so most of the work you will do in this file involves commenting out various lines.

You will have to edit the Samba configuration file to create file shares and alter the configuration.

$ sudo nano /etc/samba/smb.conf

First, lock down Samba to your local network, because it is not considered good security practice to run Samba over the Internet. Under the “[global]” section, add a line to allow only hosts on your network, which is most likely defined as “192.168.1.0/24” or “10.0.0.0/8”.

hosts allow = 192.168.1.0/24

If you are concerned about streaming performance, you can also add/edit the socket_options parameter, under the “[global]” section, to read as follows. These settings are meant to lower latency and to set large send and receive buffers.

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536

To define the home folder share, add the following section to the bottom of the file. (You could also uncomment and edit lines in the “[homes]” section.) This will set up folders for all users on your server, locked down by their username/password.

[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0775
directory mask = 0775
browseable = No

Finally, set up a simple, read-only share for the “media” folder.

[media]
comment = Media Server
path = /home/mjdescy/media
guest ok = Yes

Save the configuration file, and reload the daemon.

$ sudo service smbd restart

Wrap-Up

After setting up Samba and restarting the daemon, you will be able to connect to the shares as if they were Windows file shares. The “media” share can be used without a specific account. The “homes” shares will be named after each login user name on the system. On my network, I can use my server’s hostname to connect to the shares. If that does not work for you, try using the server’s IP address.

My media server runs headless, so I need a way to log into it from other machines for remote administration. Telnet is installed by default on Ubuntu Server, but it does not offer a secure, encrypted channel to the server, even when transferring the password. SSH, on the other hand, offers all the features of Telnet, and a lot more—including a file transfer protocol, SFTP—all within the secure, encrypted channel we want to use to connect to our server.

The most appropriate way to remotely manage an Ubuntu Server is via Secure Shell, or SSH. SSH allows you to make a secure connection to your server, which you can use for many different purposes. Most of the time, you use SSH to log in to a shell for remote administration; think of it as a secure Telnet. You can also use it to transfer files via SFTP, or as a tunnel for rsync. You can also use it to forward or tunnel ports, or to set up a simple VPN. On Ubuntu, OpenSSH is the most common Secure Shell server. The instructions below apply to Ubuntu Server 10.04, Lucid Lynx.

Installing OpenSSH

Ubuntu Server’s installer offers you the option of installing OpenSSH. If you did not elect to do so, it is simple to invoke the exact same install process from the command line. It happens that apt-get isn’t the command you use here. Instead, you use tasksel, which is meant to install groups of software packages based on tasks (such as file sharing, in this case).

$ tasksel install openssh-server

Configuration

My needs are simple: I merely want to connect to my server through the standard port (22), log in via my user name and password, and use the Bash shell or SFTP. I don’t need to use a public key-based authentication, or run the server on a nonstandard port, because it is not accessible from outside my home network. Fortunately for me, the default configuration suffices; I have never had to touch the OpenSSH configuration files.

Logging In via SSH

Logging in from other computers on your network is pretty simple. Macs and many Linux and Unix-like distributions include an SSH client by default, so you can open a terminal and issue a SSH command, as follows.

$ ssh 192.168.1.3

SSH clients assume that your account name on the remote machine is the same as it is on the local client. If the account name is different, you simply have to specify it in the SSH command.

$ ssh account@servername

On Windows machines, you have to install an SSH client, such as PuTTY, to SSH into your server.

Transferring Files via SFTP

OpenSSH includes modules for file sharing via SFTP, or SCP, which is an older protocol. The easiest way to use SFTP is via a SFTP client, which will provide a nice GUI to transfer files, just like through FTP, but through a secure channel. Typical SFTP clients include WinSCP (Windows), CyberDuck (Mac), and FileZilla (all platforms). You simply have to configure the client to log into your SSH server via port 22, your username, and your password.

Important: Uninstall Telnet

Once you have set up OpenSSH for remote administration, I strongly urge you to uninstall Telnet. Telnet does not encrypt any data between the remote computer and the server, so your password and other information could be intercepted over the network. Even if you think your network is secure, there’s little overhead involved with running OpenSSH instead of Telnet, so there is not much benefit for keeping Telnet installed.

$ sudo apt-get remove telnetd

A server should have a static IP address, so you can always find it on the network. Ubuntu Server uses DHCP out of the box, unless you set a static IP address using the installer. To change from a dynamic to a static IP address, follow the instructions below, which apply to Ubuntu Server 10.04 Lucid Lynx.

Configure Your Router

Your router most likely has a range of IP addresses that it uses for DHCP, and it probably default to the entire subnet, minus the router itself. If you set a static IP address within the DHCP range, it may cause problems with the router. It is better to carve out a small range (say 192.168.1.2 through 192.168.1.9) for static IPs. Therefore, you will want to configure your router’s DHCP address range to something like 192.168.1.10 through 192.168.1.254.

Set the Static IP Address

To set a static IP address on Ubuntu Server, edit the network interfaces file.

$ sudo nano /etc/network/interfaces

If you set up your server to use DHCP, your networking interfaces file will contain entries such as the following

# The primary network interface
auto eth0
iface eth0 inet dhcp

To change from DHCP to a static IP address, change “dhcp” to “static”, then add the address (whatever static IP address you want), gateway (the IP address of your router) and netmask (255.255.255.0 if your router IP is 192.168.1.1).

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.3
gateway 192.168.1.1
netmask 255.255.255.0

Save the file, and restart networking.

$ sudo /etc/init.d/networking restart

Now, you will be using the IP address you have chosen. If you were performing this action via SSH, your session will be dropped if the static IP address is different than the DHCP IP address. This is OK. Just SSH using the new static IP address.

Stop the DHCP Client

Even after restarting networking services, the DHCP client will still be running, and it can change your IP address unexpectedly. Therefore, you have to kill it to avoid your IP address being reset.

$ sudo killall dhclient3

If you never want to use DHCP again, you can remove the DHCP client entirely. I don’t recommend this for a home server, so proceed with caution here. If you leave the DHCP client installed, it will not run automatically, even after reboot, but it is available to call via the command line, should you need to.

$ sudo apt-get remove dhcp3-client

An Alternative: Static DHCP

If your router has a static DHCP feature, you could simply leave DHCP enabled and reserve an address for your server. I did this for years, and think it an easy alternative to setting a static IP for a server on a home network.

Because I fried my server’s hard drive, I had to reinstall Ubuntu Lucid Server. Of course I didn’t have a Lucid Server disc, and, because physical media is dead to me, I didn’t have any blank CDs to burn. I don’t have any spare thumb drives, either. Therefore, I couldn’t install Lucid server. Instead, I had to install Hardy Server (Ubuntu 8.04) using the old disc that I did have on hand, and upgrade it via the package manager. Fortunately, this was really simple.

Performing the Upgrade

After I installed Hardy via CD, the first thing I did was issue the command

$ sudo do-release-upgrade

This is the command to upgrade to the latest release. (It isn’t apt-get dist-upgrade, which is a common misconception.) It relies on the package upgrade-manager-core, which was installed by default by the Hardy installer.

The upgrade manager will determine which packages need to be removed, updated, or added. There are a few times during the upgrade that require interaction. You have to choose whether to keep or overwrite certain configuration files. (I chose to overwrite them, since I was upgrading from a fresh install.)

After the scripts ran, I rebooted the server. Upon logging in again, I ran the following command to determine which version of Ubuntu I was using:

$ lsb_release -a

Sure enough, it told me I was running the latest LTS release.

mjdescy@thor:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.1 LTS
Release: 10.04
Codename: lucid

How to Upgrade to a non-LTS Release

The configuration file for the upgrade manager is found in /etc/update-manager/release-upgrades. This file has one setting, called prompt, that you can change to suit your needs. I didn’t have to change it, because the default setting tells the update manager to look for LTS (long-term support) releases only. (Lucid and Hardy are both LTS releases.) If you change prompt to normal, the upgrade manager will allow you to update to non-LTS releases, such Maverick Meercat, once they are released.

How to Upgrade to a Development Release

After changing the upgrade manager prompt to normal (see the section above), you can also upgrade to a development release by running the upgrade manager with -d argument. In the past, I ran this method to upgrade from Hardy to Lucid prior to Lucid’s final release.

$ sudo do-release-upgrade -d

I have a Fit-PC Slim, which I use as a media back-end server on my home network. Because a Fit-PC Slim has only a 500 MHz processor and 512 MB of RAM, it is too underpowered to be a media transcoder or recorder. Therefore, I mostly use it as a file server and a torrent slave. My goal for rebuilding this server was to make it a smart, well-configured media downloader and file server for use with my WD TV Live HTPC front-end. Many other front-ends will also work very well with this setup.

Over the next week or so I am going to post articles which show how I installed and set up the OS and all the services listed below.

Operating System

Essential Services

  • OpenSSH, for remote administration and SFTP file transfer.
  • Samba file sharing, for cross-platform file sharing, including serving files to a front-end HTPC on the home network.
  • Transmission, for downloading content via BitTorrent.
  • FlexGet, for automatic download of TV series.
  • TVNamer, for automatic renaming of downloaded TV series files to recognizable names, and to move them to their storage location.

Non-Essential Services

  • A custom script to clean up old torrents on Transmission.
  • MediaTomb, a uPNP media server. (This is non-essential because I use Samba to access media files from my front-end HTPC.)
  • Lighttpd, a lightweight web server for HTTP and/or WebDAV file serving.
  • Monit, for point-in-time service monitoring via a web front-end, and to restart services if they crash.
  • Munin, for longitudinal monitoring (charts and graphs) of CPU usage, file system activity, network activity, and so on, via a web front-end.
  • Firewall setup via UFW. (This is “non-essential” because the server is already behind my router’s firewal.)
  • Winbind, to allow the server to connect to Windows/Samba shares via host name, instead of IP address.
  • Samba file system (smbfs) to allow the server to connect to external Samba shares, such as those on front-end HTPCs.