Comment 10 for bug 728128
Revision history for this message
| Mike Pontillo (mpontillo) wrote Re: ufw user.rules should be stored in /etc to allow tracking by package 'etckeeper' | #10 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
Sorry for the bug mail spam, but I've been poking at the ufw source and thinking about it some more, and I just can't let this go. =)
Perhaps the *real* bug is that there is not a clean separation between configuration and state date. Ideally, a .conf file in /etc would look somewhat (exactly?) like what you would type on the command line to generate the firewall rules. (I won't name names, but I've seen many commercial firewalls that do it this way.)
The "state", then, could be regenerated from the configuration, and would correspond to what ufw expects to be installed in iptables, or what it *would* expect to be installed if it were active. Sure, you can install it in early boot, if required (for example, if you don't yet have python available), but it should be regenerated later in the boot process, and the state should be updated if it's out of sync with the configuration.
Since ufw doesn't have an intermediate configuration layer right now, its state is also its de facto configuration. This thread is full of examples of machine-generated "DO NOT EDIT" files in /etc, but I'd add the argument that de facto configuration files are still configuration files, even if they're [nearly] impossible to hand edit. (see sendmail.cf, for example - the supported way to edit it is to use m4!) Ideally ufw should move from de facto configuration to explicit configuration.
Here's another example use case: it should be easy to take a set of firewall rules, clearly spelled out in a configuration file, and copy/paste those rules - possibly with minor edits - to another system. Unless I'm mistaken, right now the only way to do that with 'ufw' is to manually interpret the output of the 'ufw status'.