Phoenyx upgrade status report II
Hey, we're mostly over to the new box today. All websites but the primary have been moved, the three "live" users are all moved, and the new server is handling email.
This may sound like no big deal to you, but the old server is running was installed in 1998 and has never been upgraded (aside from security patches on core servers). It's a PII-400 with 192M of RAM and we've been perpetually running out of disk space for years. Moving to a P4-class 1.2Ghz with 512M of RAM and a 190G disk is amazing.
But that's not what this song is about. (Remember DNS? It's a song about DNS.)
When I first started all this migration stuff, I decided to move my secondary DNS from an old co-worker's server (on the same network as mine) to something more separated, and where I could get better visibility into what my secondary was doing. But it needed to be free or really cheap. I found this place called twisted4life.com in Europe, and I set up a few of my minor domains there, and everything seemed great. Their interface tells me when they last attempted a zone transfer, when the last successful transfer was, and things like that. They've got a weird name, but they seemed to be pretty stable.
So last night, in preparation to move my main domain, phoenyx.net, to our new server, I made twisted4life.com secondary for phoenyx.net, and set my TTL on the zone to five minutes, and went to bed. And this morning I changed my MX record to point to the new machine... and twisted4life.com has yet to request a zone transfer, more than 12 hours later. Checking the stats, they actually haven't requested a transfer for more than 36 hours. And here I am, hanging in the wind, with my primary nameserver reporting the new host as MX, and my secondary nameserver reporting the old host. Because despite not transferring my zone (or even attempting to, according to the timestamps on the control panel at t4l), they're happily serving up the old information.
Now, I don't know how DNS name servers normally get queried. I've always assumed, naively, that the first listed server got tried first... but I don't know that there's any reason a DNS resolver shouldn't try them randomly to distribute the load, just like it does with round-robin DNS entries. So I have no idea how many hosts are getting old information.
Oddly, everything else at twisted4life seems to be working... I even deleted one of my zones and it removed it from their nameserver pretty quickly.
This is probably an unusual and ultimately transitory problem with twisted4life. Come Monday, they'll probably be back to normal, and if I'd never tried to do a big change on this particular weekend, I'd probably have never seen a problem. But it sucks to be me today.
So I went looking for alternatives... I'm not sure about any of them. None of them I've looked at (and set up secondary with) tell me as much as twisted4life did (one tells me nothing), one has had oddities with getting responses to DNS queries on all of their DNS servers ("no response, immediate response, no response" patterns).
But right now, phoenyx.net has switched to xname.org, and they seem to be holding up alright so far. Another is set up with everydns.net, but I've had trouble reaching their nameservers... they'll answer, then they'll not answer, then they'll answer, often in the span of a few seconds.
So we'll see how it goes. My money's on xname.org at this point.
I hate spam!
Don't we all? But I especially hate blog and wiki spam, becuase it's not just annoying me, it defaces my site and requires me to take action to clean things up.
My roleplaying blog, The Raven's Mutterings, runs on Blosxom, and a very hacked up Pollxn comment system. I've never messed with CAPTCHAs or the like because Pollxn is an obscure comment system, and my forms don't match the standard Pollxn forms anyway. But I got my first comment spam today, and apparently the spammer plugs my form into a robot, because it kept posting new spam every so often. (Or some poor Russian kid is being paid to manually post to my site all the time.)
Pollxn makes it easy to tweak the form (through a security ID) to change its unique signature... no robot loaded up with the form from this morning will be able to post this afternoon. But I have to change that every time some new spammer loads up a robot with my form.
No easy solution. I hate CAPTCHAs. Hm. There's a text-based CAPTCHA based on simply answering a question. I might be able to work out something with that.
Phoenyx upgrade status report
Finally, I have the new mail server fully configured. It's a pain in the butt transitioning to a completely new mail server system (from Sendmail to Exim), and trying to figure out Debian Linux's convoluted config file system for Exim at the same time.
I ended up installing Exim with the default config that comes with the source to learn how Exim works, then I converted over to the Debian configuration.
See, Debian took what was a monolithic config file, broke it up into pieces so that one basic concept was in each file, and then arranged the files by directory... they get concatenated together, with a little lot of macro substitution going on. Then they used lots of if-defined's and variables, and then used a config file to a config file (really... it's called update-exim4.conf.conf) with a script that takes variables in that file and assigns them to more variables in the main config.
So in the default config, I've got, say, the Exim keyword "local_domains". I can look it up in the manual and I know what it's all about. It's the list of domains the server delivers mail locally for.
So to figure this out, I looked at the generated config file and tracked down local_domains and found it was set to the macro MAIN_LOCAL_DOMAINS. So I searched backwards to find that MAIN_LOCAL_DOMAINS was set to DC_localdomains. So I searched backwards again to find that DC_localdomains was set to an explicit value. To figure out where this value came from, I had to troll through the script that builds the config file to find where DC_localdomains got set to find the user-set variable name.
And that was for a very simple parameter. This makes learning how Exim works while reading the ($70!) manual rather tedious when every other parameter or value is a macro derived from a macro derived from some value generated by a config script.
But I think I've got the whole thing running on Debian's configuration files, doing what I had it doing on my modified source configuration. And then some... the catch here is that the Debian config contains tons more functionality, and gets upgraded pretty smoothly (the point of breaking the thing up is so that you only have to merge changes on the little sections you've changed and not and entire 600+ line file).