Some small, but seemingly intractable problems of the sort rampant in any IT environment which I've
encountered and have found solutions for.
2017-01-10 04:25:00 2017-01-10 04:25:00
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.
2009-10-13 15:25:00 2009-10-13 15:25:00
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:
2009-10-13 18:29:31 no IP address found for host mail3.example.com (during SMTP connection from [80.92.x.xx])
2009-10-13 18:29:31 H=(www3.example.com) [80.92.xx.xx] F=<email@example.com> rejected RCPT <firstname.lastname@example.org>: host lookup failed (80.92.xx.xx does not match any IP address for mail3.example.com)
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).
2009-09-14 04:55:00 2009-09-14 04:55:00
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
2009-08-21 02:21:00 2009-08-21 02:21:00
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
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.
2007-11-26 15:14:00 2007-11-26 15:14:00
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.
2007-11-13 19:23:00 2007-11-13 19:23:00
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).