Re: ipset save and restore

[Christoph Anton Mitterer <christoph.anton.mitterer@lmu.de>]

[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]

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 #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3811 bytes --]