Looking for a SHOUTCast Host ? look no further!

Check out http://lmas-networks.com you seriously cant beat what they offer for only £1.00 p/month tons of features in the centova cast control panel and if you currently have shoutcast services hosted elsewhere just drop them an email they will give you a price match deal and give you a month free 😮 !!

Shoutcast hosting

They also allow you to use your own amazon affiliate ID (free to get) so you can make some money if anyone buys a track they hear on your stream!

Try them or ask for a free trial you wont be dissapointed.


Using the /proc Filesystem to Examine Your Linux Inner Working

Quick – answer me this: How much swap space is in use on your system right now? How big is the cache on your CPU? What kernel modules are currently loaded? How many total drives and partitions are you running? If you’re running Linux, all these questions (and a whole lot more) can be answered one easy way: take a look in /proc. It’s a goldmine of system information, just waiting to be retrieved by users, administrators, and scripts. In this guide we’ll take a trip through /proc to see just what valuable system information you’ve been missing out on.

About /proc

Probably the most important thing to understand about /proc is that it’s not a normal directory with normal files. It’s more like a viewscreen into the system internals. Files in this directory are not read and saved to the hard drive like your average document or MP3, they’re generated by the Linux kernel on the fly. Accessing the file /proc/meminfo will likely give you different results each time, because memory usage is nearly always fluctuating.

By putting this kind of system information into a virtual filesystem like proc, the developers adhere to the UNIX philosophy “everything is a file”. They do this so that it can be easily read by any person or software as easily as a normal text file, no special libraries or languages necessary. For us, this means that up-to-date system information is always easily available.

Note: The files mentioned here should all open cleanly in any text editor of your choice. The examples here are showing the contents using the standard cat command from within a terminal.


If you’ve spent any time at all in proc, there’s a good chance you’re familiar with this file. Displaying the contents of cpuinfo will give you a detailed picture of exactly what CPU you have and what features it supports.



The other most well known file in proc, meminfo is an extremely handy file to keep around. It shows you information about memory and swap usage, and is one way that scripts and programs can find out what’s available.



This file shows the options that were used to start the kernel. This can be handy when troubleshooting boot problems, or if you need to verify exactly which kernel file was used for boot.



A lesser known but still useful file is filesystems. From here you can read the (somewhat extensive) list of filesystems currently supported by your kernel. Not all of these are the type of filesystems you’d use to store your data, some are like proc itself and have special-purpose uses.



In this case, PID is the process ID of a running program. Each process has a unique number that the system uses to identify that particular instance of that particular program. For example, when you run the program top from the command line, you see a list of running processes and their PIDs. Each process has its own subdirectory in proc, which you can browse for information about that particular process.



One of the most vital of the files in proc, modules contains a complete list of the currently active kernel modules. If you’ve ever had to work through video driver issues, you likely know how useful this can be. While likely not something you’d use every day, this file can be a lifesaver for troubleshooting.



You can quickly and easily check all your mounted devices by opening the mounts file. Once again, many of the items here are not necessarily mounts points that a user need be aware of. Most of the sections relevant to you will be found toward the bottom.



There’s certainly more to proc than can be covered here, so I’d greatly encourage anyone reading this to do some poking around in proc to find the bits of information that could be really useful to you. While many of the files you’ll find there are intended to be used by the OS itself, they can all provide a valuable look into Linux’s operations.

Beginner’s Guide to Grep

There is a classic bit of computer wisdom that states “If you’ve got a problem, and decide to solve it with regular expressions, now you’ve got two problems.” This of course stems from the perception that regular expressions are a complicated mix of magic characters and Voodoo. Regular expressions can allow you to achieve elegant and concise program logic quickly and easily, but only once you’ve learned to understand how they work and why. Just about any Linux or Mac system comes with a powerful regex tool call grep and learning grep is an essential task for any power user or system administrator. Today, we’ll explore some of what you can do with grep and how it can be one of the most powerful tools in your geek arsenal.

