<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <span dir="ltr"><<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">Hi,<br><br></div><div style="font-family:arial,helvetica,sans-serif">so personally I don't like the current way how we store firewall configuration within engine (saving complete iptables commands as string). I think should change the way how we store firewall configuration:<br><br></div><div style="font-family:arial,helvetica,sans-serif">1. On engine side I'd just store which services/ports (or port ranges) need to be enabled on host. By default only those services/ports that engine needs, but we can maintain also custom services defined by users<br></div></div></blockquote><div><br></div><div>Agreed. I hope that's enough on one hand, on the other hand, users can probably easily extend it via Ansible to the hosts and execution of a more customized firewalld configuration there - we probably should not own it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">2. Write plugin to ovirt-host-deploy which will translate those services/ports into actual firewall configuration on the host (it should detected what firewall is currently enabled and adapt)<br></div></div></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">3. For newly installed host I'd just use firewalld<br></div></div></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><br></div><div style="font-family:arial,helvetica,sans-serif">4. Also for 4.2 clusters I'd switch from iptables to firewalld when you execute Reinstall (we should document this and make firewalld preferred solution)</div></div></blockquote><div><br></div><div>That's a good question. If a user had the default, non-changed policy we have had in iptables - sure.</div><div>If not, I think it may be a bit of a challenge to switch otherwise.</div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><span class="HOEnZb"><font color="#888888"><br><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div style="font-family:arial,helvetica,sans-serif">Martin<br><br></div><div style="font-family:arial,helvetica,sans-serif"><br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>> wrote:<br>
> Effectively, upgrading will leave lingering (but nonetheless operational)<br>
> iptables rules on the hosts. I'm not even sure there needs to be special<br>
> upgrade treatment?<br>
<br>
Please describe the expected flow.<br>
<br>
Please note that at least when I tried, 'systemctl start firewalld' stops<br>
iptables.<br>
<br>
Thanks,<br>
<br>
><br>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>> wrote:<br>
>><br>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>><br>
>> wrote:<br>
>> > 1) Do we actually need iptables for any reason that isn't a legacy<br>
>> > consideration?<br>
>><br>
>> No idea personally.<br>
>><br>
>> Perhaps some users prefer that, and/or need that for integration with<br>
>> other<br>
>> systems/solutions/whatever.<br>
>><br>
>> If we drop iptables, how do you suggest to treat upgrades?<br>
>><br>
>> ><br>
>> > 2 & 3) I am in favor of treating custom services as a requirement and<br>
>> > plan<br>
>> > accordingly. Many (most, even) of the services are already provided by<br>
>> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages<br>
>> > (e.g.<br>
>> > gluster). Some are missing (I've recently created a pull request for<br>
>> > ovirt-imageio to firewalld, for example) and I hope we'll be able to get<br>
>> > all<br>
>> > the services to be statically provided (by either firewalld or the<br>
>> > relevant<br>
>> > 3rd party packages).<br>
>> ><br>
>> > Ideally I think we'd like use statically provided services, and provide<br>
>> > the<br>
>> > capability to provide additional services (I'm not a fan of the current<br>
>> > methodology of converting strings into xmls). I don't think we'd want to<br>
>> > limit usage to just statically provided services. (2)<br>
>> ><br>
>> > As previously stated, I don't see a technical reason to keep iptables<br>
>> > under<br>
>> > consideration. (3)<br>
>> ><br>
>> ><br>
>> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >><br>
>> >> 1. Do we want to support in some version X both iptables and firewalld,<br>
>> >> or<br>
>> >> is it ok to stop support for iptables and support only firewalld<br>
>> >> without<br>
>> >> overlap? If so, do we handle upgrades, and how?<br>
>> >><br>
>> >> 2. Do we want to support custom firewalld xml to be configured on the<br>
>> >> host by us? Or is it ok to only support choosing among existing<br>
>> >> services,<br>
>> >> which will need to be added to the host using other means (packaged by<br>
>> >> firewalld, packaged by 3rd parties, added manually by users)?<br>
>> >><br>
>> >> 3. Opposite of (2.): Do we want to support firewalld services that are<br>
>> >> added to the host using other means (see there)? Obviously we do, but:<br>
>> >> If we do, do we still want to support also iptables (see (1.))? And if<br>
>> >> so, what do we want to then happen?<br>
>> >><br>
>> >> (2.) and (3.) are not conflicting, each needs its own answer.<br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Didi<br>
>> ><br>
>> ><br>
>><br>
>><br>
<span class="m_-8287614625872159388HOEnZb"><font color="#888888">>><br>
>> --<br>
>> Didi<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Didi<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div></div>