While installing Debian 6 on VirtualBox, I noticed it evidently detected it was running in VirtualBox and automatically added three virtualbox-ose-guest-* packages to the install, which is nice. However they are somewhat dated - version 3.2.x whereas the GuestAdditions virtual CD mounted by VirtualBox provides 4.1.x.

Remove the existing packages with:

  apt-get remove virtualbox-ose-guest-dkms virtualbox-ose-guest-utils virtualbox-ose-guest-x11

(otherwise the GuestAdditions installer will complain) and reboot to remove installed kernel modules.

The virtual CD does not appear to be startable from a double click - the error "Cannot find the autorun program" pops up - instead run the script directly with:

  bash VBoxLinuxAdditions-x86.run

A further reboot will activate the GuestAdditions.

After upgrading my development environment to openSuSE 12.1, I started getting a bunch of notices like the below after every Subversion operation which uses SSH:

The issue is discussed here; in a nutshell, the solution is to add "-q" to the ssh command invoked by SVN, which is defined in the configuration file (typically ~/.subversion/config). In my case, the line in question now looks like this:

ssh = $SVN_SSH ssh -q -o ControlMaster=no

Note: ensure this line is in the [tunnels] section of the config file.

I got the following error when building PHP with cURL (on openSuSE 12.1):

/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: ext/curl/.libs/interface.o: undefined reference to symbol 'CRYPTO_set_id_callback'
/usr/lib64/gcc/x86_64-suse-linux/4.6/../../../../x86_64-suse-linux/bin/ld: note: 'CRYPTO_set_id_callback' is defined in DSO /lib64/libcrypto.so.1.0.0 so try adding it to the linker command line
/lib64/libcrypto.so.1.0.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1

Not sure why it's happening, but a look in Makefile showed that EXTRA_LIBS contained "-lcrypt" twice:

EXTRA_LIBS = -lcrypt -lz -lresolv -lcrypt -lpq -lrt -lpq -lpng -lz -ljpeg -lcurl -lrt -lm -ldl -lnsl -lxml2 -lzlcurl -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt

Changing the last "-lcrypt" to "-lcrypto" resolved the problem:

EXTRA_LIBS = -lcrypt -lz -lresolv -lcrypt -lpq -lrt -lpq -lpng -lz -ljpeg -lcurl -lrt -lm -ldl -lnsl -lxml2 -lzlcurl -lxml2 -lz -lm -lxml2 -lz -lm -lcrypt -lxml2 -lz -lm -lxml2 -lz -lm -lxml2 -lz -lm -lcrypto

I was idly watching some Apache access logs scroll by (well actually I was busy doing something, but like to keep an eye on things to spot any interesting or worrying trends early) and noticed a bunch of entries like this:

94.228.34.238 - - [06/Feb/2011:06:21:23 +0100] "GET /blog/?o=10 HTTP/1.1" 301 290 "-" "magpie-crawler/1.1 (U; Linux amd64; en-GB; +http://www.brandwatch.net)"
94.228.34.238 - - [006/Feb/2011:06:21:33 +0100] "GET /blog/?o=40 HTTP/1.1" 301 290 "-" "magpie-crawler/1.1 (U; Linux amd64; en-GB; +http://www.brandwatch.net)"

Never noticed that UA before, and it never seemed to follow up on the (perfectly valid) 301 redirects. A scan through 3 months of logs shows it's been doing that all the time - what a dumb bot.

Checking the URL provided, this appears to be the home page of a UK-based company providing "Social Media Monitoring Tools" - and who don't have the courtesy to provide any more information about their bot / crawler. Which is evidently not popular in some quarters.

So, as "Brandwatch" provides neither myself not the sites I run with any conceivable benefit, it's on the blocklist they go.

(I wonder if they monitor their own brand?)

OK, this has been driving me crazy for a bit - all I want to do is map the ol' caps lock key to CTRL using my .Xmodmap, but it seems XFCE4 overrides any settings made in .Xmodmap.

Turns out the solution (at least in Xubuntu 10.10 ,"Maverick Meerkat") is to navigate to "Xfce Menu" > "Settings" -> "Keyboard" and to click the "Use system defaults" option:

On a related note, I wonder if this solution still works...

