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.
Related reading, if you've got nothing else to do...
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.
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...
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).
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...