Long weekend that was over much to quickly. <G> I didn't get half the things I needed to accomplish done, although I did get *enough* done. BRIGID is working, after a fashion; I gave up on SuSE 7.1 and installed Mandrake 7.2. Flawless, not a single problem. I need to upgrade a few things (I suppose I don't really HAVE to, since this is an internal-access-only box, but it's a bad habit to start thinking that way) and the printer configuration still isn't correct, but at least the box boots up correctly. I might also download and try Mandrake 8.0, although I'm not certain about that. The only problem with these network changes is that I no longer have a play-around box; everything's production. Have to do something about that.

I gave away a computer this weekend; BRIGID had a twin system, named ATHENA, that was originally going to go to Keri's family as a firewall. That's impossible (their DSL modem is internal, incompatable with Linux, and uses time-limited connections) so instead it went to her Aunt Sue as a workstation. It needs a power supply, but that's not a serious problem. And in return, we got an old HP LaserJet printer and a new motherboard for PLUTO. (I don't know if PLUTO's coming out of retirement or not; I might use it as a testbed, something like that.) The printer is one of the original LaserJets; there's no number after the "t", Roman or Arabic. If I can get it working, fine; we'll see how it goes. If not... well, I'm sure we can fine someone to unload it on. <G>

Speaking of old hardware, while we were at Keri's aunt's house, her uncle John cleaned out his old computer storage closet (I supervised.) Among the interesting odds and ends were an original (and, so far as could be told without plugging it in, functional) Apple Macintosh. A "classic" from before they had that printed on the case, with the integrated CRT and no hard drive; 512k RAM on this model. Even some software, still collected in floppy disk boxes (no hard drive on those machines.) I'm not a Mac fan; I've been known to make comments about wanting an iMac, but only to gut and turn into a fish tank. (BTW, if anyone has an iMac shell they want to part with, I'm quite serious.) Still, it would be kind of an interesting project to see just what could be done with that little machine.

Oh, and I did pick up a game over the weekend. Railroad Tycoon II for Linux, from Loki. I'd played the original Railroad Tycoon many years ago and enjoyed it, so when I saw it on sale at the local Half Price Books, I figured it might be fun. (Besides, it was amusing to see all the "This game will not run on Windows! Linux Only!" and Tux stickers the staff had plastered all over the box. Even then, the cashier asked to make sure we knew it wasn't a Windows game.) It is a fun game, and it works fine in Linux; I did have it crash once, by switching to another desktop to check email, but that's it. Good graphics, interesting scenarios (this is the Gold edition, with two lengthy campaigns and about two dozen stand-alone "missions") and challenging gameplay. The missions range from 1830's England to 1900's China to Antarctica in the next century, after "Global Warming" has changed it into a new breadbasket. There's also North America, both historical and "After the Floods"; that's kind of interesting, too. I think (not having played all of the scenarios yet) that every continent is represented at least once, some of them several times. Just don't play a future- or modern-time game right after a historical scenario; the sticker shock of seeing train prices go from $10,000 to $500,000 when the initial game-cash is about the same is something of a shock. <G> At any rate, it's very playable.

And, last but not least, the new essay for the week is up, with an update on Conestoga. See you later...

Tuesday, April 3 - Well Isn't That Just a Shocker

First, I have to apologize to Bob Walder. I falsely gave credit to John Dominik yesterday for OFIM(tm) when Bob had it clearly trademarked. What can I say - OFIWM.

Now that that's out of the way, let's move on to the rant, shall we? <G>

It's no secret that a few weeks ago, ICANN announced a proposed change to the current agreements with Verisign regarding their control over the "Big Three" TLDs, .com, .net, and .org. Under the proposed change, Verisign would be allowed to keep the .com registry essentially indefinitely (at least until 2007, with preferential treatment after that - in Internet time, that's pretty close to indefinite) and would not be forced to separate their registrar and .com "owner" businesses. Just to add insult to injury, .org was mentioned in passing as being transferred to a non-profit organization at the end of 2002, with the stated intention of returning .org to the its "original function" - domains for non-profit organizations.

