From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Anton Mitterer Subject: Re: ipset save and restore Date: Thu, 20 Dec 2012 01:23:23 +0100 Message-ID: <1355963003.5199.52.camel@fermat.scientia.net> References: <1355928786.30355.22.camel@heisenberg.scientia.net> <1355955834.5199.27.camel@fermat.scientia.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg="sha512"; protocol="application/x-pkcs7-signature"; boundary="=-j8TUfA5IYMIEdRjEWGzD" Return-path: In-Reply-To: Sender: netfilter-owner@vger.kernel.org List-ID: To: netfilter@vger.kernel.org --=-j8TUfA5IYMIEdRjEWGzD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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. iptable= s > > 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= =20 > current state is not appropriate for the commands (set already exist,=20 > 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. =46rom 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= =20 > 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=20 > > > 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 set= s > > 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 empt= y,=20 > > > then simply start with the flush command in the restore file and that= 's=20 > > > 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... >=20 > That can happen for new connections only (unless you don't use conntrack= =20 > at all.) Which is already a major limitation, IMHO,... and it may not be desired or possible to do connection tracking in each situation... =20 > > Actually the above would be what one would expect from the restore > > command, I guess. > >=20 > > No chance that the semantics are changed here? >=20 > 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. --=-j8TUfA5IYMIEdRjEWGzD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCCC5ww ggXKMIIEsqADAgECAgcU58ExtpytMA0GCSqGSIb3DQEBBQUAMFgxCzAJBgNVBAYTAkRFMRMwEQYD VQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSIwIAYDVQQDExlERk4tVmVyZWluIFBD QSBHcmlkIC0gRzAxMB4XDTEyMTIxMjA4NDMxM1oXDTE0MDEwOTA4NDMxM1oweTELMAkGA1UEBhMC REUxFDASBgNVBAoTC0dyaWRHZXJtYW55MTEwLwYDVQQLEyhMdWR3aWctTWF4aW1pbGlhbnMtVW5p dmVyc2l0YWV0IE11ZW5jaGVuMSEwHwYDVQQDExhDaHJpc3RvcGggQW50b24gTWl0dGVyZXIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9X0sutkL97kWEpV8WpoTvg9h4/9ghtoDNSVx9 XFLSR0ce2QWp+WuYs1l+i39vGd/0zvCMI5ioIAm7JMD4hyu2Ni4IMxbZ/B6IhFYhb+peEYozB8Es wJYXIHCo24qR6V3FpNiOUoF/wq1Em8p28ejHp9rX8aokkB2s0059i4gn9vn3xVY3z6U7zW4giCLK s5qG8r4w7bBuzkQshtjn9+VsKicemHcfrH/gM33ZFBuFqTgDZPsphBLupE60Nylf0br2jrinFt0K kkxTDQhR021lZ01XFsPf1AtMjqBh+vsGvCfZGSt4wZ7qwIrHI88P6dkhSiP6+5v0haLsJ1vkKhbp AgMBAAGjggJ2MIICcjAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMZatm//jhCHTlmzPd8Oc9IvwmyQMB8GA1UdIwQY MBaAFJbs3K2aw/5Qozwi5T3Cxf/K2SLGMCoGA1UdEQQjMCGBH2NocmlzdG9waC5hbnRvbi5taXR0 ZXJlckBsbXUuZGUwKgYDVR0gBCMwITARBg8rBgEEAYGtIYIsAQEDAQYwDAYKKoZIhvdMBQICATCB wQYDVR0fBIG5MIG2MFmgV6BVhlNodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlm aWNhdGlvbi94NTA5L2dyaWQvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDBZoFegVYZTaHR0 cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2Rh dGEvY3Jscy9yb290LWNhLWNybC5jcmwwgdYGCCsGAQUFBwEBBIHJMIHGMGEGCCsGAQUFBzAChlVo dHRwOi8vY2RwMS5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2dyaWQvZzEv ZGF0YS9jZXJ0cy9yb290LWNhLWNlcnQuY3J0MGEGCCsGAQUFBzAChlVodHRwOi8vY2RwMi5wY2Eu ZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2dyaWQvZzEvZGF0YS9jZXJ0cy9yb290 LWNhLWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBC8rkXZzIbWa6lhtcA4z9zJ6XqDgD4hloG ZxLowGI6QyYeeZJngIJ2Zzbf9NLoqp68kjA3paZdNNfbgHO/hLCz+23VwyJ0b54rrGWXQ9b2VVNF LB1H43VmXxLU78vurvREk6K/uAeXl7h8hKSsI9Wc8GOeJ7abe0FhkpCjT0O3cwxs3v53DS8XZmoQ hQ6oRPKRk/K+ahbP6KbVYWuhNLqmKUVCJqlFYawtccrHWFtuiKQqfyQqH7Rv51CFWyL7SRfxOSrM a0HVQcftW7F/7zQqJpltpvZFHiMEZatfuYldNVYLwA3P5VzFpPfJ5K4xzgiS/pJ0d+Fl55zssL2E /mhLMIIFyjCCBLKgAwIBAgIHFOfBMbacrTANBgkqhkiG9w0BAQUFADBYMQswCQYDVQQGEwJERTET MBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEiMCAGA1UEAxMZREZOLVZlcmVp biBQQ0EgR3JpZCAtIEcwMTAeFw0xMjEyMTIwODQzMTNaFw0xNDAxMDkwODQzMTNaMHkxCzAJBgNV BAYTAkRFMRQwEgYDVQQKEwtHcmlkR2VybWFueTExMC8GA1UECxMoTHVkd2lnLU1heGltaWxpYW5z LVVuaXZlcnNpdGFldCBNdWVuY2hlbjEhMB8GA1UEAxMYQ2hyaXN0b3BoIEFudG9uIE1pdHRlcmVy MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvV9LLrZC/e5FhKVfFqaE74PYeP/YIbaA zUlcfVxS0kdHHtkFqflrmLNZfot/bxnf9M7wjCOYqCAJuyTA+IcrtjYuCDMW2fweiIRWIW/qXhGK MwfBLMCWFyBwqNuKkeldxaTYjlKBf8KtRJvKdvHox6fa1/GqJJAdrNNOfYuIJ/b598VWN8+lO81u IIgiyrOahvK+MO2wbs5ELIbY5/flbConHph3H6x/4DN92RQbhak4A2T7KYQS7qROtDcpX9G69o64 pxbdCpJMUw0IUdNtZWdNVxbD39QLTI6gYfr7Brwn2RkreMGe6sCKxyPPD+nZIUoj+vub9IWi7Cdb 5CoW6QIDAQABo4ICdjCCAnIwDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYw FAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTGWrZv/44Qh05Zsz3fDnPSL8JskDAfBgNV HSMEGDAWgBSW7NytmsP+UKM8IuU9wsX/ytkixjAqBgNVHREEIzAhgR9jaHJpc3RvcGguYW50b24u bWl0dGVyZXJAbG11LmRlMCoGA1UdIAQjMCEwEQYPKwYBBAGBrSGCLAEBAwEGMAwGCiqGSIb3TAUC AgEwgcEGA1UdHwSBuTCBtjBZoFegVYZTaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2RhdGEvY3Jscy9yb290LWNhLWNybC5jcmwwWaBXoFWG U2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZpY2F0aW9uL3g1MDkvZ3JpZC9n MS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHWBggrBgEFBQcBAQSByTCBxjBhBggrBgEFBQcw AoZVaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlk L2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBhBggrBgEFBQcwAoZVaHR0cDovL2NkcDIu cGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9ncmlkL2cxL2RhdGEvY2VydHMv cm9vdC1jYS1jZXJ0LmNydDANBgkqhkiG9w0BAQUFAAOCAQEAQvK5F2cyG1mupYbXAOM/cyel6g4A +IZaBmcS6MBiOkMmHnmSZ4CCdmc23/TS6KqevJIwN6WmXTTX24Bzv4Sws/tt1cMidG+eK6xll0PW 9lVTRSwdR+N1Zl8S1O/L7q70RJOiv7gHl5e4fISkrCPVnPBjnie2m3tBYZKQo09Dt3MMbN7+dw0v F2ZqEIUOqETykZPyvmoWz+im1WFroTS6pilFQiapRWGsLXHKx1hbboikKn8kKh+0b+dQhVsi+0kX 8TkqzGtB1UHH7Vuxf+80KiaZbab2RR4jBGWrX7mJXTVWC8ANz+VcxaT3yeSuMc4Ikv6SdHfhZeec 7LC9hP5oSzGCAwUwggMBAgEBMGMwWDELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4x EDAOBgNVBAsTB0RGTi1QS0kxIjAgBgNVBAMTGURGTi1WZXJlaW4gUENBIEdyaWQgLSBHMDECBxTn wTG2nK0wDQYJYIZIAWUDBAIDBQCgggFzMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEyMTIyMDAwMjMyM1owTwYJKoZIhvcNAQkEMUIEQDAUlPw2nZlz+/1Zx7xFMjch eCHtWn0zUZjx8rZcXuzbJJ/L2PSZrKuxc/JuDDsyVSJrmz3Xv+IvLG+DHPReS+EwcgYJKwYBBAGC NxAEMWUwYzBYMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEiMCAGA1UEAxMZREZOLVZlcmVpbiBQQ0EgR3JpZCAtIEcwMQIHFOfBMbacrTB0BgsqhkiG 9w0BCRACCzFloGMwWDELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsT B0RGTi1QS0kxIjAgBgNVBAMTGURGTi1WZXJlaW4gUENBIEdyaWQgLSBHMDECBxTnwTG2nK0wDQYJ KoZIhvcNAQEBBQAEggEAKBo6MupGbB8mLHBDhazsGkTAcd75i9A4dRZ/qOvt39rmdaz/qqM/0nAC kfroyLx0MrjN8Co+SCv/QsXKCUkp1savtFdCni1Y8V7hdj43QQln7OrHWzklKrP++4hQDkR39IiU y8OcTrZFP/LqaHRqAUOGzx/k/tT2P6SzLebcXnYYAC4Jm/NsGOGNZQJujm0zGC8SoOe21s81Sg4I eTABXVK5aFpx1qDFW/aa9KEPSbsh2Z5XDeeyibdS7AEjm1Iejv0imkkbMiKdYdMkxgYempyA98Aa LwwYW8SQH9t3sITRBVXR0Rt56HeUeQTZOZe5dwl1fcvHxDXWiwQ7E9BkXAAAAAAAAA== --=-j8TUfA5IYMIEdRjEWGzD--