waxing philosophical about "firstboot", and program design

[Robert P. J. Day]

  (time to kill and i'm in a typing mood, so if you don't want to
argue about program design, no problem.)

  i think i finally figured out how firstboot works, and its actual
logic flow is making me kind of queasy, so i thought i'd ramble on
about it and see what others had to think.  feel free to follow along
in /etc/rc.d/init.d/firstboot in FC3, i'll refer to lines there.

  first, i'm assuming that firstboot is initially invoked by having an
actual "S" start symlink to its init script that is removed after it's
run.  sounds logical, but it turns out to be kind of messy, as you'll
see later.  (BTW, i make this assumption based on the
chkconfig-related lines at the top of the script.)

  note some of the explanation at the top of that script:

"Firstboot is a druid style program that runs on the first time a
machine is booted after install.  It checks for the existence of an
/etc/sysconfig/firstboot file.  If it doesn't find the file, then the
firstboot program needs to run.  If it finds the file, firstboot will
not be run..."

the above is simply not true.  look at what happens when this script
is invoked with the "start" argument.

  first, the default action is set to "run".  that really creeps me
out -- that the default behaviour is to run.  given the significance
of something like firstboot and what kind of changes it can wreak on
your system, it makes *way* more sense to default to *not* run, and
only run if very explicit settings (like kernel command line params or
env variables) tell it to.  and, no, i don't think that's picky.  i
firmly believe that the default behaviour for *anything* should be to
do as little harm as possible unless clearly told otherwise, but
that's just me.  anyway, onward.

  the first check is:

  if [ -f "$FILENAME" ] && ! grep -q '^RUN_FIRSTBOOT=YES' "$FILENAME"
  then
      action=skip
  fi

note that this disagrees with the documentation, which claims that, if
the file is there, firstboot will not be run.  no, that's not what's
happening here.  the check is, if the file exists *and* contains
anything *other* than RUN_FIRSTBOOT=YES, firstboot will not be run.
(at this point, i'm visualizing some developers sitting around after a
few beers, yelling, "hey!  who can make this logic as convoluted as
possible?  obfuscated code contest, everybody!")

  what's wrong with just saying, the file *must* exist and it must
contain RUN_FIRSTBOOT=YES?  *any* other situation means no.  what the
current situation means is that, if the file is completely missing for
some reason, firstboot will be run.  and i find that scary.

  in addition, it's now confusing as to what will prevent firstboot
from running on subsequent boots.  you can't just *not* call firstboot
anymore since it's also responsible for processing "reconfig"
requests.  so, i guess i just got confused again -- who calls
firstboot during system boot?

  even though there's more, i'll just leave it there for now.
thoughts?

rday