From sesubram at redhat.com Thu Aug 30 13:50:10 2012 Content-Type: multipart/mixed; boundary="===============3982358241116964530==" MIME-Version: 1.0 From: Selvasundaram To: devel at ovirt.org Subject: [Engine-devel] Gluster IPTable configuration Date: Thu, 30 Aug 2012 17:11:09 +0530 Message-ID: <503F5155.6020603@redhat.com> --===============3982358241116964530== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------030709000903050400090401 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi, I want to add gluster specific IPTable configuration in addition to the = ovirt IPTable configuration (if it is gluster node). There are two approaches, 1. Having one more gluster specific IP table config in db and merge = with ovirt IPTable config (merging NOT appending) [I have the patch engine: Gluster specific firewall = configurations #7244] 2. Having two different IP Table config (ovirt and ovirt+gluster) = and use either one. Please provide your suggestions or improvements on this. -- Regards Selvasundaram --------------030709000903050400090401 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I want to add gluster specific IPTable configuration in addition to the ovirt IPTable configuration (if it is gluster node).
There are two approaches,
   1. Having one more gluster specific IP table config in db = and merge with ovirt IPTable config (merging NOT appending)
           [I have th= e patch engine: Gluster specific firewall configurations #7244]
   2. Having two different IP Table config (ovirt and ovirt+g= luster) and use either one.

Please provide your suggestions or improvements on this.

--
Regards
Selvasundaram


--------------030709000903050400090401-- --===============3982358241116964530== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wMzA3MDkwMDA5MDMwNTA0MDAwOTA0MDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksCgpJIHdhbnQgdG8gYWRkIGdsdXN0ZXIgc3BlY2lmaWMgSVBUYWJsZSBjb25maWd1 cmF0aW9uIGluIGFkZGl0aW9uIHRvIHRoZSAKb3ZpcnQgSVBUYWJsZSBjb25maWd1cmF0aW9uIChp ZiBpdCBpcyBnbHVzdGVyIG5vZGUpLgpUaGVyZSBhcmUgdHdvIGFwcHJvYWNoZXMsCiAgICAxLiBI YXZpbmcgb25lIG1vcmUgZ2x1c3RlciBzcGVjaWZpYyBJUCB0YWJsZSBjb25maWcgaW4gZGIgYW5k IG1lcmdlIAp3aXRoIG92aXJ0IElQVGFibGUgY29uZmlnIChtZXJnaW5nIE5PVCBhcHBlbmRpbmcp CiAgICAgICAgICAgIFtJIGhhdmUgdGhlIHBhdGNoIGVuZ2luZTogR2x1c3RlciBzcGVjaWZpYyBm aXJld2FsbCAKY29uZmlndXJhdGlvbnMgPGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy83MjQ0 Lz4gIzcyNDRdCiAgICAyLiBIYXZpbmcgdHdvIGRpZmZlcmVudCBJUCBUYWJsZSBjb25maWcgKG92 aXJ0IGFuZCBvdmlydCtnbHVzdGVyKSAKYW5kIHVzZSBlaXRoZXIgb25lLgoKUGxlYXNlIHByb3Zp ZGUgeW91ciBzdWdnZXN0aW9ucyBvciBpbXByb3ZlbWVudHMgb24gdGhpcy4KCi0tClJlZ2FyZHMK U2VsdmFzdW5kYXJhbQoKCgotLS0tLS0tLS0tLS0tLTAzMDcwOTAwMDkwMzA1MDQwMDA5MDQwMQpD b250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xCkNvbnRlbnQtVHJhbnNm ZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxtZXRhIGh0dHAtZXF1aXY9 ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEiPgog IDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4KICAgIEhp LDxicj4KICAgIDxicj4KICAgIEkgd2FudCB0byBhZGQgZ2x1c3RlciBzcGVjaWZpYyBJUFRhYmxl IGNvbmZpZ3VyYXRpb24gaW4gYWRkaXRpb24gdG8KICAgIHRoZSBvdmlydCBJUFRhYmxlIGNvbmZp Z3VyYXRpb24gKGlmIGl0IGlzIGdsdXN0ZXIgbm9kZSkuIDxicj4KICAgIFRoZXJlIGFyZSB0d28g YXBwcm9hY2hlcywgPGJyPgogICAgJm5ic3A7Jm5ic3A7IDEuIEhhdmluZyBvbmUgbW9yZSBnbHVz dGVyIHNwZWNpZmljIElQIHRhYmxlIGNvbmZpZyBpbiBkYiBhbmQKICAgIG1lcmdlIHdpdGggb3Zp cnQgSVBUYWJsZSBjb25maWcgKG1lcmdpbmcgTk9UIGFwcGVuZGluZyk8YnI+CiAgICAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW0kg aGF2ZSB0aGUgcGF0Y2ggPGEKICAgICAgaHJlZj0iaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9j LzcyNDQvIgogICAgICBjbGFzcz0iZ3d0LUlubGluZUh5cGVybGluayI+ZW5naW5lOiBHbHVzdGVy IHNwZWNpZmljIGZpcmV3YWxsCiAgICAgIGNvbmZpZ3VyYXRpb25zPC9hPiAjNzI0NF08YnI+CiAg ICAmbmJzcDsmbmJzcDsgMi4gSGF2aW5nIHR3byBkaWZmZXJlbnQgSVAgVGFibGUgY29uZmlnIChv dmlydCBhbmQgb3ZpcnQrZ2x1c3RlcikKICAgIGFuZCB1c2UgZWl0aGVyIG9uZS48YnI+CiAgICA8 YnI+CiAgICBQbGVhc2UgcHJvdmlkZSB5b3VyIHN1Z2dlc3Rpb25zIG9yIGltcHJvdmVtZW50cyBv biB0aGlzLiA8YnI+CiAgICA8YnI+CiAgICAtLTxicj4KICAgIFJlZ2FyZHM8YnI+CiAgICBTZWx2 YXN1bmRhcmFtPGJyPgogICAgPGJyPgogICAgPGJyPgogIDwvYm9keT4KPC9odG1sPgoKLS0tLS0t LS0tLS0tLS0wMzA3MDkwMDA5MDMwNTA0MDAwOTA0MDEtLQo= --===============3982358241116964530==-- From sesubram at redhat.com Thu Aug 30 13:55:16 2012 Content-Type: multipart/mixed; boundary="===============8626256136518510471==" MIME-Version: 1.0 From: Selvasundaram To: devel at ovirt.org Subject: [Engine-devel] Gluster IPTable configuration Date: Thu, 30 Aug 2012 19:00:16 +0530 Message-ID: <503F6AE8.7010303@redhat.com> In-Reply-To: 503F5155.6020603@redhat.com --===============8626256136518510471== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------080303050500000508090403 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi, I want to add gluster specific IPTable configuration in addition to the = ovirt IPTable configuration (if it is gluster node). There are two approaches, 1. Having one more gluster specific IP table config in db and merge = with ovirt IPTable config (merging NOT appending) [I have the patch engine: Gluster specific firewall = configurations #7244] 2. Having two different IP Table config (ovirt and ovirt+gluster) = and use either one. Please provide your suggestions or improvements on this. -- Regards Selvasundaram --------------080303050500000508090403 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I want to add gluster specific IPTable configuration in addition to the ovirt IPTable configuration (if it is gluster node).

There are two approaches,
   1. Having one more gluster specific IP table config in db = and merge with ovirt IPTable config (merging NOT appending)
           [I have th= e patch engine: Gluster specific firewall configurations #7244]
   2. Having two different IP Table config (ovirt and ovirt+g= luster) and use either one.

Please provide your suggestions or improvements on this.

--
Regards
Selvasundaram


--------------080303050500000508090403-- --===============8626256136518510471== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wODAzMDMwNTA1MDAwMDA1MDgwOTA0MDMKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGksCgpJIHdhbnQgdG8gYWRkIGdsdXN0ZXIgc3BlY2lmaWMgSVBUYWJsZSBjb25maWd1 cmF0aW9uIGluIGFkZGl0aW9uIHRvIHRoZSAKb3ZpcnQgSVBUYWJsZSBjb25maWd1cmF0aW9uIChp ZiBpdCBpcyBnbHVzdGVyIG5vZGUpLgoKVGhlcmUgYXJlIHR3byBhcHByb2FjaGVzLAogICAgMS4g SGF2aW5nIG9uZSBtb3JlIGdsdXN0ZXIgc3BlY2lmaWMgSVAgdGFibGUgY29uZmlnIGluIGRiIGFu ZCBtZXJnZSAKd2l0aCBvdmlydCBJUFRhYmxlIGNvbmZpZyAobWVyZ2luZyBOT1QgYXBwZW5kaW5n KQogICAgICAgICAgICBbSSBoYXZlIHRoZSBwYXRjaCBlbmdpbmU6IEdsdXN0ZXIgc3BlY2lmaWMg ZmlyZXdhbGwgCmNvbmZpZ3VyYXRpb25zIDxodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2MvNzI0 NC8+ICM3MjQ0XQogICAgMi4gSGF2aW5nIHR3byBkaWZmZXJlbnQgSVAgVGFibGUgY29uZmlnIChv dmlydCBhbmQgb3ZpcnQrZ2x1c3RlcikgCmFuZCB1c2UgZWl0aGVyIG9uZS4KClBsZWFzZSBwcm92 aWRlIHlvdXIgc3VnZ2VzdGlvbnMgb3IgaW1wcm92ZW1lbnRzIG9uIHRoaXMuCgotLQpSZWdhcmRz ClNlbHZhc3VuZGFyYW0KCgoKLS0tLS0tLS0tLS0tLS0wODAzMDMwNTA1MDAwMDA1MDgwOTA0MDMK Q29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMQpDb250ZW50LVRyYW5z ZmVyLUVuY29kaW5nOiA3Yml0Cgo8aHRtbD4KICA8aGVhZD4KICAgIDxtZXRhIGh0dHAtZXF1aXY9 ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOwogICAgICBjaGFyc2V0PUlTTy04ODU5 LTEiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAwMDAwIj4K ICAgIEhpLDxicj4KICAgIDxicj4KICAgIEkgd2FudCB0byBhZGQgZ2x1c3RlciBzcGVjaWZpYyBJ UFRhYmxlIGNvbmZpZ3VyYXRpb24gaW4gYWRkaXRpb24gdG8KICAgIHRoZSBvdmlydCBJUFRhYmxl IGNvbmZpZ3VyYXRpb24gKGlmIGl0IGlzIGdsdXN0ZXIgbm9kZSkuIDxicj4KICAgIDxicj4KICAg IFRoZXJlIGFyZSB0d28gYXBwcm9hY2hlcywgPGJyPgogICAgJm5ic3A7Jm5ic3A7IDEuIEhhdmlu ZyBvbmUgbW9yZSBnbHVzdGVyIHNwZWNpZmljIElQIHRhYmxlIGNvbmZpZyBpbiBkYiBhbmQKICAg IG1lcmdlIHdpdGggb3ZpcnQgSVBUYWJsZSBjb25maWcgKG1lcmdpbmcgTk9UIGFwcGVuZGluZyk8 YnI+CiAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgW0kgaGF2ZSB0aGUgcGF0Y2ggPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIgog ICAgICBocmVmPSJodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2MvNzI0NC8iCiAgICAgIGNsYXNz PSJnd3QtSW5saW5lSHlwZXJsaW5rIj5lbmdpbmU6IEdsdXN0ZXIgc3BlY2lmaWMgZmlyZXdhbGwK ICAgICAgY29uZmlndXJhdGlvbnM8L2E+ICM3MjQ0XTxicj4KICAgICZuYnNwOyZuYnNwOyAyLiBI YXZpbmcgdHdvIGRpZmZlcmVudCBJUCBUYWJsZSBjb25maWcgKG92aXJ0IGFuZCBvdmlydCtnbHVz dGVyKQogICAgYW5kIHVzZSBlaXRoZXIgb25lLjxicj4KICAgIDxicj4KICAgIFBsZWFzZSBwcm92 aWRlIHlvdXIgc3VnZ2VzdGlvbnMgb3IgaW1wcm92ZW1lbnRzIG9uIHRoaXMuIDxicj4KICAgIDxi cj4KICAgIC0tPGJyPgogICAgUmVnYXJkczxicj4KICAgIFNlbHZhc3VuZGFyYW08YnI+CiAgICA8 YnI+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA4MDMwMzA1MDUw MDAwMDUwODA5MDQwMy0tCg== --===============8626256136518510471==-- From alonbl at redhat.com Thu Aug 30 14:35:17 2012 Content-Type: multipart/mixed; boundary="===============7735001957711721084==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Thu, 30 Aug 2012 14:35:16 -0400 Message-ID: <278376844.4015237.1346351716576.JavaMail.root@redhat.com> In-Reply-To: 503F6AE8.7010303@redhat.com --===============7735001957711721084== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Selvasundaram" > To: engine-devel(a)ovirt.org > Cc: "Shireesh Anjal" > Sent: Thursday, August 30, 2012 4:30:16 PM > Subject: [Engine-devel] Gluster IPTable configuration > = > = > Hi, > = > I want to add gluster specific IPTable configuration in addition to > the ovirt IPTable configuration (if it is gluster node). > = > There are two approaches, > 1. Having one more gluster specific IP table config in db and merge > with ovirt IPTable config (merging NOT appending) > [I have the patch engine: Gluster specific firewall configurations > #7244] > 2. Having two different IP Table config (ovirt and ovirt+gluster) and > use either one. > = > Please provide your suggestions or improvements on this. > = Hello all, The mentioned patch[1], adds hard coded gluster code into the bootstrap cod= e, manipulate the firewall configuration to be gluster specific. It hardcod= ed search for "reject", insert before some other rules. I believe this hardcode approach is obsolete now that we have proper tools = for templates. A more robust solution would be defining generic profiles, each profile as = a template, each template can refer to different profiles, and assign profi= le to a node. This way the implementation is not gluster [or any] specific and can be reu= sed for more setups, code is cleaner. Example: BASIC.PRE :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] BASIC.IN accept ... accept ... BASIC.POST reject ... reject ... BASIC ${BASIC.PRE} ${BASIC.IN} ${BASIC.POST} GLUSTER ${BASIC.PRE} ${BASIC.IN} accept ... ${BASIC.POST} reject ... Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/7244/ --===============7735001957711721084==-- From acathrow at redhat.com Thu Aug 30 14:38:00 2012 Content-Type: multipart/mixed; boundary="===============9216195477928906050==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Thu, 30 Aug 2012 14:37:59 -0400 Message-ID: <1378011110.3476214.1346351879584.JavaMail.root@redhat.com> In-Reply-To: 278376844.4015237.1346351716576.JavaMail.root@redhat.com --===============9216195477928906050== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Selvasundaram" > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org > Sent: Thursday, August 30, 2012 2:35:16 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Selvasundaram" > > To: engine-devel(a)ovirt.org > > Cc: "Shireesh Anjal" > > Sent: Thursday, August 30, 2012 4:30:16 PM > > Subject: [Engine-devel] Gluster IPTable configuration > > = > > = > > Hi, > > = > > I want to add gluster specific IPTable configuration in addition to > > the ovirt IPTable configuration (if it is gluster node). > > = > > There are two approaches, > > 1. Having one more gluster specific IP table config in db and merge > > with ovirt IPTable config (merging NOT appending) > > [I have the patch engine: Gluster specific firewall configurations > > #7244] > > 2. Having two different IP Table config (ovirt and ovirt+gluster) > > and > > use either one. > > = > > Please provide your suggestions or improvements on this. > > = > = > Hello all, > = > The mentioned patch[1], adds hard coded gluster code into the > bootstrap code, manipulate the firewall configuration to be gluster > specific. It hardcoded search for "reject", insert before some other > rules. > = > I believe this hardcode approach is obsolete now that we have proper > tools for templates. > = > A more robust solution would be defining generic profiles, each > profile as a template, each template can refer to different > profiles, and assign profile to a node. > = > This way the implementation is not gluster [or any] specific and can > be reused for more setups, code is cleaner. or create custom chains ? > = > Example: > = > BASIC.PRE > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > BASIC.IN > accept ... > accept ... > BASIC.POST > reject ... > reject ... > = > BASIC > ${BASIC.PRE} > ${BASIC.IN} > ${BASIC.POST} > = > GLUSTER > ${BASIC.PRE} > ${BASIC.IN} > accept ... > ${BASIC.POST} > reject ... > = > Regards, > Alon Bar-Lev > = > [1] http://gerrit.ovirt.org/#/c/7244/ > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============9216195477928906050==-- From alonbl at redhat.com Thu Aug 30 14:40:22 2012 Content-Type: multipart/mixed; boundary="===============8231074536147612755==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Thu, 30 Aug 2012 14:40:22 -0400 Message-ID: <1896719975.4016337.1346352022153.JavaMail.root@redhat.com> In-Reply-To: 1378011110.3476214.1346351879584.JavaMail.root@redhat.com --===============8231074536147612755== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Andrew Cathrow" > To: "Alon Bar-Lev" > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org, "Se= lvasundaram" > Sent: Thursday, August 30, 2012 9:37:59 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Selvasundaram" > > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org > > Sent: Thursday, August 30, 2012 2:35:16 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "Selvasundaram" > > > To: engine-devel(a)ovirt.org > > > Cc: "Shireesh Anjal" > > > Sent: Thursday, August 30, 2012 4:30:16 PM > > > Subject: [Engine-devel] Gluster IPTable configuration > > > = > > > = > > > Hi, > > > = > > > I want to add gluster specific IPTable configuration in addition > > > to > > > the ovirt IPTable configuration (if it is gluster node). > > > = > > > There are two approaches, > > > 1. Having one more gluster specific IP table config in db and > > > merge > > > with ovirt IPTable config (merging NOT appending) > > > [I have the patch engine: Gluster specific firewall > > > configurations > > > #7244] > > > 2. Having two different IP Table config (ovirt and ovirt+gluster) > > > and > > > use either one. > > > = > > > Please provide your suggestions or improvements on this. > > > = > > = > > Hello all, > > = > > The mentioned patch[1], adds hard coded gluster code into the > > bootstrap code, manipulate the firewall configuration to be gluster > > specific. It hardcoded search for "reject", insert before some > > other > > rules. > > = > > I believe this hardcode approach is obsolete now that we have > > proper > > tools for templates. > > = > > A more robust solution would be defining generic profiles, each > > profile as a template, each template can refer to different > > profiles, and assign profile to a node. > > = > > This way the implementation is not gluster [or any] specific and > > can > > be reused for more setups, code is cleaner. > = > = > or create custom chains ? Can you please elaborate what is custom chains? = Thanks! > > = > > Example: > > = > > BASIC.PRE > > :INPUT ACCEPT [0:0] > > :FORWARD ACCEPT [0:0] > > :OUTPUT ACCEPT [0:0] > > BASIC.IN > > accept ... > > accept ... > > BASIC.POST > > reject ... > > reject ... > > = > > BASIC > > ${BASIC.PRE} > > ${BASIC.IN} > > ${BASIC.POST} > > = > > GLUSTER > > ${BASIC.PRE} > > ${BASIC.IN} > > accept ... > > ${BASIC.POST} > > reject ... > > = > > Regards, > > Alon Bar-Lev > > = > > [1] http://gerrit.ovirt.org/#/c/7244/ > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > = >=20 --===============8231074536147612755==-- From djasa at redhat.com Fri Aug 31 04:57:13 2012 Content-Type: multipart/mixed; boundary="===============2618512211074434544==" MIME-Version: 1.0 From: =?utf-8?q?David_Ja=C5=A1a_=3Cdjasa_at_redhat=2Ecom=3E?= To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Fri, 31 Aug 2012 10:57:11 +0200 Message-ID: <1346403431.18636.36.camel@dhcp-29-7.brq.redhat.com> In-Reply-To: 1896719975.4016337.1346352022153.JavaMail.root@redhat.com --===============2618512211074434544== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: > = > ----- Original Message ----- > > From: "Andrew Cathrow" > > To: "Alon Bar-Lev" > > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org, "= Selvasundaram" > > Sent: Thursday, August 30, 2012 9:37:59 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Selvasundaram" > > > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org > > > Sent: Thursday, August 30, 2012 2:35:16 PM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > = > > > = > > > = > > > ----- Original Message ----- > > > > From: "Selvasundaram" > > > > To: engine-devel(a)ovirt.org > > > > Cc: "Shireesh Anjal" > > > > Sent: Thursday, August 30, 2012 4:30:16 PM > > > > Subject: [Engine-devel] Gluster IPTable configuration > > > > = > > > > = > > > > Hi, > > > > = > > > > I want to add gluster specific IPTable configuration in addition > > > > to > > > > the ovirt IPTable configuration (if it is gluster node). > > > > = > > > > There are two approaches, > > > > 1. Having one more gluster specific IP table config in db and > > > > merge > > > > with ovirt IPTable config (merging NOT appending) > > > > [I have the patch engine: Gluster specific firewall > > > > configurations > > > > #7244] > > > > 2. Having two different IP Table config (ovirt and ovirt+gluster) > > > > and > > > > use either one. > > > > = > > > > Please provide your suggestions or improvements on this. > > > > = > > > = > > > Hello all, > > > = > > > The mentioned patch[1], adds hard coded gluster code into the > > > bootstrap code, manipulate the firewall configuration to be gluster > > > specific. It hardcoded search for "reject", insert before some > > > other > > > rules. > > > = > > > I believe this hardcode approach is obsolete now that we have > > > proper > > > tools for templates. > > > = > > > A more robust solution would be defining generic profiles, each > > > profile as a template, each template can refer to different > > > profiles, and assign profile to a node. > > > = > > > This way the implementation is not gluster [or any] specific and > > > can > > > be reused for more setups, code is cleaner. > > = > > = > > or create custom chains ? > = > Can you please elaborate what is custom chains? = > Thanks! iptables -N my_new_chain iptables -A my_new_chain iptables -A my_new_chain ... iptables -A my_new_chain # if this is matched, packet goes through rules in my_new_chain iptables -A INPUT -j my_new_chain David > = > > > = > > > Example: > > > = > > > BASIC.PRE > > > :INPUT ACCEPT [0:0] > > > :FORWARD ACCEPT [0:0] > > > :OUTPUT ACCEPT [0:0] > > > BASIC.IN > > > accept ... > > > accept ... > > > BASIC.POST > > > reject ... > > > reject ... > > > = > > > BASIC > > > ${BASIC.PRE} > > > ${BASIC.IN} > > > ${BASIC.POST} > > > = > > > GLUSTER > > > ${BASIC.PRE} > > > ${BASIC.IN} > > > accept ... > > > ${BASIC.POST} > > > reject ... > > > = > > > Regards, > > > Alon Bar-Lev > > > = > > > [1] http://gerrit.ovirt.org/#/c/7244/ > > > _______________________________________________ > > > Engine-devel mailing list > > > Engine-devel(a)ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > = > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- = David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 = Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 --===============2618512211074434544==-- From alonbl at redhat.com Fri Aug 31 05:09:47 2012 Content-Type: multipart/mixed; boundary="===============5119895758562303304==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Fri, 31 Aug 2012 05:09:47 -0400 Message-ID: <1859251011.4125137.1346404187219.JavaMail.root@redhat.com> In-Reply-To: 1346403431.18636.36.camel@dhcp-29-7.brq.redhat.com --===============5119895758562303304== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "David Ja=C5=A1a" > To: engine-devel(a)ovirt.org > Sent: Friday, August 31, 2012 11:57:11 AM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: > > = > > ----- Original Message ----- > > > From: "Andrew Cathrow" > > > To: "Alon Bar-Lev" > > > Cc: "Shireesh Anjal" , engine-devel(a)ovirt.org, > > > "Selvasundaram" > > > Sent: Thursday, August 30, 2012 9:37:59 PM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > = > > > = > > > = > > > ----- Original Message ----- > > > > From: "Alon Bar-Lev" > > > > To: "Selvasundaram" > > > > Cc: "Shireesh Anjal" , > > > > engine-devel(a)ovirt.org > > > > Sent: Thursday, August 30, 2012 2:35:16 PM > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > = > > > > = > > > > = > > > > ----- Original Message ----- > > > > > From: "Selvasundaram" > > > > > To: engine-devel(a)ovirt.org > > > > > Cc: "Shireesh Anjal" > > > > > Sent: Thursday, August 30, 2012 4:30:16 PM > > > > > Subject: [Engine-devel] Gluster IPTable configuration > > > > > = > > > > > = > > > > > Hi, > > > > > = > > > > > I want to add gluster specific IPTable configuration in > > > > > addition > > > > > to > > > > > the ovirt IPTable configuration (if it is gluster node). > > > > > = > > > > > There are two approaches, > > > > > 1. Having one more gluster specific IP table config in db and > > > > > merge > > > > > with ovirt IPTable config (merging NOT appending) > > > > > [I have the patch engine: Gluster specific firewall > > > > > configurations > > > > > #7244] > > > > > 2. Having two different IP Table config (ovirt and > > > > > ovirt+gluster) > > > > > and > > > > > use either one. > > > > > = > > > > > Please provide your suggestions or improvements on this. > > > > > = > > > > = > > > > Hello all, > > > > = > > > > The mentioned patch[1], adds hard coded gluster code into the > > > > bootstrap code, manipulate the firewall configuration to be > > > > gluster > > > > specific. It hardcoded search for "reject", insert before some > > > > other > > > > rules. > > > > = > > > > I believe this hardcode approach is obsolete now that we have > > > > proper > > > > tools for templates. > > > > = > > > > A more robust solution would be defining generic profiles, each > > > > profile as a template, each template can refer to different > > > > profiles, and assign profile to a node. > > > > = > > > > This way the implementation is not gluster [or any] specific > > > > and > > > > can > > > > be reused for more setups, code is cleaner. > > > = > > > = > > > or create custom chains ? > > = > > Can you please elaborate what is custom chains? > > Thanks! > = > iptables -N my_new_chain > iptables -A my_new_chain > iptables -A my_new_chain ... > iptables -A my_new_chain > = > # if this is matched, packet goes through rules in > my_new_chain > iptables -A INPUT -j my_new_chain > = Hello, How does this solve the original issue? The need to provide different rules to different hosts by software installe= d on destination? Standard host needs iptables X. Gluster host needs iptables X+Y. XXX host needs iptables X+Z. Maintainer of Gluster knows what Y is. Maintainer of XXX knows what Z is. If we merge all to one entry product comes with default X. User override X to A. New version of product comes with default Y. Upgrade options: 1. System continues to use A. 2. Some AI to upgrade and create A'. 3. Revert to Y, dropping user's customization. Or we can maintain one large table with complete configuration and conditio= nals. Alon. --===============5119895758562303304==-- From acathrow at redhat.com Fri Aug 31 08:12:35 2012 Content-Type: multipart/mixed; boundary="===============5139548417841503748==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Fri, 31 Aug 2012 08:12:34 -0400 Message-ID: <1750220219.3758540.1346415154344.JavaMail.root@redhat.com> In-Reply-To: 1859251011.4125137.1346404187219.JavaMail.root@redhat.com --===============5139548417841503748== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Alon Bar-Lev" > To: "David Ja=C5=A1a" > Cc: engine-devel(a)ovirt.org > Sent: Friday, August 31, 2012 5:09:47 AM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "David Ja=C5=A1a" > > To: engine-devel(a)ovirt.org > > Sent: Friday, August 31, 2012 11:57:11 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: > > > = > > > ----- Original Message ----- > > > > From: "Andrew Cathrow" > > > > To: "Alon Bar-Lev" > > > > Cc: "Shireesh Anjal" , > > > > engine-devel(a)ovirt.org, > > > > "Selvasundaram" > > > > Sent: Thursday, August 30, 2012 9:37:59 PM > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > = > > > > = > > > > = > > > > ----- Original Message ----- > > > > > From: "Alon Bar-Lev" > > > > > To: "Selvasundaram" > > > > > Cc: "Shireesh Anjal" , > > > > > engine-devel(a)ovirt.org > > > > > Sent: Thursday, August 30, 2012 2:35:16 PM > > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > = > > > > > = > > > > > = > > > > > ----- Original Message ----- > > > > > > From: "Selvasundaram" > > > > > > To: engine-devel(a)ovirt.org > > > > > > Cc: "Shireesh Anjal" > > > > > > Sent: Thursday, August 30, 2012 4:30:16 PM > > > > > > Subject: [Engine-devel] Gluster IPTable configuration > > > > > > = > > > > > > = > > > > > > Hi, > > > > > > = > > > > > > I want to add gluster specific IPTable configuration in > > > > > > addition > > > > > > to > > > > > > the ovirt IPTable configuration (if it is gluster node). > > > > > > = > > > > > > There are two approaches, > > > > > > 1. Having one more gluster specific IP table config in db > > > > > > and > > > > > > merge > > > > > > with ovirt IPTable config (merging NOT appending) > > > > > > [I have the patch engine: Gluster specific firewall > > > > > > configurations > > > > > > #7244] > > > > > > 2. Having two different IP Table config (ovirt and > > > > > > ovirt+gluster) > > > > > > and > > > > > > use either one. > > > > > > = > > > > > > Please provide your suggestions or improvements on this. > > > > > > = > > > > > = > > > > > Hello all, > > > > > = > > > > > The mentioned patch[1], adds hard coded gluster code into the > > > > > bootstrap code, manipulate the firewall configuration to be > > > > > gluster > > > > > specific. It hardcoded search for "reject", insert before > > > > > some > > > > > other > > > > > rules. > > > > > = > > > > > I believe this hardcode approach is obsolete now that we have > > > > > proper > > > > > tools for templates. > > > > > = > > > > > A more robust solution would be defining generic profiles, > > > > > each > > > > > profile as a template, each template can refer to different > > > > > profiles, and assign profile to a node. > > > > > = > > > > > This way the implementation is not gluster [or any] specific > > > > > and > > > > > can > > > > > be reused for more setups, code is cleaner. > > > > = > > > > = > > > > or create custom chains ? > > > = > > > Can you please elaborate what is custom chains? > > > Thanks! > > = > > iptables -N my_new_chain > > iptables -A my_new_chain > > iptables -A my_new_chain ... > > iptables -A my_new_chain > > = > > # if this is matched, packet goes through rules in > > my_new_chain > > iptables -A INPUT -j my_new_chain > > = > = > Hello, > = > How does this solve the original issue? It makes it easier for customers who are adding their own IPTables configur= ation - when we do rhev-h plugins it'll make things easier. This way we don't wipe out the original rules we just add our own chain. > The need to provide different rules to different hosts by software > installed on destination? > = > Standard host needs iptables X. > Gluster host needs iptables X+Y. > XXX host needs iptables X+Z. > Maintainer of Gluster knows what Y is. > Maintainer of XXX knows what Z is. > = > If we merge all to one entry product comes with default X. > User override X to A. > New version of product comes with default Y. > Upgrade options: > 1. System continues to use A. > 2. Some AI to upgrade and create A'. > 3. Revert to Y, dropping user's customization. > = > Or we can maintain one large table with complete configuration and > conditionals. > = > Alon. > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============5139548417841503748==-- From dfediuck at redhat.com Sun Sep 2 10:21:48 2012 Content-Type: multipart/mixed; boundary="===============1654673053351752266==" MIME-Version: 1.0 From: Doron Fediuck To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Sun, 02 Sep 2012 10:21:47 -0400 Message-ID: <1890405098.4216852.1346595707950.JavaMail.root@redhat.com> In-Reply-To: 1750220219.3758540.1346415154344.JavaMail.root@redhat.com --===============1654673053351752266== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Andrew Cathrow" > To: "Alon Bar-Lev" > Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org > Sent: Friday, August 31, 2012 3:12:34 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "David Ja=C5=A1a" > > Cc: engine-devel(a)ovirt.org > > Sent: Friday, August 31, 2012 5:09:47 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "David Ja=C5=A1a" > > > To: engine-devel(a)ovirt.org > > > Sent: Friday, August 31, 2012 11:57:11 AM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > = > > > Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: > > > > = > > > > ----- Original Message ----- > > > > > From: "Andrew Cathrow" > > > > > To: "Alon Bar-Lev" > > > > > Cc: "Shireesh Anjal" , > > > > > engine-devel(a)ovirt.org, > > > > > "Selvasundaram" > > > > > Sent: Thursday, August 30, 2012 9:37:59 PM > > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > = > > > > > = > > > > > = > > > > > ----- Original Message ----- > > > > > > From: "Alon Bar-Lev" > > > > > > To: "Selvasundaram" > > > > > > Cc: "Shireesh Anjal" , > > > > > > engine-devel(a)ovirt.org > > > > > > Sent: Thursday, August 30, 2012 2:35:16 PM > > > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > > > = > > > > > > = > > > > > > = > > > > > > ----- Original Message ----- > > > > > > > From: "Selvasundaram" > > > > > > > To: engine-devel(a)ovirt.org > > > > > > > Cc: "Shireesh Anjal" > > > > > > > Sent: Thursday, August 30, 2012 4:30:16 PM > > > > > > > Subject: [Engine-devel] Gluster IPTable configuration > > > > > > > = > > > > > > > = > > > > > > > Hi, > > > > > > > = > > > > > > > I want to add gluster specific IPTable configuration in > > > > > > > addition > > > > > > > to > > > > > > > the ovirt IPTable configuration (if it is gluster node). > > > > > > > = > > > > > > > There are two approaches, > > > > > > > 1. Having one more gluster specific IP table config in db > > > > > > > and > > > > > > > merge > > > > > > > with ovirt IPTable config (merging NOT appending) > > > > > > > [I have the patch engine: Gluster specific firewall > > > > > > > configurations > > > > > > > #7244] > > > > > > > 2. Having two different IP Table config (ovirt and > > > > > > > ovirt+gluster) > > > > > > > and > > > > > > > use either one. > > > > > > > = > > > > > > > Please provide your suggestions or improvements on this. > > > > > > > = > > > > > > = > > > > > > Hello all, > > > > > > = > > > > > > The mentioned patch[1], adds hard coded gluster code into > > > > > > the > > > > > > bootstrap code, manipulate the firewall configuration to be > > > > > > gluster > > > > > > specific. It hardcoded search for "reject", insert before > > > > > > some > > > > > > other > > > > > > rules. > > > > > > = > > > > > > I believe this hardcode approach is obsolete now that we > > > > > > have > > > > > > proper > > > > > > tools for templates. > > > > > > = > > > > > > A more robust solution would be defining generic profiles, > > > > > > each > > > > > > profile as a template, each template can refer to different > > > > > > profiles, and assign profile to a node. > > > > > > = > > > > > > This way the implementation is not gluster [or any] > > > > > > specific > > > > > > and > > > > > > can > > > > > > be reused for more setups, code is cleaner. > > > > > = > > > > > = > > > > > or create custom chains ? > > > > = > > > > Can you please elaborate what is custom chains? > > > > Thanks! > > > = > > > iptables -N my_new_chain > > > iptables -A my_new_chain > > > iptables -A my_new_chain ... > > > iptables -A my_new_chain > > > = > > > # if this is matched, packet goes through rules in > > > my_new_chain > > > iptables -A INPUT -j my_new_chain > > > = > > = > > Hello, > > = > > How does this solve the original issue? > = > It makes it easier for customers who are adding their own IPTables > configuration - when we do rhev-h plugins it'll make things easier. > This way we don't wipe out the original rules we just add our own > chain. > = > = Current default (virt) iptables configuration is kept in the engine's DB. So... 1. We can update the DB value to include Gluster configuration. or 2. Have an additional DB value for virt+Gluster. So (1) will work, but when gluster is not relevant we have redundant ports. But my only reservation from (2) is that it's not scalable for additional services. Either way, I agree with Alon that melding the configurations at runtime is unexpected, and shouldn't be used. After some additional thought... we can have (1), and make all gluster entries commented out (let's say with #GLSTR) by default, so it'll be enabled only when gluster is being used. This will allow introducing future configurations as well without the need for additional DB values. Sample snip of DB value: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT # vdsm -A INPUT -p tcp --dport 54321 -j ACCEPT # libvirt tls -A INPUT -p tcp --dport 16514 -j ACCEPT # SSH -A INPUT -p tcp --dport 22 -j ACCEPT # guest consoles -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT # gluster p1 #GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT # gluster p2-p6 #GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT # Reject any other input traffic -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT --reject-with icmp-h= ost-prohibited COMMIT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D So as you can see, this is something we can handle in run-time. Also it's e= asy to test, so predictable, and finally- human beings can look and understand = what it means. > > The need to provide different rules to different hosts by software > > installed on destination? > > = > > Standard host needs iptables X. > > Gluster host needs iptables X+Y. > > XXX host needs iptables X+Z. > > Maintainer of Gluster knows what Y is. > > Maintainer of XXX knows what Z is. > > = > > If we merge all to one entry product comes with default X. > > User override X to A. > > New version of product comes with default Y. > > Upgrade options: > > 1. System continues to use A. > > 2. Some AI to upgrade and create A'. > > 3. Revert to Y, dropping user's customization. > > = > > Or we can maintain one large table with complete configuration and > > conditionals. > > = > > Alon. --===============1654673053351752266==-- From iheim at redhat.com Sun Sep 2 16:51:44 2012 Content-Type: multipart/mixed; boundary="===============8274170167389393015==" MIME-Version: 1.0 From: Itamar Heim To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Sun, 02 Sep 2012 23:51:40 +0300 Message-ID: <5043C6DC.1000705@redhat.com> In-Reply-To: 1890405098.4216852.1346595707950.JavaMail.root@redhat.com --===============8274170167389393015== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 09/02/2012 05:21 PM, Doron Fediuck wrote: > ----- Original Message ----- >> From: "Andrew Cathrow" >> To: "Alon Bar-Lev" >> Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org >> Sent: Friday, August 31, 2012 3:12:34 PM >> Subject: Re: [Engine-devel] Gluster IPTable configuration >> >> >> >> ----- Original Message ----- >>> From: "Alon Bar-Lev" >>> To: "David Ja=C5=A1a" >>> Cc: engine-devel(a)ovirt.org >>> Sent: Friday, August 31, 2012 5:09:47 AM >>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>> >>> >>> >>> ----- Original Message ----- >>>> From: "David Ja=C5=A1a" >>>> To: engine-devel(a)ovirt.org >>>> Sent: Friday, August 31, 2012 11:57:11 AM >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>> >>>> Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: >>>>> >>>>> ----- Original Message ----- >>>>>> From: "Andrew Cathrow" >>>>>> To: "Alon Bar-Lev" >>>>>> Cc: "Shireesh Anjal" , >>>>>> engine-devel(a)ovirt.org, >>>>>> "Selvasundaram" >>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM >>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>>>> >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: "Alon Bar-Lev" >>>>>>> To: "Selvasundaram" >>>>>>> Cc: "Shireesh Anjal" , >>>>>>> engine-devel(a)ovirt.org >>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM >>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>>> From: "Selvasundaram" >>>>>>>> To: engine-devel(a)ovirt.org >>>>>>>> Cc: "Shireesh Anjal" >>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM >>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I want to add gluster specific IPTable configuration in >>>>>>>> addition >>>>>>>> to >>>>>>>> the ovirt IPTable configuration (if it is gluster node). >>>>>>>> >>>>>>>> There are two approaches, >>>>>>>> 1. Having one more gluster specific IP table config in db >>>>>>>> and >>>>>>>> merge >>>>>>>> with ovirt IPTable config (merging NOT appending) >>>>>>>> [I have the patch engine: Gluster specific firewall >>>>>>>> configurations >>>>>>>> #7244] >>>>>>>> 2. Having two different IP Table config (ovirt and >>>>>>>> ovirt+gluster) >>>>>>>> and >>>>>>>> use either one. >>>>>>>> >>>>>>>> Please provide your suggestions or improvements on this. >>>>>>>> >>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> The mentioned patch[1], adds hard coded gluster code into >>>>>>> the >>>>>>> bootstrap code, manipulate the firewall configuration to be >>>>>>> gluster >>>>>>> specific. It hardcoded search for "reject", insert before >>>>>>> some >>>>>>> other >>>>>>> rules. >>>>>>> >>>>>>> I believe this hardcode approach is obsolete now that we >>>>>>> have >>>>>>> proper >>>>>>> tools for templates. >>>>>>> >>>>>>> A more robust solution would be defining generic profiles, >>>>>>> each >>>>>>> profile as a template, each template can refer to different >>>>>>> profiles, and assign profile to a node. >>>>>>> >>>>>>> This way the implementation is not gluster [or any] >>>>>>> specific >>>>>>> and >>>>>>> can >>>>>>> be reused for more setups, code is cleaner. >>>>>> >>>>>> >>>>>> or create custom chains ? >>>>> >>>>> Can you please elaborate what is custom chains? >>>>> Thanks! >>>> >>>> iptables -N my_new_chain >>>> iptables -A my_new_chain >>>> iptables -A my_new_chain ... >>>> iptables -A my_new_chain >>>> >>>> # if this is matched, packet goes through rules in >>>> my_new_chain >>>> iptables -A INPUT -j my_new_chain >>>> >>> >>> Hello, >>> >>> How does this solve the original issue? >> >> It makes it easier for customers who are adding their own IPTables >> configuration - when we do rhev-h plugins it'll make things easier. >> This way we don't wipe out the original rules we just add our own >> chain. >> >> > > Current default (virt) iptables configuration is kept in the engine's DB. > So... > > 1. We can update the DB value to include Gluster configuration. > or > 2. Have an additional DB value for virt+Gluster. 3. gluster only, not virt. > > So (1) will work, but when gluster is not relevant we have redundant port= s. > But my only reservation from (2) is that it's not scalable for additional > services. > > Either way, I agree with Alon that melding the configurations at runtime > is unexpected, and shouldn't be used. > > After some additional thought... we can have (1), and make all gluster > entries commented out (let's say with #GLSTR) by default, so it'll be > enabled only when gluster is being used. This will allow introducing futu= re > configurations as well without the need for additional DB values. why not use the chains approach, and have a chain per service? > > Sample snip of DB value: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > -A INPUT -p icmp -j ACCEPT > -A INPUT -i lo -j ACCEPT > # vdsm > -A INPUT -p tcp --dport 54321 -j ACCEPT > # libvirt tls > -A INPUT -p tcp --dport 16514 -j ACCEPT > # SSH > -A INPUT -p tcp --dport 22 -j ACCEPT > # guest consoles > -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT > # gluster p1 > #GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT > # gluster p2-p6 > #GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT > # Reject any other input traffic > -A INPUT -j REJECT --reject-with icmp-host-prohibited > -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT --reject-with icmp= -host-prohibited > COMMIT > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > > So as you can see, this is something we can handle in run-time. Also it's= easy > to test, so predictable, and finally- human beings can look and understan= d what > it means. > > >>> The need to provide different rules to different hosts by software >>> installed on destination? >>> >>> Standard host needs iptables X. >>> Gluster host needs iptables X+Y. >>> XXX host needs iptables X+Z. >>> Maintainer of Gluster knows what Y is. >>> Maintainer of XXX knows what Z is. >>> >>> If we merge all to one entry product comes with default X. >>> User override X to A. >>> New version of product comes with default Y. >>> Upgrade options: >>> 1. System continues to use A. >>> 2. Some AI to upgrade and create A'. >>> 3. Revert to Y, dropping user's customization. >>> >>> Or we can maintain one large table with complete configuration and >>> conditionals. >>> >>> Alon. > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > --===============8274170167389393015==-- From dfediuck at redhat.com Mon Sep 3 02:09:04 2012 Content-Type: multipart/mixed; boundary="===============2529308778945378917==" MIME-Version: 1.0 From: Doron Fediuck To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 02:09:04 -0400 Message-ID: <1305562668.4309974.1346652544333.JavaMail.root@redhat.com> In-Reply-To: 5043C6DC.1000705@redhat.com --===============2529308778945378917== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Itamar Heim" > To: "Doron Fediuck" > Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org > Sent: Sunday, September 2, 2012 11:51:40 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > On 09/02/2012 05:21 PM, Doron Fediuck wrote: > > ----- Original Message ----- > >> From: "Andrew Cathrow" > >> To: "Alon Bar-Lev" > >> Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org > >> Sent: Friday, August 31, 2012 3:12:34 PM > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > >> > >> > >> > >> ----- Original Message ----- > >>> From: "Alon Bar-Lev" > >>> To: "David Ja=C5=A1a" > >>> Cc: engine-devel(a)ovirt.org > >>> Sent: Friday, August 31, 2012 5:09:47 AM > >>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>> > >>> > >>> > >>> ----- Original Message ----- > >>>> From: "David Ja=C5=A1a" > >>>> To: engine-devel(a)ovirt.org > >>>> Sent: Friday, August 31, 2012 11:57:11 AM > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>> > >>>> Alon Bar-Lev p=C3=AD=C5=A1e v =C4=8Ct 30. 08. 2012 v 14:40 -0400: > >>>>> > >>>>> ----- Original Message ----- > >>>>>> From: "Andrew Cathrow" > >>>>>> To: "Alon Bar-Lev" > >>>>>> Cc: "Shireesh Anjal" , > >>>>>> engine-devel(a)ovirt.org, > >>>>>> "Selvasundaram" > >>>>>> Sent: Thursday, August 30, 2012 9:37:59 PM > >>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>>>> > >>>>>> > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Alon Bar-Lev" > >>>>>>> To: "Selvasundaram" > >>>>>>> Cc: "Shireesh Anjal" , > >>>>>>> engine-devel(a)ovirt.org > >>>>>>> Sent: Thursday, August 30, 2012 2:35:16 PM > >>>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ----- Original Message ----- > >>>>>>>> From: "Selvasundaram" > >>>>>>>> To: engine-devel(a)ovirt.org > >>>>>>>> Cc: "Shireesh Anjal" > >>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > >>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration > >>>>>>>> > >>>>>>>> > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> I want to add gluster specific IPTable configuration in > >>>>>>>> addition > >>>>>>>> to > >>>>>>>> the ovirt IPTable configuration (if it is gluster node). > >>>>>>>> > >>>>>>>> There are two approaches, > >>>>>>>> 1. Having one more gluster specific IP table config in db > >>>>>>>> and > >>>>>>>> merge > >>>>>>>> with ovirt IPTable config (merging NOT appending) > >>>>>>>> [I have the patch engine: Gluster specific firewall > >>>>>>>> configurations > >>>>>>>> #7244] > >>>>>>>> 2. Having two different IP Table config (ovirt and > >>>>>>>> ovirt+gluster) > >>>>>>>> and > >>>>>>>> use either one. > >>>>>>>> > >>>>>>>> Please provide your suggestions or improvements on this. > >>>>>>>> > >>>>>>> > >>>>>>> Hello all, > >>>>>>> > >>>>>>> The mentioned patch[1], adds hard coded gluster code into > >>>>>>> the > >>>>>>> bootstrap code, manipulate the firewall configuration to be > >>>>>>> gluster > >>>>>>> specific. It hardcoded search for "reject", insert before > >>>>>>> some > >>>>>>> other > >>>>>>> rules. > >>>>>>> > >>>>>>> I believe this hardcode approach is obsolete now that we > >>>>>>> have > >>>>>>> proper > >>>>>>> tools for templates. > >>>>>>> > >>>>>>> A more robust solution would be defining generic profiles, > >>>>>>> each > >>>>>>> profile as a template, each template can refer to different > >>>>>>> profiles, and assign profile to a node. > >>>>>>> > >>>>>>> This way the implementation is not gluster [or any] > >>>>>>> specific > >>>>>>> and > >>>>>>> can > >>>>>>> be reused for more setups, code is cleaner. > >>>>>> > >>>>>> > >>>>>> or create custom chains ? > >>>>> > >>>>> Can you please elaborate what is custom chains? > >>>>> Thanks! > >>>> > >>>> iptables -N my_new_chain > >>>> iptables -A my_new_chain > >>>> iptables -A my_new_chain ... > >>>> iptables -A my_new_chain > >>>> > >>>> # if this is matched, packet goes through rules in > >>>> my_new_chain > >>>> iptables -A INPUT -j my_new_chain > >>>> > >>> > >>> Hello, > >>> > >>> How does this solve the original issue? > >> > >> It makes it easier for customers who are adding their own IPTables > >> configuration - when we do rhev-h plugins it'll make things > >> easier. > >> This way we don't wipe out the original rules we just add our own > >> chain. > >> > >> > > > > Current default (virt) iptables configuration is kept in the > > engine's DB. > > So... > > > > 1. We can update the DB value to include Gluster configuration. > > or > > 2. Have an additional DB value for virt+Gluster. > = > 3. gluster only, not virt. > = > > > > So (1) will work, but when gluster is not relevant we have > > redundant ports. > > But my only reservation from (2) is that it's not scalable for > > additional > > services. > > > > Either way, I agree with Alon that melding the configurations at > > runtime > > is unexpected, and shouldn't be used. > > > > After some additional thought... we can have (1), and make all > > gluster > > entries commented out (let's say with #GLSTR) by default, so it'll > > be > > enabled only when gluster is being used. This will allow > > introducing future > > configurations as well without the need for additional DB values. > = > why not use the chains approach, and have a chain per service? > = Since you wish to avoid collisions. So for gluster only, have a VIRT prefix as well. > > > > Sample snip of DB value: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > :INPUT ACCEPT [0:0] > > :FORWARD ACCEPT [0:0] > > :OUTPUT ACCEPT [0:0] > > -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT > > -A INPUT -p icmp -j ACCEPT > > -A INPUT -i lo -j ACCEPT > > # vdsm > > -A INPUT -p tcp --dport 54321 -j ACCEPT > > # libvirt tls > > -A INPUT -p tcp --dport 16514 -j ACCEPT > > # SSH > > -A INPUT -p tcp --dport 22 -j ACCEPT > > # guest consoles > > -A INPUT -p tcp -m multiport --dports 5634:6166 -j ACCEPT > > # gluster p1 > > #GLSTR-A INPUT -p tcp --dport p1 -j ACCEPT > > # gluster p2-p6 > > #GLSTR-A INPUT -p tcp --dport p2:p8 -j ACCEPT > > # Reject any other input traffic > > -A INPUT -j REJECT --reject-with icmp-host-prohibited > > -A FORWARD -m physdev ! --physdev-is-bridged -j REJECT > > --reject-with icmp-host-prohibited > > COMMIT > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > So as you can see, this is something we can handle in run-time. > > Also it's easy > > to test, so predictable, and finally- human beings can look and > > understand what > > it means. > > > > > >>> The need to provide different rules to different hosts by > >>> software > >>> installed on destination? > >>> > >>> Standard host needs iptables X. > >>> Gluster host needs iptables X+Y. > >>> XXX host needs iptables X+Z. > >>> Maintainer of Gluster knows what Y is. > >>> Maintainer of XXX knows what Z is. > >>> > >>> If we merge all to one entry product comes with default X. > >>> User override X to A. > >>> New version of product comes with default Y. > >>> Upgrade options: > >>> 1. System continues to use A. > >>> 2. Some AI to upgrade and create A'. > >>> 3. Revert to Y, dropping user's customization. > >>> > >>> Or we can maintain one large table with complete configuration > >>> and > >>> conditionals. > >>> > >>> Alon. > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============2529308778945378917==-- From alonbl at redhat.com Mon Sep 3 05:51:44 2012 Content-Type: multipart/mixed; boundary="===============5018097464477257031==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 05:51:44 -0400 Message-ID: <776170247.4369474.1346665904154.JavaMail.root@redhat.com> In-Reply-To: 1305562668.4309974.1346652544333.JavaMail.root@redhat.com --===============5018097464477257031== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Doron Fediuck" > To: "Itamar Heim" > Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org > Sent: Monday, September 3, 2012 9:09:04 AM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > > = > > why not use the chains approach, and have a chain per service? > > = > = > Since you wish to avoid collisions. > So for gluster only, have a VIRT prefix as well. If an implementation may separate between the WHAT and the HOW, it may be e= asier to be maintained. --- WHAT Merge several iptables rules into one node iptables. HOW Use templates to build string, send string as a file in remote. --- As you can see the HOW (which is the actual implementation) knows nothing a= bout iptables. So it is simple and can be reused. The whole logic of WHAT i= s put into the metadata, where humans may customized without touching the c= ode, even when iptables get messy and complex. An example of WHAT and HOW that are not separated is the authentication/aut= horization (Kerberos/LDAP) implementation, where both WHAT and HOW are inte= r-connected, the cost of adding a new environment in this case is huge. Doron suggested to use comments or some signature within the iptables confi= guration, this is what templates are all about, however, instead of re-inve= nting the wheel, a standard text based templates engine can be used. The template (the WHAT) may use custom chains, regular chains, it is not im= portant as implementation (the HOW) is not looking into the content. Alon. --===============5018097464477257031==-- From djasa at redhat.com Mon Sep 3 07:42:59 2012 Content-Type: multipart/mixed; boundary="===============0680615060450274702==" MIME-Version: 1.0 From: =?utf-8?q?David_Ja=C5=A1a_=3Cdjasa_at_redhat=2Ecom=3E?= To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 13:42:56 +0200 Message-ID: <1346672576.15842.126.camel@dhcp-29-7.brq.redhat.com> In-Reply-To: 776170247.4369474.1346665904154.JavaMail.root@redhat.com --===============0680615060450274702== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable what about using netcf for the configuration similarly as libvirt does? http://libvirt.org/formatnwfilter.html IMHO it should solve the problem temporarily before firewalld matures. David PS: please keep me out of CC, I'm more than happy when I watch these discussions via list Alon Bar-Lev p=C3=AD=C5=A1e v Po 03. 09. 2012 v 05:51 -0400: > = > ----- Original Message ----- > > From: "Doron Fediuck" > > To: "Itamar Heim" > > Cc: "David Ja=C5=A1a" , engine-devel(a)ovirt.org > > Sent: Monday, September 3, 2012 9:09:04 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > > = > > > why not use the chains approach, and have a chain per service? > > > = > > = > > Since you wish to avoid collisions. > > So for gluster only, have a VIRT prefix as well. > = > If an implementation may separate between the WHAT and the HOW, it may be= easier to be maintained. > = > --- > WHAT > = > Merge several iptables rules into one node iptables. > = > HOW > = > Use templates to build string, send string as a file in remote. > --- > = > As you can see the HOW (which is the actual implementation) knows nothing= about iptables. So it is simple and can be reused. The whole logic of WHAT= is put into the metadata, where humans may customized without touching the= code, even when iptables get messy and complex. > = > An example of WHAT and HOW that are not separated is the authentication/a= uthorization (Kerberos/LDAP) implementation, where both WHAT and HOW are in= ter-connected, the cost of adding a new environment in this case is huge. > = > Doron suggested to use comments or some signature within the iptables con= figuration, this is what templates are all about, however, instead of re-in= venting the wheel, a standard text based templates engine can be used. > = > The template (the WHAT) may use custom chains, regular chains, it is not = important as implementation (the HOW) is not looking into the content. > = > Alon. > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- = David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 = Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 --===============0680615060450274702==-- From sanjal at redhat.com Mon Sep 3 08:42:37 2012 Content-Type: multipart/mixed; boundary="===============7484465058576604158==" MIME-Version: 1.0 From: Shireesh Anjal To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 18:12:17 +0530 Message-ID: <5044A5A9.1090008@redhat.com> In-Reply-To: 278376844.4015237.1346351716576.JavaMail.root@redhat.com --===============7484465058576604158== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Selvasundaram" >> To: engine-devel(a)ovirt.org >> Cc: "Shireesh Anjal" >> Sent: Thursday, August 30, 2012 4:30:16 PM >> Subject: [Engine-devel] Gluster IPTable configuration >> >> >> Hi, >> >> I want to add gluster specific IPTable configuration in addition to >> the ovirt IPTable configuration (if it is gluster node). >> >> There are two approaches, >> 1. Having one more gluster specific IP table config in db and merge >> with ovirt IPTable config (merging NOT appending) >> [I have the patch engine: Gluster specific firewall configurations >> #7244] >> 2. Having two different IP Table config (ovirt and ovirt+gluster) and >> use either one. >> >> Please provide your suggestions or improvements on this. >> > Hello all, > > The mentioned patch[1], adds hard coded gluster code into the bootstrap c= ode, manipulate the firewall configuration to be gluster specific. It hardc= oded search for "reject", insert before some other rules. > > I believe this hardcode approach is obsolete now that we have proper tool= s for templates. > > A more robust solution would be defining generic profiles, each profile a= s a template, each template can refer to different profiles, and assign pro= file to a node. > > This way the implementation is not gluster [or any] specific and can be r= eused for more setups, code is cleaner. > > Example: > > BASIC.PRE > :INPUT ACCEPT [0:0] > :FORWARD ACCEPT [0:0] > :OUTPUT ACCEPT [0:0] > BASIC.IN > accept ... > accept ... > BASIC.POST > reject ... > reject ... > > BASIC > ${BASIC.PRE} > ${BASIC.IN} > ${BASIC.POST} > > GLUSTER > ${BASIC.PRE} > ${BASIC.IN} > accept ... > ${BASIC.POST} > reject ... I like the separation of PRE/IN/POST rules here. However I think it is = better to keep the service specific rules in separate configurations. = Currently, whole iptables rules script is kept in the vdc option = "IPTablesConfig". How about changing this as follows? - Split the current config into three: IPTablesConfig.PRE, = IPTablesConfig.VIRT and IPTablesConfig.POST - Let services like Gluster add their own vdc options e.g. = IPTablesConfig.GLUSTER - When assembling the full script in VdsInstaller, - Take IPTablesConfig.PRE - Append it with IPTablesConfig. for every service to be = enabled on the host/cluster - Append it with IPTablesConfig.POST Thoughts? > > Regards, > Alon Bar-Lev > > [1] http://gerrit.ovirt.org/#/c/7244/ > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --===============7484465058576604158==-- From alonbl at redhat.com Mon Sep 3 08:52:38 2012 Content-Type: multipart/mixed; boundary="===============8121238495358940879==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 08:52:37 -0400 Message-ID: <992596012.4387628.1346676757949.JavaMail.root@redhat.com> In-Reply-To: 5044A5A9.1090008@redhat.com --===============8121238495358940879== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shireesh Anjal" > To: engine-devel(a)ovirt.org > Cc: "Alon Bar-Lev" , "Selvasundaram" > Sent: Monday, September 3, 2012 3:42:17 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > > > ----- Original Message ----- > >> From: "Selvasundaram" > >> To: engine-devel(a)ovirt.org > >> Cc: "Shireesh Anjal" > >> Sent: Thursday, August 30, 2012 4:30:16 PM > >> Subject: [Engine-devel] Gluster IPTable configuration > >> > >> > >> Hi, > >> > >> I want to add gluster specific IPTable configuration in addition > >> to > >> the ovirt IPTable configuration (if it is gluster node). > >> > >> There are two approaches, > >> 1. Having one more gluster specific IP table config in db and > >> merge > >> with ovirt IPTable config (merging NOT appending) > >> [I have the patch engine: Gluster specific firewall configurations > >> #7244] > >> 2. Having two different IP Table config (ovirt and ovirt+gluster) > >> and > >> use either one. > >> > >> Please provide your suggestions or improvements on this. > >> > > Hello all, > > > > The mentioned patch[1], adds hard coded gluster code into the > > bootstrap code, manipulate the firewall configuration to be > > gluster specific. It hardcoded search for "reject", insert before > > some other rules. > > > > I believe this hardcode approach is obsolete now that we have > > proper tools for templates. > > > > A more robust solution would be defining generic profiles, each > > profile as a template, each template can refer to different > > profiles, and assign profile to a node. > > > > This way the implementation is not gluster [or any] specific and > > can be reused for more setups, code is cleaner. > > > > Example: > > > > BASIC.PRE > > :INPUT ACCEPT [0:0] > > :FORWARD ACCEPT [0:0] > > :OUTPUT ACCEPT [0:0] > > BASIC.IN > > accept ... > > accept ... > > BASIC.POST > > reject ... > > reject ... > > > > BASIC > > ${BASIC.PRE} > > ${BASIC.IN} > > ${BASIC.POST} > > > > GLUSTER > > ${BASIC.PRE} > > ${BASIC.IN} > > accept ... > > ${BASIC.POST} > > reject ... > = > I like the separation of PRE/IN/POST rules here. However I think it > is > better to keep the service specific rules in separate configurations. > Currently, whole iptables rules script is kept in the vdc option > "IPTablesConfig". How about changing this as follows? > = > - Split the current config into three: IPTablesConfig.PRE, > IPTablesConfig.VIRT and IPTablesConfig.POST > - Let services like Gluster add their own vdc options e.g. > IPTablesConfig.GLUSTER > - When assembling the full script in VdsInstaller, > - Take IPTablesConfig.PRE > - Append it with IPTablesConfig. for every service to be > enabled on the host/cluster > - Append it with IPTablesConfig.POST > = > Thoughts? This is a simple approach that will work for current implementation and con= figuration. However, it will effect all nodes, with or without gluster. I think that while we at it we should consider how to effect only appropria= te subset of nodes. Alon. --===============8121238495358940879==-- From sanjal at redhat.com Mon Sep 3 09:00:41 2012 Content-Type: multipart/mixed; boundary="===============8428353973280260170==" MIME-Version: 1.0 From: Shireesh Anjal To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 18:30:14 +0530 Message-ID: <5044A9DE.3090501@redhat.com> In-Reply-To: 992596012.4387628.1346676757949.JavaMail.root@redhat.com --===============8428353973280260170== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Shireesh Anjal" >> To: engine-devel(a)ovirt.org >> Cc: "Alon Bar-Lev" , "Selvasundaram" >> Sent: Monday, September 3, 2012 3:42:17 PM >> Subject: Re: [Engine-devel] Gluster IPTable configuration >> >> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: >>> ----- Original Message ----- >>>> From: "Selvasundaram" >>>> To: engine-devel(a)ovirt.org >>>> Cc: "Shireesh Anjal" >>>> Sent: Thursday, August 30, 2012 4:30:16 PM >>>> Subject: [Engine-devel] Gluster IPTable configuration >>>> >>>> >>>> Hi, >>>> >>>> I want to add gluster specific IPTable configuration in addition >>>> to >>>> the ovirt IPTable configuration (if it is gluster node). >>>> >>>> There are two approaches, >>>> 1. Having one more gluster specific IP table config in db and >>>> merge >>>> with ovirt IPTable config (merging NOT appending) >>>> [I have the patch engine: Gluster specific firewall configurations >>>> #7244] >>>> 2. Having two different IP Table config (ovirt and ovirt+gluster) >>>> and >>>> use either one. >>>> >>>> Please provide your suggestions or improvements on this. >>>> >>> Hello all, >>> >>> The mentioned patch[1], adds hard coded gluster code into the >>> bootstrap code, manipulate the firewall configuration to be >>> gluster specific. It hardcoded search for "reject", insert before >>> some other rules. >>> >>> I believe this hardcode approach is obsolete now that we have >>> proper tools for templates. >>> >>> A more robust solution would be defining generic profiles, each >>> profile as a template, each template can refer to different >>> profiles, and assign profile to a node. >>> >>> This way the implementation is not gluster [or any] specific and >>> can be reused for more setups, code is cleaner. >>> >>> Example: >>> >>> BASIC.PRE >>> :INPUT ACCEPT [0:0] >>> :FORWARD ACCEPT [0:0] >>> :OUTPUT ACCEPT [0:0] >>> BASIC.IN >>> accept ... >>> accept ... >>> BASIC.POST >>> reject ... >>> reject ... >>> >>> BASIC >>> ${BASIC.PRE} >>> ${BASIC.IN} >>> ${BASIC.POST} >>> >>> GLUSTER >>> ${BASIC.PRE} >>> ${BASIC.IN} >>> accept ... >>> ${BASIC.POST} >>> reject ... >> I like the separation of PRE/IN/POST rules here. However I think it >> is >> better to keep the service specific rules in separate configurations. >> Currently, whole iptables rules script is kept in the vdc option >> "IPTablesConfig". How about changing this as follows? >> >> - Split the current config into three: IPTablesConfig.PRE, >> IPTablesConfig.VIRT and IPTablesConfig.POST >> - Let services like Gluster add their own vdc options e.g. >> IPTablesConfig.GLUSTER >> - When assembling the full script in VdsInstaller, >> - Take IPTablesConfig.PRE >> - Append it with IPTablesConfig. for every service to be >> enabled on the host/cluster >> - Append it with IPTablesConfig.POST >> >> Thoughts? > This is a simple approach that will work for current implementation and c= onfiguration. > > However, it will effect all nodes, with or without gluster. I don't get the concern here. Could you please elaborate? > > I think that while we at it we should consider how to effect only appropr= iate subset of nodes. > > Alon. --===============8428353973280260170==-- From alonbl at redhat.com Mon Sep 3 09:11:57 2012 Content-Type: multipart/mixed; boundary="===============6171173114118298063==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 09:11:57 -0400 Message-ID: <34986317.4390291.1346677917107.JavaMail.root@redhat.com> In-Reply-To: 5044A9DE.3090501@redhat.com --===============6171173114118298063== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shireesh Anjal" > To: "Alon Bar-Lev" > Cc: "Selvasundaram" , engine-devel(a)ovirt.org > Sent: Monday, September 3, 2012 4:00:14 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > > > ----- Original Message ----- > >> From: "Shireesh Anjal" > >> To: engine-devel(a)ovirt.org > >> Cc: "Alon Bar-Lev" , "Selvasundaram" > >> > >> Sent: Monday, September 3, 2012 3:42:17 PM > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > >> > >> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > >>> ----- Original Message ----- > >>>> From: "Selvasundaram" > >>>> To: engine-devel(a)ovirt.org > >>>> Cc: "Shireesh Anjal" > >>>> Sent: Thursday, August 30, 2012 4:30:16 PM > >>>> Subject: [Engine-devel] Gluster IPTable configuration > >>>> > >>>> > >>>> Hi, > >>>> > >>>> I want to add gluster specific IPTable configuration in addition > >>>> to > >>>> the ovirt IPTable configuration (if it is gluster node). > >>>> > >>>> There are two approaches, > >>>> 1. Having one more gluster specific IP table config in db and > >>>> merge > >>>> with ovirt IPTable config (merging NOT appending) > >>>> [I have the patch engine: Gluster specific firewall > >>>> configurations > >>>> #7244] > >>>> 2. Having two different IP Table config (ovirt and > >>>> ovirt+gluster) > >>>> and > >>>> use either one. > >>>> > >>>> Please provide your suggestions or improvements on this. > >>>> > >>> Hello all, > >>> > >>> The mentioned patch[1], adds hard coded gluster code into the > >>> bootstrap code, manipulate the firewall configuration to be > >>> gluster specific. It hardcoded search for "reject", insert before > >>> some other rules. > >>> > >>> I believe this hardcode approach is obsolete now that we have > >>> proper tools for templates. > >>> > >>> A more robust solution would be defining generic profiles, each > >>> profile as a template, each template can refer to different > >>> profiles, and assign profile to a node. > >>> > >>> This way the implementation is not gluster [or any] specific and > >>> can be reused for more setups, code is cleaner. > >>> > >>> Example: > >>> > >>> BASIC.PRE > >>> :INPUT ACCEPT [0:0] > >>> :FORWARD ACCEPT [0:0] > >>> :OUTPUT ACCEPT [0:0] > >>> BASIC.IN > >>> accept ... > >>> accept ... > >>> BASIC.POST > >>> reject ... > >>> reject ... > >>> > >>> BASIC > >>> ${BASIC.PRE} > >>> ${BASIC.IN} > >>> ${BASIC.POST} > >>> > >>> GLUSTER > >>> ${BASIC.PRE} > >>> ${BASIC.IN} > >>> accept ... > >>> ${BASIC.POST} > >>> reject ... > >> I like the separation of PRE/IN/POST rules here. However I think > >> it > >> is > >> better to keep the service specific rules in separate > >> configurations. > >> Currently, whole iptables rules script is kept in the vdc option > >> "IPTablesConfig". How about changing this as follows? > >> > >> - Split the current config into three: IPTablesConfig.PRE, > >> IPTablesConfig.VIRT and IPTablesConfig.POST > >> - Let services like Gluster add their own vdc options e.g. > >> IPTablesConfig.GLUSTER > >> - When assembling the full script in VdsInstaller, > >> - Take IPTablesConfig.PRE > >> - Append it with IPTablesConfig. for every service to > >> be > >> enabled on the host/cluster > >> - Append it with IPTablesConfig.POST > >> > >> Thoughts? > > This is a simple approach that will work for current implementation > > and configuration. > > > > However, it will effect all nodes, with or without gluster. > = > I don't get the concern here. Could you please elaborate? If we have 500 nodes, out of them 200 gluster, why do I need to distribute = gluster specific rules to all 500? Alon. --===============6171173114118298063==-- From sanjal at redhat.com Mon Sep 3 09:22:17 2012 Content-Type: multipart/mixed; boundary="===============9153105408058428383==" MIME-Version: 1.0 From: Shireesh Anjal To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 18:51:58 +0530 Message-ID: <5044AEF6.7090309@redhat.com> In-Reply-To: 34986317.4390291.1346677917107.JavaMail.root@redhat.com --===============9153105408058428383== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Shireesh Anjal" >> To: "Alon Bar-Lev" >> Cc: "Selvasundaram" , engine-devel(a)ovirt.org >> Sent: Monday, September 3, 2012 4:00:14 PM >> Subject: Re: [Engine-devel] Gluster IPTable configuration >> >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: >>> ----- Original Message ----- >>>> From: "Shireesh Anjal" >>>> To: engine-devel(a)ovirt.org >>>> Cc: "Alon Bar-Lev" , "Selvasundaram" >>>> >>>> Sent: Monday, September 3, 2012 3:42:17 PM >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>> >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: >>>>> ----- Original Message ----- >>>>>> From: "Selvasundaram" >>>>>> To: engine-devel(a)ovirt.org >>>>>> Cc: "Shireesh Anjal" >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM >>>>>> Subject: [Engine-devel] Gluster IPTable configuration >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> I want to add gluster specific IPTable configuration in addition >>>>>> to >>>>>> the ovirt IPTable configuration (if it is gluster node). >>>>>> >>>>>> There are two approaches, >>>>>> 1. Having one more gluster specific IP table config in db and >>>>>> merge >>>>>> with ovirt IPTable config (merging NOT appending) >>>>>> [I have the patch engine: Gluster specific firewall >>>>>> configurations >>>>>> #7244] >>>>>> 2. Having two different IP Table config (ovirt and >>>>>> ovirt+gluster) >>>>>> and >>>>>> use either one. >>>>>> >>>>>> Please provide your suggestions or improvements on this. >>>>>> >>>>> Hello all, >>>>> >>>>> The mentioned patch[1], adds hard coded gluster code into the >>>>> bootstrap code, manipulate the firewall configuration to be >>>>> gluster specific. It hardcoded search for "reject", insert before >>>>> some other rules. >>>>> >>>>> I believe this hardcode approach is obsolete now that we have >>>>> proper tools for templates. >>>>> >>>>> A more robust solution would be defining generic profiles, each >>>>> profile as a template, each template can refer to different >>>>> profiles, and assign profile to a node. >>>>> >>>>> This way the implementation is not gluster [or any] specific and >>>>> can be reused for more setups, code is cleaner. >>>>> >>>>> Example: >>>>> >>>>> BASIC.PRE >>>>> :INPUT ACCEPT [0:0] >>>>> :FORWARD ACCEPT [0:0] >>>>> :OUTPUT ACCEPT [0:0] >>>>> BASIC.IN >>>>> accept ... >>>>> accept ... >>>>> BASIC.POST >>>>> reject ... >>>>> reject ... >>>>> >>>>> BASIC >>>>> ${BASIC.PRE} >>>>> ${BASIC.IN} >>>>> ${BASIC.POST} >>>>> >>>>> GLUSTER >>>>> ${BASIC.PRE} >>>>> ${BASIC.IN} >>>>> accept ... >>>>> ${BASIC.POST} >>>>> reject ... >>>> I like the separation of PRE/IN/POST rules here. However I think >>>> it >>>> is >>>> better to keep the service specific rules in separate >>>> configurations. >>>> Currently, whole iptables rules script is kept in the vdc option >>>> "IPTablesConfig". How about changing this as follows? >>>> >>>> - Split the current config into three: IPTablesConfig.PRE, >>>> IPTablesConfig.VIRT and IPTablesConfig.POST >>>> - Let services like Gluster add their own vdc options e.g. >>>> IPTablesConfig.GLUSTER >>>> - When assembling the full script in VdsInstaller, >>>> - Take IPTablesConfig.PRE >>>> - Append it with IPTablesConfig. for every service to >>>> be >>>> enabled on the host/cluster >>>> - Append it with IPTablesConfig.POST >>>> >>>> Thoughts? >>> This is a simple approach that will work for current implementation >>> and configuration. >>> >>> However, it will effect all nodes, with or without gluster. >> I don't get the concern here. Could you please elaborate? > If we have 500 nodes, out of them 200 gluster, why do I need to distribut= e gluster specific rules to all 500? When I say "Append it with IPTablesConfig. for every service to be= enabled on the host/cluster", I mean every service that "needs to be enabl= ed" on the host. In today's scenario, where virt and gluster are the only t= wo services, it will look something like: - If cluster supports virt, append IPTablesConfig.VIRT - If cluster supports gluster, append IPTablesConfig.GLUSTER So it will be driven by the cluster in which the host is being added. And g= luster rules will be sent to only the hosts of clusters that have gluster e= nabled. > > Alon. --===============9153105408058428383==-- From alonbl at redhat.com Mon Sep 3 09:50:53 2012 Content-Type: multipart/mixed; boundary="===============8610126054061656306==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 09:50:52 -0400 Message-ID: <1943701531.4395068.1346680252910.JavaMail.root@redhat.com> In-Reply-To: 5044AEF6.7090309@redhat.com --===============8610126054061656306== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Shireesh Anjal" > To: "Alon Bar-Lev" > Cc: "Selvasundaram" , engine-devel(a)ovirt.org > Sent: Monday, September 3, 2012 4:21:58 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > > > ----- Original Message ----- > >> From: "Shireesh Anjal" > >> To: "Alon Bar-Lev" > >> Cc: "Selvasundaram" , engine-devel(a)ovirt.org > >> Sent: Monday, September 3, 2012 4:00:14 PM > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > >> > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > >>> ----- Original Message ----- > >>>> From: "Shireesh Anjal" > >>>> To: engine-devel(a)ovirt.org > >>>> Cc: "Alon Bar-Lev" , "Selvasundaram" > >>>> > >>>> Sent: Monday, September 3, 2012 3:42:17 PM > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > >>>> > >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > >>>>> ----- Original Message ----- > >>>>>> From: "Selvasundaram" > >>>>>> To: engine-devel(a)ovirt.org > >>>>>> Cc: "Shireesh Anjal" > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration > >>>>>> > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I want to add gluster specific IPTable configuration in > >>>>>> addition > >>>>>> to > >>>>>> the ovirt IPTable configuration (if it is gluster node). > >>>>>> > >>>>>> There are two approaches, > >>>>>> 1. Having one more gluster specific IP table config in db and > >>>>>> merge > >>>>>> with ovirt IPTable config (merging NOT appending) > >>>>>> [I have the patch engine: Gluster specific firewall > >>>>>> configurations > >>>>>> #7244] > >>>>>> 2. Having two different IP Table config (ovirt and > >>>>>> ovirt+gluster) > >>>>>> and > >>>>>> use either one. > >>>>>> > >>>>>> Please provide your suggestions or improvements on this. > >>>>>> > >>>>> Hello all, > >>>>> > >>>>> The mentioned patch[1], adds hard coded gluster code into the > >>>>> bootstrap code, manipulate the firewall configuration to be > >>>>> gluster specific. It hardcoded search for "reject", insert > >>>>> before > >>>>> some other rules. > >>>>> > >>>>> I believe this hardcode approach is obsolete now that we have > >>>>> proper tools for templates. > >>>>> > >>>>> A more robust solution would be defining generic profiles, each > >>>>> profile as a template, each template can refer to different > >>>>> profiles, and assign profile to a node. > >>>>> > >>>>> This way the implementation is not gluster [or any] specific > >>>>> and > >>>>> can be reused for more setups, code is cleaner. > >>>>> > >>>>> Example: > >>>>> > >>>>> BASIC.PRE > >>>>> :INPUT ACCEPT [0:0] > >>>>> :FORWARD ACCEPT [0:0] > >>>>> :OUTPUT ACCEPT [0:0] > >>>>> BASIC.IN > >>>>> accept ... > >>>>> accept ... > >>>>> BASIC.POST > >>>>> reject ... > >>>>> reject ... > >>>>> > >>>>> BASIC > >>>>> ${BASIC.PRE} > >>>>> ${BASIC.IN} > >>>>> ${BASIC.POST} > >>>>> > >>>>> GLUSTER > >>>>> ${BASIC.PRE} > >>>>> ${BASIC.IN} > >>>>> accept ... > >>>>> ${BASIC.POST} > >>>>> reject ... > >>>> I like the separation of PRE/IN/POST rules here. However I think > >>>> it > >>>> is > >>>> better to keep the service specific rules in separate > >>>> configurations. > >>>> Currently, whole iptables rules script is kept in the vdc option > >>>> "IPTablesConfig". How about changing this as follows? > >>>> > >>>> - Split the current config into three: IPTablesConfig.PRE, > >>>> IPTablesConfig.VIRT and IPTablesConfig.POST > >>>> - Let services like Gluster add their own vdc options e.g. > >>>> IPTablesConfig.GLUSTER > >>>> - When assembling the full script in VdsInstaller, > >>>> - Take IPTablesConfig.PRE > >>>> - Append it with IPTablesConfig. for every service > >>>> to > >>>> be > >>>> enabled on the host/cluster > >>>> - Append it with IPTablesConfig.POST > >>>> > >>>> Thoughts? > >>> This is a simple approach that will work for current > >>> implementation > >>> and configuration. > >>> > >>> However, it will effect all nodes, with or without gluster. > >> I don't get the concern here. Could you please elaborate? > > If we have 500 nodes, out of them 200 gluster, why do I need to > > distribute gluster specific rules to all 500? > = > When I say "Append it with IPTablesConfig. for every service > to be enabled on the host/cluster", I mean every service that "needs > to be enabled" on the host. In today's scenario, where virt and > gluster are the only two services, it will look something like: > = > - If cluster supports virt, append IPTablesConfig.VIRT > - If cluster supports gluster, append IPTablesConfig.GLUSTER > = > So it will be driven by the cluster in which the host is being added. > And gluster rules will be sent to only the hosts of clusters that > have gluster enabled. OK... this is why I prefer templates. Much more simple and generic. No need= to have custom application logic within application. Alon --===============8610126054061656306==-- From sanjal at redhat.com Mon Sep 3 10:35:01 2012 Content-Type: multipart/mixed; boundary="===============8740361949901427296==" MIME-Version: 1.0 From: Shireesh Anjal To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 20:04:41 +0530 Message-ID: <5044C001.9080106@redhat.com> In-Reply-To: 1943701531.4395068.1346680252910.JavaMail.root@redhat.com --===============8740361949901427296== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Monday 03 September 2012 07:20 PM, Alon Bar-Lev wrote: > > ----- Original Message ----- >> From: "Shireesh Anjal" >> To: "Alon Bar-Lev" >> Cc: "Selvasundaram" , engine-devel(a)ovirt.org >> Sent: Monday, September 3, 2012 4:21:58 PM >> Subject: Re: [Engine-devel] Gluster IPTable configuration >> >> On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: >>> ----- Original Message ----- >>>> From: "Shireesh Anjal" >>>> To: "Alon Bar-Lev" >>>> Cc: "Selvasundaram" , engine-devel(a)ovirt.org >>>> Sent: Monday, September 3, 2012 4:00:14 PM >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>> >>>> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: >>>>> ----- Original Message ----- >>>>>> From: "Shireesh Anjal" >>>>>> To: engine-devel(a)ovirt.org >>>>>> Cc: "Alon Bar-Lev" , "Selvasundaram" >>>>>> >>>>>> Sent: Monday, September 3, 2012 3:42:17 PM >>>>>> Subject: Re: [Engine-devel] Gluster IPTable configuration >>>>>> >>>>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: >>>>>>> ----- Original Message ----- >>>>>>>> From: "Selvasundaram" >>>>>>>> To: engine-devel(a)ovirt.org >>>>>>>> Cc: "Shireesh Anjal" >>>>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM >>>>>>>> Subject: [Engine-devel] Gluster IPTable configuration >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I want to add gluster specific IPTable configuration in >>>>>>>> addition >>>>>>>> to >>>>>>>> the ovirt IPTable configuration (if it is gluster node). >>>>>>>> >>>>>>>> There are two approaches, >>>>>>>> 1. Having one more gluster specific IP table config in db and >>>>>>>> merge >>>>>>>> with ovirt IPTable config (merging NOT appending) >>>>>>>> [I have the patch engine: Gluster specific firewall >>>>>>>> configurations >>>>>>>> #7244] >>>>>>>> 2. Having two different IP Table config (ovirt and >>>>>>>> ovirt+gluster) >>>>>>>> and >>>>>>>> use either one. >>>>>>>> >>>>>>>> Please provide your suggestions or improvements on this. >>>>>>>> >>>>>>> Hello all, >>>>>>> >>>>>>> The mentioned patch[1], adds hard coded gluster code into the >>>>>>> bootstrap code, manipulate the firewall configuration to be >>>>>>> gluster specific. It hardcoded search for "reject", insert >>>>>>> before >>>>>>> some other rules. >>>>>>> >>>>>>> I believe this hardcode approach is obsolete now that we have >>>>>>> proper tools for templates. >>>>>>> >>>>>>> A more robust solution would be defining generic profiles, each >>>>>>> profile as a template, each template can refer to different >>>>>>> profiles, and assign profile to a node. >>>>>>> >>>>>>> This way the implementation is not gluster [or any] specific >>>>>>> and >>>>>>> can be reused for more setups, code is cleaner. >>>>>>> >>>>>>> Example: >>>>>>> >>>>>>> BASIC.PRE >>>>>>> :INPUT ACCEPT [0:0] >>>>>>> :FORWARD ACCEPT [0:0] >>>>>>> :OUTPUT ACCEPT [0:0] >>>>>>> BASIC.IN >>>>>>> accept ... >>>>>>> accept ... >>>>>>> BASIC.POST >>>>>>> reject ... >>>>>>> reject ... >>>>>>> >>>>>>> BASIC >>>>>>> ${BASIC.PRE} >>>>>>> ${BASIC.IN} >>>>>>> ${BASIC.POST} >>>>>>> >>>>>>> GLUSTER >>>>>>> ${BASIC.PRE} >>>>>>> ${BASIC.IN} >>>>>>> accept ... >>>>>>> ${BASIC.POST} >>>>>>> reject ... >>>>>> I like the separation of PRE/IN/POST rules here. However I think >>>>>> it >>>>>> is >>>>>> better to keep the service specific rules in separate >>>>>> configurations. >>>>>> Currently, whole iptables rules script is kept in the vdc option >>>>>> "IPTablesConfig". How about changing this as follows? >>>>>> >>>>>> - Split the current config into three: IPTablesConfig.PRE, >>>>>> IPTablesConfig.VIRT and IPTablesConfig.POST >>>>>> - Let services like Gluster add their own vdc options e.g. >>>>>> IPTablesConfig.GLUSTER >>>>>> - When assembling the full script in VdsInstaller, >>>>>> - Take IPTablesConfig.PRE >>>>>> - Append it with IPTablesConfig. for every service >>>>>> to >>>>>> be >>>>>> enabled on the host/cluster >>>>>> - Append it with IPTablesConfig.POST >>>>>> >>>>>> Thoughts? >>>>> This is a simple approach that will work for current >>>>> implementation >>>>> and configuration. >>>>> >>>>> However, it will effect all nodes, with or without gluster. >>>> I don't get the concern here. Could you please elaborate? >>> If we have 500 nodes, out of them 200 gluster, why do I need to >>> distribute gluster specific rules to all 500? >> When I say "Append it with IPTablesConfig. for every service >> to be enabled on the host/cluster", I mean every service that "needs >> to be enabled" on the host. In today's scenario, where virt and >> gluster are the only two services, it will look something like: >> >> - If cluster supports virt, append IPTablesConfig.VIRT >> - If cluster supports gluster, append IPTablesConfig.GLUSTER >> >> So it will be driven by the cluster in which the host is being added. >> And gluster rules will be sent to only the hosts of clusters that >> have gluster enabled. > OK... this is why I prefer templates. Much more simple and generic. No ne= ed to have custom application logic within application. I don't see what is so complex about the above approach, but do agree = that it is not completely generic. A new service will require a new if = condition in the VdsInstaller. In order to understand the templates approach better, can you please = point me to some existing code in oVirt that uses such an approach? I = see an example of the template text above, but I'm not sure how it can = be used from the code. > > Alon > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --===============8740361949901427296==-- From acathrow at redhat.com Mon Sep 3 16:05:23 2012 Content-Type: multipart/mixed; boundary="===============0398962432298371348==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 16:05:20 -0400 Message-ID: <379791011.4807536.1346702720899.JavaMail.root@redhat.com> In-Reply-To: 1943701531.4395068.1346680252910.JavaMail.root@redhat.com --===============0398962432298371348== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Shireesh Anjal" > Cc: engine-devel(a)ovirt.org > Sent: Monday, September 3, 2012 9:50:52 AM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Shireesh Anjal" > > To: "Alon Bar-Lev" > > Cc: "Selvasundaram" , engine-devel(a)ovirt.org > > Sent: Monday, September 3, 2012 4:21:58 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > > > > > ----- Original Message ----- > > >> From: "Shireesh Anjal" > > >> To: "Alon Bar-Lev" > > >> Cc: "Selvasundaram" , > > >> engine-devel(a)ovirt.org > > >> Sent: Monday, September 3, 2012 4:00:14 PM > > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > > >> > > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > >>> ----- Original Message ----- > > >>>> From: "Shireesh Anjal" > > >>>> To: engine-devel(a)ovirt.org > > >>>> Cc: "Alon Bar-Lev" , "Selvasundaram" > > >>>> > > >>>> Sent: Monday, September 3, 2012 3:42:17 PM > > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > > >>>> > > >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > >>>>> ----- Original Message ----- > > >>>>>> From: "Selvasundaram" > > >>>>>> To: engine-devel(a)ovirt.org > > >>>>>> Cc: "Shireesh Anjal" > > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration > > >>>>>> > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I want to add gluster specific IPTable configuration in > > >>>>>> addition > > >>>>>> to > > >>>>>> the ovirt IPTable configuration (if it is gluster node). > > >>>>>> > > >>>>>> There are two approaches, > > >>>>>> 1. Having one more gluster specific IP table config in db > > >>>>>> and > > >>>>>> merge > > >>>>>> with ovirt IPTable config (merging NOT appending) > > >>>>>> [I have the patch engine: Gluster specific firewall > > >>>>>> configurations > > >>>>>> #7244] > > >>>>>> 2. Having two different IP Table config (ovirt and > > >>>>>> ovirt+gluster) > > >>>>>> and > > >>>>>> use either one. > > >>>>>> > > >>>>>> Please provide your suggestions or improvements on this. > > >>>>>> > > >>>>> Hello all, > > >>>>> > > >>>>> The mentioned patch[1], adds hard coded gluster code into the > > >>>>> bootstrap code, manipulate the firewall configuration to be > > >>>>> gluster specific. It hardcoded search for "reject", insert > > >>>>> before > > >>>>> some other rules. > > >>>>> > > >>>>> I believe this hardcode approach is obsolete now that we have > > >>>>> proper tools for templates. > > >>>>> > > >>>>> A more robust solution would be defining generic profiles, > > >>>>> each > > >>>>> profile as a template, each template can refer to different > > >>>>> profiles, and assign profile to a node. > > >>>>> > > >>>>> This way the implementation is not gluster [or any] specific > > >>>>> and > > >>>>> can be reused for more setups, code is cleaner. > > >>>>> > > >>>>> Example: > > >>>>> > > >>>>> BASIC.PRE > > >>>>> :INPUT ACCEPT [0:0] > > >>>>> :FORWARD ACCEPT [0:0] > > >>>>> :OUTPUT ACCEPT [0:0] > > >>>>> BASIC.IN > > >>>>> accept ... > > >>>>> accept ... > > >>>>> BASIC.POST > > >>>>> reject ... > > >>>>> reject ... > > >>>>> > > >>>>> BASIC > > >>>>> ${BASIC.PRE} > > >>>>> ${BASIC.IN} > > >>>>> ${BASIC.POST} > > >>>>> > > >>>>> GLUSTER > > >>>>> ${BASIC.PRE} > > >>>>> ${BASIC.IN} > > >>>>> accept ... > > >>>>> ${BASIC.POST} > > >>>>> reject ... > > >>>> I like the separation of PRE/IN/POST rules here. However I > > >>>> think > > >>>> it > > >>>> is > > >>>> better to keep the service specific rules in separate > > >>>> configurations. > > >>>> Currently, whole iptables rules script is kept in the vdc > > >>>> option > > >>>> "IPTablesConfig". How about changing this as follows? > > >>>> > > >>>> - Split the current config into three: IPTablesConfig.PRE, > > >>>> IPTablesConfig.VIRT and IPTablesConfig.POST > > >>>> - Let services like Gluster add their own vdc options e.g. > > >>>> IPTablesConfig.GLUSTER > > >>>> - When assembling the full script in VdsInstaller, > > >>>> - Take IPTablesConfig.PRE > > >>>> - Append it with IPTablesConfig. for every > > >>>> service > > >>>> to > > >>>> be > > >>>> enabled on the host/cluster > > >>>> - Append it with IPTablesConfig.POST > > >>>> > > >>>> Thoughts? > > >>> This is a simple approach that will work for current > > >>> implementation > > >>> and configuration. > > >>> > > >>> However, it will effect all nodes, with or without gluster. > > >> I don't get the concern here. Could you please elaborate? > > > If we have 500 nodes, out of them 200 gluster, why do I need to > > > distribute gluster specific rules to all 500? > > = > > When I say "Append it with IPTablesConfig. for every > > service > > to be enabled on the host/cluster", I mean every service that > > "needs > > to be enabled" on the host. In today's scenario, where virt and > > gluster are the only two services, it will look something like: > > = > > - If cluster supports virt, append IPTablesConfig.VIRT > > - If cluster supports gluster, append IPTablesConfig.GLUSTER > > = > > So it will be driven by the cluster in which the host is being > > added. > > And gluster rules will be sent to only the hosts of clusters that > > have gluster enabled. > = > OK... this is why I prefer templates. Much more simple and generic. > No need to have custom application logic within application. Do we want to use a template that's so tightly tied into iptables - does it= lock is into an implementation in the config files? Wouldn't we rather hav= e the rules in the config file (eg. tcp.port 80, udp.port xyz, etc) rather = than be so closely tied to an implementation. How will things look when we move to firewalld[1], or some other system, r= ather than creating and managing our own iptables rules? What happened to the custom chain discussion, did I miss that or was it sil= ently dropped? [1] https://fedoraproject.org/wiki/FirewallD > = > Alon > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============0398962432298371348==-- From alonbl at redhat.com Mon Sep 3 16:50:01 2012 Content-Type: multipart/mixed; boundary="===============1662260442545035720==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 16:50:00 -0400 Message-ID: <1615906426.4421296.1346705400892.JavaMail.root@redhat.com> In-Reply-To: 379791011.4807536.1346702720899.JavaMail.root@redhat.com --===============1662260442545035720== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Andrew Cathrow" > To: "Alon Bar-Lev" > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" > Sent: Monday, September 3, 2012 11:05:20 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Shireesh Anjal" > > Cc: engine-devel(a)ovirt.org > > Sent: Monday, September 3, 2012 9:50:52 AM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "Shireesh Anjal" > > > To: "Alon Bar-Lev" > > > Cc: "Selvasundaram" , engine-devel(a)ovirt.org > > > Sent: Monday, September 3, 2012 4:21:58 PM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > = > > > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > > > > > > > ----- Original Message ----- > > > >> From: "Shireesh Anjal" > > > >> To: "Alon Bar-Lev" > > > >> Cc: "Selvasundaram" , > > > >> engine-devel(a)ovirt.org > > > >> Sent: Monday, September 3, 2012 4:00:14 PM > > > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > >> > > > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > > >>> ----- Original Message ----- > > > >>>> From: "Shireesh Anjal" > > > >>>> To: engine-devel(a)ovirt.org > > > >>>> Cc: "Alon Bar-Lev" , "Selvasundaram" > > > >>>> > > > >>>> Sent: Monday, September 3, 2012 3:42:17 PM > > > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > >>>> > > > >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > > >>>>> ----- Original Message ----- > > > >>>>>> From: "Selvasundaram" > > > >>>>>> To: engine-devel(a)ovirt.org > > > >>>>>> Cc: "Shireesh Anjal" > > > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > > > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration > > > >>>>>> > > > >>>>>> > > > >>>>>> Hi, > > > >>>>>> > > > >>>>>> I want to add gluster specific IPTable configuration in > > > >>>>>> addition > > > >>>>>> to > > > >>>>>> the ovirt IPTable configuration (if it is gluster node). > > > >>>>>> > > > >>>>>> There are two approaches, > > > >>>>>> 1. Having one more gluster specific IP table config in db > > > >>>>>> and > > > >>>>>> merge > > > >>>>>> with ovirt IPTable config (merging NOT appending) > > > >>>>>> [I have the patch engine: Gluster specific firewall > > > >>>>>> configurations > > > >>>>>> #7244] > > > >>>>>> 2. Having two different IP Table config (ovirt and > > > >>>>>> ovirt+gluster) > > > >>>>>> and > > > >>>>>> use either one. > > > >>>>>> > > > >>>>>> Please provide your suggestions or improvements on this. > > > >>>>>> > > > >>>>> Hello all, > > > >>>>> > > > >>>>> The mentioned patch[1], adds hard coded gluster code into > > > >>>>> the > > > >>>>> bootstrap code, manipulate the firewall configuration to be > > > >>>>> gluster specific. It hardcoded search for "reject", insert > > > >>>>> before > > > >>>>> some other rules. > > > >>>>> > > > >>>>> I believe this hardcode approach is obsolete now that we > > > >>>>> have > > > >>>>> proper tools for templates. > > > >>>>> > > > >>>>> A more robust solution would be defining generic profiles, > > > >>>>> each > > > >>>>> profile as a template, each template can refer to different > > > >>>>> profiles, and assign profile to a node. > > > >>>>> > > > >>>>> This way the implementation is not gluster [or any] > > > >>>>> specific > > > >>>>> and > > > >>>>> can be reused for more setups, code is cleaner. > > > >>>>> > > > >>>>> Example: > > > >>>>> > > > >>>>> BASIC.PRE > > > >>>>> :INPUT ACCEPT [0:0] > > > >>>>> :FORWARD ACCEPT [0:0] > > > >>>>> :OUTPUT ACCEPT [0:0] > > > >>>>> BASIC.IN > > > >>>>> accept ... > > > >>>>> accept ... > > > >>>>> BASIC.POST > > > >>>>> reject ... > > > >>>>> reject ... > > > >>>>> > > > >>>>> BASIC > > > >>>>> ${BASIC.PRE} > > > >>>>> ${BASIC.IN} > > > >>>>> ${BASIC.POST} > > > >>>>> > > > >>>>> GLUSTER > > > >>>>> ${BASIC.PRE} > > > >>>>> ${BASIC.IN} > > > >>>>> accept ... > > > >>>>> ${BASIC.POST} > > > >>>>> reject ... > > > >>>> I like the separation of PRE/IN/POST rules here. However I > > > >>>> think > > > >>>> it > > > >>>> is > > > >>>> better to keep the service specific rules in separate > > > >>>> configurations. > > > >>>> Currently, whole iptables rules script is kept in the vdc > > > >>>> option > > > >>>> "IPTablesConfig". How about changing this as follows? > > > >>>> > > > >>>> - Split the current config into three: IPTablesConfig.PRE, > > > >>>> IPTablesConfig.VIRT and IPTablesConfig.POST > > > >>>> - Let services like Gluster add their own vdc options e.g. > > > >>>> IPTablesConfig.GLUSTER > > > >>>> - When assembling the full script in VdsInstaller, > > > >>>> - Take IPTablesConfig.PRE > > > >>>> - Append it with IPTablesConfig. for every > > > >>>> service > > > >>>> to > > > >>>> be > > > >>>> enabled on the host/cluster > > > >>>> - Append it with IPTablesConfig.POST > > > >>>> > > > >>>> Thoughts? > > > >>> This is a simple approach that will work for current > > > >>> implementation > > > >>> and configuration. > > > >>> > > > >>> However, it will effect all nodes, with or without gluster. > > > >> I don't get the concern here. Could you please elaborate? > > > > If we have 500 nodes, out of them 200 gluster, why do I need to > > > > distribute gluster specific rules to all 500? > > > = > > > When I say "Append it with IPTablesConfig. for every > > > service > > > to be enabled on the host/cluster", I mean every service that > > > "needs > > > to be enabled" on the host. In today's scenario, where virt and > > > gluster are the only two services, it will look something like: > > > = > > > - If cluster supports virt, append IPTablesConfig.VIRT > > > - If cluster supports gluster, append IPTablesConfig.GLUSTER > > > = > > > So it will be driven by the cluster in which the host is being > > > added. > > > And gluster rules will be sent to only the hosts of clusters that > > > have gluster enabled. > > = > > OK... this is why I prefer templates. Much more simple and generic. > > No need to have custom application logic within application. > = > = > Do we want to use a template that's so tightly tied into iptables - > does it lock is into an implementation in the config files? Wouldn't > we rather have the rules in the config file (eg. tcp.port 80, > udp.port xyz, etc) rather than be so closely tied to an > implementation. You refer to a model similar to libvirt[1] referred by David - abstract any= thing. This model will not work well without templates, as one probably need to co= nstruct the abstract rule base similar manner by merging of hunks of config= uration. You can take the result in whatever language and either convert it to anoth= er language (iptables) or to dbus calls (firewalld). My main questions are: a. Do we want to invest NOW in generic language to define firewall rules? b. Is such decision is required at this point? There are so many projects out there that are specialized in this particula= r domain. I, personally, find firehol[2] very useful for my configurations.= But I don't know many that are intermediate between generic rules into an = interface other than iptables (eg. firewalld). So we can have dependency of firewalld at node side, and feed it with whate= ver it accepts, however, having firewalld as dependency will make the cost = of porting to other distributions much higher. > How will things look when we move to firewalld[1], or some other > system, rather than creating and managing our own iptables rules? > = > What happened to the custom chain discussion, did I miss that or was > it silently dropped? As I did not fully understand your suggestion asked, but not answered. How do you use custom chains in order to meet the requirement of providing = different firewall configurations to different hosts? Regards, Alon [1] http://libvirt.org/formatnwfilter.html [2] http://firehol.sourceforge.net/ --===============1662260442545035720==-- From acathrow at redhat.com Mon Sep 3 16:57:57 2012 Content-Type: multipart/mixed; boundary="===============1355484607373243196==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 16:57:57 -0400 Message-ID: <1782554206.4811021.1346705877535.JavaMail.root@redhat.com> In-Reply-To: 1615906426.4421296.1346705400892.JavaMail.root@redhat.com --===============1355484607373243196== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Andrew Cathrow" > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" > Sent: Monday, September 3, 2012 4:50:00 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Andrew Cathrow" > > To: "Alon Bar-Lev" > > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" > > Sent: Monday, September 3, 2012 11:05:20 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "Alon Bar-Lev" > > > To: "Shireesh Anjal" > > > Cc: engine-devel(a)ovirt.org > > > Sent: Monday, September 3, 2012 9:50:52 AM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > = > > > = > > > = > > > ----- Original Message ----- > > > > From: "Shireesh Anjal" > > > > To: "Alon Bar-Lev" > > > > Cc: "Selvasundaram" , > > > > engine-devel(a)ovirt.org > > > > Sent: Monday, September 3, 2012 4:21:58 PM > > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > = > > > > On Monday 03 September 2012 06:41 PM, Alon Bar-Lev wrote: > > > > > > > > > > ----- Original Message ----- > > > > >> From: "Shireesh Anjal" > > > > >> To: "Alon Bar-Lev" > > > > >> Cc: "Selvasundaram" , > > > > >> engine-devel(a)ovirt.org > > > > >> Sent: Monday, September 3, 2012 4:00:14 PM > > > > >> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > >> > > > > >> On Monday 03 September 2012 06:22 PM, Alon Bar-Lev wrote: > > > > >>> ----- Original Message ----- > > > > >>>> From: "Shireesh Anjal" > > > > >>>> To: engine-devel(a)ovirt.org > > > > >>>> Cc: "Alon Bar-Lev" , "Selvasundaram" > > > > >>>> > > > > >>>> Sent: Monday, September 3, 2012 3:42:17 PM > > > > >>>> Subject: Re: [Engine-devel] Gluster IPTable configuration > > > > >>>> > > > > >>>> On Friday 31 August 2012 12:05 AM, Alon Bar-Lev wrote: > > > > >>>>> ----- Original Message ----- > > > > >>>>>> From: "Selvasundaram" > > > > >>>>>> To: engine-devel(a)ovirt.org > > > > >>>>>> Cc: "Shireesh Anjal" > > > > >>>>>> Sent: Thursday, August 30, 2012 4:30:16 PM > > > > >>>>>> Subject: [Engine-devel] Gluster IPTable configuration > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> Hi, > > > > >>>>>> > > > > >>>>>> I want to add gluster specific IPTable configuration in > > > > >>>>>> addition > > > > >>>>>> to > > > > >>>>>> the ovirt IPTable configuration (if it is gluster node). > > > > >>>>>> > > > > >>>>>> There are two approaches, > > > > >>>>>> 1. Having one more gluster specific IP table config in > > > > >>>>>> db > > > > >>>>>> and > > > > >>>>>> merge > > > > >>>>>> with ovirt IPTable config (merging NOT appending) > > > > >>>>>> [I have the patch engine: Gluster specific firewall > > > > >>>>>> configurations > > > > >>>>>> #7244] > > > > >>>>>> 2. Having two different IP Table config (ovirt and > > > > >>>>>> ovirt+gluster) > > > > >>>>>> and > > > > >>>>>> use either one. > > > > >>>>>> > > > > >>>>>> Please provide your suggestions or improvements on this. > > > > >>>>>> > > > > >>>>> Hello all, > > > > >>>>> > > > > >>>>> The mentioned patch[1], adds hard coded gluster code into > > > > >>>>> the > > > > >>>>> bootstrap code, manipulate the firewall configuration to > > > > >>>>> be > > > > >>>>> gluster specific. It hardcoded search for "reject", > > > > >>>>> insert > > > > >>>>> before > > > > >>>>> some other rules. > > > > >>>>> > > > > >>>>> I believe this hardcode approach is obsolete now that we > > > > >>>>> have > > > > >>>>> proper tools for templates. > > > > >>>>> > > > > >>>>> A more robust solution would be defining generic > > > > >>>>> profiles, > > > > >>>>> each > > > > >>>>> profile as a template, each template can refer to > > > > >>>>> different > > > > >>>>> profiles, and assign profile to a node. > > > > >>>>> > > > > >>>>> This way the implementation is not gluster [or any] > > > > >>>>> specific > > > > >>>>> and > > > > >>>>> can be reused for more setups, code is cleaner. > > > > >>>>> > > > > >>>>> Example: > > > > >>>>> > > > > >>>>> BASIC.PRE > > > > >>>>> :INPUT ACCEPT [0:0] > > > > >>>>> :FORWARD ACCEPT [0:0] > > > > >>>>> :OUTPUT ACCEPT [0:0] > > > > >>>>> BASIC.IN > > > > >>>>> accept ... > > > > >>>>> accept ... > > > > >>>>> BASIC.POST > > > > >>>>> reject ... > > > > >>>>> reject ... > > > > >>>>> > > > > >>>>> BASIC > > > > >>>>> ${BASIC.PRE} > > > > >>>>> ${BASIC.IN} > > > > >>>>> ${BASIC.POST} > > > > >>>>> > > > > >>>>> GLUSTER > > > > >>>>> ${BASIC.PRE} > > > > >>>>> ${BASIC.IN} > > > > >>>>> accept ... > > > > >>>>> ${BASIC.POST} > > > > >>>>> reject ... > > > > >>>> I like the separation of PRE/IN/POST rules here. However I > > > > >>>> think > > > > >>>> it > > > > >>>> is > > > > >>>> better to keep the service specific rules in separate > > > > >>>> configurations. > > > > >>>> Currently, whole iptables rules script is kept in the vdc > > > > >>>> option > > > > >>>> "IPTablesConfig". How about changing this as follows? > > > > >>>> > > > > >>>> - Split the current config into three: IPTablesConfig.PRE, > > > > >>>> IPTablesConfig.VIRT and IPTablesConfig.POST > > > > >>>> - Let services like Gluster add their own vdc options e.g. > > > > >>>> IPTablesConfig.GLUSTER > > > > >>>> - When assembling the full script in VdsInstaller, > > > > >>>> - Take IPTablesConfig.PRE > > > > >>>> - Append it with IPTablesConfig. for every > > > > >>>> service > > > > >>>> to > > > > >>>> be > > > > >>>> enabled on the host/cluster > > > > >>>> - Append it with IPTablesConfig.POST > > > > >>>> > > > > >>>> Thoughts? > > > > >>> This is a simple approach that will work for current > > > > >>> implementation > > > > >>> and configuration. > > > > >>> > > > > >>> However, it will effect all nodes, with or without gluster. > > > > >> I don't get the concern here. Could you please elaborate? > > > > > If we have 500 nodes, out of them 200 gluster, why do I need > > > > > to > > > > > distribute gluster specific rules to all 500? > > > > = > > > > When I say "Append it with IPTablesConfig. for every > > > > service > > > > to be enabled on the host/cluster", I mean every service that > > > > "needs > > > > to be enabled" on the host. In today's scenario, where virt and > > > > gluster are the only two services, it will look something like: > > > > = > > > > - If cluster supports virt, append IPTablesConfig.VIRT > > > > - If cluster supports gluster, append IPTablesConfig.GLUSTER > > > > = > > > > So it will be driven by the cluster in which the host is being > > > > added. > > > > And gluster rules will be sent to only the hosts of clusters > > > > that > > > > have gluster enabled. > > > = > > > OK... this is why I prefer templates. Much more simple and > > > generic. > > > No need to have custom application logic within application. > > = > > = > > Do we want to use a template that's so tightly tied into iptables - > > does it lock is into an implementation in the config files? > > Wouldn't > > we rather have the rules in the config file (eg. tcp.port 80, > > udp.port xyz, etc) rather than be so closely tied to an > > implementation. > = > You refer to a model similar to libvirt[1] referred by David - > abstract anything. > = > This model will not work well without templates, as one probably need > to construct the abstract rule base similar manner by merging of > hunks of configuration. > = > You can take the result in whatever language and either convert it to > another language (iptables) or to dbus calls (firewalld). > = > My main questions are: > a. Do we want to invest NOW in generic language to define firewall > rules? > b. Is such decision is required at this point? > = > There are so many projects out there that are specialized in this > particular domain. I, personally, find firehol[2] very useful for my > configurations. But I don't know many that are intermediate between > generic rules into an interface other than iptables (eg. firewalld). > = > So we can have dependency of firewalld at node side, and feed it with > whatever it accepts, however, having firewalld as dependency will > make the cost of porting to other distributions much higher. > = > > How will things look when we move to firewalld[1], or some other > > system, rather than creating and managing our own iptables rules? > > = > > What happened to the custom chain discussion, did I miss that or > > was > > it silently dropped? > = > As I did not fully understand your suggestion asked, but not > answered. > = > How do you use custom chains in order to meet the requirement of > providing different firewall configurations to different hosts? Right now we just overwrite the existing iptables configuration with our ow= n, so if a user already added a rule to their host - eg. for a monitoring a= gent the we stomp over it. Adding our rules as a custom chain means that we don't need to overwrite ex= isting rules we can extend them. The advantage of using something like firewalld to add rules is that we don= 't have to worry about parsing existing rules, etc we can let that service = handle it. We need to handle firewall rules for ovirt-node plugins (eg. open port XYZ= for monitoring agent ABC) - I'm not sure if this has been discussed yet, a= dding Mike .... > = > Regards, > Alon > = > [1] http://libvirt.org/formatnwfilter.html > [2] http://firehol.sourceforge.net/ >=20 --===============1355484607373243196==-- From alonbl at redhat.com Mon Sep 3 17:09:34 2012 Content-Type: multipart/mixed; boundary="===============5164991700453937320==" MIME-Version: 1.0 From: Alon Bar-Lev To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 17:09:34 -0400 Message-ID: <811147153.4421845.1346706574096.JavaMail.root@redhat.com> In-Reply-To: 1782554206.4811021.1346705877535.JavaMail.root@redhat.com --===============5164991700453937320== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Andrew Cathrow" > To: "Alon Bar-Lev" > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" , "Mi= ke Burns" > Sent: Monday, September 3, 2012 11:57:57 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > Right now we just overwrite the existing iptables configuration with > our own, so if a user already added a rule to their host - eg. for a > monitoring agent the we stomp over it. > Adding our rules as a custom chain means that we don't need to Here I lost you... :) I thought ovirt-engine is the master and ovirt-hypervisor is a slave. This derives that all management activities of slave is done by master... There should be no setting at slave that master is not aware of. This also enables you to duplicate hipervisor, recover configuration or pus= h mass configuration change. In your above case, this rule for monitoring agent may be added at master r= epository and pushed to slaves belongs to specific group, just like the glu= ster case. The template mechanism is what enable you to create a custom configuration = per environment. Using push and not re-integrate derives much simpler and deterministic impl= ementation. But maybe I did not understand some of the fundamental concepts of the arch= itecture. Regards, Alon. --===============5164991700453937320==-- From acathrow at redhat.com Mon Sep 3 17:21:12 2012 Content-Type: multipart/mixed; boundary="===============0105869419916232861==" MIME-Version: 1.0 From: Andrew Cathrow To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Mon, 03 Sep 2012 17:21:11 -0400 Message-ID: <2000454800.4812856.1346707271710.JavaMail.root@redhat.com> In-Reply-To: 811147153.4421845.1346706574096.JavaMail.root@redhat.com --===============0105869419916232861== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Alon Bar-Lev" > To: "Andrew Cathrow" > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" , "Mi= ke Burns" > Sent: Monday, September 3, 2012 5:09:34 PM > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > = > = > ----- Original Message ----- > > From: "Andrew Cathrow" > > To: "Alon Bar-Lev" > > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" , > > "Mike Burns" > > Sent: Monday, September 3, 2012 11:57:57 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > = > > = > > Right now we just overwrite the existing iptables configuration > > with > > our own, so if a user already added a rule to their host - eg. for > > a > > monitoring agent the we stomp over it. > > Adding our rules as a custom chain means that we don't need to > = > Here I lost you... :) > = > I thought ovirt-engine is the master and ovirt-hypervisor is a slave. > = > This derives that all management activities of slave is done by > master... > = Let's say I use nagios for my host monitoring. I setup a rhel/fedora/*EL host using my standard corporate and include port= 5667/5666 for nagios. ovirt engine connects to it and blocks nagios. While it would be great to have all firewall rules (and other settings) man= aged from ovirt-engine we are a long way away from that. Adding rules rather than overwriting iptables config would allow us not to = stomp on the user's existing settings. > There should be no setting at slave that master is not aware of. > = > This also enables you to duplicate hipervisor, recover configuration > or push mass configuration change. > = > In your above case, this rule for monitoring agent may be added at > master repository and pushed to slaves belongs to specific group, > just like the gluster case. yes, but in the 24 months between now and when we get to implement that fea= ture ...... > = > The template mechanism is what enable you to create a custom > configuration per environment. > = > Using push and not re-integrate derives much simpler and > deterministic implementation. > = > But maybe I did not understand some of the fundamental concepts of > the architecture. > = > Regards, > Alon. >=20 --===============0105869419916232861==-- From djasa at redhat.com Tue Sep 4 05:06:14 2012 Content-Type: multipart/mixed; boundary="===============6132015333592771096==" MIME-Version: 1.0 From: =?utf-8?q?David_Ja=C5=A1a_=3Cdjasa_at_redhat=2Ecom=3E?= To: devel at ovirt.org Subject: Re: [Engine-devel] Gluster IPTable configuration Date: Tue, 04 Sep 2012 11:06:08 +0200 Message-ID: <1346749568.15842.143.camel@dhcp-29-7.brq.redhat.com> In-Reply-To: 2000454800.4812856.1346707271710.JavaMail.root@redhat.com --===============6132015333592771096== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Andrew Cathrow p=C3=AD=C5=A1e v Po 03. 09. 2012 v 17:21 -0400: > = > ----- Original Message ----- > > From: "Alon Bar-Lev" > > To: "Andrew Cathrow" > > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" , "= Mike Burns" > > Sent: Monday, September 3, 2012 5:09:34 PM > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > = > > = > > ----- Original Message ----- > > > From: "Andrew Cathrow" > > > To: "Alon Bar-Lev" > > > Cc: engine-devel(a)ovirt.org, "Shireesh Anjal" , > > > "Mike Burns" > > > Sent: Monday, September 3, 2012 11:57:57 PM > > > Subject: Re: [Engine-devel] Gluster IPTable configuration > > = > > > > = > > > Right now we just overwrite the existing iptables configuration > > > with > > > our own, so if a user already added a rule to their host - eg. for > > > a > > > monitoring agent the we stomp over it. > > > Adding our rules as a custom chain means that we don't need to > > = > > Here I lost you... :) > > = > > I thought ovirt-engine is the master and ovirt-hypervisor is a slave. > > = > > This derives that all management activities of slave is done by > > master... > > = > = > Let's say I use nagios for my host monitoring. > I setup a rhel/fedora/*EL host using my standard corporate and include po= rt 5667/5666 for nagios. > ovirt engine connects to it and blocks nagios. > = > While it would be great to have all firewall rules (and other settings) m= anaged from ovirt-engine we are a long way away from that. > Adding rules rather than overwriting iptables config would allow us not t= o stomp on the user's existing settings. This sounds like you want precise feature set of firewalld, just faster. David > = > = > > There should be no setting at slave that master is not aware of. > > = > > This also enables you to duplicate hipervisor, recover configuration > > or push mass configuration change. > = > > = > > In your above case, this rule for monitoring agent may be added at > > master repository and pushed to slaves belongs to specific group, > > just like the gluster case. > = > yes, but in the 24 months between now and when we get to implement that f= eature ...... > = > > = > > The template mechanism is what enable you to create a custom > > configuration per environment. > = > > = > > Using push and not re-integrate derives much simpler and > > deterministic implementation. > > = > > But maybe I did not understand some of the fundamental concepts of > > the architecture. > > = > > Regards, > > Alon. > > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- = David Ja=C5=A1a, RHCE SPICE QE based in Brno GPG Key: 22C33E24 = Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 --===============6132015333592771096==--