Adding the information about which host we were checking for certcheck
did help in debugging. It pointed out that a specific host was at fault
(nb02 in this case though it could change over time) and further
investigation of this host showed acme.sh was not running there at all
due to earlier failures. Rather than the playbook ending at that point
it continued to run until building the certcheck list and then had a
fatal error leading to the confusion.
Add a breadcrumb comment to the Ansible role to help point this behavior
out in the future.
Change-Id: Ib607665d75eb666d19c8508346eb217783b98eb5
We've seen the certcheck list building loop fail because some host
doesn't ahve the appropriate var in its hostvars. Unfortunately ansible
logging doesn't record the value of the list iteration item when an
iteration fails. It only records this value when it succeeds....
Work around this with our own debugging output.
Additionally use a unique loop_var value in case we're hitting some sort
of 'item' name collision problem. It is just good practice to avoid
'item' anyway.
Change-Id: Ia3ed089187e0b8397413fbb989c44906d56811ae
In Ansible 6 this doesn't come out as a list. Refactor this into a
more jinja-y pipeline that should do a better job of it.
Change-Id: I5684291047a3e1000cd38ba33a951bed9fa3081f
This autogenerates the list of ssl domains for the ssl-cert-check tool
directly from the letsencrypt list.
The first step is the install-certcheck role that replaces the
puppet-ssl_cert_check module that does the same. The reason for this
is so that during gate testing we can test this on the test
bridge.openstack.org server, and avoid adding another node as a
requirement for this test.
letsencrypt-request-certs is updated to set a fact
letsencrypt_certcheck_domains for each host that is generating a
certificate. As described in the comments, this defaults to the first
host specified for the certificate and the listening port can be
indicated (if set, this new port value is stripped when generating
certs as is not necessary for certificate generation).
The new letsencrypt-config-certcheck role runs and iterates all
letsencrypt hosts to build the final list of domains that should be
checked. This is then extended with the
letsencrypt_certcheck_additional_domains value that covers any hosts
using certificates not provisioned by letsencrypt using this
mechanism.
These additional domains are pre-populated from the openstack.org
domains in the extant check file, minus those openstack.org domain
certificates we are generating via letsencrypt (see
letsencrypt-create-certs/handlers/main.yaml). Additionally, we
update some of the certificate variables in host_vars that are
listening on port !443.
As mentioned, bridge.openstack.org is placed in the new certcheck
group for gate testing, so the tool and config file will be deployed
to it. For production, cacti is added to the group, which is where
the tool currently runs. The extant puppet installation is disabled,
pending removal in a follow-on change.
Change-Id: Idbe084f13f3684021e8efd9ac69b63fe31484606
