fallback-reboot, a new last resort in rebooting a system remotely

From: Dan Stromberg (strombrg_at_tesuji.nac.uci.edu)
Date: 08/30/04 

Date: 30 Aug 2004 04:25:49 GMT

Comments and suggestions are welcome, especially if there's already
something like this in the free software world. Thanks for reading.

This is the README for fallback-reboot version 0.5.

fallback-reboot is distributed under the terms of the FSF's GPL v2. For
full licensing terms, see the file COPYING.

You can always find the latest version of fallback-reboot at
http://dcs.nac.uci.edu/~strombrg/fallback-reboot

If you run it as root, say from an rc script, then it can be used as a
last-resort remote-reboot facility. And I do mean last-resort; it
doesn't even try to sync your disks, it just goes down hard and fast,
on the assumption that you've already tried the good ways, and this is
all that's left.

I've carefully set up the Makefile (augmented with a python script) to
give you a random password, because I knew that if I distributed this
package with a default password, some clown somewhere wouldn't bother to
change the password and get into trouble. So there you go, you get a
highly random, 8 character password, but you can change it to something
else if you want. I believe that using a hard-to-type random password
is more effective at getting people to change a password, than giving
them a password like "changeme".

The program is at a low version number for three reasons:
1) I haven't had a reason to use it yet; I've only done light testing of
it. In fact, I only just wrote it today, Sun Aug 29, 2004, but I have a
system that's crashing often, and I plan to try it there at first
opportunity.
2) It is subject to replay attacks.
3) The password is compiled into the executable. I may actually keep
this limitation though...

The program sits in the background, after doing an mlockall() to
keep itself from being paged, and listening for connections on a
compiled-in port number (3002 by default in the current incarnation, but
I may look for a better port later), reads a password from that port,
and if the password is correct, the program attempts a reboot -without-
doing any sync()'s, or any other form of disk I/O. Yes, this means you
could lose data, but then you already tried the orderly shutdown
procedures, and they didn't work, right?

For now, client-side usage is basically like:

telnet confused.host.com 3002
This is fallback-reboot version 0.5.
Enter password:

BTW, if telnet just hangs instead of giving you a password prompt, the
first thing to check is to see if you've neglected to punch a hole
through your personal firewall (iptables, ipchains, whatever).

Server-side usage is like:

#!/bin/sh
/usr/local/bin/fallback-reboot &

...I recommend putting this in /etc/rc3.d or rc5.d or whatever.

On Tru64, you may want to use my "daemon" program, like:

/usr/local/bin/daemon /usr/local/bin/fallback-reboot &

...because at least -some- versions of Tru64 don't finish changing
runlevels until all the programs started from the rc directory for that
runlevel terminate - "daemon" gets around that.

BTW, I -don't- recommend starting it like:

/usr/local/bin/fallback-reboot > /var/adm/fb.out 2>&1

...or similar, because then you're getting back into disk I/O, which is
a big part of what we're trying to avoid to gain
accessibility/reliability.

Future plans include adding some form of cryptography to prevent replay
attacks, and a specialised client, probably written in python - but
these things will have to wait until I find out more about how the basic
idea works. I may also make it autoconf'd, if I end up porting it
around enough to make that worthwhile. And I may do a getservbyname()
for the port number, and possibly put the password in a file all by
itself, or maybe use a public+private key cryptosystem. I'm kind of
fond of challenge-response systems based on a hash though.

The current version is pretty linux-specific, but if the basic idea
works out, I'll at least want to port it to Solaris as well, and
possibly AIX, IRIX and Tru64 as well. As far as linux versions go, I've
built the program on Redhat 9, Redhat Enterprise Linux 3, and Fedora
Core 2, all with no errors despite compiling with -ansi -pedantic -Wall
(a nice, high warning level).

If you disconnect after telnet'ing, but before entering a password,
fallback-reboot will send some ominous looking errors to the TTY you
started it from. Don't worry too much about them, as long as
fallback-reboot keeps waiting around for the next authentication
attempt.

fallback-reboot will attempt to confirm whether the reboot is working or
not, but it may not be able to for obvious reasons. :) ping is your
friend. BTW, if the machine isn't even pingable, you usually don't need
to bother trying this program.

Enjoy.

Dan Stromberg, Sun Aug 29 19:50:09 PDT 2004, strombrg@uci.edu,
http://dcs.nac.uci.edu/~strombrg 

-- 
Dan Stromberg                                               UCI/NACS/DCS