Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 134086 - Problems running ipsec
Problems running ipsec
Product: Fedora
Classification: Fedora
Component: openswan (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
Blocks: FC3Target
  Show dependency treegraph
Reported: 2004-09-29 11:27 EDT by Matthias Saou
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-14 07:11:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matthias Saou 2004-09-29 11:27:23 EDT
Description of problem:
I'm trying to set up IPSec on Fedora Core 3 test2 and am having many
annoying issues :
- On one machine, I have the exact same
/etc/ipsec.d/examples/no_oe.conf file as on the others, but when I try
to run "service ipsec start", I get "/etc/init.d/ipsec:
(/etc/ipsec.d/examples/no_oe.conf, line 12) section header "
auto=ignore" has wrong number of fields (1) -- `start aborted", which
I really don't understand as all lines have "auto=ignore", that one
not having anything in particular.
- When running "service ipsec start", something gets either stuck or
not properly daemonized since a while loop with initlog calls is still
running after the service command has finished its execution :

/bin/sh -c while read line; do /sbin/initlog -s $line -f
${LOG_FACILITY:-daemon} -p ${LOG_PRIORITY:-error} -t ipsec__plutorun; done

- Last, the docs are really poor, messy and outdated (that's actually
more on the openswan side, I'll open another bug later on for that).

Version-Release number of selected component (if applicable):

How reproducible:
The running while loop with initlog is 100% reproducible on all 4
machines I've tested it on. The "wrong number of fields" problem is
100% reproducible on the only machine it's happening on, even after
"rpm -e ipsec-tools openswan && rm -rf /etc/ipsec.*" and reinstalling
both packages.

Steps to Reproduce:
1. Install ipsec-tools & openswan
2. service ipsec start
3. ps ax | grep initlog
Actual results:
/bin/sh -c while read line; do /sbin/initlog -s $line -f
${LOG_FACILITY:-daemon} -p ${LOG_PRIORITY:-error} -t ipsec__plutorun; done

Expected results:

Additional info:
I've already had a similar "wrong number of fields" error when I had a
config file with an error or bad indentation, but here I'm using the
default config files and didn't edit anything. The system was
installed with a minimal set of packages and ipsec-tools and openswan
were later added with yum, so maybe it's a missing runtime dependency
not pulled in by the packages? Just a thought.
Comment 1 Matthias Saou 2004-09-29 13:27:57 EDT
Sorry, this bug should ovbiouslt have been against openswan and not
ipsec-tools, changing that.
Comment 2 Paul Wouters 2004-10-03 15:31:46 EDT
Unfortunately, ipsec.conf's parser is due for an update (see
programs/starter). It is very sensitive to spaces and tabs (which are
not both 'white space').
You should have conn name, and on the next line have <tab>option, and
the end of the conn must have an empty line.
We've added a trailing space to the conn lines which seems to fix the
missing tab problem in CVS head.

We will look into the logging loop, but the fedora package changed a
lot of the logging functions, so I am not sure yet what code is at
fault here.
Comment 3 Matthias Saou 2004-10-04 07:56:23 EDT
Well, with the exact default examples/no_oe.conf, I was getting that
problem. Adding a white space at the end of every conn line seems to
have worked around it, weird. Thanks for the tip.
Comment 4 Ken Bantoft 2004-10-05 10:08:49 EDT
Fixed in Openswan 2.2.1 (released shortly) - changed the no_oe.conf.in
file in the distribution.

Note You need to log in before you can comment on or make changes to this bug.