How It Works

In short, grep’s job is to search through a block of input. That’s pretty vague, so it’s best described by example. Let’s say you’ve got a text file called distros.txt that has a list of Linux distributions, such as the one below.

Debian – Stable server distribution
Ubuntu – Desktop distro originally based on Debian
Kubuntu – Uses KDE desktop instead of Gnome
Fedora – Continuation of the free Red Hat desktop system
Gentoo – A fast, source-based Linux system for pro users
SuSE – Commercial Linux owned by Novell
Mint – Ubuntu-derived distro with additional restricted software

Grep can be used to read through the text and filter it to show only the parts you want. If you wanted to see only the lines that contain the word “Ubuntu”, you’d run the following command:

grep Ubuntu distros.txt


(Your version of grep may or may not include color highlighting like in the example above)

Case Sensitivity

You may have noticed that our last search did not return Kubuntu. Unless told otherwise, grep will assume that you entered your expression exactly the way you wanted it, and this applies to upper and lower case. If you search for “ubuntu” but your text file contains “Ubuntu”, your search will find nothing. To make your search case-insensitive, use the -i switch, as in

grep -i ubuntu distros.txt


Whole Word

With the previous search, you included all capitalization variants of the word “Ubuntu”. It included Kubuntu because it contains the word you searched for. You may want to only include the standard version, not Kubuntu or Edubuntu, etc. If that’s the case, you can tell grep to match the whole word only by passing the -w option.

grep -i ubuntu distros.txt



Much as you can use grep to show only matching entries, you can also use it to show everything BUT the matching entries. To expand on our previous searches, we can now use the -v option to reverse our results and only show the lines that don’t match.



Grep has full support for wildcards when matching patterns. When using wildcards and other special characters, you want to make sure your search pattern is in quotes, so the Linux shell doesn’t try to interpret them before grep can. Common wildcards include * for groups of characters and . to represent a single unknown character.



If the wildcards are a little too broad for you, you can specify individual characters or a range to include in your search. Characters within square brackets will be included in your search pattern. For example, if you had a file with a list such as

Item 1 - apples
Item 2 - bananas
Item 3 - coconuts
Item 4 - peaches
Item 5 - Grapes
Item 6 - Apricot

You can choose a particular range by using something like

grep "Item [2-4]" items.txt

Grep is an immensely powerful tool, and learning it thoroughly can pay off in all kinds of ways. Understanding grep is also makes it much simpler to move on to other powerful console tools like sed and awk. Between those three tools, an amazing amount of console and script magic can be done with far less effort than seems possible. If you’re a fan of grep, or would like to see other tools like sed and awk covered here, please drop a note in the comments.

Introduction to the Nano Text Editor

Nano is an ncurses-based editor (which means it must be run from a terminal window) that focuses on simplicity. Nano is a clone of the aging Pico text editor,  the editor for the Pine email client that was very popular, back in the early ’90s, on UNIX and UNIX-like systems. Pine has now been replaced by Alpine and Pico by Nano, but some things haven’t changed — like the simplicity of editing with Nano.

Nano was first created in 1999 under the name “TIP” (a charming, recursive acronym that stands for “TIP Isn’t Pine”) by Chris Allagretta. Mr. Allagretta decided to create this clone of Pico because Pico wasn’t released under the GPL.  The name was officially changed on January 10, 2000 to alleviate confusion between the new editor and the tip command (The tip command is common in Sun Solaris).

Nano uses very simple key combinations in order to work with files. A file is either opened or started with the command:


Where FILENAME is the name of the file you want to open. Or, if you need to edit a file that only the root user has access to:

sudo nano FILENAME

