- 09 Mar, 2018 17 commits
- 08 Mar, 2018 22 commits
-
-
Evan Hunt authored
-
Evan Hunt authored
-
Evan Hunt authored
-
Michał Kępień authored
Tweak timestamp checking in the cds system test Closes #136 See merge request !114
-
Michał Kępień authored
4912. [test] Improved the reliability of the 'cds' system test. [GL #136] (cherry picked from commit c92bacec)
-
Michał Kępień authored
Given the characteristics of the three timestamps involved in file modification time checks in the cds system test (each one is an hour apart from the next), reduce the resolution of these checks to 1 minute. This will prevent intermittent false negatives caused by exceeding the currently allowed difference of 9 seconds between file modification times without making the test moot. Also note that by using abs(), checkmtime.pl allows the cds system test to pass when the modification time of the checked file is less than an hour (or two hours for the second check) in the past. This should never happen, so remove abs() from the condition checked by checkmtime.pl. (cherry picked from commit ab2913a2)
-
(cherry picked from commit efc9bc5d)
-
Michał Kępień authored
Fix a race in the mkeys system test Closes #128 See merge request !103
-
Michał Kępień authored
4911. [test] Improved the reliability of the 'mkeys' system test. [GL #128] (cherry picked from commit 32f875f9)
-
Michał Kępień authored
Calling nextpart() after reconfiguring ns1 is not safe, because the expected log message may appear in ns5/named.run before nextpart() is run. With the TTL for ./DNSKEY set to 20 seconds, ns5 will refresh it after 10 seconds, by which time wait_for_log() will already have failed. This results in a false negative. However, just calling nextpart() before reconfiguring ns1 would introduce a different problem: if ns5 refreshed ./DNSKEY between these two steps, the subsequent wait_for_log() call would return immediately as it would come across the log message about a failure while refreshing ./DNSKEY instead of the expected success. This in turn would result in a different false negative as the root key would still be uninitialized by the time "rndc secroots" is called. Prevent both kinds of false negatives by: - calling nextpart() before reconfiguring ns1, in order to prevent the first case described above, - looking for a more specific log message, in order to prevent the second case described above. Also look for a more specific log message in the first part of the relevant check, not to fix any problem, but just to emphasize that a different fetch result is expected in that case. With these tweaks in place, if a (failed) ./DNSKEY refresh is scheduled between nextpart() and reconfiguring ns1, wait_for_log() will just wait for two more seconds (one "hour"), at which point another refresh attempt will be made that will succeed. (cherry picked from commit 012ca0a2)
-
Mark Andrews authored
Resolve "Update util/check-changes to work on release branches." Closes #133 See merge request !110
-
Mark Andrews authored
(cherry picked from commit 88a22020)
-
Mark Andrews authored
-
Mark Andrews authored
Resolve "in-view duplicate zone not detected by named-checkconf" Closes #125 See merge request !97
-
Mark Andrews authored
(cherry picked from commit 83f85817)
-
Mark Andrews authored
check for in-view zones colliding with other zone definitions; also check the syntax of the in-view zone name (cherry picked from commit 3e7e2800)
-
Mark Andrews authored
(cherry picked from commit ca55c672)
-
Tinderbox User authored
-
Tinderbox User authored
-
- 07 Mar, 2018 1 commit
-