Tag: fedora

Networking

How to Install and Configure dnsmasq

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

    Linux

    My Conky Configuration

    One of my favorite things about using Linux and BSD is Conky. Conky is a free, light-weight system monitor that can display nearly any information about your system directly on your desktop. Originally a fork of Torsmo, Conky’s torsmo-based code is BSD licensed. New code in Conky has been licensed under the GPL 3.0.

    Installation is easy. 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:

    Conky is very simple to configure. Using a pre-defined set of variables in a configuration file you define what Conky should monitor and where those monitored parameters are displayed on your desktop. The look and feel of what’s displayed is highly customizable.

    On most systems the default configuration file location is /etc/conky/. There you will find the sample configuration file conky.conf. You’ll want to copy it to ~/.conkyrc and then start modifying it.

    When setting up my Conky configuration, I decided to dispense with the fancy network graphs and other eye candy that I’ve seen in so many others use and go with a more utilitarian approach. I settled on four areas for Conky to monitor:

    • System – basic system information showing kernel version, uptime, total RAM and Swap usage, etc.
    • Processor – shows the top five applications or processes based on CPU usage
    • Memory – shows the top five applications or process based on system RAM usage
    • Network – shows basic information regarding wired and wireless connections, including IP address, inbound and outbound speed, connection quality, etc.

    This minimalistic approach looks good (less “cluttered”) in my humble opinion, and provides just the information I need while not straining system resources.

    One of the many cool things about Conky is its support for the use of conditional statements within its configuration file. The ${if_existing} variable, as an example, checks for the existence of a file passed to it as an argument and will display everything between ${if_existing} and the matching ${endif}. I used this particular variable to my advantage when configuring the network monitoring section. Instead of displaying information about each wired and wireless interface, even when they weren’t up, I chose instead to display information about them only if they were up by using the existence of a particular interface (e.g., eth0) in /proc/net/route.

    Anyhoo, here’s the configuration file I’m currently using. Feel free use it as is or change it to fit your needs and taste. Post your Conky configuration in the comment section.

    And here are some screenshots:

    Screenshot of Conky running on my Crunchbang linux desktop

    Figure 1

    Screenshot of Conky running on my Crunchbang linux desktop

    Figure 2
    Linux

    Configure Command Line Aliases in Bash

    (11.24.09 – This post was edited to expand the discussion on the various files read by Bash for login and sub-shells — iceflatline)

    This post will describe how to set up command line aliases in Free Software Foundation’s “Bourne Again Shell” (BASH) for reducing common input mistakes and improving efficiency at the terminal.

    Let’s take the simple case of a command like ls –a, which prints a list of the current directory’s files, including the hidden ones. Let’s change that command to something perhaps more efficient:

    Nice. Now we need only to type lsa to get the same results. Not enough of an improvement over simply typing ls –a? Let’s take another example. Say we use something like the following command to routinely download a specific directory from a web site: wget -nH -r -l inf ftp://ftp.somewebsite.com/directory1/directory2/. Sure we could try to remember a string like this each time we need it and debug if mistakes are made, but let’s make it easier:

    You get the idea; I’m sure you can think of other examples. The point here is that each of these aliases will start to add up after awhile to help save you time and reduce mistakes.

    Now, let’s say we open up a terminal and enter a few aliases like ones above. What happens when we close and reopen the terminal? Unfortunately aliases entered like this won’t carry over to the next bash shell session. To accomplish that we need to set up something more permanent.

    There are three files in your home directory that hold a special meaning to Bash, allowing you to set up your environment automatically when you log in, when you start another Bash shell, and when you log out. These files may or may not exist depending on the Linux distribution you’re using. If they’re missing, Bash defaults to /etc/profile. These files are:

  • .bash_profile: read by Bash when you log into the system
  • .bashrc: read by Bash when you start a sub-shell
  • .bash_logout: read by Bash when a login shell exits

    • Bash allows two replacements for .bash_profile: .bash_login and .profile. However, only one of these files is read when you log in. If .bash_profile isn’t there, Bash will look for .bash_login. If that file is missing, it will look for .profile. If you start a sub-shell (e,g, a new terminal or X windows), Bash will read commands from .bashrc. Most users, however, want to have the same commands run regardless of whether it is a login shell or a sub-shell. This is typically done by including a small script (similar to the one for .myaliases below) or the line source .bashrc within .bash_profile to execute .bashrc. All the commands, including aliases, are then placed in .bashrc.

    Using a text editor you can add your own aliases directly to .bashrc or, in some cases, simply uncomment ones that the distribution may have added for you (Ubuntu for example does this). Another approach is to create your own file containing your aliases and then simply point to that file from within .bashrc. This might be handy if you want to easily carry your aliases from one system to another. To do this, first create the file:

    Now, open the file in your favorite editor and enter your aliases and save it. Here’s a list of the ones I often use:

    Now, open .bashrc and add or uncomment the following script, making sure to modify the file name to match the file you created for your aliases; then save the file.

    Now reboot the system or simply issue the following command to have bash recognize the aliases:

    That’s it. Your new aliases should be ready to go. You can get a list of your aliases at anytime using the command alias without any arguments, and you can temporarily “unalias” any alias you’ve set up with the command unalias aliasname. However, this will only last for as long as the shell session does. To permanently eliminate the alias you’ll need to delete it from your alias file.

    But what if we want to have these aliases available when we log in or run a session as root, or another user? To do that we need to add our list of aliases to a file that is accessible to bash on a system-wide bases. In the case of a Fedora or a Fedora-based distribution, that file is most likely going to be /etc/bashrc, and the case of Ubuntu or other debian based distribution that file is likely to be /etc/bash.bashrc. Place your aliases at the end of those files and restart the system or use the command exec bash and they will be available regardless of which user you are.

    References

    Newham, C., and Bill Rosenblatt. Learning the bash Shell. 2nd ed. Sebastopol, CA, USA: O’Reilly, 1998. Print.

    Linux

    Installing Xfce-Terminal on Ubuntu and Fedora

    While the default XTerminal or Gnome Terminal that comes with Ubuntu is just fine, I had the occasion recently to use Xubuntu, a Ubuntu derivative that uses the Xfce desktop environment. I really fell in love with Xfce-Terminal, Xubuntu’s default terminal emulator. This article will describe how to install Xfce-Terminal and configure some of its options.

    Written for the Xfce desktop environment, Xfce-Terminal is a modern, lightweight, and low memory cost terminal emulator for X11. It offers full-customization for the key bindings, the aspect ratio, the colors, and the ability to use multiple tabs with terminals within a single window. Most importantly though, it doesn’t bore you to tears looking it all the time.

    Screenshot of the Xfce-Terminal on Ubuntu Jaunty

    Figure 1

    Install and Configure

    To install Xfce-Terminal on Ubuntu use apt-get:

    To install Xfce-Terminal on Fedora* use yum:

    * A quick note concerning the installation on Fedora. The Xfce project site offers the source tarball for Xfce-Terminal but I simply ran into too many unresolvable package dependency problems while trying to compile it on Fedora 11. This command simply installs the Xfce desktop environment, which includes Xfce-Terminal, and you won’t have to switch to Xfce in order to use it.

    After the package is installed you can find a link to Xfce-Terminal under Applications -> Accessories (Ubuntu) or Applications -> System Tools (Fedora). Of course, you can also start from the application launcher – just hit Alt-F2 and use the command xfce4-terminal (Ubuntu) or Terminal (Fedora). Xfce-Terminal will use the login shell of the user who starts the application (/bin/bash in case of a typical Linux system).

    Configuration is easy. Open Edit->Preferences to bring up the Preferences dialog allowing you to tweak Xfce-Terminal to your liking. The settings are stored in ~/.config/terminalrc (Ubuntu) or ~/.config/Terminal/terminalrc (Fedora), which also stores a few hidden options for settings that are not included in the user interface.

    You can also customize the behavior of Xfce-Terminal by passing along options via the command line. For example:

    In this case, the terminal will launch with a window that is 80 columns * 40 rows and with the title “foo.”

    One of the things I also find really useful is the tab feature that enables you to open several terminals within a single window. Since each tabbed terminal in the window is a separate subprocess, you can also use each terminal for a different task. For example:

    This would result in two tabs; one terminal window open and ready with a command prompt, the other open with nano ready to go.

    Just substitute Terminal for xfce4-terminal in the preceding commands when working in Fedora.

    Conclusion

    Terminal emulators are like your significant other – you have to be with them all the time so you might as well get the one you want. Xfce-Terminal is certainly worthy of a look for those looking for a nicer experience than the standard XTerminal or GNOME Terminal. You can find out more about Xfce-Terminal at the developer’s site.

    Have a favorite terminal emulator? Leave a comment on what you use and why you like it.