...making Linux just a little more fun!

Serving Your Home Network on a Silver Platter with Ubuntu

By Shane Lazar

Linux has always been a good choice for a server OS. In practical terms, however, this functionality has been out of reach for the everyday computer user, mainly due to the technical know-how required to manage a dedicated server OS. On the other hand, our homes today are more filled with computers than ever before - and, in a multi-node network, a server can provide many benefits. In this article, I am going to try to guide you in setting up a useful server for your home network, one that is headless (i.e., without monitor, keyboard, or mouse) and can be stowed away neatly out of view.

This setup will be ideal for:

Hardware required:

The basic setup:

Internet <--> Ubuntu Server <--> Ethernet Hub <--> LAN Machines

Services we are going to be running on our system:

Let us dive right in!

1. Getting Ubuntu

Download the Ubuntu (currently at version 7.04, "Feisty Fawn") Server CD image from Ubuntu's download page.

2. Making the installation CD

Burn the ubuntu-7.04-server-i386.iso image to a CD using your favorite image-burning program. Remember, burn the image; do not extract the files from the image file. If you are going to be using an old CD-ROM, burn the CD at the slowest possible speed, for reliability.

3. Installing Ubuntu on Your Server

Ubuntu is well known for having an easy installation process. For now, plug in a monitor, keyboard, and the network cables (Internet and LAN, both), put in the Ubuntu server CD, and boot up! You may need to change your BIOS settings to allow booting from CD.

  1. Select the hard disk installation, choose your desired language, then pick your country and keyboard.
  2. Configure the network interface connected to the Internet, using one of 3 options: autoconfiguration, autoconfiguration with DHCP (automatically assigned IP addresses), or manual. Which one you choose really depends on your Internet connection; ask your ISP, if in doubt. If you have to configure manually, configure your Internet connection on the eth0 network card, for simplicity's sake.
  3. For partitioning, I recommend "Guided - use entire disk", as it is a no-brainer, and accept the settings, thereby writing changes to disk.
  4. Allow the system clock to be set to UTC.
  5. Create the system administrator's user account; enter the full user name, account name, and administrator's password (which has to be verified).
  6. Ubuntu will continue to install the base system.
  7. Enter your ISP's proxy server settings, if required.
  8. When you are asked to choose the software to install, select both DNS and LAMP server. You do this using the spacebar to check the boxes, cursor keys, and TAB, to navigate through the menu.
  9. Complete the installation, reboot, and you will be presented with a command-line interface (CLI) prompting you to log in. Use the administrator account name and password to do so.

Before we continue, I did mention that I would try to make this as simple as possible, and now you are probably wondering what you are doing in a CLI. This is necessary, as we want our server to run as lean as possible. After all, it is going to be stowed away in a closet, so who needs a fancy GUI? I promise we won't be spending much longer on the CLI. A couple of tips for new users:

4. Checking Internet connectivity

First thing we will do on our new system is to check if we are connected to the Internet. Do this simply by pinging Google.

ping www.google.com

Stop the pinging with Ctrl+C. If all went well, you should be getting responses to your pings. If not, try switching the LAN and Internet cables around. Most probably, you will get a ping response by now. Keep in mind which card your Internet is configured on, eth0 or eth1, and modify the instructions accordingly. In this guide, the Internet is on eth0 and the LAN is on eth1.

5. LAN network configuration

Now, we will configure our LAN network card. We will do this using vim, a CLI text editor.

Four simple commands you will use in vim are:

Let us open our network configuration file with administrative privileges:

sudo vim /etc/network/interfaces

You will be asked to enter the administrator's password. Navigate with the cursor key and add the following at the end of this file:

auto eth1
iface eth1 inet static

If you need to change the configuration of your Internet connection, you should do this now in the eth0 section. Restart your network interfaces using:

sudo /etc/init.d/networking restart

6. Update Ubuntu

Install any available updates by:

sudo apt-get update

and then

sudo apt-get upgrade

7. Installing Webmin

Now we will install the packages required for Webmin, the Web-based administration tool:

sudo apt-get install libnet-ssleay-perl openssl libauthen-pam-perl libio-pty-perl libmd5-perl

Download Webmin:

wget http://prdownloads.sourceforge.net/webadmin/webmin_1.350_all.deb

