| Age | Commit message (Collapse) | Author |
|---|
|
If a target is a hostname we'll explicitly resolve it for
both IPv4 and IPv6.
|
|
THis tests that a server is listening on :53.
|
|
If we're given an IPv4 or IPv6 address then use it, if
not then attempt to resolve the name that we've been
given to one/other/both of these types and test
in turn.
|
|
This is a clone of the code that we're already using for
SSL checking of domains. The biggest excpetion is that I've
disabled the SSL v2/v3 checking because that is causing alerts
on https://google.com/
This closes #9563.
|
|
This allows the test-suite to pass.
|
|
No functional changes.
|
|
Also only sleep between fetches if we couldn't find a job because
the queue was empty.
|
|
|
|
This was an invalid comment, the timeout related to HTTP-fetches.
|
|
|
|
We now parse a single test-definition into multiple
test-implementations. This isn't required here because
the parser only needs to know that the configuration file
*can* be parsed, not what the result is.
Validate that we got an array, but otherwise ignore the
results after the first.
|
|
|
|
This is a stub for the moment, but it validates that we can have
multiple handlers for a given test-type.
This updates #9558.
|
|
|
|
We need to do this such that we can show all possible results
of a test in the status-page. There might be three back-ends
with different results and if we filter by class-type we'll
be able to see that.
|
|
The new approach uses the redis gems timeout functionality
and ensures we never return a null-job. Instead we timeout
and repeat with a stalling-sleep in the way.
This closes #9553.
|
|
|
|
|
|
As soon as we allow multiple test-implementations we get
into a mess, as Mauve regards an ID as unique and that is
based upon the test-definition not the implementing method
We want to allow:
* HTTPS test to succeed.
* SSL-check to fail.
Which means multiple tests of type "https" will have different
IDs. Force this by adding on the class of the implementation.
|
|
|
|
a given input-line.
|
|
We now work on the assumption that a single "job", pulled from
the queue, might contain multiple "test" objects. These are
the instances of the protocol-testers which we actually execute.
This is part of #9558.
|
|
|
|
|
|
|
|
The redis-state "alerter" saves state in a useful way for the
future, and will now save an array of hashes - each has corresponding
to a useful result.
|
|
|
|
We now record:
custodian.$type.$host.test_duration [time]
|
|
|
|
Rather than passing our settings-object around, as well as
specific settings that are read from it, just pass the object.
The worker can read the settings directly if/when it needs to.
|
|
We now set the queue-address via $QUEUE_ADDRESS, otherwise
we default to localhost. This works for both redis & beanstalkd.
|
|
Now that we've moved to using redis by default the handling of queue-flushing
needs to change. We can simply get rid of the busy-wait and run a redis
"del" operation.
With that in mind we've moved the flushing logic to our queue abstraction
layer, and simplified our queue-helper script.
|
|
|
|
This refereed to ruby1.8 in a versioned way which was wrong.
|
|
|
|
(i.e. "pxe.io must not run mx otherwise 'no mail for steve'.")
|
|
Default to redis as this is more likely to be installed.
|
|
This replaces redis as a hard-wired default.
|
|
This means we can queue/dequeue to either Redis or Beanstalkd.
|
|
We now connec to the MX-servers via XX:25 and alert if that
fails.:wq
|
|
|
|
This will perform a DNS-lookup AND SMTP-test for the given
domain.
|
|
This is not-yet used, but it will-be shortly. The intention is
that we can seamlessly swap out the queue implemention in the
near future so that we'll be able to use Redis.
|
|
We show the result we expected and what we received,
but we do so with quoted strings. So rather than:
* one
* two
we show "one,two". This closes #8538.
|
|
|
|
which protocol to use.
|
|
|
|
|
|
compare stuff.
|
|
|