For more on the story of what, where, when, why, and how, go take a look at Hands Off My .Org. They've got most of the story, with links to the original sources. I'm not going to reiterate the whole story, except to say that I both participated in ICANN's "public feedback forum" and communicated by email with Mike Roberts, who was head of ICANN at the time. This proposed change generated a lot of feedback, very, very little of it in favor. Despite that, ICANN approved the change yesterday. As for their public feedback forum... Mike Roberts posted one message, when the forum was set up, before there had been much "feedback". Since then, there has been no sign that ICANN ever looked at the forum, read it, or even noticed its existence. So much for public accountability.

Since this happened, I've heard of a few interesting developments. One is New.net creating new TLDs without ICANN's permission; they've already gotten some ISPs to use their root server, worked out a method for users of ISPs that haven't, and are starting to gain some popularity. Maybe someone should set up a competing root-level DNS registry. I can't, I've got my own windmills to tilt at. But it sure would be interesting to see what would happen if, say, the Linux or Open Source (all right, all right RMS... the Free Software community) were to create a distributed network of root servers in competition with ICANN. Then only thing keeping ICANN in control of the DNS organization is inertia; there's absolutely no reason why DNS servers can't be pointed to other root servers. On Unix servers running BIND - i.e., the great majority of DNS servers on the Internet - it would take a matter of seconds by a root-level user to make the change. You could even just ADD the new root servers, so ICANN's domain system would still be accessable.

Wouldn't that be interesting?

PS - if you're interested in setting up access to the New.net domains, and you administrate DNS servers, go look at this page.

Wednesday, April 4 - More DNS Info

To continue yesterday's topic, there's an article today in the Village Voice about the alternative root servers. They're focusing mainly on one system that's apparently been around for quite a while, but they also mention New.net and a few other alternative coalitions that I hadn't heard from before. It definitely sounds like New.net has the advantage, but it raised another point as well - the threat of balkanization. After all, it's possible that some ISPs will use New.net's root servers and ignore ICANN. Others will use the "official" root servers, and ignore New.net. And what about those littler guys? Where do they fit?

The problem is that DNS is really not a solidly controlled system, in the sense that there's no barrier to entry to being a root domain server. The exact same server that I'm using today to serve domains could be a TLD, other than the bandwidth and system load problems. Which means that virtually anyone can declare themselves to be an alternative root server. Now, as it mentions in the article, most of those who've already done so have banded together into two groups. Even so, that means there are *five* sets of "root servers" right now, some of them conflicting as to what TLDs they serve. All five competing for recognition by the world's ISPs. You might tell your friend your email address as recorded by one of those root server systems - but if he or she isn't using the same root server, they won't be able to find you.

Resolving the more basic part of that issue - how to see TLDs served by other root servers - is relatively simple. Either create and distribute a "root.hints" file (which the DNS server uses to find those root servers) which contains ALL of the root server organizations, or create a truly open "Super-Root" which serves the same purpose - anyone can register a new root server with the "Super-Root", and DNS queries simply spam across all of them looking for the TLD they want.

The real problem is the TLD conflicts. People being, generally speaking, unimaginative, I'm sure that each of the alternative root servers have a few TLDs in common; off the top of my head, the most likely conflicts are .sex, .kids, .shop, and .web. I'm equally certain that ther are others I haven't listed; from some information I've been able to find, a few of the organizations registered TLDs because other root servers already had them, deliberately putting themselves into competition. That's a lot tougher to solve. After all, if you make it possible for anyone to become a root server - and there's no way to prevent it - then it's impossible to prevent those root servers from creating competing TLDs.

So it seems we come full circle; to get out from under a stupidly inefficient (or deliberately harmful) organization in the form of ICANN, we create a problem that can only be solved by created another ruling body - which could easily end up exactly where ICANN is. Catch-22.

Or have we?

Do we really need to create a central organization to arbitrate these things? Or is it possible to do it some other way? Suppose we find a way to meld these organizations into one Super-Root, as stated above. What are the possible means of resolving the TLD (and below that, the domain) conflicts that are certain to occur?

