Hey Gustavo, Please excuse the delay in replying; apparently I didn't get the email.
> I don't think users expect the behaviour of `netfilter-persistent start` > to change from "reset all rules to a known state" to > "add known rules on top of what's running", in my use case at least I > relay/trust that netfilter-persistent will clean any manually added > rules. Agree. The patch provides an option to do that, but not by default (no change). Some users/scenarios would benefit from it (below.) > What's the usercase you have in mind? I think the feature is useful but > I'd not change the defaults for the start action, I'm open to add a new > action (start-no-flush?) or include the patch but change the defaults > to "no" The use case is better interoperability with ufw, as iptables-persistent runs later in the boot process, and flushes ufw's rules, so ufw status shows inactive/disabled (can't find its rules) even if it's correctly setup. This is an issue for ufw users in some Ubuntu cloud images/providers, where iptables-persistent ships pre-configured platform/vendor rules (e.g., rootfs's iSCSI server), and users run ufw for their firewall rules. In that case, having the new option (not flushing existing rules) would allow both tools to coexist, each one with their own/different purpose. Since the changes are gated by a non-default option, and would need a manual switch (or preconfiguration during the image build process), hopefully that's not too much of an inconvenience, and still might help where needed. Would that be OK? cheers, -- Mauricio Faria de Oliveira
