On Sat, Jun 20, 2026 at 01:07:29PM +0000, David Härdeman wrote:
June 19, 2026 at 9:59 PM, "Marc Haber" <[email protected]
mailto:[email protected]?to=%22Marc%20Haber%22%20%3Cmh%2Bdebian-packages%40zugschlus.de%3E
> wrote:
On Tue, Jun 09, 2026 at 02:31:32AM +0000, David Härdeman wrote:
[Unit]
Description=Early firewall configuration with ferm
Documentation=man:ferm(1)
Before=network-pre.target
Wants=network-pre.target
After=local-fs.target
ConditionFileIsExecutable=/usr/sbin/ferm
ConditionPathExists=/etc/ferm/ferm.conf
I am not sure whether After=local-fs.target is needed. According to
bootup(7) that comes _before_ sysinit.target and all services depend on
that. I think that is redundant.
I'm not at home, so can't check right now, but if I remember correctly,
my thinking was that we might want:
DefaultDependencies=no
That also breaks a lot of implicit dependencies on startup, for example
the sysinit dependency that we need here. I am not too fond of that
idea, but ...
To e.g. prevent the firewall from being torn down on shutdown.
... that is an aspect that I didn't cover i my thoughts before.
ExecStart=-/bin/sh -c '/usr/libexec/ferm/ferm-systemd activate && touch
/run/ferm-early-success'
Is that any different than having the touch in an ExecStartPost?
Yeah, the "=-" means "ignore failure", but we only want the touch to run
on success. With ExecStartPost I think the touch would always be executed.
Docs say: ExecStartPost= commands are only run after the commands
specified in ExecStart= have been invoked successfully
So you would recommend to use the same rule set and just come up with
the rule set in some degraded form if it needs network?
Yeah, my draft approach would mean one rule set.
I agree with what you said earlier in the bug report - (i.e. I'd recommend
that people don't specify firewall rules with hostnames at all). But if
they insist, this means that the firewall rules will at least be loaded
(just later).
You have a point here, my gut feeling still says that people are going
to yell at me because I left their system unprotected for a few seconds.
# Execute wrapper
ExecCondition=/bin/sh -c 'if [ -f /run/ferm-early-success ]; then rm -f
/run/ferm-early-success; exit 1; else exit 0; fi'
What is the rationale behind this?
I means that "ferm.service" won't do anything the first time it's executed
(i.e. during boot) if "ferm-early.service" was successful. And after the
first time "ferm.service" has been started, it'll behave like a normal
systemd .service (so admins that change rules can do e.g. "systemctl
restart ferm", and it'll work as expected).
I see.
The advantage is that there's no need to define two distinct rule sets.
The early rule set is rather simply spelled out, I think.
My gut feeling prefers a real two-step approach with two distinct rule
sets.
Conceptually cleaner, but the question is how many people would be willing
to rewrite their firewall config for that (especially given that ferm seems
to be kind of EOL; personally I still have the long-term goal to transition
to "pure" NFT).
That's as well my long-term goal. Sadly nft sucks when it comes to
dual stack networking.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
