Jonathan's blog

This is a +1 for Easy Firewall Generator for iptables.

Of course any self-respecting sysadmin should be able to set up iptables, but sometimes starting off can be tricky. So I use the this website, which lets you define the basics using a handful of checkboxes, and it generates a script that configures your computer’s iptables firewall.

It works for single hosts and servers that do NAT, and includes protection against a great many nasties.

Once you have this, it’s then an easy task to hand-configure the result to your heart’s content.

This evening, my other half’s Eee 701 broke.

Whenever she turned it on, the green power LED and blue wireless LED came on, stayed on, and nothing else happened. The screen backlight didn’t come on, no power was supplied to the USB ports and the fan did not start to spin.

I tried the usual fixes – taking the battery out, poking a paperclip in the reset button in the back. This didn’t work.

Next I reset the BIOS. To do this, you need to:

• Remove the battery and disconnect from the mains
• Remove the memory cover from the back with a small screwdriver
• Locate the BIOS contacts. Turn it so the memory chip is at the bottom, and look at the top half (the bit that isn’t covered by the memory chip). The contacts are in the bottom-left corner of this, and they are small copper triangles. I’ve circled them in red in this picture.


The BIOS contacts

• You need to short-circuit the two small triangular copper contacts with a screwdriver for a second or two.
• Replace the memory cover and battery, and turn the Eee on again.
• For me, this worked and it booted normally. Your mileage may vary!

I decided that I need to sort out the way I do my personal calendaring.

Currently I only use my phone’s built-in calendar. I nearly always have my phone with me, but it’s a bit of a pain to enter stuff on when I’m sat at a computer anyway, and carrying all that information solely on my phone presents a huge risk of loss, theft or breakage.

I need some kind of centralised store of information that is able to sync with all the devices and programs I want to use, namely:

• Some sort of cross-platform calendar client – mainly for use on Linux but also nice to be able to use similar software if I’m on Windows or OS X.
• Sony-Ericsson P1i (Symbian) built-in calendar
• iPhone, for when I get one
• Web interface, for those times when I’m borrowing a computer and can’t install a client.

Google Calendar seems to be a good choice. It’s flexible and can sync with lots of things.

Linux

So I installed Lightning on all my Fedora and Ubuntu machines. It’s a calendar extension for Thunderbird, which I already use. To install it yourself:

On Fedora:
yum install thunderbird-lightning
On Ubuntu:
apt-get thunderbird-lightning

It’s easy to set up, too. Suppose your Google account is joebloggs@gmail.com, then you would…

• Add a new calendar to Lightning by right-clicking in the Calendar area
• Choose On the Network
• Select CalDAV
• Enter your location as https://www.google.com/calendar/dav/joebloggs@gmail.com/events
• Give the calendar a name

OS X and Windows

It’s a little more work to install Lightning on OS X. You have to download the add-on from Mozilla, and install it in Thunderbird. Same story for Windows.

It’s quite straightforward and there are instructions on the website.

When you’re done, follow the same instructions as for Linux to subscribe to your Google calendar in Lightning.

Sony Ericsson UIQ

Setting up Google Calendar on my Sony Ericsson P1i was a bit of a pain, too. The P1i can’t interact with Google natively, I had to set up an account with Goosync to enable this. Goosync talks to Google, and your phone talks to Goosync using SyncML.

But once you have a Goosync account, you can synchronise a lot of handsets with Google calendar.

So first, you will need to set up an account with Goosync. It’s free and very easy. Goosync will ask you to tie your Goosync account to your Google account.

There’s also an option to have the settings for your phone sent automatically to your handset. However this didn’t work for me so I had to enter the settings manually.

Assuming the sync task on your phone has been set up properly, do a  test run to make sure it all works.

• If possible, connect to a wireless network first. If not, 3G will have to do.
• Go to the Main Menu
• Go to Tools
• Go to Remote Sync
• Find the profile that syncs with Goosync
• Find the sync task called Calendar. Make sure it is ticked, and then tap Sync to start off the first synchronisation.

If that worked, you can now run the sync task whenever you like from within the calendar itself.

• Open your phone calendar
• Tap More
• Tap Calendar manager
• Tap Synchronise

That’s all there is to it! Unfortunately there’s no way of making your calendar synchronise automatically at set intervals, but that’s probably a good thing, because you can’t get stung for 3G charges!

iPhone and iPod touch

Coming soon…

