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.)

A quick shell script to make an atomic copy of a Subversion repository using svn hotcopy:

Quick self-note:

MalwareBytes ( http://www.malwarebytes.org/ )

 Comboxfix ( http://www.bleepingcomputer.com/combofix/ )

MS Malicious Software Removal Tool: http://www.microsoft.com/security/malwareremove/default.aspx

Also: list of sites worth blocking: http://www.grc.com/sn/hosts_mvps_org.txt

When accessing a remote server via SSH from a workstation connected to the internet via e.g. a NATed router setup, quite often the SSH will just hang after a short period of inactivity.

To prevent this, add the following lines to the SSH daemon config file (usually /etc/ssh/sshd_config):

KeepAlive yes
ClientAliveInterval 30

and restart the daemon (a reload may not be effective).

Also note that the SSH session used to make the change to the SSH daemon may not benefit from the modified configuration.

I recently purchased an HP 2133 mini-notebook, and while it's quite a nice piece of equipment it does have some annoyances. One of which is the Synaptics touchpad, which appears to simulate a left-click of the mouse if the cursor hovers over certain GUI elements for more than a second or two - this makes working without a proper mouse a right royal pain in the posterior. This appears to be the default hardware behaviour, as the same thing happened in the pre-installed Windows Vista.

After some trawling through Google it appears the solution is to add the following line to the relevant InputDevice section of xorg.conf:

    Option "TapButton1" "0" 

After restarting X this seems to solve the problem.

Venerable tech discussion site Slashdot seems to have lost its way a bit in recent years, but occasionally it comes up with some useful stuff apart from tired memes ("In Soviet Russia Natalie Portman pours hot grits into your pants"), such as the following three threads which contain a mixed bag of readers' Unix, vi (vim) and Emacs tricks.

• (Useful) Stupid Unix Tricks?
• (Useful) Stupid Vim Tricks?
• (Stupid) Useful Emacs Tricks?

Of course, there are more than one or two tricks I'm personally familiar with, but also a whole boatload of stuff where you have to think "Why didn't I know this before (or think to find out if such a thing exists)?". Such as generic auto-completion in Emacs, "Meta-/".

 

One of the first tools I install on a fresh OS X installation is the excellent iTerm. However, "out of the box" the cursor keys (arrow keys) don't seem to work in many text-based applications such as vi/vim.

One solution (in 0.9.5) is as follows:

• Click on Bookmarks, then Manage Profiles
• Select Default from the Terminal Profiles section
• Change the Type option below Terminal Settings to linux (sic)

In all newly-opened iTerm sessions the cursor keys should then work as desired.

Deja-vu all over again...

74.86.249.98 - - [19/Dec/2007:10:17:22 +0100] "GET /path/to/file HTTP/1.1" 200 10049 "-" "Mozilla/5.0 (compatible; Gigamega.bot/1.0; +http://www.gigamega.net/bot.html)"

When starting Alfresco after making changes to the .war file, it appears to start and it is possible to access the login page and log in, but all other actions result in a server error. The error logs then contain messages like this:

09:25:01,313 ERROR [org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/alfresco].[jsp]] Servlet.service() for servlet jsp threw exception java.lang.OutOfMemoryError: PermGen space