Re: linux-ipsec: Boot script bug: locking the boot process

> It seems that the current scripts are bringing up the remote SG's

No, this time it's just a case of all the testing having been done with setups in which connection setup was quick. I suppose there's a reason, in a sense: it's usually better to do things sequentially if you can, because it makes testing and troubleshooting much easier. However, it is true that connection setup is potentially time-consuming, so this is a case where a different approach may be in order, at least as an option.

> If not then I would gripe that it's a bug and should happen at least

I think pluto can cope with it in parallel. However, if there are many connections, this could give quite a pile of whack processes running, possibly enough to cause difficulties. I think doing this really requires a "nowait" option for whack, so that it can go away as soon as it's passed the word to pluto (as it used to, in fact), rather than waiting around for pluto's reply.

Doing it asynchronously is easy, but see last paragraph.

There is a higher-level issue here which might cause difficulties by and by: what happens if later phases of the boot are starting programs which depend on the connections being up? Of course, that's really a more general issue, because even if the setup attempts are being done synchronously, they can fail.

A related problem is the need to clear away any asynchronous leftovers if the IPSEC subsystem is stopped or restarted. That little headache makes me think that "whack --nowait" is the right way to do this -- then the asychronism is all inside pluto, where it can be handled cleanly.

                                                          Henry Spencer
                                                       henry@spsystems.net
                                                     (henry@zoo.toronto.edu)