If this does not work, there is probably a newer version of Webmin. Get the link to the latest *.deb file from the Webmin site.

Install it:

sudo dpkg -i webmin_1.350_all.deb

You will get the following output:

Webmin install complete. You can now login to https://your-server-name:10000/ as root with your root password, or as any user who can use sudo to run commands as root.

And that's it! We are done with the CLI. Log out:


Now, you can disconnect the monitor and keyboard, stow your server away, and continue from your desktop machine on a beautiful Web-GUI!

8. Configure your LAN machines

However, before you do that, you will have to configure your desktop machine's network card. Set it up as follows:

IP address:
Subnet mask:
DNS server:

Your other machines would have incrementing IP addresses, e.g.,,,...

9. Upgrade Webmin

Open your favorite Web browser and navigate to Enter the administrator's user name and password. Welcome to the powerful Webmin!

On the tree menu on the left, go to Webmin > Webmin Configuration. Click Upgrade Webmin, and, with "Latest version from www.webmin.com" selected, click the Upgrade button. If there is an upgrade available, it will be installed for you.

10. Shorewall Firewall

To install the Shorewall firewall, go to System > Software Packages and in the "Install a New Package" section, select "Package from APT", enter shorewall, and click Install. This may take some time, depending on your Internet connection, but Shorewall will be installed.

Now, go to Networking > Shorewall Firewall, and we'll begin setting up your firewall. Do not start the firewall yet, or you might lock yourself out of the server. We will configure Shorewall section by section.

Network Zones: This section defines zones to which we will assign "levels of trust". We will create three zones: the firewall, Internet, and local zones.

Click Add a new network zone. You will be provided with a number of options. We are interested in the Zone ID field and the Zone type list. For each zone, enter the options as follows, and click Create before returning to the page to create the next.

Network Interfaces: This section tells the firewall which Ethernet card is connected to the Internet, and which one to the LAN. In our case, we have only two interfaces.

Click Add a new network interface, and again you will be presented with a vast array of options. We will define only Interface, Zone name, and Broadcast address. Here, also, you will have to setup one interface at a time, clicking Create before returning to configure the next. Configure as follows:

Default Policies: The default policies tell the firewall what to do with packets coming from various sources. We will set it to drop all requests from the Internet, and accept all from the LAN and the firewall itself. Click Add a new default policy. As before, we will define one policy at a time, clicking Create before proceeding. Configure the policies as follows:

Firewall Rules: This section defines specific rules for specific services. We will enable them as the need arises, later.

TOS: This section optimizes Web browsing as much as you can on your end. Click Add a new type of service, and we will proceed to configure the services one by one.

Masquerading: This tells the server to forward requests from the LAN to the Internet, which is required for Internet connection-sharing. Click Add a new masquerading rule, and enter the following rule.

When Stopped: This allows machines whose IP addresses are specified to access the server even when the firewall is not running. No other IP addresses will have access. Add as many as you want, but there should be at least one, just in case. In the example below, I have allowed access from two IP addresses on the LAN. Click Add a new stopped address, and configure as follows:

We don't need to add any other settings.

Back on the Shorewall main page, click "Check Firewall". You should get the thumbs up. Note that an "OK" result here does not guarantee the firewall will work properly, or will work at all. It simply checks the rules syntax.

There is a security feature that prevents an unconfigured Shorewall from being started up, when booting. This has to be changed manually. For this, you will need a Java-enabled Web browser to do it using Webmin, or you could resort to using vim from the CLI.

What you have to do is change the line


in the file /etc/default/shorewall to


In Webmin, go to Others > File Manager. This will give you a nice Java-based file manager. Navigate to the above mentioned file, and click the "Edit" button at the top. A text editor window will pop up. (Disable pop-up blocker.) Make the change, and then save and close.

Again, using this browser, browse to the file /etc/shorewall/shorewall.conf, click "Edit", and find the line IP_FORWARDING=Keep. Change the value from Keep to On. Save and close.

Now, let us make sure that Shorewall is set to start at bootup. Go to System > Bootup and Shutdown, look for shorewall in the list. Tick the checkbox, and click "Start Now and On Boot" at the bottom. Go back to the Networking > Shorewall Firewall page, and you should see six buttons where there were previously only two. Click "Show Status", to verify that all is running well. Your Internet connection sharing should be set up, now. Try it out!

