Jonathan's blog

The other day, I wanted to find out which of the videos in my movie collection were encoded with multitrack (e.g. 5.1) sound.

I found a tool for Linux called themonospot. Happily, it’s packaged with Fedora and can be installed simply by doing

yum install themonospot-console

Once installed it’ll quickly give you information about your video files:

[jonathan@zeus ~]$ themonospot-console /media/public/Movies/Sunshine/Sunshine.avi
File path:               /media/public/Movies/Sunshine/Sunshine.avi
Codec name:              XVID
Codec desc:              xvid
Frame size:              704 x 288
Average video bitrate:   1,423 Kb/Sec
File size:               1,525,886 KB
Total time:              01:47:26.00 seconds
Frame rate:              24.00 frames/sec
Total frames:            154,574
Video data rate:         23 frames/sec
Video quality:           113
Packet Bitstream:        False
ISFT data:               VirtualDubMod 1.5.10.2 (build 2540/release)
JUNK data:               VirtualDubMod build 2540/release
USER data:               XviD0046
Audio 01:                0x2000 (AC3) 448.00 Kb/Sec - 48000 Hz (6 Channels)

As you can see, my copy of Sunshine has 6-channel audio (i.e. 5.1). But what if you want to run a batch job to check all of your films and see which ones have surround sound?

Then use perl.

I wrote an extremely hacky script that takes a path as an argument and whizzes round to fetch the encoding of all .avi or .AVI files in the directory. It prints the names of any that have more than 2 audio channels (i.e. better than stereo).

It sometimes goes wrong if the output of themonospot-console varies, as it occasionally does.

So you get output like this…

[jonathan@zeus ~]$ ./findAudioEncoding.pl /media/public/Movies/
/media/public/Movies/Catch Me If You Can/Catch Me If You Can.avi : 6
/media/public/Movies/National Treasure - Book of Secrets/National Treasure - Book of Secrets.avi : 6
/media/public/Movies/Never Been Kissed/Never Been Kissed.avi : 6
/media/public/Movies/Rescuers, The/Rescuers, The.avi : 5
Argument "" isn't numeric in numeric gt (>) at ./findAudioEncoding.pl line 12.
/media/public/Movies/Brideshead Revisited/Brideshead Revisited.avi : 5
/media/public/Movies/Passion of the Christ, The/Passion of the Christ, The.avi : 6

If you’re interested in the source, here it is. If you find this useful, why not “like” my post? (The at the bottom)

#!/usr/bin/perl -w
# findAudioEncoding.pl

