[Swan-dev] testing and unstable dns

Andrew Cagney andrew.cagney at gmail.com
Sun Apr 18 18:08:14 UTC 2021


I might have figured this out.  The code starting just nsd, wasn't stomping
on /etc/nsd/server.d/nsd-server-libreswan.conf's port.  start-dns.sh
inherited this.  If that pans out I'll see about always starting unbound,
per:
https://lists.libreswan.org/pipermail/swan-dev/2020-February/003660.html
and if that pans out, the sed hacking can go.

On Sat, 17 Apr 2021 at 20:33, Andrew Cagney <andrew.cagney at gmail.com> wrote:

> BTW, I took a look at swan-prep --dnssec.  As best I can the big
> difference between namespaces and KVM is when the config files are
> installed:
>
> - with KVMs the nsd and unbound directories are set up before the test is
> run (during transmogrify)
> - with namespaces, the nsd and unbound directories are set up as part of
> some interesting mounts by swan-prep
>
> would things be more straight forward if, for namespaces, the directories
> were set up behind the scenes before the test starts (I'm mainly thinking
> of those mounts trying to hide stuff and/or provide a scratch space for
> test specific files)?  That way namespaces and KVM would better resemble
> each other without the need to involve swan-prep.
>
>
>
> On Sat, 17 Apr 2021 at 19:55, Andrew Cagney <andrew.cagney at gmail.com>
> wrote:
>
>>
>>
>> On Sat, 17 Apr 2021 at 15:17, Antony Antony <antony at phenome.org> wrote:
>>
>>> On Sat, Apr 17, 2021 at 11:03:15AM -0400, Andrew Cagney wrote:
>>> > Problem is still there :-(  Anyone had some inspiration?  For instance
>>> with
>>> > nsd-4.3.2-1.fc32.x86_64
>>> >
>>> https://testing.libreswan.org/v4.3-474-g9267a3fd5d-main/ikev2-55-ipseckey-06/
>>> > OUTPUT/nic.console.diff
>>> >
>>> > On Mon, 29 Mar 2021 at 10:09, Andrew Cagney <andrew.cagney at gmail.com>
>>> wrote:
>>> >
>>> >     Picking up an IRC discussion, I'm wondering if anyone has ideas on
>>> why DNS
>>> >     isn't robust within the KVM test environment.
>>>
>>> I just pushed a minor fix. Let me see how ikev2-55-ipseckey-06 runs on
>>> testing.
>>>
>>> my last attempt to fix to dnssec tests:
>>> https://lists.libreswan.org/pipermail/swan-dev/2020-February/003660.html
>>>
>>> then I fixed only ikev2-55-ipseckey-01 and added namespace support.
>>> A quick look on testing shows ikev2-55-ipseckey-01 nic is not the issue
>>> anymore.
>>>
>>> ls -lt v4.3*/ikev2-55-ipseckey-01/OUTPUT/nic.console.diff
>>> all diff files are 0 bytes. which suggest my fix should work.
>>>
>>> next dnssec issue is  dns key sort order.
>>>
>>> https://testing.libreswan.org/v4.3-474-g9267a3fd5d-main/ikev2-55-ipseckey-01/OUTPUT/east.console.diff
>>>
>>> DNS tests should work in namespace too, atleast the NIC part.
>>> pubkey sorting order is a different problem.
>>>
>>> since afce9e92f nsd and unbound start is handled in swan-prep. It knows
>>> how
>>> to handle namespace vs systemctl.
>>>
>>> I recollect thinking, that we should add 10 sec while loop on nic like
>>> we do
>>> for strongswan.
>>>
>>> BTW:
>>> 6e9893ef090 comment and ./testing/guestbin/start-dns.sh are in the wrong
>>> direction, however, lets see if ikev2-55-ipseckey-06 nic is stable after
>>> my
>>> fix.
>>>
>>
>> How so?  It replaced all of:
>>
>> -#once unbound work properly replace the next lines
>> +setenforce Permissive
>>  nic #
>> - sed -i 's/5353/53/' /etc/nsd/nsd.conf
>> -nic #
>> - #/testing/guestbin/swan-prep --dnssec
>> -nic #
>> - setenforce Permissive
>> -nic #
>> - systemctl start nsd-keygen
>> -nic #
>> - systemctl start nsd
>> -nic #
>> - dig +short  @127.0.0.1  road.testing.libreswan.org  IPSECKEY
>> -10 0 2 . AQPHFfpyJ3Ck4fMKcCH5DD/iZRKH2f0Sy6/U4M<HUGE_RAW_KEY>
>>
>> with a small script and brief log lines:
>>
>> + ../../pluto/bin/start-dns.sh
>> +starting dns
>> +digging for road.testing.libreswan.org IPSECKEY
>> +Everything went well, including things like NXDOMAIN.
>> +Found 2 records
>>
>> Note, in particular, it removed the raw keys from dig..  The assumption
>> is that this standalone script can be tweaked to handle namespaces (and
>> further bloat to swan-prep can be avoided).
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan-dev/attachments/20210418/73b8d333/attachment.html>


More information about the Swan-dev mailing list