[Design] _updown custom arguments

Hi --

0) Pre-background: I think it is a good design to have an _updown script. It makes freeswan more extensible. Thanks!

1. Background and rationale for today's discussion: Writing an updown script from scratch would be a pile of work. There is a class of people who would like to have a slightly customized updown script, but don't want to start from scratch. We should encourage people to
   • start with the as-distributed script
   • make a copy
   • change the copy as necessary... but no more than necessary!

Alas, some of the defensive arg-checking in the as-distributed version makes things more complicated than they need to be.

2) Suggestion: It should be a _documented_ feature that calling _updown (or copy_of_updown, before modifications) with the arguments "custom blah blah foo bar" is exactly equivalent to calling it with no arguments at all, no matter what arguments follow the word "custom".

(The point being that the user can then edit the thing in some minimal way to add handling for the custom features.)

I believe the foregoing suggestion can be accomplished by simple changes to two lines in the code. To avoid export issues I won't send you the code, but ask yourself what happens when the pluto verb is up-client or down-client and $1 is "custom" as opposed to "". Adding a disjunction to the two

        case-selector)
statements helps a lot in my experience.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.freeswan.org Links 1998-fall 1998-spring 1998-summer 1998-winter 1999-winter announce briefs bugs design freeswan-list hipsec ietf-sectest users users-admin Request more information about Pantek

3) After changing the code, don't forget to change the fine documentation (man ipsec_pluto).

The documentation (and the code) would have been simpler if we could say that the standard features are implemented by passing stuff in the enviroment, while the users can do what they want with positional parameters. Things used to be nice and orthogonal like that, but the introduction of the ipfwadm argument de-orthogonalized things.

	Digression: I suspect the code would have been
	simpler if ipfwadm had been implemented as new
	pluto_verbs (up-client-fw and down-client-fw).

But in any case, the current suggestion is intended to orthogonality to whatever arguments come after the magic word "custom".

===
For a not-quite unrelated suggestion, see next msg.