11. BIND DNS Server

Ubuntu server pretty much does all the configurations necessary for a working BIND DNS server. There is, however, one thing we can do to make the lookups faster. We can tell our server to forward unknown requests to your ISP's DNS server.[1]

Go to Servers > BIND DNS Server, click on "Forwarding and Transfers", and, in the fields marked "Server to forward queries to", enter the IP addresses of your ISP's DNS servers. Save, and click "Apply Changes" in the main BIND DNS server page.

12. Squid Proxy Server

Now, we will move on to installing and setting up Squid as your caching proxy server. Go to Servers >Squid Proxy Server. Webmin will inform you that Squid is not installed on your system, and provide you with an option to install it using APT. Click on the link (labelled "Click here") provided, to install Squid. Webmin will keep you informed of the progress and, once completed, will give you some information on the installed packages.

Go back to the main page for Squid, and now you should have a host of configuration tools available. I will not explain all the options available, but, if you require more clarification, help is available at the top left of the tool's page. (You will have to disable your browser's popup blocker.)

Ports and Networking: Here we will tell Squid which port it will be listening on. The default is port 3128. We will stick to this, but you can change it. In the "Options for port" field, enter transparent. This will make Squid a transparent proxy server, which eliminates the need to configure machines on your LAN. Save the changes.

Memory Usage: Here, you can define memory usage limits for Squid, or choose to go with the default settings. I would draw attention to the "Maximum cached object size" option. Here, you can define the maximum size of cached files.

Cache Options: The option I would recommend you changing here is the "Cache Directories" one. Squid defaults to a 100MB cache, which is pretty minuscule for our caching proxy objective. Decide how much of your hard disk you wish to use for the cache; I use 5GB out of my 40GB hard disk. In the "Directory" field, enter /var/spool/squid, "Type" as UFS, in "Size (MB)", enter however much you decided on in megabytes, for the 1st- and 2nd-level directories, enter one of the following numbers; 16,32,64,128 or 256 (defaults being 16 and 256, respectively). These numbers basically define the file structure of your cache. Read the help documentation, for more information on this and other options. Save your changes.

Helper Programs: In the "DNS server addresses" field, enter, select the radio button, and save. This tells Squid to send DNS requests to the BIND DNS server running on your server.

Access Control: Here, we will define which LAN machines will be able to use Squid, by their IP addresses. At the bottom of the "Access Control Lists" section, select Client Address from the drop down list, and click "Create new ACL". In the page that appears, enter a name of your choice in the "ACL Name" field (e.g., Local_Network), define the range of IP addresses you wish to grant access to, and the Netmask, e.g., From =, To =, Netmask = If you would like to grant access to all machines on your LAN, enter as follows; From =, To = *leave blank*, Netmask = Save your changes.

Having defined the machines on our LAN, we will now tell Squid what to do with requests from these machines. Click "Add proxy restriction" in the "Proxy Restrictions" section. Select the "Allow" action, and the ACL you just created (Local_Network) from the "Match ACLs" list. Save your changes.

Your new restriction will be at the bottom of the restrictions list, and, since they are effectuated in order, you will have to move your new rule up the list to third place. Do this using the "Move" arrows, to the right of the defined restrictions.

For security reasons, we will create a new user named squid who will run squid. Go to System>Users and Groups. Click "Create a new user", and enter the following;

Leave the rest unchanged. Click "Create".

Now, we will grant permissions to the user squid to write to our cache. Go to Others > Command Shell, and execute the following command:

chown -R squid:squid /var/spool/squid/

Return to the Squid Proxy Server page.

Administrative Options: In the "Run as Unix user" field, click the browse button, and select squid from the list of users. In the "Visible hostname" field, enter the name of your server. This you can find out from the "System Information" page in Webmin, as "System hostname". Save the changes.

Click "Initialize Cache". Once this terminates successfully, return to the Squid main page and click "Start Squid". Since we are making a transparent proxy server, we need to add some rules in the firewall, to redirect requests to pass through Squid. Go to Networking>Shorewall Firewall>Firewall Rules>Manually Edit File, and paste the following rule:

#squid transparent proxy redirect
REDIRECT	loc	3128	tcp	www

If you changed the port Squid listens to, earlier on, use that port in this rule, instead of 3128. Save the changes, and Apply Configuration.

Test if your desktop machines have access to the Internet. The difference between a simple Internet connection sharing and using a caching proxy is that frequently visited Web sites will load faster, as some content is stored on your server.

13. Samba file sharing

Now, we'll move on to installing and setting up Samba for file sharing to both Linux and Windows machines. Go to Servers > Samba Windows File Sharing. As was the case with Squid, Webmin detects that Samba is not installed, and provides an easy link to install it using APT. Go ahead and click the link, to download and install Samba. Once this is done, we will now configure file sharing.

Since we are sharing on a trusted network, we will setup our file server with read and write permissions for everybody.

Return to Servers > Samba Windows File Sharing, and, in the first section, click "Create a new file share", then complete as follows:

This will create the share public, with Read-only permissions for all. Using Others > File Manager, navigate to /home, select the folder public, and click Info. In the info window that opens, in the Permissions section, select all the checkboxes for User, Group, and Other, thereby giving permission to everybody to read and write to this folder.

Now, navigate to /etc/samba, select smb.conf, and click Edit. Look for the line

; security = user

and change it to

; security = share

Scroll down to the end of the file, to find the section which describes the share we just created, and edit it to it look like this:

	comment = public
	path = /home/public
	public = yes
	writable = yes
	create mask = 0777
	directory mask = 0777
	force user = nobody
	force group = nogroup

Save and close. If you need to change your Workgroup, do that from the Windows Networking tool in the Global Configuration section on the Samba Windows File Sharing page. Samba's default workgroup is, ironically, MSHOME. Click Restart Samba Server, and verify that you have access to the shared folder with read and write permission from your desktop machine, by creating and deleting a file in the share. The only settings you will have to enter on your LAN machine to gain access are:

14. TorrentFlux

For those of us who use Bittorrent for peer-to-peer file sharing, we will install TorrentFlux, which is a Web-based Bittorrent client. Some of the advantages of using TorrentFlux include;

In your Web browser, go to the TorrentFlux Web site, and download the latest version of TorrentFlux. In Webmin, go to Others > Upload and Download. In the "Upload files to server" section, browse to the torrentflux_2.x.tar.gz file you just downloaded in the "Files to upload" field. In the field "File or directory to upload to", enter /var/www. Select in the Extract ZIP or TAR files options the Yes, then delete radio button. Click "Upload" to upload, and unpack TorrentFlux.

Using Other>File Manager, browse to the /var/www/torrentflux_2.x directory, and double-click the INSTALL file, to open it in your browser. Read the instructions carefully.

First, and very important, we will set the root password for our MySQL database. Note that this root user is different from the system root user. The same applies to all MySQL users.

Go to Servers > MySQL Database Server, and click User Permissions from the Global Options section. From the list of users, click on any of the instances of root. In the password field, select Set to.., and enter a password for the MySQL root user. You may be asked to log in, after setting the password. Repeat for all the other instances, with the same password.

TorrentFlux uses MySQL for its database features. So, let us go ahead and create a database for TorrentFlux. On the main MySQL page, click Create a new database. In the "Database name" field, enter torrentflux and don't make any other changes. Click Create.

To create the required tables, click on the torrentflux database we just created, then click the "Execute SQL" button. In the second section, which says "Select an SQL commands file to execute on database", select "From local file", and browse to the file /var/www/torrentflux_2.x/sql/mysql_torrentflux.sql, click Ok, and then Execute. Now, if you return to the table list, you will see that some tables have been created.

For security reasons, we will create a MySQL user specifically for TorrentFlux. On the MySQL main page, click "User Permissions", and then "Create new user". Enter the following, and make sure to select the appropriate radio buttons:

Don't select any of the permissions, and Save.

Now, we will allow this new user to modify the torrentflux database, only. Back on the MySQL main page, click on "Database Permissions", and then on "Create new database permissions". Remembering to select the appropriate radio buttons, select the following;

For the permissions, hold the Ctrl key, and select the following;

That's it; we're done with MySQL!

Now, we will tell TorrentFlux about the database settings we have just implemented. Using the Java browser, navigate to /var/www/torrentflux_2.x/html, select the config.php file, and click "Edit". Modify the "Your database connection information" section, entering the correct settings. Hints are provided. It should look something like this:

$cfg["db_type"] = "mysql"; // mysql, postgres7 view adodb/drivers/
$cfg["db_host"] = "localhost"; // DB host computer name or IP
$cfg["db_name"] = "torrentflux"; // Name of the Database
$cfg["db_user"] = "torrentflux"; // username for your MySQL database
$cfg["db_pass"] = "
*password for MySQL user torrentflux*"; // password for database

Save and close.

Now, we will tell the Web server, Apache httpd, to serve TorrentFlux on port 80. Go to Servers > Apache Web server. You should have a Default Server and a Virtual Server, set up for you already. Click on the Virtual Server, and, at the bottom, in the "Virtual Server Details" section, make the following changes;

and Save. Then, on the Apache server page, click "Apply Changes" at the top right.

Now, in your browser, navigate to, and you should get the TorrentFlux login page. Note that the username and password you enter here will create the administrator's account settings. Don't forget these. Choose wisely, and proceed to login.

You will be taken to the settings page, where we will change a few things.

Have a look at the other settings, and change them as you wish. You can change them later, as well. Click "Update Settings". There are "lights" that indicate problems in your settings. All should be green. Notice that TorrentFlux will download directly to our shared folder, giving instant access over the LAN.

A nice feature of TorrentFlux is queueing. Click on "queue" at the top, and choose if you want to enable it, and define how many torrent connections you want to allow to run in total (server threads) and per user (user threads). Click "Update Settings". Going with the 40% max download bandwidth per Torrent and allowing two connections total to run at a time still leaves 20% of the bandwidth for Web browsing.

Use the "new user" page to create normal or admin users for any one you want to grant access to. Other settings include search engine options and filters, external links, rss feeds, and database backups.

Adding torrents is done either by uploading from your desktop machine, pasting the URL of the torrent file, or searching using the available search engines. Files will be saved in folders according to TorrentFlux usernames in the shared folder.

Now, we will open ports 40000-40010 in Shorewall for the Torrent software to work properly. Go to Networking > Shorewall Firewall >: Firewall Rules > Manually Edit File, and paste this rule at the end:

ACCEPT	net	$FW	tcp	40000:40010

If you wish to access your TorrentFlux from the Internet, e.g., while at work, and have a static external IP address, simply open port 80 on the external firewall, by adding this rule:

#Apache Web server
ACCEPT	net	$FW	tcp	80

Click Save, and then Apply Configuration in the Shorewall main page. You can then access TorrentFlux from anywhere, by browsing to http://*your external IP address*

If you have a dynamic IP address, then you will also have to use a service such as that provided by Dynamic DNS, which is free. Instructions for this are available on ubuntuguide.org. Although they are meant to be done at the actual machine, you can do them through Webmin, running the sudo commands in Others > Command Shell and editing the dyndns_update file in the Java file manager tool.

One thing to be wary of is completely filling up your hard disk. This will inevitably cause problems. So, just make sure you have enough space, before you decide to run your Torrent session.

15. System logs

Speaking of space, although system log files are useful in diagnosing problems, they sometimes occupy a whole lot of space. We will now limit the size of the log files.

Go to System > Log File Rotation>Edit Global Options and set the "Maximum size before rotating" to 50M (for 50MB) and the "Number of old logs to keep" to 4. This should allow you to have decent system logs, without eating up all your disk space. For a few days under normal use, keep an eye on the size of log files in /var/log using the Java file manager. See which logs are huge, fiddle with their settings in System>Log File Rotation and System>System Logs. Bear in mind that all that logging might be due to a real problem in your system. In general, though, the debug logs are pretty massive, and not very important for our purpose, especially the ones that debug network traffic.

16. Backing up Webmin configurations

Once you have set everything up, and all is working fine, it would be wise to backup your settings, in case you get too adventurous trying to fiddle around and break something, or even if you decide to change your server machine. This will enable you to restore all your settings.

Go to Webmin > Backup Configuration Files. In the "Modules to backup" list, select all of them (using the Shift key); for the Backup destination choose Local file, and enter a path, e.g., /home/*admin username*/backup-*date*.tar; in the "Include in backup" section, check "Webmin module configuration files" and "Server configuration files", and click "Backup Now". I recommend naming your backup files including the date, as choosing which one to restore from becomes easier.

