A quick update to let you all know that I’ve added a servers tab at the top of the site that will bring you to some pages with real-time information about the Quake 3 and Quake 4 servers I operate. This is something I’ve been meaning to do for awhile and finally had some time around the holidays to hack together enough (really ugly) PHP code to make it happen. Stop by these servers anytime if you’d like to get your frag on!
Update: Due to some security concerns I am no longer making these servers available publicly. As a result, I have removed the tab from the site.
(20170504 — The steps in this post were amended to address changes in recent versions of software — iceflatline)
In a previous post, I described how to install and setup pfSense in a home network. In this post I will describe how to configure pfSense to act as an Network Time Protocol (“NTP”) server, as well as how to configure various hosts in your network to synchronize their local clock to this server.
pfSense is a customized version of FreeBSD tailored specifically for use as a perimeter firewall and router. It can be managed almost entirely from a web-based GUI. In addition to being a firewall and routing platform, pfSense includes a long list of other features, as well as a package system allowing its capabilities to be expanded even further. pfSense is free, open source software distributed under the BSD license.
Originally designed by David L. Mills of the University of Delaware circa 1985, NTP is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks, and one of the oldest Internet protocols still in use. NTP uses User Datagram Protocol (UDP) port number 123. pfSense uses OpenNTPD, a free, easy to use implementation of NTP.
The versions for the software used in this post were as follows:
FreeBSD 11.0-RELEASE
pfSense 2.3.3-RELEASE-p1
Ubuntu 16.04.2 LTS
Windows 7 Professional (x64)
Configure OpenNTPD in pfSense
Before configuring the OpenNTP server, it’s a good idea to ensure that pfSense itself is keeping accurate time. The best way to do that is to have it synchronize its clock with one or more remote NTP servers. First though, you should make sure that the clock in the machine hosting pfSense is set to something close to accurate – if the difference is too great, pfSense will not synchronize properly with the remote NTP server.
Login to the pfSense machine using its “webConfigurator” (webGUI) interface. Navigate to System->General Setup and select the timezone that matches the physical location of the pfSense machine from among the options under “Timezone.” Next, enter the host name or IP address for the remote NTP server under “Timeservers” (Remember to add at least one DNS server under “DNS Servers” if you decide to use a host name instead of an IP address). Most likely you’ll find this field is already populated with one or more default remote NTP server(s) such as 0.pfsense.pool.ntp.org, 1.pfsense.pool.ntp.org, etc. These servers will work just fine in most cases, however you may get more accurate results if you use one of the continental zone servers (e.g., europe., north-america., oceania., or asia.pool.ntp.org), and even more accurate time if you choose to use one of the country zone servers (e.g., us.pool.ntp.org in the United States). For all of these zones, you can use the 0, 1 or 2 prefix, like 0.us.pool.ntp.org, to distinguish between servers from a particular region or country. (See the NTP Pool Project web site for more information on how to use pool.ntp.org servers). Like 0.pfsense.pool.ntp.org, these server entries will pick random NTP servers from a pool of known good ones. Also, while one NTP server is sufficient, you can improve reliability by adding more. Just make sure their host names or IP addresses are separated by a space.
Now that the pfSense machine is on its way to keeping accurate time, let’s configure its OpenNTPD server. Navigate to Services->NTP and pick which interface OpenNTPD should listen on. This will typically be the “LAN” interface. When complete select “Save.” The OpenNTPD server will start immediately, however there may a delay of several minutes before it is ready to service NTP requests as it must first ensure that its own time is accurate. That’s all there is to it. You’ll find the OpenNTPD logs under by selecting the ‘NTP” tab under Status->System Logs->NTP.
Configure Hosts
Windows
After configuring the OpenNTPD server in pfSense, let’s configure a Windows host to synchronize its local clock to this server. Right-click on the time (usually located in the lower right corner of the desktop) and select “Adjust date/time.” Select the “Internet Time” tab, then select “Change settings.” Check the “Synchronize with an Internet time server” box, enter the host name or IP address of the pfSense machine, then select “Update now.” It’s not uncommon to get error message the first time you attempt to update. Wait a few seconds and try again; you should receive a “The clock was successfully synchronized…” message.
Linux
Many Linux distributions feature two utilities to help the local clock maintain its accuracy: ntpdate and/or ntpd (Note: Linux systems using systemd-timesyncd are discussed below). The ntpdate utility is typically included in Linux distributions as a default package, but if yours does not you can install it using your distribution’s package manager, for example:
1
sudo apt-get install ntpdate
ntpdate typically runs once at boot time and will synchronize the local clock with a default NTP server defined by the distribution. However what if this machine isn’t rebooted often, say in the case of a server for example? And what about using the OpenNTPD server in the pfSense machine? We can address both of those issues by occasionally running ntpdate using the following command. For this and subsequent examples we’ll assume the IP address assigned to the LAN interface in the pfSense machine is 192.168.1.1:
1
sudo ntpdate192.168.1.1
Perhaps a more effective approach though is to use cron, a utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon. These tasks are typically referred to as “cron jobs.” A “crontab” is a file which contains one or more cron job entries to be run at specified times. You can create a new crontab (or edit an exiting one) using the command crontab -e under your user account. Because ntpdate needs to be run by the system’s root user we’ll create the crontab using the command sudo crontab -e. Here’s some example cron job entries using the ntpdate command. Note that cron will attempt to email to the user the output of the commands it runs. To silence this, you can redirect the command output to /dev/null:
While using ntpdate will certainly work well, the utility ntpd on the other hand is considerably more sophisticated. It continually runs, calculating the drift of the local clock and then adjusting its time on an ongoing basis by synchronizing with one or more NTP servers. By default ntpd acts as a NTP client, querying NTP servers to set the local clock, however it also can act as a NTP server, providing time service to other clients. Alas though, nothing is free, and using ntpd will result in yet one more system process that may not otherwise be running in your system, consuming both CPU and memory resources, albeit modestly.
Like ntpdate many Linux distributions include ntpd by default. If yours does not, you can install it using your distribution’s package manager, for example:
1
sudo apt-get install ntp
The installation process should add ntpd to the requisite run levels and start its daemon automatically. Now we need to configure it so that it acts as a NTP client only and not as a NTP server. After all, that’s what we’re going to use the pfSense machine for right?
ntpd is configured using the file /etc/ntp.conf. Open this file and comment out the existing ntp pool servers, then add the IP address assigned to the LAN interface on the pfSense machine. Again, we’ll assume this address is 192.168.1.1. Appending the “iburst” option to the address will provide for faster initial synchronisation. We’ll also want to comment out the NTP server-related options that allow the local machine to exchange time with other host devices on the network and interrogate the local NTP server. The remaining options can remain at their default settings:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile/var/lib/ntp/ntp.drift
# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# Specify one or more NTP servers.
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
#server 0.ubuntu.pool.ntp.org
#server 1.ubuntu.pool.ntp.org
#server 2.ubuntu.pool.ntp.org
#server 3.ubuntu.pool.ntp.org
server192.168.1.1iburst
# Use Ubuntu's ntp server as a fallback.
#server ntp.ubuntu.com
# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.
# By default, exchange time with everybody, but don't allow configuration.
#restrict -4 default kod notrap nomodify nopeer noquery
#restrict -6 default kod notrap nomodify nopeer noquery
# Local users may interrogate the ntp server more closely.
#restrict 127.0.0.1
#restrict ::1
# Clients from this (example!) subnet have unlimited access, but only if
# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255
# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient
A comment about the driftfile option: this file is used to store the local clock’s frequency offset. ntpd uses this file to automatically compensate for the local clock’s natural time drift, allowing it to maintain reasonably accurate time even if it cannot communicate with the pfSense machine for some period of time.
While not required, you can run the ntpdate command one time to fully synchronize the local clock with the OpenNTPD server in pfSense, then restart ntpd.
1
2
3
sudo/etc/init.d/ntp stop
sudo ntpdate192.168.1.1
sudo/etc/init.d/ntp start
In recent Linux releases using systemd-timesyncd, timedatectl replaces ntpdate and timesyncd replaces the client portion of ntpd. By default timedatectl syncs the time by querying one or more NTP servers once on boot and later on uses socket activation to recheck once network connections become active. timesyncd on the other hand regularly queries the NTP server(s) to keep the time in sync. It also stores time updates locally, so that after reboots monotonically advances if applicable.
The NTP server(s) used to sync time for timedatectl and timesyncd from can be specified in /etc/systemd/timesyncd.conf. By default the system will rely upon the default NTP server(s) defined by the distribution and specified by FallbackNTP= in the “[Time]” section of the file. To use the OpenNTPD server in the pfSense machine, uncomment NTP= and append the IP address assigned to the LAN interface on the pfSense machine. Again, assuming this address is 192.168.1.1:
1
2
3
[Time]
NTP=192.168.1.1
#FallbackNTP=ntp.ubuntu.com
You can specify additional NTP servers by listing their host names or IP addresses separated by a space on these lines. Now run the following command:
1
timedatectl set-ntp yes
The current status of time and time configuration via timedatectl and timesyncd can be checked with the command timedatectl status:
1
2
3
4
5
6
7
8
$timedatectl status
Local time:Tue2017-04-2517:41:04EDT
Universal time:Tue2017-04-2521:41:04UTC
RTC time:Tue2017-04-2521:41:04
Time zone:America/New_York(EDT,-0400)
Network time on:yes
NTP synchronized:yes
RTC inlocal TZ:no
FreeBSD
ntpdate and ntpd are installed in FreeBSD by default, however ntpd is not configured to start at boot time.
Similar to Linux, we can run ntpdate manually as root to synchronize with the OpenNTP server running in the pfSense machine. Again, we’ll assume 192.168.1.1 is the IP address assigned to the LAN interface on the pfSense machine.
1
ntpdate192.168.1.1
ntpdate can also be made to run at boot time in FreeBSD by using the sysrc command to add the following lines to /etc/rc.conf:
1
2
sysrc ntpdate_enable=YES
sysrc ntpdate_hosts=192.168.1.1
We can also use cron under FreeBSD to run ntpdate. You can create a new crontab (or edit an exiting one) using the command crontab -e as root. The example cron job entries provided above under Linux will also work under FreeBSD.
To enable ntpd under FreeBSD, open /etc/ntp.conf and comment out the existing ntp pool servers and add the IP address assigned to the LAN interface on the pfSense machine. The remaining options can remain at their default settings:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
#
# The following three servers will give you a random set of three
# NTP servers geographically close to you.
# See http://www.pool.ntp.org/ for details. Note, the pool encourages
# users with a static IP and good upstream NTP servers to add a server
# to the pool. See http://www.pool.ntp.org/join.html if you are interested.
#
# The option `iburst' is used for faster initial synchronisation.
#
#server 0.freebsd.pool.ntp.org iburst
#server 1.freebsd.pool.ntp.org iburst
#server 2.freebsd.pool.ntp.org iburst
#server 3.freebsd.pool.ntp.org iburst
server192.168.1.1iburst
#
# If you want to pick yourself which country's public NTP server
# you want sync against, comment out the above servers, uncomment
# the next ones and replace CC with the country's abbreviation.
# Make sure that the hostnames resolve to a proper IP address!
#
# server 0.CC.pool.ntp.org iburst
# server 1.CC.pool.ntp.org iburst
# server 2.CC.pool.ntp.org iburst
#
# Security: Only accept NTP traffic from the following hosts.
# The following configuration example only accepts traffic from the
# above defined servers.
#
# Please note that this example doesn't work for the servers in
# the pool.ntp.org domain since they return multiple A records.
# (This is the reason that by default they are commented out)
Now use sysrc to add the following two lines to /etc/rc.conf. The first line enables ntpd. The second tells the system to perform a one time sync at boot time:
1
2
sysrc ntpd_enable=YES
sysrc ntpd_sync_on_start=YES
Run the ntpdate command one time to synchronize the local clock with the OpenNTPD server in pfSense, then start ntpd.
1
2
ntpdate192.168.1.1
service ntpd start
Conclusion
This concludes the post on how to how to configure your pfSense machine to also act as a NTP server. The OpenNTPD service in pfSense will listen for requests from FreeBSD, Linux and Windows hosts and allow them to synchronize their local clock with that of the OpenNTPD server in pfsense. Using pfSense as a NTP server in your network ensures that your hosts always have consistent accurate time and reduces the load on the Internet’s NTP servers. Configuring Windows hosts to utilize this server is straightforward, while configuration under FreeBSD and Linux requires a bit more work.
Recently I had the pleasure of building a Network Attached Storage (“NAS”) server based on FreeNAS. Since then, this device has more than fulfilled my initial requirements for reliable file storage and media server in my network. In a previous post, I described how I configured FreeNAS to store web files and serve as a document root for the Apache http server implemented in my Ubuntu server. Using a similar approach, this post will describe how I configured FreeNAS to host my Subversion (“svn”) repository.
Software versions used in this post were as follows:
FreeNAS v0.7.1 Shere (revision 5127)
Ubuntu Server v10.04 LTS (x64)
Subversion 1.6.6dfsg-2ubuntu1
nfs-common v1:1.2.0-4ubuntu4
portmap v6.0.0-1ubuntu2
Configuring the FreeNAS Server
I began by creating the directory svn on /mnt/files, an existing mount point on my FreeNAS server. This directory would serve as the location for my svn repository. Then I enabled the Network File System (“NFS”) service so that /mnt/files/svn could be accessed from the Ubuntu server. To do this, navigate to Services->NFS->Settings and make sure that the check box for enabling NFS is checked and specify the number of servers that will run (the default value of four should easily handle dozens of users). Now select “Save and Restart.” Next, navigate to Services->NFS->Shares and select the “+” icon, where you are presented with the configuration screen for creating a new NFS share. Enter the path to be shared; the network that is authorized to access this shared path; and, make sure that the “All dirs” checkbox selected. The remaining options can retain their defaults (See Figure 1). Now select “Add” then “Apply changes.”
Figure 1
Configuring the Ubuntu Server
In order to mount the NFS shared path without error, I needed to add a couple of packages. The nfs-common package is needed when a host acts as an NFS client, and includes a number of processes that ensure a particular NFS connection is allowed and may proceed. Also, because NFS relies upon remote procedure calls to function, the package portmap is needed in order to map RPC requests to the NFS service:
1
sudo apt-get install nfs-common portmap
After these requisite packages were added, I created a directory to mount the NFS shared path. In this command, you must include the IP address of the FreeNAS server as well as the path to the directory created on it previously:
1
2
sudo mkdir/media/svn
sudo mount192.168.10.5:/mnt/files/svn/media/svn
Then I made sure the permissions for this directory were set correctly:
1
sudo chmod755/media/svn
Next, I added the following lines to /etc/fstab in order for the shared path to mount automatically at boot time:
1
2
3
4
5
6
###Start iceflatline
#Mount the FreeNAS directory /mnt/files/svn for use as a Subversion repository
Then I installed Subversion. The Subversion package for Ubuntu includes the Subversion client, tools to create a Subversion repository (svnadmin), and a custom protocol to make the repository I create on FreeNAS available over my network (svnserve):
1
sudo apt-get install subversion
And created an svn repository at the root of the shared path:
1
svnadmin create/media/svn
Next, I removed anonymous access to the repository and established write privileges for authenticated users. To do this, open /media/svn/conf/svnserve.conf and uncomment the following lines (Note: The svnserve.conf file is sensitive to white spaces, so make sure to not leave a space preceding the line when removing the hash (#) symbol):
1
2
3
anon-access=none
auth-access=write
password-db=passwd
Then I added myself as an authenticated user to the /media/svn/conf/passwd file:
1
2
3
# harry = harryssecret
# sally = sallyssecret
iceflatline=<my password>
I plan to use svn’s custom protocol for access to the repository so I need to start the svn server. One way to start it is to use the svnserve command:
1
svnserve-d-r/media/svn
However, I wanted the svn server to start up at boot time, as well as have stop and restart capabilities while it was running, so I created the following simple init script:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
#! /bin/sh
### BEGIN INIT INFO
# Provides: svnserve
# Required-Start:
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: svnserve init script
# Description: This file is used to start, stop, restart,
# and determine status of the svn server daemon.
# Author: iceflatline <iceflatline@gmail.com>
### END INIT INFO
### START OF SCRIPT
set-e
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="svnserve"
NAME=svnserve
DAEMON=/usr/bin/$NAME
# Make sure the path in DAEMON_ARGS
# reflects the location of the svn repository
DAEMON_ARGS="-d -r /media/svn"
SCRIPTNAME=/etc/init.d/$NAME
# Exit if the subversion package is not installed
[-x"$DAEMON"]||exit0
# Load the VERBOSE setting and other rcS variables
./lib/init/vars.sh
# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
Now, if for some reason the Ubuntu server is rebooted, the svn server will fire up automatically.
With the svn server now running, I created a root-level directory in subversion for a project called “code”:
1
svn mkdir svn://192.168.10.5/code
After creating the project in subversion I can now use the standard svn commands or applications such Tortoise, RapidSVN and others to checkout the project or otherwise interact with the repository.
Conclusion
This concludes the post on how to configure a FreeNAS server for use as an svn repository. Sure, I could have installed the subversion package directly on FreeBSD, the underlying operating system for FreeNAS, but that approach adds processes that are not native to the FreeNAS implementation. By using the approach outlined in this post, I was able to place the repository on a solid, reliable and centralized storage system, and provide good logical and physical separation between the svn repository and the svn server functionality.
(20140208 – This post has been amended to provided an updated version of the Apache directive — iceflatline)
Over this past summer I had the pleasure of cobbling together a few spare parts in order to build a Network Attached Storage (“NAS”) box based on FreeNAS. This device has more than fulfilled my initial requirements for reliable file storage and media server in my network. This post will describe how I configured this FreeNAS box to store web files and serve as a document root for the Apache http server implemented in my Ubuntu server. This approach places my local web files on a solid, reliable and centralized RAID 5 disk storage system, and provides good logical and physical separation between file storage and file server functionality.
The versions for the software used in this post were as follows:
FreeNAS v0.7.1 Shere (revision 5127)
Ubuntu Server v10.04 LTS (x64)
Apache v2.1.14
nfs-common v1:1.2.0-4ubuntu4
portmap v6.0.0-1ubuntu2
Configuring the FreeNAS Server
I began by creating the directory www on /mnt/files, an existing mount point. This directory would serve as my new Apache document root. Then, I enabled the Network File System (“NFS”) service in FreeNAS so that /mnt/files/www could be accessed from the Ubuntu server. To do this, navigate to Services->NFS->Settings and make sure that the check box for enabling NFS is checked and specify the number of servers that will run (the default value of four should easily handle dozens of users). Now select “Save and Restart.” Next, navigate to Services->NFS->Shares and select the “+” icon, where you are presented with the configuration screen for creating a new NFS share. Enter the path to be shared; the network that is authorized to access this shared path; and, make sure that the “All dirs” checkbox selected. The remaining options can retain their defaults (See Figure 1). Now select “Add” then “Apply changes.”
Figure 1
Configuring the Ubuntu Server
To configure the Ubuntu server I needed to add a couple of packages in order to mount the NFS shared path without error. The nfs-common package is needed when a host acts as an NFS client, and includes a number of processes that ensure a particular NFS connection is allowed and may proceed. Because NFS relies upon remote procedure calls to function, the package portmap is also needed to map RPC requests to the NFS service:
1
sudo apt-get install nfs-common portmap
Next, I created a directory so I could mount the NFS shared path. Here you must include the IP address of the FreeNAS server as well as the directory created on it previously:
1
2
sudo mkdir/media/www
sudo mount192.168.10.5:/mnt/files/www/media/www
In order for the shared path to mount automatically at boot time, I added the following lines to the /etc/fstab file:
1
2
3
4
5
6
###Start iceflatline
#Mount the FreeNAS directory /mnt/file/www for use as an Apache document root
I made sure the directory permissions were set correctly, and modified the owner and group associated with /media/www so that the Apache http server could access it:
1
2
3
sudo chmod755/media/www
sudo chown www-data-R/media/www
sudo chgrp www-data-R/media/www
Then edited the /etc/apache2/apache2.conf file, adding an alias for /media/www and a directory directive to the end of the file:
1
2
3
4
5
6
7
8
9
10
11
###Start iceflatline
#Alias and directive for FreeNAS directory /mnt/file/www
Alias/www“/media/www”
<Directory“/media/www”>
Options None
AllowOverride None
Require all granted
</Directory>
###End iceflatline
I created an index.html file and moved it to /media/www to test the above configuration, and made sure the file permissions were set correctly:
XHTML
1
2
3
4
5
6
7
8
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<body>
<h1>
The FreeNAS document root works!
</h1>
</body>
</html>
1
sudo chmod644/media/www/index.html
Finally, I restarted the Apache http server:
1
sudo/etc/init.d/apache2 restart
Conclusion
This concludes the post on how to configure a FreeNAS server as an Apache document root, providing a reliable way to store your web files, while at the same time utilizing the Ubuntu and Apache servers for what they do best – serving up those files.
This post will describe how to install and configure dnsmasq on a Linux- or Unix-based host. Once configured, you’ll be able to use dnsmasq to provide DNS and DHCP services in your home network.
So, why do you even need dnsmasq? Afterall, your ISP provides DNS and your home network gateway/router likely provides DHCP service for your network, right? Perhaps the best way to answer then is to explain the problem I was trying to solve. In my home network I would typically assign a static IP address to each host on my network, and then use its host file to resolve the host’s name to the IP address it was assigned. This approach allowed me to easily communicate between these hosts by simply typing their name rather than trying to remember their static IP address. However, as the number of hosts on my network started to grow, configuring static IP addresses and constantly updating the host files became unwieldy. dnsmasq solves this problem.
dnsmasq is a small, lightweight, and easy to configure caching DNS proxy and DHCP server targeted at small or home networks. It can serve the names of local hosts which are not in the global DNS, and its DHCP server integrates with its DNS server to allow hosts with DHCP-allocated addresses to appear in the DNS along with names configured either in each host or in its configuration file. dnsmasq supports static and dynamic DHCP leases and even BOOTP/TFTP for network booting of diskless hosts. dnsmasq is opensource software and is distributed under the terms of the GPL. Supported platforms include Linux, *BSD, Solaris and Mac OS X.
The versions for the software used in this post were as follows:
FreeBSD 7.2 RELEASE and dnsmasq v2.52,1
Fedora v12 and dnsmasq v2.51-1.fc12
Ubuntu server v9.10 and dnsmasq v2.47-3_all.deb
Download and Install
I chose to install dnsmasq on my Ubuntu server-based machine. However, any host on your network in which you can add one or more external nameservers to /etc/resolv.conf and some or all of your hosts in /etc/hosts, can easily be used for hosting dnsmasq.
To install dnsmasq on a Debian-based distribution like Ubuntu:
1
sudo apt-get install dnsmasq
On Fedora-based distributions:
1
2
$su
# yum install dnsmasq
And on *BSD, if you’ve installed the Ports collection:
1
2
3
$cd/usr/ports/dns/dnsmasq/
$su
# make install clean
Or, if you would prefer to add the package:
1
2
$su
# pkg_add -r dnsmasq
The dnsmasq script will be installed in /etc/init.d, symlinked from runlevels 2-5, and start automatically in a Debian-based distribution like Ubuntu. In Fedora-based distributions, the dnsmasq script is installed in /etc/init.d; however, you will need to create a symbolic link to it from the appropriate runlevel directory in order for it to start automatically at boot time. This is typically done using chkconfig command as root. The following example shows how to add the dnsmasq script to runlevels 2-5 and start dnsmasq in Fedora:
1
2
3
$su
# chkconfig dnsmasq on
# /etc/init.d/dnsmasq start
Newer versions of Fedora, however, may require this set of commands instead:
1
2
3
$su
# systemctl enable dnsmasq.service
# systemctl start dnsmasq.service
In *BSD, the dnsmasq script will be installed in /usr/local/etc/rc.d. To get dnsmasq to start at boot time, add the following line to /etc/rc.conf:
1
dnsmasq_enable="YES"
Then start dnsmasq:
1
2
$su
# /usr/local/etc/rc.d/dnsmasq start
Configure
Configuring dnsmasq is straightforward. The various DHCP and DNS options can be passed via command line when starting dnsmasq, or may be set via its configuration file, dnsmasq.conf. I generally prefer to use dnsmasq’s configuration file; it’s very well commented and easy to follow.
Let’s walk through the changes I made to the default configuration file in order to provision both DNS and DHCP service for my network. Make sure you create a backup copy of your default file before you begin.
To start, I uncommented the following two options to force dnsmasq to filter my local network DNS queries so they did not reach the public DNS servers.
1
2
3
4
5
6
7
# Never forward plain names (without a dot or domain part)
domain-needed
# Never forward addresses in the non-routed address spaces.
bogus-priv
By default, dnsmasq will send queries to any of the nameservers you define in /etc/resolv.conf, however, it will try to favor those it knows to be up. Uncommenting the following setting forces dnsmasq to use the nameservers listed in /etc/resolv.conf strictly in the order they appear. Since I had a pretty good sense of which DNS servers I wanted to use and in what order I uncommented this line:
1
strict-order
By default dnsmasq will listen for DNS queries on all network interfaces. I have several interfaces on my server (Hamachi, eth0, eth1, etc.), but only one that is physically connected to my local network, so I uncommented the following line in order to force dnsmasq to listen for DHCP and DNS requests on that interface only – in my case eth0. Simply repeat the line with the another interface name if you have additional interfaces you would like dnsmasq to listen to.
1
interface=eth0
The following two lines are optional; however, if used, dnsmasq will append the domain name you choose to the host names defined in dnsmasq.conf and/or /etc/hosts. I use these, but the only real benefit I saw in my network was that I was able to ping devices such as my game consoles based on the names I defined for them using the dhcp-host parameter (see below).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Set this (and domain: see below) if you want to have a domain
# automatically added to simple names in a hosts-file.
expand-hosts
# Set the domain for dnsmasq. this is optional, but if it is set, it
# does the following things.
# 1) Allows DHCP hosts to have fully qualified domain names, as long
# as the domain part matches this setting.
# 2) Sets the "domain" DHCP option thereby potentially setting the
# domain of all systems configured by DHCP
# 3) Provides the domain part for "expand-hosts"
domain=home.net
To enable dnsmasq’s integrated DHCP server you’ll need to uncomment the following line and provide the range of addresses available for lease in your network, and optionally, a lease time.
1
dhcp-range=192.168.10.100,192.168.10.254,24h
If you have a host on your network that you’d like to have receive the same IP address every lease, then uncomment the following line and provide the host’s MAC address, as well as the preferred IP address – one from the dhcp-range you defined above. For example, I like to have the computer I use most often receive the same IP address. That way I can easily forward ports to it, etc. Alternatively, I could have simply given it a static IP address and defined the name/address combination in the /etc/hosts file of the machine hosting dnsmasq.
1
dhcp-host=00:27:0E:02:A8:AE,192.168.10.100
If your network is anything like mine you probably have devices that don’t have a host names associated with them the same way a computer does (e.g., Xbox 360). The following parameter will assign a name to these devices in dnsmasq. You’ll need to provide the devices’s MAC address and the name you’d like associated with it. Here’s an example of how I have this defined in my network:
1
2
3
4
5
dhcp-host=00:0B:E6:05:38:47,wii
dhcp-host=00:22:48:48:EE:37,xbox2
dhcp-host=00:12:5A:99:67:DE,xbox1
dhcp-host=00:04:5A:A5:26:B0,tivo1
dhcp-host=00:1D:7E:00:E5:58,tivo2
By default dnsmasq assumes that host running dnsmasq is your gateway/router. That wasn’t the case in my network so I needed to specify the IP address of my Cisco gateway/router in the following line:
1
dhcp-option=3,192.168.10.1
The DHCP server needs somewhere keep its lease database file. I simply retained the default location chosen by dnsmasq for my Ubuntu server install. Note that this default location will vary depending on which platform your using to host dnsmasq:
1
#dhcp-leasefile=/var/lib/misc/dnsmasq.leases
Finally, you can adjust the number of entries dnsmasq will keep in its DNS cache in the following line. I retained the default of 150.
1
#cache-size=150
That’s it for configuring dnsmasq.conf. Keep in mind though that the options described here really only scratch the surface. I would strongly urge you to read through dnsmasq.conf thoroughly as there are many more options available for fine-tuning dnsmasq’s numerious capapbilities. But for now let’s move on and consider two additional files, /etc/resolv.conf and /etc/hosts, that are important when configuring dnsmasq.
resolv.conf
dnsmasq will consult a several locations when going about the business of resolving your network’s DNS queries. These locations include its internal cache, for any queries it may have already resolved; /etc/hosts, for any static name/IP address combinations that may be defined there; and, if the DHCP server is being utilized, it will of course know from its configuration file and lease database file which IP addresses it has assigned to the hosts configured to use DHCP. When it can’t resolve DNS queries via these methods, dnsmasq will send queries to the nameservers defined in /etc/resolv.conf. You must have at least one public DNS server defined there and it’s typical to simply use the DNS server(s) provided by your ISP. Following is an example of how I have my /etc/resolv.conf file configured. Recall that I uncommented the strict-order line in dnsmasq.conf as described above so dnsmasq will utilize DNS servers in the order I have them listed here.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#Allow applications on the machine hosting dnsmasq to also use it too
nameserver127.0.0.1
#Google DNS
nameserver8.8.8.8
#OpenDNS
nameserver208.67.222.222
nameserver208.67.220.220
#Cox
nameserver68.105.28.11
nameserver68.105.29.11
nameserver68.105.28.12
#An option to use my network gateway/router as the upstream DNS. Note that the #pubic DNS server addresses will need to be defined in the router.
#nameserver 192.168.10.1
/etc/hosts
As I mentioned, dnsmasq will consult the /etc/hosts file on the host its running on when resolving DNS queries. This comes handy when there are hosts in your network that you have assigned, or would like to assign, static IP addresses to. In those cases the host name/IP address combinations can simply be added to /etc/hosts. In fact, if desired, you could elect not to use dnsmasq’s DHCP server at all and rely soley on dnsmasq’s use of /etc/hosts to resolve local IP addresses. In this respect, /etc/hosts is no different than any other host file resident on most computers except that now you only need to maintain the one file. Of course, the tradeoff is that you’ll need to configure static IP addresses on all your hosts. I settled on a hybrid approach for my network. I configured all client hosts (laptops, desktop PCs, game consoles, etc) to use dnsmasq’s DHCP server, and configured all servers and network equipment (access point, router, network printers, etc.) with static IP addresses. Here’s an example of my /etc/hosts file:
1
2
3
4
5
6
7
127.0.0.1localhost
192.168.10.1router
192.168.10.2wap
192.168.10.4server1
192.168.10.11server2
192.168.10.51print-hp
192.168.10.52print-canon
Final Steps
Once dnsmasq.conf, /etc/resolv.conf, and /etc/hosts are configured to your liking restart dnsmasq:
1
# /etc/init.d/dnsmasq restart
Or, if your using *BSD:
1
# /usr/local/etc/rc.d/dnsmasq restart
Make sure to disable any other DHCP servers that may be running in your network, then simply configure your hosts to use DHCP – they should recieve an IP address that’s in the range defined in dnsmasq.conf. If you’re planning on configuring some hosts with static IP addresses, set the IP address of the host running dnsmasq as the DNS server and IP address of the gateway/router as the gateway. You’ll also want to make sure to enter that host/IP address information in /etc/hosts on the host running dnsmasq. That’s it! You now have DNS and DHCP service up and running in your network.
Now let’s run a quick test to make sure dnsmasq is caching DNS queries. The simplest to do that is to use the dig utility:
1
$dig iceflatline.com
When you look at the output from dig and find the line showing the query time. Note the time and run the command again. You should see a noticable improvement in response time indicating that dnsmasq is caching query results locally.
Conclusion
This concludes the article on how to install and configure dnsmasq on your Linux- or Unix-based host. As you can see, dnsmasq isn’t terribly complicated and proves to be a really nice open source package for implementing a small, lightweight caching DNS proxy and DHCP server. For a full list of all the configuration options and other information I encourage you to visit the dnsmasq web site.