When you have the file open in Nano you will notice, at the bottom of the terminal window, a short list of command key-combination examples. All key combinations for Nano start with the CTRL key. To execute a command you hold the CTRL (commonly referred to as the “Control Key”) key down and click the secondary key to perform the action. The most common key combinations for Nano are:

  • CTRL-x – Exits the editor. If you are in the middle of editing a file the exit process will ask you if you want to save your work.
  • CTRL-r –  Read a file into your current working file. This enables you to add text from another file while working from within a new file.
  • CTRL-c – Display the current cursor position.
  • CTRL-k – Cut text.
  • CTRL-u – Uncut (or Paste) text.
  • CTRL-o – Save file name and continue working.
  • CTRL-t – check the spelling of your text.
  • CTRL-w – Search your text.
  • CTRL-a – Go to the beginning of your current working line.
  • CTRL-e – Go to the end of the current working line.
  • CTRL-g – Get help with Nano.

There are plenty more commands to use in Nano. To see the command listing use the Get help command.


Not all distributions will ship with Nano pre-installed. Ubuntu, for one, does. If your distribution does not have Nano installed, fear not, you will find it in the default repositories. To install this tool all you need to do is follow these steps:

  1. Open up your Add/Remove Software utility.
  2. Search for “nano” (no quotes).
  3. Mark Nano for installation.
  4. Click Apply to install.

That’s it! Nano will now be installed. All you have to do now is open up a terminal and start editing.

Fun fact

The recursive acronym is very common within the Linux community. Although originated back in the early, often romanticized, days of the computer hacker, this type of acronym is one that humorously refers to itself. You have more than likely come across the acronym GNU in your Linux travels. Did you know that GNU stands for GNU is Not UNIX? Recursive acronym. Other fun recursive acronyms are:

  • LAME: LAME ‘AIN’T an MP3 Encoder
  • JACK: JACK Audio Connection Kit
  • LINUX: Linux Is Not UNIX
  • WINE: Wine Is Not an Emulator

You will often find Linux developers trying to create names for their applications that include recursive acronyms.

Accept OpenID Logins

OpenID is a critical piece of “Open Web” infrastructure. The ability to authenticate users without relying on a single gatekeeper entity puts every site on an equal playing field. As a result, community-driven, decentralized networks can enjoy all the same advantages as closed-source, proprietary players, and end users retain more of their autonomy and privacy. All of that sounds well and good, but it is not much use if you don’t enable OpenID on the sites that you maintain. This weekend, why not add support for OpenID logins to your web service? You might be surprised how many LAMP and LAMP-like frameworks have a straightforward solution.

Admittedly, OpenID had its share of problems, particularly in the early days. Before there were ubiquitous OpenID providers, it was confusing for users and seemed indistinguishable from other single-sign-on systems. On top of that, OpenID login widgets suffered from the “NASCAR problem” (confronting users with a cacophony of tiny site-logo buttons with little explanation), the standards process seemed to get bogged down entirely, and other technologies like OAuth started competing for developer attention.

Despite the hurdles in the beginning, the situation has improved considerably in just a few short years. The odds are that if you use an open source content management system (CMS) or web application framework, you can enable OpenID for visitor interaction such as comments and/or for actual persistent user accounts. In the long run, supporting OpenID should reduce your account-management headaches. Let’s survey the latest options.

Systems Offering Native OpenID Support

A few open source CMSes offer native support for acting as an OpenID “consumer,” which is OpenID slang for a site accepting OpenID authentication. Unless otherwise specified, all of these packages support the current, 2.0 version of the OpenID specification.

Drupal was one of — if not the — first. Drupal 5 featured an OpenID extension module, but OpenID was fully integrated with the Drupal 6 release in 2007. The official administration guide documents how to use OpenID for user management.

Plone also includes OpenID consumer support by default, for version 3.0 and later. For security reasons, Plone defaults to placing OpenID users in a low-privilege “Authenticated” virtual group, but site administrators can change this policy site-wide to enable full interaction.

Two open source wiki packages include built-in OpenID consumer functionality. Ikiwiki’s, dating back to 2008, is courtesy of a plugin which is enabled in default installs, though optional. Tiki Wiki‘s OpenID support was introduced with the project’s 2.0 release. It is available in the default install, but must be activated by administrators.

