PostFix not working after update

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

PostFix not working after update

Paul Lauzon
I am trying to troubleshoot after an update using apt-get update/upgrade I did a few days ago on Debian 9 (now 10).   PostFix does not seem to work anymore. I tried many things: rebooting, restarting postfix, upgrading debian from 9 to 10.  But it is still not working as before.

I confirmed that the master.cf and main.cf were not changed by the installer.  Is there a troubleshooting guide somewhere?

Here is some info I got:

# service postfix status
   ? postfix.service - Postfix Mail Transport Agent
      Loaded: loaded (/lib/systemd/system/postfix.service; disabled; vendor preset: enabled)
      Active: active (exited) since Fri 2020-10-09 05:26:54 PDT; 6min ago
     Process: 3059 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
    Main PID: 3059 (code=exited, status=0/SUCCESS)

   Oct 09 05:26:54 ...: Starting Postfix Mail Transport Agent...
   Oct 09 05:26:54 ...: Started Postfix Mail Transport Agent.

# postfix -v check
   postfix: name_mask: all
   postfix: inet_addr_local: configured 5 IPv4 addresses
   postfix: inet_addr_local: configured 2 IPv6 addresses
   postfix: Postfix is running with backwards-compatible default settings
   postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
   postfix: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
   postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out
   postfix/postfix-script: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
   postfix/postfix-script: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ

I looked at the log and saw similar warnings as above:
   Oct  9 05:35:00 ...: name_mask: all
   Oct  9 05:35:00 ...: inet_addr_local: configured 5 IPv4 addresses
   Oct  9 05:35:00 ...: inet_addr_local: configured 2 IPv6 addresses
   Oct  9 05:35:00 ...: Postfix is running with backwards-compatible default settings
   Oct  9 05:35:00 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details
   Oct  9 05:35:00 ...: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
   Oct  9 05:35:04 ...: warning: symlink leaves directory: /etc/postfix/./makedefs.out
   Oct  9 05:35:04 ...: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
   Oct  9 05:35:05 ...: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
   Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly


I looked at the postfix compatibility web page but I am not sure what options make it go into compatibility mode.  Also the above are warnings so I am guessing this would not prevent postfix from running.  Or maybe warnings are considered unacceptable?

I also tried this:
      apt-get install --reinstall postfix

Do I really need to do these?
   postconf compatibility_level=2
   postfix reload
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Noel Jones-2

On 10/12/2020 3:59 PM, Paul Lauzon wrote:

> I am trying to troubleshoot after an update using apt-get
> update/upgrade I did a few days ago on Debian 9 (now 10).   PostFix
> does not seem to work anymore. I tried many things: rebooting,
> restarting postfix, upgrading debian from 9 to 10.  But it is still
> not working as before.
>
> I confirmed that the master.cf <http://master.cf> and main.cf
> <http://main.cf> were not changed by the installer.  Is there a
> troubleshooting guide somewhere?
>

General debugging info here:
http://www.postfix.org/DEBUG_README.html

In particular, see what postfix logs when you run "postfix start"

Do NOT enable verbose logging. Everything you need is very likely in
the normal logging.


   -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Bob Proulx
In reply to this post by Paul Lauzon
Paul Lauzon wrote:
> PostFix does not seem to work anymore.

There are an infinite number of ways for something to fail but only
exactly one correct way for it to work.

In addition to the other comments I see this:

> # service postfix status
>    ? postfix.service - Postfix Mail Transport Agent
>       Loaded: loaded (/lib/systemd/system/postfix.service; disabled; vendor preset: enabled)

Why is it disabled?  Is that the problem?  That it is not running?  Try enabling it.
Since you are running systemd the systemd way to enable it is:

    systemctl enable postfix.service

>    Oct  9 05:35:00 ...: Postfix is running with backwards-compatible default settings
>    Oct  9 05:35:00 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details
>    Oct  9 05:35:00 ...: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"

The above might be a notification of a change but it is not going to
be "the problem" you are chasing down.  I see you updated it with the
following but I would have recommended to ignore it for the moment.

> Do I really need to do these?
>    postconf compatibility_level=2
>    postfix reload

Before doing this I would have asked what was the state of field 5 in
the master.cf file.  If it is 'y' or 'n' then the above will not
change anything.  But if it is '-' then note that the default changed
from "no" previously to "yes" now in the newer version.  Running the
above switches to using the new "yes" default instead of the previous
"no" default.

    # service type  private unpriv  chroot  wakeup  maxproc command + args
    #               (yes)   (yes)   (yes)   (never) (100)
    # ==========================================================================
    smtp       inet  n       -       y       -       -       smtpd

>    Oct  9 05:35:04 ...: warning: symlink leaves directory: /etc/postfix/./makedefs.out
>    Oct  9 05:35:04 ...: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
>    Oct  9 05:35:05 ...: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
>    Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly

The theory goes that in Debian when the init script starts it runs a
helper script /usr/lib/postfix/configure-instance.sh which will update
all files that are needed for running inside the chroot.  If those
files are out of sync then that is an indication that the init did not
run that script and therefore did not run correctly.  Since you are
running systemd (Lasciate ogne speranza, voi ch'intrate.) then the
start process would be something like this.

    systemctl is-enabled postfix.service
    systemctl enable postfix.service
    systemctl start postfix.service
    systemctl status postfix.service

Note that in the systemd architecture systemctl isn't the process that
does the starting.  It simply sends a message to the running systemd.
Therefore it never reports on the status of any action.  One must
always remember to follow any action with a status request in order to
know the success or failure of the previous action.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Paul Lauzon
Thanks for the help.

I have kept Postfix and many other services disabled at power-up since last year and it works well for me that way.  I did that last year after I got DDOS and spammed tons of mail with virus attachments and my server was so overwhelmed that I could not use it for days and even login with putty took several hours trying.  By starting my server with only the basic services, when the DDOS/spam happens, I can just request a server reboot and I can login easily and start the services after I am done.

I did not do these yet:
> postconf compatibility_level=2
> postfix reload

This is what I have in my master.cf file:
# ==========================================================================
# service type  private unpriv  chroot  wakeup  maxproc command + args
#               (yes)   (yes)   (yes)   (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes

So that '-' would be what created the issue perhaps?   If so, is it better to run postfix using chroot = yes since this is the new default?  I would have to find a tutorial on how to reinstall it properly that way I guess.  Or I could just put a 'no' there but it would make it less secure?  I prefer the most secure option.

For systemd (funny: abandon all hope, ye who enter), I would hope that a 'disabled' service is not considered 'uninstalled' so that when I updated my certificates using "Let's Encrypt" it did not update the Postfix certificates.  But any automation is a very good way to screw-up...  Just like my update did.

On Mon, Oct 12, 2020 at 7:09 PM Bob Proulx <[hidden email]> wrote:
Paul Lauzon wrote:
> PostFix does not seem to work anymore.

There are an infinite number of ways for something to fail but only
exactly one correct way for it to work.

In addition to the other comments I see this:

> # service postfix status
>    ? postfix.service - Postfix Mail Transport Agent
>       Loaded: loaded (/lib/systemd/system/postfix.service; disabled; vendor preset: enabled)

Why is it disabled?  Is that the problem?  That it is not running?  Try enabling it.
Since you are running systemd the systemd way to enable it is:

    systemctl enable postfix.service

>    Oct  9 05:35:00 ...: Postfix is running with backwards-compatible default settings
>    Oct  9 05:35:00 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details
>    Oct  9 05:35:00 ...: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"

The above might be a notification of a change but it is not going to
be "the problem" you are chasing down.  I see you updated it with the
following but I would have recommended to ignore it for the moment.

> Do I really need to do these?
>    postconf compatibility_level=2
>    postfix reload

Before doing this I would have asked what was the state of field 5 in
the master.cf file.  If it is 'y' or 'n' then the above will not
change anything.  But if it is '-' then note that the default changed
from "no" previously to "yes" now in the newer version.  Running the
above switches to using the new "yes" default instead of the previous
"no" default.

    # service type  private unpriv  chroot  wakeup  maxproc command + args
    #               (yes)   (yes)   (yes)   (never) (100)
    # ==========================================================================
    smtp       inet  n       -       y       -       -       smtpd

>    Oct  9 05:35:04 ...: warning: symlink leaves directory: /etc/postfix/./makedefs.out
>    Oct  9 05:35:04 ...: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
>    Oct  9 05:35:05 ...: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
>    Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly

The theory goes that in Debian when the init script starts it runs a
helper script /usr/lib/postfix/configure-instance.sh which will update
all files that are needed for running inside the chroot.  If those
files are out of sync then that is an indication that the init did not
run that script and therefore did not run correctly.  Since you are
running systemd (Lasciate ogne speranza, voi ch'intrate.) then the
start process would be something like this.

    systemctl is-enabled postfix.service
    systemctl enable postfix.service
    systemctl start postfix.service
    systemctl status postfix.service

Note that in the systemd architecture systemctl isn't the process that
does the starting.  It simply sends a message to the running systemd.
Therefore it never reports on the status of any action.  One must
always remember to follow any action with a status request in order to
know the success or failure of the previous action.

Bob
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Bob Proulx
Paul Lauzon wrote:
> I have kept Postfix and many other services disabled at power-up since last
> year and it works well for me that way.  I did that last year after I got
> DDOS and spammed tons of mail with virus attachments and my server was so
> overwhelmed that I could not use it for days and even login with putty took
> several hours trying.  By starting my server with only the basic services,
> when the DDOS/spam happens, I can just request a server reboot and I can
> login easily and start the services after I am done.

Gotcha.  It's unusual.  But shouldn't be "the problem".

> I did not do these yet:
> > postconf compatibility_level=2
> > postfix reload
>
> This is what I have in my master.cf file:
> # ==========================================================================
> # service type  private unpriv  chroot  wakeup  maxproc command + args
> #               (yes)   (yes)   (yes)   (never) (100)
> # ==========================================================================
> smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes

Since the chroot field is a "-" that means it will use the default
value.  Postfix documents this here.

    http://www.postfix.org/COMPATIBILITY_README.html#chroot

Summary: If it is 0 then it assumes that default is 'y' and if it is
set to 2 then it assumes it is 'n'.  But in case I made a typo there
ignore me and read the authoritative documentation which I am sure has
been proofread carefully!

Which means that changing compatibility_level from 0 to 2 will change
the chroot configuration to stop using it in your case now when you
were using the chroot by default before.

If you simply want to silence the warning message "using
backwards-compatible default setting chroot=y" then setting that field
explicitly to 'y' before doing should keep the exact same
configuration that you had before making that change but the warning
would be silenced.

    smtp inet n - y - - smtpd -o smtpd_sasl_auth_enable=yes

> So that '-' would be what created the issue perhaps?

It is what created the warning message "using backwards-compatible
default setting chroot=y".  But let me assure you that there are
zillions of Debian systems out there emitting that warning because no
one changed anything and things are working okay regardless.  It seems
very unlikely to be related to whatever is "the problem" that you are
currently experiencing.

> If so, is it better to run postfix using chroot = yes since this is
> the new default?  I would have to find a tutorial on how to
> reinstall it properly that way I guess.  Or I could just put a 'no'
> there but it would make it less secure?  I prefer the most secure
> option.

I prefer keeping in the middle of the wildebeest herd as it crosses
the river.  The crocodile predators most often take the weak ones from
the edge first.  Debian has for many years been defaulting to the
chroot configuration.  You have apparently been using the chroot
configuration.  Therefore I would continue.  I am myself using the
chroot configuration.  I would investigate why the init start of
postfix did not update the chroot properly.  But again I don't think
that is "the problem" you are currently experiencing.

> For systemd (funny: abandon all hope, ye who enter), I would hope that a
> 'disabled' service is not considered 'uninstalled' so that when I updated
> my certificates using "Let's Encrypt" it did not update the Postfix
> certificates.  But any automation is a very good way to screw-up...  Just
> like my update did.

By this I assume you are setting the postfix ssl configuration
variables smtpd_tls_key_file and smtpd_tls_cert_file to use your Let's
Encrypt obtained Domain Validation certificates?  That's fine.  I do
that too.  But note that SMTP STARTTLS as far as I know does not and
cannot not require certificate validation.  It's opportunistic only.

    http://www.postfix.org/TLS_README.html

By default Debian configures a self-signed certificate.  That's okay
too.  Likely not "the problem" you are currently experiencing.  For
debugging things the best reference is all of the good information here.

    http://www.postfix.org/DEBUG_README.html

However let me point you specifically to what I would do.  I see by
what you have shown so far this:

    Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly

So postfix is not running for some reason.  In that case start it.
Then look in the /var/log/syslog and /var/log/mail.log files for any
messages logged there.  Here is an example of what might be seen there
from a systemd system here, which should match your systemd machine there.

    rwp@madness:~$ sudo systemctl start postfix.service

    rwp@madness:~$ sudo tail /var/log/syslog
    Oct 13 14:26:30 madness systemd[1]: Starting Postfix Mail Transport Agent (instance -)...
    Oct 13 14:26:30 madness postfix/postfix-script[17085]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
    Oct 13 14:26:30 madness postfix/postfix-script[17123]: starting the Postfix mail system
    Oct 13 14:26:30 madness postfix/master[17125]: daemon started -- version 3.4.14, configuration /etc/postfix
    Oct 13 14:26:30 madness systemd[1]: Started Postfix Mail Transport Agent (instance -).
    Oct 13 14:26:30 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:26:30 madness systemd[1]: Started Postfix Mail Transport Agent.

It would be expected that if there is a problem that there would be an
error message logged in that file at that location.  I will create an
error for the example.

    Oct 13 14:31:13 madness systemd[1]: Starting Postfix Mail Transport Agent (instance -)...
    Oct 13 14:31:13 madness configure-instance.sh[17675]: postconf: fatal: /etc/postfix/main.cf, line 46: missing '=' after attribute name: "errorinconfigurationfilehereplacedbyrwpasanexample"
    Oct 13 14:31:14 madness configure-instance.sh[17675]: postconf: fatal: /etc/postfix/main.cf, line 46: missing '=' after attribute name: "errorinconfigurationfilehereplacedbyrwpasanexample"
    Oct 13 14:31:15 madness systemd[1]: [hidden email]: Control process exited, code=exited, status=1/FAILURE
    Oct 13 14:31:15 madness systemd[1]: [hidden email]: Failed with result 'exit-code'.
    Oct 13 14:31:15 madness systemd[1]: Failed to start Postfix Mail Transport Agent (instance -).
    Oct 13 14:31:15 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:31:15 madness systemd[1]: Started Postfix Mail Transport Agent.

Note that systemctl status shows nothing of use here.  We need the
logfile for that information.

    rwp@madness:~$ sudo systemctl status postfix.service
    * postfix.service - Postfix Mail Transport Agent
       Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled)
       Active: active (exited) since Tue 2020-10-13 14:31:15 MDT; 1min 29s ago
      Process: 17680 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
     Main PID: 17680 (code=exited, status=0/SUCCESS)

    Oct 13 14:31:15 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:31:15 madness systemd[1]: Started Postfix Mail Transport Agent.

Again this is simply an example that I created to show the type of
thing that might be seen as an error in the log file.

What's in your log file?

Good luck! :-)

Bob
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Paul Lauzon
Thanks a lot for taking the time to thoroughly answer my questions!

My problem is that I only see warnings in the log file, no errors.

Even after forcing a value for chroot (tried both 'y' and 'n', see below), it still complains about compatibility.  But from the list of compatibility issues, that was the only one I could find in my config files.  Unless these settings are in some other files than master.cf and main.cf.

This is the original log I included in my first email:
      Oct  9 05:35:00 ...: name_mask: all
      Oct  9 05:35:00 ...: inet_addr_local: configured 5 IPv4 addresses
      Oct  9 05:35:00 ...: inet_addr_local: configured 2 IPv6 addresses
      Oct  9 05:35:00 ...: Postfix is running with backwards-compatible default settings
      Oct  9 05:35:00 ...: See http://www.postfix.org/COMPATIBILITY_README.html for details
      Oct  9 05:35:00 ...: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
      Oct  9 05:35:04 ...: warning: symlink leaves directory: /etc/postfix/./makedefs.out
      Oct  9 05:35:04 ...: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
      Oct  9 05:35:05 ...: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
      Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly

I have set chroot = 'y' for both smtp and smtps in master.cf, started postfix and got this:
   Oct 14 04:42:02 ... postfix[25139]: Postfix is running with backwards-compatible default settings
   Oct 14 04:42:02 ... postfix[25139]: See http://www.postfix.org/COMPATIBILITY_README.html for details
   Oct 14 04:42:02 ... postfix[25139]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
   Oct 14 04:42:02 ... postfix/postfix-script[25202]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
   Oct 14 04:42:02 ... postfix/postfix-script[25223]: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
   Oct 14 04:42:03 ... postfix/postfix-script[25236]: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
   Oct 14 04:42:03 ... postfix/postqueue[25246]: warning: Mail system is down -- accessing queue directly

I also tried chroot = 'n' for both smtp and smtps in master.cf, started postfix and got this:
   Oct 14 04:47:44 ... postfix[26087]: Postfix is running with backwards-compatible default settings
   Oct 14 04:47:44 ... postfix[26087]: See http://www.postfix.org/COMPATIBILITY_README.html for details
   Oct 14 04:47:44 ... postfix[26087]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
   Oct 14 04:47:45 ... postfix/postfix-script[26150]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
   Oct 14 04:47:45 ... postfix/postfix-script[26171]: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
   Oct 14 04:47:45 ... postfix/postfix-script[26184]: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ
   Oct 14 04:47:45 ... postfix/postqueue[26194]: warning: Mail system is down -- accessing queue directly

Perhaps I will try deleting postfix and reinstalling it from scratch.  It's already been a week without mail...

On Tue, Oct 13, 2020 at 4:36 PM Bob Proulx <[hidden email]> wrote:
Paul Lauzon wrote:
> I have kept Postfix and many other services disabled at power-up since last
> year and it works well for me that way.  I did that last year after I got
> DDOS and spammed tons of mail with virus attachments and my server was so
> overwhelmed that I could not use it for days and even login with putty took
> several hours trying.  By starting my server with only the basic services,
> when the DDOS/spam happens, I can just request a server reboot and I can
> login easily and start the services after I am done.

Gotcha.  It's unusual.  But shouldn't be "the problem".

> I did not do these yet:
> > postconf compatibility_level=2
> > postfix reload
>
> This is what I have in my master.cf file:
> # ==========================================================================
> # service type  private unpriv  chroot  wakeup  maxproc command + args
> #               (yes)   (yes)   (yes)   (never) (100)
> # ==========================================================================
> smtp inet n - - - - smtpd -o smtpd_sasl_auth_enable=yes

Since the chroot field is a "-" that means it will use the default
value.  Postfix documents this here.

    http://www.postfix.org/COMPATIBILITY_README.html#chroot

Summary: If it is 0 then it assumes that default is 'y' and if it is
set to 2 then it assumes it is 'n'.  But in case I made a typo there
ignore me and read the authoritative documentation which I am sure has
been proofread carefully!

Which means that changing compatibility_level from 0 to 2 will change
the chroot configuration to stop using it in your case now when you
were using the chroot by default before.

If you simply want to silence the warning message "using
backwards-compatible default setting chroot=y" then setting that field
explicitly to 'y' before doing should keep the exact same
configuration that you had before making that change but the warning
would be silenced.

    smtp inet n - y - - smtpd -o smtpd_sasl_auth_enable=yes

> So that '-' would be what created the issue perhaps?

It is what created the warning message "using backwards-compatible
default setting chroot=y".  But let me assure you that there are
zillions of Debian systems out there emitting that warning because no
one changed anything and things are working okay regardless.  It seems
very unlikely to be related to whatever is "the problem" that you are
currently experiencing.

> If so, is it better to run postfix using chroot = yes since this is
> the new default?  I would have to find a tutorial on how to
> reinstall it properly that way I guess.  Or I could just put a 'no'
> there but it would make it less secure?  I prefer the most secure
> option.

I prefer keeping in the middle of the wildebeest herd as it crosses
the river.  The crocodile predators most often take the weak ones from
the edge first.  Debian has for many years been defaulting to the
chroot configuration.  You have apparently been using the chroot
configuration.  Therefore I would continue.  I am myself using the
chroot configuration.  I would investigate why the init start of
postfix did not update the chroot properly.  But again I don't think
that is "the problem" you are currently experiencing.

> For systemd (funny: abandon all hope, ye who enter), I would hope that a
> 'disabled' service is not considered 'uninstalled' so that when I updated
> my certificates using "Let's Encrypt" it did not update the Postfix
> certificates.  But any automation is a very good way to screw-up...  Just
> like my update did.

By this I assume you are setting the postfix ssl configuration
variables smtpd_tls_key_file and smtpd_tls_cert_file to use your Let's
Encrypt obtained Domain Validation certificates?  That's fine.  I do
that too.  But note that SMTP STARTTLS as far as I know does not and
cannot not require certificate validation.  It's opportunistic only.

    http://www.postfix.org/TLS_README.html

By default Debian configures a self-signed certificate.  That's okay
too.  Likely not "the problem" you are currently experiencing.  For
debugging things the best reference is all of the good information here.

    http://www.postfix.org/DEBUG_README.html

However let me point you specifically to what I would do.  I see by
what you have shown so far this:

    Oct  9 05:35:05 ...: postfix/postqueue[...]: warning: Mail system is down -- accessing queue directly

So postfix is not running for some reason.  In that case start it.
Then look in the /var/log/syslog and /var/log/mail.log files for any
messages logged there.  Here is an example of what might be seen there
from a systemd system here, which should match your systemd machine there.

    rwp@madness:~$ sudo systemctl start postfix.service

    rwp@madness:~$ sudo tail /var/log/syslog
    Oct 13 14:26:30 madness systemd[1]: Starting Postfix Mail Transport Agent (instance -)...
    Oct 13 14:26:30 madness postfix/postfix-script[17085]: warning: symlink leaves directory: /etc/postfix/./makedefs.out
    Oct 13 14:26:30 madness postfix/postfix-script[17123]: starting the Postfix mail system
    Oct 13 14:26:30 madness postfix/master[17125]: daemon started -- version 3.4.14, configuration /etc/postfix
    Oct 13 14:26:30 madness systemd[1]: Started Postfix Mail Transport Agent (instance -).
    Oct 13 14:26:30 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:26:30 madness systemd[1]: Started Postfix Mail Transport Agent.

It would be expected that if there is a problem that there would be an
error message logged in that file at that location.  I will create an
error for the example.

    Oct 13 14:31:13 madness systemd[1]: Starting Postfix Mail Transport Agent (instance -)...
    Oct 13 14:31:13 madness configure-instance.sh[17675]: postconf: fatal: /etc/postfix/main.cf, line 46: missing '=' after attribute name: "errorinconfigurationfilehereplacedbyrwpasanexample"
    Oct 13 14:31:14 madness configure-instance.sh[17675]: postconf: fatal: /etc/postfix/main.cf, line 46: missing '=' after attribute name: "errorinconfigurationfilehereplacedbyrwpasanexample"
    Oct 13 14:31:15 madness systemd[1]: [hidden email]: Control process exited, code=exited, status=1/FAILURE
    Oct 13 14:31:15 madness systemd[1]: [hidden email]: Failed with result 'exit-code'.
    Oct 13 14:31:15 madness systemd[1]: Failed to start Postfix Mail Transport Agent (instance -).
    Oct 13 14:31:15 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:31:15 madness systemd[1]: Started Postfix Mail Transport Agent.

Note that systemctl status shows nothing of use here.  We need the
logfile for that information.

    rwp@madness:~$ sudo systemctl status postfix.service
    * postfix.service - Postfix Mail Transport Agent
       Loaded: loaded (/lib/systemd/system/postfix.service; enabled; vendor preset: enabled)
       Active: active (exited) since Tue 2020-10-13 14:31:15 MDT; 1min 29s ago
      Process: 17680 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
     Main PID: 17680 (code=exited, status=0/SUCCESS)

    Oct 13 14:31:15 madness systemd[1]: Starting Postfix Mail Transport Agent...
    Oct 13 14:31:15 madness systemd[1]: Started Postfix Mail Transport Agent.

Again this is simply an example that I created to show the type of
thing that might be seen as an error in the log file.

What's in your log file?

Good luck! :-)

Bob
Reply | Threaded
Open this post in threaded view
|

Re: PostFix not working after update

Jaroslaw Rafa
Dnia 14.10.2020 o godz. 08:36:49 Paul Lauzon pisze:
>       Oct  9 05:35:04 ...: warning: /var/spool/postfix/etc/ssl/certs/ca-certificates.crt and /etc/ssl/certs/ca-certificates.crt differ
>       Oct  9 05:35:05 ...: warning: /var/spool/postfix/lib/i386-linux-gnu/libnss_systemd.so.2 and /lib/i386-linux-gnu/libnss_systemd.so.2 differ

From just a quick look, I would be worried about these. Please examine why
is this and try to fix the issue.
--
Regards,
   Jaroslaw Rafa
   [hidden email]
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."