NIC Death/Resurrection

Today I moved EXP IV to its Final Resting Place (FRP), hooked it up to its woefully underpowered UPS, re-installed NUT (Network UPS Tools), played a quick game, and forgot about it.

About four hours later I noticed the sucker dropped off the network.

I guess it took that "Final Resting Place" concept too literally.

The FRP, where EXP III used to live, is at the end of the longest wire on the network. It leaves the switch, travels across the fireplace mantel, and drops down to the other side of the fambly room. Maybe twenty five or thirty feet max. Apparently, the built-in NVidia NIC was unhappy with that situation, because I plugged my laptop into that wire and it was happy.

So I added a RealTek NIC (RTL 8129C) and edited the udev settings to tell the OS eth0 was now eth1 and eth1 was now eth0 and rebooted.

Maybe this had something to do with the reported lag. Maybe it will be better. Maybe it will die again.

I don't know. If you see any improvement drop me a note.

Screwing The Pooch, Linux-Style

My dear wife, Pinky Dink, has been running Ubuntu 6.04 LTS (LTS="Long Term Support") for close to three years now. She has been quite pleased with it but I've been bugging her about upgrading to 8.04 LTS for months.

But she's seen how my "upgrades" go (the long saga of EXP IV being the most recent) and wanted nothing to do with it. So we compromised for a while. 6.04 came stock with FireFox 1.x, which is dreadfully out of date. I found a hack on the Web and upgraded here to 2.x, which is only woefully out of date. The problem there is the upgrade was out-of-band, so she stopped getting updates to FireFox or important plug-ins like Flash (which is full of vulnerabilities and has been hacked to death lately).

Not a good situation.

So I finally talked her into it and she let me do it.

I anticipated the SCSI issue. Maybe you haven't noticed, but IDE hard drives are obsolete. SATA is now king and to simplify things, Linux now treats all drives as SCSI drives. If you upgrade to a new kernel and your root drive is on /dev/hda1 (the old IDE drive designation), the kernel will choke on boot because it thinks it should be /dev/sda1 (SCSI). The way around that is to either use LVM (Logical Volume Manager - which I despise) or to label your drives before you upgrade, which is exactly what I did, having learned that the hard way over several VM Linux upgrades and the EXP III/IV debacle. Use e2label for ext2/3/4 drives and mkswap /dev/whatever -L yourlabel for the swap partition. Then edit /etc/fstab with LABEL=yourlabel where /dev/hdax used to be. Reboot to make sure it works. If it doesn't... call me. Leave a message.

I knew there were going to be other issues. VNC4 is a wash, as I mentioned before. I was prepared for that. The alternative has always been Cygwin/X, which is slower and suffers from a lack of a dependable clipboard, among other things.

What I didn't expect was problems with her wireless drivers. When I first set that box up back in '06, the RaLink drivers had to be built from alpha or beta source and had to be rebuilt every time there was a kernel upgrade.

But over the years, the RaLink drivers were mainlined into the Linux kernel and that problem disappeared.

Turns out, it's back. With a vengeance. And it's apparently due to some "philosophical" differences the developers at Ubuntu have with the driver. For details, see this exasperated posting from some poor schmuck who can't get Ubuntu to admit they have a problem. I followed his lead, downloaded the source code, and blacklisted the stock Ubuntu drivers. Wireless is fine again, but I will be fucked on the next kernel upgrade.

One problem down.

The next was the remoting issue. Pinky's box is in the kitchen, but I always used VNC4 to hook up to it and do patching and housekeeping (which is a really bad idea - if your session gets trashed during an upgrade you can leave the box in an "undefined" state - but I'm prepared to take that risk because I'm too lazy to get up out of my chair).

As I said, I expected to fall back on Cygwin/X. Silly me.

Cygwin, for those who may not know, is a set of Linux utilities that run on top of Windows. Cygwin/X is an X server that allows you to run graphical programs or full graphical desktop sessions on another Unix box across the network while you're logged in to Windows.

This is very nice, considering it's free when most third party X servers (such as Hummingbird Exceed) cost hundreds of dollars.

The problem is, with all due respect to the Cygwin developers, they keep fucking the god damned thing up.

Upgrading Cygwin is a crap shoot. Something is always guaranteed to be broken.

So when I tried to connect to Pinkie's box and the X screen kept bouncing, blinking on and off, I knew I was in for more fun. I crossed my fingers, girded my loins, and upgraded Cygwin.

It worked. Or perhaps I should say I simply haven't found what's broken in it yet.

Now I have the box where I want it to be (almost). In fact I'm posting from it now, wirelessly and over a network Cygwin/X session! I'm 90% pleased with the way things turned out and this is still the best Linux box I ever built.

Ban-O-Matic is BACK

And it's up to revision 3 at this point. I made several seriously schweet improvements that should be ported over to the other scripts.

Sorry that took so damned long.

An unintended casualty came in the form of _gabriel_chile_. He was an innocent bystander. He simply chose the wrong name. I'll have to straighten that out.

Sorry to make you put up with all those idiots for so long.

And speaking of idiots, I noticed Ranger was back. He's not in the KillFile but he used to be. The sucker is just too damned good.

I've had a few complaints about the new server concerning lag. It's hard to tell from here, but it appears to be OK. There may have been some other issues. Time Warner Telecom (TWT) got hit with a DNS attack last week.

How would TWT's problems affect us?

Well, it goes like this: Some poor schmuck on TWT logs in to the server while TWT's DNS servers are getting bombed. UT isn't affected by the DNS attack because there is no name resolution involved. No problem there, but as soon as this schmuck needs to download one of our UT mods, if he can't resolve www.mrhinkydink.com (the high speed server with all the mods), he's going to pull that mod off the local server (here in my family room) and subsequently consume most of the upstream bandwidth, which would seriously suck for anyone else who happens to be playing.

I'm sure that's clear as mud, but it is a possibility. We get TWT players here all the time and the local mod downloads have been a problem forever.

I did some other things to make the server more responsive. All the game binaries have had their CPU priorities upped.

Anyway, that's that for now. I hope everything's working out for you.