deandra.homeip.net

Ever restart a service after changing a configuration file? If you're a Linux admin, chances are you have. I probably do it several times a day, on average.

Now, when you restart a service, how often, on average, do you check that the service actually restarted? The init scripts in Debian will tell you if it thinks the process started successfully, but do you double-check what the init script told you?

A better question is, "should you have to?"

One of the things I missed about not having Linux on my laptop is that I was unable to use MythTV to watch the shows recorded by my PVR. However, with the discovery of MythTV Player (http://sudu.dk/mythtvplayer/) I found I was once again able to wirelessly stream recordings to anywhere in the house. However, I soon discovered that the Windows networking stack left much to be desired. Playback would constantly underrun the buffer, resulting in halting and choppy playback. After a little net searching, I found a couple tweaks I could make to Vista that seem to have improved network performance.

Overachievement (n): Accomplishing more than planned. Like when a firefighting team starts a controlled burn of a few hectares, and ends up burning down half the countryside. Or when we start a one-hour test to test how well GroupWise would authenticate against OpenLDAP, and ended up deploying the system on a Friday afternoon, with two or three hours to work out the bugs.

Today, after my coworker called in sick, I found myself out at a school, just on the edge of nowhere, re-imaging the workstations. By myself. I thought, "Oh goody, it's only forty-odd machines, I can kick them off, sit around and read Slashdot for fifteen minutes while they image, configure them, and then be on my way by lunchtime.

Pshya, right.

A while ago, I set up one of our Postfix servers at work to do authenticated relaying, so I could relay through that server from anywhere. This made the configuration of Thunderbird on my laptop much easier. However, I made a grievous error during the setup that came back to bite me in the ass.

Reasons

slurpd is deprecated and removed from OpenLDAP 2.4. This means that slurpd replication will probably break in the next Debian stable upgrade (lenny), as Lenny ships with 2.4. I decided to get a head-start, and get syncrepl-based replication working on my existing Etch systems before the upgrades come around.

OpenLDAP, with its single master and multiple read-only slaves, is generally very robust. However, there are times when you might have to kill your master replica and promote one of its slaves in place. Here's a brief rundown on how to do that.

OpenLDAP implements a single-master replication scheme. All slaves have read-only replicas. All LDAP modify operations are performed on the master, and then replicated to the slaves. This provides a much more robust and lightweight system than eDirectory.

The replication process is fairly robust. The replication damon (slurpd) gracefully handles unreachable hosts, and is multithreaded, so an unreachable replica doesn't cause trouble for all the others.

I've lived in Quesnel for about three and a half years now, and I guess I've been spoiled with their road maintenance.

This weekend, I made a trip to Prince George, and as soon as I crossed the city boundary, my Tracker was nearly swallowed by an enormouse pothole. No sooner had I climbed out of that one than another nearly tore off one of my front wheels. This type of abuse continued until I had stopped at my destination.

Every trip in town thereafter was like driving through a field of exploded mines, dodging and swerving to save my alignment and suspension from certain death.

One day, in line at the company cafeteria, Joe says to Mike behind him, "My elbow hurts like hell. I guess I'd better see a doctor."

"Listen, you don't have to spend that kind of money," Mike replies.
"There's a diagnostic computer down at Wal-Mart. Just give it a urine sample and the computer will tell you what's wrong and what to do about it.
It takes ten seconds and costs ten dollars . . A lot cheaper than a doctor."