[Openswan Users] "/usr/local/sbin/ipsec setup --start" doesn't return the prompt on Ubuntu 9.10 when complied from source.

[phearnomore]

2009/12/9 Paul Wouters <paul at xelerance.com>:
> On Wed, 9 Dec 2009, phearnomore wrote:
>
>> I have two versions of Openswan installed on my fresh Ubuntu 9.10 system:
>>
>> assiduus at ubuntu:~$ /usr/local/sbin/ipsec --version
>> Linux Openswan U2.6.23/K2.6.31-14-generic-pae (netkey)
>> See `ipsec --copyright' for copyright information.
>
>> Now the problem: when I run the first version of the program I don't
>> get the prompt back while ^C doesn't seem to cancel Openswan's
>> operation:
>
> This is a known bug with /bin/dash. It has been reported to the dash
> maintainer (Herbert Xu), but I have not seen a bugfix for this yet.
>
> A workaround has been commit, see a4f8195028a3d293ce1b9fcdb2dda3f7495337cc
> shown below. Another workaround (a better one in my opinion) is to link
> /bin/sh back to /bin/bash on your ubuntu/debian system.

A strange thing happened today: I wanted to, let's say, sum things up
and did a fresh install of Ubuntu Server. Apart from 'sudo apt-get
update/upgrade', I got what was missing for openswan with:

assiduus at ubuntu:~$ sudo apt-get --no-install-recommends install
build-essential libgmp3-dev gawk flex bison man2html xmlto

Then I did the linking part:

assiduus at ubuntu:~$ ls -ld /bin/sh
lrwxrwxrwx 1 root root 9 2009-12-10 12:53 /bin/sh -> /bin/bash

and started Openswan (once again no modifications to the configuration
files - just 'make programs' and 'sudo make install':

assiduus at ubuntu:~$ sudo /usr/local/sbin/ipsec setup --start
ipsec_setup: Starting Openswan IPsec U2.6.23/K2.6.31-14-generic-pae...
^Cassiduus at ubuntu:~$

Once again it froze. Differently then with /bin/dash, at least "graphically":

assiduus at ubuntu:~$ sudo /usr/local/sbin/ipsec setup --start
ipsec_setup: Starting Openswan IPsec U2.6.23/K2.6.31-14-generic-pae...
^C
assiduus at ubuntu:~$

but in comparison to the dash freezing this is what it got from ps aux
- and it grows every time I run Openswan with bash:

root      9453  0.0  0.0   2720   640 pts/0    S    12:54   0:00
/bin/sh /usr/local/lib/ipsec/_plutorun --debug  --uniqueids yes --f
root      9457  0.0  0.0   2692  1140 pts/0    S    12:54   0:00
/bin/sh /usr/local/libexec/ipsec/newhostkey --quiet
root      9461  0.0  0.0   2692   668 pts/0    S    12:54   0:00
/bin/sh /usr/local/libexec/ipsec/newhostkey --quiet
root      9464  0.0  0.0   1948   408 pts/0    S    12:54   0:00
/usr/local/libexec/ipsec/rsasigkey 2192
root      9468  0.0  0.0   2692   612 pts/0    S    12:54   0:00
/bin/sh /usr/local/libexec/ipsec/newhostkey --quiet

With dash it also froze but all processes were gone after --stop.

I don't know what to say because it was working at some point but back
then I had the latest kernel installed, I also experimented a bit with
the package version of Openswan having it installed and removed and
then installed again and so on (all for the testing purposes). But
here we've got a completely fresh installation of Ubuntu 9.10 (only
OpenSSH added during the installation process), updated, upgraded,
openswan with the necessary packages installed and /bin/sh linked to
/bin/bash. I dunno...

> diff --git a/programs/_plutorun/_plutorun.in
> b/programs/_plutorun/_plutorun.in
> index d2bef7f..ec27b09 100755
> --- a/programs/_plutorun/_plutorun.in
> +++ b/programs/_plutorun/_plutorun.in
> @@ -222,6 +222,19 @@ then
>        exit 0
>  fi
>
> +# Work around problem with broken shells (e.g. Busybox sh).
> +# We are called with stdout & stderr going to a logger process started
> +# by "ipsec setup". For some reason, when the below loop runs with
> +# stdout & stderr redirected to a new logger, the pipe to the old logger
> +# is leaked through to _plutorun as file descriptor 11, and the old
> +# logger (and "ipsec setup") can never exit. By closing fds 1 & 2
> +# before they can be dup'd to 11, we somehow avoid the problem.
> +# This problem may also apply to Ubuntu's dash shell
> +# (http://archives.free.net.ph/message/20090803.221025.1b0ebafd.en.html)
> +# but the workaround has not been tested there.
> +exec 1>/dev/null
> +exec 2>/dev/null
> +
>  until (
>        if test -s $info
>        then

Cheers,

-- 
phearnomore