10.12.2024 00:46, Wietse Venema via Postfix-users wrote:
The prob here is that it isn't trivial at all to set up the
chroot environment, despite all the efforts to solve this so
far. Many things can be simplified greatly by using proxy
maps for example, and that probably will be the way I'll
recommend to use instead of copying all sorts of random stuff
into chroot, regardless if it's needed there or not, or even
if it helps there or not.
You could mount read-only,no-execute the dependencies under
/var/spool/postfix. Oh wait, systemd builds a symlink web of hell;
/etc/resolv.conf is no longer a file but a symlink info the void.
Good luck with duplicating that.
It's lovely you mention this. Very interesting.
2 points.
1. The deps which are required within chroot - they're just too
numerous. All sorts of various stuff from /etc and /lib.
SSL certs for STARTTLS. All cyrus and openssl stuff. Various
libnss modules, /etc/services /etc/host.conf etc (some are
for glibc). A *lot* of stuff. The prob with that is that
each basically needs its own mount.
And mounts wont actually help, since individual files gets
created anew and renamed to place, leaving the mount pointing
back to the old file.
2. over the years, we've had issues with resolv.conf when it
was NOT managed by systemd. All bug reports in debian BTS
is about ifup scripts not run at proper time, or not run
at all or updating an incomplete resolv.conf or all sorts
of things.
When this file is managed by systemd, I know exactly what to
do with it, it is rather trivial (it should be done for all
instances though).
It's strange you said systemd builds symlink web of hell.
It redirected a few (maybe just one) runtime-info file from
/etc to /run - this way, /etc can be read-only (I used RO
/etc for years before systemd). I know no other usages of
symlinks by systemd.
Maybe it's about links in /etc/systemd/system/ and various
service.wants.d and such - but these aren't actually used
as symlinks. Systemd itself uses just symlink *name* to
find which units to deal with. The symlink target is just
for the user to better see which unit it is. The only
recognized target is /dev/null to disable something.
Where systemd has "web of hell" is entirely different place
though: it has numerous directories where unit files are
kept. It is exactly like $PATH. So it's not always
easy to find where a given unit is actually defined,
without tools (like `type' or `command' but systemd-specific).
Sometimes I really wonder where these myths come from :)
I'm NOT a systemd advocate. I use it and I like abilities
and simplicity it brings, and I see why it's worth to actually
use its abilities when it is available. I run systems with
traditional sysvinit too, and I love it as well, for different
properties and reasons. But some things people tell about
systemd are just.. well, I've no idea where they're coming.
If you want symlink web of hell, look at /sys filesystem
in linux. *That* be a real one. And start from the
traditional /etc/mtab which has become symlink to /proc/mounts,
which, in turn, has become symlink to /proc/self/mounts.
Way before systemd.
Thanks,
/mjt
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
