<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 2 May 2021 at 16:17, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 2 May 2021, Antony Antony wrote:<br>
>>     I think the swan-prep should to copy fresh config files every time.<br>
>> <br>
>> Moving the nsd/unbound stuff out of transmogrify makes sense.<br>
>>     the namespace directories and files, which are bind mount, should be setup<br>
>>     in swan-prep.  especially because we want to restart inside a vm(east or<br>
>>     west..) manually, inside a namespace, without resetting the all namespaces<br>
>>     of a test. So I think we should leave those tasks in swan-prep. It should<br>
>>     not be in namespace test runner.<br>
I think a per-test feature (eg running a DNS server) should be handled<br>
in the per-test setup, so swap-prep. Doing that in kvmrunner/namespacerunner<br>
does not make any sense to me. That's just too much secret sauce on the<br>
outside. I'd rather have to tests do the things themselves.<br>
I'd like the DNS daemons to be started within the test, and if possible<br>
without requiring any mounts. What is wrong with:<br>
unbound -c /testing/pluto/XXXX/unbound.conf<br>
Let the conf file or the command line options deal with a tmp dir and<br>
pid file ? We don't need to talk to another they do other than port 53 / 5353<br>
Keep it as simple as possible. Also avoid systemctl start|stop|status<br>
because it doesn't work inside namespaces. Avoid code that does<br>
different things in kvm or namespaces (like trying to check for KVM and<br>
then issuing systemctl status seems wrong to me)<br></blockquote><div><br></div><div>There's a tension here between using services the way god^^^D the guest intended (with fedora it's systemctl, NetBSD it's /etc/rc.d/*) VS inventing our own secret sauce for achieving a similar effect.<br></div><div><div><br></div><div><<ipsec start>> illustrates this.  For ipsec fans, it is one across all platforms, but for fedora fanastas systemctl also does the right thing.</div><div><br></div></div><div>... with that in mind I changed start-dns.sh to just run the custom guestbin/unbound-start.sh and guestbin/nsd-start.sh.  I figure those scripts know what to do.</div><div><br></div><div>otoh, how much does this matter?<br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> (I'm sure there is other stuff)<br>
>> while this is currently implemented by walking the VM through a boot-and-login<br>
>> sequence, there's nothing to rule out using snapshots, say.  Just as long as<br>
>> the environment is established before the test starts.<br>
If it is one snapshot per domain, eg you compile libreswan, install it,<br>
then snapshot the thing to boot more quickly, it shouldn't be running<br>
any DNS at the start, because most tests don't need it. So it would have<br>
to be swan-prep that starts it anyway.<br>
>> If I were to type "reboot" in such a vm, then I'll need to first manually<br>
>> re-establish the above before entering the first shell command.  Why should<br>
>> namespaces be different?<br>
Well, namespaces are ephemeral. You don't "reboot" them. You re-create<br>
them. But I'm still not sure this matters for the issue we are talking<br>
>>  If namespaces and KVM established some minimum<br>
>> environment before running tests then I think the odds of tests runing under<br>
>> both frameworks would be greatly improved.<br>
Don't we have that minimum? What are you trying to make the new minimum?<br></blockquote><div><br></div>No.  We don't have a minimum.</div><br><div class="gmail_quote">For namespaces, test scripts have to go through all sorts of custom sized hoops before services can start.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Consider /run:</div><div class="gmail_quote"><br></div>Each service and pluto are making their own set of custom mounts so that things like /run/<service>.pid work (technical nit, /run needs something as otherwise parallel plutos will get confused).<div class="gmail_quote">I don't understand why.</div><div class="gmail_quote">Is there a way for the namespace script to prep that directory before the test is started so that:<br></div><div class="gmail_quote">  - /run is writeable and per test instance<br></div><div class="gmail_quote">swan-prep would no longer have to deal with this.<br></div><div><br></div><div>However, if this isn't possible can we adopt techniques that work more consistently between namespaces and KVMs?</div><div><br></div><div>For instance, your suggestion to use:</div><div>  unbound -c /testing/pluto/XXXX/unbound.conf</div><div>could be one.  Another is to just, blindly use tmpfs regardless of the guest, start-dns.sh is doing that.<br></div><div><br></div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
>> BTW, I'd take the above list as a starting point for discussion.  Currently<br>
>> swan-prep has to deal with cleaning up from previous tests, I think that's a<br>
>> bug.<br>
> I have been trying to reply to this e-mail for two weeks. This is the best <br>
> I could come with on your discovery of the clean-up feature as a bug. In my <br>
> opinion, it is a wrong conclusion!<br>
> I have been scratching my head to understand how you would reach the <br>
> conclusion it is a bug. As far as I can remember it has been there from the <br>
> beginning of KVM testing scripts, such as swan-prep.<br>
> To be clear do not remove the hooks put in there to support rerunning<br>
> a test manually by script by script without using runner: such as swan-prep <br>
> cleaning up previous instances,<br>
I am not sure I see what you two are really disagreeing about.<br>
Andrew is saying, "it would be nice if the filesystem was clean and<br>
swan-prep didn't need to go check for that".<br>
Antony is saying, "I want to be able to run swan-prep, do test stuff,<br>
then re-run swan-prep for a new test without reboot".<br>
Running swan-prep twice should not make any changes to the filesystem on<br>
the 2nd iteration. It would just be repeating what it is doing. So I<br>
don't think Andrew would break that. Unless Antony wants to run 1 test,<br>
and then later another test. And the first test "left" a config file<br>
somewhere. In this case, running swan-prep a second time would wipe<br>
anything the first test did. I think not breaking this has value. I<br>
also sometimes run multiple tests manually one after the other from<br>
consoles without reboot. But it is rare. These days I try to use<br>
namespace-runner.py to run multiple tests.<br>
I am myself more concerned with things happening in post-mortem, and<br>
how running a single test that does not run post-mortem would end up<br>
with a different output then that test running in a bundle of tests<br>
that get a post-mortem. Like moving the selinux audit checks into<br>
postmortem would mean running a single test means I cannot see if<br>
I trigger audit issues. I really do want to be able to keep running<br>
a test as a single test or as part of a bundle, without it failing with<br>
a false positive or silently not doing some checks for me anymore.<br>
But I don't know how to do that.<br></div></blockquote><div><br></div><div>While I have this lurking in Makefile.inc.local:</div><div><br></div><div>  KVMRUNNER_FLAGS += --run-post-mortem</div><div><br></div><div>it also isn't ideal.  Some days I want the VMs to shut down and post mortem to run, some days I don't.</div><div><br></div><div>If a test is deliberately targeting audit, why not run the audit command as part of the test's scripts?   The only risk I see is the test being copied, resulting in completely unrelated tests explicitly checking for audit records when they don't need to.</div><div><br></div><div>For audit though, the open question is still what to do about tests that deliberately trigger audit records. They would need to be flushed since post-mortem.sh doesn't expect this.<br></div><div><br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
> also in some init scripts, westinit/roadinit.sh, may remove the <br>
> addressees/routes added during a run that is to clean up the previous run. <br>
> e.g MOBIKE dns. I don"t agree with removing those even if it may speedup a<br>
> test run. It is an essential feature! And rebooting KVM is not an <br>
> alternative!<br>
In this specific case, I actually am on the fence. I really don't like<br>
that I run some tests involving road, and when the test is done I cannot<br>
"ssh road" because the test removed the real IP of road and didn't put<br>
it back in the end. but I understand why this is, because otherwise you<br>
cannot run it manually and then look at the state using a shell. But in<br>
general, test cases should "reset" things like DNS configs after their<br>
run, provided that they specifically test for the expected changes<br>
during the run.<br></div></blockquote><div><br></div><div>This is why I use:<br></div><div>  .gmake kvmsh-road</div><div>always works (or ./kvm sh road)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
> If you feel avoiding clean-up would considerably speed up our testrun feel <br>
> free to add some options which by default disabled and could be optionally <br>
> enabled on testrun say on <a href="http://testing.libreswan.org" rel="noreferrer" target="_blank">testing.libreswan.org</a>.<br>
Yes, it seems most of these issues of expecting different things depend<br>
on whether the test is run manually or grouped. I would not be against<br>
an ENV variable being set by the kvmrunner/namespace runner that<br>
swan-prep uses to skip cleanup, that would not be set if running a<br>
single test. I would hope that such an approach would address everyone's<br>
concern ?<br>