[Swan-dev] test caes as documentation versus ipsec.conf.common ease of use

[Antony Antony]

Hi
I am catching up on this thread. I don't like cloning either. Cloned connections create overhead to maintain. And they drift apart. Some of the cloned tests use a different convention for left and right. This drives me mad:) 

I recently normalized psk secrets. So please keep the number of unique PSK lines minimum. If they are all the same we can easily mix different PSK tests.

The idea is , for example, east.conf and west.conf include modular connections. 
The script, swanprep, call readwriteconf to expand the 'also=' lines and create a simple ipsec.conf file without any "also=" lines.  

Swanprep copy this file to the VM as /etc/ipsec.conf
"make check" or "swantest" will archive the expanded ipsec.conf to the OUTPUT/ directory as the config file used for the testrun. 

Later when you browse a testrun you see the expanded one without any "also=" lines.

The proposal is to add an extra switch to readwriteconf. With this switch it will expand only the necessary connection lines. 

The main advantages I see are:
1. when we depreciate keywords readwriteconf will use the latest one.
2. If we expand all included connection to a concise conn statement it is easy to read and follow. And it becomes documentation for people who are looking for how do I configure X, Y, Z

Does this make sense?

Yes, Not all testcases are good examples but it is real One could learn from it, if the test case passes it will be up to date. At least that is the idea:)

Right now when I try to read /testing/baseconfigs/all/etc/ipsec.d/ipsec.conf.common I get confused:)

-antony

On Thu, Feb 05, 2015 at 03:47:53AM -0500, D. Hugh Redelmeier wrote:
> | From: Paul Wouters <paul at nohats.ca>
> | 
> | Antony brought up a while ago that due to our use of ipsec.conf.common,
> | the test cases do not work very well as documentation. It would be much
> | better to write out the full configurations so people can read them and
> | understand them better.
> 
> I don't think that the primary purpose of our myriad test cases is
> as examples for users.  In fact, many tests ought to be very bad
> examples.
> 
> Perhaps a subset of instructive examples could become a few of our
> test cases.  In fact that's a good idea: it means that the examples are 
> regularly tested.
> 
> I don't like cloned text.  It means that any change must be repeated
> many times.  And of course that just doesn't happen reliably.  So we
> get divergence.
> 
> Modularity needs to be designed and then evolve.  Perhaps the existing
> modularity is not as good as it should be.  I'm not saying that there
> isn't room for improvement.  But cloning sounds like the wrong way.
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev
>