Category: Activities

Another fun day

My colo facility contacted me on Wednesday to say that this weekend they’d be moving my machine to a new rack, and also that they’d gotten a new IP range and I had to switch over to the new range soon, but they’d let me have both IPs for the switch over.

So today my system suddenly went off the air. I was sort of expecting it, but I didn’t see any shutdown messages because they just three-finger-saluted it. After a couple of hours, I phoned for an update, and was told that they’d just powered it up. But it still wasn’t responding to pings, until I mentioned to them that eth0 and eth1 are in the opposite order than what you’d expect.

Once it came up, I tried to configure an eth0:1 using the new IP. That actually seemed to work on the dom0, so then I tried to do it on my domU. That seemed to work too. I was able to ssh into both ips on both the dom0 and the domU. So I thought I’d swap the domU ips around, so the new one was eth0, and the old one was eth0:1, which would make it easier to get rid of the old one when I don’t need it any more. So I changed it in /etc/network/interfaces and rebooted.

But then suddenly things started going pear shaped. The domU was refusing to boot with an error about being unable to find /dev/hda1. On the dom0, “ifconfig” would just hang. And then it stopped responding at all. Now I was in full panic mode. I called Annexa and Dave called the guys who were doing the rack move and convinced them to go back to the facility. I met them there, and found that my poor box wasn’t even responding on the KVM. We power cycled it, and found that it wasn’t starting the domUs, and also that while it started up eth0 and eth0:1, it didn’t start the virtual bridge interfaces (peth0, vif0.0, vif7.0, vif8.0, vif9.0, xenbr0). That’s not good. It appears that Xen doesn’t like the extra interface or something. So I got rid of eth0:1, changed eth0 to the new IP, and rebooted. This time, it started up and so did the domUs.

I was still having a bit of problem with my personal domU – it didn’t want to resolve. Evidently somewhere along the way I’d decided to remove this program “resolvconf” that is supposed to maintain your name resolution for you, and when I did it had replaced my resolv.conf with one that looks like it was copied from my home machine. So I fixed that and things sort of worked, but in spite of the fact that I had the old IP on eth0:1 it wasn’t answering on it.

So it looks like I’m up and running, but I can’t use the old IPs. So you’re not going to see this until your DNS cache updates and you see the updates I made over at zoneedit.com.

USB speed confusion

Every time my external USB disk disconnects itself (like it did after a short power glitch on Wednesday), I have to google the kernel message to see if it remounted with USB 2.0 speed or the slower USB 1.1 speed. I just can’t seem to keep straight in my head whether “USB full speed” or “USB high speed” is the good one.

Note to self: it’s “USB high speed”.

I think.

Dear GoDaddy

I set up “automatic domain renewal” so that I wouldn’t have to take any action, or indeed have to think about it, when one of my domains comes up for renewal. So why do you send me four identical emails within 10 minutes telling me that one of my domains is coming up for renewal? I don’t need to know, that’s why I told you to take care of it! Even one message would have been more than sufficient. But do you really need to blast one to the technical contact, one to the billing contact, one to the registrant and one to the email address on the account? What the fuck is the purpose of having a separate “billing contact” if you’re going to write every email possibly associated with the account about a billing issue. It’s called “billing contact” for a reason, fuckwads.

No, that’s not good either

I wrote about some work I’ve been doing on the Waypoint Generator in Rants and Revelations » Getting there, still some collateral damage. In that, I said I wanted to do some more testing. Well, I did. I reloaded the entire DAFIF dataset. The test took 4 straight days to run, and that’s not including losing a day or so when my router lost its mind. And what this test told me is that the new algorithm for eliminating duplicate points is overzealous.
For instance, it classified two Canadian airports, CYEE Midland/Huronia and CNL8 Wyevale/Boker Field, as being the same. They’re actually nearly two nautical miles apart.

I was calling points the same if the types matched and they’re within 0.05 degrees latitude and 0.05 degrees longitude of each other. Unfortunately that is just about 3 nautical miles in the north/south direction, which this test has shown is too wide a net.

The problem is that I want to spot duplicates when a waypoint changes id, AND when they update the coordinates. I’ve seen places where they’ve updated the coordinates by half a degree, especially in the case of user-entered data.

I think what I’m going to have to do is trust that the coordinates aren’t going to change a whole bunch at the same time the id changes. So what I’ll do is call something a duplicate if it’s within 0.05 degrees if the ids match, but within 0.01 degrees if the ids don’t match. That’s less than a nautical mile, and it would be pretty odd to find two airports within a nautical mile of each other. (A lot less odd to find heliports or reporting points, unfortunately.)

Damn, this means another multi-day test run, unfortunately.