So I have this big-ish Samsonite suitcase which many years ago suffered a partial failure of the telescopic handle, specifically the inner telescopic tube on one side would no longer slide out of the outer tube, so the whole assembly would only partially extend, like this:

Spent a lot of time working out why openvpn wouldn't connect from a Vagrant virtual machine (running Ubuntu 14.04 LTS):

Tue Jan 10 02:51:25 2017 Control Channel Authentication: tls-auth using INLINE static key file
Tue Jan 10 02:51:25 2017 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jan 10 02:51:25 2017 Socket Buffers: R=[212992->200000] S=[212992->200000]
Tue Jan 10 02:51:25 2017 UDPv4 link local: [undef]
Tue Jan 10 02:51:25 2017 UDPv4 link remote: [AF_INET]xxx.xxx.xxx.xxx:1194
Tue Jan 10 02:51:25 2017 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx::1194, sid=92749f62 ced33a12
Tue Jan 10 02:52:25 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Tue Jan 10 02:52:25 2017 TLS Error: TLS handshake failed
Tue Jan 10 02:52:25 2017 SIGUSR1[soft,tls-error] received, process restarting
Tue Jan 10 02:52:25 2017 Restart pause, 2 second(s)

Turns out the openvpn version (2.3.2) is outdated; 2.3.4 or later is needed.

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.