use strict;
my $path = $ARGV[0];
chomp (my @files = `find $path 2> /dev/null | grep -i .avi`);
foreach my $file (@files) {
        chomp (my $channels = `themonospot-console "$file" | grep \"Audio 01\" | awk \' { print \$10 } \'`);
        $channels =~ s/\(//g;
        if ($channels > 2) {
                print "$file : $channels\n";
        }
}

I just spotted that my Nagios/RRD graphs of my home server are showing a strange correlation.

From these graphs, it seems that the higher the outdoor temperature, the more free memory the system has available. I’m sure this is just a coincidence, though…

Outdoor temperature

Free memory

I posted a few months ago to say that my server wasn’t a massive fan of the high temperature in my loft.

Well, now it’s too cold. The UK has had a bit of a cold snap lately. Outdoor temperatures in Bristol last night got as low as -3 °C, and in turn the temperature in my loft went down to 2.5 °C.

Ambient temperature in my loft

Thing is, that’s probably a bit too cold for my server now. The CPU is happily sitting there at 24 °C but the disks are all around 15 °C.

According to Wikipedia:

A common misconception is that a colder hard drive will last longer than a hotter hard drive. The Google study seems to imply the reverse – “lower temperatures are associated with higher failure rates”. Hard drives with S.M.A.R.T.-reported average temperatures below 27 °C had failure rates worse than hard drives with the highest reported average temperature of 50 °C, failure rates at least twice as high as the optimum S.M.A.R.T.-reported temperature range of 36 °C to 47 °C.

So my disks appear to be at risk of failing sooner. Worse yet, they’re not consistently at 15 °C but fluctuate wildly on a daily and seasonal basis. Looks like all I can do is keep my data on a redundant array and swap out any disks when (not if) they fail.

For some time now I’ve been running Ubuntu 9.04 Netbook Remix on my EeePC 901. I’ve been very impressed with it.

Today I was prompted to upgrade to the new version, 9.10. On my connection at work (via Janet) the upgrade didn’t take long at all…

Upgrade Screenshot

After 9 minutes of frenzied downloading, the upgrade itself took around an hour and a half. Afterwards, I rebooted. I like what they’ve done with the UI!

Ubuntu Screenshot

The roll-over animations make it look and feel nice and polished to use. They’ve also paid close attention to certain aspects of the interface, such as the package manager. It’s a breeze to configure the system.

One notable new addition is Ubuntu One, a free cloud storage service. I have no need for it, as I have my own server, but it’s a handy feature for most people.

Most of the stuff is the same old. Most things work the same as they used to, so it takes no time at all to find your way around the new version.

Well done Ubuntu!

For those who have been following the issues around Samba suddenly breaking upon upgrade, I’ve now got to the bottom of it.

I’ve updated the original post with details, so if you wish to leave comments, please leave them on that post.

I’ve now written several Nagios plugins and submitted them all to MonitoringExchange.

Here’s a quick summary:

• check_temper for monitoring the temperature with a TEMPer USB thermometer
• check_kernel for checking that the currently running kernel on an RPM-based system is the most recent installed kernel (not necessarily the latest available kernel in the repository)
• check_aql_balance for monitoring the number of SMS text message credits on your AQL account^[1]
• check_k8temp for monitoring the temperature of an AMD K8 (e.g. Athlon or Sempron) CPU

As I said in a previous post, I finally got my TEMPer USB thermometer to work on Fedora, thanks to a patch by Tollef Fog Heen that has now been incorporated into the Fedora kernel.

I’m not familiar with C so I only made minor tweaks to Tollef Fog Heen’s code, which returns a temperature as a number. I wrote a wrapper in Perl that crudely interfaces this program to Nagios. In reality, I should wise up on my C a little and write the whole thing in C. When I do this, I’ll submit it to Monitoring Exchange.

For the time being, I’ll publish my Nagios plugin on this blog, in the hope that it might be useful to someone, despite being incredibly hacky.

First you’ll need the code for the program that reads the temperature from the TEMPer. Compile it like this:

g++ -o get_temper TEMPer2.c

Note that the path to the TEMPer device is hard-coded in the C If yours isn’t at /dev/ttyUSB0 then you’ll need to change the source before compiling.

Then download my Nagios plugin (check_temper), and put both the plugin and the program get_temper in your Nagios plugin directory. This is likely to be /usr/local/nagios/libexec if you built from source, and /usr/lib/nagios/plugins if you installed from RPM in the Fedora repository.

Now all you have to do is the usual Nagios magic for adding any other plugin. Simple!

Update

Forget all that you’ve read above! I’ve now rewritten the entire plugin in C, so there is no need for the perl wrapper. You can download it from MonitoringExchange.

Some time ago I bought a cheap USB thermometer called TEMPer. I was disappointed to find that it didn’t work on Fedora. It would only work on Windows using a poor piece of proprietary software.

I eventually found the blog of Tollef Fog Heen, who had managed to get his TEMPer to work. Unfortunately his solution involved patching and compiling a kernel.

However since then, it seems his patch has been integrated into the stock Fedora kernel and it is now possible to read the temperature from it.

The TEMPer device appears to be a USB-serial adapter, with a serial I2C device at the end of it. It’s not straightforward to extract the temperature from it, but Tollef Fog Heen has written a simple C program to return the temperature.

His program polls the TEMPer every second and prints the temperature to the command line. It doesn’t stop until you kill the program. I made a couple of tweaks to the code so it prints the temperature once, formatted as a raw number with no extra text, and then quits. You can find my modified source here.

Disclaimer: I don’t know C. I haven’t changed any of the logic of the code, only the way it prints the output. If the code is buggy, it wasn’t me!

Now I have an executable that returns the temperature from the TEMPer, I can think about building some application that could use this. How about a Nagios plugin?

Today I encountered a problem in my FreeRADIUS setup. Usernames can be sent to my RADIUS servers as a simple username (e.g. jonathan) or with a realm prepended (e.g. DOMAIN\jonathan).

When a username with a realm gets sent to a RADIUS authentication server that is doing MSCHAP, the domain is automatically stripped and you never notice. But when it gets sent to an accounting server (clearly no MSCHAP) there is no stripping or escaping done automatically.

This caught me out.

Users were authenticating on my network successfully. DOMAIN\rachel and DOMAIN\thomas were happily authenticated against the domain controllers and gained access to the wireless. But when they started sending accounting packets, the \r and \t portions of their usernames were sent to the database unquoted, where they were interpreted as a Unix newline and a tabspace respectively.

Eeek!

I didn’t notice until I saw that MySQL had converted these \r and \t characters to the hex equivalents. Where my accounting table should have contained rachel, it actually contained DOMAIN=0Dachel.

Yikes!

I fixed this by creating a local proxy realm. At the end of my proxy.conf, I added these lines:

realm DOMAIN {
}

Obviously substituting DOMAIN for the real name of my domain.

Then in the preacct section of my virtual server I added the module ntdomain to populate the variable %{Stripped-User-Name} with the domain part of the username that was originally in %{User-Name}.

Now, looking at the top of whichever dialup.conf suits your database architecture, make sure the following line is uncommented:

sql_user_name = "%{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}}"

…and that all other definitions of sql_user_name are commented.

Once you’ve done this, your accounting detail logs will contain username likes DOMAIN\\username (with an escaped backslash) and your database table will simply have username.

I have a samba fileserver which has been happily running for a couple of years with identical config but on different versions of samba, and on Fedora and CentOS.

The latest incarnation was running samba 3.2.11.

But the other day, my samba package was upgraded to 3.4.1

Samba shares on the server immediately stopped working and access is immediately denied to all users.

I looked at the config and nothing has changed during the upgrade.

I looked at the logs and no access attempts are recorded; no errors are logged.

I noticed that the new template config file is a little different from previous versions, so I made the necessary changes and migrated my config to the new file. No change to samba’s behaviour at all.

For a while I wondered if I had a rogue samba server on my network, but stopping my samba service causes requests to time out rather than be denied. So it’s definitely my samba daemon that’s responding, but goodness knows why it behaving like this.

Restarting samba puts the following in the log file:

[2009/10/02 10:33:54,  0] smbd/server.c:1065(main)
smbd version 3.4.1-0.41.fc11 started.
Copyright Andrew Tridgell and the Samba Team 1992-2009
[2009/10/02 10:33:54,  0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use
[2009/10/02 10:33:54,  0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Address already in use

I will keep hunting until I find what’s caused this. Unfortunately I can’t watch any of my recorded TV programmes until then!

I’ll post back here when I’ve tracked it down.

Update: I managed to get Samba working again. Sort of. This is a snippet from my now-working smb.conf:

# ----------------------- Standalone Server Options ------------------------
#
# Scurity can be set to user, share(deprecated) or server(deprecated)
#
# Backend to store user information in. New installations should
# use either tdbsam or ldapsam. smbpasswd is available for backwards
# compatibility. tdbsam requires no further configuration.

security = user
#       passdb backend = tdbsam
passdb backend = smbpasswd

As you can see, I simply reverted to the older smbpasswd authentication after yum upgraded Samba and switched to tdbsam and my shares magically sprung back to life. It’s a shame, because I don’t like going backwards. I like going forwards – hence I run Fedora.

I can confirm that this “fix” works with the latest version of Samba at the time of writing – version 3.4.2.

So despite the claim that tdbsam requires no extra configuration, clearly there’s more to it than that. I will once again post back here when I’ve found a way to enable tdbsam without breaking everything.