[Swan] Can you do a test

[Philippe Vouters]

Paul,

Re-inject those commits and do not discuss. If anyone has to complain 
about my work, he has to contact me with a test case, not you. The only 
thing you proved me is that you are only able to bring a constant mess 
wherever you can.

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 09/01/2013 04:17, Paul Wouters a écrit :
> On Wed, 9 Jan 2013, Philippe Vouters wrote:
>
> Philippe,
>
>> I am awaiting from you to re-inject these commits.
>
> I am not sure why you reverted them at this point, if you did not
> believe they were wrong. I have done testing this morning by reverting
> them in a local branch, and seeing problems going away. That is why I
> asked about your specific scenario.
>
>> The real mess that caused my 2 of 5 days efforts debugging Libreswan 
>> and correcting it is brought in by the fork'ed/exec'ed autoconn 
>> --addall inside programs/pluto/server.c
>>
>> Who had this idea of this fork/exec which does not exist in Openswan ?
>
> A _very_ strong voice from the community during many years that the
> scripting within openswan was way too complicated, and error prone
> especially on embedded systems with non-gnu versions of sh, sed, awk,
> dirname, etc.
>
> The first step was taken when in openswan 2.5, the "addconn" routine was
> introduced, which obsoleted a very complicated "auto" script. The second
> step was to no longer need a script to call the "addconn" command on
> startup (see openswan's old _plutoload script, where it first did all
> the work with sed/awk and later on just called addconn). So calling
> addconn was moved from an external script into the pluto daemon. While
> we could have done this with systemd in a PostExec, by doing it within
> pluto we make it easier on embedded system that just want to start pluto
> straight from /etc/inittab.
>
> Second, the community wanted pluto to parse ipsec.conf itself, so it
> would not need the overly complicated _plutorun/setup/_plutoadd/ipsec
> and _startklips/_startnetkey scripting. This was also very problematic
> on embedded systems. In openswan, pluto is unaware of ipsec.conf, and
> shell scripts parse it and turn it into options specified to pluto.
> This also limits pluto that it cannot re-read its configuration file on
> receiving the HUP signal, something that is implied on modern systems.
>
> Third, the systemd/upstart introduction obsoleted the need for our own
> infinite loop scripting to restart the daemon on crash. Finally, this
> became a core feature of the init system, which meant that _plutorun
> was no longer needed and we could let the init system restart the pluto
> daemon on crash, removing the requirement for _plutorun. We still have
> a very stripped down _plutorun to support sysv init systems that have
> no buildin restart mechanism.
>
> We received positive feedback on these changes.
>
> Tomorrow, I am continuing with Antony to bring up and test more test
> cases. This would either lead to more issues similar to what your
> scenario shows, or not. Once our testing harnass can run the road
> warrior tests, we should also run into your problem, and we can
> investigate. Note that using my red hat vpn on my roadwarrior laptop,
> and using my mobile phone to do ipsec/l2tp while roaming, does not
> trigger the problem you observed. So the status of the commits in
> question should become more clear over the next couple of days.
>
> Regards,
>
> Paul
>