5:33 a.m.
Hey,
We're looking to migrate from iptables to firewalld. We came up with a
couple of possible approaches we'd like opinions on. I'll list the options
first, and will
1) Replicate existing flow:
As of date, iptable rules are inserted in the database via SQL config
files. During host deployment, VdsDeployIptablesUnit adds the required
rules (based on cluster/firewall configuration) to the deployment
configuration, en route to being deployed on the host via otopi and its
iptables plugin.
Pros:
- Reuse of existing infrastructure.
Cons:
- Current infrastructure is overly complex...
- Many of the required services are provided by firewalld. Rewriting them
is wasteful; specifying them (instead of providing actual service .xml
content) will require adaptations on both (engine/host) sides. More on that
later.
2) Host side based configuration:
Essentially, all the required logic (aforementioned cluster/firewall
configuration) to determine if/how firewalld should be deployed could be
passed on to the host via ohd. Vdsm could take on the responsibility of
examining the relevant configuration, and then creating and/or adding the
required services (using vdsm.conf and vdsm-tool).
Pros:
- Engine side involvement is greatly diminished.
- Simple(r).
Cons:
- Custom services/rules capabilities will have to be rethought and
re-implemented (current infrastructure supports custom iptables rules by
being specified in the SQL config file).
3) Some other hybrid approach:
If we're able to guarantee all the required firewalld services are
statically provided one way or the other, the current procedure could be
replicated and be made more simpler. Instead of providing xml content in
the form of strings, service names could be supplied. The responsibility of
actual service deployment becomes easier, and could be left to otopi (with
the appropriate modifications) or switched over to vdsm.
--
Regardless, usage of statically provided vs. dynamically created services
remains an open question. I think we'd like to avoid implementing logic
that ask whether some service is provided (and then write it if it
isn't...), and so choosing between the dynamic and static approaches is
also needed. Using the static approach, guaranteeing *all* services are
provided will be required.
I do believe guaranteeing the presence of all required services is worth
it, however custom services aren't going to be naively compatible, and
we'll still have to use similar mechanism as described in #1 (service
string -> .xml -> addition of service name to active zone).
Your thoughts are welcome.
Thanks,
Leon
5:40 a.m.
top-posting:
You need to also consider how upgrade will be handled, right?
Or iptables will still remain supported?
Also, see some comments inline.
Regards,
Oved
On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Hey,
We're looking to migrate from iptables to firewalld. We came up with a
couple of possible approaches we'd like opinions on. I'll list the options
first, and will
1) Replicate existing flow:
As of date, iptable rules are inserted in the database via SQL config
files. During host deployment, VdsDeployIptablesUnit adds the required
rules (based on cluster/firewall configuration) to the deployment
configuration, en route to being deployed on the host via otopi and its
iptables plugin.
Pros:
- Reuse of existing infrastructure.
Cons:
- Current infrastructure is overly complex...
Can you elaborate?
I'm not an otopi expert, but I think that otopi plugins shouldn't be more
complex than what you describe in section #2, and the plugins were meant in
order to handle such cases.
- Many of the required services are provided by firewalld. Rewriting them
is wasteful; specifying them (instead of providing actual service
.xml
content) will require adaptations on both (engine/host) sides. More on that
later.
2) Host side based configuration:
Essentially, all the required logic (aforementioned cluster/firewall
configuration) to determine if/how firewalld should be deployed could be
passed on to the host via ohd. Vdsm could take on the responsibility of
examining the relevant configuration, and then creating and/or adding the
required services (using vdsm.conf and vdsm-tool).
So here you replace the otopi plugin with relevant vdsm-tool code, and the
question is why is that better?
Pros:
- Engine side involvement is greatly diminished.
- Simple(r).
Cons:
- Custom services/rules capabilities will have to be rethought and
re-implemented (current infrastructure supports custom iptables rules by
being specified in the SQL config file).
3) Some other hybrid approach:
If we're able to guarantee all the required firewalld services are
statically provided one way or the other, the current procedure could be
replicated and be made more simpler. Instead of providing xml content in
the form of strings, service names could be supplied. The responsibility of
actual service deployment becomes easier, and could be left to otopi (with
the appropriate modifications) or switched over to vdsm.
--
Regardless, usage of statically provided vs. dynamically created services
remains an open question. I think we'd like to avoid implementing logic
that ask whether some service is provided (and then write it if it
isn't...), and so choosing between the dynamic and static approaches is
also needed. Using the static approach, guaranteeing *all* services are
provided will be required.
I do believe guaranteeing the presence of all required services is worth
it, however custom services aren't going to be naively compatible, and
we'll still have to use similar mechanism as described in #1 (service
string -> .xml -> addition of service name to active zone).
Your thoughts are welcome.
Thanks,
Leon
6:08 a.m.
Hey Oved,
I don't think completely moving away from iptables is foreseeable at this
point, but I could be of course wrong. Either way, upgrading still needs to
be thought of.
By stating that the current infrastructure is complex, I was referring to
the entire chain of storing rules in the database, fetching them using a
dedicated deployment class consisting of include/exclude logic, sending
them over, unpacking, deploying...
This procedure involves a lot of code that could be made redundant if the
required logic is present in the host, which to me seems favorable. It of
course entails other potential difficulties, primarily in the form of
custom services.
I don't think otopi's firewalld plugin is any more complex than the
potential code that will have to be written in vdsm-tool, however it
currently expects the data generated by aforementioned chain. The hybrid
approach briefly touches on simplifying Engine's involvement while
retaining use of otopi's plugin.
On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali(a)redhat.com> wrote:
top-posting:
You need to also consider how upgrade will be handled, right?
Or iptables will still remain supported?
Also, see some comments inline.
Regards,
Oved
On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
>
Can you elaborate?
I'm not an otopi expert, but I think that otopi plugins shouldn't be more
complex than what you describe in section #2, and the plugins were meant in
order to handle such cases.
- Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
>
So here you replace the otopi plugin with relevant vdsm-tool code, and the
question is why is that better?
> Pros:
>
> - Engine side involvement is greatly diminished.
> - Simple(r).
>
> Cons:
>
> - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
6:12 a.m.
On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Hey Oved,
I don't think completely moving away from iptables is foreseeable at this
point, but I could be of course wrong. Either way, upgrading still needs to
be thought of.
I see.
By stating that the current infrastructure is complex, I was
referring to
the entire chain of storing rules in the database, fetching them using a
dedicated deployment class consisting of include/exclude logic, sending
them over, unpacking, deploying...
This procedure involves a lot of code that could be made redundant if the
required logic is present in the host, which to me seems favorable. It of
course entails other potential difficulties, primarily in the form of
custom services.
I don't think otopi's firewalld plugin is any more complex than the
potential code that will have to be written in vdsm-tool, however it
currently expects the data generated by aforementioned chain. The hybrid
approach briefly touches on simplifying Engine's involvement while
retaining use of otopi's plugin.
Okay. I think that writing a new plugin for firewalld is indeed a good
option, whether you "refactor" the engine side or not.
On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali(a)redhat.com> wrote:
> top-posting:
> You need to also consider how upgrade will be handled, right?
> Or iptables will still remain supported?
>
> Also, see some comments inline.
>
> Regards,
> Oved
>
> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
> wrote:
>
>>
>> Hey,
>>
>> We're looking to migrate from iptables to firewalld. We came up with a
>> couple of possible approaches we'd like opinions on. I'll list the
options
>> first, and will
>>
>> 1) Replicate existing flow:
>>
>> As of date, iptable rules are inserted in the database via SQL config
>> files. During host deployment, VdsDeployIptablesUnit adds the required
>> rules (based on cluster/firewall configuration) to the deployment
>> configuration, en route to being deployed on the host via otopi and its
>> iptables plugin.
>>
>> Pros:
>>
>> - Reuse of existing infrastructure.
>>
>> Cons:
>>
>> - Current infrastructure is overly complex...
>>
>
> Can you elaborate?
> I'm not an otopi expert, but I think that otopi plugins shouldn't be more
> complex than what you describe in section #2, and the plugins were meant in
> order to handle such cases.
>
> - Many of the required services are provided by firewalld. Rewriting them
>> is wasteful; specifying them (instead of providing actual service .xml
>> content) will require adaptations on both (engine/host) sides. More on that
>> later.
>>
>>
>> 2) Host side based configuration:
>>
>> Essentially, all the required logic (aforementioned cluster/firewall
>> configuration) to determine if/how firewalld should be deployed could be
>> passed on to the host via ohd. Vdsm could take on the responsibility of
>> examining the relevant configuration, and then creating and/or adding the
>> required services (using vdsm.conf and vdsm-tool).
>>
>>
> So here you replace the otopi plugin with relevant vdsm-tool code, and
> the question is why is that better?
>
>
>> Pros:
>>
>> - Engine side involvement is greatly diminished.
>> - Simple(r).
>>
>> Cons:
>>
>> - Custom services/rules capabilities will have to be rethought and
>> re-implemented (current infrastructure supports custom iptables rules by
>> being specified in the SQL config file).
>>
>>
>> 3) Some other hybrid approach:
>>
>> If we're able to guarantee all the required firewalld services are
>> statically provided one way or the other, the current procedure could be
>> replicated and be made more simpler. Instead of providing xml content in
>> the form of strings, service names could be supplied. The responsibility of
>> actual service deployment becomes easier, and could be left to otopi (with
>> the appropriate modifications) or switched over to vdsm.
>>
>> --
>>
>> Regardless, usage of statically provided vs. dynamically created
>> services remains an open question. I think we'd like to avoid implementing
>> logic that ask whether some service is provided (and then write it if it
>> isn't...), and so choosing between the dynamic and static approaches is
>> also needed. Using the static approach, guaranteeing *all* services are
>> provided will be required.
>>
>> I do believe guaranteeing the presence of all required services is worth
>> it, however custom services aren't going to be naively compatible, and
>> we'll still have to use similar mechanism as described in #1 (service
>> string -> .xml -> addition of service name to active zone).
>>
>>
>> Your thoughts are welcome.
>>
>> Thanks,
>> Leon
>>
>>
>
6:57 a.m.
On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <oourfali(a)redhat.com> wrote:
On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
>
> Hey Oved,
>
> I don't think completely moving away from iptables is foreseeable at this
> point, but I could be of course wrong. Either way, upgrading still needs to
> be thought of.
>
I see.
>
> By stating that the current infrastructure is complex, I was referring to
> the entire chain of storing rules in the database, fetching them using a
> dedicated deployment class consisting of include/exclude logic, sending them
> over, unpacking, deploying...
>
> This procedure involves a lot of code that could be made redundant if the
> required logic is present in the host, which to me seems favorable. It of
> course entails other potential difficulties, primarily in the form of custom
> services.
>
> I don't think otopi's firewalld plugin is any more complex than the
> potential code that will have to be written in vdsm-tool, however it
> currently expects the data generated by aforementioned chain. The hybrid
> approach briefly touches on simplifying Engine's involvement while retaining
> use of otopi's plugin.
>
Okay. I think that writing a new plugin for firewalld is indeed a good
option, whether you "refactor" the engine side or not.
otopi already has a 'firewalld' plugin. It's already in use, at least
by engine-setup, so we should be a bit careful if we want to change it.
Not preventing/objecting anything, just mentioning.
This plugin's interface currently only takes XML-content as input.
It has no place for configuring existing firewalld services presumably
already provided elsewhere (by firewalld itself or 3rd party packages,
such as vdsm). So if we go that route we probably want to extend this
interface to allow passing service names and rely on them being defined
elsewhere.
A related issue is that for engine-setup, the _input_ is currently
firewalld xml content, and if users choose to configure 'iptables',
this is parsed to generate iptables rules. This is currently an engine-setup
issue only, but will affect also host deploy flow if we decided to
allow passing service names (without their xml content) and still keep
compatibility to current state and allow configuring iptables on the
host. We'll then be there in the same situation we are at with engine-setup.
See also https://bugzilla.redhat.com/1432354 . An alternative is obviously
deciding to remove iptables support and support only firewalld, but this
is a rather radical change for users, imo.
See also this for some of the existing behavior of engine-setup:
https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9
IMO we first need to decide what we want, then how to do that. IMO the
questions we have re "what we want" are, more-or-less:
1. Do we want to support in some version X both iptables and firewalld, or
is it ok to stop support for iptables and support only firewalld without
overlap? If so, do we handle upgrades, and how?
2. Do we want to support custom firewalld xml to be configured on the
host by us? Or is it ok to only support choosing among existing services,
which will need to be added to the host using other means (packaged by
firewalld, packaged by 3rd parties, added manually by users)?
3. Opposite of (2.): Do we want to support firewalld services that are
added to the host using other means (see there)? Obviously we do, but:
If we do, do we still want to support also iptables (see (1.))? And if
so, what do we want to then happen?
(2.) and (3.) are not conflicting, each needs its own answer.
My (thoughts about) answers:
1. If done well enough, and considerably simplifies things, I think it's
ok to jump directly from "only iptables" to "only firewalld", but
then
we should announce this ahead of time to give users time to plan/prepare.
If it's not too costly, I'd prefer to support both for the foreseeable
future, though.
2. Latter option here is problematic, if we need/want to allow
customizing services during deploy. E.g. suppose that one day we want
to make the vdsm port configurable. It will be nice if this can be done
by only changing things on the engine, without having to distribute
changes (conf and/or packages) to all hosts before host-deploy.
I'd say we can go a long way here by having a strict requirement from
all services that we need/want on hosts to have official IANA-registered
port numbers - then, it's imo much easier to tell users "If you want to
change the port for service X, you have to (long list of complex actions
goes here)". Currently, where services are not registered, we risk
conflicts with existing services, requiring the user to change ports -
and so we can't make this process too difficult. No idea how important
this is in practice.
3. Not sure :-( I'd say that if we want to support both iptables and
firewalld together, and support both "xml in engine" and "xml in
host",
then it might be ok if the custom rules/services will not automatically
apply to both iptables and firewalld. Meaning - you can set both custom
iptables rules and firewalld services, but it's up to you to make sure
they actually do the same thing if that's important to you.
Bottom line: I think we should summarize the open questions in a way
that will make it clear to users how each answer will affect them, and
ask what they think. Leon already started doing this [1], I only saw
one reply. Perhaps this means that users do not care that much, and
expect us to just decide and tell them what we decided (and always to
keep the option to disable this feature, as is possible today, and do
this themselves, if our choice of solution does not fit their needs).
I know this is way too loooong, sorry. Feel free to ignore, but then
please ask simpler questions if you want shorter answers :-)
[1] http://lists.ovirt.org/pipermail/users/2017-March/080600.html
>
>
>
> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali(a)redhat.com> wrote:
>>
>> top-posting:
>> You need to also consider how upgrade will be handled, right?
>> Or iptables will still remain supported?
>>
>> Also, see some comments inline.
>>
>> Regards,
>> Oved
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the
options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required rules
>>> (based on cluster/firewall configuration) to the deployment configuration,
>>> en route to being deployed on the host via otopi and its iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>
>>
>> Can you elaborate?
>> I'm not an otopi expert, but I think that otopi plugins shouldn't be
more
>> complex than what you describe in section #2, and the plugins were meant in
>> order to handle such cases.
>>
>>> - Many of the required services are provided by firewalld. Rewriting
>>> them is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>
>> So here you replace the otopi plugin with relevant vdsm-tool code, and
>> the question is why is that better?
>>
>>>
>>> Pros:
>>>
>>> - Engine side involvement is greatly diminished.
>>> - Simple(r).
>>>
>>> Cons:
>>>
>>> - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in the
>>> form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created
>>> services remains an open question. I think we'd like to avoid
implementing
>>> logic that ask whether some service is provided (and then write it if it
>>> isn't...), and so choosing between the dynamic and static approaches is
also
>>> needed. Using the static approach, guaranteeing all services are provided
>>> will be required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and
we'll
>>> still have to use similar mechanism as described in #1 (service string ->
>>> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>
>
--
Didi
8:47 a.m.
I may be too naive, but it all sounds too complex to me.
Is there any reference to the use cases of the firewall configuration?
Few questions:
- Why do we need to use firewalld?
- What is the role of the central management in this regard?
-- Does it need to manage firewalls per host in detail? (are we acting as a
firewall management system?)
-- Does it need to apply a firewall template configuration to all the
hosts? (all being identical)
-- Does it need to specify what services it wants the host to run and
mention if the whole setup should be harden or not?
As far as I know, firewalld and iptables can co-exist, therefore, I do not
see the need to 'upgrade' or perform a hard replacement.
It can be done as an option (firewall-type: iptables/firewalld).
On upgrade it continues with the 'old' definition and on new created host
the default can be firewalld.
Is someone will explicitly want to change it from one to the other, we
could go with remove/add approach to make things simpler.
I personally like the distributed approach, where the upper management
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels
do the explicit work and figure out what they need to do.
If that was the original approach, Engine would have not 'care' what type
of firewall you use down at the host, you could even use a custom firewall,
an NFV firewall solution
or anything that may pop up in the future.
Engine would have just said: I want libvirt, vdsm, ssh, etc... services
opened (for access from ...).
Custom settings? That implies we manage firewalls. So either let the user
add their special stuff on the hosts or provide them with a proper firewall
management interface.
Thanks,
Edy.
On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali
<oourfali(a)redhat.com> wrote:
>
>
> On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
>>
>> Hey Oved,
>>
>> I don't think completely moving away from iptables is foreseeable at
this
>> point, but I could be of course wrong. Either way, upgrading still
needs to
>> be thought of.
>>
>
> I see.
>
>>
>> By stating that the current infrastructure is complex, I was referring
to
>> the entire chain of storing rules in the database, fetching them using a
>> dedicated deployment class consisting of include/exclude logic, sending
them
>> over, unpacking, deploying...
>>
>> This procedure involves a lot of code that could be made redundant if
the
>> required logic is present in the host, which to me seems favorable. It
of
>> course entails other potential difficulties, primarily in the form of
custom
>> services.
>>
>> I don't think otopi's firewalld plugin is any more complex than the
>> potential code that will have to be written in vdsm-tool, however it
>> currently expects the data generated by aforementioned chain. The hybrid
>> approach briefly touches on simplifying Engine's involvement while
retaining
>> use of otopi's plugin.
>>
>
> Okay. I think that writing a new plugin for firewalld is indeed a good
> option, whether you "refactor" the engine side or not.
otopi already has a 'firewalld' plugin. It's already in use, at least
by engine-setup, so we should be a bit careful if we want to change it.
Not preventing/objecting anything, just mentioning.
This plugin's interface currently only takes XML-content as input.
It has no place for configuring existing firewalld services presumably
already provided elsewhere (by firewalld itself or 3rd party packages,
such as vdsm). So if we go that route we probably want to extend this
interface to allow passing service names and rely on them being defined
elsewhere.
A related issue is that for engine-setup, the _input_ is currently
firewalld xml content, and if users choose to configure 'iptables',
this is parsed to generate iptables rules. This is currently an
engine-setup
issue only, but will affect also host deploy flow if we decided to
allow passing service names (without their xml content) and still keep
compatibility to current state and allow configuring iptables on the
host. We'll then be there in the same situation we are at with
engine-setup.
See also https://bugzilla.redhat.com/1432354 . An alternative is obviously
deciding to remove iptables support and support only firewalld, but this
is a rather radical change for users, imo.
See also this for some of the existing behavior of engine-setup:
https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9
IMO we first need to decide what we want, then how to do that. IMO the
questions we have re "what we want" are, more-or-less:
1. Do we want to support in some version X both iptables and firewalld, or
is it ok to stop support for iptables and support only firewalld without
overlap? If so, do we handle upgrades, and how?
2. Do we want to support custom firewalld xml to be configured on the
host by us? Or is it ok to only support choosing among existing services,
which will need to be added to the host using other means (packaged by
firewalld, packaged by 3rd parties, added manually by users)?
3. Opposite of (2.): Do we want to support firewalld services that are
added to the host using other means (see there)? Obviously we do, but:
If we do, do we still want to support also iptables (see (1.))? And if
so, what do we want to then happen?
(2.) and (3.) are not conflicting, each needs its own answer.
My (thoughts about) answers:
1. If done well enough, and considerably simplifies things, I think it's
ok to jump directly from "only iptables" to "only firewalld", but
then
we should announce this ahead of time to give users time to plan/prepare.
If it's not too costly, I'd prefer to support both for the foreseeable
future, though.
2. Latter option here is problematic, if we need/want to allow
customizing services during deploy. E.g. suppose that one day we want
to make the vdsm port configurable. It will be nice if this can be done
by only changing things on the engine, without having to distribute
changes (conf and/or packages) to all hosts before host-deploy.
I'd say we can go a long way here by having a strict requirement from
all services that we need/want on hosts to have official IANA-registered
port numbers - then, it's imo much easier to tell users "If you want to
change the port for service X, you have to (long list of complex actions
goes here)". Currently, where services are not registered, we risk
conflicts with existing services, requiring the user to change ports -
and so we can't make this process too difficult. No idea how important
this is in practice.
3. Not sure :-( I'd say that if we want to support both iptables and
firewalld together, and support both "xml in engine" and "xml in
host",
then it might be ok if the custom rules/services will not automatically
apply to both iptables and firewalld. Meaning - you can set both custom
iptables rules and firewalld services, but it's up to you to make sure
they actually do the same thing if that's important to you.
Bottom line: I think we should summarize the open questions in a way
that will make it clear to users how each answer will affect them, and
ask what they think. Leon already started doing this [1], I only saw
one reply. Perhaps this means that users do not care that much, and
expect us to just decide and tell them what we decided (and always to
keep the option to disable this feature, as is possible today, and do
this themselves, if our choice of solution does not fit their needs).
I know this is way too loooong, sorry. Feel free to ignore, but then
please ask simpler questions if you want shorter answers :-)
[1] http://lists.ovirt.org/pipermail/users/2017-March/080600.html
>
>>
>>
>>
>> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali <oourfali(a)redhat.com>
wrote:
>>>
>>> top-posting:
>>> You need to also consider how upgrade will be handled, right?
>>> Or iptables will still remain supported?
>>>
>>> Also, see some comments inline.
>>>
>>> Regards,
>>> Oved
>>>
>>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
>>> wrote:
>>>>
>>>>
>>>> Hey,
>>>>
>>>> We're looking to migrate from iptables to firewalld. We came up with
a
>>>> couple of possible approaches we'd like opinions on. I'll list
the
options
>>>> first, and will
>>>>
>>>> 1) Replicate existing flow:
>>>>
>>>> As of date, iptable rules are inserted in the database via SQL config
>>>> files. During host deployment, VdsDeployIptablesUnit adds the
required rules
>>>> (based on cluster/firewall configuration) to the deployment
configuration,
>>>> en route to being deployed on the host via otopi and its iptables
plugin.
>>>>
>>>> Pros:
>>>>
>>>> - Reuse of existing infrastructure.
>>>>
>>>> Cons:
>>>>
>>>> - Current infrastructure is overly complex...
>>>
>>>
>>> Can you elaborate?
>>> I'm not an otopi expert, but I think that otopi plugins shouldn't
be
more
>>> complex than what you describe in section #2, and the plugins were
meant in
>>> order to handle such cases.
>>>
>>>> - Many of the required services are provided by firewalld. Rewriting
>>>> them is wasteful; specifying them (instead of providing actual
service .xml
>>>> content) will require adaptations on both (engine/host) sides. More
on that
>>>> later.
>>>>
>>>>
>>>> 2) Host side based configuration:
>>>>
>>>> Essentially, all the required logic (aforementioned cluster/firewall
>>>> configuration) to determine if/how firewalld should be deployed could
be
>>>> passed on to the host via ohd. Vdsm could take on the responsibility
of
>>>> examining the relevant configuration, and then creating and/or adding
the
>>>> required services (using vdsm.conf and vdsm-tool).
>>>>
>>>
>>> So here you replace the otopi plugin with relevant vdsm-tool code, and
>>> the question is why is that better?
>>>
>>>>
>>>> Pros:
>>>>
>>>> - Engine side involvement is greatly diminished.
>>>> - Simple(r).
>>>>
>>>> Cons:
>>>>
>>>> - Custom services/rules capabilities will have to be rethought and
>>>> re-implemented (current infrastructure supports custom iptables rules
by
>>>> being specified in the SQL config file).
>>>>
>>>>
>>>> 3) Some other hybrid approach:
>>>>
>>>> If we're able to guarantee all the required firewalld services are
>>>> statically provided one way or the other, the current procedure could
be
>>>> replicated and be made more simpler. Instead of providing xml content
in the
>>>> form of strings, service names could be supplied. The responsibility
of
>>>> actual service deployment becomes easier, and could be left to otopi
(with
>>>> the appropriate modifications) or switched over to vdsm.
>>>>
>>>> --
>>>>
>>>> Regardless, usage of statically provided vs. dynamically created
>>>> services remains an open question. I think we'd like to avoid
implementing
>>>> logic that ask whether some service is provided (and then write it if
it
>>>> isn't...), and so choosing between the dynamic and static
approaches
is also
>>>> needed. Using the static approach, guaranteeing all services are
provided
>>>> will be required.
>>>>
>>>> I do believe guaranteeing the presence of all required services is
worth
>>>> it, however custom services aren't going to be naively compatible,
and we'll
>>>> still have to use similar mechanism as described in #1 (service
string ->
>>>> .xml -> addition of service name to active zone).
>>>>
>>>>
>>>> Your thoughts are welcome.
>>>>
>>>> Thanks,
>>>> Leon
>>>>
>>>
>>
>
--
Didi
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
8:49 a.m.
1) Do we actually need iptables for any reason that isn't a legacy
consideration?
2 & 3) I am in favor of treating custom services as a requirement and plan
accordingly. Many (most, even) of the services are already provided by
either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
(e.g. gluster). Some are missing (I've recently created a pull request for
ovirt-imageio to firewalld, for example) and I hope we'll be able to get
all the services to be statically provided (by either firewalld or the
relevant 3rd party packages).
Ideally I think we'd like use statically provided services, and provide the
capability to provide additional services (I'm not a fan of the current
methodology of converting strings into xmls). I don't think we'd want to
limit usage to just statically provided services. (2)
As previously stated, I don't see a technical reason to keep iptables under
consideration. (3)
On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com> wrote:
1. Do we want to support in some version X both iptables and firewalld, or
is it ok to stop support for iptables and support only firewalld without
overlap? If so, do we handle upgrades, and how?
2. Do we want to support custom firewalld xml to be configured on the
host by us? Or is it ok to only support choosing among existing services,
which will need to be added to the host using other means (packaged by
firewalld, packaged by 3rd parties, added manually by users)?
3. Opposite of (2.): Do we want to support firewalld services that are
added to the host using other means (see there)? Obviously we do, but:
If we do, do we still want to support also iptables (see (1.))? And if
so, what do we want to then happen?
(2.) and (3.) are not conflicting, each needs its own answer.
--
Didi
8:59 a.m.
On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
1) Do we actually need iptables for any reason that isn't a
legacy
consideration?
No idea personally.
Perhaps some users prefer that, and/or need that for integration with other
systems/solutions/whatever.
If we drop iptables, how do you suggest to treat upgrades?
2 & 3) I am in favor of treating custom services as a requirement and plan
accordingly. Many (most, even) of the services are already provided by
either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages (e.g.
gluster). Some are missing (I've recently created a pull request for
ovirt-imageio to firewalld, for example) and I hope we'll be able to get all
the services to be statically provided (by either firewalld or the relevant
3rd party packages).
Ideally I think we'd like use statically provided services, and provide the
capability to provide additional services (I'm not a fan of the current
methodology of converting strings into xmls). I don't think we'd want to
limit usage to just statically provided services. (2)
As previously stated, I don't see a technical reason to keep iptables under
consideration. (3)
On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com> wrote:
>
>
> 1. Do we want to support in some version X both iptables and firewalld, or
> is it ok to stop support for iptables and support only firewalld without
> overlap? If so, do we handle upgrades, and how?
>
> 2. Do we want to support custom firewalld xml to be configured on the
> host by us? Or is it ok to only support choosing among existing services,
> which will need to be added to the host using other means (packaged by
> firewalld, packaged by 3rd parties, added manually by users)?
>
> 3. Opposite of (2.): Do we want to support firewalld services that are
> added to the host using other means (see there)? Obviously we do, but:
> If we do, do we still want to support also iptables (see (1.))? And if
> so, what do we want to then happen?
>
> (2.) and (3.) are not conflicting, each needs its own answer.
>
>
> --
> Didi
--
Didi
10:01 a.m.
Effectively, upgrading will leave lingering (but nonetheless operational)
iptables rules on the hosts. I'm not even sure there needs to be special
upgrade treatment?
On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
wrote:
> 1) Do we actually need iptables for any reason that isn't a legacy
> consideration?
No idea personally.
Perhaps some users prefer that, and/or need that for integration with other
systems/solutions/whatever.
If we drop iptables, how do you suggest to treat upgrades?
>
> 2 & 3) I am in favor of treating custom services as a requirement and
plan
> accordingly. Many (most, even) of the services are already provided by
> either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
(e.g.
> gluster). Some are missing (I've recently created a pull request for
> ovirt-imageio to firewalld, for example) and I hope we'll be able to get
all
> the services to be statically provided (by either firewalld or the
relevant
> 3rd party packages).
>
> Ideally I think we'd like use statically provided services, and provide
the
> capability to provide additional services (I'm not a fan of the current
> methodology of converting strings into xmls). I don't think we'd want to
> limit usage to just statically provided services. (2)
>
> As previously stated, I don't see a technical reason to keep iptables
under
> consideration. (3)
>
>
> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>>
>>
>> 1. Do we want to support in some version X both iptables and firewalld,
or
>> is it ok to stop support for iptables and support only firewalld without
>> overlap? If so, do we handle upgrades, and how?
>>
>> 2. Do we want to support custom firewalld xml to be configured on the
>> host by us? Or is it ok to only support choosing among existing
services,
>> which will need to be added to the host using other means (packaged by
>> firewalld, packaged by 3rd parties, added manually by users)?
>>
>> 3. Opposite of (2.): Do we want to support firewalld services that are
>> added to the host using other means (see there)? Obviously we do, but:
>> If we do, do we still want to support also iptables (see (1.))? And if
>> so, what do we want to then happen?
>>
>> (2.) and (3.) are not conflicting, each needs its own answer.
>>
>>
>> --
>> Didi
>
>
--
Didi
1:01 a.m.
On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Effectively, upgrading will leave lingering (but nonetheless
operational)
iptables rules on the hosts. I'm not even sure there needs to be special
upgrade treatment?
Please describe the expected flow.
Please note that at least when I tried, 'systemctl start firewalld' stops
iptables.
Thanks,
On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com> wrote:
>
> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber(a)redhat.com>
> wrote:
> > 1) Do we actually need iptables for any reason that isn't a legacy
> > consideration?
>
> No idea personally.
>
> Perhaps some users prefer that, and/or need that for integration with
> other
> systems/solutions/whatever.
>
> If we drop iptables, how do you suggest to treat upgrades?
>
> >
> > 2 & 3) I am in favor of treating custom services as a requirement and
> > plan
> > accordingly. Many (most, even) of the services are already provided by
> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
> > (e.g.
> > gluster). Some are missing (I've recently created a pull request for
> > ovirt-imageio to firewalld, for example) and I hope we'll be able to get
> > all
> > the services to be statically provided (by either firewalld or the
> > relevant
> > 3rd party packages).
> >
> > Ideally I think we'd like use statically provided services, and provide
> > the
> > capability to provide additional services (I'm not a fan of the current
> > methodology of converting strings into xmls). I don't think we'd want
to
> > limit usage to just statically provided services. (2)
> >
> > As previously stated, I don't see a technical reason to keep iptables
> > under
> > consideration. (3)
> >
> >
> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com>
> > wrote:
> >>
> >>
> >> 1. Do we want to support in some version X both iptables and firewalld,
> >> or
> >> is it ok to stop support for iptables and support only firewalld
> >> without
> >> overlap? If so, do we handle upgrades, and how?
> >>
> >> 2. Do we want to support custom firewalld xml to be configured on the
> >> host by us? Or is it ok to only support choosing among existing
> >> services,
> >> which will need to be added to the host using other means (packaged by
> >> firewalld, packaged by 3rd parties, added manually by users)?
> >>
> >> 3. Opposite of (2.): Do we want to support firewalld services that are
> >> added to the host using other means (see there)? Obviously we do, but:
> >> If we do, do we still want to support also iptables (see (1.))? And if
> >> so, what do we want to then happen?
> >>
> >> (2.) and (3.) are not conflicting, each needs its own answer.
> >>
> >>
> >> --
> >> Didi
> >
> >
>
>
>
> --
> Didi
--
Didi
3:55 a.m.
Hi,
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:
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
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)
3. For newly installed host I'd just use firewalld
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)
Martin
On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
wrote:
> Effectively, upgrading will leave lingering (but nonetheless operational)
> iptables rules on the hosts. I'm not even sure there needs to be special
> upgrade treatment?
Please describe the expected flow.
Please note that at least when I tried, 'systemctl start firewalld' stops
iptables.
Thanks,
>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > 1) Do we actually need iptables for any reason that isn't a legacy
>> > consideration?
>>
>> No idea personally.
>>
>> Perhaps some users prefer that, and/or need that for integration with
>> other
>> systems/solutions/whatever.
>>
>> If we drop iptables, how do you suggest to treat upgrades?
>>
>> >
>> > 2 & 3) I am in favor of treating custom services as a requirement and
>> > plan
>> > accordingly. Many (most, even) of the services are already provided by
>> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
>> > (e.g.
>> > gluster). Some are missing (I've recently created a pull request for
>> > ovirt-imageio to firewalld, for example) and I hope we'll be able to
get
>> > all
>> > the services to be statically provided (by either firewalld or the
>> > relevant
>> > 3rd party packages).
>> >
>> > Ideally I think we'd like use statically provided services, and
provide
>> > the
>> > capability to provide additional services (I'm not a fan of the
current
>> > methodology of converting strings into xmls). I don't think we'd
want
to
>> > limit usage to just statically provided services. (2)
>> >
>> > As previously stated, I don't see a technical reason to keep iptables
>> > under
>> > consideration. (3)
>> >
>> >
>> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
<didi(a)redhat.com>
>> > wrote:
>> >>
>> >>
>> >> 1. Do we want to support in some version X both iptables and
firewalld,
>> >> or
>> >> is it ok to stop support for iptables and support only firewalld
>> >> without
>> >> overlap? If so, do we handle upgrades, and how?
>> >>
>> >> 2. Do we want to support custom firewalld xml to be configured on the
>> >> host by us? Or is it ok to only support choosing among existing
>> >> services,
>> >> which will need to be added to the host using other means (packaged
by
>> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >>
>> >> 3. Opposite of (2.): Do we want to support firewalld services that
are
>> >> added to the host using other means (see there)? Obviously we do,
but:
>> >> If we do, do we still want to support also iptables (see (1.))? And
if
>> >> so, what do we want to then happen?
>> >>
>> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>
--
Didi
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5 a.m.
On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina(a)redhat.com> wrote:
Hi,
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:
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
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.
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)
Agreed.
3. For newly installed host I'd just use firewalld
Agreed.
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)
That's a good question. If a user had the default, non-changed policy we
have had in iptables - sure.
If not, I think it may be a bit of a challenge to switch otherwise.
Y.
Martin
On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com>
> wrote:
> > Effectively, upgrading will leave lingering (but nonetheless
> operational)
> > iptables rules on the hosts. I'm not even sure there needs to be special
> > upgrade treatment?
>
> Please describe the expected flow.
>
> Please note that at least when I tried, 'systemctl start firewalld' stops
> iptables.
>
> Thanks,
>
> >
> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
> >>
> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber(a)redhat.com>
> >> wrote:
> >> > 1) Do we actually need iptables for any reason that isn't a legacy
> >> > consideration?
> >>
> >> No idea personally.
> >>
> >> Perhaps some users prefer that, and/or need that for integration with
> >> other
> >> systems/solutions/whatever.
> >>
> >> If we drop iptables, how do you suggest to treat upgrades?
> >>
> >> >
> >> > 2 & 3) I am in favor of treating custom services as a requirement
and
> >> > plan
> >> > accordingly. Many (most, even) of the services are already provided
> by
> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
> packages
> >> > (e.g.
> >> > gluster). Some are missing (I've recently created a pull request
for
> >> > ovirt-imageio to firewalld, for example) and I hope we'll be able
to
> get
> >> > all
> >> > the services to be statically provided (by either firewalld or the
> >> > relevant
> >> > 3rd party packages).
> >> >
> >> > Ideally I think we'd like use statically provided services, and
> provide
> >> > the
> >> > capability to provide additional services (I'm not a fan of the
> current
> >> > methodology of converting strings into xmls). I don't think
we'd
> want to
> >> > limit usage to just statically provided services. (2)
> >> >
> >> > As previously stated, I don't see a technical reason to keep
iptables
> >> > under
> >> > consideration. (3)
> >> >
> >> >
> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
<didi(a)redhat.com
> >
> >> > wrote:
> >> >>
> >> >>
> >> >> 1. Do we want to support in some version X both iptables and
> firewalld,
> >> >> or
> >> >> is it ok to stop support for iptables and support only firewalld
> >> >> without
> >> >> overlap? If so, do we handle upgrades, and how?
> >> >>
> >> >> 2. Do we want to support custom firewalld xml to be configured on
> the
> >> >> host by us? Or is it ok to only support choosing among existing
> >> >> services,
> >> >> which will need to be added to the host using other means
(packaged
> by
> >> >> firewalld, packaged by 3rd parties, added manually by users)?
> >> >>
> >> >> 3. Opposite of (2.): Do we want to support firewalld services that
> are
> >> >> added to the host using other means (see there)? Obviously we do,
> but:
> >> >> If we do, do we still want to support also iptables (see (1.))?
And
> if
> >> >> so, what do we want to then happen?
> >> >>
> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
> >> >>
> >> >>
> >> >> --
> >> >> Didi
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Didi
> >
> >
>
>
>
> --
> Didi
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
5:20 a.m.
On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina(a)redhat.com>
wrote:
> Hi,
>
> 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:
>
> 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
>
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.
Right, we should take care only about services/ports which we need. So we
probably could drop the ability for users to define their own custom
services/ports within engine for firewalld and force them to use Ansible
or other tools to handle their own configuration.
>
> 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)
>
Agreed.
>
> 3. For newly installed host I'd just use firewalld
>
Agreed.
>
> 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)
>
That's a good question. If a user had the default, non-changed policy we
have had in iptables - sure.
If not, I think it may be a bit of a challenge to switch otherwise.
Right. We could detect if there's some custom firewall rules in
IPTablesConfigSiteCustom engine-config option and if not we could probably
assume that switching to firewalld could be performed.
We could also mark iptables configuration as deprecated in 4.2 and declare
that it will be removed in 4.3. That would add some time for users to
prepare for the switch ...
Y.
>
>
>
> Martin
>
>
>
> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
>
>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > Effectively, upgrading will leave lingering (but nonetheless
>> operational)
>> > iptables rules on the hosts. I'm not even sure there needs to be
>> special
>> > upgrade treatment?
>>
>> Please describe the expected flow.
>>
>> Please note that at least when I tried, 'systemctl start firewalld'
stops
>> iptables.
>>
>> Thanks,
>>
>> >
>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com>
>> wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > 1) Do we actually need iptables for any reason that isn't a
legacy
>> >> > consideration?
>> >>
>> >> No idea personally.
>> >>
>> >> Perhaps some users prefer that, and/or need that for integration with
>> >> other
>> >> systems/solutions/whatever.
>> >>
>> >> If we drop iptables, how do you suggest to treat upgrades?
>> >>
>> >> >
>> >> > 2 & 3) I am in favor of treating custom services as a
requirement
>> and
>> >> > plan
>> >> > accordingly. Many (most, even) of the services are already
provided
>> by
>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>> packages
>> >> > (e.g.
>> >> > gluster). Some are missing (I've recently created a pull
request for
>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be
able
>> to get
>> >> > all
>> >> > the services to be statically provided (by either firewalld or the
>> >> > relevant
>> >> > 3rd party packages).
>> >> >
>> >> > Ideally I think we'd like use statically provided services,
and
>> provide
>> >> > the
>> >> > capability to provide additional services (I'm not a fan of
the
>> current
>> >> > methodology of converting strings into xmls). I don't think
we'd
>> want to
>> >> > limit usage to just statically provided services. (2)
>> >> >
>> >> > As previously stated, I don't see a technical reason to keep
>> iptables
>> >> > under
>> >> > consideration. (3)
>> >> >
>> >> >
>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <
>> didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> 1. Do we want to support in some version X both iptables and
>> firewalld,
>> >> >> or
>> >> >> is it ok to stop support for iptables and support only
firewalld
>> >> >> without
>> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >>
>> >> >> 2. Do we want to support custom firewalld xml to be configured
on
>> the
>> >> >> host by us? Or is it ok to only support choosing among
existing
>> >> >> services,
>> >> >> which will need to be added to the host using other means
>> (packaged by
>> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >> >>
>> >> >> 3. Opposite of (2.): Do we want to support firewalld services
that
>> are
>> >> >> added to the host using other means (see there)? Obviously we
do,
>> but:
>> >> >> If we do, do we still want to support also iptables (see
(1.))?
>> And if
>> >> >> so, what do we want to then happen?
>> >> >>
>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
5:46 a.m.
On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <mperina(a)redhat.com> wrote:
On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina(a)redhat.com>
> wrote:
>
>> Hi,
>>
>> 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:
>>
>> 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
>>
>
> 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.
>
Right, we should take care only about services/ports which we need. So we
probably could drop the ability for users to define their own custom
services/ports within engine for firewalld and force them to use Ansible
or other tools to handle their own configuration.
Right, so why not create an Ansible playbook which the users can change
(extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?
...
>
>>
>> 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)
>>
>
... and then ovirt-host-deploy will be in charge of executing that
playbook? Seems fairly straightforward.
Y.
> Agreed.
>
>
>>
>> 3. For newly installed host I'd just use firewalld
>>
>
> Agreed.
>
>
>>
>> 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)
>>
>
> That's a good question. If a user had the default, non-changed policy we
> have had in iptables - sure.
> If not, I think it may be a bit of a challenge to switch otherwise.
>
Right. We could detect if there's some custom firewall rules in
IPTablesConfigSiteCustom engine-config option and if not we could probably
assume that switching to firewalld could be performed.
We could also mark iptables configuration as deprecated in 4.2 and declare
that it will be removed in 4.3. That would add some time for users to
prepare for the switch ...
Y.
>
>
>>
>>
>>
>> Martin
>>
>>
>>
>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David <didi(a)redhat.com>
>> wrote:
>>
>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com>
>>> wrote:
>>> > Effectively, upgrading will leave lingering (but nonetheless
>>> operational)
>>> > iptables rules on the hosts. I'm not even sure there needs to be
>>> special
>>> > upgrade treatment?
>>>
>>> Please describe the expected flow.
>>>
>>> Please note that at least when I tried, 'systemctl start firewalld'
>>> stops
>>> iptables.
>>>
>>> Thanks,
>>>
>>> >
>>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
<didi(a)redhat.com>
>>> wrote:
>>> >>
>>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>>> >> wrote:
>>> >> > 1) Do we actually need iptables for any reason that isn't a
legacy
>>> >> > consideration?
>>> >>
>>> >> No idea personally.
>>> >>
>>> >> Perhaps some users prefer that, and/or need that for integration
with
>>> >> other
>>> >> systems/solutions/whatever.
>>> >>
>>> >> If we drop iptables, how do you suggest to treat upgrades?
>>> >>
>>> >> >
>>> >> > 2 & 3) I am in favor of treating custom services as a
requirement
>>> and
>>> >> > plan
>>> >> > accordingly. Many (most, even) of the services are already
>>> provided by
>>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>>> packages
>>> >> > (e.g.
>>> >> > gluster). Some are missing (I've recently created a pull
request
>>> for
>>> >> > ovirt-imageio to firewalld, for example) and I hope we'll
be able
>>> to get
>>> >> > all
>>> >> > the services to be statically provided (by either firewalld or
the
>>> >> > relevant
>>> >> > 3rd party packages).
>>> >> >
>>> >> > Ideally I think we'd like use statically provided services,
and
>>> provide
>>> >> > the
>>> >> > capability to provide additional services (I'm not a fan of
the
>>> current
>>> >> > methodology of converting strings into xmls). I don't think
we'd
>>> want to
>>> >> > limit usage to just statically provided services. (2)
>>> >> >
>>> >> > As previously stated, I don't see a technical reason to
keep
>>> iptables
>>> >> > under
>>> >> > consideration. (3)
>>> >> >
>>> >> >
>>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <
>>> didi(a)redhat.com>
>>> >> > wrote:
>>> >> >>
>>> >> >>
>>> >> >> 1. Do we want to support in some version X both iptables
and
>>> firewalld,
>>> >> >> or
>>> >> >> is it ok to stop support for iptables and support only
firewalld
>>> >> >> without
>>> >> >> overlap? If so, do we handle upgrades, and how?
>>> >> >>
>>> >> >> 2. Do we want to support custom firewalld xml to be
configured on
>>> the
>>> >> >> host by us? Or is it ok to only support choosing among
existing
>>> >> >> services,
>>> >> >> which will need to be added to the host using other means
>>> (packaged by
>>> >> >> firewalld, packaged by 3rd parties, added manually by
users)?
>>> >> >>
>>> >> >> 3. Opposite of (2.): Do we want to support firewalld
services
>>> that are
>>> >> >> added to the host using other means (see there)? Obviously
we do,
>>> but:
>>> >> >> If we do, do we still want to support also iptables (see
(1.))?
>>> And if
>>> >> >> so, what do we want to then happen?
>>> >> >>
>>> >> >> (2.) and (3.) are not conflicting, each needs its own
answer.
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Didi
>>> >> >
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Didi
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Didi
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
6:10 a.m.
Right, so why not create an Ansible playbook which the users can
change
(extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?
I think I like the playbook proposal the best.
Lets assume the engine provides a firewall.yaml playbook somewhere in /etc:
- The default playbook would contain our default firewalld
configuration (we should also provide it in /usr/share/doc to give the
user a reference)
- The engine or host deploy script can provide ansible variables so
the playbook can even be a parametrized one (port numbers)
- The user can add rules he needs
- The user can REPLACE the content with iptables rules if he wishes
so (we can even say it is unsupported, but possible)
As an extension:
- We can provide ovirt-engine-firewalld ansible role with the default
config so we can properly update files using RPM. The user defined (or
default) playbook would just call this role and would stay intact
during package upgrades.
This is outside of database, allows customization and adapts to
whatever firewall backend we might need.
--
Martin Sivak
SLA / oVirt
On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <mperina(a)redhat.com> wrote:
>>
>>
>>
>> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina(a)redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> 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:
>>>>
>>>> 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
>>>
>>>
>>> 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.
>>
>>
>> Right, we should take care only about services/ports which we need. So we
>> probably could drop the ability for users to define their own custom
>> services/ports within engine for firewalld and force them to use Ansible or
>> other tools to handle their own configuration.
>
>
Right, so why not create an Ansible playbook which the users can
change
(extend?), based on http://docs.ansible.com/ansible/firewalld_module.html ?
>
...
>>
>>
>>>
>>>>
>>>>
>>>> 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)
>
>
> ... and then ovirt-host-deploy will be in charge of executing that
> playbook? Seems fairly straightforward.
> Y.
>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 3. For newly installed host I'd just use firewalld
>>>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 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)
>>>
>>>
>>> That's a good question. If a user had the default, non-changed policy we
>>> have had in iptables - sure.
>>> If not, I think it may be a bit of a challenge to switch otherwise.
>>
>>
>> Right. We could detect if there's some custom firewall rules in
>> IPTablesConfigSiteCustom engine-config option and if not we could probably
>> assume that switching to firewalld could be performed.
>>
>> We could also mark iptables configuration as deprecated in 4.2 and declare
>> that it will be removed in 4.3. That would add some time for users to
>> prepare for the switch ...
>>
>>> Y.
>>>
>>>>
>>>>
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David
<didi(a)redhat.com>
>>>> wrote:
>>>>>
>>>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>>>>> wrote:
>>>>> > Effectively, upgrading will leave lingering (but nonetheless
>>>>> > operational)
>>>>> > iptables rules on the hosts. I'm not even sure there needs
to be
>>>>> > special
>>>>> > upgrade treatment?
>>>>>
>>>>> Please describe the expected flow.
>>>>>
>>>>> Please note that at least when I tried, 'systemctl start
firewalld'
>>>>> stops
>>>>> iptables.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> >
>>>>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
<didi(a)redhat.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>>>>> >> wrote:
>>>>> >> > 1) Do we actually need iptables for any reason that
isn't a legacy
>>>>> >> > consideration?
>>>>> >>
>>>>> >> No idea personally.
>>>>> >>
>>>>> >> Perhaps some users prefer that, and/or need that for
integration
>>>>> >> with
>>>>> >> other
>>>>> >> systems/solutions/whatever.
>>>>> >>
>>>>> >> If we drop iptables, how do you suggest to treat upgrades?
>>>>> >>
>>>>> >> >
>>>>> >> > 2 & 3) I am in favor of treating custom services as
a requirement
>>>>> >> > and
>>>>> >> > plan
>>>>> >> > accordingly. Many (most, even) of the services are
already
>>>>> >> > provided by
>>>>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd
party
>>>>> >> > packages
>>>>> >> > (e.g.
>>>>> >> > gluster). Some are missing (I've recently created a
pull request
>>>>> >> > for
>>>>> >> > ovirt-imageio to firewalld, for example) and I hope
we'll be able
>>>>> >> > to get
>>>>> >> > all
>>>>> >> > the services to be statically provided (by either
firewalld or the
>>>>> >> > relevant
>>>>> >> > 3rd party packages).
>>>>> >> >
>>>>> >> > Ideally I think we'd like use statically provided
services, and
>>>>> >> > provide
>>>>> >> > the
>>>>> >> > capability to provide additional services (I'm not
a fan of the
>>>>> >> > current
>>>>> >> > methodology of converting strings into xmls). I
don't think we'd
>>>>> >> > want to
>>>>> >> > limit usage to just statically provided services. (2)
>>>>> >> >
>>>>> >> > As previously stated, I don't see a technical
reason to keep
>>>>> >> > iptables
>>>>> >> > under
>>>>> >> > consideration. (3)
>>>>> >> >
>>>>> >> >
>>>>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
>>>>> >> > <didi(a)redhat.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> 1. Do we want to support in some version X both
iptables and
>>>>> >> >> firewalld,
>>>>> >> >> or
>>>>> >> >> is it ok to stop support for iptables and support
only firewalld
>>>>> >> >> without
>>>>> >> >> overlap? If so, do we handle upgrades, and how?
>>>>> >> >>
>>>>> >> >> 2. Do we want to support custom firewalld xml to be
configured on
>>>>> >> >> the
>>>>> >> >> host by us? Or is it ok to only support choosing
among existing
>>>>> >> >> services,
>>>>> >> >> which will need to be added to the host using other
means
>>>>> >> >> (packaged by
>>>>> >> >> firewalld, packaged by 3rd parties, added manually
by users)?
>>>>> >> >>
>>>>> >> >> 3. Opposite of (2.): Do we want to support
firewalld services
>>>>> >> >> that are
>>>>> >> >> added to the host using other means (see there)?
Obviously we do,
>>>>> >> >> but:
>>>>> >> >> If we do, do we still want to support also iptables
(see (1.))?
>>>>> >> >> And if
>>>>> >> >> so, what do we want to then happen?
>>>>> >> >>
>>>>> >> >> (2.) and (3.) are not conflicting, each needs its
own answer.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Didi
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Didi
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Didi
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
6:38 a.m.
Hi,
I like option number 3 the most from reading the comments.
We are not a configuration management system, so custom rules should not be
a main consideration.
VDSM should probably enable the firewalld rules it needs to work and engine
should not care about firewall at all.
A user wanting to add more rules then this should probably use the ones
planned in:
https://github.com/cockpit-project/system-api-roles
Thanks,
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Mon, Mar 27, 2017 at 2:10 PM, Martin Sivak <msivak(a)redhat.com> wrote:
> Right, so why not create an Ansible playbook which the users can
change
> (extend?), based on http://docs.ansible.com/
ansible/firewalld_module.html ?
I think I like the playbook proposal the best.
Lets assume the engine provides a firewall.yaml playbook somewhere in /etc:
- The default playbook would contain our default firewalld
configuration (we should also provide it in /usr/share/doc to give the
user a reference)
- The engine or host deploy script can provide ansible variables so
the playbook can even be a parametrized one (port numbers)
- The user can add rules he needs
- The user can REPLACE the content with iptables rules if he wishes
so (we can even say it is unsupported, but possible)
As an extension:
- We can provide ovirt-engine-firewalld ansible role with the default
config so we can properly update files using RPM. The user defined (or
default) playbook would just call this role and would stay intact
during package upgrades.
This is outside of database, allows customization and adapts to
whatever firewall backend we might need.
--
Martin Sivak
SLA / oVirt
On Mon, Mar 27, 2017 at 12:46 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 1:20 PM, Martin Perina <mperina(a)redhat.com>
wrote:
>>
>>
>>
>> On Mon, Mar 27, 2017 at 12:00 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Mon, Mar 27, 2017 at 11:55 AM, Martin Perina <mperina(a)redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> 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:
>>>>
>>>> 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
>>>
>>>
>>> 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.
>>
>>
>> Right, we should take care only about services/ports which we need. So
we
>> probably could drop the ability for users to define their own custom
>> services/ports within engine for firewalld and force them to use
Ansible or
>> other tools to handle their own configuration.
>
>
> Right, so why not create an Ansible playbook which the users can change
> (extend?), based on http://docs.ansible.com/
ansible/firewalld_module.html ?
> ...
>>
>>
>>>
>>>>
>>>>
>>>> 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)
>
>
> ... and then ovirt-host-deploy will be in charge of executing that
> playbook? Seems fairly straightforward.
> Y.
>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 3. For newly installed host I'd just use firewalld
>>>
>>>
>>> Agreed.
>>>
>>>>
>>>>
>>>> 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)
>>>
>>>
>>> That's a good question. If a user had the default, non-changed policy
we
>>> have had in iptables - sure.
>>> If not, I think it may be a bit of a challenge to switch otherwise.
>>
>>
>> Right. We could detect if there's some custom firewall rules in
>> IPTablesConfigSiteCustom engine-config option and if not we could
probably
>> assume that switching to firewalld could be performed.
>>
>> We could also mark iptables configuration as deprecated in 4.2 and
declare
>> that it will be removed in 4.3. That would add some time for users to
>> prepare for the switch ...
>>
>>> Y.
>>>
>>>>
>>>>
>>>>
>>>>
>>>> Martin
>>>>
>>>>
>>>>
>>>> On Mon, Mar 27, 2017 at 8:01 AM, Yedidyah Bar David
<didi(a)redhat.com>
>>>> wrote:
>>>>>
>>>>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>>>>> wrote:
>>>>> > Effectively, upgrading will leave lingering (but nonetheless
>>>>> > operational)
>>>>> > iptables rules on the hosts. I'm not even sure there needs
to be
>>>>> > special
>>>>> > upgrade treatment?
>>>>>
>>>>> Please describe the expected flow.
>>>>>
>>>>> Please note that at least when I tried, 'systemctl start
firewalld'
>>>>> stops
>>>>> iptables.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> >
>>>>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <
didi(a)redhat.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <
lgoldber(a)redhat.com>
>>>>> >> wrote:
>>>>> >> > 1) Do we actually need iptables for any reason that
isn't a
legacy
>>>>> >> > consideration?
>>>>> >>
>>>>> >> No idea personally.
>>>>> >>
>>>>> >> Perhaps some users prefer that, and/or need that for
integration
>>>>> >> with
>>>>> >> other
>>>>> >> systems/solutions/whatever.
>>>>> >>
>>>>> >> If we drop iptables, how do you suggest to treat upgrades?
>>>>> >>
>>>>> >> >
>>>>> >> > 2 & 3) I am in favor of treating custom services
as a
requirement
>>>>> >> > and
>>>>> >> > plan
>>>>> >> > accordingly. Many (most, even) of the services are
already
>>>>> >> > provided by
>>>>> >> > either firewalld itself (e.g. vdsm, libvirt) or the
3rd party
>>>>> >> > packages
>>>>> >> > (e.g.
>>>>> >> > gluster). Some are missing (I've recently created
a pull request
>>>>> >> > for
>>>>> >> > ovirt-imageio to firewalld, for example) and I hope
we'll be
able
>>>>> >> > to get
>>>>> >> > all
>>>>> >> > the services to be statically provided (by either
firewalld or
the
>>>>> >> > relevant
>>>>> >> > 3rd party packages).
>>>>> >> >
>>>>> >> > Ideally I think we'd like use statically provided
services, and
>>>>> >> > provide
>>>>> >> > the
>>>>> >> > capability to provide additional services (I'm not
a fan of the
>>>>> >> > current
>>>>> >> > methodology of converting strings into xmls). I
don't think we'd
>>>>> >> > want to
>>>>> >> > limit usage to just statically provided services. (2)
>>>>> >> >
>>>>> >> > As previously stated, I don't see a technical
reason to keep
>>>>> >> > iptables
>>>>> >> > under
>>>>> >> > consideration. (3)
>>>>> >> >
>>>>> >> >
>>>>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
>>>>> >> > <didi(a)redhat.com>
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> 1. Do we want to support in some version X both
iptables and
>>>>> >> >> firewalld,
>>>>> >> >> or
>>>>> >> >> is it ok to stop support for iptables and support
only
firewalld
>>>>> >> >> without
>>>>> >> >> overlap? If so, do we handle upgrades, and how?
>>>>> >> >>
>>>>> >> >> 2. Do we want to support custom firewalld xml to
be configured
on
>>>>> >> >> the
>>>>> >> >> host by us? Or is it ok to only support choosing
among existing
>>>>> >> >> services,
>>>>> >> >> which will need to be added to the host using
other means
>>>>> >> >> (packaged by
>>>>> >> >> firewalld, packaged by 3rd parties, added manually
by users)?
>>>>> >> >>
>>>>> >> >> 3. Opposite of (2.): Do we want to support
firewalld services
>>>>> >> >> that are
>>>>> >> >> added to the host using other means (see there)?
Obviously we
do,
>>>>> >> >> but:
>>>>> >> >> If we do, do we still want to support also
iptables (see (1.))?
>>>>> >> >> And if
>>>>> >> >> so, what do we want to then happen?
>>>>> >> >>
>>>>> >> >> (2.) and (3.) are not conflicting, each needs its
own answer.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Didi
>>>>> >> >
>>>>> >> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Didi
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Didi
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>>
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:05 a.m.
Why do we need to use firewalld?
I think that the initial
trigger was the realization we're completely
lacking ipv6 handling (which requires use of another, similar tool in
ip6tables) in the current infrastructure.
Assessing the situation and reviewing the code for potential solutions led
us to a couple of conclusions:
- Current flow is overly complex and should be reexamined regardless.
- The naive solution would be to duplicate the current flow for ip6tables,
potentially leading to a lot of boilerplate code. I'm sure there are more
sophisticated solutions that could be implemented within the current
infrastructure, but firewalld naturally came up as it allows us to handle
both ipv4 and ipv6 via a single entity.
- As many of the services are already statically provided by either
firewalld or 3rd party packages, we'll be able to merely pass names of
services instead of complete rule sets.
- el7 is shipped with and makes use of firewalld by default.
What is the role of the central management in this regard?
I'd like its role to be as insignificant as possible.
-- Does it need to manage firewalls per host in detail? (are we
acting as
a firewall management system?)
No. Ansible was recently brought up as a solution/replacement to custom
rules/service deployment, and other than that, there is no justification to
having central management. The hosts have the required information to
determine which services/rules should be enabled on them (via either vdsm
or otopi)
-- Does it need to apply a firewall template configuration to all the
hosts? (all being identical)
-- Does it need to specify what services it wants the host to run and
mention if the whole setup should be harden or not?
If we do decide to keep Engine's involvement, it should be as minimal as
possible. Names of required services should be provided and that's it, in
my opinion (and even that sounds wasteful).
As far as I know, firewalld and iptables can co-exist, therefore, I
do
not see the need to 'upgrade' or perform a hard replacement.
It can be done as an option (firewall-type: iptables/firewalld).
On upgrade it continues with the 'old' definition and on new created host
the default can be firewalld.
Is someone will explicitly want to change it from one to the other,
we
could go with remove/add approach to make things simpler.
firewalld doesn't play well with iptables' service. Enabling firewalld
disables iptables' service and flushes its rules.
I personally like the distributed approach, where the upper
management
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels
do the explicit work and figure out what they need to do.
If that was the original approach, Engine would have not 'care' what type
of firewall you use down at the host, you could even use a custom firewall,
an NFV firewall solution
or anything that may pop up in the future.
Engine would have just said: I want libvirt, vdsm, ssh, etc... services
opened (for
access from ...).
Custom settings? That implies we manage firewalls. So either let the
user
add their special stuff on the hosts or provide them with a proper firewall
management interface.
Agreed. I'll go even further and write that Engine shouldn't even state the
services hosts require; a host should be self aware of the services it
needs to use based on the relevant configuration (e.g. if gluster is
supported in the cluster, enable gluster service)
On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>
> I may be too naive, but it all sounds too complex to me.
> Is there any reference to the use cases of the firewall configuration?
>
> Few questions:
> - Why do we need to use firewalld?
> - What is the role of the central management in this regard?
-- Does it need to manage firewalls per host in detail? (are we
acting as
> a firewall management system?)
-- Does it need to apply a firewall template configuration to all the
> hosts? (all being identical)
-- Does it need to specify what services it wants the host to run and
> mention if the whole setup should be harden or not?
>
> As far as I know, firewalld and iptables can co-exist, therefore, I do not
> see the need to 'upgrade' or perform a hard replacement.
It can be done as an option (firewall-type: iptables/firewalld).
On upgrade it continues with the 'old' definition and on new created host
> the default can be firewalld.
Is someone will explicitly want to change it from one to the other,
we
> could go with remove/add approach to make things simpler.
>
I personally like the distributed approach, where the upper
management
> layer passes what it wants to the lower layers with minimum
information.
> Letting the lower levels
do the explicit work and figure out what they need to do.
If that was the original approach, Engine would have not 'care' what type
> of firewall you use down at the host, you could even use a custom firewall,
> an NFV firewall solution
or anything that may pop up in the future.
Engine would have just said: I want libvirt, vdsm, ssh, etc... services
> opened
(for access from ...).
Custom settings? That implies we manage firewalls. So either let the
user
> add their special stuff on the hosts or provide them with a proper
firewall
> management interface.
>
> Thanks,
> Edy.
>
>
> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
>
>> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali <oourfali(a)redhat.com>
>> wrote:
>> >
>> >
>> > On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> >>
>> >> Hey Oved,
>> >>
>> >> I don't think completely moving away from iptables is foreseeable
at
>> this
>> >> point, but I could be of course wrong. Either way, upgrading still
>> needs to
>> >> be thought of.
>> >>
>> >
>> > I see.
>> >
>> >>
>> >> By stating that the current infrastructure is complex, I was referring
>> to
>> >> the entire chain of storing rules in the database, fetching them using
>> a
>> >> dedicated deployment class consisting of include/exclude logic,
>> sending them
>> >> over, unpacking, deploying...
>> >>
>> >> This procedure involves a lot of code that could be made redundant if
>> the
>> >> required logic is present in the host, which to me seems favorable. It
>> of
>> >> course entails other potential difficulties, primarily in the form of
>> custom
>> >> services.
>> >>
>> >> I don't think otopi's firewalld plugin is any more complex than
the
>> >> potential code that will have to be written in vdsm-tool, however it
>> >> currently expects the data generated by aforementioned chain. The
>> hybrid
>> >> approach briefly touches on simplifying Engine's involvement while
>> retaining
>> >> use of otopi's plugin.
>> >>
>> >
>> > Okay. I think that writing a new plugin for firewalld is indeed a good
>> > option, whether you "refactor" the engine side or not.
>>
>> otopi already has a 'firewalld' plugin. It's already in use, at
least
>> by engine-setup, so we should be a bit careful if we want to change it.
>> Not preventing/objecting anything, just mentioning.
>>
>> This plugin's interface currently only takes XML-content as input.
>> It has no place for configuring existing firewalld services presumably
>> already provided elsewhere (by firewalld itself or 3rd party packages,
>> such as vdsm). So if we go that route we probably want to extend this
>> interface to allow passing service names and rely on them being defined
>> elsewhere.
>>
>> A related issue is that for engine-setup, the _input_ is currently
>> firewalld xml content, and if users choose to configure 'iptables',
>> this is parsed to generate iptables rules. This is currently an
>> engine-setup
>> issue only, but will affect also host deploy flow if we decided to
>> allow passing service names (without their xml content) and still keep
>> compatibility to current state and allow configuring iptables on the
>> host. We'll then be there in the same situation we are at with
>> engine-setup.
>> See also https://bugzilla.redhat.com/1432354 . An alternative is
>> obviously
>> deciding to remove iptables support and support only firewalld, but this
>> is a rather radical change for users, imo.
>>
>> See also this for some of the existing behavior of engine-setup:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1024707#c9
>>
>> IMO we first need to decide what we want, then how to do that. IMO the
>> questions we have re "what we want" are, more-or-less:
>>
>> 1. Do we want to support in some version X both iptables and firewalld, or
>> is it ok to stop support for iptables and support only firewalld without
>> overlap? If so, do we handle upgrades, and how?
>>
>> 2. Do we want to support custom firewalld xml to be configured on the
>> host by us? Or is it ok to only support choosing among existing services,
>> which will need to be added to the host using other means (packaged by
>> firewalld, packaged by 3rd parties, added manually by users)?
>>
>> 3. Opposite of (2.): Do we want to support firewalld services that are
>> added to the host using other means (see there)? Obviously we do, but:
>> If we do, do we still want to support also iptables (see (1.))? And if
>> so, what do we want to then happen?
>>
>> (2.) and (3.) are not conflicting, each needs its own answer.
>>
>> My (thoughts about) answers:
>>
>> 1. If done well enough, and considerably simplifies things, I think it's
>> ok to jump directly from "only iptables" to "only firewalld",
but then
>> we should announce this ahead of time to give users time to plan/prepare.
>> If it's not too costly, I'd prefer to support both for the foreseeable
>> future, though.
>>
>> 2. Latter option here is problematic, if we need/want to allow
>> customizing services during deploy. E.g. suppose that one day we want
>> to make the vdsm port configurable. It will be nice if this can be done
>> by only changing things on the engine, without having to distribute
>> changes (conf and/or packages) to all hosts before host-deploy.
>> I'd say we can go a long way here by having a strict requirement from
>> all services that we need/want on hosts to have official IANA-registered
>> port numbers - then, it's imo much easier to tell users "If you want to
>> change the port for service X, you have to (long list of complex actions
>> goes here)". Currently, where services are not registered, we risk
>> conflicts with existing services, requiring the user to change ports -
>> and so we can't make this process too difficult. No idea how important
>> this is in practice.
>>
>> 3. Not sure :-( I'd say that if we want to support both iptables and
>> firewalld together, and support both "xml in engine" and "xml in
host",
>> then it might be ok if the custom rules/services will not automatically
>> apply to both iptables and firewalld. Meaning - you can set both custom
>> iptables rules and firewalld services, but it's up to you to make sure
>> they actually do the same thing if that's important to you.
>>
>> Bottom line: I think we should summarize the open questions in a way
>> that will make it clear to users how each answer will affect them, and
>> ask what they think. Leon already started doing this [1], I only saw
>> one reply. Perhaps this means that users do not care that much, and
>> expect us to just decide and tell them what we decided (and always to
>> keep the option to disable this feature, as is possible today, and do
>> this themselves, if our choice of solution does not fit their needs).
>>
>> I know this is way too loooong, sorry. Feel free to ignore, but then
>> please ask simpler questions if you want shorter answers :-)
>>
>> [1] http://lists.ovirt.org/pipermail/users/2017-March/080600.html
>>
>> >
>> >>
>> >>
>> >>
>> >> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali
<oourfali(a)redhat.com>
>> wrote:
>> >>>
>> >>> top-posting:
>> >>> You need to also consider how upgrade will be handled, right?
>> >>> Or iptables will still remain supported?
>> >>>
>> >>> Also, see some comments inline.
>> >>>
>> >>> Regards,
>> >>> Oved
>> >>>
>> >>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >>> wrote:
>> >>>>
>> >>>>
>> >>>> Hey,
>> >>>>
>> >>>> We're looking to migrate from iptables to firewalld. We came
up with
>> a
>> >>>> couple of possible approaches we'd like opinions on.
I'll list the
>> options
>> >>>> first, and will
>> >>>>
>> >>>> 1) Replicate existing flow:
>> >>>>
>> >>>> As of date, iptable rules are inserted in the database via SQL
config
>> >>>> files. During host deployment, VdsDeployIptablesUnit adds the
>> required rules
>> >>>> (based on cluster/firewall configuration) to the deployment
>> configuration,
>> >>>> en route to being deployed on the host via otopi and its
iptables
>> plugin.
>> >>>>
>> >>>> Pros:
>> >>>>
>> >>>> - Reuse of existing infrastructure.
>> >>>>
>> >>>> Cons:
>> >>>>
>> >>>> - Current infrastructure is overly complex...
>> >>>
>> >>>
>> >>> Can you elaborate?
>> >>> I'm not an otopi expert, but I think that otopi plugins
shouldn't be
>> more
>> >>> complex than what you describe in section #2, and the plugins were
>> meant in
>> >>> order to handle such cases.
>> >>>
>> >>>> - Many of the required services are provided by firewalld.
Rewriting
>> >>>> them is wasteful; specifying them (instead of providing actual
>> service .xml
>> >>>> content) will require adaptations on both (engine/host) sides.
More
>> on that
>> >>>> later.
>> >>>>
>> >>>>
>> >>>> 2) Host side based configuration:
>> >>>>
>> >>>> Essentially, all the required logic (aforementioned
cluster/firewall
>> >>>> configuration) to determine if/how firewalld should be deployed
>> could be
>> >>>> passed on to the host via ohd. Vdsm could take on the
responsibility
>> of
>> >>>> examining the relevant configuration, and then creating and/or
>> adding the
>> >>>> required services (using vdsm.conf and vdsm-tool).
>> >>>>
>> >>>
>> >>> So here you replace the otopi plugin with relevant vdsm-tool code,
and
>> >>> the question is why is that better?
>> >>>
>> >>>>
>> >>>> Pros:
>> >>>>
>> >>>> - Engine side involvement is greatly diminished.
>> >>>> - Simple(r).
>> >>>>
>> >>>> Cons:
>> >>>>
>> >>>> - Custom services/rules capabilities will have to be rethought
and
>> >>>> re-implemented (current infrastructure supports custom iptables
>> rules by
>> >>>> being specified in the SQL config file).
>> >>>>
>> >>>>
>> >>>> 3) Some other hybrid approach:
>> >>>>
>> >>>> If we're able to guarantee all the required firewalld
services are
>> >>>> statically provided one way or the other, the current procedure
>> could be
>> >>>> replicated and be made more simpler. Instead of providing xml
>> content in the
>> >>>> form of strings, service names could be supplied. The
responsibility
>> of
>> >>>> actual service deployment becomes easier, and could be left to
otopi
>> (with
>> >>>> the appropriate modifications) or switched over to vdsm.
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Regardless, usage of statically provided vs. dynamically
created
>> >>>> services remains an open question. I think we'd like to
avoid
>> implementing
>> >>>> logic that ask whether some service is provided (and then write
it
>> if it
>> >>>> isn't...), and so choosing between the dynamic and static
approaches
>> is also
>> >>>> needed. Using the static approach, guaranteeing all services
are
>> provided
>> >>>> will be required.
>> >>>>
>> >>>> I do believe guaranteeing the presence of all required services
is
>> worth
>> >>>> it, however custom services aren't going to be naively
compatible,
>> and we'll
>> >>>> still have to use similar mechanism as described in #1 (service
>> string ->
>> >>>> .xml -> addition of service name to active zone).
>> >>>>
>> >>>>
>> >>>> Your thoughts are welcome.
>> >>>>
>> >>>> Thanks,
>> >>>> Leon
>> >>>>
>> >>>
>> >>
>> >
>>
>>
>>
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
9:16 a.m.
You're right, but I don't think it matters; hosts will remain unaffected
until they're reinstalled via an upgraded Engine.
Clients should be made aware their custom rules are going to be obsolete
and that they should reapply them once they reinstall.
On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
wrote:
> Effectively, upgrading will leave lingering (but nonetheless operational)
> iptables rules on the hosts. I'm not even sure there needs to be special
> upgrade treatment?
Please describe the expected flow.
Please note that at least when I tried, 'systemctl start firewalld' stops
iptables.
Thanks,
>
> On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>>
>> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > 1) Do we actually need iptables for any reason that isn't a legacy
>> > consideration?
>>
>> No idea personally.
>>
>> Perhaps some users prefer that, and/or need that for integration with
>> other
>> systems/solutions/whatever.
>>
>> If we drop iptables, how do you suggest to treat upgrades?
>>
>> >
>> > 2 & 3) I am in favor of treating custom services as a requirement and
>> > plan
>> > accordingly. Many (most, even) of the services are already provided by
>> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party packages
>> > (e.g.
>> > gluster). Some are missing (I've recently created a pull request for
>> > ovirt-imageio to firewalld, for example) and I hope we'll be able to
get
>> > all
>> > the services to be statically provided (by either firewalld or the
>> > relevant
>> > 3rd party packages).
>> >
>> > Ideally I think we'd like use statically provided services, and
provide
>> > the
>> > capability to provide additional services (I'm not a fan of the
current
>> > methodology of converting strings into xmls). I don't think we'd
want
to
>> > limit usage to just statically provided services. (2)
>> >
>> > As previously stated, I don't see a technical reason to keep iptables
>> > under
>> > consideration. (3)
>> >
>> >
>> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
<didi(a)redhat.com>
>> > wrote:
>> >>
>> >>
>> >> 1. Do we want to support in some version X both iptables and
firewalld,
>> >> or
>> >> is it ok to stop support for iptables and support only firewalld
>> >> without
>> >> overlap? If so, do we handle upgrades, and how?
>> >>
>> >> 2. Do we want to support custom firewalld xml to be configured on the
>> >> host by us? Or is it ok to only support choosing among existing
>> >> services,
>> >> which will need to be added to the host using other means (packaged
by
>> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >>
>> >> 3. Opposite of (2.): Do we want to support firewalld services that
are
>> >> added to the host using other means (see there)? Obviously we do,
but:
>> >> If we do, do we still want to support also iptables (see (1.))? And
if
>> >> so, what do we want to then happen?
>> >>
>> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>
--
Didi
10:11 a.m.
--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
><br ><br >
On Sun, Mar 26, 2017 at 2:08 PM, Leon Goldberg <<a href=3D"mailto:lg=
oldber(a)redhat.com"
target=3D"_blank">lgoldber(a)redhat.com</a>&gt; wrote:<br >><br
>> Hey Oved,<br
>><br >> I don't think
completely moving away from iptables is foreseeable a=
t this<br >> point, but I could
be of course wrong. Either way, upgrading still n=
eeds to<br >> be thought
of.<br >><br ><br >
I see.<br ><br >><br
>> By stating that the current infrastructure is complex, I was
referr=
ing to<br >> the entire chain of
storing rules in the database, fetching them us=
ing a<br >> dedicated
deployment class consisting of include/exclude logic, sen=
ding them<br >> over, unpacking,
deploying...<br >><br >> This procedure involves a lot of code that
could be made redundant i=
f the<br >> required logic is
present in the host, which to me seems favorable.=
It of<br >> course entails
other potential difficulties, primarily in the form o=
f custom<br >> services.<br >><br
>> I don't think otopi's firewalld plugin is any more complex
than the=
<br >> potential code that will have to be written in
vdsm-tool, however i=
t<br >> currently expects the data generated by
aforementioned chain. The h=
ybrid<br >> approach briefly
touches on simplifying Engine's involvement while r=
etaining<br >> use of otopi's
plugin.<br >><br ><br >
Okay. I think that writing a new plugin for firewalld is indeed a good<=
br > option, whether you "refactor" the engine
side or not.<br <br
</span>otopi already has a 'firewalld' plugin. It's already in
use, at least=
<br by engine-setup, so we should be a bit careful if we want to
change it.<br Not preventing/objecting anything,
just mentioning.<br <br This
plugin's interface currently only takes XML-content as input.<br It has no place for configuring existing firewalld services
presumably<br already provided elsewhere (by
firewalld itself or 3rd party packages,<br such as
vdsm). So if we go that route we probably want to extend this<br interface to allow passing service names and rely on them being
defined<br elsewhere.<br <br A related issue is that for
engine-setup, the _input_ is currently<br firewalld
xml content, and if users choose to configure 'iptables',<br this is parsed to generate iptables rules. This is currently an
engine-setup=
<br issue only, but will affect also host deploy flow if we decided
to<br allow passing service names (without
their xml content) and still keep<br
compatibility to current state and allow configuring iptables on the<br host. We'll then be there in the same situation we are at
with engine-setup.=
<br See also <a
href=3D"https://bugzilla.redhat.com/1432354" rel=3D"noreferrer" t=
arget=3D"_blank">https://bugzilla.redhat.com/14<wbr>32... .
An alternati=
ve is obviously<br deciding to remove iptables support
and support only firewalld, but this<br>=
is a rather radical change for users, imo.<br
<br See also this for some of the
existing behavior of engine-setup:<br
<br <a
href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1024707#c9" rel=3D"=
noreferrer"
target=3D"_blank">https://bugzilla.redhat.com/sh<wbr>o...
id=3D1024707#c9</a><br <br IMO we
first need to decide what we want, then how to do that. IMO the<br questions we have re "what we want" are,
more-or-less:<br <br 1. Do we
want to support in some version X both iptables and firewalld, or<b=
r is it ok to stop support for iptables and support only
firewalld 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 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 My (thoughts about)
answers:<br <br 1. If
done well enough, and considerably simplifies things, I think it's<br>=
ok to jump directly from "only iptables" to "only firewalld", but
then<br we should announce this ahead of
time to give users time to plan/prepare.<br=
If it's not too costly, I'd prefer to support both for
the foreseeable<br future, though.<br <br 2. Latter option here is
problematic, if we need/want to allow<br
customizing services during deploy. E.g. suppose that one day we want<br to make the vdsm port configurable. It will be nice if this can
be done<br by only changing things on the
engine, without having to distribute<br changes
(conf and/or packages) to all hosts before host-deploy.<br I'd
say we can go a long way here by having a strict requirement from<br all services that we need/want on hosts to have official
IANA-registered<br>=
port numbers - then, it's imo much easier to tell users "If you want to<br change the port for service X, you have to (long list of
complex actions<br>=
goes here)". Currently, where services are not registered, we risk<br conflicts with existing services, requiring the user to change
ports -<br and so we can't make this
process too difficult. No idea how important<br this is
in practice.<br <br 3. Not
sure :-( I'd say that if we want to support both iptables and<br firewalld together, and support both "xml in engine"
and "xml in host",<br then it might be ok if the custom
rules/services will not automatically<br apply to
both iptables and firewalld. Meaning - you can set both custom<br iptables rules and firewalld services, but it's up to you
to make sure<br they actually do the same thing if
that's important to you.<br <br Bottom
line: I think we should summarize the open questions in a way<br that will make it clear to users how each answer will affect
them, and<br ask what they think. Leon already
started doing this [1], I only saw<br one
reply. Perhaps this means that users do not care that much, and<br expect us to just decide and tell them what we decided (and
always to<br keep the option to disable this
feature, as is possible today, and do<br this
themselves, if our choice of solution does not fit their needs).<br <br I know this is way too loooong,
sorry. Feel free to ignore, but then<br please
ask simpler questions if you want shorter answers :-)<br
<br [1] <a
href=3D"http://lists.ovirt.org/pipermail/users/2017-March/080600.html=
" rel=3D"noreferrer"
target=3D"_blank">http://lists.ovirt.org/piperma<wbr>il=
/users/2017-March/080600.<wbr>html</a><br <div
class=3D"m_7457438430304499453HOEnZb"><div
class=3D"m_74574384303044994=
53h5"><br ><br >><br
>><br >><br >> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali
<<a href=3D"mailto=
:oourfali@redhat.com"
target=3D"_blank">oourfali(a)redhat.com</a>&gt; wrote:<b=
r >>><br
>>> top-posting:<br
>>> You need to also consider how upgrade will be handled,
right?<b=
r >>> Or iptables will still remain
supported?<br >>><br >>> Also, see some comments
inline.<br >>><br >>> Regards,<br >>> Oved<br >>><br
>>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg
<<a href=3D"m=
ailto:lgoldber@redhat.com"
target=3D"_blank">lgoldber(a)redhat.com</a>&gt;<br>=
>>> wrote:<br
>>>><br
>>>><br
>>>> Hey,<br
>>>><br
>>>> We're looking to migrate from iptables to
firewalld. We cam=
e up with a<br >>>>
couple of possible approaches we'd like opinions on. I'll l=
ist the options<br >>>>
first, and will<br
>>>><br
>>>> 1) Replicate existing flow:<br >>>><br >>>> As of date, iptable rules are
inserted in the database via S=
QL config<br >>>>
files. During host deployment, VdsDeployIptablesUnit adds t=
he required rules<br >>>>
(based on cluster/firewall configuration) to the deployment=
configuration,<br >>>> en
route to being deployed on the host via otopi and its ip=
tables plugin.<br
>>>><br
>>>> Pros:<br
>>>><br
>>>> - Reuse of existing infrastructure.<br >>>><br >>>> Cons:<br >>>><br >>>> - Current infrastructure is
overly complex...<br >>><br >>><br
>>> Can you elaborate?<br
>>> I'm not an otopi expert, but I think that otopi plugins
shouldn=
't be more<br >>> complex
than what you describe in section #2, and the plugins w=
ere meant in<br >>> order to
handle such cases.<br >>><br >>>> - Many of the required
services are provided by firewalld. R=
ewriting<br >>>>
them is wasteful; specifying them (instead of providing act=
ual service .xml<br >>>>
content) will require adaptations on both (engine/host) sid=
es. More on that<br >>>>
later.<br
>>>><br
>>>><br
>>>> 2) Host side based configuration:<br >>>><br >>>> Essentially, all the required
logic (aforementioned cluster=
/firewall<br >>>>
configuration) to determine if/how firewalld should be depl=
oyed could be<br >>>>
passed on to the host via ohd. Vdsm could take on the respo=
nsibility of<br >>>>
examining the relevant configuration, and then creating and=
/or adding the<br >>>>
required services (using vdsm.conf and vdsm-tool).<br
>>>><br
>>><br
>>> So here you replace the otopi plugin with relevant
vdsm-tool co=
de, and<br >>> the
question is why is that better?<br
>>><br
>>>><br
>>>> Pros:<br
>>>><br
>>>> - Engine side involvement is greatly
diminished.<br
>>>> - Simple(r).<br >>>><br >>>> Cons:<br >>>><br >>>> - Custom
services/rules capabilities will have to be r=
ethought and<br >>>>
re-implemented (current infrastructure supports custom ipta=
bles rules by<br >>>>
being specified in the SQL config file).<br
>>>><br
>>>><br
>>>> 3) Some other hybrid approach:<br >>>><br >>>> If we're able to guarantee
all the required firewalld servi=
ces are<br >>>>
statically provided one way or the other, the current proce=
dure could be<br >>>>
replicated and be made more simpler. Instead of providing x=
ml content in the<br >>>>
form of strings, service names could be supplied. The respo=
nsibility of<br >>>>
actual service deployment becomes easier, and could be left=
to otopi (with<br >>>> the
appropriate modifications) or switched over to vdsm.<br=
>>>><br >>>> --<br >>>><br >>>> Regardless, usage of
statically provided vs. dynamically cr=
eated<br >>>>
services remains an open question. I think we'd like to avo=
id implementing<br >>>>
logic that ask whether some service is provided (and then w=
rite it if it<br >>>>
isn't...), and so choosing between the dynamic and static a=
pproaches is also<br >>>>
needed. Using the static approach, guaranteeing all service=
s are provided<br >>>>
will be required.<br
>>>><br
>>>> I do believe guaranteeing the presence of all
required serv=
ices is worth<br >>>> it,
however custom services aren't going to be naively comp=
atible, and we'll<br >>>>
still have to use similar mechanism as described in #1 (ser=
vice string -><br >>>>
.xml -> addition of service name to active zone).<br >>>><br >>>><br >>>> Your thoughts are
welcome.<br
>>>><br
>>>> Thanks,<br
>>>> Leon<br
>>>><br
>>><br
>><br ><br <br <br
<br
</div></div></div></div><span
class=3D"HOEnZb"><font color=3D"#888888"><span=
class=3D"m_7457438430304499453HOEnZb"><font
color=3D"#888888">--<br
Didi<br
______________________________<wbr>_________________<br Devel mailing list<br <a
href=3D"mailto:Devel@ovirt.org"
target=3D"_blank">Devel(a)ovirt.org</a><br>=
<a href=3D"http://lists.ovirt.org/mailman/listinfo/devel"
rel=3D"noreferrer"=
target=3D"_blank">http://lists.ovirt.org/mailman<wbr>/...
</font></span></font></span></blockquote></div><br></div
<br>______________________________<wbr>_________________<br Devel mailing list<br <a
href=3D"mailto:Devel@ovirt.org">Devel@ovirt.org</a><br <a
href=3D"http://lists.ovirt.org/mailman/listinfo/devel"
rel=3D"noreferrer"=
target=3D"_blank">http://lists.ovirt.org/<wbr>mailman/...
></blockquote></div><br></div
</div></blockquote></div></body></html>=
--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37--
On 27 Mar 2017, at 17:05, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
=20
> Why do we need to use firewalld?
I think that the initial trigger was the realization we're completely lack=
ing
ipv6 handling (which requires use of another, similar tool in ip6tables)=
in the current infrastructure.=20
=20
Assessing the situation and reviewing the code for potential solutions led=
us to
a couple of conclusions:
=20
- Current flow is overly complex and should be reexamined regardless.
- The naive solution would be to duplicate the current flow for ip6tables,=
potentially leading to a lot of boilerplate code. I'm sure there are more s=
ophisticated solutions that could be implemented within the current infrastr=
ucture, but firewalld naturally came up as it allows us to handle both ipv4 a=
nd ipv6 via a single entity.
- As many of the services are already statically provided by either
firewa=
lld or 3rd party packages, we'll be able to merely pass names of
services in=
stead of complete rule sets.
- el7 is shipped with and makes use of firewalld by default.
=20
> What is the role of the central management in this regard?
I'd like its role to be as insignificant as possible.
=20
> -- Does it need to manage firewalls per host in detail? (are we acting a=
s a
firewall management system?)
No. Ansible was recently brought up as a solution/replacement to
custom r=
ules/service deployment, and other than that, there is no justification
to h=
aving central management. The hosts have the required information to determi=
ne which services/rules should be enabled on them (via either vdsm or otopi)=
=20
> -- Does it need to apply a firewall template configuration to all the ho=
sts?
(all being identical)
> -- Does it need to specify what services it wants the host to
run and me=
ntion if the whole setup should be harden or not?
If we do decide to keep Engine's involvement, it should be as
minimal as p=
ossible. Names of required services should be provided and that's
it, in my o=
pinion (and even that sounds wasteful).
=20
> As far as I know, firewalld and iptables can co-exist, therefore, I do n=
ot
see the need to 'upgrade' or perform a hard replacement.
> It can be done as an option (firewall-type:
iptables/firewalld).
> On upgrade it continues with the 'old' definition and on new created hos=
t the default can be firewalld.
> Is someone will explicitly want to change it from one to the
other, we c=
ould go with remove/add approach to make things simpler.
firewalld doesn't play well with iptables' service. Enabling
firewalld dis=
ables iptables' service and flushes its rules.=20
Understood, good to know.
But still, this approach will work fine, we do the same with linux/ovs bridg=
e options. Add an option to choose the firewall type. Support both at phase=
1, allowing to change the type and at phase 2 deprecate the iptables type.
=20
> I personally like the distributed approach, where the upper management l=
ayer
passes what it wants to the lower layers with minimum information. Lett=
ing the lower levels
> do the explicit work and figure out what they need to do.
> If that was the original approach, Engine would have not 'care' what typ=
e of firewall you use down at the host, you could even use a custom firewall=
, an NFV firewall solution
> or anything that may pop up in the future.
> Engine would have just said: I want libvirt, vdsm, ssh, etc... services o=
pened (for access from ...).
> Custom settings? That implies we manage firewalls. So either let
the use=
r add their special stuff on the hosts or provide them with a proper
firewal=
l management interface.
Agreed. I'll go even further and write that Engine shouldn't
even state th=
e services hosts require; a host should be self aware of the services
it nee=
ds to use based on the relevant configuration (e.g. if gluster is supported i=
n the cluster, enable gluster service)
=20
> On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>=20
> I may be too naive, but it all sounds too complex to me.
> Is there any reference to the use cases of the firewall configuration?
>=20
> Few questions:
> - Why do we need to use firewalld?
> - What is the role of the central management in this regard?
> -- Does it need to manage firewalls per host in detail? (are we acting as=
a
firewall management system?)
> -- Does it need to apply a firewall template configuration to all
the hos=
ts? (all being identical)
> -- Does it need to specify what services it wants the host to run
and men=
tion if the whole setup should be harden or not?
>=20
> As far as I know, firewalld and iptables can co-exist, therefore, I do no=
t
see the need to 'upgrade' or perform a hard replacement.
> It can be done as an option (firewall-type: iptables/firewalld).
> On upgrade it continues with the 'old' definition and on new created host=
the default can be firewalld.
> Is someone will explicitly want to change it from one to the
other, we co=
uld go with remove/add approach to make things simpler.
>=20
> I personally like the distributed approach, where the upper management la=
yer
passes what it wants to the lower layers with minimum information. Letti=
ng the lower levels
> do the explicit work and figure out what they need to do.
> If that was the original approach, Engine would have not 'care' what type=
of firewall you use down at the host, you could even use a custom firewall,=
an NFV firewall solution
> or anything that may pop up in the future.
> Engine would have just said: I want libvirt, vdsm, ssh, etc... services o=
pened (for access from ...).
> Custom settings? That implies we manage firewalls. So either let
the user=
add their special stuff on the hosts or provide them with a proper
firewall=
management interface.
>=20
> Thanks,
> Edy.
>=20
>=20
>> On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <didi(a)redhat.com> wr=
ote:
>> On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali
<oourfali(a)redhat.com> wrot=
e:
rote:
>> > >> >> Hey Oved,
>> > >> >> I don't think
completely moving away from iptables is foreseeable at t=
his
>> >> point, but I could be of course wrong. Either way,
upgrading still ne=
eds to
>> >> be thought of.
>> > >> >> > I see.
>> >> > >> >> By stating that the current infrastructure is
complex, I was referrin=
g to
>> >> the entire chain of storing rules in the database,
fetching them usin=
g a
>> >> dedicated deployment class consisting of
include/exclude logic, sendi=
ng them
>> >> over, unpacking, deploying...
>> > >> >> This procedure
involves a lot of code that could be made redundant if=
the
>> >> required logic is present in the host, which to me
seems favorable. I=
t of
>> >> course entails other potential difficulties,
primarily in the form of=
custom
>> >> services.
>> > >> >> I don't think
otopi's firewalld plugin is any more complex than the
>> >> potential code that will have to be written in vdsm-tool, however it
>> >> currently expects the data generated by aforementioned chain. The hyb=
rid
>> >> approach briefly touches on simplifying Engine's
involvement while re=
taining
>> >> use of otopi's plugin.
>> > >> >> > Okay. I think that writing a new plugin for
firewalld is indeed a good=
>> > option, whether you "refactor" the engine side
or not.
>>=20
>> otopi already has a 'firewalld' plugin. It's already in use, at
least
>> by engine-setup, so we should be a bit careful if we want to change it.
>> Not preventing/objecting anything, just mentioning.
>>=20
>> This plugin's interface currently only takes XML-content as input.
>> It has no place for configuring existing firewalld services presumably
>> already provided elsewhere (by firewalld itself or 3rd party packages,
>> such as vdsm). So if we go that route we probably want to extend this
>> interface to allow passing service names and rely on them being defined
>> elsewhere.
>>=20
>> A related issue is that for engine-setup, the _input_ is currently
>> firewalld xml content, and if users choose to configure 'iptables',
>> this is parsed to generate iptables rules. This is currently an engine-s=
etup
>> issue only, but will affect also host deploy flow if we
decided to
>> allow passing service names (without their xml content) and still keep
>> compatibility to current state and allow configuring iptables on the
>> host. We'll then be there in the same situation we are at with engine-se=
tup.
>> See also https://bugzilla.redhat.com/1432354 . An alternative
is obvious=
ly
>> deciding to remove iptables support and support only
firewalld, but this=
>> is a rather radical change for users, imo.
>>=20
>> See also this for some of the existing behavior of engine-setup:
>>=20
>> https://bugzilla.redhat.com/show_bug.cgi?id=3D1024707#c9
>>=20
>> IMO we first need to decide what we want, then how to do that. IMO the
>> questions we have re "what we want" are, more-or-less:
>>=20
>> 1. Do we want to support in some version X both iptables and firewalld, o=
r
>> is it ok to stop support for iptables and support only
firewalld without=
>> overlap? If so, do we handle upgrades, and how?
>>=20
>> 2. Do we want to support custom firewalld xml to be configured on the
>> host by us? Or is it ok to only support choosing among existing services=
,
>> which will need to be added to the host using other means
(packaged by
>> firewalld, packaged by 3rd parties, added manually by users)?
>>=20
>> 3. Opposite of (2.): Do we want to support firewalld services that are
>> added to the host using other means (see there)? Obviously we do, but:
>> If we do, do we still want to support also iptables (see (1.))? And if
>> so, what do we want to then happen?
>>=20
>> (2.) and (3.) are not conflicting, each needs its own answer.
>>=20
>> My (thoughts about) answers:
>>=20
>> 1. If done well enough, and considerably simplifies things, I think it's=
>> ok to jump directly from "only iptables" to
"only firewalld", but then
>> we should announce this ahead of time to give users time to plan/prepare=
.
>> If it's not too costly, I'd prefer to support both
for the foreseeable
>> future, though.
>>=20
>> 2. Latter option here is problematic, if we need/want to allow
>> customizing services during deploy. E.g. suppose that one day we want
>> to make the vdsm port configurable. It will be nice if this can be done
>> by only changing things on the engine, without having to distribute
>> changes (conf and/or packages) to all hosts before host-deploy.
>> I'd say we can go a long way here by having a strict requirement from
>> all services that we need/want on hosts to have official IANA-registered=
>> port numbers - then, it's imo much easier to tell users
"If you want to
>> change the port for service X, you have to (long list of complex actions=
>> goes here)". Currently, where services are not
registered, we risk
>> conflicts with existing services, requiring the user to change ports -
>> and so we can't make this process too difficult. No idea how important
>> this is in practice.
>>=20
>> 3. Not sure :-( I'd say that if we want to support both iptables and
>> firewalld together, and support both "xml in engine" and "xml in
host",
>> then it might be ok if the custom rules/services will not automatically
>> apply to both iptables and firewalld. Meaning - you can set both custom
>> iptables rules and firewalld services, but it's up to you to make sure
>> they actually do the same thing if that's important to you.
>>=20
>> Bottom line: I think we should summarize the open questions in a way
>> that will make it clear to users how each answer will affect them, and
>> ask what they think. Leon already started doing this [1], I only saw
>> one reply. Perhaps this means that users do not care that much, and
>> expect us to just decide and tell them what we decided (and always to
>> keep the option to disable this feature, as is possible today, and do
>> this themselves, if our choice of solution does not fit their needs).
>>=20
>> I know this is way too loooong, sorry. Feel free to ignore, but then
>> please ask simpler questions if you want shorter answers :-)
>>=20
>> [1] http://lists.ovirt.org/pipermail/users/2017-March/080600.html
>>=20
>> >> > >> > >>
> >> >> On Sun, Mar 26, 2017 at 1:40 PM, Oved Ourfali
<oourfali(a)redhat.com> w=
rote:
>> >> >>
>>> top-posting:
>> >>> You need to also consider how upgrade will be handled, right?
>> >>> Or iptables will still remain supported?
>> >> >> >>> Also, see some
comments inline.
>> >> >> >>> Regards,
>> >>> Oved
>> >> >> >>> On Sun, Mar
26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>=
>> >>> wrote:
>> >>> >> >>> >> >>>> Hey,
>> >>> >> >>>> We're
looking to migrate from iptables to firewalld. We came up wit=
h a
>> >>>> couple of possible approaches we'd like
opinions on. I'll list the o=
ptions
>> >>>> first, and will
>> >>> >> >>>> 1)
Replicate existing flow:
>> >>> >> >>>> As of
date, iptable rules are inserted in the database via SQL conf=
ig
>> >>>> files. During host deployment,
VdsDeployIptablesUnit adds the requi=
red rules
>> >>>> (based on cluster/firewall configuration) to
the deployment configu=
ration,
>> >>>> en route to being deployed on the host via
otopi and its iptables p=
lugin.
>> >>> >>
>>>> Pros:
>> >>> >> >>>> - Reuse of
existing infrastructure.
>> >>> >> >>>> Cons:
>> >>> >> >>>> - Current
infrastructure is overly complex...
>> >> >> >> >> >>> Can you elaborate?
>> >>> I'm not an otopi expert, but I think that otopi plugins
shouldn't be=
more
>> >>> complex than what you describe in section #2,
and the plugins were m=
eant in
>> >>> order to handle such cases.
>> >> >> >>>> - Many of
the required services are provided by firewalld. Rewritin=
g
>> >>>> them is wasteful; specifying them (instead
of providing actual serv=
ice .xml
>> >>>> content) will require adaptations on both
(engine/host) sides. More=
on that
>> >>>> later.
>> >>> >> >>> >> >>>> 2) Host side based configuration:
>> >>> >> >>>>
Essentially, all the required logic (aforementioned cluster/firewal=
l
>> >>>> configuration) to determine if/how firewalld
should be deployed cou=
ld be
>> >>>> passed on to the host via ohd. Vdsm could
take on the responsibilit=
y of
>> >>>> examining the relevant configuration, and
then creating and/or addi=
ng the
>> >>>> required services (using vdsm.conf and
vdsm-tool).
>> >>> >> >> >> >>> So here you replace the otopi plugin with
relevant vdsm-tool code, a=
nd
>> >>> the question is why is that better?
>> >> >> >>> >> >>>> Pros:
>> >>> >> >>>> - Engine
side involvement is greatly diminished.
>> >>>> - Simple(r).
>> >>> >> >>>> Cons:
>> >>> >> >>>> - Custom
services/rules capabilities will have to be rethought and=
>> >>>> re-implemented (current infrastructure
supports custom iptables rul=
es by
>> >>>> being specified in the SQL config file).
>> >>> >> >>> >> >>>> 3) Some other hybrid approach:
>> >>> >> >>>> If
we're able to guarantee all the required firewalld services are
>> >>>> statically provided one way or the other, the current procedure
cou=
ld be
>> >>>> replicated and be made more simpler. Instead
of providing xml conte=
nt in the
>> >>>> form of strings, service names could be
supplied. The responsibilit=
y of
>> >>>> actual service deployment becomes easier,
and could be left to otop=
i (with
>> >>>> the appropriate modifications) or switched
over to vdsm.
>> >>> >> >>>> --
>> >>> >> >>>>
Regardless, usage of statically provided vs. dynamically created
>> >>>> services remains an open question. I think we'd like to
avoid imple=
menting
>> >>>> logic that ask whether some service is
provided (and then write it i=
f it
>> >>>> isn't...), and so choosing between the
dynamic and static approache=
s is also
>> >>>> needed. Using the static approach,
guaranteeing all services are pr=
ovided
>> >>>> will be required.
>> >>> >> >>>> I do
believe guaranteeing the presence of all required services is w=
orth
>> >>>> it, however custom services aren't going
to be naively compatible, a=
nd we'll
>> >>>> still have to use similar mechanism as
described in #1 (service str=
ing ->> >>>> .xml -> addition of service name to
active zone).
>> >>> >> >>> >> >>>> Your thoughts are welcome.
>> >>> >> >>>> Thanks,
>> >>>> Leon
>> >>> >> >> >> > >>
>>=20
>>=20
>>=20
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>=20
>=20
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
=20
--Apple-Mail-A72B9685-D24B-4ED5-AF76-C191A881AA37
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type"
content=3D"text/html; charset=3D=
utf-8"></head><body
dir=3D"auto"><div><br></div><div><br>On 27 Mar
2017, at 1=
7:05, Leon Goldberg <<a
href=3D"mailto:lgoldber@redhat.com">lgoldber@redh=
at.com</a>> wrote:<br><br></div><blockquote
type=3D"cite"><div><div dir=3D=
"ltr">> Why do we need to use firewalld?<br><span
class=3D"gmail-"></span=
<div>I
think that the initial trigger was the realization
we're completely=20
lacking ipv6 handling (which requires use of another, similar tool in=20
ip6tables) in the current infrastructure. <br><br>Assessing the situation an=
d reviewing the code for potential solutions led us to a couple of conclusio=
ns:<br><br></div><div>- Current flow is overly complex and should
be reexami=
ned regardless.<br></div><div>-
The naive solution would be to duplicate the current flow for=20
ip6tables, potentially leading to a lot of boilerplate code. I'm sure=20
there are more sophisticated solutions that could be implemented within=20
the current infrastructure, but firewalld naturally came up as it allows
us to handle both ipv4 and ipv6 via a single entity.<br></div><div>-
As
many of the services are already statically provided by either=20
firewalld or 3rd party packages, we'll be able to merely pass names of=20
services instead of complete rule sets.<br></div><div>- el7 is shipped
with a=
nd makes use of firewalld by default.<br><br></div><div><span
class=3D"gmail=
-">> What is the role of the central management in this
regard?<br></span=
I'd like its role to be as insignificant as possible.<span
class=3D"gmail-"=
<br><br>> -- Does it need to manage firewalls per host in detail? (are
w=
e acting as a firewall management
system?)<br></span></div><div>No.
Ansible was recently brought up as a solution/replacement to custom=20
rules/service deployment, and other than that, there is no justification
to having central management. The hosts have the required information=20
to determine which services/rules should be enabled on them (via either=20
vdsm or otopi)<br><br></div><span
class=3D"gmail-"><div>> -- Does it need=
to apply a firewall template configuration to all the hosts? (all being ide=
ntical)<br>> -- Does it need to specify what services it wants the host t=
o run and mention if the whole setup should be harden or
not?<br></div></spa=
n><div>If
we do decide to keep Engine's involvement, it should be as minimal as=20
possible. Names of required services should be provided and that's it,=20
in my opinion (and even that sounds wasteful).<span
class=3D"gmail-"><br><br=
> As far as I know, firewalld and=20
iptables can
co-exist, therefore, I do not see the need to 'upgrade' or=20
perform a hard replacement.<br>> It can be done as an option (firewall-ty=
pe: iptables/firewalld).<br>> On upgrade it continues with the 'old'
defi=
nition and on new created host the default can be firewalld.<br>>
Is someone will explicitly want to change it from one to the other, we=20
could go with remove/add approach to make things
simpler.<br></span></div><d=
iv>firewalld doesn't play well with iptables' service. Enabling firewalld di=
sables iptables' service and flushes its rules.
<br></div></div></div></bloc=
kquote><div><br></div>Understood, good to know.<div>But still,
this approach=
will work fine, we do the same with linux/ovs bridge options. Add an option=
to choose the firewall type. Support both at phase 1, allowing to cha=
nge the type and at phase 2 deprecate the iptables
type.</div><div><br><bloc=
kquote type=3D"cite"><div><div dir=3D"ltr"><span
class=3D"gmail-"><div><br>&=
gt; I
personally like the distributed approach, where the upper management=20
layer passes what it wants to the lower layers with minimum information.
Letting the lower levels<br>> do the explicit work and figure out what t=
hey need to do.<br>> If
that was the original approach, Engine would have not 'care' what type=20
of firewall you use down at the host, you could even use a custom=20
firewall, an NFV firewall solution<br>> or anything that may pop up in th=
e future.<br><div>> Engine would have just said: I want libvirt, vdsm,
ss=
h, etc... services opened (for access from ...).<br></div>> Custom
settings? That implies we manage firewalls. So either let the user add=20
their special stuff on the hosts or provide them with a proper firewall=20
management interface.<br></div></span>Agreed. I'll go even
further=20
and write that Engine shouldn't even state the services hosts require; a
host should be self aware of the services it needs to use based on the=20
relevant configuration (e.g. if gluster is supported in the cluster,=20
enable gluster service)</div><div
class=3D"gmail_extra"><br><div class=3D"gm=
ail_quote">On Sun, Mar 26, 2017 at 4:47 PM, Edward Haas <span
dir=3D"ltr">&l=
t;<a href=3D"mailto:ehaas@redhat.com"
target=3D"_blank">ehaas(a)redhat.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div
dir=3D"ltr"><div><di=
v><div><div><div><div><div><div><div><div><div><div><br>I
may be too naive, b=
ut it all sounds too complex to me.<br>Is there any reference to the use cas=
es of the firewall configuration?<br><br></div><div>Few
questions:<br></div>=
- Why do we need to use firewalld?<br></div>- What is the role of the centra=
l management in this regard?<br>-- Does it need to manage firewalls per host=
in detail? (are we acting as a firewall management system?)<br>-- Does it n=
eed to apply a firewall template configuration to all the hosts? (all being i=
dentical)<br></div>-- Does it need to specify what services it wants the hos=
t to run and mention if the whole setup should be harden or
not?<br><br></di=
v>As far as I know, firewalld and iptables can co-exist, therefore, I do not=
see the need to 'upgrade' or perform a hard replacement.<br></div>It
can be=
done as an option (firewall-type: iptables/firewalld).<br>On upgrade it con=
tinues with the 'old' definition and on new created host the default can be f=
irewalld.<br></div>Is someone will explicitly want to change it from one to
t=
he other, we could go with remove/add approach to make things simpler.<br><b=
r></div>I personally like the distributed approach, where the upper manageme=
nt layer passes what it wants to the lower layers with minimum information. L=
etting the lower levels<br></div>do the explicit work and figure out what th=
ey need to do.<br></div>If that was the original approach, Engine would have=
not 'care' what type of firewall you use down at the host, you could even u=
se a custom firewall, an NFV firewall solution<br></div>or anything that may=
pop up in the future.<br></div><div>Engine would have just said: I want
lib=
virt, vdsm, ssh, etc... services opened (for access from
...).<br></div><div=
Custom settings? That implies we manage firewalls. So either let the
user a=
dd their special stuff on the hosts or provide them with a proper firewall
m=
anagement
interface.<br></div><div><br></div>Thanks,<br></div>Edy.<br><div><=
div><div><div><div><div><div><div><div><div><div><div><div><div><br></div></=
div></div></div></div></div></div></div></div></div></div></div></div></div>=
</div><div class=3D"gmail_extra"><br><div
class=3D"gmail_quote"><div><div cl=
ass=3D"h5">On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <span
dir=3D"=
ltr"><<a href=3D"mailto:didi@redhat.com"
target=3D"_blank">didi(a)redhat.co=
m</a>></span> wrote:<br></div></div><blockquote
class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div><d=
iv class=3D"h5"><span>On Sun, Mar 26, 2017 at 2:12 PM, Oved Ourfali
<<a h=
ref=3D"mailto:oourfali@redhat.com"
target=3D"_blank">oourfali(a)redhat.com</a>=
> wrote:<br
11:07 a.m.
Clients should be made aware their custom rules are going to be
obsolete and
that they should reapply them once they reinstall.
Would you want to manually fix every reinstalled host? I would
consider that very annoying. This has to be somewhat automatic if we
want to support custom firewall rules. And although I agree the engine
is not the right place for that, it is the only central place we have
and from which we are starting the reinstall task.
Martin
On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
> You're right, but I don't think it matters; hosts will remain unaffected
> until they're reinstalled via an upgraded Engine.
>
Clients should be made aware their custom rules are going to be
obsolete and
that they should reapply them once they reinstall.
>
> On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
>>
>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > Effectively, upgrading will leave lingering (but nonetheless
>> > operational)
>> > iptables rules on the hosts. I'm not even sure there needs to be
special
>> > upgrade treatment?
>>
>> Please describe the expected flow.
>>
>> Please note that at least when I tried, 'systemctl start firewalld'
stops
>> iptables.
>>
>> Thanks,
>>
>> >
>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <didi(a)redhat.com>
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > 1) Do we actually need iptables for any reason that isn't a
legacy
>> >> > consideration?
>> >>
>> >> No idea personally.
>> >>
>> >> Perhaps some users prefer that, and/or need that for integration with
>> >> other
>> >> systems/solutions/whatever.
>> >>
>> >> If we drop iptables, how do you suggest to treat upgrades?
>> >>
>> >> >
>> >> > 2 & 3) I am in favor of treating custom services as a
requirement and
>> >> > plan
>> >> > accordingly. Many (most, even) of the services are already
provided
>> >> > by
>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>> >> > packages
>> >> > (e.g.
>> >> > gluster). Some are missing (I've recently created a pull
request for
>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be
able to
>> >> > get
>> >> > all
>> >> > the services to be statically provided (by either firewalld or the
>> >> > relevant
>> >> > 3rd party packages).
>> >> >
>> >> > Ideally I think we'd like use statically provided services,
and
>> >> > provide
>> >> > the
>> >> > capability to provide additional services (I'm not a fan of
the
>> >> > current
>> >> > methodology of converting strings into xmls). I don't think
we'd want
>> >> > to
>> >> > limit usage to just statically provided services. (2)
>> >> >
>> >> > As previously stated, I don't see a technical reason to keep
iptables
>> >> > under
>> >> > consideration. (3)
>> >> >
>> >> >
>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
<didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> 1. Do we want to support in some version X both iptables and
>> >> >> firewalld,
>> >> >> or
>> >> >> is it ok to stop support for iptables and support only
firewalld
>> >> >> without
>> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >>
>> >> >> 2. Do we want to support custom firewalld xml to be configured
on
>> >> >> the
>> >> >> host by us? Or is it ok to only support choosing among
existing
>> >> >> services,
>> >> >> which will need to be added to the host using other means
(packaged
>> >> >> by
>> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >> >>
>> >> >> 3. Opposite of (2.): Do we want to support firewalld services
that
>> >> >> are
>> >> >> added to the host using other means (see there)? Obviously we
do,
>> >> >> but:
>> >> >> If we do, do we still want to support also iptables (see (1.))?
And
>> >> >> if
>> >> >> so, what do we want to then happen?
>> >> >>
>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
12:47 p.m.
On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak(a)redhat.com> wrote:
> Clients should be made aware their custom rules are going to be
obsolete
and
> that they should reapply them once they reinstall.
Would you want to manually fix every reinstalled host? I would
consider that very annoying. This has to be somewhat automatic if we
want to support custom firewall rules. And although I agree the engine
is not the right place for that, it is the only central place we have
and from which we are starting the reinstall task.
But we do not want to support custom firewall rules, we are not a firewall
manager.
IMO, oVirt should support the hardening of its services and co-exist with
other rules.
Custom firewall settings imply one of these:
- We need to extend current firewall options.
- It needs to be implemented outside oVirt.
But if the need to support back doors is proven to be a must, then
implement them
outside the main core solution, these edge cases should not block the main
business
logic.
Martin
On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
> You're right, but I don't think it matters; hosts will remain unaffected
> until they're reinstalled via an upgraded Engine.
>
> Clients should be made aware their custom rules are going to be obsolete
and
> that they should reapply them once they reinstall.
>
> On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>>
>> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > Effectively, upgrading will leave lingering (but nonetheless
>> > operational)
>> > iptables rules on the hosts. I'm not even sure there needs to be
special
>> > upgrade treatment?
>>
>> Please describe the expected flow.
>>
>> Please note that at least when I tried, 'systemctl start firewalld'
stops
>> iptables.
>>
>> Thanks,
>>
>> >
>> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
<didi(a)redhat.com>
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > 1) Do we actually need iptables for any reason that isn't a
legacy
>> >> > consideration?
>> >>
>> >> No idea personally.
>> >>
>> >> Perhaps some users prefer that, and/or need that for integration with
>> >> other
>> >> systems/solutions/whatever.
>> >>
>> >> If we drop iptables, how do you suggest to treat upgrades?
>> >>
>> >> >
>> >> > 2 & 3) I am in favor of treating custom services as a
requirement
and
>> >> > plan
>> >> > accordingly. Many (most, even) of the services are already
provided
>> >> > by
>> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>> >> > packages
>> >> > (e.g.
>> >> > gluster). Some are missing (I've recently created a pull
request
for
>> >> > ovirt-imageio to firewalld, for example) and I hope we'll be
able
to
>> >> > get
>> >> > all
>> >> > the services to be statically provided (by either firewalld or
the
>> >> > relevant
>> >> > 3rd party packages).
>> >> >
>> >> > Ideally I think we'd like use statically provided services,
and
>> >> > provide
>> >> > the
>> >> > capability to provide additional services (I'm not a fan of
the
>> >> > current
>> >> > methodology of converting strings into xmls). I don't think
we'd
want
>> >> > to
>> >> > limit usage to just statically provided services. (2)
>> >> >
>> >> > As previously stated, I don't see a technical reason to keep
iptables
>> >> > under
>> >> > consideration. (3)
>> >> >
>> >> >
>> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David <
didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >> 1. Do we want to support in some version X both iptables and
>> >> >> firewalld,
>> >> >> or
>> >> >> is it ok to stop support for iptables and support only
firewalld
>> >> >> without
>> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >>
>> >> >> 2. Do we want to support custom firewalld xml to be configured
on
>> >> >> the
>> >> >> host by us? Or is it ok to only support choosing among
existing
>> >> >> services,
>> >> >> which will need to be added to the host using other means
(packaged
>> >> >> by
>> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>> >> >>
>> >> >> 3. Opposite of (2.): Do we want to support firewalld services
that
>> >> >> are
>> >> >> added to the host using other means (see there)? Obviously we
do,
>> >> >> but:
>> >> >> If we do, do we still want to support also iptables (see
(1.))?
And
>> >> >> if
>> >> >> so, what do we want to then happen?
>> >> >>
>> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>>
>>
>>
>> --
>> Didi
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:16 a.m.
--Bioi7KQHbUCfdppItjnvNgbqRsI3Kcuki
Content-Type: multipart/mixed; boundary="b9EXQwBtmwbwLU8PwiNGeiXMuAbEvcopm";
protected-headers="v1"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <a635b271-0e64-e256-5834-a34a4633be01(a)mittwald.de>
Subject: Re: [ovirt-devel] Firewalld migration.
References: <CA+mNUtDjTH31=qb-FyTUjO0LdMW9y0kSmqizG2Pq=HnBukns1g(a)mail.gmail.com>
<CAJ_kCt5kvevgcrcBGi_RqMPgkS1TC-9C2v_1qBtyQZpGuiPAhQ(a)mail.gmail.com>
<CA+mNUtDLz9_D4r5L_BU_oRcyhhrc2DL=1h5WPCbWqUbLRL8xfA(a)mail.gmail.com>
<CAJ_kCt7qjwLy+T90X_wHscqTAh-z0=t+YHCJGm0ssk=i3bC4AQ(a)mail.gmail.com>
<CAHRwYXtr7TJZ1-CACgdJ1H2ANO=6oMujar7C3rsfNYnvQWiGmA(a)mail.gmail.com>
<CA+mNUtDUb8RdbGgmZj0w0SXvav4+RGX_Qys5EhN-Ff=0kLS-=g(a)mail.gmail.com>
<CAHRwYXuMxbHNYMcfBLDG0sVR1rpcsij4TG0p_3CjreGMXuGwqw(a)mail.gmail.com>
<CA+mNUtBLPGdqR4M=yrh772F=UXj9bK+1hGfeGxunfMHnq3PecA(a)mail.gmail.com>
<CAHRwYXv+wJwhHzMfVN3sgJ=VeDHOgL48tKYjSe6rhF4EyTQGEg(a)mail.gmail.com>
<CA+mNUtA=xD=7x+CVme2pRpf07-Ta=K9M6b3SooMiiTBDMkL2ag(a)mail.gmail.com>
<CAF0zDV6K4E+eBf6hzLXh5GUXO9H8F3cJkzDWx5879A3mHp64OA(a)mail.gmail.com>
<CALmkdFRtrtCLj4g_=S_6yjz6Vegx4Y--yw2eGuo1net5AhsSeg(a)mail.gmail.com>
In-Reply-To: <CALmkdFRtrtCLj4g_=S_6yjz6Vegx4Y--yw2eGuo1net5AhsSeg(a)mail.gmail.com>
--b9EXQwBtmwbwLU8PwiNGeiXMuAbEvcopm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Hi,
just a quick note from the end user /sys admin/dev ops perspective:
wouldn't it suffice if you have rules for common config management
systems at hand / in the docs/ on github?
I like packages the most, that don't try to own the whole system.
just provide a saltstack formula and I'm fine ;)
just my 2 cent
Mit freundlichen Gr=FC=DFen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
K=F6nigsberger Stra=DFe 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Gesch=E4ftsf=FChrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause=
n
Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha=
usen
--b9EXQwBtmwbwLU8PwiNGeiXMuAbEvcopm--
--Bioi7KQHbUCfdppItjnvNgbqRsI3Kcuki
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJY2lQbAAoJEMby9TMDAbQRb1gQAKjqhWdwWeIr4MUmimSUPouB
jf+SslNUd2xRllMYNtEjf3EuLnSXbkUOZHUIvpnJkkaRKorVMdJN0nMpNW1K8ziI
82AmCoSr98IxfXRZBJH3UcHRqbhcPERKaWwCrRIlX1PO5LxtNZdv4qUcJMWnxlw+
FIzmKjIOci40YvbfWkOP1/f9nCNPVdk+I3sjmqgilGPMjQf1nkhkAGSKG1moUJuo
I+gCpulKqHoVJG6R/X8GcBDZ75k72kYA/tj9Fat5d9vgb/aY2OMP/OKHif8jNpGq
j8s1szhH2kM5QNvC1QRKqocKgTOBghELIG0jTujIgApJ7aj6m3QMPnlnIkLVJVhr
V+PFVW7abGR5anO9tHJ3GDdF7h9vnkLjAYT0SRUycpDf6Brz2SBRTEEaf8ICaeG7
4DCCKWMQGfgCZ+CNNvbHPlQM2BeOCBFdTSErRZfDdtd8aMmVE+aX7mmEFXSj2RGl
Ut35bjDDss6dmgHmilztRvGFI4D06WGIGv8iCOt6cg/+2ls03cdWINyv8QAu8KB0
zP6gDM3znMk9Y0NxBIUhUng9syV3t3a6w3mXQIhiCZBw9gygtWReXPC3VgqeqDsA
vLGsYNxCHTVtNZTr7i5yCUrKv6ZZibxANsUAwhT3eQc4lQ9U1lMGRQrAzkLmIJnS
voxOV1zq55z5EchAusej
=mLGR
-----END PGP SIGNATURE-----
--Bioi7KQHbUCfdppItjnvNgbqRsI3Kcuki--
8 a.m.
But we do not want to support custom firewall rules, we are not a
firewall
manager.
IMO, oVirt should support the hardening of its services and co-exist with
other rules.
Custom firewall settings imply one of these:
- We need to extend current firewall options.
- It needs to be implemented outside oVirt.
But if the need to support back doors is proven to be a must, then implement
them
outside the main core solution, these edge cases should not block the main
business
logic.
I seem to remember that the one feature that sets us apart from
everybody else is that we know how to manage the bare metal. And the
current standing decision I know about is that we want to keep that
capability.
Yaniv? Is that still so?
All other solutions (OpenStack, OpenShift, ..) require you to
configure the bare metal first and then deploy virtualization. We
simplify this for the sysadmin and that makes us special (for good and
bad as Sven pointed out).
So, if we do not want to support custom rules in the engine, then the
whole host deploy script (not just firewall) needs to work very
differently, because the end goal is to have properly deployed node
for virtualization. And the "properly" word is defined both by us and
the owner sysadmin.
But deploy has to all or nothing operation, otherwise the engine will
start using half configured host and you risk someone forgetting to
run an extra script.
Martin
On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak(a)redhat.com> wrote:
>>
>> > Clients should be made aware their custom rules are going to be obsolete
>> > and
>> > that they should reapply them once they reinstall.
>>
>> Would you want to manually fix every reinstalled host? I would
>> consider that very annoying. This has to be somewhat automatic if we
>> want to support custom firewall rules. And although I agree the engine
>> is not the right place for that, it is the only central place we have
>> and from which we are starting the reinstall task.
>
>
But we do not want to support custom firewall rules, we are not a
firewall
manager.
IMO, oVirt should support the hardening of its services and co-exist with
other rules.
Custom firewall settings imply one of these:
- We need to extend current firewall options.
- It needs to be implemented outside oVirt.
But if the need to support back doors is proven to be a must, then implement
them
outside the main core solution, these edge cases should not block the main
business
logic.
>
>
>>
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > You're right, but I don't think it matters; hosts will remain
unaffected
>> > until they're reinstalled via an upgraded Engine.
>> >
>> > Clients should be made aware their custom rules are going to be obsolete
>> > and
>> > that they should reapply them once they reinstall.
>> >
>> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi(a)redhat.com>
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > Effectively, upgrading will leave lingering (but nonetheless
>> >> > operational)
>> >> > iptables rules on the hosts. I'm not even sure there needs to
be
>> >> > special
>> >> > upgrade treatment?
>> >>
>> >> Please describe the expected flow.
>> >>
>> >> Please note that at least when I tried, 'systemctl start
firewalld'
>> >> stops
>> >> iptables.
>> >>
>> >> Thanks,
>> >>
>> >> >
>> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
<didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> >> wrote:
>> >> >> > 1) Do we actually need iptables for any reason that
isn't a legacy
>> >> >> > consideration?
>> >> >>
>> >> >> No idea personally.
>> >> >>
>> >> >> Perhaps some users prefer that, and/or need that for
integration
>> >> >> with
>> >> >> other
>> >> >> systems/solutions/whatever.
>> >> >>
>> >> >> If we drop iptables, how do you suggest to treat upgrades?
>> >> >>
>> >> >> >
>> >> >> > 2 & 3) I am in favor of treating custom services as a
requirement
>> >> >> > and
>> >> >> > plan
>> >> >> > accordingly. Many (most, even) of the services are
already
>> >> >> > provided
>> >> >> > by
>> >> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd
party
>> >> >> > packages
>> >> >> > (e.g.
>> >> >> > gluster). Some are missing (I've recently created a
pull request
>> >> >> > for
>> >> >> > ovirt-imageio to firewalld, for example) and I hope
we'll be able
>> >> >> > to
>> >> >> > get
>> >> >> > all
>> >> >> > the services to be statically provided (by either
firewalld or the
>> >> >> > relevant
>> >> >> > 3rd party packages).
>> >> >> >
>> >> >> > Ideally I think we'd like use statically provided
services, and
>> >> >> > provide
>> >> >> > the
>> >> >> > capability to provide additional services (I'm not a
fan of the
>> >> >> > current
>> >> >> > methodology of converting strings into xmls). I don't
think we'd
>> >> >> > want
>> >> >> > to
>> >> >> > limit usage to just statically provided services. (2)
>> >> >> >
>> >> >> > As previously stated, I don't see a technical reason
to keep
>> >> >> > iptables
>> >> >> > under
>> >> >> > consideration. (3)
>> >> >> >
>> >> >> >
>> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
>> >> >> > <didi(a)redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> 1. Do we want to support in some version X both
iptables and
>> >> >> >> firewalld,
>> >> >> >> or
>> >> >> >> is it ok to stop support for iptables and support only
firewalld
>> >> >> >> without
>> >> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >> >>
>> >> >> >> 2. Do we want to support custom firewalld xml to be
configured on
>> >> >> >> the
>> >> >> >> host by us? Or is it ok to only support choosing among
existing
>> >> >> >> services,
>> >> >> >> which will need to be added to the host using other
means
>> >> >> >> (packaged
>> >> >> >> by
>> >> >> >> firewalld, packaged by 3rd parties, added manually by
users)?
>> >> >> >>
>> >> >> >> 3. Opposite of (2.): Do we want to support firewalld
services
>> >> >> >> that
>> >> >> >> are
>> >> >> >> added to the host using other means (see there)?
Obviously we do,
>> >> >> >> but:
>> >> >> >> If we do, do we still want to support also iptables
(see (1.))?
>> >> >> >> And
>> >> >> >> if
>> >> >> >> so, what do we want to then happen?
>> >> >> >>
>> >> >> >> (2.) and (3.) are not conflicting, each needs its own
answer.
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Didi
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel(a)ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
8 a.m.
On Tue, Mar 28, 2017 at 3:16 PM, Sven Kieske <s.kieske(a)mittwald.de> wrote:
Hi,
just a quick note from the end user /sys admin/dev ops perspective:
wouldn't it suffice if you have rules for common config management
systems at hand / in the docs/ on github?
I like packages the most, that don't try to own the whole system.
just provide a saltstack formula and I'm fine ;)
s/saltstack/ansible/g ;-)
Not that I have anything against saltstack, but we have made some
investment in Ansible modules for oVirt, and it seems logical we'll keep
adding more such modules to manage the hosts (and perhaps later on the
network, storage, ...)
Of course, we'd be happy to see contributions for saltstack based oVirt
mgmt!
And looking at[1], there's certainly demand for it. Sounds like a great
GSoC project idea, no?
Do you know if it should be done to SaltVirt[2] or SaltCloud[3] ? I'm not
sure and have not investigated it yet.
Y.
[1] https://github.com/saltstack/salt/issues/30323
[2] https://docs.saltstack.com/en/latest/topics/virt/
[3] https://docs.saltstack.com/en/latest/topics/cloud/
just my 2 cent
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
9:10 a.m.
On Tue, Mar 28, 2017 at 3:16 PM, Sven Kieske <s.kieske(a)mittwald.de> wrote:
Hi,
just a quick note from the end user /sys admin/dev ops perspective:
wouldn't it suffice if you have rules for common config management
systems at hand / in the docs/ on github?
I like packages the most, that don't try to own the whole system.
just provide a saltstack formula and I'm fine ;)
just my 2 cent
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
After doing a little bit of research, it seems like the previously
suggested ansible approach could be well suited. We already have an
inventory script[1] that could be used in combination with firewalld
ansible playbooks, i.e.:
*"ansible-playbook --limit=some-cluster
--inventory=ovirt-engine-hosts-ansible-inventory.py
some-cluster-firewalld.yaml"*[1]
https://github.com/oVirt/ovirt-engine-metrics/blob/64fef8c80ec607056b8477...
9:45 a.m.
On Tue, Mar 28, 2017 at 5:10 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
On Tue, Mar 28, 2017 at 3:16 PM, Sven Kieske
<s.kieske(a)mittwald.de> wrote:
>
> Hi,
>
> just a quick note from the end user /sys admin/dev ops perspective:
>
> wouldn't it suffice if you have rules for common config management
> systems at hand / in the docs/ on github?
>
> I like packages the most, that don't try to own the whole system.
>
> just provide a saltstack formula and I'm fine ;)
>
> just my 2 cent
>
> Mit freundlichen Grüßen / Regards
>
> Sven Kieske
>
> Systemadministrator
> Mittwald CM Service GmbH & Co. KG
> Königsberger Straße 6
> 32339 Espelkamp
> T: +495772 293100
> F: +495772 293333
> https://www.mittwald.de
> Geschäftsführer: Robert Meyer
> St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad
> Oeynhausen
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
After doing a little bit of research, it seems like the previously suggested
ansible approach could be well suited. We already have an inventory
script[1] that could be used in combination with firewalld ansible
playbooks, i.e.:
"ansible-playbook --limit=some-cluster
--inventory=ovirt-engine-hosts-ansible-inventory.py
some-cluster-firewalld.yaml"
[1]
https://github.com/oVirt/ovirt-engine-metrics/blob/64fef8c80ec607056b8477...
Whoever that wants to use this script, please use the shell wrapper
in same directory. If you want to run the python script directly
you have to set PYTHONPATH as is done there.
Regarding the actual idea of using ansible - of course that's doable,
but might not integrate very nicely into the host-deploy process.
host-deploy runs on the host, not on the engine. So we'll have to
do one of these:
1. Copy the ansible stuff to the host, install ansible there, and
run it locally. Ugly imo.
2. Run it semi-independently of host-deploy. In practice this means
it somehow needs to run before it, or nothing will open the vdsm port
and so the engine will fail connecting to it.
3. Change the host-deploy process on the engine side to also run
ansible.
4. Rewrite host-deploy using ansible :-) This actually was discussed
in the past in the integration team, and rejected, but we now know
ansible somewhat better, so might rethink our objections...
Also please note that unless you choose (2.), the above-mentioned
inventory script is not really relevant, because you want to configure
a specific host, and you don't need an inventory script for that.
In ovirt-engine-metrics, we chose (2.) - you can run the ansible
script at any point in time, and it will configure all of the
relevant hosts for sending metrics (if configured on the engine machine).
Best,
--
Didi
10:29 a.m.
On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak <msivak(a)redhat.com> wrote:
> But we do not want to support custom firewall rules, we are not
a
firewall
> manager.
> IMO, oVirt should support the hardening of its services and co-exist with
> other rules.
> Custom firewall settings imply one of these:
> - We need to extend current firewall options.
> - It needs to be implemented outside oVirt.
>
> But if the need to support back doors is proven to be a must, then
implement
> them
> outside the main core solution, these edge cases should not block the
main
> business
> logic.
I seem to remember that the one feature that sets us apart from
everybody else is that we know how to manage the bare metal. And the
current standing decision I know about is that we want to keep that
capability.
Yaniv? Is that still so?
It is, but we also need to acknowledge that:
1. We can't configure (and/or possibly customize) everything (NTP?
multipath.conf configuration? even vdsm.conf!). We strive to improve and do
it well, but there are limits and challenges.
2. There are better tools to do it than via engine-config -> database ->
host-deploy, which are also easier for both us to support as well as our
users to work with.
Y.
All other solutions (OpenStack, OpenShift, ..) require you to
configure the bare metal first and then deploy virtualization. We
simplify this for the sysadmin and that makes us special (for good and
bad as Sven pointed out).
So, if we do not want to support custom rules in the engine, then the
whole host deploy script (not just firewall) needs to work very
differently, because the end goal is to have properly deployed node
for virtualization. And the "properly" word is defined both by us and
the owner sysadmin.
But deploy has to all or nothing operation, otherwise the engine will
start using half configured host and you risk someone forgetting to
run an extra script.
Martin
On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>
>
> On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak(a)redhat.com> wrote:
>>
>> > Clients should be made aware their custom rules are going to be
obsolete
>> > and
>> > that they should reapply them once they reinstall.
>>
>> Would you want to manually fix every reinstalled host? I would
>> consider that very annoying. This has to be somewhat automatic if we
>> want to support custom firewall rules. And although I agree the engine
>> is not the right place for that, it is the only central place we have
>> and from which we are starting the reinstall task.
>
>
> But we do not want to support custom firewall rules, we are not a
firewall
> manager.
> IMO, oVirt should support the hardening of its services and co-exist with
> other rules.
> Custom firewall settings imply one of these:
> - We need to extend current firewall options.
> - It needs to be implemented outside oVirt.
>
> But if the need to support back doors is proven to be a must, then
implement
> them
> outside the main core solution, these edge cases should not block the
main
> business
> logic.
>
>
>>
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>> > You're right, but I don't think it matters; hosts will remain
unaffected
>> > until they're reinstalled via an upgraded Engine.
>> >
>> > Clients should be made aware their custom rules are going to be
obsolete
>> > and
>> > that they should reapply them once they reinstall.
>> >
>> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David
<didi(a)redhat.com>
>> > wrote:
>> >>
>> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > Effectively, upgrading will leave lingering (but nonetheless
>> >> > operational)
>> >> > iptables rules on the hosts. I'm not even sure there needs to
be
>> >> > special
>> >> > upgrade treatment?
>> >>
>> >> Please describe the expected flow.
>> >>
>> >> Please note that at least when I tried, 'systemctl start
firewalld'
>> >> stops
>> >> iptables.
>> >>
>> >> Thanks,
>> >>
>> >> >
>> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David <
didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg <
lgoldber(a)redhat.com>
>> >> >> wrote:
>> >> >> > 1) Do we actually need iptables for any reason that
isn't a
legacy
>> >> >> > consideration?
>> >> >>
>> >> >> No idea personally.
>> >> >>
>> >> >> Perhaps some users prefer that, and/or need that for
integration
>> >> >> with
>> >> >> other
>> >> >> systems/solutions/whatever.
>> >> >>
>> >> >> If we drop iptables, how do you suggest to treat upgrades?
>> >> >>
>> >> >> >
>> >> >> > 2 & 3) I am in favor of treating custom services as
a
requirement
>> >> >> > and
>> >> >> > plan
>> >> >> > accordingly. Many (most, even) of the services are
already
>> >> >> > provided
>> >> >> > by
>> >> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd
party
>> >> >> > packages
>> >> >> > (e.g.
>> >> >> > gluster). Some are missing (I've recently created a
pull request
>> >> >> > for
>> >> >> > ovirt-imageio to firewalld, for example) and I hope
we'll be
able
>> >> >> > to
>> >> >> > get
>> >> >> > all
>> >> >> > the services to be statically provided (by either
firewalld or
the
>> >> >> > relevant
>> >> >> > 3rd party packages).
>> >> >> >
>> >> >> > Ideally I think we'd like use statically provided
services, and
>> >> >> > provide
>> >> >> > the
>> >> >> > capability to provide additional services (I'm not a
fan of the
>> >> >> > current
>> >> >> > methodology of converting strings into xmls). I don't
think we'd
>> >> >> > want
>> >> >> > to
>> >> >> > limit usage to just statically provided services. (2)
>> >> >> >
>> >> >> > As previously stated, I don't see a technical reason
to keep
>> >> >> > iptables
>> >> >> > under
>> >> >> > consideration. (3)
>> >> >> >
>> >> >> >
>> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
>> >> >> > <didi(a)redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >> 1. Do we want to support in some version X both
iptables and
>> >> >> >> firewalld,
>> >> >> >> or
>> >> >> >> is it ok to stop support for iptables and support
only
firewalld
>> >> >> >> without
>> >> >> >> overlap? If so, do we handle upgrades, and how?
>> >> >> >>
>> >> >> >> 2. Do we want to support custom firewalld xml to be
configured
on
>> >> >> >> the
>> >> >> >> host by us? Or is it ok to only support choosing
among existing
>> >> >> >> services,
>> >> >> >> which will need to be added to the host using other
means
>> >> >> >> (packaged
>> >> >> >> by
>> >> >> >> firewalld, packaged by 3rd parties, added manually by
users)?
>> >> >> >>
>> >> >> >> 3. Opposite of (2.): Do we want to support firewalld
services
>> >> >> >> that
>> >> >> >> are
>> >> >> >> added to the host using other means (see there)?
Obviously we
do,
>> >> >> >> but:
>> >> >> >> If we do, do we still want to support also iptables
(see (1.))?
>> >> >> >> And
>> >> >> >> if
>> >> >> >> so, what do we want to then happen?
>> >> >> >>
>> >> >> >> (2.) and (3.) are not conflicting, each needs its own
answer.
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Didi
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Didi
>> >
>> >
>> >
>> > _______________________________________________
>> > Devel mailing list
>> > Devel(a)ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/devel
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
10:58 a.m.
2. There are better tools to do it than via engine-config ->
database ->
host-deploy, which are also easier for both us to support as well as our
users to work with.
I am all in favor of skipping engine-config and database.
1. We can't configure (and/or possibly customize) everything
(NTP?
multipath.conf configuration? even vdsm.conf!). We strive to improve and do
it well, but there are limits and challenges.
Sure, but we still run the host deploy from the engine side and then
activate the host immediately. Which means we need give the user a
chance to execute customizations in the middle of the process.
Currently it was firewall only and the way it was done was pretty
awkward, but we can do better instead of removing the option
completely.
I actually like the radical option Didi mentioned -> using Ansible for
the whole deploy flow. A simple host-deploy dir with playbooks (and
builtin roles) is something most people would understand easily.
And it would even remove all the infrastructure burden from us, oVirt
would not be the host management solution, Ansible would take the role
and we would just invoke it when deploying a new host much like we do
with host deploy now (except Ansible manages its own ssh connection
too).
Martin
On Tue, Mar 28, 2017 at 5:29 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak <msivak(a)redhat.com> wrote:
>>
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewall options.
>> > - It needs to be implemented outside oVirt.
>> >
>> > But if the need to support back doors is proven to be a must, then
>> > implement
>> > them
>> > outside the main core solution, these edge cases should not block the
>> > main
>> > business
>> > logic.
>>
>> I seem to remember that the one feature that sets us apart from
>> everybody else is that we know how to manage the bare metal. And the
>> current standing decision I know about is that we want to keep that
>> capability.
>>
>> Yaniv? Is that still so?
>
>
> It is, but we also need to acknowledge that:
1. We can't configure (and/or possibly customize) everything
(NTP?
multipath.conf configuration? even vdsm.conf!). We strive to improve and do
it well, but there are limits and challenges.
2. There are
better tools to do it than via engine-config -> database ->
host-deploy, which are also easier for both us to support as well as our
users to work with.
> Y.
>
>
>>
>> All other solutions (OpenStack, OpenShift, ..) require you to
>> configure the bare metal first and then deploy virtualization. We
>> simplify this for the sysadmin and that makes us special (for good and
>> bad as Sven pointed out).
>>
>> So, if we do not want to support custom rules in the engine, then the
>> whole host deploy script (not just firewall) needs to work very
>> differently, because the end goal is to have properly deployed node
>> for virtualization. And the "properly" word is defined both by us and
>> the owner sysadmin.
>>
>> But deploy has to all or nothing operation, otherwise the engine will
>> start using half configured host and you risk someone forgetting to
>> run an extra script.
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>> >
>> >
>> > On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak(a)redhat.com>
wrote:
>> >>
>> >> > Clients should be made aware their custom rules are going to be
>> >> > obsolete
>> >> > and
>> >> > that they should reapply them once they reinstall.
>> >>
>> >> Would you want to manually fix every reinstalled host? I would
>> >> consider that very annoying. This has to be somewhat automatic if we
>> >> want to support custom firewall rules. And although I agree the engine
>> >> is not the right place for that, it is the only central place we have
>> >> and from which we are starting the reinstall task.
>> >
>> >
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewall options.
>> > - It needs to be implemented outside oVirt.
>> >
>> > But if the need to support back doors is proven to be a must, then
>> > implement
>> > them
>> > outside the main core solution, these edge cases should not block the
>> > main
>> > business
>> > logic.
>> >
>> >
>> >>
>> >>
>> >> Martin
>> >>
>> >> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > You're right, but I don't think it matters; hosts will
remain
>> >> > unaffected
>> >> > until they're reinstalled via an upgraded Engine.
>> >> >
>> >> > Clients should be made aware their custom rules are going to be
>> >> > obsolete
>> >> > and
>> >> > that they should reapply them once they reinstall.
>> >> >
>> >> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David
<didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> >> wrote:
>> >> >> > Effectively, upgrading will leave lingering (but
nonetheless
>> >> >> > operational)
>> >> >> > iptables rules on the hosts. I'm not even sure there
needs to be
>> >> >> > special
>> >> >> > upgrade treatment?
>> >> >>
>> >> >> Please describe the expected flow.
>> >> >>
>> >> >> Please note that at least when I tried, 'systemctl start
firewalld'
>> >> >> stops
>> >> >> iptables.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> >
>> >> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
>> >> >> > <didi(a)redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
>> >> >> >> <lgoldber(a)redhat.com>
>> >> >> >> wrote:
>> >> >> >> > 1) Do we actually need iptables for any reason
that isn't a
>> >> >> >> > legacy
>> >> >> >> > consideration?
>> >> >> >>
>> >> >> >> No idea personally.
>> >> >> >>
>> >> >> >> Perhaps some users prefer that, and/or need that for
integration
>> >> >> >> with
>> >> >> >> other
>> >> >> >> systems/solutions/whatever.
>> >> >> >>
>> >> >> >> If we drop iptables, how do you suggest to treat
upgrades?
>> >> >> >>
>> >> >> >> >
>> >> >> >> > 2 & 3) I am in favor of treating custom
services as a
>> >> >> >> > requirement
>> >> >> >> > and
>> >> >> >> > plan
>> >> >> >> > accordingly. Many (most, even) of the services
are already
>> >> >> >> > provided
>> >> >> >> > by
>> >> >> >> > either firewalld itself (e.g. vdsm, libvirt) or
the 3rd party
>> >> >> >> > packages
>> >> >> >> > (e.g.
>> >> >> >> > gluster). Some are missing (I've recently
created a pull
>> >> >> >> > request
>> >> >> >> > for
>> >> >> >> > ovirt-imageio to firewalld, for example) and I
hope we'll be
>> >> >> >> > able
>> >> >> >> > to
>> >> >> >> > get
>> >> >> >> > all
>> >> >> >> > the services to be statically provided (by either
firewalld or
>> >> >> >> > the
>> >> >> >> > relevant
>> >> >> >> > 3rd party packages).
>> >> >> >> >
>> >> >> >> > Ideally I think we'd like use statically
provided services, and
>> >> >> >> > provide
>> >> >> >> > the
>> >> >> >> > capability to provide additional services
(I'm not a fan of the
>> >> >> >> > current
>> >> >> >> > methodology of converting strings into xmls). I
don't think
>> >> >> >> > we'd
>> >> >> >> > want
>> >> >> >> > to
>> >> >> >> > limit usage to just statically provided services.
(2)
>> >> >> >> >
>> >> >> >> > As previously stated, I don't see a technical
reason to keep
>> >> >> >> > iptables
>> >> >> >> > under
>> >> >> >> > consideration. (3)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar
David
>> >> >> >> > <didi(a)redhat.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> 1. Do we want to support in some version X
both iptables and
>> >> >> >> >> firewalld,
>> >> >> >> >> or
>> >> >> >> >> is it ok to stop support for iptables and
support only
>> >> >> >> >> firewalld
>> >> >> >> >> without
>> >> >> >> >> overlap? If so, do we handle upgrades, and
how?
>> >> >> >> >>
>> >> >> >> >> 2. Do we want to support custom firewalld xml
to be configured
>> >> >> >> >> on
>> >> >> >> >> the
>> >> >> >> >> host by us? Or is it ok to only support
choosing among
>> >> >> >> >> existing
>> >> >> >> >> services,
>> >> >> >> >> which will need to be added to the host using
other means
>> >> >> >> >> (packaged
>> >> >> >> >> by
>> >> >> >> >> firewalld, packaged by 3rd parties, added
manually by users)?
>> >> >> >> >>
>> >> >> >> >> 3. Opposite of (2.): Do we want to support
firewalld services
>> >> >> >> >> that
>> >> >> >> >> are
>> >> >> >> >> added to the host using other means (see
there)? Obviously we
>> >> >> >> >> do,
>> >> >> >> >> but:
>> >> >> >> >> If we do, do we still want to support also
iptables (see
>> >> >> >> >> (1.))?
>> >> >> >> >> And
>> >> >> >> >> if
>> >> >> >> >> so, what do we want to then happen?
>> >> >> >> >>
>> >> >> >> >> (2.) and (3.) are not conflicting, each needs
its own answer.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Didi
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Didi
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Devel mailing list
>> >> > Devel(a)ovirt.org
>> >> > http://lists.ovirt.org/mailman/listinfo/devel
>> >> _______________________________________________
>> >> Devel mailing list
>> >> Devel(a)ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>
>
11:34 a.m.
--4pdsjT4L2os85dEm9kquOeQ6Ptg5l9wSs
Content-Type: multipart/mixed; boundary="vlCuSqbaLt9KI0wGL5rPUod0kVrUpQ1xE";
protected-headers="v1"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <9f5a0933-a32b-be8f-e33b-5e11571f70b7(a)mittwald.de>
Subject: Re: [ovirt-devel] Firewalld migration.
References: <CA+mNUtDjTH31=qb-FyTUjO0LdMW9y0kSmqizG2Pq=HnBukns1g(a)mail.gmail.com>
<CAJ_kCt5kvevgcrcBGi_RqMPgkS1TC-9C2v_1qBtyQZpGuiPAhQ(a)mail.gmail.com>
<CA+mNUtDLz9_D4r5L_BU_oRcyhhrc2DL=1h5WPCbWqUbLRL8xfA(a)mail.gmail.com>
<CAJ_kCt7qjwLy+T90X_wHscqTAh-z0=t+YHCJGm0ssk=i3bC4AQ(a)mail.gmail.com>
<CAHRwYXtr7TJZ1-CACgdJ1H2ANO=6oMujar7C3rsfNYnvQWiGmA(a)mail.gmail.com>
<CA+mNUtDUb8RdbGgmZj0w0SXvav4+RGX_Qys5EhN-Ff=0kLS-=g(a)mail.gmail.com>
<CAHRwYXuMxbHNYMcfBLDG0sVR1rpcsij4TG0p_3CjreGMXuGwqw(a)mail.gmail.com>
<CA+mNUtBLPGdqR4M=yrh772F=UXj9bK+1hGfeGxunfMHnq3PecA(a)mail.gmail.com>
<CAHRwYXv+wJwhHzMfVN3sgJ=VeDHOgL48tKYjSe6rhF4EyTQGEg(a)mail.gmail.com>
<CA+mNUtA=xD=7x+CVme2pRpf07-Ta=K9M6b3SooMiiTBDMkL2ag(a)mail.gmail.com>
<CAF0zDV6K4E+eBf6hzLXh5GUXO9H8F3cJkzDWx5879A3mHp64OA(a)mail.gmail.com>
<CALmkdFRtrtCLj4g_=S_6yjz6Vegx4Y--yw2eGuo1net5AhsSeg(a)mail.gmail.com>
<CAF0zDV6v1DYCmdniaVzbhOZy1bnzh0fNnTFHCkd1vAn_jwnyTg(a)mail.gmail.com>
<CAJgorsauFKOpF2iCuxTXhaPAQM5AY9_T_bR+APV75iRO81PPrg(a)mail.gmail.com>
<CAF0zDV6f38_7EwRE6nNb1WXHrAk7OEZv=wA3btvrdrBtQx3FCg(a)mail.gmail.com>
In-Reply-To: <CAF0zDV6f38_7EwRE6nNb1WXHrAk7OEZv=wA3btvrdrBtQx3FCg(a)mail.gmail.com>
--vlCuSqbaLt9KI0wGL5rPUod0kVrUpQ1xE
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 28/03/17 17:58, Martin Sivak wrote:
I actually like the radical option Didi mentioned -> using Ansible
for
the whole deploy flow. A simple host-deploy dir with playbooks (and
builtin roles) is something most people would understand easily.
=20
And it would even remove all the infrastructure burden from us, oVirt
would not be the host management solution, Ansible would take the role
and we would just invoke it when deploying a new host much like we do
with host deploy now (except Ansible manages its own ssh connection
too).
+1
but some drawback (actual ansible user here):
you in fact need _some_ libs on the managed hosts for certain ansible
features to work (e.g. if you want to respect selinux settings on the
host), so you would also need to provide these or list them as
prerequisites.
I understand ovirt can't just provide config mgmt solutions for every
tool out there (puppet, chef, ansible, saltstack, etc.).
the best approach would be, if it is pluggable, like foreman did this
with it's smart proxys and plugins:
https://theforeman.org/plugins/
so you could provide a plugin infrastructure and maybe write the ansible
integration yourself and the community can add their own
plugins like puppet or chef modules at will. If they mature enough
you could even ship those (optional).
I really think there would be some value in this, because many small
deployments use tools like puppet or ansible, while these do not scale
well for large environments, where you tend to have things like salt or
chef.
PS: if you want to annoy some users you could even declare a hard
dependency on foreman and use foreman for the host deployment (a tool
that's actually written for exact this scope), others might find this
higher integration nice. I'm not sure if I would like it or not.
--=20
Mit freundlichen Gr=FC=DFen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
K=F6nigsberger Stra=DFe 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Gesch=E4ftsf=FChrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause=
n
Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha=
usen
--vlCuSqbaLt9KI0wGL5rPUod0kVrUpQ1xE--
--4pdsjT4L2os85dEm9kquOeQ6Ptg5l9wSs
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJY2pCIAAoJEMby9TMDAbQRdKsQANGoClhjwMSXu1Ep/ejKbVy1
UUvXHvFLaj7Y51ZlzQrNK7NldOjQ4TvjfcFk0+EzVvdrc8dtr+gcLNBO32yv/+x5
7SlxTp3P9oKjBUzWNa5T1lUR3PsGfpuVygl11LDFN+nFiJhxE4hpxCfB6N4vbnSX
w/zPAo31XZpHZaiswCrD0D3A5JMLASqd+4GWGvLFmuqYlhbwg/xUoWNORveFQ8ry
ddyXnMXaMnYhy5oHkwsAdiK89EahLTgwbsd18dCM7nGtZx6XzjwDiJ6Epv5seFPS
NHfTHp3zkkiS/humrnCRmqR63QjiJfFtSan+3Jl98y2lxLuhHZLTSj0uFyQxkHeN
fiOM4usvBk3RY8vjJ+VuujrueDaN+0/fCvt86erJlghxhHrPFUNHU/ZHFs4lANbH
pIyG8072kc7B+94CTuzNAAjzMliAn7ma7/GSRT3Ux1se/tX+Bje49lbiGDnzLrFa
/7xmcJJqT6gFHInsiLT4auGKE+PJ5BI6UK87k/8jYrPovNYSc7/enM0h97qG43uF
jxrT+rOFZbLptWHCp+xFCnTvB3l5c0jFVyHI4w2bYVAAj8+L45N6xbYyYL+lx9rc
gBabgRezvGaP0gCMjXSPUjBJ3ALO5qzaMLNkLL/L4ClLbY6XAw/fU6UVC9EuslnK
wd19j00KdJBQdsVtAxpk
=ZoMB
-----END PGP SIGNATURE-----
--4pdsjT4L2os85dEm9kquOeQ6Ptg5l9wSs--
4:20 p.m.
On Tue, Mar 28, 2017 at 7:34 PM, Sven Kieske <s.kieske(a)mittwald.de> wrote:
On 28/03/17 17:58, Martin Sivak wrote:
> I actually like the radical option Didi mentioned -> using Ansible for
> the whole deploy flow. A simple host-deploy dir with playbooks (and
> builtin roles) is something most people would understand easily.
>
> And it would even remove all the infrastructure burden from us, oVirt
> would not be the host management solution, Ansible would take the role
> and we would just invoke it when deploying a new host much like we do
> with host deploy now (except Ansible manages its own ssh connection
> too).
+1
but some drawback (actual ansible user here):
you in fact need _some_ libs on the managed hosts for certain ansible
features to work (e.g. if you want to respect selinux settings on the
host), so you would also need to provide these or list them as
prerequisites.
I understand ovirt can't just provide config mgmt solutions for every
tool out there (puppet, chef, ansible, saltstack, etc.).
the best approach would be, if it is pluggable, like foreman did this
with it's smart proxys and plugins:
https://theforeman.org/plugins/
Ah, that's a different story altogether.
You can use Forman/Satellite to manage your hosts life-cycle.
It's a great, quite well integrated solution we are very fond of.
We support both discovered hosts (from bare-metal) as well as hosts added
already to Foreman.
so you could provide a plugin infrastructure and maybe write the ansible
integration yourself and the community can add their own
plugins like puppet or chef modules at will. If they mature enough
you could even ship those (optional).
I really think there would be some value in this, because many small
deployments use tools like puppet or ansible, while these do not scale
well for large environments, where you tend to have things like salt or
chef.
PS: if you want to annoy some users you could even declare a hard
dependency on foreman and use foreman for the host deployment (a tool
that's actually written for exact this scope), others might find this
higher integration nice. I'm not sure if I would like it or not.
I'd be happy to do that in the future. Right now there are some obstacles
to doing that.
Remember that there are huge benefits to using Foreman not just for host
life-cycle, but also VM life-cycle.
Y.
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:53 a.m.
On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <ydary(a)redhat.com> wrote:
Hi,
I like option number 3 the most from reading the comments.
We are not a configuration management system, so custom rules should not be
a main consideration.
VDSM should probably enable the firewalld rules it needs to work and engine
should not care about firewall at all.
A user wanting to add more rules then this should probably use the ones
planned in:
https://github.com/cockpit-project/system-api-roles
I, too, like the idea of shedding off the attempt to configure custom
iptables rules. Moving to firewalld makes it much easier to manage
such customization out of oVirt. (Anybody who's ever edited iptables
chains by hand would know what I mean)
Please note that what you describe is Leon's alternative (2.). Where
Vdsm, as oVirt host agent, has complete responsibility on configuring
the services needed by oVirt. There is no Engine/Vdsm interaction in
alternative (2.). Option (3.) requires Engine to provide a list of
services to the host.
3:23 a.m.
Ok, so I guess I misread.
VDSM should have that responsibility and engine should not be evolved.
I like the suggestion from other in the thread on managing the admin custom
rules via Ansible and the inventory playbook we have already created.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary(a)redhat.com
IRC : ydary
On Wed, Mar 29, 2017 at 9:53 AM, Dan Kenigsberg <danken(a)redhat.com> wrote:
On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <ydary(a)redhat.com>
wrote:
> Hi,
> I like option number 3 the most from reading the comments.
> We are not a configuration management system, so custom rules should not
be
> a main consideration.
> VDSM should probably enable the firewalld rules it needs to work and
engine
> should not care about firewall at all.
> A user wanting to add more rules then this should probably use the ones
> planned in:
> https://github.com/cockpit-project/system-api-roles
I, too, like the idea of shedding off the attempt to configure custom
iptables rules. Moving to firewalld makes it much easier to manage
such customization out of oVirt. (Anybody who's ever edited iptables
chains by hand would know what I mean)
Please note that what you describe is Leon's alternative (2.). Where
Vdsm, as oVirt host agent, has complete responsibility on configuring
the services needed by oVirt. There is no Engine/Vdsm interaction in
alternative (2.). Option (3.) requires Engine to provide a list of
services to the host.
3:28 a.m.
On Tue, Mar 28, 2017 at 6:58 PM, Martin Sivak <msivak(a)redhat.com> wrote:
> 2. There are better tools to do it than via engine-config ->
database ->
> host-deploy, which are also easier for both us to support as well as our
> users to work with.
I am all in favor of skipping engine-config and database.
This is a "detail", not a radical change. We can easily make
the engine read these from a conf file instead of the db.
Not sure we have clear guidelines re what should be in the db
vs what should be in config files. IIUC the only "tool" we
provide for editing config files is engine-setup, which is
quite restricting, considering it has other missions. Perhaps
we should have another tool for that, or teach engine-config
to do that as well. We hesitate from telling people to directly
edit/write config files (vs using engine-config), because, I
guess, we assume that's considered a bit too technical, and
because there is no protection/validation/syntax-checking/etc
if you only use an editor (vs engine-config, engine-setup or
any other tool).
> 1. We can't configure (and/or possibly customize) everything (NTP?
> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
> it well, but there are limits and challenges.
Sure, but we still run the host deploy from the engine side and then
activate the host immediately. Which means we need give the user a
chance to execute customizations in the middle of the process.
Currently it was firewall only and the way it was done was pretty
awkward, but we can do better instead of removing the option
completely.
I actually like the radical option Didi mentioned -> using Ansible for
the whole deploy flow. A simple host-deploy dir with playbooks (and
builtin roles) is something most people would understand easily.
I didn't even really start to analyze what this will require, but I'd
like to mention that the host-deploy process has two sides - one is
the code of ovirt-host-deploy (+otopi) that's copied to the host and
runs there, and the other side is the engine. If we want to keep the
other side to be the engine, we'll have to somehow teach it to talk
to ansible, or to teach ansible to talk to it. If we want to replace
this with something else, we need to check what the engine currently
does, what info is needed for that, make sure all that info is (made)
available externally (API/DB/config files/whatever) and then start
writing stuff (ansible roles or plugins) to do that.
And it would even remove all the infrastructure burden from us, oVirt
would not be the host management solution, Ansible would take the role
and we would just invoke it when deploying a new host much like we do
with host deploy now (except Ansible manages its own ssh connection
too).
I think saying the above is like saying that already now we do not have
to carry the burden of deploying hosts, because python+java do that for
us.
From a shallow and short experience with ansible for
ovirt-engine-metrics,
I think you/we should treat ansible as a language, not as a
tool. As a
language, it has some nice features/builtins, a nice standard library and
a great user community (providing both support and examples etc.), but
it's just that - a language.
If you have a look at ovirt-engine-metrics, you current find there:
389 lines in yml files
466 lines in all files under templates (some .j2, some plain conf)
I expect the functionality of host-deploy to be at least 10 times
larger. So a reimplementation will require at least several thousand
lines of ansible yml. I do not think this will be much easier to
understand/debug than the current python+java code. At least the
otopi+host-deploy code - I know almost nothing of the java code
in the engine, can't even tell how much of it is purely host-deploy
(i.e. will be removed if we reimlement in ansible).
Martin
On Tue, Mar 28, 2017 at 5:29 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak <msivak(a)redhat.com> wrote:
>>
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewall options.
>> > - It needs to be implemented outside oVirt.
>> >
>> > But if the need to support back doors is proven to be a must, then
>> > implement
>> > them
>> > outside the main core solution, these edge cases should not block the
>> > main
>> > business
>> > logic.
>>
>> I seem to remember that the one feature that sets us apart from
>> everybody else is that we know how to manage the bare metal. And the
>> current standing decision I know about is that we want to keep that
>> capability.
>>
>> Yaniv? Is that still so?
>
>
> It is, but we also need to acknowledge that:
> 1. We can't configure (and/or possibly customize) everything (NTP?
> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
> it well, but there are limits and challenges.
> 2. There are better tools to do it than via engine-config -> database ->
> host-deploy, which are also easier for both us to support as well as our
> users to work with.
> Y.
>
>
>>
>> All other solutions (OpenStack, OpenShift, ..) require you to
>> configure the bare metal first and then deploy virtualization. We
>> simplify this for the sysadmin and that makes us special (for good and
>> bad as Sven pointed out).
>>
>> So, if we do not want to support custom rules in the engine, then the
>> whole host deploy script (not just firewall) needs to work very
>> differently, because the end goal is to have properly deployed node
>> for virtualization. And the "properly" word is defined both by us and
>> the owner sysadmin.
>>
>> But deploy has to all or nothing operation, otherwise the engine will
>> start using half configured host and you risk someone forgetting to
>> run an extra script.
>>
>> Martin
>>
>> On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas(a)redhat.com> wrote:
>> >
>> >
>> > On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak(a)redhat.com>
wrote:
>> >>
>> >> > Clients should be made aware their custom rules are going to be
>> >> > obsolete
>> >> > and
>> >> > that they should reapply them once they reinstall.
>> >>
>> >> Would you want to manually fix every reinstalled host? I would
>> >> consider that very annoying. This has to be somewhat automatic if we
>> >> want to support custom firewall rules. And although I agree the engine
>> >> is not the right place for that, it is the only central place we have
>> >> and from which we are starting the reinstall task.
>> >
>> >
>> > But we do not want to support custom firewall rules, we are not a
>> > firewall
>> > manager.
>> > IMO, oVirt should support the hardening of its services and co-exist
>> > with
>> > other rules.
>> > Custom firewall settings imply one of these:
>> > - We need to extend current firewall options.
>> > - It needs to be implemented outside oVirt.
>> >
>> > But if the need to support back doors is proven to be a must, then
>> > implement
>> > them
>> > outside the main core solution, these edge cases should not block the
>> > main
>> > business
>> > logic.
>> >
>> >
>> >>
>> >>
>> >> Martin
>> >>
>> >> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> wrote:
>> >> > You're right, but I don't think it matters; hosts will
remain
>> >> > unaffected
>> >> > until they're reinstalled via an upgraded Engine.
>> >> >
>> >> > Clients should be made aware their custom rules are going to be
>> >> > obsolete
>> >> > and
>> >> > that they should reapply them once they reinstall.
>> >> >
>> >> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David
<didi(a)redhat.com>
>> >> > wrote:
>> >> >>
>> >> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg
<lgoldber(a)redhat.com>
>> >> >> wrote:
>> >> >> > Effectively, upgrading will leave lingering (but
nonetheless
>> >> >> > operational)
>> >> >> > iptables rules on the hosts. I'm not even sure there
needs to be
>> >> >> > special
>> >> >> > upgrade treatment?
>> >> >>
>> >> >> Please describe the expected flow.
>> >> >>
>> >> >> Please note that at least when I tried, 'systemctl start
firewalld'
>> >> >> stops
>> >> >> iptables.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> >
>> >> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
>> >> >> > <didi(a)redhat.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
>> >> >> >> <lgoldber(a)redhat.com>
>> >> >> >> wrote:
>> >> >> >> > 1) Do we actually need iptables for any reason
that isn't a
>> >> >> >> > legacy
>> >> >> >> > consideration?
>> >> >> >>
>> >> >> >> No idea personally.
>> >> >> >>
>> >> >> >> Perhaps some users prefer that, and/or need that for
integration
>> >> >> >> with
>> >> >> >> other
>> >> >> >> systems/solutions/whatever.
>> >> >> >>
>> >> >> >> If we drop iptables, how do you suggest to treat
upgrades?
>> >> >> >>
>> >> >> >> >
>> >> >> >> > 2 & 3) I am in favor of treating custom
services as a
>> >> >> >> > requirement
>> >> >> >> > and
>> >> >> >> > plan
>> >> >> >> > accordingly. Many (most, even) of the services
are already
>> >> >> >> > provided
>> >> >> >> > by
>> >> >> >> > either firewalld itself (e.g. vdsm, libvirt) or
the 3rd party
>> >> >> >> > packages
>> >> >> >> > (e.g.
>> >> >> >> > gluster). Some are missing (I've recently
created a pull
>> >> >> >> > request
>> >> >> >> > for
>> >> >> >> > ovirt-imageio to firewalld, for example) and I
hope we'll be
>> >> >> >> > able
>> >> >> >> > to
>> >> >> >> > get
>> >> >> >> > all
>> >> >> >> > the services to be statically provided (by either
firewalld or
>> >> >> >> > the
>> >> >> >> > relevant
>> >> >> >> > 3rd party packages).
>> >> >> >> >
>> >> >> >> > Ideally I think we'd like use statically
provided services, and
>> >> >> >> > provide
>> >> >> >> > the
>> >> >> >> > capability to provide additional services
(I'm not a fan of the
>> >> >> >> > current
>> >> >> >> > methodology of converting strings into xmls). I
don't think
>> >> >> >> > we'd
>> >> >> >> > want
>> >> >> >> > to
>> >> >> >> > limit usage to just statically provided services.
(2)
>> >> >> >> >
>> >> >> >> > As previously stated, I don't see a technical
reason to keep
>> >> >> >> > iptables
>> >> >> >> > under
>> >> >> >> > consideration. (3)
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar
David
>> >> >> >> > <didi(a)redhat.com>
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> 1. Do we want to support in some version X
both iptables and
>> >> >> >> >> firewalld,
>> >> >> >> >> or
>> >> >> >> >> is it ok to stop support for iptables and
support only
>> >> >> >> >> firewalld
>> >> >> >> >> without
>> >> >> >> >> overlap? If so, do we handle upgrades, and
how?
>> >> >> >> >>
>> >> >> >> >> 2. Do we want to support custom firewalld xml
to be configured
>> >> >> >> >> on
>> >> >> >> >> the
>> >> >> >> >> host by us? Or is it ok to only support
choosing among
>> >> >> >> >> existing
>> >> >> >> >> services,
>> >> >> >> >> which will need to be added to the host using
other means
>> >> >> >> >> (packaged
>> >> >> >> >> by
>> >> >> >> >> firewalld, packaged by 3rd parties, added
manually by users)?
>> >> >> >> >>
>> >> >> >> >> 3. Opposite of (2.): Do we want to support
firewalld services
>> >> >> >> >> that
>> >> >> >> >> are
>> >> >> >> >> added to the host using other means (see
there)? Obviously we
>> >> >> >> >> do,
>> >> >> >> >> but:
>> >> >> >> >> If we do, do we still want to support also
iptables (see
>> >> >> >> >> (1.))?
>> >> >> >> >> And
>> >> >> >> >> if
>> >> >> >> >> so, what do we want to then happen?
>> >> >> >> >>
>> >> >> >> >> (2.) and (3.) are not conflicting, each needs
its own answer.
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Didi
>> >> >> >> >
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Didi
>> >> >> >
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Didi
>> >> >
>> >> >
>> >> >
>> >> > _______________________________________________
>> >> > Devel mailing list
>> >> > Devel(a)ovirt.org
>> >> > http://lists.ovirt.org/mailman/listinfo/devel
>> >> _______________________________________________
>> >> Devel mailing list
>> >> Devel(a)ovirt.org
>> >> http://lists.ovirt.org/mailman/listinfo/devel
>> >
>> >
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Didi
6:56 a.m.
Hey,
There seems to be a growing consensus towards moving custom rules out of
Engine. It is believed that Engine shouldn't have assumed the role of a
centralized firewall management system in he first place, and that using a
proper 3rd party solution will be both favorable to the users (allowing
better functionality and usability) and will allow us to simplify our
firewall deployment process.
Considering we don't have to manage custom rules, a host will be able to
derive all the information regarding its firewalld services from its own
configuration. Consequently, option #2 becomes a forerunner with Engine's
involvement being even further diminished.
On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Hey,
We're looking to migrate from iptables to firewalld. We came up with a
couple of possible approaches we'd like opinions on. I'll list the options
first, and will
1) Replicate existing flow:
As of date, iptable rules are inserted in the database via SQL config
files. During host deployment, VdsDeployIptablesUnit adds the required
rules (based on cluster/firewall configuration) to the deployment
configuration, en route to being deployed on the host via otopi and its
iptables plugin.
Pros:
- Reuse of existing infrastructure.
Cons:
- Current infrastructure is overly complex...
- Many of the required services are provided by firewalld. Rewriting them
is wasteful; specifying them (instead of providing actual service .xml
content) will require adaptations on both (engine/host) sides. More on that
later.
2) Host side based configuration:
Essentially, all the required logic (aforementioned cluster/firewall
configuration) to determine if/how firewalld should be deployed could be
passed on to the host via ohd. Vdsm could take on the responsibility of
examining the relevant configuration, and then creating and/or adding the
required services (using vdsm.conf and vdsm-tool).
Pros:
- Engine side involvement is greatly diminished.
- Simple(r).
Cons:
- Custom services/rules capabilities will have to be rethought and
re-implemented (current infrastructure supports custom iptables rules by
being specified in the SQL config file).
3) Some other hybrid approach:
If we're able to guarantee all the required firewalld services are
statically provided one way or the other, the current procedure could be
replicated and be made more simpler. Instead of providing xml content in
the form of strings, service names could be supplied. The responsibility of
actual service deployment becomes easier, and could be left to otopi (with
the appropriate modifications) or switched over to vdsm.
--
Regardless, usage of statically provided vs. dynamically created services
remains an open question. I think we'd like to avoid implementing logic
that ask whether some service is provided (and then write it if it
isn't...), and so choosing between the dynamic and static approaches is
also needed. Using the static approach, guaranteeing *all* services are
provided will be required.
I do believe guaranteeing the presence of all required services is worth
it, however custom services aren't going to be naively compatible, and
we'll still have to use similar mechanism as described in #1 (service
string -> .xml -> addition of service name to active zone).
Your thoughts are welcome.
Thanks,
Leon
7:13 a.m.
On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Hey,
There seems to be a growing consensus towards moving custom rules out of
Engine. It is believed that Engine shouldn't have assumed the role of a
centralized firewall management system in he first place, and that using a
proper 3rd party solution will be both favorable to the users (allowing
better functionality and usability) and will allow us to simplify our
firewall deployment process.
Considering we don't have to manage custom rules, a host will be able to
derive all the information regarding its firewalld services from its own
configuration. Consequently, option #2 becomes a forerunner with Engine's
involvement being even further diminished.
Engine - no, running from RHVM - yes - if you are using Ansible , I think
it makes sense to use a single common script or possibly per cluster.
Y.
On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
> - Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
> Pros:
>
> - Engine side involvement is greatly diminished.
> - Simple(r).
>
> Cons:
>
> - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
7:35 a.m.
Engine - no, running from RHVM - yes - if you are using Ansible , I
think it
makes sense to use a single common script or possibly per cluster.
Exactly my point. The engine should not manage those, but it should
still know how to execute them to perform a proper host deploy.
Martin
On Thu, Apr 6, 2017 at 2:13 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
>>
>> Hey,
>>
>> There seems to be a growing consensus towards moving custom rules out of
>> Engine. It is believed that Engine shouldn't have assumed the role of a
>> centralized firewall management system in he first place, and that using a
>> proper 3rd party solution will be both favorable to the users (allowing
>> better functionality and usability) and will allow us to simplify our
>> firewall deployment process.
>>
>> Considering we don't have to manage custom rules, a host will be able to
>> derive all the information regarding its firewalld services from its own
>> configuration. Consequently, option #2 becomes a forerunner with Engine's
>> involvement being even further diminished.
>
>
Engine - no, running from RHVM - yes - if you are using Ansible , I
think it
makes sense to use a single common script or possibly per cluster.
> Y.
>
>>
>>
>>
>> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
>> wrote:
>>>
>>>
>>> Hey,
>>>
>>> We're looking to migrate from iptables to firewalld. We came up with a
>>> couple of possible approaches we'd like opinions on. I'll list the
options
>>> first, and will
>>>
>>> 1) Replicate existing flow:
>>>
>>> As of date, iptable rules are inserted in the database via SQL config
>>> files. During host deployment, VdsDeployIptablesUnit adds the required rules
>>> (based on cluster/firewall configuration) to the deployment configuration,
>>> en route to being deployed on the host via otopi and its iptables plugin.
>>>
>>> Pros:
>>>
>>> - Reuse of existing infrastructure.
>>>
>>> Cons:
>>>
>>> - Current infrastructure is overly complex...
>>> - Many of the required services are provided by firewalld. Rewriting them
>>> is wasteful; specifying them (instead of providing actual service .xml
>>> content) will require adaptations on both (engine/host) sides. More on that
>>> later.
>>>
>>>
>>> 2) Host side based configuration:
>>>
>>> Essentially, all the required logic (aforementioned cluster/firewall
>>> configuration) to determine if/how firewalld should be deployed could be
>>> passed on to the host via ohd. Vdsm could take on the responsibility of
>>> examining the relevant configuration, and then creating and/or adding the
>>> required services (using vdsm.conf and vdsm-tool).
>>>
>>> Pros:
>>>
>>> - Engine side involvement is greatly diminished.
>>> - Simple(r).
>>>
>>> Cons:
>>>
>>> - Custom services/rules capabilities will have to be rethought and
>>> re-implemented (current infrastructure supports custom iptables rules by
>>> being specified in the SQL config file).
>>>
>>>
>>> 3) Some other hybrid approach:
>>>
>>> If we're able to guarantee all the required firewalld services are
>>> statically provided one way or the other, the current procedure could be
>>> replicated and be made more simpler. Instead of providing xml content in the
>>> form of strings, service names could be supplied. The responsibility of
>>> actual service deployment becomes easier, and could be left to otopi (with
>>> the appropriate modifications) or switched over to vdsm.
>>>
>>> --
>>>
>>> Regardless, usage of statically provided vs. dynamically created services
>>> remains an open question. I think we'd like to avoid implementing logic
that
>>> ask whether some service is provided (and then write it if it isn't...),
and
>>> so choosing between the dynamic and static approaches is also needed. Using
>>> the static approach, guaranteeing all services are provided will be
>>> required.
>>>
>>> I do believe guaranteeing the presence of all required services is worth
>>> it, however custom services aren't going to be naively compatible, and
we'll
>>> still have to use similar mechanism as described in #1 (service string ->
>>> .xml -> addition of service name to active zone).
>>>
>>>
>>> Your thoughts are welcome.
>>>
>>> Thanks,
>>> Leon
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
8:03 a.m.
p.s., we've begun implementing option #2 using the following design and
approach:
Beginning with a configurable threshold for cluster compatibility levels
(defaulted to 4.2), instead of using/deploying iptables' deploy unit, we
set a firewalld boolean in vdsm.conf's deploy unit (similarly to iptables;
only in case firewall override is set).
Using a new dedicated vdsm configurator for firewalld, the required
services are added to the active zone(s) (currently being just the public
one) and become operational. This only takes place if firewalld's boolean
is set to true in vdsm.conf. We determine what non-baseline services should
be added based on what is installed on the host (e.g. gluster packages).
This approach guarantees that neither upgrading Engine or a host separately
will cause unwarranted firewall related modifications (more specifically,
custom rules/iptables' service remain intact). Explicitly
installing/re-installing hosts in compatible clusters via an upgraded
Engine is the only way to override custom rules/enabling firewalld's
service over iptables' service (barring manual alterations to
vdsm.conf...). We're also going to warn users during engine-setup and add
alerts during host (re)installations.
On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
Hey,
There seems to be a growing consensus towards moving custom rules out of
Engine. It is believed that Engine shouldn't have assumed the role of a
centralized firewall management system in he first place, and that using a
proper 3rd party solution will be both favorable to the users (allowing
better functionality and usability) and will allow us to simplify our
firewall deployment process.
Considering we don't have to manage custom rules, a host will be able to
derive all the information regarding its firewalld services from its own
configuration. Consequently, option #2 becomes a forerunner with Engine's
involvement being even further diminished.
On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
wrote:
>
> Hey,
>
> We're looking to migrate from iptables to firewalld. We came up with a
> couple of possible approaches we'd like opinions on. I'll list the options
> first, and will
>
> 1) Replicate existing flow:
>
> As of date, iptable rules are inserted in the database via SQL config
> files. During host deployment, VdsDeployIptablesUnit adds the required
> rules (based on cluster/firewall configuration) to the deployment
> configuration, en route to being deployed on the host via otopi and its
> iptables plugin.
>
> Pros:
>
> - Reuse of existing infrastructure.
>
> Cons:
>
> - Current infrastructure is overly complex...
> - Many of the required services are provided by firewalld. Rewriting them
> is wasteful; specifying them (instead of providing actual service .xml
> content) will require adaptations on both (engine/host) sides. More on that
> later.
>
>
> 2) Host side based configuration:
>
> Essentially, all the required logic (aforementioned cluster/firewall
> configuration) to determine if/how firewalld should be deployed could be
> passed on to the host via ohd. Vdsm could take on the responsibility of
> examining the relevant configuration, and then creating and/or adding the
> required services (using vdsm.conf and vdsm-tool).
>
> Pros:
>
> - Engine side involvement is greatly diminished.
> - Simple(r).
>
> Cons:
>
> - Custom services/rules capabilities will have to be rethought and
> re-implemented (current infrastructure supports custom iptables rules by
> being specified in the SQL config file).
>
>
> 3) Some other hybrid approach:
>
> If we're able to guarantee all the required firewalld services are
> statically provided one way or the other, the current procedure could be
> replicated and be made more simpler. Instead of providing xml content in
> the form of strings, service names could be supplied. The responsibility of
> actual service deployment becomes easier, and could be left to otopi (with
> the appropriate modifications) or switched over to vdsm.
>
> --
>
> Regardless, usage of statically provided vs. dynamically created services
> remains an open question. I think we'd like to avoid implementing logic
> that ask whether some service is provided (and then write it if it
> isn't...), and so choosing between the dynamic and static approaches is
> also needed. Using the static approach, guaranteeing *all* services are
> provided will be required.
>
> I do believe guaranteeing the presence of all required services is worth
> it, however custom services aren't going to be naively compatible, and
> we'll still have to use similar mechanism as described in #1 (service
> string -> .xml -> addition of service name to active zone).
>
>
> Your thoughts are welcome.
>
> Thanks,
> Leon
>
>
9:31 a.m.
On Thu, Apr 6, 2017 at 4:03 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
p.s., we've begun implementing option #2 using the following
design and
approach:
I'm missing the design @ https://github.com/oVirt/ovirt-site/pulls ...
Beginning with a configurable threshold for cluster compatibility levels
(defaulted to 4.2), instead of using/deploying iptables' deploy unit, we
set a firewalld boolean in vdsm.conf's deploy unit (similarly to iptables;
only in case firewall override is set).
This is exactly what I preferred we want to - continue to extend VDSM to
perform deployment, service management and configuration...
Using a new dedicated vdsm configurator for firewalld, the required
services are added to the active zone(s) (currently being just the public
one) and become operational. This only takes place if firewalld's boolean
is set to true in vdsm.conf. We determine what non-baseline services should
be added based on what is installed on the host (e.g. gluster packages).
This approach guarantees that neither upgrading Engine or a host
separately will cause unwarranted firewall related modifications (more
specifically, custom rules/iptables' service remain intact). Explicitly
installing/re-installing hosts in compatible clusters via an upgraded
Engine is the only way to override custom rules/enabling firewalld's
service over iptables' service (barring manual alterations to
vdsm.conf...). We're also going to warn users during engine-setup and add
alerts during host (re)installations.
I would not pursue this direction until we are convinced using Ansible is
not a better, easier, more user-friendly approach.
Ansible can do all the checks and understand if need to keep iptables or
switch to firewalld.
Y.
On Thu, Apr 6, 2017 at 2:56 PM, Leon Goldberg <lgoldber(a)redhat.com> wrote:
> Hey,
>
> There seems to be a growing consensus towards moving custom rules out of
> Engine. It is believed that Engine shouldn't have assumed the role of a
> centralized firewall management system in he first place, and that using a
> proper 3rd party solution will be both favorable to the users (allowing
> better functionality and usability) and will allow us to simplify our
> firewall deployment process.
>
> Considering we don't have to manage custom rules, a host will be able to
> derive all the information regarding its firewalld services from its own
> configuration. Consequently, option #2 becomes a forerunner with Engine's
> involvement being even further diminished.
>
>
>
> On Sun, Mar 26, 2017 at 1:33 PM, Leon Goldberg <lgoldber(a)redhat.com>
> wrote:
>
>>
>> Hey,
>>
>> We're looking to migrate from iptables to firewalld. We came up with a
>> couple of possible approaches we'd like opinions on. I'll list the
options
>> first, and will
>>
>> 1) Replicate existing flow:
>>
>> As of date, iptable rules are inserted in the database via SQL config
>> files. During host deployment, VdsDeployIptablesUnit adds the required
>> rules (based on cluster/firewall configuration) to the deployment
>> configuration, en route to being deployed on the host via otopi and its
>> iptables plugin.
>>
>> Pros:
>>
>> - Reuse of existing infrastructure.
>>
>> Cons:
>>
>> - Current infrastructure is overly complex...
>> - Many of the required services are provided by firewalld. Rewriting
>> them is wasteful; specifying them (instead of providing actual service .xml
>> content) will require adaptations on both (engine/host) sides. More on that
>> later.
>>
>>
>> 2) Host side based configuration:
>>
>> Essentially, all the required logic (aforementioned cluster/firewall
>> configuration) to determine if/how firewalld should be deployed could be
>> passed on to the host via ohd. Vdsm could take on the responsibility of
>> examining the relevant configuration, and then creating and/or adding the
>> required services (using vdsm.conf and vdsm-tool).
>>
>> Pros:
>>
>> - Engine side involvement is greatly diminished.
>> - Simple(r).
>>
>> Cons:
>>
>> - Custom services/rules capabilities will have to be rethought and
>> re-implemented (current infrastructure supports custom iptables rules by
>> being specified in the SQL config file).
>>
>>
>> 3) Some other hybrid approach:
>>
>> If we're able to guarantee all the required firewalld services are
>> statically provided one way or the other, the current procedure could be
>> replicated and be made more simpler. Instead of providing xml content in
>> the form of strings, service names could be supplied. The responsibility of
>> actual service deployment becomes easier, and could be left to otopi (with
>> the appropriate modifications) or switched over to vdsm.
>>
>> --
>>
>> Regardless, usage of statically provided vs. dynamically created
>> services remains an open question. I think we'd like to avoid implementing
>> logic that ask whether some service is provided (and then write it if it
>> isn't...), and so choosing between the dynamic and static approaches is
>> also needed. Using the static approach, guaranteeing *all* services are
>> provided will be required.
>>
>> I do believe guaranteeing the presence of all required services is worth
>> it, however custom services aren't going to be naively compatible, and
>> we'll still have to use similar mechanism as described in #1 (service
>> string -> .xml -> addition of service name to active zone).
>>
>>
>> Your thoughts are welcome.
>>
>> Thanks,
>> Leon
>>
>>
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2576
days inactive
2587
days old
37 comments
10 participants
participants (10)
-
Dan Kenigsberg -
Edward Haas -
Leon Goldberg -
Martin Perina -
Martin Sivak -
Oved Ourfali -
Sven Kieske -
Yaniv Dary -
Yaniv Kaul -
Yedidyah Bar David