[Swan-dev] Converting all test cases to not use ipsec.conf.common

[D. Hugh Redelmeier]

| From: Paul Wouters <paul at nohats.ca>
| Date: Tue, 26 Sep 2017 20:36:03 -0400 (EDT)

| We have talked about this in the past, but before I go ahead, I wanted
| to ask if anyone objects to the test cases being converted to standalone
| configuration files that no longer use or need ipsec.conf.common.

| The disadvantage is that any changes that upto now could be made in an
| also= conn that is included would effect all the conns that use it.

This is a very late comment.  Sorry. [I deleted all my excuses.]

It is also theoretical.  I don't often look at the details of the test
configurations.

I think that saying something once, in one place, is a lot better than
smearing it over a lot of locations.  That means that any bug fix or
change will be consistently applied.

But good use of also= requires a discipline.  One should not just do
ad-hoc sharing.  Just because two settings happen to be the same is
not a reason to share.  One shares if they are logically the same.

Simple local example: east and west, in most cases could often share
the same conns but not the same conf file.

Sharing should likely be hierarchical.  That can make it hard to find
the definition of a conn that is being referenced.  To solve this, a
disciplined naming scheme should be used.

- perhaps all conns that are shared should have unique names

- perhaps those names should follow a convention to make clear where
  the definition is to be found.

- prehaps sharing ought to be done consistently (always or never).

- a tool (confread?) should be able to spit out where also= stuff
  comes from, even outside the context of a system running libreswan.
  For example, I develop on a machine with the source, and I do
  test builds of (make base) on it, but I don't have libreswan
  installed on it (and no virtual machines running it).

Another advantage of also= is that it can keep a lot of boilerplate
out of ones field of view.  How many lines are these expanded conns?
How many of those lines are actual distinct for each particular test?

Separate recommendation: all conf files should be named in such a way
that all of them, and only them, can be found by a find -name *.conf
(or some other regex).