The current playbook assumes the old digicert ssl cert thats in private.
However, we got that in 2020 and it's expired. We switched pagure.io
over to letsencrypt a while back. Somehow we didn't change the playbook
however, or the change was lost somewhere. :(
So, this adds 2 calls to the letsencrypt role to get certs for the prod
and staging pagure instances. I think this should do the right thing
with placement of files, but more eyes welcome.
Without this playbooks runs have the chance of messing up pagure.io
certs, so I think we should fix this asap.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This deploys a copy of coreos-cincinnati services to the new ocp4
cluster, in order to start migrating off the current ocp3 cluster.
The new deployment copy is not going to serve requests yet, until
all the routes are in place and the DNS updated.
Signed-off-by: Luca BRUNO <luca.bruno@coreos.com>
So, without this tlsproxy wasn't working and no connection reuse was
happening. With it, it seems to be processing away nicely and reusing
connections.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Recently, redhat.com changed internal MX servers. The new servers are
have rate limits on incoming emails from one ip and admins there don't
want to add a bunch of exceptions, so we need to adjust our end to not
flood connections to them. Currently, connections burst up to 100 (the
smtp postfix default) which goes over their limits and causes the
internal MX to reject emails from us for a while.
So, this change:
* Adds some domains to fast_flush. This allows us to use postqueue -s
domain to flush emails to a particular domain.
* Changes the smtp limit to 40. This is under the redhat.com limit.
* Has ansible actually install the master.cf.gateway on bastion servers.
Currently they were using the stock/default one.
* Enables the tlsproxy service, which is actually needed to get that tls
reuse working.
After these changes, we keep few connections to the redhat.com mx open,
but we reuse them and send more emails over existing connections. No
'too many connection emails' have happened since the changes.
The queue slowly seems to be processing down.
Since this was causing an outage of email, I have already applied these
things to bastion01, but I'd like to make sure we match up to whats in
ansible.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Right now we are hitting redhat.com mx server connection limits.
This might be because we are starting too many new connections at once.
Enabling this should reduce the new connections by reusing existing
ones.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
