Pants Full of Unix

1. Schedule maintenance on a PDU in the middle of a day, on a week dayWednesday.
2. When questioned over this obvious risk in the change management meeting by the Director over Windows systems, assure everyone that nothing could go wrong because the circuit is redundant.
3. Permit your electrical contractor to blow a fuse when performing this work at 11:30 US Eastern.
4. Take down all of the production HP-UX Oracle systems, most of the prod SQL Servers, all of the ESX servers in that site, several network core switches, one blade chassis, the OpenView server you assured us you were migrating off a year ago, so we took it off hardware support (which subsequently fails to boot because one of its PSUs has failed), and assorted other prod systems.
5. Rather than acting in your capacity over Operations, establishing a bridge call, and following the documentation your direct reports have created around order of startup after a site failure, permit chaos to run wild for three hours until cooler heads insist on at least a touch of Order.

Why, yes, I did have fuN at work today!

I didn’t really make much noise when I sucked this content out from Livejournal and put it up here (although maybe I’ll go over there and note that this exists, now that I’m comfortable with its stability), but now I’ve also finally gotten around to something I’ve meant to do for some time: /var/log/gr, wherein you will find links to various RSS feeds that I produce (including one from here).

First off, the reason to do this is that lots of places (notably, anything Brad Fitzpatrick touches…) now weight PTR records matching things like /(dsl|static)-[0-9]+-[0-9]+-[0-9]+-[0-9]+/ as indicating spam. Which, you know, I understand, but it’s a pain for people who maintain their own mail servers and have one of the less-than-ideal ISPs. When I moved into Philly, I was forced to switch from Speakeasy (who I liked very much, and do PTR records without any muss or fuss quickly) to Verizon Business DSL (you don’t get static IPs from Verizon without the business service), and I presumed that getting reverse DNS was going to be a hassle, so I put off doing the research.

After I got around to doing the research, I read various accounts describing pain and irritation, but found several that were successful of which Dean Gibson’s post to the postfix mailing list is the most complete I bothered to record in delicious:

http://archives.neohapsis.com/archives/postfix/2003-07/2967.html

That made made me think it wasn’t going to be a big deal, but I put it off some more (”about a year”, I think) because I was lazy and wasn’t seeing all that much lost mail. I’m still both of those things, but I was going through doing some setup for email at moonbar.net for some of the Apothecary folks (configuring SPF for the domain to forward allowability on through to _spf.google.com, so that they can just spoof the source address in GMail and not deal with my requirements around IMAPS and SMTP with SSL authentication), so I figured I’d clean this up too. It turns out it’s even easier now! Here’s what you do:

1. Email mmvbts@verizon.com the IP address domain mapping that you want.
2. Call 800-483-5325, choose option 3 for “Verizon enhanced products”, choose option 3 for “domain name services”.
3. Explain what you want and that you’ve sent the email (the account isn’t monitored, so you do have to call to tell them to look at it), verify your account information.
4. Wait 24 to 72 hours.

I’m currently in step 4, so I’ll update after I see how that goes…

Update: All set!

> server ns2.bellatlantic.net
Default server: ns2.bellatlantic.net
Address: 71.252.0.72#53
> 71.242.125.164
Server:         ns2.bellatlantic.net
Address:        71.252.0.72#53

164.125.242.71.in-addr.arpa     name = stow.eclipsed.net.

(Yes, they really do still have their primary external DNS in the bellatlantic.net domain.)

eAccelerator.

No, it's not perfect English (Oxford, American, whatever… Standard {Written,White} English), but it makes its point clearly and concisely. Like a blog, it's still conversational (in a way technical documentation “shouldn't” be), but that isn't getting in the way of my understanding the content.

Yes, eAccelerator is easier to describe than the sprawling blob of PHP, but the fact that you're documenting a sprawling blob is no excuse to start writing like you stopped paying attention in English class during fourth grade.

(I note that this maybe sounds like I'm saying, “Speak English!” I don't mean to be. I'd have a harder time processing properly-written Italian or German, and I wouldn't have a prayer in French, Russian, Japanese, and so forth, but I would be completely lost if I were reading Italian or German as poorly written as the English PHP documentation. I have a feeling that someone for whom English was not a first language would be totally stymied by the English PHP documentation. That's simply unacceptable by any sane consumer of the product.)

When you people were telling me to go look at the spec files that you'd written for something else (which was helpful, in theory) or that I should really be using XYZ other Linux distribution (which was completely useless, so you can go get fucked again, still), what you really should have said was:

“Hey, dumbass! PHP5 includes a php5.spec file that does all of that shit. It's right there in the distribution source. So quit whining.”

Because it is, and I'm using it right now.

I don't expect Apache (Solr) Lucene to cough up their own spec file (but find . -name \*.spec is officially part of my SOP now), but I also don't anticipate that it'll scatter binaries and, worse, shared objects hither and yon to the extent that PHP does. Which, you know, is probably wishful thinking, but don't burst my bubble just yet please.