Updating jwhois on CentOS to solve v6nic errors

I use fail2ban on my servers, and I noticed whois queries to v6nic.net were running into problems. If you're having the same problems, here's how to fix them.

I use fail2ban on some of my servers, along with the "jwhois" application (to automatically return whois info in the automated fail2ban emails I receive).

I noticed that 43.229.53.15 was coming back in my emails as follows:

 [Querying whois.v6nic.net]
 [Unable to connect to remote host]
 missing whois program

This is because v6nic.net is defunct and has been taken over by a cybersquatter (discussion about this on the Red Hat Bugzilla). The whois server whois.apnic.net works adequately in its place.

The version of jwhois available from the epel repo for el6 (CentOS 6) is out of date:

jwhois.x86_64 4.0-19.el6 @base

rpmfind lists 4.0-43 for Fedora Core 24 as the latest version, but this isn't compatible (loads of dependency issues if you try and manually install).

So, let's fix it manually.

jwhois derives its list of whois servers from /etc/jwhois.conf (by default). Let's do a search/replace all with nano.

Assuming nano is installed (sudo yum install nano -y) do the following:
Press Ctrl \
Type in whois.v6nic.net and press Enter
Type in whois.apnic.net and press Enter
Press A to replace all found instances
Type Ctrl X to exit, then Y to save the changed file.
Done!

Related reading, if you've got nothing else to do...

Replacing a FiiO E7 battery - simple! (Photos)

I've had a FiiO E7 headphone amp for a few years and it's recently gained a new lease of life -- as an audio interface! However, the OEM battery got a bit long in the tooth, so I set about replacing it. It's much easier than you might think. Click through for photos and step-by-step instructions, plus a list of components to buy. (Warning: magnifying glass and hot glue gun are advantageous!)

I've had a FiiO E7 headphone amp for a few years and it's recently gained a new lease of life -- as an audio interface for my LG G3! Sadly, the has G3 shockingly bad audio quality from its onboard 3.5 mm output - riddled with noise, fuzz/hiss and audible aliasing and distortion. This is likely due to poor design from LG in an effort to power save, combined with a latent bug in Android relating to how it scales audio samples, the latter sounding like it's aliasing audio in a certain range of gain due to it internally resampling or something stupid like that. My old Galaxy S3 LTE running Cyanogenmod 10 (4.2.2) sounded amazing, I wish it hadn't died!

ANYWAY! Recent builds of Android (I'm running 5.1) include a provision for audio-via-USB, enabled by default on most devices, so hooking up a micro-to-mini USB cable between the phone and the E7 gives you blissfully great audio quality.

So, I dug mine out of a cupboard - with a flat battery, of course - and charged it up. Soon after, the battery got fat and decided to push the front of the screen out... Ok, time to replace the battery! Continue reading "Replacing a FiiO E7 battery - simple! (Photos)"

Photos: inside a 'vintage' BT street cabinet

Following on from the Virgin Media street cab article, I came across a PCP last week with the doors left unlocked (and wide open to the elements!) I phoned it in to Openreach and it's already fixed, but as I had my camera...

This is a 'vintage' BT street cabinet, so no FTTC VDSL equipment. Still hoping to grab some close-up snaps of one of those, though given the cost of equipment in them I doubt I'd find an open one which wasn't vandalised. Who knows...

Some photos for your nerdy enjoyment:

Tiplet: no SNMP replies? Fix broken SNMP responses in Windows Server 2008, Windows 8

I encountered a weird problem on a Windows Server 2008 R2 install which had dual NICs on the same physical network (different subnets, DNS and gateways) - you could interrogate its SNMP agent and you wouldn't get a response even though the right community was set and you might initially see it working properly! This borkage would happen indefinitely after beginning, though punctuated with momentary spurts of correct operation (depending on which way the wind was blowing, how you looked at the box, whether you spoke softly to it...) but then arbitrarily breaking again. Intensely frustrating.

From my own analysis, as SNMP traffic is (usually) UDP, the responses were being routed through the wrong interface (Windows' SNMP agent binds automatically to all interfaces on 0.0.0.0:161 and doesn't care about interface order or metrics, even if you define custom metrics -- though you can force it by setting metrics on your connections' default gateways). The incorrectly-identified replies to SNMP requests were also being caught by the firewall (for whatever reason), even though it has the appropriate SNMP rules to allow ingress/egress traffic on UDP 161 and 162 (trap traffic).

But guess what, for once MS has actually issued a fix for this! It's on the Microsoft site via the snappily-named article "Incorrect source IP address is returned in the SNMP response in Windows 8, Windows Server 2012, Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008". I've applied this to the servers I'm setting up monitoring for, and it works beautifully.

Big kudos to "mobilenow" who linked to this hotfix on the Solarwinds Thwack forum and explained the hotfix was produced after they opened a bug case after similarly trawling the net during production of their ServerSilo monitoring product. Probably worth checking them out. 🙂

Hopefully this avoids you wasting as much time as I spent trying to fix this...

I