If you have Fedora and an nVidia graphics card, chances are you’ll want to use kmod-nvidia as your graphics driver. It is closed-source, but produced by nVidia themselves and has several advantages over the default open-source drivers that are typically bundled with most distributions – for example, 3D hardware acceleration.

If you have already installed kmod-nvidia – read on, and find out why you should upgrade to akmod-nvidia.

So what’s wrong with kmod-nvidia?

The way it works is simple. For each kernel version, there is a corresponding nVidia kernel module. Keeping the two in sync is a pain, so the packagers at RPMFusion have made a metapackage, simply called kmod-nvidia which tracks the right version of the module for your kernel, e.g. kmod-nvidia-2.6.29.5-191. It’s simple – you install just the metapackage and yum automatically installs the right version of the kernel module.

The problem arises when a new kernel is released, but the packagers of kmod-nvidia haven’t yet released the corresponding kernel module. Sometimes they do it in a few hours but often it takes longer – maybe a day or two. For all the time that the corresponding kernel module doesn’t exist, you cannot update your kernel (and if you are using PackageKit to update your system, you cannot easily update anything!)

What’s different about akmod-nvidia?

akmod-nvidia is different. Rather than downloading someone else’s kernel module when it’s available, akmod-nvidia compiles its own version of the module for whatever kernel you have.

So if you update your kernel, next time you boot into the new kernel, akmod will see that no module exists yet on your system for your kernel, and it will compile it automatically. This takes only one or two seconds – I haven’t noticed the delay on my system.

The advantage is that you don’t have to wait for anyone else to do anything when you update your kernel. It’s also extremely useful if you are running some sort of custom kernel, such as PlanetCCRMA’s realtime audio kernel.

So how do I install akmod-nvidia?

