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]: postfix@-.service: Control process
exited, code=exited, status=1/FAILURE
Oct 13 14:31:15 madness systemd[1]: postfix@-.service: 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