I noticed this fella hammering away at one of my sites:

195.42.102.25 - - [31/Aug/2010:02:16:10 +0200] "GET /some/url.html HTTP/1.1" 200 13427 "-" "Mozilla/5.0 (compatible; Purebot/1.1; +http://www.puritysearch.net/)"
195.42.102.25 - - [31/Aug/2010:02:16:12 +0200] "GET /some/other/url.html HTTP/1.1" 200 55822 "-" "Mozilla/5.0 (compatible; Purebot/1.1; +http://www.puritysearch.net/)"

The URL in the browser UA string appears at first glance to be some kind of search site, but the "category link" on the page are stuffed with the kind of keywords you associate with spam of all kinds and no actual search results were returned for a couple of common keywords.

It now has its own entry in the Bad Bot List and some special rules at firewall level. Hasta la vista.

Here at Penguin Blogs, Inc. we get a fair bit of comment spam. Most of it is automatically blocked by a fairly ingenious filter mechanism, but from time to time unknowns get through such as contentless posts like the following:

Very nice posting. I liked it.
thank you for your great posting.
Well that was a nice post

Purportedly this was written by a "Nick Matyas" of "Web Royalty" - what looks to be a legitimate SEO consultancy (look them up yourself, I'm not giving them the benefit of a link) but who are either using underhanded spamming methods, or have made a bad choice in outsourcing their own SEO.

Whatever, their URL is now on the filter list for this and many other sites, so they won't be troubling us here again.

The RocketRaid 1740 (rr174x) is a  4-channel PCI to Serial ATA II RAID controller, which according to the documentation is "ideal for small business home and office servers, NAS storage, workgroup and web servers". In this case it is being used in a generic PC to create and manage a RAID5 array of 4 1TB disks for a simple data storage facility.

The 174x (and other HighPoint products) have good and well-documented driver support for a range of operating systems including diverse Linux distributions and FreeBSD, see here for details:

http://www.highpoint-tech.com/BIOS_Driver/page/rr1740.htm

It appears the most reliable way to install the driver is to use the "Open Source Driver" provided at the bottom of the drivers page. Follow a fresh installation the following packages need to be installed to do this:

• gcc
• make
• linux-headers-$(uname -r)

Download the .tgz file to a suitable directory, and in the directory product/rr1740pm/linux/ execute "make install". (No need for a prior "make").

Following a reboot the rr174x kernel module should be successfully installed and issuing dmesg | grep rr174x  should produce output like this:

[   27.757987] rr174x: module license 'Proprietary' taints kernel.
[   27.766618] rr174x:RocketRAID 174x controller driver v2.4 (Nov 28 2009 17:49:58)
[   27.766694] rr174x:adapter at PCI 2:4:0, IRQ 18
[   28.342352] rr174x:start channel [0,0]
[   28.343802] rr174x:start channel [0,1]
[   28.345248] rr174x:start channel [0,2]
[   28.346694] rr174x:start channel [0,3]
[   28.556067] rr174x:[0 0] Start channel soft reset.
[   28.556094] rr174x:[0 1] Start channel soft reset.
[   28.556115] rr174x:[0 2] Start channel soft reset.
[   28.556134] rr174x:[0 3] Start channel soft reset.
[   28.956572] rr174x:channel [0,0] started successfully
[   29.088461] rr174x:channel [0,1] started successfully
[   29.210253] rr174x:channel [0,2] started successfully
[   29.322073] rr174x:channel [0,3] started successfully
[   29.416168] scsi2 : rr174x

Update: this works in exactly the same way in Ubuntu 10.4 LTS, so presumably all recent Ubuntu versions, and probably most recent Linux distributions.

The problem:

Mails from a particular customer are frequently being rejected by our mail server (exim) because the hostname provided by the sending mail server does not resolve to the sending IP address. For example:

The solution:

In an ideal world the customer's IT department (or at least whoever is responsible for their IT affairs) would fix the problem at their end, as it would be in their own interest to do so. However, experience shows that it's hard to get hold of the right person or people, let alone explain what the problem is and what they can do about it (especially if several layers of outsourcing are involved).

Failing that, it would be convenient if our mail server software had some sort of facility for whitelisting particular IP addresses / hosts. Unfortunately however, mail server administration is not my speciality, and here experience shows that even if such an option exists, I can search for hours before definitively establishing its existence (or lack thereof) and implementing it in a way which doesn't screw with the rest of the mail server configuration.

Another possibility would be to switch off hostname validation entirely (if such an option exists), however this would open the floodgates to all the spam mail which is being rejected by this test (the current mainlog has 4965 such entries for the last 13 days).

Much simple, in the end, is to add an entry for the offending hostname in /etc/hosts, a matter of a few seconds and in the short term much less invasive than messing around with the mailserver configuration. It's useful to annotate what the entry is there for of course, and also bear in mind any issues which could arise through a particular hostname being "hardwired" to a particular IP address. The latter would be the case e.g. if another application on the same server needed to access other services under the same hostname (in one case I have had to add the primary domain name of a customer to /etc/hosts so we can receive their mails).

When it comes to the great vi versus Emacs debate, I am firmly on both sides of the fence, using vi (or vim) for smaller, command-line based editing tasks (particularly when working on remote servers); and Emacs for software development. Unfortunately, the default Emacs installation in Linux is, to put it mildly, butt-ugly:

(Click for full-sized version... it doesn't look quite so bad when scaled down).

Playing around with the standard font selection settings doesn't help much as the standard Emacs package does not support antialiased fonts in Linux (or more precisely X.org). However since version 23.1 XFT is supported, albeit experimentially, which provides much nicer font display:

In Ubuntu the package emacs-snapshot provides antialiased font support and seems to work without any problems.

More details on XFT-enabled Emacs are here: http://www.emacswiki.org/emacs/XftGnuEmacs

Over the last couple of years I've been leading a somewhat itinerant lifestyle and have been mainly relying on products from the House of Jobs for my UNIXoid computing needs. Consequently I haven't been keeping up with the latest developments in desktop Linux, and having just had the opportunity to set up a brand-new PC with Xubuntu, I'm suffering a little bit of culture shock: for some reason everything "just worked". It basically installed itself with no manual editing of configuration files necessary.

However, in Xubuntu there doesn't seem to be a simple, mouse-based way of mapping the goddam awful CAPSLOCK key to CTRL. No problem, I thought. Just let me get at /etc/X11/XF86Config /etc/X11/xorg.conf with a handy text editor, just like in the good old days. Weird. Not much in there, is there? A bit of poking around online reveals that HAL appears to have taken over, and my PC is trying to eject me from the pod bays into the vacuum of space. No, scratch that, HAL stands for "Hardware Abstraction Layer" and is something nifty which takes care of the nasty business of different sorts of hardware devices being plugged in. It also provides the capability to create XML configuration files modifying the behaviour of attached devices, such as the keyboard. The place to do this is in the directory /etc/hal/fdi/policy/ and the file can have any name, provided it ends in .fdi. 

For setting the caps lock key to CTRL the following appears to work:

X.org needs to be restarted for the configuration to take effect. (Some sources indicated restarting the hal daemon will cause the new settings to be registered, but this didn't work for me.)

Note that HAL is scheduled for replacement (which might explain repeated "I can't let you do that, Dave" entries in /var/log/messages) by something called DeviceKit, which will be even niftier (though quite possibly requiring a totally different style of configuration.

Having moved a bit recently and being busy at the same time, I still haven't got round to setting up my home network quite the way I'd like it. With the result that a while back I checked out some code from a Subversion repository to a laptop, and when I came to check it back in the LAN IP of the box with the repository on it had changed. Of course the working copy was still pointing to the old IP, making it impossible to commit my code changed, and the cheap consumer-grade router which looks after the network doesn't seem capable of assigning IP addresses based on MAC address. How to get the working copy pointed at the changed IP address?

Castig about in the .svn directories in the working copy, each contains a text file named "entries" which in turn contains two lines which look like this:

Manually updating the IP address seemed to work for that directory, so a simple

took care of the entire working copy. Rather than just update the IP address I created an entry in /etc/hosts for svn.local, so should the repository IP address change again before I get things sorted, all I need to do is update the IP address here rather than mess about with SVN internals.

(Another workaround would be to make a tarball of the working copy without the .svn directories, delete the working copy, check it out again and untar the code over the new working copy.)