1. 09 Mar, 2018 14 commits
  2. 08 Mar, 2018 3 commits
    • Michał Kępień's avatar
      Tweak timestamp checking in the cds system test · ab2913a2
      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.
    • Michał Kępień's avatar
      Fix a race between "rndc reconfig" and waiting for a ./DNSKEY fetch to complete · 012ca0a2
      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.
    • Mark Andrews's avatar
  3. 07 Mar, 2018 4 commits
  4. 06 Mar, 2018 3 commits
  5. 01 Mar, 2018 1 commit
    • Evan Hunt's avatar
      revise soft limit test · 86838b2a
      Evan Hunt authored
      - don't bail out of the loop if clients are exceeded, just count incidents
      - verbosely describe expectations and results
  6. 28 Feb, 2018 1 commit
  7. 27 Feb, 2018 5 commits
  8. 26 Feb, 2018 4 commits
  9. 25 Feb, 2018 2 commits
  10. 24 Feb, 2018 2 commits
  11. 23 Feb, 2018 1 commit
    • Evan Hunt's avatar
      improve dyndb test resilience · 749df056
      Evan Hunt authored
      - no longer grep for specific line numbers when checking
        parameter logging, as those can change
      - report the failure immediatey if parameter check fails