At present, Simple Machines Forum (SMF) is the only dedicated discussion forum system to include built-in OpenID functionality (at least among projects in widespread usage). You may wish to check out the latest version of SMF from Subversion, though; there have been incompatibilities reported between SMF’s implementation and major OpenID providers Google and Yahoo.

Last but certainly not least, the StatusNet microblogging system includes OpenID support, although if you use one of the free, cloud-hosted services emanating from the official status.net domain, it may be temporarily disabled for bug-fixing. If you run your own instance of the software, however, it is a standard administration option.

Systems supporting OpenID via plugins

The next-best thing to native OpenID consumer support is the ability to install an OpenID plugin. In some cases, site administrators can understandably be wary of this option, if the plugin is from a third-party source. Several OpenID plugins developed by individuals have come and gone for popular CMS and blogging packages over the years, and relying on one with a less-than-certain-future could leave you in the lurch when there is an API change in a future release. Such problems are not always the case, though; a quick review of the plugin’s history is generally enough to let you know whether is has long-term dependability.

The WordPress blogging platform, for example, has a well-supported OpenID plugin that supports both OpenID authentication of users, and OpenID authentication for commenters. For API compatibility reasons, it is generally only available for the current generation of WordPress itself, at present 2.8.x.

The popular web discussion forum package phpBB has had a spottier history with its leading OpenID plugin solution, OpenID for phpBB. At present, the plugin is reported to work well with the latest releases of phpBB3, but it does tend to lag behind core phpBB releases in the long run. There are occasionally other MODs developed for phpBB, but few that last.

In the wiki space, both MediaWiki and DokuWiki have OpenID plugins. MediaWiki’s OpenID extension has thorough documentation, including instructions on how to upgrade from previous versions without losing user account data. DokuWiki’s plugin documentation cites some potential compatibility warnings; it is also unique in that it includes the ability for the site administrator to restrict OpenID access to a particular OpenID provider.

The Xoops CMS and XoopsCube application platform can be OpenID-enabled through a third-party module. In both cases, some post-installation work is required to fully integrate OpenID users with the rest of the system, but this process is documented.

An OpenID module is available for the WebGUI CMS as well, which is reportedly slated to be moved into the WebGUI core for a future release. It has been stable for several years.

Finally, the Trac bug-tracking system supports an OpenID plugin, making it perhaps the only bug-reporting package to support such a feature. There are installation and compatibility instructions at the plugin’s page, which among other things note that only Trac 0.11 is currently supported.

OpenID frameworks

Even if your site does not run any of the above-listed packages, not all hope is lost. Most web application frameworks have solid OpenID libraries these days, including Django, Rails, Zend, and many more. Barring that, there are OpenID consumer libraries for all of the common web development languages: PHP, Ruby, Perl, Python, Java, etc.

The best place to look for current information on OpenID support in development libraries is probably the official OpenID wiki. The Libraries page attempts to maintain an up-to-date-list of all active OpenID projects, sorted by framework and by language, and you can check the page history to see that it has a good track record of frequent updates. The wiki also lists license and OpenID version compatibility for each entry.

If all else fails, of course, you can roll your own OpenID authentication solution. Perhaps the lowest-level OpenID solution in development is mod_auth_openid, which adds OpenID authentication directly into Apache itself. It requires SQLite and the external libopkele OpenID function libraries, but you can configure it directly in httpd.conf, including whether or not to store OpenID session information in cookies, as well as optional whitelisted and blacklisted OpenID providers.

Missing pieces

Despite all of the open source packages listed above, there are still several high-profile CMSes and web frameworks with no active OpenID support whatsoever.

Joomla, for example, has neither native support nor an actively developed OpenID extension. The last attempt was “unpublished” with the release of Joomla 1.5 due to API incompatibility.

