[Openswan dev] asynchronous event-driven initialization / configuration / reconfiguration

[John Denker]

Hi Folks --

Quoting from the ipsec init script:

# The startup and shutdown times are a difficult compromise (in particular,
# it is almost impossible to reconcile them with the insanely early/late
# times of NFS filesystem startup/shutdown).  Startup is after startup of
# syslog and pcmcia support; shutdown is just before shutdown of syslog.

Actually, there is *no* good compromise that covers the general case, as
can be seen from the following use-cases:

 1) Suppose I start up my laptop with no network connections, and then
  carry it to a place where wireless connectivity is available.
 
 2) (Mobility) Same as above, but then I carry it to a place where
  /different/ network connectivity is available.

 3) A similar thing can happen with a desktop:  After the computer has 
  been up for several days, the DHCP server decides to be unfriendly and 
  replace the old IP address with a new and different one.

 4) Suppose we are recovering from a power failure.  At the time the
  computer comes up, there is no network connectivity, because routers
  have not restarted and modems have not synced up.  At some later
  time, the network comes back up.

 5) Suppose I plug in a PCMCIA or USB networking device at some point,
  long after the boot-up process is complete.

 *) etc. etc. etc.

The design of all init.d scripts is archaic because it synchronous.  In
contrast, the modern approach is asynchronous and event-driven.  The "upstart" 
daemon has been around for several years.  It has become reasonably mature 
and has been adopted fairly widely (albeit not universally).
  http://en.wikipedia.org/wiki/Upstart

All in all, I can think of about ten good reasons why openswan initialization,
configuration, and reconfiguration should be asynchronous and event-driven.

Note:  To minimize the pain of supporting distributions that still use init.d 
scripts to the exclusion of upstart, we could use a "library plus wrapper" 
approach.  That is
  ++ most of the code would be in the library scripts
  ++ the init.d script would be a wrapper that calls the library scripts
  ++ the upstart code would be a wrapper that calls the library scripts.

So, some questions:
  a) Has anybody already implemented some version of this?  Partially or 
   otherwise?

  b) Is there any reason for not doing this?