On Mon, Mar 03, 2014 at 11:32:14AM +0100, Patrick Schaaf wrote: > On Thursday 27 February 2014 14:02:30 Patrick McHardy wrote: > > > Yeah, I agree. I think family wide sets and global (AF_UNSPEC) sets should > > bet quite easy to add. However there's the question how to expose them > > in the nft list table output. The idea is to be able to recreate the > > current ruleset, including sets and elements, by parsing the output of > > nft list table. If we don't include sets, the user will have to seperately > > save and restore them. OTOH if we simply include global and AF-specific > > sets, they will be restored once for each table and this will fail on > > the second table. > > > > Any other ideas? > > First of all I'd like to note that this needs-separate-saving, is exactly the > situation we have right now with ipset, so it is not something totally > unknown. Recreating a table that references nonexisting global sets, would > fail, just like loading / restoring iptables rules that reference nonexisting > ipsets, fails right now. Right, but it makes atomic replacements of the ruleset either asymetrical to saving them or simply impossible. Sets are considered a part of the rulset. > Alternatively - but I'm not sure how good an idea that would be - couldn't > such nonexisting set references somehow create "forward declarations" to > permit loading in any order, and threat as-yet-undefined sets as empty? That would mean any typo in set names would create an empty set instead of an error. I don't think this is a good idea. > An additional issue that I imagine we'd have, is set names clashing between > global and per-table sets. To this end, maybe it would be useful to have a > syntactic means to differentiate the two cases when referencing sets. Maybe > append a second '@' to reference global sets? > > nfd add rule ip input ip saddr @sharedset@ The alternative would be scoping, we need to look up in multiple scopes anyways. AF-specific overrides global. > Rule listing could be a bit flexibly when just a plain set name is given, > showing per table or global sets as they exist. Yeah, that definitely makes sense, we don't want to dump all global sets if they're not even used within a table. Actually even easier would be to not show them at all outside of the AF_UNSPEC family and require the user to restore in the correct order when using global sets. We do support file inclusions etc. that make this easy to handle. A full dump (all AFs) would simply begin with AF_UNSPEC and be restorable without any manual intervention. > Just some thoughts I have on the issue, looking from the outside. Use as you > see fit :) Thanks. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