Bug tracking and software development is also particularly under-served, with Trac alone providing a live OpenID option. The market-leading bugtracker Bugzilla has no OpenID support and none on the horizon. Canonical’s Launchpad — which in its public hosting role serves as an OpenID identity provider — cannot accept OpenID authentication as a consumer.

But why dwell on the negatives? With all the OpenID-supporting options out there, a great many projects already support the open standard, and adding to that can only increase the motivation factor for the projects left out in the cold to join in the fun. Of course, accepting OpenID logins is only one half of the equation. If you run a site of your own, you may want to consider setting up your server as an OpenID identity provider — but that’s another weekend.

Install XOOPS for Powerful Open Source Content Management

Content is king. It always has been and always will be. It drives our businesses and motivates our customers. But when you think content management, so many tools come to mind. There’s Drupal and Joomla! for starters. Both of those tools are outstanding solutions for content management. But many organizations are projects are choosing XOOPS.

So what would make one choose XOOPS over other strategies? XOOPS offers the following features:

  • Database driven: XOOPS is powered by MySQL database.
  • Modular: Add or remove as many modules as you like.
  • User customization: Your users can edit profiles, select personal themes, upload custom avatars, and more.
  • World-wide support: Official support sites can be found all over the world (in many languages).
  • Multi-byte languages: Including Japanese, simple and traditional Chinese, Korean, and more.
  • Group permission system: Granular control over group and user permissions.
  • Skinnable interface: Over 800 themes available.

But features alone don’t always demonstrate why you should choose a particular project, especially when a feature set is matched almost feature-for-feature by other projects. If you look at sourceforge.net, you will find XOOPS one of (if not the) highest ranked CMS tool. You’ll find many reasons to select XOOPS as your CMS. Once you have made that choice, it is then time to get going on the build. You might be surprised to know that, regardless of power, XOOPS isn’t all that difficult to get up and running. In this tutorial I will lay out the steps to installing XOOPS on your already running Linux box.

It should be noted, just for clarification, that this tutorial will be using Ubuntu 9.10 as a base for installation.


Let’s take a look at the requirements, before we begin the installation. In order to successfully install XOOPS, you will need:

  • Web server: For this install, we will use Apache. XOOPS can be installed on other platforms using other servers.
  • PHP >= 4.3.0 (5.2 recommended)
  • MySQL >= 3.23 (>= 4.1 recommeded)

Pre-flight setup

You will be using your web browser for the actual installation of XOOPS. But before you can get to that stage, there are a few steps you must take:

  1. Make sure your server is set up and running properly (with PHP and MySQL support). 
  2. Set up your database for XOOPS.
  3. Prepare the directory structure for XOOPS

Let’s tackle these steps one at a time.

Step One

If you have set up your server as a LAMP (Linux Apache MySQL PHP) server, you should be good to go. If you haven’t done so, you can do this easily on a Ubuntu machine with the command:

sudo tasksel

You will then select LAMP server and follow the simple instructions.

Step Two

The next step is to set up your database. We will create a database called “xoops” (no quotes) with the following steps:

  1. Create the database with the command: mysqladmin -u db_user -p create xoops
  2. Change to the MySQL prompt with the command: mysql -u db_user -p (Where db_user is the MySQL administrative user — usually root, unless you’ve made a change to this in order to heighten security).
  3. Grant privileges to the user on the xoops database with the command: GRANT ALL PRIVILEGES ON xoops.* TO root@localhost IDENTIFIED BY 'password'; Here password is the actual password of the database administrator.
  4. Flush all privileges with the command: flush privileges;

Step Three

Now it’s time to prepare the directory structure. The first thing you will do is download the XOOPS file from Sourceforge.  Once you have downloaded that file move the file to /var/www/. But before you unpack the file you need to consider one thing: Are you planning on having more than XOOPS served up on this server? Will you have multiple web sites here? If so you will want to contain XOOPS inside of its own directory. If not, you can unpack the XOOPS file directly into /var/www. I will go on the assumption you plan on having more than one site on your server, so we will create a container folder for XOOPS. Follow these steps:

  1. From within your terminal (and from within the /var/www directory) issue the command su mkdir XOOPS.
  2. Move the XOOPS file into the newly created XOOPS directory with the command sudo mv xoops-XXX.zip XOOPS (Where XXX is the release number).
  3. Change into the XOOPS directory with the command cd XOOPS.
  4. Unpack the XOOPS file with the command sudo unzip xoops-XXX.zip (Where XXX is the release number).

