Darwin didn't seem to want to boot under QEMU, but OpenDarwin seems to
be doing better... But after what seemed like a successful install, I'm
getting that dang grey screen with the apple symbol upon reboot.
Mon Mar 28 20:21:48 PST 2005
I got the silly idea that it might be fun to port to Darwin... But QEMU
won't boot Darwin for x86... I'm now looking into PearPC and
Sun Mar 27 17:45:25 PST 2005
Some autoconf changes to better support compilers other than gcc.
Tested with tcc on Fedora Core 3 and Solaris' SUNWspro compilers.
Fri Mar 25 22:13:13 PST 2005
It's working on FreeBSD 5.4 Beta 1. :) Releasing 0.999.
Fri Mar 25 18:10:00 PST 2005
I've got fallback-reboot.c ./configure'ing and compiling on FreeBSD, and
I've taken a stab at getting install-rc-script to contend with *BSD rc
systems. Then I discover that FreeBSD 5.4-BETA1 doesn't come with
Thu Mar 24 21:06:22 PST 2005
Starting over with 5.4-BETA1-i386-disc1.iso. :-S I'm using the same
"hard disk" that I used for DragonFly....
Thu Mar 24 20:48:51 PST 2005
I played around with DragonFly some more afterall. Specifically, I got
it running under QEMU, and fiddled around a bit. However, I'm now
seeing that the latest version of vm_mmap.c
has nothing more than stub functions for mlockall() and munlockall(),
and comp.unix.programmer doesn't seem to know a means of simulating
mlockall() given a functional mlock(). So I really am going to
have to move on to FreeBSD. On the bright side for DragonFly, their
compiler is predefining __FreeBSD__ to 4, so it shouldn't be too hard to
come up with code that'll build and work on both FreeBSD and
DragonFly, once DragonFly has a real mlockall() implementation.
Tue Mar 15 16:47:06 PST 2005
Today, I was fiddling with a Sun, starting to do some SVM/RAID 5
experiments. At a moment when the Sun Ultra 1's SCSI subsystem was
useless (no commands would run at the shell prompt at all),
fallback-reboot still cheerfully gave a prompt....
Sat Mar 12 11:20:14 PST 2005
I put some time into porting fallback-reboot to DragonFly BSD. They
sounded like the best match, since:
They bill themselves as a more progressive BSD
I like Dragonflies a lot
The live CD didn't have a ksh or bash, and their /bin/sh doesn't
appear to support shell functions
As I was hunting around for the right includes and preprocessor
symbols, I got popped into a kernel debugger. "continue" just
gave an error, and "next" got stuck in an endless loop.
...so, I may try FreeBSD if I find some time for a *BSD port again.
Mon Mar 7 10:50:39 PST 2005
Releasing 0.998. In this version:
DEBUG cpp symbol renamed to AUTH_NO_REBOOT
DEBUG2 cpp symbol renamed to VERBOSE
AIX uses plock() instead of mlockall() now
install-bufsock knows how to set the $PATH more broadly, to be more
likely to pick up a python executable
Note: this release not announced on freshmeat.
Sun Mar 6 21:24:02 PST 2005
Releasing 0.997. This version supports AIX 5.1, understands prngd, has
a bit better installation system, and allows you to easily change the
ports on which fallback-reboot and prngd are on via configure options.
Thu Mar 3 12:16:54 PST 2005
Released 0.996. Includes misc cleanups, especially some safeguards for
bad /.fallback-reboot-passwd files. Also improved autoconf portability.
I tested building the daemon with SUNWspro cc (solaris native cc) today.
It built fine, but I had to get rid of the -ansi -pedantic -Wall in the
Mon Feb 21 18:00:58 PST 2005
Releasing version 0.995. In this version:
The daemon only supports RIPEMD-160, not SHA-1 anymore, since
SHA-1 has been broken. This means that old fallback-reboot-client
programs (0.99 and before) are incompatible with the new daemon.
The new client is compatible with both the new daemon
(RIPEMD-160) and the old daemons (SHA-1, Cleartext).
The client now attempts to use RIPEMD-160 via the optional, and
often not preinstalled, M2Crypto python module. This module comes
with Fedora Core 3, but not Redhat Enterprise 3 or Solaris 9. If
fallback-reboot-client cannot find this module, it will fall back
to a bidirectional pipe to the openssl program, which must be on
A minor DOS attack is fixed. The attack was against the daemon,
not the host the daemon was running on.
This release has been tested on an Ubuntu 4.10 system, using a
pipe to openssl, not with M2Crypto.
Thu Feb 3 17:37:16 PST 2005
A serious error in the SIGUSR1 stuff snuck through. I believe it's
fixed now - at least on FC3. Releasing 0.99.
Thu Feb 3 10:14:52 PST 2005
Releasing 0.98. Main changes are that the programs go in $prefix/sbin,
not $prefix/bin, and the daemon will reread /.fallback-reboot-passwd if
you send it a SIGUSR1. Also "make install" does not create
/.fallback-reboot-passwd anymore; that's up to S11fallback-reboot now,
and even that's only done if the file doesn't already exist.
Wed Feb 2 21:44:21 PST 2005
I have a strong hypothesis as to why bill didn't reboot tonight. I ran
my fallback-reboot setup script more than once. The second invocation
would have rewritten /.fallback-reboot-passwd, but the daemon memorizes
this file's content upon invocation. Also, the second invocation of the
daemon would have errored out due to a busy port.
Wed Feb 2 21:38:51 PST 2005
Release 0.96 tonight. Please see the Changelog for changes.
S11fallback-reboot respects --prefix now, and is generated from
S11fallback-reboot generates /.fallback-reboot-passwd if it does
not yet exist
fallback-rewboot daemon uses SO_REUSEADDR
"make install" removes the previous binary to avoid Text File Busy
"make clean" also removes S11fallback-reboot
Wed Feb 2 19:01:17 PST 2005
A Redhat Enterprise 3 server got stuck tonight, named bill. We've been
collecting fallback-reboot-passwd's using gpg and srsh.
I attempted to reboot bill by decrypting bill's fallback-reboot-passwd
and entering it into fallback-reboot-client bill, but I consistently got
a "Bad password, disconnecting.." error, and no reboot. I plan to check
if bill's fallback-reboot-passwd was somehow changed once it's back up.
Thu Jan 27 15:46:16 PST 2005
We've largely rolled out fallback-reboot in UCI/NACS/DCS on the systems
to which it is applicable (Recent Solaris, Recent Linux). I currently
have a machine that is getting stuck a lot (runs Fedora Core 3), and I'm
now finding that although I cannot ssh into the machine, I can
fallback-reboot it. It's beginning to look
like this FC3 machine is getting bit by the pci=routeirq thing. More
Thu Jan 20 15:57:34 PST 2005
I've split out the password into a separate file in the root directory,
among other things. Please see the ChangeLog for specifics. Also we've
set a rollout of the program in motion in my group, so hopefully we'll
have some good data on just how effective this is, within a month or
Sun Jan 16, 2005:
I've added cryptography, to strongly deter replay attacks.
You can still use it without crypto though - in fact, you'll only
get crypto if autoconf can find openssl. The crypto used is your
basic challenge-response system based on SHA1.