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. 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? 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@ Rule listing could be a bit flexibly when just a plain set name is given, showing per table or global sets as they exist. Just some thoughts I have on the issue, looking from the outside. Use as you see fit :) best regards Patrick -- 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
