June 2005 Archives
My mom took this snapshot, and it was impromptu (honest)!
Diagnosing DNS trouble is especially fun because of caching. If you keep doing dig sowbug.org over and over, all you're usually doing is reading the cached value from your local DNS server, rather than confirming that the changes you've made at your registrar are taking effect. So I came up with the following method to try to trace exactly what was happening. It might be wrong, but it seems to make sense.
dig sldfkjalfkajdfldsj.com: The hope in doing this was that I'd get an NXDOMAIN error from the highest possible authority (i.e., farthest from my local DNS). This returned the following:;; AUTHORITY SECTION: com. 10800 IN SOA a.gtld-servers.net. \ nstld.verisign-grs.com. 1120164931 1800 900 604800 900
dig @a.gtld-servers.net sowbug.org: In other words, ask a.gtld-servers.net what it thinks about sowbug.org:;; AUTHORITY SECTION: . 172800 IN NS k.root-servers.net. . 172800 IN NS d.root-servers.net.
dig @k.root-servers.net sowbug.org: Lather, rinse, repeat:;; AUTHORITY SECTION: org. 172800 IN NS tld1.ultradns.net.
dig @tld1.ultradns.net sowbug.org: Ah, now we're getting somewhere:;; AUTHORITY SECTION: sowbug.org. 86400 IN NS park4.secureserver.net. sowbug.org. 86400 IN NS park3.secureserver.net.
At this point I figured out that the root nameservers had the wrong nameservers listed for my domain. So I continued to fiddle with the registrar's self-service web page, and eventually got it right.
Some of what I've done to my new server so far. By the way, it's Fedora Core 2. I'm running Core 2 because Core 3 and later pretty much require yum rather than apt, and yum is a real resource hog and won't reasonably work in 64MB of DRAM.
- As root: crontab -e, then add
25 3 * * * apt-get update && apt-get -y dist-upgrade. - Create a backup script on a different machine with several lines resembling this:
rsync -az -vv --sparse --stats --delete --rsh=ssh root@<hostname>:/home .
I put the public key for the archiving machine in root's .ssh/authorized_keys2, so that the script can log in automatically without needing to know root's password. apt-get install ImageMagick ImageMagick-perl(note that they're case-sensitive!)
I'll update this entry as I do more stuff.
As all three of you noticed, my server died last Wednesday. It's a User Mode Linux server, and my trusty nightly rsync backup script sorta stopped working back in November 2004, so when the server disappeared, yeah, I lost some data.
Fortunately, November 2004 was just before my son was born, so blog entries dropped off dramatically around then, and there wasn't a lot to reconstruct. I got help from several sources:
- Bloglines caches blogs in a format that's pretty faithful to the original. I was able to save their Javascript page, fiddle with it a little, then view the result in my browser. Then I copied the HTML into an HTML editor, and that was close enough to the original content.
- For metadata like timestamps, I asked around and luckily a few friends had RSS and Atom feeds left over on their computers. It helps to know people working at a company developing blog software. :) Thanks, Antony and Erik!
- Google Desktop Search's web history helped with some HTML recovery.
I was able to get all but about five late-2004 items perfectly recovered. Apologies in advance when those show up, incorrectly, as "updated" in your aggregator.
Oh, and by the way, I'm now hosted at Linode. No comment yet on their reliability, but their configuration pages are quite nice. I look forward to the commercialization of Xen; I suspect you get more bang for the buck than UML.
Update: For some reason my registrar decided to switch my domain to their parked host webserver, so anyone visiting sees a "coming soon!" page instead of mine. I believe I fixed the problem two hours ago, but their nameservers are still serving the incorrect address. What good is a 60-minute TTL if you can't get your changes published more quickly than that?
In Gonzales v. Raich, six Supreme Court justices acted against the express will of the people in eight states.* Will Bill Frist now include those justices in his rants against "activist judges"?
*Of the ten states with laws permitting use of medical marijuana, eight enacted their laws as the result of direct popular election.
This past weekend I was burning a DVD, and about halfway through I accidentally dropped something on the keyboard's sleep button. The CPU fan obediently spun down and the monitor promptly switched off. Sigh. I reached for a new DVD blank and prepared to throw away the now-ruined one in the drive. Imagine my amazement when I woke up the computer, it resumed burning, and verification succeeded!
We've come a long way since 1996, when moving the cursor over the wrong part of the desktop would kill a burn.
Yesterday I discovered the shell commands pushd and popd. For some reason every time I read the man pages I didn't grok what they were for, but this time it clicked.
Suppose you're in some directory somewhere like ~/src/main/project/module/test/data/, and you need to work with a file in your ~/scraps directory. Without pushd and popd, you have three choices: open a new shell, cd to ~/scraps and then cd back again when you're done, or use path completion to type the full path to the file in ~/scraps.
But what you really want is the hyperspace button, where you jump to the other directory, do your work, then jump back wherever you were before. This is what pushd/popd does:
[~/src/main/project/module/test/data] $ pushd ~/scraps [~/scraps] $ (work with the file) [~/scraps] $ popd [~/src/main/project/module/test/data] $ (I'm back here again!)
As you can guess from the command names, it's a stack. So you can push all the locations you want and then get back where you were when you're done.
A belated thanks to my friend and partner in entrepreneurial endeavors, Erik Kay, who mentioned these commands to me two years ago.
