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

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.

The Problem

I don't like to anthropomorphisize technology, but sometimes I swear computers and the like know very well the most inconvenient times to fail. Such as on a Saturday evening, just as I arrive in Tokyo tired and exhausted after a trip halfway round the world. Going on line to check my mail before falling into a deep, jetlagged sleep, I discover the rental server I was running at the time was not responding. Not even to pings. It seemed to have vanished from the net completely.

The Problem

At a former company, whose directors were notorious for spending pounds to save pennies, there was a Server Room. It was basically a small room created by partitioning off one part of the developers' room. It had a door, a window, and was quite spacious - more than enough room for the three racks, PBX set up and miscellaneous collection of "Frankenstein" servers (converted desktops) which had been acquired over the years. There was air-conditioning, of course: supplied by a contraption made in Iran, of all places. (Apparently it was very cheap).

The Problem

In FreeBSD, when using vim in INSERT mode, using the arrow keys results in the characters A, B, C or D being inserted.