...were the weekend.

Saturday was pleasant. Sunday started to get too steamy for comfort, so in the end we closed the windows and turned on the air. That will make it easier to sleep tonight. Tomorrow is supposed to be downright nasty, probably with an excessive heat alert and maybe an air quality warning too.

Tess was out in the pasture for the longest she has been this year, about four hours. Even though I had sprayed and anointed her with fly stuff, the flies were after her by then and she was eager to come in. We've been over two weeks without any rain now, so the grass is getting tough and dry. Not as tasty and nice I suppose, but a lot safer for her since it now starts to resemble hay. She's still eating it with apparent relish, but I'm not worried about grass founder now until we get enough rain to start some new growth.

Gary's starting to talk about a second dog, as I predicted. He's looking at older golden retrievers, which should be fine. I told him it was up to him, since he will be primary caregiver anyway, but probably we don't want a puppy with teething and chewing issues. Just about any dog over two years old should be fine, and dogs over about six often go begging for new homes, so I'm encouraging him to look in that direction.

As for me, I'm still looking for Simon in all the places he isn't any more. Not seeing ghosts, just not seeing him. This morning in the spot where I would have to be careful to step over him I found instead a dead meadow vole brought in by one of the cats. It was not a suitable substitute, though I did in fact step over it.

DECnet workarounds seem to be stable now, but I still have to fix the last few steps so that they happen automatically at boot time rather than requiring manual intervention on my part. I know how to do that, and Ubuntu's "upstart" system be damned. Since they can't be bothered to adequately map it out and explain it, I can't be bothered to use it. Ubuntu gets dumped next time I upgrade. They had promise, but they're heading off a cliff as far as I'm concerned rather than building a usable future.

Earlier this week I installed a bandwidth monitoring tool on the Alpha DS10 at work because it came highly recommended by a couple of people. The Debian installation with synaptic, for whatever reason, was a flop. It didn't all get in the right places, wasn't functional, and I couldn't tell what exactly was wrong, so I "uninstalled" it. I figured I'd download the source, compile, and reinstall next week.

A couple of days later, I realized that my mailbox on that machine had hundreds of messages. Huh? There's no mail service to there, so they had to be internal. It turned out they were coming from crond, the scheduler that runs batch jobs at preset intervals. It was trying to run a reporting job from the uninstalled package, every five minutes. And failing, and failing, and failing...

Except, there was nothing in the crontab. Neither root nor my own account (the only two real non-daemonic users on that machine) had anything in crontab at all. The man pages for crontab suggested that the crond had its own internal storage that was updated only when crontab was updated. OK, so I figured the bad package had installed a crontab, and the uninstall had erased it, but crond never caught on and was still trying to run the now dead crontab. What to do?

Reboot? Stop the daemon and restart it? Neither one did anything. Hmm, how about if I make a new crontab, either empty or with some innocuous thing like "display the time at midnight each day" and let crond realize that the other job was no longer there? Nope, that didn't stop it either. Literal clockwork kept sending me the same error every five minutes. I purged the mailbox twice a day because it was getting so large.

Finally, today, I found it. Debian's man files are not always the best. The crond was using not just the crontabs in /var/spool/cron but also reading manually supplied tables in /etc/cron.d and of course, that's where the culprit command was coming from. Deleted it (as the uninstall should have done,) and the error mails finally stopped coming.

I'm inclined to think such an ill-behaved daemon should instead be named Crom, like Conan's god who lives on a mountaintop and ignores the prayers and lives of mortals. Or maybe I just should have called in Drax, that Timelord technician who was an expert in fixing disordered chronostats?

What a concept. I'm turning the computer off as soon as I post this.

Spent much of the morning battling a recalcitrant Travan tape drive. I picked that machine for the mail server specifically because it had a backup drive on board. Linux recognized it, the commands that should be able to use it make a valiant effort, but... it keeps getting I/O errors. Tried several tapes with similar results. I'm hoping it's just dirty, since it's been sitting unused for several years. Couldn't find a cleaner cartridge, so I have to order one. Meanwhile, backup is by making tarballs and storing them on another machine that does daily backups to tape.

Script kiddies and spammers are still after the machine, but I'm more confident now that it can resist them. The one who keeps trying thousands of usernames and passwords against ssh is certainly never going to get in that way, but I'm about ready to close the ssh port to outside traffic entirely in any case. The spammers in Taiwan and Norway who keep trying to use it as an open relay are getting dumped each time. I ran the prescribed checks against sendmail and it passed them all. So, I'm going to turn down the concern and get my other work done for a while.

Tess was frantic to get to the grass yesterday, but today she was better behaved mostly. She got 45 minutes and came back in without too much urging. (Well, I waved a peppermint alfalfa treat under her nose, but she had to come all the way in to her stall before she got it.)

Car report: Gasoline prices are back up. In fact, they are now the highest they've been in almost a year, higher than when I bought the car. Filled the tank this evening on the way home, and when I ran my spreadsheet, found that for this tank I got 28 mpg, including the day of that awful slushy snow storm. My running average for the last five fuel purchases is 27.05 mpg. As the weather improves, the mileage is climbing again. Hit 6000 miles at the end of last week, though, so I've got to take it in for maintenance.

Weather has been threatening all day, but no rain. Now they seem to have dropped it from the report, but it is still air and damp, with looming clouds. If it were a little warmer I'd be expecting tornado watches.

Anyway, off to do other things.

Gotta go do chores in a few minutes because we're going to dinner and then to an Irish music performance and lecture.

Still I need to vent about lousy documentation, on three sides: Windows (nothing new there), Linux (you mean there even IS documentation?) and Watchguard Systems (no excuse there guys, people pay big bucks for your trash.)

A couple of years ago, I had VPN working from home to the Watchguard Firebox II at work. This let me log in over an encrypted tunnel to tweak things or check on a problem if someone called me, rather than having to drive 15 miles to work on my day off.

Last year the Firebox was upgraded to an X700. VPN has never worked since. I figured it was because the consultants never put my definitions back in, and didn't get around to it for a while because it's a tortuous process only partly described by Watchguard's documents. However, I finally decided I do need it, so this week I've been trying to reinstate it.

No joy. I've followed Watchguard's instructions step by step, defining the connection, enabling it, defining the user, loading all to the firewall box. Since they only provide client setup for Windows, I set up my test client at home on my mate's Windows XP. According to both Microsoft and Watchguard, everything is set up properly. Except, it won't connect. There's a negotiation all right, the Firebox opens a connection when requested, but after a couple of packets are exchanged, it shuts down. So far nothing appears in the log there. The debugging logs on the client station indicate that the connect request is acknowledged, a handshake is exchanged, and then the server closes the connection. I can't see that they even get as far as the authentication sequence. I thought the Norton Firewall on Gary's machine was perhaps interfering, so I disabled it briefly, but with the same result.

Windows produces an error number 619, which is supposed to mean that the port was not available. This makes no sense, because I can see the connection take place and then break. A port unavailable yields either no response or a single denial message.

The Linux VPN client (pptp-client) is messy to set up, but I do understand how it is supposed to work. It doesn't, though. Again, the debug log indicates that the server acknowledges the connection but then closes the socket before asking for authentication. Who knows what Watchguard is doing? I don't. I'm not sure they do either.

I've turned on the debug logging at the server end, but haven't been back there yet to see if it says anything. I don't have high expectations though. I can find several other people over the past two or three years posting similar questions on various linux and security forums. I have found no case where an answer was provided, or where the original poster came back and said he/she got it to work and here's how. As far as I can determine, Watchguard's RUVPN is just broken and doesn't work at all.