• Ruling Standards Body, a la ICANN
• First-Come First-Served
• Arbitration and Decision by a randomly selected member of the Super-Root
• Reasoned Debate followed by Compromise and Cooperation
• Trial by Combat
• I rule as benevolent dictator, casting decisions with the flip of a coin and banishing the loser to by eaten by dogs

OK, so maybe some of those aren't as serious as others...

The first is unacceptable. That's what we have now, and there's too much potential for corruption and balkanization. The second... well, again, you need someone to arbitrate who was first, and the loser would be almost certain to simply split off to form a new root server organization. The biggest problem isn't handling future disputes by would-be root servers; it's getting the *current* root servers to agree. And that's a problem it will be very, very difficult to solve.

Looks like interesting times ahead. I do not believe ICANN will survive; they have angered too many domain holders. I don't think New.net can, alone, take over the entire DNS namespace. And the other groups all appear too small to survive. Interesting times, indeed...

Friday, April 6 - I Do These Stupid Things Because I'm An Idiot

Sorry about the lack of an update yesterday. Ummm... yesterday ran a little long. <G> Work was a continuous stretch spent hammering the keyboard, resolving various issues related to an upgrade the other night, and dealing with a pair of junior admins that, to be frank for a moment, suck. Not much I can do about that for the moment, but by 4 o'clock I was tired of dealing with them, so I used the time I'd accumulated during the previous night's overtime and went home early. Keri said I was supposed to take it easy and not do anything on computers last night, but we all know how long that lasted. So after a time period of relaxing and taking it easy, I went in and started fiddling with Apache on THOR.

See, I use a couple of password protected folders here on my site. It's not that I don't love and trust you all, it's just that I like to be able to refer to my copy of O'Reilly's Perl CD Bookshelf from anywhere, including work - and since that's a copyrighted work, sharing it online would be bad. So, I just restrict access to the folder. I'm not THAT worried about it - is anyone really coing to exert concentrated effort to get at my copy of the cd when they could find it online somewhere free for the asking? I doubt it - so I just use an .htaccess file. How does that work you ask? Well, it's really quite simple.

Rather than writing a tutorial on it, I'm going to point you to two other tutorials, both of them very well written. The first (and more basic) is here on Apache Today, an excellent site filled with Apache news and information. The setup they describe is essentially, with a few modifications, the one I'm using today. The other tutorial, also on Apache Today, is much more in-depth and goes through some of the more advanced methods of restricting access to portions of your site. It's in four parts: Part 1, Part 2, Part 3, and Part 4. They're all (in my opinion) well written explanations of how this stuff works.

Now we come to the idiot part. <G>

If you read the first tutorial, you'll notice that the first thing it says to do is to at a directive to the listing in the httpd.conf configuration file. That directive - "AllowOverride AuthConfig" - tells Apache to watch for .htaccess files. Well... I kinda forget to check that. I knew it worked, you see - it worked fine on my site for the Perl CD. And so when Keri said she needed to password-protect a few client sites-in-progress, I just assumed they'd work too. And we all know what happens when we assume, right? Right. It didn't work. At all. I spent two days struggling to figure out why it didn't work, and finally, in a fit of frustration, I asked the Daynotes backchannel for hints. I got responses, too, but nothing that helped. Then it hit me. I knew I had that AuthConfig option in there, but... well... it wouldn't hurt to take a look. So I went in, and I looked.

Ooops.

The problem was, I had two settings for my site, and only one for the others. I had a general one, applying to /www/*/html, which I'd intended to be the only one - and it didn't have AuthConfig set. The other one, which probably snuck in as a copy/paste from my old server, applied only to my site, and did have it set. Therefore, it worked fine on my site, and didn't on anyone else's.

The two directives were otherwise identical, so I just deleted the one for my site and changed the generic one. It was a simple fix, but sheesh... two days to find it...

Ah well. "I Do These Silly Things..." and both endings, if you please. <G>

In other news, the emergence of my wife the geek continues. <G> Just look at her post for today. Look! She fixed a couple of computer problems on her own! I'm so happy! And she's asking for hardware... <sniff> It makes me remember why I married her all over again.