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

[Antony Antony]

Hi Paul,
Thanks for adding --conn option. It is a good to have option.

If expanding "also" is done well this is a good idea. My experience with 
readwriteconf is it need more work before this effort could begin.  
Currently, I wonder it work at all! See the example below.

If we do this, my preference is to convert incrementally. To avoid noise in 
the test output. If the base line outputs change, please follow it up 
immediately, rather than taking weeks to fix.

try basic-pluto-01 

/usr/local/libexec/ipsec/readwriteconf --conn  westnet-eastnet

conn westnet-eastnet
	#also = westnet-eastnet-ipv4 west-east-base-id-nss 
west-east-base-ipv4 westnet-ipv4 eastnet-ipv4 west-leftrsasigkey 
east-rightrsasigkey
	left=192.1.2.45
	leftid="@west"
	leftnexthop=192.1.2.23
	leftsubnet=192.0.1.0/24
	leftrsasigkey=0sAQOm9dY/449sAWr8e3xtV4tJOQ1396zihfGYHkttpT6zlprRmVq8EPKX3vIo+V+SCfDI1BLkYG6cYJgQAX0mt4+VYi2H3c3e9tOPNbBQ0Bj1mfgE8f9hW7x/H8AE2OSMrDStesHaPC2MMK7WPFmxOpTT1Spzkb1ZXz5yv0obncWyK03nDSQ+d/l/LdadKe9wfXptorhhDEsJSgZxhHCFmo9SoYAG/cb8Pif6Fvoyg6nKgNsPSr/36VWOvSlNI6bcKrNdYqkhHr6D2Gk8AwpIjtM6EfKGWtEwZb3I9IOH/wSHMwVP4NiM/rMZTN2FQPNNbuhJFAYsH1lZBY8gsMpGP8kgfgQwfZqAbD8KiffTr9gVBDf5
	left=192.1.2.45
	right=192.1.2.23
	rightid="@east"
	rightnexthop=192.1.2.45
	rightsubnet=192.0.2.0/24
	rightrsasigkey=0sAQO9bJbr33iJs+13DaF/e+UWwsnkfZIKkJ1VQ7RiEwOFeuAme1QfygmTz/8lyQJMeMqU5T6s0fmo5bt/zCCE4CHJ8A3FRLrzSGRhWPYPYw3SZx5Zi+zzUDlx+znaEWS2Ys1f040uwVDtnG4iDDmnzmK1r4qADy5MBVyCx40pAi67I1/b8p61feIgcBpj845drEfwXCZOsdBCYFJKsHclzuCYK0P0x1kaZAGD6k7jGiqSuFWrY91LcEcp3Om0YL9DTViPZHOVcKw1ibLCnNRiwF9WX60b5d1Jk2r1I4Lt1OfV8VXyLaImpjZTL5T7mSJcR8xtgDCIljgM9fLtN9AJ1QePae+pmc5NGneeOcQ488VRUUjv
	right=192.1.2.23
	auto=ignore
	type=tunnel
	compress=no
	pfs=yes
	ikepad=yes
	authby=never
	phase2=esp
	ikev2=permit
	esn=no

Note the wrong authby line in the expanded connection. The expanded 
connection got many options, some of which are defaults, such as ikepad=yes, 
esn=no.  Do we really need those for documentation? If these extras are in 
the expanded version, it ould defeat the goal. Users will be more confused.

Also I wonder if the readwriteconf could be smart enough to put some stuff 
to conn %default.  

If readwriteconf create a minimal "conn" and do not change output then it 
could be interesting to convert some test cases. I am not sure readwriteconf 
is smart for all tests. We could just expand a few test cases.

Currently it completely removes "conn %default", which is a bad idea!

Look at ikev2-18-x509-alias
/usr/local/libexec/ipsec/readwriteconf --conn road-east-ipv4-psk-ikev2

Shouldn't It leave %default alone?

Oh, look the expanding  of "plutodebug=all" you might be able get rid of with --setup option.

In some configuration files common options are abstracted within the config 
file. If converted using a script, I wonder how readable it would look.  See 
interop-ikev2-strongswan-33-ike-algo-responder/west.conf or 
ikev2-18-x509-alias

-antony

On Tue, Sep 26, 2017 at 08:36:03PM -0400, Paul Wouters wrote:
> 
> Hi,
> 
> 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 advantage is that each test case is its own documentation case. This
> is very useful to our users. Right now due to the also= includes, this
> is useless to endusers as documentation.
> 
> 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.
> After this rewrite, there is no easy way to edit an include file. For
> example, if we change the rsw RSA key on west, it means changing all
> the raw RSA testcases to update the *.conf files.
> 
> I've made the changes that allow me to use ipsec readwriteconf to
> convert all test cases in an automated way. If I hear now object this
> week, I'll go ahead sometime next week.
> 
> Paul
> _______________________________________________
> Swan-dev mailing list
> Swan-dev at lists.libreswan.org
> https://lists.libreswan.org/mailman/listinfo/swan-dev