[Swan-dev] what is swan-transmogrify doing?

[Paul Wouters]

On Mon, 25 Jan 2016, Andrew Cagney wrote:

>
> I've now twice tracked a test VM's slow boot (<30s -> >1minute) down
> to the Python (I'll get to that in a moment) script
> "swan-transmogrify" that is run, every time the machine is booted,
> from "/etc/rc.d/rc.local".  The first slow down I encountered was
> tracked down to "chcon -R --reference /var/log /testing/pluto"; and

that's to prevent selinux warnings inside the guest. It could possibly
be commented out. Maybe Tuomo can fix it better.

> the latest, I suspect, is with "systemctl restart network.service"
> interacting with some tools needed for Kerberos.

The network restart is because it reconfigured the "base" VM into
one of the known guests "west, east, etc".

> Well, according to
> https://libreswan.org/wiki/Test_Suite#swan-transmogrify "This python
> script compares the nic of eth0 with the list of known MAC addresses
> from the XML files. By identifying the MAC, it knows which identity
> (west, east, etc) it should take on. Files are copied from
> /testing/baseconfigs/ into the VM's /etc directory and the network
> service is restarted. "
>
> That sounds like a simple "first-boot" like operation; not something
> that needs to be done every time, and not something requiring MAC
> magic.  In fact, we could even run something like:

Yes. But the original idea was that we would be using a single image
(eg uml disk) and use a copy-on-write to transmogrify it into west,east,
etc and then throw away the COW at the end of the test. This to ensure
no state is left behind for the next test.

But you are right, with KVM we deviated a little bit from this. But
I think for the docker tests Antony did, it might still be needed
because those images are created from scratch for each test.

> i.e., initiate the transmogrification (google thinks that is a word!)
> once, from outside the VM, and with an explicit host name. No need for
> any MAC magic, and no need for repeated fiddling with config files or
> restarting networks during every boot.

We do need to ensure some files are always correct for that test, such
as resolv.conf that might be different for different tests. But in
general, yes we could probably get away with that for the KVM tests.
We also always create the NSS database from a known saved copy that
only contains the raw RSA key. Some tests need a cert added, some
tests need to get that cert via IKE. So it is important to always
cleanup the NSS and start from the minimal one.

> Who knows. It contains docker magic. It silently runs random
> processes.  And it's written in Python and not SH (boot scripts IMNSHO
> should be simple SH).

Shell sucks for variables and sub shells and automating interactive
things :P

>  However, what I suspect is that it has, over
> time, it has out-of-site-out-of-mind accumulated stuff that really
> really needs to be transparent and initiated from the "*init.sh"
> scripts.  For instance, both swan-transmogrify and swan-prep screw
> around with the contents of /etc/ipsec.d/*.

> thoughts,
> Andrew
>
> PS: Why are the VMs running NFS; and why do the VMs suck down useless
> megabytes of debuginfo RPMs :-)

We weren't sure if we were moving the 9P filesystem to NFS or not. 9P
is nice because it works even if OE screwed up the network. But 9P is
not writable in RHEL (by design) and it seems slower than NFS by a lot.
But NFS can go down when the networking gets screwed up by IPsec. So
for instance we could lose logging.

debuginfo is needed to get proper gdb backtraces :P But you know that :P

Paul