On Thu, 20 Dec 2012, Christoph Anton Mitterer wrote: > 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. No, "ipset restore" is not identical with iptables-restore. For example with the latter you are not able to incrementally update existing rulesets. > > > 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. Then you know exactly which sets are unused and can selectively destroy those. Or you can flush/destroy all of them and recreate. Or destroy the unused one and swap the used ones with new sets. > > > 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 . You did not mention that you use list type of sets... Those keep references to the elements, yes, and the elements cannot be destroyed while they are members. > So none of the sets is really used by iptables, and I'd expect I could > destroy them. No, because those are members of a set. > 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 you want to destroy all those sets, then first you have to flush at least setA. > > > > 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. No, that'd be totally incosistent, no way. > > > > 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. 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". ipset is a basic tool to manipulate the sets and it's an interface to all low level commands, nothing more. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlecsik.jozsef@xxxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
