22013-01-21 08:45:46ClintonEbadiperhaps what some firewall rules would look like12013-01-21 08:34:07ClintonEbadiit turns out that I am actually going to write new domtool container types god help meThe system described below does not yet exist and is only in the earliest planning stages. See FirewallRules for how we manage firewalls today.

The current FirewallRules system is a pretty thin abstraction over ferm, and has an ad-hoc parser with a number of built in limitations. Even after only having a dozen or so rules, it is becoming clear that managing firewall rules will quickly become burdensome both for members and admins. Based on current patterns of requests, there a few things to consider: We need a way to define groups of rules that members can trivially request default ports for shell user (http, vcs software, mail, ssh, ...) common rules for certain cgi applications or special uses (e.g. wordpress always needs to contact wordpress.org for full functionality) Don't want to tie configuration to physical nodes (e.g. moving to a new shell server) Restrict users to having rules on certain nodes (statically enforced) Members should be able to grant themselves "safe" rules without any admin intervention allowing members to grant themselves safely marked rule groups seems like a good start A few wish list considerations: Want to store per-node firewall config for system services (apache, exim, imap, etc.) Ideally, also store common port config (afs, kerberos, domtool, etc.) Conclusion: the current fwtool implementation would require duplicating a lot of functionality already present in the support machinery for the domtool domain type. A new syntax for user rule files would need to be created (or tons of hackish supporting code) so ... The only (in)sane way forward is to create a domtool container for firewalls to manage rules. This has distinct advantages: Takes advantage of current domtool infrastructure for pushing configs The domtool language is quite nice and has the needed functionality for abstracting groups of users, common config, etc. Lays the groundwork for using domtool to perform node management in addition to domain management

My current thinking, expressed in pseudo-domtool @sig@ CategorySystemAdministration CategoryWorkInProgress