Because if you have a machine you suspect you might need to reboot someday, it may save you a trip to the machine's physical location
Because unlike sshd or whatever, I've attempted to make fallback-reboot depend on as few OS and machine resources as possible. Specifically, after the program has initialized itself:
- fallback-reboot does not require fork or exec to be working. It remains memory resident from boot time, until you need it.
- fallback-reboot does not require any disk drives to be working. It doesn't read or write any files - not even log files.
- fallback-reboot does not even appear to require the virtual memory system (code/data paging/swapping in VM) or demand paging from the filesystem to be functioning properly
Yes, it does. However, what it's built overtop of is just TCP/IP, the openssl project's libcrypto, the C library, and a small bit of the berkeley sockets API.
- I hope so!
- Seriously, the server process is written in carefully coded C. It checks return values carefully, and it only reads data with fgets and fgetc. But if you have doubts, please download the code and look it over yourself! The more skeptical you are, the better.
- Also, fallback-reboot uses an accepted algorithm to get a
nonreplayable challenge-response authentication system based on
RIPEMD-160, which to my knowledge is a hash function that hasn't yet
been broken.
In all of my testing of fallback-reboot, I haven't had to do a single manual fsck. However, it is possible you will have to - just unlikely. Also, I'm presently of the belief that journaled/logging filesystems will make this even less likely than it used to be - which wasn't really all that likely to begin with.
- Solaris 2.[79] (2.8 shouldn't be a problem, but building on it is untested)
- Linux (Redhat Enteprise 3, Fedora Core 3, Ubuntu 4.10, Mint 17),
- AIX 5.1 (requires prngd)
- FreeBSD 5.4 Beta 1
BTW, fallback-reboot 1.1 is known not to build on
- Solaris 2.6.
- fallback-reboot has been used successfully on an FC3 system, at a time when sshd was unusable due to extremely high system load. And another time, on the same machine... evolution was growing huge, load was 48+, but fallback-reboot cheerfully gave a prompt. However, eventually, evolution OOM'd, so I didn't need fallback-reboot.
- Tested pretty extensively on Fedora, Redhat Enterprise and
Solaris. BTW, once on a Solaris 8 system, while the SCSI
subsystem was in ruins, fallback-reboot cheerfully gave a prompt.
- Tested it only a tiny bit on Ubuntu
- The AIX port is not that well tested yet - it compiles, runs, and accepts connections, but no reboots yet, as all of our AIX systems are in production. Unless someone else gives me feedback about how the program works on AIX, we'll have to wait until one of our local AIX systems has a serious problem.
- The FreeBSD port has seen only minimal testing, and that was with QEMU, not on physical hardware.
Certainly. AFAIK, fallback-reboot is somewhat unique, but there is a variety of ways of contending with crashy systems. The most similar project I've seen is rICMP, though it appears to be linux-specific, and I haven't seen it ported to kernel 2.6 yet.
Please be sure to use GNU make, sometimes known as "gmake".
Give it a sec. Some forms of getting random data can take a while. Then try it again. If you're feeling in a hurry, you might try using a system call tracer to see what the daemon is up to.
/dev/urandom, /dev/random, or prngd. If you don't have /dev/urandom or /dev/random, you can probably obtain prngd and build it for your system. Put it on tcp/708, unless you want to tell fallback-reboot's configure what port you're going to use for prngd. You may also be able to use egd instead of prngd.
