New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config: ensure SASL socket file is not inside a volume mount #3131
Conversation
And drop redundant repetition of default value in `master.cf`.
The `user-patches.sh` was not very robust, hence I adopted the solution @polarathene proposed by adding a dedicated file in Dovecot's configuration for the LMTP service.
This commit also includes the removal of files as mentioned in #3118 (see #3116 (comment)). This is a cleanup measure. The old socket file is the primary focus of this commit (and its assocated PR), but I figured this would be _the_ chance to incorporate the removal of the other, unneeded files in order to not open yet another PR.
What even is this: not ok 85 [General] system: postfix should not log to syslog in 123ms
# (from function `assert_failure' in file test/test_helper/bats-assert/src/assert_failure.bash, line 66,
# in test file test/tests/serial/tests.bats, line 208)
# `assert_failure' failed
#
# -- command succeeded, but it was expected to fail --
# output : Feb 28 14:51:12 mail rsyslogd: cannot create '/var/spool/postfix/dev/log': No such file or directory [v8.2102.0 try https://www.rsyslog.com/e/2176 ]
# --
# Can somebody please tell me what's happening here? 🤣 🤣 🤣 Why, if Postfix does not log to syslog, is syslog still trying to create |
This reminds me that I forgot to look into an extra change for dropping the There is some Postfix docs about configuring for
So it's possibly due to EDIT: And here it is: $ cat /etc/rsyslog.d/postfix.conf
# Create an additional socket in postfix's chroot in order not to break
# mail logging when rsyslog is restarted. If the directory is missing,
# rsyslog will silently skip creating the socket.
$AddUnixListenSocket /var/spool/postfix/dev/log And here is the Postfix docs I recalled for adjusting the logs. AFAIK, we'd want to set This would just require the following:
Should I raise a separate PR for that, or do you want to bundle those changes into this PR? There are some limitations cited in those Postfix logging docs. Not entirely clear if syslog is still relevant there. I think we'd be okay, but another set of eyes going over those limitations might be good 👍 |
Since I can review quickly, and only 1 review is required ATM, please raise another PR :) The removal of the syslog config file for postfix that you proposed to do in the Dockerfile, if you can also do that in the scripts, I'd do it in the scripts :) |
Done, feel free to merge after approving 👍 EDIT: Oh awesome.. failing tests, should have expected that 😂 I'll look into resolving them. |
Forgive me, I haven't read in detail the initial bug report. I was wondering if the other sockets that are also volume mounted are also problematic: Details
|
Are all those postfix files sockets? I wasn't sure why they seemed to be empty when I saw them. All I know is they're various programs that Postfix uses to run (bulk are configured in I know they're added in a fresh image without a volume mounted, but I didn't investigate if they were created as part of the package install or from Postfix service being started. I think it's the latter due to this being the
AFAIK, something caused a users permissions for the socket to change from the configured Correcting the user and group assigned to the socket should resolve the main issue. The new socket location is likely not necessary, just following the same workaround that was used for supervisor (Sep 2017, a time when the Docker bug was likely on systems with old enough kernels). |
Yes (
In detail, Podman rootless? Not going to block this PR, just curious about this, because afaik we didn't include patches for "not supported" stuff in the past? |
EDIT: Whoops, forgot to read the test content that it failed with 😝
Revised the PR to handle that. Alright, I have since learned that
Presently this is what
NOTE: Github Actions service was acting up, I went to inspect the error logs, and got an error about the workflow run logs not being available anymore, so re-ran the test, and now it's only run the lint test instead of the test suite, hence the PR status of "All checks passed" 😅 (hence the tests will still fail) This still seems to be having issues, so will need to wait to re-run tests again. |
There is no confirmation yet that
Socket files could instead live at The reports from users experiencing issues related to sockets AFAIK is specific to this Dovecot created auth socket and a lack of permissions for Postfix (and Dovecot in some cases IIRC) from accessing it. It's highly likely it was just related to bad config on our end with the ownership. |
So what do we want to do now? (in one sentence please). Move all sockets to |
No action, leave as-is with
This PR does not need to worry about that.
|
I have no idea at the moment. Just mentioned it, while I stumbled upon it. |
I would stick with "standards", so yes. I am not sure if switching to using a tmpfs could not introduce other issues in the future 🤷 However, there is no urgent need. We can do it later. |
Co-authored-by: Casper <casperklein@users.noreply.github.com>
Auto-merge is on, just FYI :) |
AFAIK, they need to reside in I'm not sure why the socket files are created in the We could handle it as a special-case I guess, here's two approaches to symlink subdirs and avoid some.
v13 could look at changing that to
df -h
Filesystem Size Used Avail Use% Mounted on
overlay 120G 115G 5.1G 96% /
tmpfs 64M 0 64M 0% /dev
shm 64M 0 64M 0% /dev/shm
/dev/mapper/ventoy2 120G 115G 5.1G 96% /etc/hosts
tmpfs 16G 0 16G 0% /proc/asound
tmpfs 16G 0 16G 0% /proc/acpi
tmpfs 16G 0 16G 0% /proc/scsi
tmpfs 16G 0 16G 0% /sys/firmware
|
👍
Sure. I once had a problem with /dev/shm, but can't remember exactly atm what that was 😞 |
My memory returned 😆 Back then I could not execute files in
|
Description
Change the SASL auth socket path. The SASL socket was on a path that would end up getting volume mounted (
/var/mail-state
) in some setups, this could cause issues. The socket is not actually state, so it doesn't need to end up there.Fixes #3110
Superseeds #3125
Type of change
Checklist:
docs/
)