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

Andrew Cagney andrew.cagney at gmail.com
Mon Jan 25 15:15:19 UTC 2016


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
the latest, I suspect, is with "systemctl restart network.service"
interacting with some tools needed for Kerberos.

So what's it doing?

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:

    $ make kvm-domain-east
    $ ./testing/utils/kvmsh --hostname swanbase --shutdown east
'/testing/guestbin/swan-transmotrify east'

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.

So what's it really doing?

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).   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/*.


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

More information about the Swan-dev mailing list