Problem
solo-provisioner-network-nft.service carries no ordering against the host's own firewall units:
DefaultDependencies=no
After=local-fs.target
Before=solo-provisioner-daemon.service
Two consequences.
1. Undefined ordering against loaders that flush. Stock /etc/nftables.conf starts with flush ruleset. If nftables.service is enabled, whether it runs before or after the weaver loader is unspecified — and if it runs after, both weaver tables are gone from the moment the node boots. ufw.service and firewalld.service have the same unconstrained relationship.
2. Rules can land after interfaces are up. The conventional idiom for a firewall unit is to order before network-pre.target (and Wants= it, so the target is pulled into the transaction) so no packet is ever processed without the ruleset loaded. The weaver loader does neither, leaving a window at boot in which the host has interfaces up and no host firewall.
There is also no install-time detection: nothing in the repo checks for an enabled nftables.service, ufw, firewalld, or netfilter-persistent, so an operator who has one of these configured gets no warning that it will fight the provisioner.
Proposed fix
Render the loader with the standard firewall-unit ordering:
DefaultDependencies=no
Wants=network-pre.target
Before=network-pre.target nftables.service ufw.service firewalld.service solo-provisioner-daemon.service
After=local-fs.target
and add a preflight check to block node install / kube cluster install that reports any enabled conflicting firewall manager, with resolution hints (disable and mask the unit, or accept that weaver state will need re-assertion).
Ordering only narrows the race — a later manual systemctl restart nftables still wipes the tables — so this is complementary to daemon-side re-assertion, not a replacement for it.
Acceptance
Problem
solo-provisioner-network-nft.servicecarries no ordering against the host's own firewall units:Two consequences.
1. Undefined ordering against loaders that flush. Stock
/etc/nftables.confstarts withflush ruleset. Ifnftables.serviceis enabled, whether it runs before or after the weaver loader is unspecified — and if it runs after, both weaver tables are gone from the moment the node boots.ufw.serviceandfirewalld.servicehave the same unconstrained relationship.2. Rules can land after interfaces are up. The conventional idiom for a firewall unit is to order before
network-pre.target(andWants=it, so the target is pulled into the transaction) so no packet is ever processed without the ruleset loaded. The weaver loader does neither, leaving a window at boot in which the host has interfaces up and no host firewall.There is also no install-time detection: nothing in the repo checks for an enabled
nftables.service,ufw,firewalld, ornetfilter-persistent, so an operator who has one of these configured gets no warning that it will fight the provisioner.Proposed fix
Render the loader with the standard firewall-unit ordering:
and add a preflight check to
block node install/kube cluster installthat reports any enabled conflicting firewall manager, with resolution hints (disable and mask the unit, or accept that weaver state will need re-assertion).Ordering only narrows the race — a later manual
systemctl restart nftablesstill wipes the tables — so this is complementary to daemon-side re-assertion, not a replacement for it.Acceptance
network-pre.targetand beforenftables.service/ufw.service/firewalld.service.nftables.serviceenabled leaves both weaver tables present.