On Sun, Jun 25, 2023 at 05:27:04PM +0100, Jonathan Wiltshire wrote:
> Maybe I missed something important, but this seems a very odd way of doing
> things. Do you really set up a dummy service unit which is expected to fail
> in standalone mode, and therefore starts the socket instead?
>
> Why not use an ExecStartPre= or ExecCondition= in your normal units to
> prevent starting when in inetd mode?
>
Unfortunately, Exec* directives can only be used in .service units.
This statement is at odds with the documentation for systemd.socket(5).
I meant ExecCondition (see https://github.com/systemd/systemd/issues/14012),
but indeed there is not way to by-pass the socket opening within a
socket unit. Once enabled, the ftp socket is under systemd control, the
only way to prevent that is by using ConditionPathExists AFAIK.
That's
the reason to enable an external oneshot .service unit to start
alternatively one of the two other units. Ideally one day or another such
features could
be available also in other type of units (there is an issue open since
2019). Incidentally, it is possible to add a ConditionPathExists and a
something like /etc/proftpd/proftpd_not_to_be_run (which is the trick used
in sshd) but would be completely Debian specific and out of the usual
workflow to manage inetd/standalone modes in proftpd. So, I'm not that keen
on
this kind of trick.
I don't think a ConditionPathExists hack is necessary here. Yes, in the
standalone case you will end up with the socket unit failing, and the local
admin will have to disable that if it annoys them, but any competent
administrator should be able to figure that out with the help of
NEWS.Debian.
Ok, I did my homework again and found that the best thing to do seems removing
the
proftpd-run.service and enabling the proftpd.service only at installation time.
That would allow proftpd working flawlessly at least for new installation on bookworm
and even upgrades from bullseye to p-u.
Unfortunately, an upgrade from -4 would not fix the situation, which should
be fixed by the admin in any case, by simply disabling proftpd.socket by hand.
But for annotating this thing in NEWS, I can't see any other details to have care.
If you (RMs) like this plan, I would submit one more debdiff with the proposed
changes
and wait for a final approvement, if possible.
--
Francesco P. Lovergine
