1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
Overview
========
The kvm-* make targets provide an alternative build and test
framework.
Just keep in mind that some is experimental.
Installing KVM test domains
---------------------------
Preparation (FC23)
------------------
sudo dnf install virt-manager virt-install python3-pexpect
sudo usermod -a -G qemu cagney
sudo chmod g+w /var/lib/libvirt/qemu/
Makefile.inc.local configuration
................................
(from "make kvm-config-variables")
Before creating the test domains, the following make variables need to
be defined (these make variables are only used when creating the
domains):
KVM_POOL: directory containing the test domain disks
KVM_SOURCEDIR: directory to mount on /source within the domains
KVM_TESTINGDIR: directory to mount on /testing within the domains
For a traditional test domain configuration, with a single libreswan
source directory mounted under /source, add the following to
Makefile.inc.local:
KVM_POOL = /home/build/pool
KVM_SOURCEDIR = $(abs_top_srcdir)
KVM_TESTINGDIR = $(abs_top_srcdir)/testing
Alternatively, if you have multiple libreswan source directories and
would like their common parent directory to be mounted under /source
then add the following to Makefile.inc.local:
KVM_POOL = $(abspath $(abs_top_srcdir)/../pool)
KVM_SOURCEDIR = $(abspath $(abs_top_srcdir)/..)
KVM_TESTINGDIR = $(abs_top_srcdir)/testing
Installing and uninstalling test networks and test domains
..........................................................
Once the make variables are set, the test networks and test domains
can be installed with:
make install-kvm-networks
make install-kvm-domains
If not already present, a base domain, from which the test domains are
be cloned, is also be created.
Conversely the test domains and networks can be completely uninstalled
using:
make uninstall-kvm-networks
make uninstall-kvm-domains
The base domain, from which the test domains are cloned, is not
uninstalled. To also remove the base domain use:
make uninstall-kvm-domains uninstall-kvm-base-domain
This is both to prevent accidental domain updates; and avoid the
unreliable and slow process of creating the base .qcow2 file.
Logging into a test domain
--------------------------
To get a shell prompt on a domain, such as east, use either:
./testing/utils/kvmsh.py east
or:
make kvmsh-east
to exit enter the escape character '^]'.
Installing libreswan
--------------------
To install libreswan on all test domains (except nic), use:
make kvm-install
and to install libreswan on just one domain, for instance "east", use:
make kvm-install-east
To clean the kvm build directory use:
make kvm-clean
(This replaces something like "make check UPDATEONLY=1")
Creating test keys
------------------
The tests requires custom keys. They are generated using a test
domain, with:
make kvm-keys
Please note that they are not currently automatically re-generated
(this is because of concern that critical keys may be accidentally
deleted). To manually re-build the keys use:
make clean-kvm-keys kvm-keys
(This replaces directly running scripts in testing/x509 directory)
Running the tests
-----------------
There are two targets available for running the testsuite. The
difference is in how previously run tests are handled.
- run tests unconditionally:
make kvm-test
This target is best suited for the iterative build test cycle where
a limited set of tests need to be run. For instance, to update the
domain east with the latest changes and then run a subset of tests,
use:
make kvm-install-east kvm-test KVM_TESTS=testing/pluto/ikev2-algo-*
- to run tests that haven't passed (i.e, un-tested and failed tests):
make kvm-check
This target is best suited for running or updating the entire
testsuite. For instance, because some tests fail intermittently, a
second kvm-check will likely improve the test results.
(This replaces and better focuses the functionality found in "make
check" and the script testing/utils/swantest.)
(If you forget to run kvm-keys it doesn't matter, both kvm-test and
kvm-check depend on the kvm-keys target.)
Examining test results
----------------------
The script kvmresults can be used to examine the results from the
current test run:
./testing/utils/kvmresults.py testing/pluto
(even while the testsuite is still running) and compare the results
with an earlier baseline vis:
./testing/utils/kvmresults.py testing/pluto ../saved-testing-pluto-directory
mk/manpages.mk
--------------
The make variable MANPAGES contains the list of man pages to be built
and installed. For instance, assuming there is foo.3.xml source, then:
MANPAGES += foo.3
will build/install foo.3 into $(MANDIR.3) (man3). If the .xml source
is being generated (into $(builddir)/foo.3.xml) then $(builddir)
should be specified vis:
MANPAGES += $(builddir)/foo.3
If the .xml file specifies multiple <refname></refname> entries then
they will all be installed (see packaging/utils/refname.sh).
TODO: Invert this rule, instead of specifying the output, specify the source files: MANPAGES += foo.3.xml
mk/find.sh
----------
This script outputs a list of everything that might be make file
related. For instance:
./mk/find.sh | xargs grep PROGRAMS
mk/tests.sh
-----------
This script goes through a whole heap of make commands, such as
sub-directory clean/build, that should work.
|