If you haven’t already got the RPMFusion repository set up on your computer, you will need to do this. (The following code snippet is for Fedora. For CentOS, see the RPMFusion Configuration page.

rpm -Uvh
http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm
http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm

If you already have kmod-nvidia, uninstall it.

yum remove kmod-nvidia

Then you can install akmod-nvidia. It will probably need to pull in a handful of dependencies.

yum install akmod-nvidia

Now if you reboot, akmod will automatically compile your kernel module. You’ll never have to wait for packagers again!

This a short and simple guide, explaining how to set up remote monitoring of Linux hosts using NRPE in Nagios. The procedure is simple, but having searched for information on this earlier today I didn’t find a straightforward all-inclusive guide, so I’ve written my own.

These instructions were written with Nagios 3.0.6, and they assume that you already have a working Nagios monitoring server. They assume that the monitoring server was installed from RPM, not from source (some paths will vary).

Configuring the remote server

First, we install the NRPE on the remote server to be monitored. This comes as standard in the Fedora repositories, but on CentOS you’ll need to add the EPEL repository first.

yum install nrpe

We’ll need to make one or two changes to get it working. First open up /etc/nagios/nrpe.cfg and find the allowed_hosts directive. Replace it with the IP address of your Nagios monitoring server.

allowed_hosts=123.123.123.123

Edit your /etc/sysconfig/iptables and add a line to allow port 5666/TCP from the monitoring server’s IP address.

-A INPUT -m tcp -p tcp -s 123.123.123.123--dport 5666 -j ACCEPT

Finally, restart iptables and start NRPE to get it working. We also tell NRPE to start on boot.

service iptables restart
service nrpe start
chkconfig nrpe on

Configuring the Nagios server

Edit your commands.cfg (usually in /etc/nagios/objects/ if you installed from RPM) and add the following command definition:

define command{
        command_name    check_nrpe
        command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$
        }

If this is your first remote Linux host to monitor, create a new host definition file in the same directory as commands.cfg, e.g. linux.cfg. Make a host definition for your new server:

define host{
        use                     linux-server
        host_name               myserver
        alias                   My Server
        address                 234.234.234.234
        }

Add the following to it as a test to show it works:

define service{
        use                         generic-service
        host_name                   myserver
        service_description         PING
        check_command               check_ping!100.0,20%!500.0,60%
        }

define service{
        use                         generic-service
        host_name                   yourserver
        service_description         Load
        check_command               check_nrpe!check_load
        }

Restart Nagios and ensure that both tests work OK. If so, we can move on to some custom test.

Custom checks

The default NRPE client comes with a handful of built-in tests. You can see these near the bottom of nrpe.cfg on your remote machine. But they’re not very exciting, and you’ll probably want to use some of the other checks. If you want to see a list of the available checks in your yum repo, try this:

yum list available nagios-plugins-*

Install any that take your fancy. You’ll need to set up a definition for them in your nrpe.cfg. Use the examples in the file, and try running the Nagios plugin yourself to see if it gives you any clues about the arguments it wants.

Please note, in the default config of NRPE, you cannot use placeholders like $ARG1$, for security reasons. Either hardcode the values in, like

command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1

or enable dont_blame_nrpe=1 further up in the file. There is a security risk associated with doing this. Your funeral!

Restart NRPE again, and let’s move on to setting up your Nagios server. There is no need to create a new command definition, since we are using NRPE again. So open up linux.cfg and let’s add a service definition for the check_hda1 that exists in nrpe.cfg.

define service{
        use                             generic-service
        host_name                       myserver
        service_description             Disk status
        check_command                   check_nrpe!check_hda1
        }

Restart Nagios again and your new checks should appear. Go ahead and install any useful plugins from your yum repository, or have a look at Monitoring Exchange, a great source of free Nagios plugins.

I wrote my own plugins for monitoring your account balance with AQL and checking for the latest installed kernel. One day I will probably get round to uploading them to Monitoring Exchange.

I’ve just written a module for Nagios that will determine if the currently running kernel is the latest kernel available on the system. It will not tell you if there is a newer kernel in a yum repository or similar.

The main gotcha is that you need an RPM-based system for my script to work, e.g. RHEL, CentOS, Fedora and many others. It is most certainly not bulletproof, but it works on my systems.

All feedback welcome.

N.B. I’ve now published this module on Monitoring Exchange. Please download the plugin from there, as I will keep that copy up to date if there are changes in the future (and the copy on this page is likely to go out of date).

check_kernel

#!/usr/bin/perl -w

# Usage:   check_kernel

use strict;
use lib "/usr/local/nagios/libexec";
use utils qw(%ERRORS);

my $running_kernel=`uname -r`;
my $installed_kernel=`rpm -q kernel | tail -n 1`;
my $rpm = `which rpm`;

chomp $running_kernel;
chomp $installed_kernel;

if ($rpm =~ m/no rpm in/i) {
   print "UNKNOWN - You must be running an RPM-based system\n";
   exit $ERRORS{'UNKNOWN'};
}

if (!defined $running_kernel || !defined $installed_kernel) {
   print "UNKNOWN - Test failed\n";
   exit $ERRORS{'UNKNOWN'};
}

# Strip off the "kernel-" prefix so the strings will match
$installed_kernel =~ s/kernel-//gi;

# Do the test
if ($running_kernel eq $installed_kernel) {
   print "OK - running latest installed kernel ($running_kernel)\n";
   exit $ERRORS{'OK'};
} else {
   print "WARNING - reboot to run latest installed kernel ($installed_kernel)\n";
   exit $ERRORS{'WARNING'};
}

Sometimes you need to change the log verbosity of wpa_supplicant for debugging purposes. First check which log verbosity you are currently running with.

ps -ef | grep wpa_supplicant | grep -v grep

-d represents verbose
-dd represents extra verbose

To change the log verbosity, edit /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service and add -d or -dd as appropriate. Example:

[D-BUS Service]
Name=fi.epitest.hostap.WPASupplicant
Exec=/sbin/wpa_supplicant -u -d -f /var/log/wpa_supplicant.log
User=root

Restart NetworkManager and run the check again to see which log verbosity you are running with.

Is it just me, or is this not the kind of error message you want from a company that handles your bank and debit card details?

Error 500 from PayPal

Recently, a friend asked me if I could copy her home videos from a miniDV tape onto a DVD. I said sure, OK, and if she lent me her camcorder I’d be able to get it done.

I’ve never actually used miniDV before, and I’ve only ever tried to process video on Linux a handful of times – and it’s usually been a disaster. Fedora seems to be a rock-steady platform for many tasks, although I would say it can be a bit lacking in high-quality media tools. I decided to give it a go on Fedora, but I was also prepared to fail over to Windows Movie Maker if necessary. Yuck.

So I searched the Fedora repos for the term DV, and came across a tool called Kino.

Kino is a non-linear DV editor for GNU/Linux. It features excellent integration with IEEE-1394 for capture, VTR control, and recording back to the camera. It captures video to disk in Raw DV and AVI format, in both type-1 DV and type-2 DV (separate audio stream) encodings.

Great – sounds like it will do the job. I plugged in the camcorder (a Sharp VL-NZ50) and fired up Kino. It immediately recognised the camera, no intervention necessary. Kino has full control of the tape – I was able to start, stop, rewind, and fast-forward the video. There was a single button to capture the entire tape to disk.

I found it made a new file for each time recording had been restarted on the camcorder. This might be ideal if you wanted to later burn a DVD with scene selection, but I wanted to create a single video.

After capture was complete, approximately one hour of video took up just over 12 GB – luckily I have crazy disks in my PC!

Kino also has features to export video in various formats. I simply exported as a single DV file (no re-encoding required).

Then I used DeVeDe to wrap the raw video file in a nice DVD format with a basic menu, and create an ISO image that I could simply burn to DVD.

I was very pleasantly surprised at how easy it was to get great results copying a miniDV tape to a DVD using Fedora.

A few months ago I set up a website, Memories of Korea, to showcase some slides I inherited. Naturally I was keen to find out how many visitors I’d had, so I set about finding something that could draw pretty graphs.

Based on my experiences setting up website statistics with AWstats, I’ve now prepared a guide for anyone else wishing to do the same.

This guide assumes you are running either Fedora or CentOS, with Apache httpd web server. The majority of the AWstats config will apply on any distro, and with several different web servers, but paths and installation procedures may vary.

Installing AWstats

First things first, let’s install AWstats. On Fedora:

sudo yum install awstats

On CentOS, you need to jump through a hoop first by enabling the EPEL repository:

sudo rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
sudo yum install awstats

Tweaking your Apache logs

AWstats works by reading your httpd access logs. Somewhere in your httpd.conf you should have a line like this.

CustomLog logs/access_log common

or

CustomLog logs/access_log combined

If you have virtual servers, each server is likely to have its own log file and associated CustomLog directive, too. For now, just pick one set of logs to work with and do the rest later. If your CustomLog directive ends in common, change it to combined. This keeps the log format the same, but causes a couple of extra fields to be logged.

Don’t worry if you can’t change the log format for one reason or another – AWstats will still work but you won’t get quite as many juicy stats.

While you’re nosing around in httpd.conf, make a note of the path and filename of the access log – you’ll need it in a second. In my case it’s /var/log/access_log, which is the default for non-virtual Apache servers.

Go into /etc/awstats. There should be a sample config file called awstats.model.conf. This contains most of the default options you will need, so let’s make a copy of it and work on that. Give the copy the same name as your website

cp awstats.model.conf awstats.www.memoriesofkorea.com.conf
vi awstats.www.memoriesofkorea.com.conf

You don’t need to change many options to get it going, so I will outline the basics here. Find the following directives in the config file, and change their values appropriately. Leave everything else alone – for now!
Tell AWstats where your Apache log file is:

LogFile="/var/log/httpd/access_log"

Leave this as 1 if you are using combined Apache logs. Change it to 4 if you are using common Apache logs.

LogFormat=1

Set this to the main name of your website.

SiteDomain="www.memoriesofkorea.com"

If your website has other names, add them here. Usually the only “other” name is simply omitting the www. Leave in 127.0.0.1 and localhost, which may be important if you access your website from the server it is running on.

HostAliases="memoriesofkorea.com 127.0.0.1 localhost"

Save your changes and exit.

Run AWstats for the first time

When you installed AWstats, it was automatically configured to run and collect log information hourly, but you’re too impatient to wait for cron, run the first AWstats update now:

/usr/share/awstats/tools/awstats_updateall.pl now

Grant access to the AWstats page

You need to edit the file /etc/httpd/conf.d/awstats.conf. This just tells Apache who can view the statistics. Somewhere in the middle of the file there should be a block like the one below. By default only 127.0.0.1 (the web server itself) is allowed to view the page, so if your web browser isn’t running on the server, you will need to change something.

You might want to add a single IP address, an IP address range (e.g. 192.168.0.1/24 for a home network) or simply all to grant access to the world.

    Options None
    AllowOverride None
    Order allow,deny
    Allow from 127.0.0.1
    Allow from 192.168.0.0/24
    Allow from all

Save the file and exit. Restart Apache.

service httpd restart

See your statistics

Assuming all went well, you should be able to view your statistics page at http://www.mysite.com/awstats/awstats.pl

Other options

You no doubt saw in the /etc/awstats.conf file that there are many, many more configurable options for AWstats, including user authentication to name but one.

The config file is well commented and there is plenty of documentation online to help you along.