Category: Networking

The Networking category contains posts relating to network operations, administration, management, and provisioning.

bookmark_borderHow to Install and Configure dnsmasq

Posted on by iceflatline

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:

    On Fedora-based distributions:

    And on *BSD, if you’ve installed the Ports collection:

    Or, if you would prefer to add the package:

    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:

    Newer versions of Fedora, however, may require this set of commands instead:

    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:

    Then start dnsmasq:

    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.

    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:

    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.

    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).

    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.

    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.

    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:

    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:

    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:

    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.

    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.

      /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:

    Final Steps

    Once dnsmasq.conf, /etc/resolv.conf, and /etc/hosts are configured to your liking restart dnsmasq:

    Or, if your using *BSD:

    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:

    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.

    References

    http://www.thekelleys.org.uk/dnsmasq/docs/setup.html
    http://www.thekelleys.org.uk/dnsmasq/docs/FAQ

    bookmark_borderRemote Access To Your Ubuntu Server Using PuTTY, Hamachi and SSH

    Posted on by iceflatline

    (20130205 – This post has been amended to reflect the most recent version of LogMeIn Hamachi — iceflatline)

    This post will describe how to set up a secure virtual private network (VPN) to your Ubuntu home server using the Linux version of LogMeIn Hamachi. Once configured, you’ll be able to use secure shell (SSH) to access and manage your server from anywhere outside of your home network without the need to forward ports or make any other configuration changes on your home network gateway/router.

    LogMeIn Hamachi is a hosted VPN service that is capable of establishing secure LAN-like links between computers, even if they’re behind Network Address Translation (NAT) devices. You can use it to create secure virtual networks on demand, across public or private networks. In order for LogMeIn Hamachi to work, a “mediation server,” operated by the LogMeIn, is required. The mediation server stores machine nicknames, statically allocated IPv4 (IP) addresses in the 25.x.x.x range and the associated authentication token of the user. An overview, including protocol-level details of the security architecture employed by LogMeIn can be found at LogMeIn Hamach.

    LogMeIn Hamachi provides three network types for flexibility in meeting diverse use case scenarios. They differ mainly in network topology. LogMeIn Hamachi clients can be members of any network; however, depending on the network owner’s LogMeIn Hamachi subscription, networks have the following limitations:

    • Free subscription allows you to have five members in a network
    • Standard subscription allows you to have 32 members in a network
    • Premium subscription allows you to have 256 members in a network
    • Multi-network subscription or a LogMeIn Central subscription allows you to have 256 members in all your networks

    Further information regarding the subscription types can be at LogMeIn Hamachi.

    SSH is a open source program for logging into a remote machine and, in most cases, for executing commands on that machine. It provides secure encrypted communications between two untrusted hosts over an insecure network. X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. It is intended as a replacement for rlogin, rsh and rcp, and can be used to provide other applications with a secure communication channel. To use SSH, you will need to install an SSH client on the computer you connect from (most Linux distributions and Unix variations include an SSH client), and an SSH server on the computer you connect to. The most popular open source SSH client and server are maintained by the OpenSSH project.

    The versions for the software used in this post were as follows:

    • LogMeIn Hamachi (Linux) v2.1.0.86-x64 (beta)
    • LogMeIn Hamachi (Windows) v2.1.0.284
    • OpenSSH Server v1:5.9p1-5ubuntu1
    • PuTTY v0.62
    • PuTTYgen v0.62
    • Ubuntu server v12.04 (x64)

    So, let’s get started.

    Installing the SSH Server

    As you may recall, the OpenSSH server is an option you have the opportunity to select when you installed and setup your Ubuntu server. If you did not select that option, you’ll need to install the OpenSSH server manually:

    If the SSH server was already installed apt will let you know, otherwise the installation will proceed. When complete, the SSH server daemon will start automatically. To check to make sure it’s running, use the following command:

    Install and Configure LogMeIn Hamachi on the Ubuntu Server

    The LogMeIn Hamachi Linux client comes as a single executable binary compiled for the platform of your choice. This binary includes the Hamachi daemon, the control application, and the setup utility. However, before we can successfully install LogMeIn Hamachi on our Ubuntu Server we must first install the Linux Standard Base (LSB). LSB is a standard Linux core system that some third-party applications written for Linux, like LogMeIn Hamachi, use for successful implementation across a variety of distributions:

    With that dependency out of the way, let’s download the 64-bit Linux version of LogMeIn Hamachi to our Ubuntu server.

    Then install it:

    After LogMeIn Hamachi is installed it will start up as a background process (daemon) automatically. However, you can stop, start or restart the Hamachi daemon manually from the command line with the following commands:

    When the Hamachi daemon is run for the first time it stays offline. Let’s bring it online:

    You can change its status back to offline at any time using the following command:

    Note that the daemon remembers its state if the Ubuntu server it is shutdown or if shutdown using the sudo /etc/init.d/logmein-hamachi stop command. So if its state was online, it will automatically go online when started next time. If it was offline, it will stay offline.

    Next, let’s create a nickname for our Ubuntu server so that we can identify it easily from a remote client machine:

    Now, let’s create our LogMeIn Hamachi network. In this step you’ll need to enter a unique name for your network as well as a password for it. If your network name is already in use you’ll need to keep trying until you select one that’s unique. If you’ve previously setup a LogMeIn Hamachi network and want to simply add your server to it, then substitute join for create in the following command:

    That’s it. Your LogMeIn Hamachi VPN should be up and running with your Ubuntu server added as one of its member hosts. You can display the status of LogMeIn Hamachi at any time by running the command sudo hamachi without any arguments. To display a full list of all the LogMeIn Hamachi command options, use sudo hamachi -h.

    Install and Configure LogMeIn Hamachi on a Linux Client

    Now that we’ve installed LogMeIn Hamachi on our Ubuntu Server and created a secure VPN, it’s time to install LogMeIn Hamachi on any Linux-based machines you’d like to use to access your server remotely. You can follow the steps explained above for the Ubuntu server in order to download and install LogMeIn Hamachi on your Linux macbine. Once installed, bring the logmein-hamachi daemon online:

    Create a nickname for your remote client machine:

    Then join the network you created at the server:

    Let’s check to make sure we can see our Ubuntu server on our LogMeIn Hamachi VPN. The following command will your networks (and their hosts) that you are a member of:

    Assuming that LogMeIn Hamachi is running on your Ubuntu server, you should see the nickname you created for the Ubuntu server listed, as well as the IP address assigned to it by LogMeIn (e.g., 25.x.x.x). An asterisk next to a host indicates that corresponding machine is currently online (Note: you will not see the machine your’re running the command from listed). Now that we have our Ubuntu server and our remote Linux client machine online, let’s see if we can initiate a terminal session with the server using SSH:

    You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by typing yes and you’ll be presented with the login and password prompt. The public key from your Ubuntu server is stored in ~/.ssh/known_hosts. If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run an SSH session with your server, simply add the IP address along with a name (e.g. home-server-ssh) to your hosts file (/etc/hosts). Next time you use LogMeIn Hamachi/SSH to connect to your server, use the name instead of the IP address and the host file will resolve the IP address for you.

    Install and Configure LogMeIn Hamachi on a Windows Client

    Configuring a Windows machine to access your Ubuntu server remotely is easy too. Download and install the Windows version of LogMeIn Hamachi. When you fire up the application for the first time, LogMeIn Hamachi will be in the offline state. Select the Power On icon on the top left of the application). A pop-up screen will appear asking you to enter the nickname to assign to your remote machine. After it is entered, the application will go online; however, we won’t see our Ubuntu server just yet, we first must add ourselves to the network we created. Select the “Join an existing network” and fill in the name of the network and the password you created when setting up the Ubuntu Server and select “Join”. You should see the name of the LogMeIn Hamachi network we created, as well the LogMeIn Hamachi IP address and nickname for our Ubuntu server appear in the screen (See Figure 1). Once installed, the LogMeIn Hamachi application will start whenever Windows starts and the user has logged in. You’ll find various configuration settings for the application under System->Preferences.

    Screenshot of the Hamachi Application

    Figure 1

    We’re almost there. Now we need to download and install an SSH application (Windows doesn’t support SSH natively). There are many out there to choose from, but the one I typically use is PuTTY, a free implementation of Telnet and SSH for Win32 and Linux/Unix platforms. Download PuTTY.exe (or the Installer version if you’d prefer) and run it. Enter the LogMeIn Hamachi IP address for your Ubuntu server in the Host name field, make sure to select the SSH radio button, and then select “Open” (See Figure 2).

    Screenshot of the PuTTY Application

    Figure 2

    You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. If you’re absolutely sure that you are indeed connecting to your Ubuntu server, accept by selecting Yes; a terminal emulator will open and you’ll be presented with the login and password prompt.

    If you don’t want to have to remember the LogMeIn Hamachi IP address each time you want to run a session with your server, then simply add the address along with a name of your choice (e.g. home-server-ssh) to your hosts file (/windows/system32/drivers/etc/hosts). Next time you use SSH to connect to your server, use the name instead of the IP address and the hosts file will resolve the IP address for you.

    Additional Security

    As you may have noticed, we’re using conventional password authentication in order to prove to our Ubuntu server who we claim to be. That may be an acceptable level of authentication considering we’re also authenticating over SSH and a secure VPN tunnel. However, you may want to have a more secure form of authentication. Public key authentication is an alternative means of identifying yourself to your Ubuntu server. Instead of typing a password, you generate a key pair, consisting of a public key (which your server is allowed to know) and a private key (which you keep secret and do not give out). The private key is able to generate signatures. A signature created using your private key cannot be forged by anybody who does not have that key; but anybody who has your public key can verify that a particular signature is genuine. Public key authentication is more secure and more flexible, but a little more difficult to set up. We’ll walk through the steps on both a Linux and a Windows client machine in the follow examples, but in essence what is involved is generating a key pair on our remote client machine, and copying the public key to the Ubuntu server. Then, when the server asks to prove who we are, the SSH application can generate a signature using your private key. The server can verify that signature (since it has your public key) and allow you to log in.

      Linux Client

    Let’s set up our remote Linux client for public key authentication. We first need to generate the public/private key pair:

    By default the RSA keys are 2048 bits. You can increase this to 4096 bits if desired with the -b option:

    You’ll be asked by the script where it should store the keys (~/.ssh is the default), and then asked to enter in a passphrase in order to encrypt the private key that will be stored in this machine. If you don’t want to be asked for a passphrase each time you connect, just press enter. It is up to you to decide whether or not you should password encrypt your key when you create it. However, if you don’t, then anyone gaining access to your private key will automatically have SSH access to the server. After you enter a passphrase and confirm it, or simply hit enter, your encrypted private key (id_rsa) and your public key (id_rsa.pub) are generated and stored in ~/.ssh (assuming you accepted the default directory).

    Now that our keys are generated, let’s move the public key to our Ubuntu server. Ensure that LogMeIn Hamachi is running, then enter the following command:

    This command will copy your public key to ~/.ssh/authorized_keys on your Ubuntu server. That’s it. Now, next time you use SSH/LogMeIn Hamachi to initiate a session with your server you’ll be asked to provide the passphrase (if you provided one when you generated the keys) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.

      Windows Client

    Configuring our remote Windows client for public key authentication requires a little more work. First, we need a Windows application that can generate the public/private key pair. We’ll use PuTTYgen, PuTTY’s key generation utility, to perform this task. PuTTYgen is installed automatically if you use the Windows installer version of PuTTY, else you can simply download and use the standalone version of PuTTYgen.

    Start PuTTYgen and verify that “SSH-2 RSA” is selected and change the “Number of bits in a generated key” field to 2048 (or more). Select “Generate” where you’ll be asked by PuTTYgen to move your mouse over the applications blank area in order to generate “randomness.” PuTTYgen will then proceed to create your public/private key pair (See Figure 3).

    Screenshot of the PuTTYgen application after generating a public/private key pair

    Figure 3

    You may now enter a passphrase for you private key and confirm it. Again, it’s up to you to decide whether or not to protect your private key with a passphrase. However, electing not to means that anyone gaining access to your private key will have SSH access to the server. You also have the opportunity to modify the “Key comment” field. The default entry is the key type and the date it was created. If you intend on creating additional keys, you may wish to populate this field with something different in order to help you differentiate between the various keys.

    When complete, select “Save private key” and choose a file name and a location to save the *.ppk file. Next, carefully copy the text contained in the “Public key for pasting into OpenSSH authorized_keys file” box into a text file and save it. Using a program like WinSCP copy the text file to your user account on the Ubuntu server. Now, login to this account and append the contents of this text file to the file ~/.ssh/authorized_keys and make sure permissions are set correctly:

    We’re done with PuTTYgen so let’s exit the program. Now fire up PuTTY and navigate to Connection->SSH->Auth. Under Authentication parameters select the Browse button and select the *.ppk file you saved in the previous step (See Figure 4). Now, navigate back up to Session and enter the LogMeIn Hamachi IP address for your server in the Host name field, make sure to select the SSH radio button, and then select Open (of course, LogMeIn Hamachi should be running). You may receive a warning concerning the authenticity of the host you’re trying to reach along with a fingerprint of its public RSA key, and asked if you’re sure you want to continue connecting. Accept by selecting Yes; you’ll be asked to provide the passphrase (if you created one) for your private key instead of your server password. Congrats, you’re now using public key authentication to login to your server. Once you know your key pair works back up both the public and private keys files to an offline media, such as a USB flash drive or CD.

    Screenshot Showing the Private Key Load Screen in the PuTTY Application

    Figure 4

    Now that we have public key authentication set up, you may be wondering if you can still logon to the server without a private key? In other words, can you still use your server username and password? The answer is yes. However, that can be changed. After you’re sure that public key authentication is working on the remote machines you’ll be using to access your Ubuntu server, you may want to consider shutting down password authentication. To do that, logon on to your server and open the OpenSSH server’s config file (/etc/ssh/sshd_config). Look for the line #PasswordAuthentication yes and change it to PasswordAuthentication no (Make sure to uncomment the line). Then restart the SSH server with the following command:

    Conclusion

    Good times eh? Using some open source tools and LogMeIn Hamachi, we set up a secure VPN between remote Windows and Linux clients, and our Ubuntu server. And, we didn’t have to touch our home gateway/router. We also improved the security of the network by using public key authentication.

    References

    https://help.ubuntu.com/community/SSH/OpenSSH/Keys
    http://the.earth.li/~sgtatham/putty/0.60/htmldoc/
    http://www.openssh.com/
    http://www.ibm.com/developerworks/library/l-keyc.html

    bookmark_borderHow to Install and Configure MRTG on Ubuntu Server

    Posted on by iceflatline

    (20161025 – The software versions used in this post were updated — iceflatline)

    (20150902 – The steps and script in this post were amended to remove logging — iceflatline)

    This post will describe how to install and configure Tobi Oetiker’s MRTG (Multi Router Traffic Grapher) on your Ubuntu server. All steps assume that the Apache http server is installed and operating correctly. Once configured, you’ll be able to use MRTG to monitor the traffic in and out of your network using the SNMP capability in your network’s gateway\router. MRTG generates static HTML pages containing PNG images which provide a visual representation of this traffic. MRTG typically produces daily, weekly, monthly, and yearly graphs. MRTG is written in perl and works on Unix/Linux as well as Windows. MRTG is free software licensed under the GNU GPL.

    Software versions used in this post were as follows:

    • Ubuntu Server v16.04.1 x64 LTS)
    • mrtg v2.17.4-3ubuntu1

    So, let’s get started.

    Download and Install

    First, update your package list:

    Then download and install MRTG:

    If this is the first time installing MRTG on your server you’ll likely be presented with the following message (See Figure 1). Answering “Yes” means that the MRTG configuration file will not be readable by others (file permissions set to 640). Answering “No” means that the file is readable by others (file permissions set to 644). In this example we’re going to accept the default Yes.

    Screenshot showing install message regarding MRTG file permissions

    Figure 1

    MRTG installs a sample configuration file /etc/mrtg.cfg used to hold the SNMP information obtained from your gateway\router. For a full listing of what MRTG installs and where, run the locate command:

    Technically speaking, mrtg.cfg could remain in /etc, but just to keep things tidy let’s create a directory for it and move it into that directory:

    That’s it for installing MRTG. Now let’s move on and configure it.

    Configure

    MRTG includes a script called cfgmaker that will help us populate /etc/mrtg/mrtg.cfg with the information obtained from your gateway\router. But before you run cfgmaker, you should setup the SNMP service in your gateway\router. This usually involves logging into your gateway\router and enabling SNMP. The default SNMP community name is typically “public.” If you change the SNMP community name to something else, make note of it. Now, run the following command, substituting your SNMP community name, if you’ve changed it, and adding the IP address of your gateway\router:

    If you would like to add more than one gateway\router to MRTG simply append the additional URL(s) to the same mrtg.cfg file. Then, when you build the web page using the indexmaker command described below, all the gateway\routers (and their associated graphs) will be displayed on the same HTML page.

    Next, open /etc/mrtg/mrtg.cfg and make sure under Global Configuration Options that the lines “WorkDir: /var/www/mrtg” (under Debian), and “Options[_]: growright, bits” (under Global Defaults) are uncommented. Finally, add the following lines to the existing line EnableIPv6: no under the Global Defaults section:

    What does all this do? The line RunAsDaemon: Yes will enable MRTG to…um… run as a daemon. This is beneficial because MRTG is launched only once, thus the parsing of the /etc/mrtg/mrtg.cfg file is done only once, not repeatedly as would be the case if one were to run MRTG as a cron task – another acceptable method for running MRTG. Also, when running as a daemon, MRTG itself is responsible for timing the measurement intervals; therefore, we need to add the Interval line option and assign it a value – in this example 5. This means that every five minutes MRTG will poll the SNMP service in your gateway\router and update its graphs. Finally, since many gateway\routers do not currently support SNMP over IPv6, we’ll retain the line EnableIPv6: no.

    Speaking of graphs, by default MRTG graphs grow to the left, so by adding the option “growright” the direction of the traffic visible in MRTG’s graphs flips causing the current time to be at the right edge of the graph and the history values to the left. We’ve also chosen the “bits” option, which means that the monitored traffic values obtained from your gateway\router are multiplied by 8 and displayed bits per second instead of bytes per second.

    Okay, now it’s time to create the web pages which display the MRTG graphs using the indexmaker command. Run the following commands:

    Open /etc/apache2/apache2.conf and add the following lines in the section containing similar Directory directives:

    Then restart Apache:

    When restarting Apache you may receive a warning concerning its inability to “…reliably determine the server’s fully qualified domain name…” This non-critical error can be fixed by adding the following line to /etc/apache2/apache2.conf:

    MRTG has been configured. Let’s start it up and see what it displays.

    Start

    There’s something important to keep in mind when starting MRTG, and that is that MRTG requires the environmental variable “LANG” to be C in order to run properly. Since most Linux systems these days, including Ubuntu server, use UTF-8 (run echo $LANG to see what your system uses), let’s change LANG to C and start MRTG using the following command:

    When you run MRTG for the first time you may see a lot of complaints about missing log files. No worries, this is normal for the first 2-3 times you start MRTG this way. If, however, it continues to complain you may want to look into the source of the problem.

    Well, that’s it. Now point your browser to http://your-server-address/mrtg and you should see a page that resembles Figure 2. You may have more or less graphs depending on the number of interfaces reported by your gateway\router(s).

    Screenshot showing the default MRTG web page

    Figure 2

    Because of the aforementioned option in /etc/mrtg/mrtg.cfg, you’ll see the graph starting “grow” to the right as the traffic is monitored over time, and the Y axis displayed as bits per second. If you click on any one of these graphs you’ll be taken to another page showing individual graphs for 30 minute, two hour, and daily averages, along with the maximum, average, and current bit rate in and out of that particular interface. Only interested in displaying one particular interface? Want to graph other SNMP data? No worries, just remember to run indexmaker again to update the MRTG index.html file.

    Okay, so now that we have MRTG installed, configured and running let’s move on and discuss how to keep it running.

    Operate

    Starting MRTG by hand is not ideal in the long run. So perhaps after you’ve done some tweaking on MRTG and are satisfied with the results, you can automate the process of running MRTG by using a startup script in your system startup sequence. Here’s the script that I use:

    To use the script, save it to your home directory as mrtg and make it executable. Then move or copy it to /etc/init.d:

    Now, link the mrtg script to all of Ubuntu server’s multi-user run levels (2-5):

    Now, let’s start MRTG using our script. If it’s currently running then substitute restart for start in the following command:

    That’s it. Now if for some reason your server is rebooted, MRTG should fire up automatically. If you would like to remove the MRTG script from the server’s multi-user run levels, use the command sudo update-rc.d -f mrtg remove).

    Conclusion

    This concludes the post on how to install and configure MRTG on Ubuntu server. As you can see, MRTG isn’t terribly complicated and proves to be a really nice open source package for monitoring and displaying traffic in and out your network from virtually anywhere you have a web browser. For a full list of all the configuration options and other information I encourage you to visit the MRTG web site.

    References

    http://oss.oetiker.ch/mrtg/doc/index.en.html

    iceflatline