[Openswan dev] RFC: Changes to whack's --status output

[Paul Wouters]

On Thu, 25 Nov 2004, D. Hugh Redelmeier wrote:

> Proposal: test out the proposals with --status post-processing.  They 
> can be added to the ipsec command easily.

I agree with Hugh here. I would prefer us to not break the current output,
but add the new proposed output in a new option to whack --status first.

While we are thinking of changing this, I'd like to rethink the various
ways we are now presenting information:

- ipsec whack --status 
- ipsec barf 
- ipsec eroute 
- setkey [-P] -D
- tail -f /var/log/*

First, I'd like to keep the eroutes, and ensure they also display
consistently with both KLIPS and the native 2.6 stack. Currently even
Ken's perl script to replace eroute doesnt do this (setkey gives seperate
lines for the two policies, while eroute consolidates it into one line)

Second, the barf is meant as a 'dump everything under the sun for
debugging'.  It should probably remove the 'display the command used to
give output' feature, as this is a remnant of old politics. It should
get some cruft removed and switch to the ip command (that has already
started happening in cvs HEAD) since the 'route' command does not show
all information, such as source based routing entries. I would also be
tempted to remove the inclusion of all the scripts verbatim or move that
into a seperate option to barf as almost all barfs we have to look at
are using our versions of the scripts.  Also, I'd like an alias for barf to
'debug' or something slightly less childish then barf :)

Third, I think ipsec whack --status in its current form is next to
useless to most users. Even I find it very difficult to read. In its
current shape, it falls between eroute and barf, but doesnt do a good
job.  If we want the status function to return user readable output,
as a more elaborate case of getting the state as compared to eroute, so
for the enduser, then I think Ken's third approach is best, even though
that doesn't scale very well on machines with lots of tunnels. But those
people should know better what they are doing, and should be able to
specify the status of a single connection name or instance, as Hugh
suggested. (--status connname)

I think it is still useful to keep a more machine readable status option
that can be used by developers with grep, or which can be used as basis
for other GUI/web interfaces to display the status.

Other options could include presenting the status information in a very
structured way such as XML, RSS or SNMP. Though that is probably best
left to third party tools.

Finall, to get back to eroute. I really like eroute. It is very simple,
one line per connection. I wish we could keep a eroute like output
without having /proc filesystem issues with it.

The only thing missing perhaps is the connection name and auth type,
and perhaps ia better way of knowing the current state when it is being
setup (but then, from a pure eroute perspective there is either a trap
or no entry at all)

What I am further missing is a command to show me the last few lines
of pluto output (say the last 20-40). Or to have an 'ipsec log' option
you can run that 'tail -f's all ipsec subsystem output. This will
avoid me having to figure out where syslog is leaving the information
(secure? daemon.log?  auth.log? messages?). tail -f /var/log/* used
to work fine, but these days some versions of tail dont silently skip
directories but stop, and some foolish people put named pipes or sockets
in that directory. Such an option also would make receiving logfiles
easier. And most of the time when receiving or reading a barf, those
loglines tell me the exact problem. So being able to run 'ipsec log >
forpaul.txt' while in another window starting ipsec (or just the conn)
would be very useful. It is a bit similar to seeing some messages happening
when you manually 'ipsec auto --up connname'.

One last comment regarding Ken's 3rd output. I am not sure what to do with
all the names of the various options, since each vendor calls them differently.
I agree with hugh then we shouldn't call something 'Local ID' when in the
config file we call that 'left'. If we think that 'localid' is a better name,
perhaps we should think about renaming the whole left/right scheme into 
something else, though I realise that is a very touch subject, and there are
many (good) reasons why it was decided to use left/right.

One work around for this could be to allow the --status flag to have a 
--vendor flag, where we will 'translate' our configuration terms in those of
the remote vendor. This would only make sense with specific connection names
passed to status, eg: ipsec whack --status paul-customer --vendor cisco

Another option would be to help generate configuration files for the remote
end: ipsec config our-conn --vendor draytek
which would then spit out all the options you should set on the draytek
machine (--vendor draytek --model vigor ?). Ideally, this should be read
from a syntax that can be given (and maintained?) by the respective vendors.
It could even list known issues with vendors such as

warning: you need to use firmware >= x.y.z with Vendor Foo, model Bar, due
to broken md5 implemention. Use 'ike=3des-sha1-modp2048' as a work around.


Hope some of this makes sense :)

Paul