We're going to want Mailman 3 served over HTTPS for security
reasons, so start by generating certificates for each of the sites
we have in v2. Also collect the acme.sh logs for verification.
Vexxhost wants to change the routers for their IPv6 setup, which will
change their link-local addresses. Change our setup to use the global
addresses instead, which will stick.
We want to limit the time we remember possibly broken index responses
which we sometimes receive from the pypi CDN. We cannot set this per
location, so this is a comprise between reducing the impact of bad eggs
in the cache and trying not to throw out the good eggs too fast.
This is a new mailing list into which the current staff ML from the
lists.openstack.org site will be manually migrated. The existing one
is not included in our current configuration anyway, but a followup
change will set up an appropriate forward for its old address once
migration is complete.
In order to be able to redirect list addresses which have moved from
one domain to another, we need a solution to alias the old addresses
to the new ones. We have simple aliases but they only match on the
local part. Add a new /etc/aliases.domain which matches full
local_part@domain addresses instead. Also collect this file in the
Mailman deployment test for ease of inspection.
In OFTC, entery message is set via ``entrymsg`` command,
correcting it in doc.
<ChanServ> *** SET Help ***
URL: Set the channel's homepage.
EMAIL: Sets the channel's e-mail address.
ENTRYMSG: Sets the channel greeting.
It appears that simply setting stdin to an empty string is
insufficient to make newlist calls from Ansible correctly look like
they're coming from a non-interactive shell. As it turns out, newer
versions of the command include a -a (--automate) option which does
exactly what we want: sends list admin notifications on creation
without prompting for manual confirmation.
Drop the test-time addition of -q to quell listadmin notifications,
as we now block outbound 25/tcp from nodes in our deploy tests. This
has repeatedly exposed a testing gap, where the behavior in
production was broken because of newlist processes hanging awaiting
user input even though we never experienced it in testing due to the
-q addition there.
Mailman utilizes on-disk queues to store its actions, so doesn't act
unless its queue runners are operating. They're not started at
setup, so perform a service restart to make sure they're running in
Mailman uses a (usually hidden) mailing list named "mailman" to
handle things like password reminders and certain other sorts of
notifications. We have one in the configuration for all the sites on
lists.openstack.org but not on lists.katacontainers.io, even though
the production server has one. Not creating this list will cause
the services to fail to start, and since we want to test restarting
them in an upcoming change, add the missing entry (it will be a
no-op in production anyway).
Zuul change I6d7e7e7a9e19d46a744f9ffac8d532fc6b4bba01 introduced a
multi-line formatter that makes exceptions and other multi-line output
much easier to follow in the logs. Use it here for the simple
formatter in the production Zuul deployment.
This is a typo from the job shuffle in
I8f6150ec2f696933c93560c11fed0fd16b11bf65 -- this should be a soft
It is currently causing periodic jobs to fail
Mailman v2.1 is still a Python2-only application, and expects
/usr/bin/python to be present. On Ubuntu Focal, there is no such
symlink provided by the Python 2.7 packages, and an extra
python-is-python2 transitional package is used to explicitly create
it in cases where that's required.
It's good to be able to look at the MTA logs and see whether
anything's (attempted to be) sent, since we block SMTP egress from
these test nodes by default.
Our deployment tests don't need to send E-mail messages. More to the
point, they may perform actions which would like to send E-mail
messages. Make sure, at the network level, they'll be prevented from
doing so. Also allow all connections to egress from the loopback
interface, so that services like mailman can connect to the Exim MTA
Add new rolevars for egress rules to support this, and also fix up
some missing related vars in the iptables role's documentation.
This used to be called "bridge", but was then renamed with
Ia7c8dd0e32b2c4aaa674061037be5ab66d9a3581 to install-ansible to be
It is true that this is installing Ansible, but as part of our
reworking for parallel jobs this is the also the synchronisation point
where we should be deploying the system-config code to run for the
Thus naming this "boostrap-bridge" should hopefully be clearer again
about what's going on.
I've added a note to the job calling out it's difference to the
infra-prod-service-bridge job to hopefully also avoid some of the
This playbook was renamed "install-ansible.yaml" with
We want all jobs to match on this; it will make them run if we update
the ansible version on the bastion host, bridge.