1

I just face an extensive Email service disruption at my work. During the incident, we had some postfix giving some errors concerning:

Fatal: connect #n to subsystem private/rewrite: Connection refused.

Since it was a big incident, many things were tried at the same time, so I am unsure if what is coming next is what fixed the issue or not, I'm looking for opinions.

Following those Connection Refused, they went back in time on other Postfix servers we had, and someone remember a similar issue and it was related to Certificates. So they ran update-ca-certificate --fresh and restarted Postfix and it worked...

At the same time a Router / Firewall was restarted...

So what we are trying to figure out, is if that update-ca-certificate was actually needed...

If you would run servers for a long time, should you need to run this update-ca-certificate to update certs after X amount of time?

Improve this question
1
  • Something seems odd about that versioned Ubuntu tag. Modern Ubuntu ships some scripts that copy certificate bundles into the postfix chroot directory, so the way that works or does not work is likely something you want to investigate.
    – anx
    Sep 26 at 14:11

3 Answers 3

Reset to default
2

Chances to find out what helped afterwards are pretty slim. Generally, update-ca-certs only needs to be run after CA files change. When they are updated by the package management of the OS (in this case apt) it is done automatically. When you add or change files there you need to run it manually. It does not need to be run at intervals.

Improve this answer
1
  • Thanks that's pretty much what I was trying to confirm - And you just did that!! Thanks @gerald
    – pSyToR
    Sep 29 at 10:43
0

You could create a script like this

#!/bin/bash
/usr/sbin/update-ca-certificates

And then store it somewhere /path/to/update_ca_certs.sh

Give it exec rights

chmod +x /path/to/update_ca_certs.sh

And then create a cronjob

crontab -e

For example daily at 2AM

0 2 * * * /path/to/update_ca_certs.sh
Improve this answer
1
0

Only way I can think of to find out from an already fixed issue is to check back through /var/logs/<some_logs> you might get lucky and still have relevant info available. For <some_logs> I'm thinking mail.log, mail.info and maybe syslog

In /var/logs, could try something like

sudo grep -r postfix | grep refused

to search all of /var/log/* and subdirectories, or

sudo grep postfix mail.log mail.info syslog | grep refused

to target those specific files. Might need to play around with the

For example, a log might have details as to what it was that meant postfix couldn't connect. If you're really lucky there'll be some info about what process allowed postfix to re-establish the connection, which will be easier to find if you know roughly what time the fix/es took place

If logs have rotated since posting and been zipped use zgrep in place of grep and append the appropriate number to the file name/s

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .