On Thu, 2012-12-20 at 13:00 +0100, Jozsef Kadlecsik wrote: > No, "ipset restore" is not identical with iptables-restore. For example > with the latter you are not able to incrementally update existing > rulesets. Well incrementally updating would also mean removing entries that are no longer existing.... otherwise it's only making a union. And as I said before... anyone who wants to do this can easily sed "s/^/ipset //" | sh > Nothing prevents you to write a few liner in any scripting language, which > either adds a "flush" command or wraps "create, add" into "create temp, > add to temp, swap, destroy temp". Of course one can do this and actually I'm doing right now... but it's quite unhandy if anybody has to do this just to get a proper restore. And when doing it "proper" it's not just a one liner... it has to work with different names for the actions like create, creat, crea, etc. and one always risks to break things (and even get security issues by that) when the syntax of ipset should change or be extended. With temp names there's the issue, that (I guess) there is a maximum name for set names, so one cannot just add all new sets as tmp_<originalname> as this might already fail Last but not least, while this allows atomic swaps of single set... one cannot swap the whole ipset configuration in one atomic step. ipset's current restore should actually be called exec, or merge, or load... btw: I might have noticed a bug(?) in at least 6.11 With the following output of store: # ipset list | grep ^Name I'd have expected to get the same sets with list -names but it gives me one twice: # ipset list -name lrz_lcg_se_cn lrz_lcg_se_pn lrz_lcg_ce_cn lrz_lcg_ce_compn lrz_lcg_ce_compn lrz_lcg_se lrz_lcg_ce DROPPED Is that expected? Thanks, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
