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 To e.g. prevent the firewall from being torn down on shutdown. >> 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. >> And, more importantly: >> ExecStart=-/bin/sh -c '/usr/libexec/ferm/ferm-systemd activate && touch >> /run/ferm-early-success' >> >> The "=-" means this will be a best-effort attempt and won't >> error out on failure (like if hostnames have been used in the >> ferm scripts, not something I'd endorse, but I know there's >> people who have different opinions). >> > > 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). >> # 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). > Will ferm still establish a filter when a name lookup fails? I THINK it > may error out itself and not establish anything? Yeah, when name lookup fails, ferm will (IIRC) just error out. That's the trade-off. If the rules contain hostnames, the firewall will only come up after the network is up and name resolution works (but I'd argue that people using hostnames in their rules have kind of opted into that behaviour). The advantage is that there's no need to define two distinct rule sets. > 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). Cheers, David
