On 27 February 2014 15:02, Patrick McHardy <kaber@xxxxxxxxx> wrote: > On Thu, Feb 27, 2014 at 01:15:36PM +0100, Arturo Borrero Gonzalez wrote: >> Hi there! >> >> I can't remember this subject being discussed in the near past. >> >> Why not using system-wide sets? Or at least, family-wide sets? >> >> >From the user point of view, I think is very interesting to define >> sets that can be used in rules all across the ruleset, same set in >> different tables and families. > > 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? idea 1: print global sets when listing every time a table is listed. To backup the ruleset, the user must iterate over the list of tables/AF (nft list table $AF $TABLE), so the global sets get printed several times. when restoring, try to add the global set to the kernel. If the set already exist, return EEXIST from the kernel, and let nft ignore that if operating with 'nft -f'. idea 2: add `nft list ruleset', which prints all tables in all AF, including global sets. Global sets are only printed in this 'ruleset' view. Still, the ignore EEXIST errors from the kernel for globals sets. > >> Being family-wide is what ipset does, and I'm sure is what most people >> will expect. >> >> On the other hand, I understand this would be a major change at this point. > > Should be fine. I'm thinking of keeping the table specific sets and also > having per AF and AF_UNSPEC sets. For maps we should restrict this feature > to data maps since verdicts may need a table context. I agree. -- Arturo Borrero González -- 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
