And Then I Kind Of Hacked My Own Work

      Yesterday provided those moments of happiness and terror associated with thrilling adventure or, perhaps, opera.

      In the course of what should be a routine, even cut-and-dried kind of task, that's not really a good thing.  It was only supposed to be an address change on a critical piece of equipment at the North Campus.  My last-chance (or last-but-one) emeritus laptop booted slowly and took a long time to settle down; the version of Java it had on the shelf was even older than the device I was connecting to wanted, but upgraded smoothly and displayed the login screen.

      Which wanted a password.  The factory default didn't work. 

      Uh-oh.  It's lazy of me, but for anything not connected to the public internet or in-house network, I routinely keep the default password.  No matter how carefully you document changes, there is always the chance you'll be hit by a bus and the next tech who has to work on the thing won't be able to find the set of manuals you used, or won't be able to read your notes, or won't think to look for them.  There are ways around that.  Posting login information on devices that are generally inaccessible is one method, and all the better if there's a door or cover that has to be opened to get at the network port or serial connection; but even those have the potential to trip someone up or are security holes.

      So why would I have changed this one?  Think, think--  Oh!  The passwords (there are three levels of access) are global: the "admin" login on the configuration port is the same one used for the (not as powerful) port used for monitoring and control!  But...what was that password?  That one, we'd posted on the back of the clipboard the operators used for their on/off-duty logs -- but we don't have local operators these days and the clipboard was miles away if it even still existed.

      But hadn't I come up with a strong mnemonic for that password?  Oh dear, whatever had I--  It came to me in a striking image,* just as I had intended.   I tried that password and I was in!

     The changes I needed to make weren't huge.  A new IP address, gateway and domain server to get the device on the new, more-secure (and harshly tested) company network, some minor alterations, and it was time to hit "APPLY CHANGES."

      Oh, right.  It's very Linux-y.  A mouse-click, the screen blanked--  And the touchscreen on the front of the device went out!

      There's always a funny feeling when your blood pressure spikes, your pulse begins to race, and a few seconds tick slowly past before calm memory reminds, "It does this every time, you know."  It's been a dozen years since I had to make any changes to this device.  Sure enough, after about thirty seconds, the screen lit up with text and it talked itself through the reboot process, scrolled a few jillion lines by and settled on, "RECALIBRATE TOUCHSCREEN? [YES] [NO]."

      That trap was horribly familiar.  The right answer is NO.  Tell it yes and it shrinks the display to a postage stamp and you're done until you can get the manufacturer's tech support into the machine, either in person or by plugging the powerful front-panel configuration port into a dual-NIC computer with the howling masses of the public Internet on the other port, which is, of course, a never-do-this kind of thing.  You'll never guess how I know....

      The screen came came right up after NO.  I connected the normal control and monitor port to the LAN and proceeded to remote into the computer at the far end and move it to the new IP addresses almost routinely; it took a little reassurance that it was okay (it's really not) to run the Java applet that duplicated the touchscreen display.

      That was more than enough drama for one day.  It's not supposed to be an exciting job.
________________________
* Nope, no hints.  It's a lousy password anyway, for a reason I have no intention of explaining.