Hi, I'm facing an issue on a ephemeral machine booted into a read-only nfs4 root with an overlayfs to make / writable. postfix doesn't start, since the copy command in configure-instance:91 fails. It copies the data, but overlayfs has an long-standing issue with nfs4_acls [1], which cp -p will try to copy but fail. The files are thus copied over and on the next start of postfix, the service will start without any issues (complaing again about the same problem for copying the libraries in Line 109, which is ignored though by the trailing || : in this line. Is there a specific reason to copy these files with -p? From what I can tell, they're all word-readable and owned by root:root, so maybe preserving timestamps (if that is intended) would be enough? From the commit introducing -p [2], It seems like this was done to have more readable code. That would solve this issue for this specific scenario without interfering with other installations as far as I can tell. I acknowledge that this should ideally be fixed in overlayfs for a general solution, but in hope of getting a faster solution, I wanted to ask if you'd consider changing the cp options. Best, Cornelius Hoffmann [1] https://lore.kernel.org/linux-fsdevel/CAJfpeguwUtRWRGmNmimNp-FXzWqMCCQMb24iWPu0w_J0_rOnnw@mail.gmail.com/ [2] https://salsa.debian.org/postfix-team/postfix-dev/-/commit/ca82392182402ab7de571346d27345e6644952d2
11.03.2025 14:54, Cornelius Hoffmann wrote:
Why it fails? From the cp(1) manpage:
-p same as --preserve=mode,ownership,timestamps
This list looked innocent enough to keep everything. Which ACLs it tries
to copy here? It shouldn't?
It's an interesting idea, I definitely see your intention here, and
definitely sympathize. Yet, I'd love to understand what's going on
here, if not only for documentation purposes. Current solution seems
to be the best one..
Thanks,
/mjt
Sorry, for some reason it seems our mail server filtered out the reply to this issue. On Sun, 16 Mar 2025 07:44:42 +0300 Michael Tokarev <mjt@tls.msk.ru> wrote: > > I'm facing an issue on a ephemeral machine booted into a read-only nfs4 > > root with an overlayfs to make / writable. postfix doesn't start, since > > the copy command in configure-instance:91 fails. It copies the data, but > > overlayfs has an long-standing issue with nfs4_acls [1], which cp -p will > > try to copy but fail. > > Why it fails? From the cp(1) manpage: > > -p same as --preserve=mode,ownership,timestamps > > This list looked innocent enough to keep everything. Which ACLs it tries > to copy here? It shouldn't? > > --preserve[=ATTR_LIST] > preserve the specified attributes (default: mode,ownership,time‐ > stamps), if possible additional attributes: context, links, > xattr, all > > Even with --preserve (with no argument, which is different from -p), it > *tries* to preserve additional attributes only "if possible". > > I'm confused. Mode, ownership and timestamp has always been copied by > this code (it used cpio in the past). Maybe cp(1) does more than what's > described, - in which case it definitely should be fixed one way (by > removing extra actions it does) or another (fixing the docs to match > reality). The manpage (compare https://manpages.debian.org/testing/coreutils/cp.1.en.html) actually mentions > ATTR_LIST is a comma-separated list of attributes. Attributes are 'mode' for permissions (including any ACL and xattr permissions), So it is expected that ACLs, including NFSv4 ACLs are copied when using --preserve=mode. The command also works, it does everything it can copy, but exits with error code 1 and then the shell script exits right there (since -e is set in the shebang) and thus the service startup also fails. Before, the command just used plain cp without any extra arguments, see https://salsa.debian.org/postfix-team/postfix-dev/-/blame/8fc13ff2a05c5fc3cad87809efe87611804845b0/debian/configure-instance.sh?page=1#L125 This behaviour was changed in ca823921 as mentioned above. My current "workaround" is to copy all these files manually first with the same options, but ignore failures before the service starts. cp will then not attempt to copy the ACLs (for some reason).
Hi, Thanks for all the work you put into postfix in the last months! a few systems from bookworm to trixie. One case was /etc/services having the mtime from packaging, while /var/spool/postfix/etc/services having one from today (despite containing the contents from bookworm). Another one is from systems where /etc/localtime is set by a script right after postfix check is called (mtimes/ctimes/btimes are identical, despite /etc/localtime being "newer"). I created a merge request in salsa to drop the -u option: https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/48 and think that dropping `-u` here makes sense. Best Regards, Stoiko Ivanov
Hi! I don't really want to drop `-u' from here. The same problem exists when updating ssl certs for example, - and re-creating all the files every time seems like a wrong idea. See also #1110704 for exactly the same issue. Instead, I created a poor-man cp(1) replacement in perl, which addresses 3rd issue - it does copy+rename instead of truncate+copy, so that the files are created atomically. Another tool which does it is rsync, but I don't want to depend on rsync here. I felt such tool was needed, but I was lazy to write one. I plan to perform an update to postfix package in the next trixie point release. Thanks, /mjt
See https://salsa.debian.org/postfix-team/postfix-dev/-/commit/d4e1171ae6a79d36e7121bb0698eef3bd3f2498b for the solution I plan to use. There are 2 bugs filed about this issue, #1110704 and #1100100. Thanks, /mjt
We believe that the bug you reported is fixed in the latest version of
postfix, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1100100@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated postfix package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 13 Aug 2025 14:29:46 +0300
Source: postfix
Architecture: source
Version: 3.10.3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Postfix Team <team+postfix@tracker.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 1100100 1110704
Changes:
postfix (3.10.3-3) unstable; urgency=medium
.
* configure-instance.in: fix typo
* configure-instance.in: limit maxdepth=1 in /etc/ssl/certs dirs
* configure-instance.in: use home-grown file copy procedure to sync chroot
There are a few issues with using cp(1) to update files in chroot, -
a file should be copied even if the source date is *less* than the
target date (eg, if a package has been downgraded), which is not done
by `cp -u` (#1110704), a file should be copied atomically (copy+rename,
not truncate+copy), and care should be taken with extra attributes
(#1100100). Use a simple perl-based script (using just perl-base)
to update files instead, which fixes all this stuff.
(Closes: #1100100, #1110704)
Checksums-Sha1:
c26c38db4886933d218bfa39954df57bf285004b 3161 postfix_3.10.3-3.dsc
ac27fa96c007f06a66a67bb49ea4ecb406197359 198636 postfix_3.10.3-3.debian.tar.xz
a782b3d05177bc7b3724575acee66d1ebc8b7146 5840 postfix_3.10.3-3_source.buildinfo
Checksums-Sha256:
cea9db9021a69ff7d87dd843cd08ecf284f1d9aaa32bfc31eabd435d3d98617c 3161 postfix_3.10.3-3.dsc
63c38dab6f483cefa1508160a8ade03c0b4c1a1a12d85451d5ac9acafdc15f77 198636 postfix_3.10.3-3.debian.tar.xz
e3be649bd2f2e5cc952a4275fc44a6744a27ec76a8dced34ced1aa15ff632056 5840 postfix_3.10.3-3_source.buildinfo
Files:
4eb2698a79c568e0d5fbc9542ebe9b0a 3161 mail optional postfix_3.10.3-3.dsc
5b6f572de81eacc9a8fd988e9e9ecec1 198636 mail optional postfix_3.10.3-3.debian.tar.xz
bf8e473e61bebd6e8f36234ea67d936e 5840 mail optional postfix_3.10.3-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmicd04ACgkQgqpKJDse
lHhnOhAAuZI/EoyDWI7btJ0SWLXyN6WL4PJJ8OSFsZgeNYHUzIhuTP24VERtOlIi
wk4Z2WV/GMyDwK3NYUoYCdSmMWkJGu5m3mVwmia7mnlT4Ii3So6x2Udd+jw/HCCs
J9xXRfMsXe85m/TVnAXEoyM9pR+jjuEzievs3F1HQ3Zv9r1hrUyQDbZHbAnf69QB
XbqWpTQefxX274qIVvxZcJ5gSM85M5HL5aPpbZDYOgFRP7tScefpmCADDYD94139
KRz4TdFp3JfnyiiMUwj8GZnEoXGxrJsx8gnaX1YNoahdD00rnRN0u3wcy3D3PcFj
Cm1tqkTHDaszw3VvZalsnlFnyAfbNE4nnC5yIuhGtgpB11B3I1XMnSCN//0TKVLf
caefbSpvbAYIiv2tL4aiBYB6KE2GwNNj0gtt5TpeWf3FL9As+MV1LUKLYlqvWTiy
S785Cnu2KsuvMfobY+p9ySbvXHtV0+LwDSGh+1Kn5j+4KNbHA4V9ywOzwh5Us0Wu
hSVXR9r/ftWR2lmUBVHeorb1W5fP80enl0WGmEPgAsiNtECeIb3ll19pkTjHdIvl
LYDPZdR5qbWLEj2SAO5kh+H6PoyW+B7WzqLhI3FZrHmjiWimdRDr606Ylngf3PnX
H2Vi0SAb4mzeSNTO8PK3zWuYPx44TratjR1n2u2N3s2BEfZcaDM=
=aM1p
-----END PGP SIGNATURE-----
We believe that the bug you reported is fixed in the latest version of
postfix, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1100100@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Michael Tokarev <mjt@tls.msk.ru> (supplier of updated postfix package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 22 Aug 2025 09:51:46 +0300
Source: postfix
Architecture: source
Version: 3.10.4-1~deb13u1
Distribution: trixie
Urgency: medium
Maintainer: Debian Postfix Team <team+postfix@tracker.debian.org>
Changed-By: Michael Tokarev <mjt@tls.msk.ru>
Closes: 1100100 1110704
Changes:
postfix (3.10.4-1~deb13u1) trixie; urgency=medium
.
* New upstream stable/bugfix version 3.10.4, with a handful of fixes.
From the upstream release notes:
- Fixes for postscreen(8):
* Bugfix (defect introduced: Postfix 2.2, date 20050203): after
detecting a lookup table change, and after starting a new
postscreen process, the old postscreen process logged an ENOTSOCK
error while attempting to accept a connection on a socket that
it was no longer listening on. This error was introduced first
in the multi_server skeleton code, and was five years later
duplicated in the event_server skeleton that was created for
postscreen. Problem reported by Florian Piekert.
* Bugfix (defect introduced: Postfix 2.8, date 20101230):
after detecting a cache table change and before starting a new
postscreen process, the old postscreen process did not close the
postscreen_cache_map, and therefore kept an exclusive lock that
could prevent a new postscreen process from starting. Problem
reported by Florian Piekert.
- Fixes for tlsproxy(8):
* Bugfix (defect introduced: Postfix 3.7): incorrect backwards
compatible support for the legacy configuration parameters
tlsproxy_client_level and tlsproxy_client_policy. This
disabled the tlsproxy TLS client role when a legacy parameter
was set (instead of the newer tlsproxy_client_security_level
or tlsproxy_client_policy_maps). Reported by John Doe,
diagnosed by Viktor Dukhovni.
* Bugfix (defect introduced: Postfix 3.4): with the TLS client role
disabled by configuration, the tlsproxy daemon dereferenced a
null pointer while handling a tlsproxy client request. Reported by
John Doe.
- Reducing process churn: Postfix daemons no longer automatically
restart after a btree:, dbm:, hash:, lmdb:, or sdbm: table file
modification time change, when they opened that table for writing.
- Portability: deleted an <openssl/engine.h> build dependency,
because the feature is being removed from OpenSSL, and Postfix
no longer needs it.
- Cleanup: with "tls_required_enable = yes", the Postfix SMTP client
will no longer maintain TLSRPT statistics for messages that contain
a "TLS-Required: no" header. This can prevent TLSRPT notifications
for TLSRPT notifications.
- Bugfix (defect introduced: Postfix 3.6, date 20200710): Postfix TLS
client code logged "Untrusted TLS connection" (wrong) instead of
"Trusted TLS connection" (right), for a new or resumed TLS session,
when a server offered a trusted (valid PKI trust chain) certificate
that did not match the expected server name pattern. Fix by Viktor
Dukhovni.
* d/gbp.conf: debian-branch=debian/trixie
* configure-instance.in: fix typo
* configure-instance.in: limit maxdepth=1 in /etc/ssl/certs dirs
* configure-instance.in: use home-grown file copy procedure to sync chroot
There are a few issues with using cp(1) to update files in chroot, -
a file should be copied even if the source date is *less* than the
target date (eg, if a package has been downgraded), which is not done
by `cp -u` (#1110704), a file should be copied atomically (copy+rename,
not truncate+copy), and care should be taken with extra attributes
(#1100100). Use a simple perl-based script (using just perl-base)
to update files instead, which fixes all this stuff.
(Closes: #1100100, #1110704)
Checksums-Sha1:
c313b8d1e0c28d6f66d4a92f08a729742da2f0dc 3193 postfix_3.10.4-1~deb13u1.dsc
a6c4489bd7d0868ac0374e2b97b83fc9c2c2c2b9 5050100 postfix_3.10.4.orig.tar.gz
fe2532dfd80afa849c4655788c45787827f0c275 220 postfix_3.10.4.orig.tar.gz.asc
aeaca58181b5da49ae277347d1c7039145c1d220 199408 postfix_3.10.4-1~deb13u1.debian.tar.xz
340ebc36d1c1b3f1399ab0447decd3fe9dd58c02 5738 postfix_3.10.4-1~deb13u1_source.buildinfo
Checksums-Sha256:
03510c7dae7331b27669f6918e39129a570f71885b927d67fd10c90b8fcec30c 3193 postfix_3.10.4-1~deb13u1.dsc
cfb66861fe8f964787ddaeab15f3ca3e7ef3de730f97171afc4a5eca338ca444 5050100 postfix_3.10.4.orig.tar.gz
dd85a2d75a87e5e1d4cae8117b05aed56055b0c85e450e500d01e66017c5e302 220 postfix_3.10.4.orig.tar.gz.asc
1b5c780f721a5ae9efd941d29e940ddb75f2ef362bf9f7bdb4773ce15bfb2e2d 199408 postfix_3.10.4-1~deb13u1.debian.tar.xz
2ff6db19687f3df52dc763b03313d5368d1f5f822d2943a818645c24b6e05dce 5738 postfix_3.10.4-1~deb13u1_source.buildinfo
Files:
6bccc564cfd2e802b2c4a1ca009ddeaf 3193 mail optional postfix_3.10.4-1~deb13u1.dsc
c9f472fe0455eff7a8334479fb0f1154 5050100 mail optional postfix_3.10.4.orig.tar.gz
bc0e8eb3f4aa659c4819d9f35193894f 220 mail optional postfix_3.10.4.orig.tar.gz.asc
a52f5e68ef61263185baadb71b51fd80 199408 mail optional postfix_3.10.4-1~deb13u1.debian.tar.xz
6488c53934e00b75d4d6a072bf38bef3 5738 mail optional postfix_3.10.4-1~deb13u1_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmioFJoACgkQgqpKJDse
lHj62A/+IfvR4KeS54aLu/lOV/gd+ikfR7CJXx5h9M35gk1A0VcPLpy5yBWeAIr4
bUviIsY5gD9H+8I6pY2hBsIRibEkBLldYCxh2x2yXID1KnyHLFwGw6eakh0Vo6q5
K2UEHef5nYiN1RZ5nANeoil++DqDQrNXR9H64HH41xh83RAxrwHYdINgSf79GGTt
PZXSoAsr7Z7TB1jD4zot9t9845VVOUAFFBQxp1xOM8z9o9tvj7ntR1XRgKDSeML6
TgFo0hyNl6YJX72g/qTwOmR5Sj4+wCz1doOU90fUiV2R0k/PVU+4vqDkL6J3cX5B
+VuRdxRUKOevQ+XU6UqPK4IeOv4dVBdynogJ9WlBSKlq/E5K1aYSccwiV6LoHZNK
ASuwfqL48FVsY6BYp+YuGiW3x7uJdsAoVLrAKxSZS0/p24h2b0Db2hCTTDLhhKbr
CgtDa25nnML9dX96Lv/Vu8mZVbgpO71bYJU/fqBxCQtOUeL6fjre15f424vAH5Uo
HIS2GNSYa6QVPBLbAfml+TmpvWs8sbdra28+gAN+3oBx/tvm3K6Grsch/tXvo0GU
oD4GD0WFWQ6C56d/fhQipq8bI2SwQj2RlExQKlUE8MVC0U/mbBe4ZB+vQdklhTxV
EOTQg6oKN+tcohuAnwH2eyn1ar8mftZnv7fbmo3c4aRY/dQhbIs=
=2kHb
-----END PGP SIGNATURE-----