On Thu, 2012-12-20 at 00:24 +0100, Jozsef Kadlecsik wrote: > > restore is even documented in the ipset manpage to do what e.g. iptables > > restore does... getting the session back... but it doesn't. > > I think that should definitely be documented better. > Restore executes the commands specified in the saved session file. If the > current state is not appropriate for the commands (set already exist, > etc.), then it'll fail. I'll add this to the manpage. The manpage says: Restore a saved session generated by save. The save session can be fed from stdin. From this I personally would expect the same behaviour as what I get from iptables-restore,... which includes e.g. "deleting" no longer used entries. > > Well if you have long running systems and sets get unused one probably > > want's to release their memory. > But then why do you want to restore them, if those sets are unused? Uhm? I don't want to restore them... I have a set file, which get's changed in some way... e.g. new sets and entries added,... some sets and entries removed. Then I distribute this file across the cluster and want to have it loaded. > > btw: "ipset destroy" fails if a single set still contains entries... > That's not true. Maybe you mix "set contains entries" with "set used in a > rule"? Yes and now ;) ... at least when with rule you mean an iptables rules I have ipsets that are not used in any iptables rules at all. But the some sets have References, because they are included in another of type list:set . So none of the sets is really used by iptables, and I'd expect I could destroy them. But then it says: "Set cannot be destroyed: it is in use by a kernel component" (which is obviously ipsets itself). Of course when first doing a flush... it succeeds as you say, because all list:set sets are emptied. > > wouldn't it be better if all empty sets are destroyed and it only fails > > on those which are not? > I don't understand your sentence at all... In the above case I had e.g. setA of type list:set containing (setB and setC). setB of type bitmap:ip containing nothing setC of type bitmap:ip containing nothing setD of type bitmap:ip containing nothing (non of them used anyhow in iptables rules) If I know call ipset destroy,.. it fails with the aforementioned error... and all sets exist as before, while at least setA and setD could have been destroyed as they is nowhere used. > > > If the sets are in use then you cannot delete > > > them at all. > > I understand that this might be necessary from a technical point of > > view,.. but wouldn't it be simply possible to consider non-existing sets > > to be empty sets? > Non-existing sets are ... non-existent. What I meant is: Ideally it shouldn't be impossible to delete a set that is in use by iptables rules... such a set could be "deleted" and the iptables set match and target should simply consider such a set to be empty and neither fill it with new entries. > > > If you are not concerned that for a very small time the sets are empty, > > > then simply start with the flush command in the restore file and that's > > > all (I don't see why you'd want to destroy those). > > Well I'd have expected that everybody would be concerned... when you > > have some high speed network you surely will loose packets... > > That can happen for new connections only (unless you don't use conntrack > at all.) Which is already a major limitation, IMHO,... and it may not be desired or possible to do connection tracking in each situation... > > Actually the above would be what one would expect from the restore > > command, I guess. > > > > No chance that the semantics are changed here? > > No, not really. Any special reason? Nothing speaks at least against adding another restore command which does a proper restore. The current restore seems to be not much more then a sed "s/^/ipset /" | sh and I guess anybody can do this himself, not needing a special ipset restore command for it. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
