Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
Add a job creating a release tarball to GitLab CI
Add a GitLab CI job (which is run only if all other jobs in a pipeline
succeed) that builds a BIND release tarball, i.e. fetches the source
tarball from the tarball building job, creates Windows zips, puts
certain parts of BIND documentation into the appropriate places, and
packs it all up into a single tarball whose contents can be subsequently
signed and published.
Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
Add a Windows debug system test job to GitLab CI
Add a system test job for binaries created by Visual Studio in the
"Debug" build configuration to GitLab CI so that they can be tested
along their "Release" counterparts when necessary.
Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
Add a Windows debug build job to GitLab CI
Add a Visual Studio build job using the "Debug" build configuration to
GitLab CI without enabling it for every pipeline as it takes about twice
as long to complete as its "Release" counterpart.
Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
Create and test BIND source tarballs in GitLab CI
Add a set of jobs to GitLab CI that create a BIND source tarball and
then build and test its contents. Run those extra jobs only when a tag
is pushed to the Git repository as they are only meant to be sanity
checks of BIND source tarball contents.
Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
Include prepare-softhsm2.sh in source tarballs
The util/prepare-softhsm2.sh script is useful for initializing a working
SoftHSM environment which can be used by unit tests and system tests.
However, since it is a test-specific script, it does not really belong
in the util/ subdirectory which is mostly pruned during the BIND source
tarball creation process. Move the prepare-softhsm2.sh script to
bin/tests/ so that its location is more appropriate for its purpose and
also so that it does not get removed during the BIND source tarball
creation process, allowing it to be used for setting up test
environments for tarball-based builds.
Michał Kępień [Wed, 11 Dec 2019 11:04:29 +0000 (12:04 +0100)]
List paths which should be excluded from tarballs
Convert the logic (currently present in the form of "rm -rf" calls in
util/kit.sh) for removing files and directories which are tracked by Git
but redundant in release tarballs into a set of .gitattributes rules
which allow the same effect to be achieved using "git archive".
Michał Kępień [Tue, 10 Dec 2019 09:31:33 +0000 (10:31 +0100)]
Only use LC_ALL=C where intended
The LC_ALL=C assignments in the "idna" system test, which were only
meant to affect a certain subset of checks, in fact persist throughout
all the subsequent checks in that system test. That affects the test's
behavior and is misleading.
When the "VARIABLE=value command ..." syntax is used in a shell script,
in order for the variable assignment to only apply to "command", the
latter must be an external binary; otherwise, the VARIABLE=value
assignment persists for all subsequent commands in a script:
$ /bin/sh foo.sh
bar: BAR=baz1
foo: BAR=baz0
bar: BAR=baz2
foo: BAR=baz2
$
Fix by saving the value of LC_ALL before the relevant set of checks in
the "idna" system test, restoring it afterwards, and dropping the
"LC_ALL=C command ..." syntax.
Witold Kręcicki [Sun, 8 Dec 2019 21:44:08 +0000 (22:44 +0100)]
Fix a race in socket destruction - we need to remove handle from socket in async close callback or we might race between destruction in the callback and in the original nmhandle_unref
Witold Kręcicki [Tue, 3 Dec 2019 18:48:10 +0000 (19:48 +0100)]
netmgr:
- make tcp listening IPC pipe name saner
- put the pipe in /tmp on unices
- add pid to the pipe name to avoid conflicts between processes
- fsync directory in which the pipe resides to make sure that the
child threads will see it and be able to open it
Witold Kręcicki [Mon, 2 Dec 2019 12:54:44 +0000 (13:54 +0100)]
- Add separate priority event queue for events that must be processed
even when worker is paused (e.g. interface reconfiguration). This is
needed to prevent deadlocks when reconfiguring interfaces - as network
manager is paused then, but we still need to stop/start listening.
- Proper handling of TCP listen errors in netmgr - bind to the socket first,
then return the error code.
Witold Kręcicki [Mon, 2 Dec 2019 10:19:55 +0000 (11:19 +0100)]
Add uv_handle_{get,set}_data functions that's absent in pre-1.19 libuv to make code clearer.
This might be removed when we stop supporting older libuv versions.
Witold Kręcicki [Thu, 28 Nov 2019 09:21:34 +0000 (10:21 +0100)]
netmgr: make tcp listening multithreaded.
When listening for TCP connections we create a socket, bind it
and then pass it over IPC to all threads - which then listen on
in and accept connections. This sounds broken, but it's the
official way of dealing with multithreaded TCP listeners in libuv,
and works on all platforms supported by libuv.
Mark Andrews [Wed, 4 Dec 2019 10:41:04 +0000 (21:41 +1100)]
Testing node->down requires the tree lock to be held.
In decrement_reference only test node->down if the tree lock
is held. As node->down is not always tested in
decrement_reference we need to test that it is non NULL in
cleanup_dead_nodes prior to removing the node from the rbt
tree. Additionally it is not always possible to aquire the
node lock and reactivate a node when adding parent nodes.
Reactivate such nodes in cleanup_dead_nodes if required.
Ondřej Surý [Thu, 5 Dec 2019 17:09:21 +0000 (18:09 +0100)]
Bail-out early if dig fails to finish successfully or takes too long
Before, the zero system test could get stuck almost infinitely, because
the first test sends > 300 queries with 5 seconds timeout on each in
each pass. If named crashed early, it would took the test more than 4
hours to properly timeout.
This commit introduces a "watchdog" on the dig commands running in the
background and failing the test on timeout, failing any test if any dig
command fails to return successfully, and making the tests.sh script
shellcheck clean.
The kasp system test has a call to sed to retrieve the key identifier
without leading zeros. The sed call could not handle key id 0.
Update the kasp test to also correctly deal with this case.
The autosign test has a test case where a DNSSEC maintaiend zone
has a set of DNSSEC keys without any timing metadata set. It
tests if named picks up the key for publication and signing if a
delayed dnssec-settime/loadkeys event has occured.
The test failed intermittently despite the fact it sleeps for 5
seconds but the triggered key reconfigure action should happen after
3 seconds.
However, the test output showed that the test query came in before
the key reconfigure action was complete (see excerpts below).
The loadkeys command is received:
15:38:36 received control channel command 'loadkeys delay.example.'
The reconfiguring zone keys action is triggered after 3 seconds:
15:38:39 zone delay.example/IN: reconfiguring zone keys
15:38:39 DNSKEY delay.example/NSEC3RSASHA1/7484 (ZSK) is now published
15:38:39 DNSKEY delay.example/NSEC3RSASHA1/7455 (KSK) is now published
15:38:39 writing to journal
And 6 more seconds later the reconfigure keys action is complete:
15:38:47 zone delay.example/IN: next key event: 05-Dec-2019 15:48:39
This commit fixes the test by checking the "next key event" log has
been seen before executing the test query, making sure that the
reconfigure keys action has been complete.
This commit however does not fix, nor explain why it took such a long
time (8 seconds) to reconfigure the keys.
Michał Kępień [Fri, 6 Dec 2019 13:11:01 +0000 (14:11 +0100)]
Automatically run clean.sh from run.sh
The first step in all existing setup.sh scripts is to call clean.sh. To
reduce code duplication and ensure all system tests added in the future
behave consistently with existing ones, invoke clean.sh from run.sh
before calling setup.sh.
Michał Kępień [Fri, 6 Dec 2019 13:11:01 +0000 (14:11 +0100)]
Detect missing system test results
At the end of each system test suite run, the system test framework
collects all existing test.output files from system test subdirectories
and produces bin/tests/system/systests.output from those files.
However, it does not check whether a test.output file was found for
every executed test. Thus, if the test.output file is accidentally
deleted by the system test itself (e.g. due to an overly broad file
removal wildcard present in clean.sh), its output will not be included
in bin/tests/system/systests.output. Since the result of each system
test suite run is determined by bin/tests/system/testsummary.sh, which
only operates on the contents of bin/tests/system/systests.output, this
can lead to test failures being ignored. Fix by ensuring the number of
test results found in bin/tests/system/systests.output is equal to the
number of tests run and triggering a system test suite failure in case
of a discrepancy between these two values.
Michał Kępień [Fri, 6 Dec 2019 13:11:01 +0000 (14:11 +0100)]
Remove bin/tests/system/clean.sh
Since the role of the bin/tests/system/clean.sh script has now been
reduced to calling a given system test's clean.sh script, remove the
former altogether and replace its only use with a direct invocation of
the latter.
Michał Kępień [Fri, 6 Dec 2019 13:11:01 +0000 (14:11 +0100)]
Remove the -r switch from system test scripts
Since files containing system test output are no longer stored in test
subdirectories, bin/tests/system/clean.sh no longer needs to take care
of removing the test.output file for a given test as testsummary.sh
already takes care of that and even if a test suite terminates
abnormally and another one is started, tee invoked without the -a
command line switch overwrites the destination file if it exists, so
leftover test.output.* files from previous test suite runs are not a
concern. Remove the -r command line switch and the code associated with
it from the relevant scripts.
Michał Kępień [Fri, 6 Dec 2019 13:11:01 +0000 (14:11 +0100)]
Store system test output in bin/tests/system/
Some clean.sh scripts contain overly broad file deletion wildcards which
cause the test.output file (used by the system test framework for
collecting output) in a given system test's directory to be erroneously
removed immediately after the test is started (due to setup.sh scripts
calling clean.sh at the beginning). This prevents the test's output
from being placed in bin/tests/system/systests.output at the end of a
test suite run and thus can lead to test failures being ignored. Fix by
storing each test's output in a test.output.<test-name> file in
bin/tests/system/, which prevents clean.sh scripts from removing it (as
they should only ever affect files contained in a given system test's
directory).
Since the introduction of durations, all ttlval configuration types
are replaced with durations. Duration is an ISO 8601 duration, a
TTL-style value, or a number. These two references were missed and
are now also replaced.
This commit makes some minor changes to the trust anchor code:
1. Replace the undescriptive n1, n2 and n3 identifiers with slightly
better rdata1, rdata2, and rdata3.
2. Fix an occurrence where in the error log message a static number
32 was printed, rather than the rdata3 length.
3. Add a default case to the switch statement checking DS digest
algorithms to catch unknown algorithms.
Ondřej Surý [Wed, 4 Dec 2019 23:02:43 +0000 (00:02 +0100)]
Test for the hard fetchlimit instead of soft fetchlimit
Previously, the fetchlimit tested the recursive-clients soft limit
that's defined as 90% of the hard limit (the actual configured value).
This worked previously because the reaping of the oldest recursive
client was put on the same event queue as the current TCP client, thus
the cleaning has happened before the new TCP client established a new
connection.
With the change in BIND 9.14 that added a multiple event queues the
cleaning of the oldests clients is no longer synchronous and could
happen stochastically making the soft limit testing fail often. The
situation became even worse with the new networking manager, thus we
change the system test to fail only if the hard limit bound is not
honored.
Changing the accounting of the already reaped TCP clients so the soft
limit testing is possible again is out of the scope for this change.
Diego Fronza [Mon, 2 Dec 2019 22:19:56 +0000 (19:19 -0300)]
Fix resolver tests: prefetch 40/41
These two tests were failing basically because in order for prefetching to
happen, the TTL for a given DNS record must be greater than or equal to
the prefetch config value + 9.
The previous TTL for both records was 10, while prefetch value in
configuration was 3, thus making only records with TTL >= 12 elligible
for prefetching.
TTL value for both records was adjusted to the value 13, and prefetch
value was set to 4 (inc by 1), so records with TTL (4 + 9) >= 13 are
elligible for prefetching.
Adjusting prefetch value to 4 gives the test 1 second more to avoid time
problems when sharing resources on a heavy loaded PC.
Also prefetch value in settings is now read by the script and used
by it to corrrectly calculate the amount of time needed to delay before
sending a request to trigger prefetch, adding a bit of flexibility to
fine tune the test in the future.
Diego Fronza [Fri, 29 Nov 2019 14:53:09 +0000 (11:53 -0300)]
Fix resolver test: prefetch disabled
The previous test had two problems:
1. It wasn't written specifically for testing what it was supposed to:
prefetch disabled.
2. It could fail in some circunstances if the computer's load is too
high, due to sleeps not taking parallel tests and cpu load into account.
The new test is testing prefetch disabled as follows:
1. It asks for a txt record for a given domain and takes note of the
record's TTL (which is 10).
2. It sleeps for (TTL - 5) = 5 seconds, having a window of 5 seconds to
issue new queries before the record expires from cache.
3. Three(3) queries are executed in a row, with a interval of 1 second
between them, and for each query we verify that the TTL in response is
less than the previous one, thus ensuring that prefetch is disabled (if
it were enabled this record would have been refreshed already and TTL
would be >= the first TTL).
Having a window of 5 seconds to perform 3 queries with a interval of 1
second between them gives the test a reasonable amount of time
to not suffer from a machine with heavy load.