So far so good. Remember where we mentioned we were going to serve XOOPS from within its own directory? Well, as it stands, you would have to be pointing your browser to http://SERVER_ADDRESS/XOOPS/htdocs/. We want to avoid this so move into the the /var/www/XOOPS/htdocs and move the entire contents of this directory into /var/www/XOOPS. You can do this with the command sudo mv * ../. Now you can back out into /var/www/XOOPS and all of those files will be found.

You now need to create the directory /var/www/XOOPS/uploads with the command sudo mkdir /var/www/XOOPS/uploads. 

The next step is to check to see if the directory /var/www/XOOPS/xoops_data exists. If it does not, create it with the command sudo mkdir /var/www/XOOPS/xoops_data. Now you have to change some permissions. You must give the following directories/files write permission:

  • /xoops_data/configs/
  • /xoops_data/caches/
  • /xoops_data/caches/xoops_cache/
  • /xoops_data/caches/smarty_cache/
  • /xoops_data/cache/smarty_compile/
  • /var/www/XOOPS/mainfile.php

The above is done with the command chmod 777 "DIRECTORY/FILE NAME". And that is the difficult aspect of the installation. Now you only need point your browser to http://ADDRESS_TO_SERVER/XOOPS/ to begin the web-based installation.

Web install

There will be approximately fourteen screens to walk through for this installation. All of these screen will be very intuitive. The screens are:

  1. Language selection: Select the language for the installer.
  2. Introduction: Read about the installation process.
  3. Configuration check: XOOPS installer checks to see if everything is ready.
  4. Paths settings: Are all of your paths correct?
  5. Database connection: Database server settings.
  6. Database configuration: XOOPS database settings.
  7. Configuration save: Write settings to mainfile.php.
  8. Tables creation: Create tables on database.
  9. Initial settings: Admin user creation.
  10. Data insertion: Data is inserted into tables.
  11. Site configuration: Configure your site.
  12. Select theme: Choose the default theme for your site.
  13. Modules installation: Select modules to install.
  14. Welcome: Final notes.

Only a couple of these screens really need any explanation. The first is Figure 1. This is the second screen you will come across. This screen not only serves as an introduction, but also outlines everything you will need to do for the installation. There are a couple of steps I intentionally left out. Should you choose to add those steps, the instructions are fairly obvious on this screen. 

You might think the next screen(s) that would need attention would be related to the database. If you have created the database in the manner outlined above, you can accept the defaults from the screens. The only exception will be the MySQL admin password.

After the database screens (screens 5 and 6) the next screen that requires user-input is screen 9. Screen 9 requires you to fill out information for an administrator account — very simple.

The Site Configuration screen (see Figure 2) might be the next screen that could trip you up. As you can see there is a bit of pre-configured data added to each section. If your site is a public site, you will want to play close attention to the Meta Tags and Description as these can help your search rankings. You will also want to make sure Yes is selected, if you want to allow New User registration.

The next two screens (Select theme and Modules installation) are also both very intuitive. Upon installation you will only have two themes to choose from and three modules to install. You will need to download more themes and modules in order to further extend the look and functionality of your XOOPS site. You can find more modules at the XOOPS Module Repository and XOOPS themes from the XOOPS Theme Gallery.

Final thoughts

Congratulations! You now have a running XOOPS site installed and ready to go. Make sure you log in as the administrator you created in screen 9 (Initial Settings) so you can further customize your XOOPS site.

Xoops InstallationFigure 2


Xoops installFigure 1

Set Up a TFTP Server on Linux

