xenophobia

Finally had a successful migration, end-to-end, without administrator intervention.

We're trying to move everyone off of mares because we are evil and oppressive hosts.  But I hate scheduling moves, especially since I've got a day job and don't like working nights.

Wow, been a while.  No explanation, no apologies.

Anyway.  Spent about a day working on trying to get the Sentry Power Tower XL working with powerman.  I'm not declaring victory here, because I still haven't got powerman working.  But I'm much farther along, and I got sufficiently annoyed at the lack of documentation to rant at Luke, whose remark was "you can fix this."

So.  Documentation on controlling the Sentry/Servertech Power Tower XL via SNMP, as written by someone who's never used SNMP before.

First, set up the box so that you can connect to it.  I used a Cisco-pinout RJ45 serial cable, 9600 8n1.  Power it up, sign in with the default username and password (admn/admn).  If necessary, reset the firmware by holding in the reset button next to the LCD on the front.

(Some notes: "front" is the side with all the plugs, regardless of how you actually choose to mount it.  Also, the reset button is an unlabeled pinhole.)

The online documentation on resetting was a little inaccurate, at least for the firmware version I originally had.  Nothing will happen when you initially push the button.  Hold down the button until the display changes to 3 horizonal lines, then release.  The display will change to one pair of horizontal lines in the middle of the display.

Now that we can log in, we need to upgrade the firmware.  The mechanism is pretty clever.  The box includes an ftp client that can download the firmware from a remote host and install it.  (It also includes an ftp server, apparently, but that's unrelated.)  We ran into trouble because we're on a masq'd network that doesn't allow active FTP.  If you don't have this problem, you can tell the box to download the firmware from ftp://ftp.servertech.com/pub/firmware/Sentry3/Version_5/v5.3/PTXL-PT2x-PT4x-48xx/ .

We downloaded the firmware locally and set up a quick FTP server.  Whatever.

Either way, set the ftp settings as appropriate.  Our settings are as shown:

                                                                               
Sentry: show ftp                                                               
                                                                               
   FTP Client Configuration                                                    
                                                                               
      Host:       172.16.10.206                                                
      Username:   prgmr                                                       
      Password:   ******                                                       
      Directory:  Downloads/                                                   
      Filename:   mrrpm-v53s.bin                                               
                                                                               
   FTP Automatic Update Configuration                                          
                                                                               
      Automatic Updates:  Disabled                                             
      Scheduled Day:      Everyday                                             
      Scheduled Hour:     12 AM                                                
                                                                               
   Command successful              

Then issue a 'restart ftpload'.  The box will download and flash its firmware.

Cool. Now you have a fully armed and operational Sentry Power Tower XL.  (Incidentally, much of this probably also applies to the Switched CDU.)

SNMP is going to be a little tougher, especially if you've never used it.  I had to install the appropriate software (on Ubuntu, apt-get install snmp worked fine.).  Then I had to download MIBs, which translate the numeric keys returned by snmp into human-readable values.  To do this:

 * download mib file: wget ftp://ftp.servertech.com/pub/SNMP/sentry3/Sentry3.mib
 * copy mib file to snmp's search path: cp Sentry3.mib /usr/share/snmp/mibs
 * specify that you want to use this file: I did this by adding a "-m +Sentry3-MIB" to my snmp commands.  There are better ways.  Note that you use the name listed in the file, not the filename itself.

Now you should be able to get useful information.  Try:

$ snmpwalk -v2c -c public -m +Sentry3-MIB

This should give you a long list of keys, including stuff like power usage.  Congratulations.

You should also be able to control the outlets.  This was where I got extremely annoyed and started ranting, because I had to resort to guessing magic numbers to figure this out.  There's probably some documentation somewhere, but I couldn't find it.  To spare you the trouble:

The OID you want is: Sentry3-MIB::outletControlAction.1.1.<outlet number>

The magic numbers are: 1 (on), 2 (off), 3 (reboot).

In our case, the approriate invocation to reboot outlet 4 was:

$ snmpset -v2c -c private -m +Sentry3-MIB 172.16.10.242 Sentry3-MIB::outletControlAction.1.1.4 i 3

That's the translated OID, "i" for integer, and the value we want to set, "3".

Now to actually figure out how to put powerman in front of this.

blog.prgmr.com and wiki.prgmr.com may now be accessed over IPv6.  We also now have SSHFP records in dns for all of the dom0's.  If you notice any missing, please let support know.

replacing a drive;  older system without hot swap. 

we've had packet loss at svtix all day.  my provider tells me:

Reminded Luke that someone who didn't know us might suspect from his blog that we run an extremely unstable service!  That would be a travesty.  I suggested that he make a daily post: "nothing to report" or "doin' fine" or "10 days without a fatal accident" or something like that.

So I've been working on stuff at home, and I want to backup stuff on a publicly accessible server.  Ordinarily, I use a tar pipe for the purpose:

$ ssh user@host "cd parentdir ; tar -cvf - sourcedir" | tar xvf -

Problem is, I'm trying to back up home directories, most of which are inaccessible to my user.  I can't log in as root, because I have root login via SSH disabled like a good sysadmin.  I might be able to use su, but I've never gotten that to work.  Sudo might as well not exist.  This is Solaris.

Normally, I ssh to the remote host and push the tar rather than pulling it, but the home machine is in NAT hell.  Setting up port forwarding sounds like work, and totally inelegant besides.   Luke suggested bouncing the tar through another machine, but yuck.  I mean, really.

Solution: make a fifo and use that.

On the source host:

# mkfifo /transfer
# chmod 666 /transfer
# cd /export ; tar cvf /transfer export

The tar process will begin, then pause while it waits for something to read from the fifo.  On the destination host:

$ ssh user@host cat /transfer | tar xvf -

Problem solved.  Don't forget, putting absolute paths in a tar can ruin your day.

We're working on a virtualization API and web management tool, just like everyone else in the world.  What will differentiate ours is that it will something we want to use, and it will display our. . . idiosyncratic approach to UI, authentication, and features.

Actually I'm pretty enthused.  We're starting from the rackspace API and throwing in Luke's coercive provisioning ideas, and it's kind of turning into something interesting.  (But hungry.  Always hungry.)  I've thrown myself wholeheartedly into the project, as I tend to do when confronted with the prospect of great effort for uncertain reward.

Yeah, I don't know why that is either.  I should probably get that checked.

Okay, I guess that was an adequate break.  I worked through some of the book examples with my dad, and man -- I was rusty.  It was pretty embarrassing, although it all seemed to come back pretty quickly.

Anyway, though, we've hit a bunch of errata.  Mostly little things.  Some absolute deal-breakers.  There are a couple of bits that we need to expand our explanations of.  Some sections where I really just want to say "skip ahead and skim the next two chapters, then come back and this'll make more sense."  Not sure how to deal with those.

I guess these things are never done.