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 <b...@proulx.com> 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 >