Good post over on linux.com the often forgotten TFTP can be a life saver.

Most users are familiar with FTP, but if you want to kickstart Red Hat installs, PXE boot systems, auto-provision VoIP phones or unbrick a Linux-based router, you want a Trivial File Transfer Protocol (TFTP) server. Setting one up on Linux is easy, and a perfect project to take on over the weekend.

TFTP (RFC 1350) is very low-overhead variant of the more familiar FTP that you are probably already used to interacting with. It is optimized for transferring files over a local network to small devices that may not even have permanent storage. In the old days, that originally meant thin clients booting over the network. Today there are still network services that depend on TFTP (most notably the Linux Terminal Server Project and Red Hat’s Kickstart remote-installation system) but it has taken on a second important role in VoIP, as the preferred way to “auto-provision” many IP telephones and analog telephone adapters (ATAs), distributing configuration files at boot time in a manner similar to DHCP. In addition to that, if you accidentally brick your Linux-based router while installing DD-WRT, TFTP may be your only path to restoring it. Fortunately, even though the protocol might not get the same public respect as FTP, Linux supports it just fine.

TFTP uses UDP as its transport protocol, on the reserved port 69. Like FTP, it can be used in either ASCII or binary mode, but unlike FTP it has no directory-listing or navigation features, because it was not primarily designed for interactive client use. Instead, TFTP clients typically boot up and request a specific file. If a listening server has the file, it acknowledges the request and begins transferring it.

This is a very simple process, which is what makes TFTP popular for thin client setups like Preboot eXecution Environment (PXE) and for embedded devices without built-in or USB-attachable storage. But it also includes no authentication step or access control methods, which makes man-in-the-middle attacks a very real security issue when dealing with VoIP deployments that require a support server to be running constantly.

An attacker that compromises the TFTP server can send rogue configuration files that do anything from register phones with different Session Initiation Protocol (SIP) gateways to perform denial-of-service by setting bad configuration parameters. Attacking a PXE system is a little more difficult, since the setup also includes DHCP, but it is certainly possible to upload a bad bootimage to thin clients.

On the other hand, if you just need to unbrick your router or flash a device with new firmware over TFTP, you do not need to run a TFTP server constantly. If you are really paranoid, you can just disconnect the WAN connection during the process. Since the two use cases are so different, the best choice for a static TFTP server probably is not the choice you would want just for an isolated job. We will consider each in turn.

Setting up static TFTP

For administrating a netboot or VoIP deployment, there are two main Linux TFTP server projects to choose from: tftpd-hpa and atftpd. The former is a port of OpenBSD’s TFTP daemon, though the Linux version has diverged over the course of several releases. Atftpd (which stands for Advanced TFTPd) is native to Linux. Both include support for several newer TFTP revision options, such as negotiable transfer block sizes and negotiable time-outs.

Your distribution may package one or the other, or both. If you are faced with a choice, the main differences between the two are in their security features and support for multicast TFTP.

Atftpd provides only host-level security using the libwrap TCP wrapper library. You can add TFTP clients by host name or address to /etc/hosts.allow or use exclusion rules in /etc/hosts.deny. Tftpd-hpa, on the other hand, respects rules in both hosts.allow and hosts.deny, but also implements several other security features. By default, it can only serve files that are publicly readable (i.e., o+r), and will only allow files to be uploaded by clients if the filename in question already exists and is publicly writable. Finally, starting the daemon with the -s option performs a chroot to the TFTP file directory to prevent an attacker from accessing anything else on the server.

Only atftpd, however, supports multicast TFTP, both the version specified in RFC 2090 and the slightly-different version that is part of the PXE specification. Thus, if you need to support PXE thin clients, atftpd is the better choice, but for all others, including VoIP provisioning, the added security features of tftpd-hpa are worth having.

Both servers can be started either by inetd or as standalone daemons, and store a configuration file in /etc/default/.

