On 02/26/10 12:08, Stefan Bauer wrote:
> Damn, i just mentioned, i already integrated that flushing in the
> racoon.prerm script but did not included the changes in the last
> version.
>
> This will be fixed in 1:0.7.3-2 which is already waiting for an
> upload into unstable.
That's nice thanks.
At the risk of beeing stubborn, would you mind adding an invocation
like that to a prerm script of ipsec-tools? That would be fine.
> Snippet from /var/lib/dpkg/info/racoon.prerm
>
> case "$1" in
> remove|upgrade|deconfigure)
> # stopping the setkey service to flush the kernel IPsec
> SA/SP database
> /etc/init.d/setkey stop || echo "Kernel IPsec SA/SP database
> flushed" || echo 0
If you did not change that in setkey.init script, it already says
something like "Flushing IPsec SA/SP database: done". So you probably
don't need the 'echo' statement.
Besides, I don't think we should call
/etc/init.d/setkey stop
on *upgrade*. Or do you plan to call
/etc/init.d/setkey start
in *preinst upgrade* phase? Even then IPsec connections would fail
during a short period. Or am I wrong?
I am also not sure about the deconfigure case.
As of writing this I start thinking if it is not even better to *only*
call
/etc/init.d/setkey stop
in an *ipsec-tools.setkey.prerm* script, since the IPsec SP database is
closely associated with the setkey service and just indirectly with
racoon, which is just one ISAKMP daemon of many.
And probably somebody could install racoon and ipsec-tools and decide
later to only use ipsec-tools and deinstall racoon, which would flush
the SP database, although the person wants to continue to use
ipsec-tools.
> sorry for the trouble.
No trouble at all. Thanks for responding on bug reports!
Jan
--
Jan Sievers |
Freie Universität Berlin | [email protected]
Zentraleinrichtung für Datenverarbeitung | http://www.zedat.fu-berlin.de
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