If you wish, you can set up Webmin to periodically backup your configurations automatically, in the "Scheduled backups" section. I set mine to backup up daily and weekly. Previous scheduled backups are replaced, and only the latest one is kept. Restoring is simply a matter of choosing which modules to restore, from which backup file, and whether the configurations should be applied.

17. Updating your server

Once in a while, it would be wise to update your server to get the latest fixes and patches. Do this by going to System>Software Packages, and in the "Upgrade all Packages" section, select:

Click "Upgrade Now", and it will all be done automagically, giving all the information about the upgrade. Also periodic upgrades to Webmin, as we did at the beginning of this guide, are advisable.

Other tools

Some examples of other functionality you may be interested in including:

As you may have gathered by now, administering a Linux server is not a brain-twisting business, as some may have you think. Once you have everything set up to meet your needs, your LAN server/gateway should run like clockwork, requiring only occasional upgrades and maybe a pat on the back. Moreover, Webmin makes it a pleasant point-and-click affair, although, like everything else, you have to know what it is you want to do. This is where the vast documentation and help from the Linux community is priceless and indispensable.

With luck, everything has worked as expected, so far, and you now benefit from a free (as in free speech), powerful, flexible, easy-to-manage, easy-to-use, and cheap solution to your home networking needs. This, dear friends, is the brilliance of free and open source software!

[1] Rick Moen comments: On balance, I'd recommend against forwarding queries to one's ISP's nameservers. At minimum, users should understand the tradeoff.

Declaring forwarders in BIND declares a list of nameserver IPs to consult on all lookups BIND cannot answer from its local cache, in preference to the various nameservers that are authoritative for those domains, that would have been otherwise consulted. In the very short term, this gives you faster responses on early queries (i.e., for a short while after your local BIND instance fires up). After a while, most likely queries will be hits on the local cache, making your relatively high speed of access to the ISP's nameservers mostly irrelevant.

What you lose, through such forwarding, constitutes in my view a very serious drawback: you are making your DNS rely on the performance, reliability, and security of your ISP's nameservers. Most ISP nameservers turn out to have poor performance, are seriously lacking in performance and reasonableness of configuration, and have alarming security problems.

To be specific about some of those things: Many ISPs appear to have deliberately overridden the Time to Live (TTL) values that would normally be shared with cached DNS records, to artificially prolong the life of that cached information even though it may have been sent with low TTL values to keep cached copies from being used after becoming obsolete. The ISPs presumably do this, subverting the intended DNS-updating mechanisms, to reduce (needed) network traffic.

The worst problem is the security one: Studies such as Dan Kaminsky's have shown that a large number of ISP nameservers are vulnerable to cache poisoning, a form of attack in which they are induced to cache fraudulent data. This is especially true when those nameservers are used by forwarding nameservers in the fashion that this article describes.

The alternative, of course, is to just simply run your own recursive-resolver nameserver without forwarders, which by default will then get its data from the root zone and the immense tree of authoritative servers it defines. Fortunately, this works just perfectly without touching anything at all, out of the box, and imposes no performance deficiencies once you've started loading the cache.

I guess, overall, there's an instinctive tendency in people to think "Let's rely on the ISP's services, because they're the pros, and we should get better performance and reliability, that way." However, it turns out that, most often, none of those things is actually the case, and you can do much better on your own, with surprising ease.

One last suggestion: BIND9 is certainly a respected do-it-all nameserver, but is vastly overfeatured when all you need is a simple recursive resolver (and, in particular, aren't serving up locally defined domains of your own, which is called authoritative service). Also, BIND9 is infamously bloated and slow.

For all of those reasons, I long ago started keeping a catalogue of alternatives to BIND9, and in all honesty cannot say which of them I'd recommend, since I've stayed with BIND9 despite reservations, but you might browse the alternatives.

Talkback: Discuss this article with The Answer Gang

[picture] Shane is a Medical Resident in Romania. He has been a ardent user of FOSS and Linux since 2004. He spends a sizeable amount of time on Linux forums learning about it and helping others where he can. Currently his favorite distro is Ubuntu, while he has used Mandrake/Mandriva in the past on his desktop and still does for his home network server.

Copyright © 2007, Shane Lazar. Released under the Open Publication License unless otherwise noted in the body of the article. Linux Gazette is not produced, sponsored, or endorsed by its prior host, SSC, Inc.

Published in Issue 141 of Linux Gazette, August 2007