The tftpd-hpa server’s file is /etc/default/tftpd-hpa. By default it includes the line RUN_DAEMON="no", which allows it to be started and managed by inetd. Change this value to “yes” to start the server as a daemon instead. The OPTIONS= line lists a quoted series of run-time configuration flags, the most important of which is -s /path/to/tftp/directory.

Atftpd’s configuration is found in /etc/default/atftpd. By default, it includes USE_INETD=true to indicate inetd management; change this to false to run atftpd as a daemon. Aftpd requires that you specify the TFTP directory as the final argument, after all of the command-line switches, so you would simply append /var/tftpd to the end of its OPTIONS line.

Next, make sure that you create the TFTP directory you intend to use (say, /var/tftp/), and give it the proper ownership and permissions. Both daemons run as user nobody by default, so run chown -R nobody /var/tftp to set the ownership correctly, and chmod -R 777 /var/tftp to assign the correct permissions. Then, start the daemon: either execute /etc/init.d/atftpd restart or /etc/init.d/tftpd-hpa restart. Both services uses the standard Linux syslog utility, with run-time verbosity control so you can monitor their behavior.

For advanced usage, each of the servers also provides a way to serve alternate contents when it receives a specific file request, based on regular-expression matching and replacement. This can be useful when a device is hard-coded to request a specific firmware image, but you need to flash it with a newer replacement. But the two servers differ in their implementations. Atftpd uses Perl-Compatible Regular Expressions (PCREs), and allows for simple pattern/replacement pairs based on filename. Tftpd-hpa uses POSIX regular expression syntax, which is not as flexible, but it allows file remapping rules to be based on client IP address in addition to matching filenames alone.

The Simpler Case: TFTPing a Single File

If all you need to do is make one file available over TFTP for a short period of time, including restoring the factory firmware to a bricked router or uploading an update to your Cisco IP phone, you do not need to install and configure a full service like either of those discussed above. While it would be nice if Linksys and Cisco provided a simple command-line or GUI TFTP application for these occasions, neither do.

There is at least one robust, painless-to-use standalone TFTP app for Linux, though: tftpgui. Written in Python, tftpgui is meant to run as a user-initiated interactive application. The author documents its use with a variety of Cisco equipment, and it has also been tested with Vonage, Sipura, Linksys, and Grandstream hardware.

Currently, no distributions package tftpgui, so you will need to grab the latest tarball from the project’s downloads page. You can unpack its contents anywhere; it does not need to be compiled and installed to be used. In order to run on the default port of 69, you must launch the GUI as root, so execute sudo python ./tftpgui.py & to get started.

There are four buttons at the top: Start and Stop enable and disable the server, Exit closes the GUI, and Setup allows you to specify configuration rules. You must select a TFTP directory holding the files you need to move, and you can specify a log directory and change the UDP port on which the server listens.

The one security feature tftpgui includes is the ability to restrict incoming TFTP requests to a specific subnet, so if you must run the application in a hostile environment, you can at least try to isolate yourself to a vacant subnet before starting. You can also enter the remote clients IP address and specify a subnet mask of 32, even though purists may call that cheating.

After you apply any configuration settings and press Start in the main window, the main canvas will report any TFTP requests and return codes. You can then restart the remote device and watch its TFTP request hit the server, or if you are attempting to de-brick a router, follow whatever steps the instructions tell you to do.

Tftpgui does not support any of the extended protocol options like filename replacement or multicasting, but if you were stuck without a simple way to serve up a replacement firmware image or provisioning file, it may fit the bill.

In some ways, TFTP is a relic from the 1980s. As embedded devices get smarter and memory gets cheaper, more and more OEM products that used to use TFTP alone as their update mechanism are starting to include embedded HTTP stacks. That certainly makes it easier to troubleshoot, since most Linux boxes have Apache or another web server already installed. Still, when you find yourself trapped with a device that speaks only an unfamiliar protocol, it is reassuring to see that on Linux machines, old RFCs never die.

%d bloggers like this: