Two months using RSP with EVAs and going strong

This blog post will be a recap of my painful migration to RSP, which is now almost finished for the systems I care for which are EVAs, Integrity Servers running HP-UX, and Proliant servers running ESX. This post will talk about EVAs. The other systems will be covered later.

When it came time to migrate from ISEE to RSP, I was very fearful of doing the migration for my EVAs. Why? Because server components rarely fail nowadays. This leaves us mostly with mechanical disks, power supplies and batteries. Since disk arrays such as EVAs have a bunch of them, they are the most prone to failure and require the most maintenance.

I started testing RSP as early as last October, with disastrous results. There's a price to pay for being bleeding edge. It took quite a while for me to understand all the RSP components, but now the puzzle is fairly complete. And now that many Jack Bauer-style customers like me have started migrating without the help of HP, I'm seeing an increasing number of disguised complaints in the ITRC forums of disgruntled users, even from HP employees.

I was so pissed with all the bugs I've had with my initial test run of RSP, I decided to go back to square one and put myself in the shoes of HP's QA people, thinking about how they must actually test their software; and I said to myself: "chances are they start with freshly installed environments"... thus I did the same. I reinstalled the CMS from scratch, even went as far as zapping my Storage Management Servers, and took great care to RTFM the boring prerequisites guide which is so clinical that it would make reading medical transcriptions a funny adventure. Every small dependency, from ELMC to MC3 components, to manually configuring WEBES to use the "CommandView" protocol have been taken care of.

And it works!

Up until now, I've had three events, on two different EVAs, and they were all forwarded to WEBES, then the ISEE client, then HP. HP then called back the contact person to schedule what needs to be done. What's fun now is that since everything is centralized rather than dispersed on multiple SMSes. Configuring the contacts for the EVAs is easier. We're spread out in multiple data centers across the province, and this proves much easier to manage.

Using a centralized CMS, however, has its drawbacks. For instance, what will happen if there's an event and the CMS is down? Will it be queued until it gets back up? I haven't tested this yet. Furthermore, should we invest in a highly-available CMS? That's quite a sum of money. And what will happen when my CMS or SMS are out of contract? Guess what, I wouldn't be surprised if it doesn't work anymore.

So many questions, so little time...

Building a lean'n'mean emacs for HP-UX

The port of emacs available in the Porting and Archiving Center for HP-UX is a helluva big build, with all options. It requires a total of 22 libraries, that's nonsense if you're only interested in running the textmode version of emacs. Here's how to build one for HP-UX.

You need the following to build it:

• The aCC compiler - I have not been able to compile it with gcc (both using the stock source or the one modified by the Porting Center). If you don't have it, there is an evaluation versionavailable on the HP Software Depot. Sorry, normally I prefer using gcc, too.
• GNU Make
• Libncurses (also required on the servers where you intend to run emacs. I haven't taken my chances with the stock curses library).

Here is the procedure to follow:

The porting center already did the grunt work of modifying the code to have it compile nicely under HP-UX -- thanks Richard. That is impossible if you take the stock emacs source. Grab that ported source directly from the porting center:

# wget http://hpux.connect.org.uk/ftp/hpux/Editors/emacs-22.3/emacs-22.3-hppa-11.11.depot.gz

Sidenote: if you don't have wget, now would be a good time to install it, it's very useful for doing this kind of stuff if your servers have an outbound connection to the internet.

Extract the tar file and run configure like this:
# ./configure --prefix=/opt/emacs --without-x

N.B. You don't need to add --prefix if you prefer having it under /usr/local. The report at the end of configure should look like this:

Should Emacs use the GNU version of malloc? yes
Should Emacs use a relocating allocator for buffers? yes
Should Emacs use mmap(2) for buffer allocation? no
What window system should Emacs use? none
What toolkit should Emacs use? none
Where do we find X Windows header files? NONE
Where do we find X Windows libraries? NONE
Does Emacs use -lXaw3d? no
Does Emacs use -lXpm? no
Does Emacs use -ljpeg? no
Does Emacs use -ltiff? no
Does Emacs use -lungif? no
Does Emacs use -lpng? no
Does Emacs use X toolkit scroll bars? no

Then run gmake to build emacs:

# gmake

Finally, install emacs:

# gmake install

And you're done.

The Three Way Carter System or: how I Learned to Stop Worrying And Love Rubber Gloves

Disclaimer: I don't work in the trade, and have no field experience. This blog post exists only for the purpose of informing what a Carter System is, and how to protect yourself if you have one -- any electrical work requires a qualified electrician.

The previous diagram shows a wacky (and dangerous) way to bring power from one end to another using three way switches with a light in between. It uses the travelers to carry one neutral and one hot. With this, the two commons can have 4 states:

1. Hot - Neutral (lamp turns on)
2. Neutral - Neutral (lamp turns off)
3. Neutral - Hot (lamp turns on, with reversed polarity)
4. Hot - Hot (lamp turns off, and the socket remains hot)

States #3 and #4 are dangerous, as anyone changing a lightbulb who happens to touch the socket gets an electric shock. An electrician can also have problems changing the light fixture thinking it is off, while it's not necessarily the case. There is no way to know. The only thing that can be of any indication is if the tradesman that initially installed this used both red wires to connect to the light as illustrated above.

I did some research and found out that this is called a "Carter System" or "Chicago Three-Way". I have no clue how local electricians call this over here, but I'm sure they have a name for this. The examples I've seen on the net show that it can be used to power a garage or shed with 3-conductor cable, with an outside light toggled at both ends. Oh yes, and I can't see any relation to President Carter since by the time he was in office, the NEC had outlawed the practice for over 50 years.

In my case, I've seen this inside my circa-1950 house and thus why I blog this here. There are many houses like mine in Montreal, with a long passageway using three-way switches, and I suspect that a cable routing like this must have been installed in more than one place around here.

Can it be fixed? Not without rewiring. You could remove one of the switches, replace the other one with a standard two-way switch, then bring the neutral to the light fixture from the other side of the circuit. But then you'll end up with a light that can be turned on only from one far end of the house, which is probably against some building code as well. Assuming this Carter System passed inspection and was allowed at the time of the installation, it can probably stay there as long as you don't modify the circuit. But if you remodel, it would be a good thing to have it fixed.

To my knowledge, a Carter System doesn't seem to pose any fire hazard, but something as trivial as changing a light bulb can result in an electric shock. And if you're really, really unlucky, the shock can be fatal... As an example, just imagine someone unlucky enough to have a weak heart, unlucky enough to be bare feet on an aluminium step ladder, unlucky enough to have that ladder grounded by one way or another, and unlucky enough to have the switches set to state #4 above. That's a really stupid death that could have been prevented, and a case for primetime news.

Lesson learned: If you live in an old house, wear rubber gloves when changing bulbs, or turn off your breakers first.