8:26 a.m.
Hi,
I'm going to write a provider for firewall as a part of OpenLMI project.
My current plan is to use FirewallD (via DBus) as a backend for this provider.
I'm now facing the most difficult part: Model.
As far as I know there is no DMTF profile for firewall. There are few classes
in the CIM schema that seem to describe some kind of firewall (see page 11 of
[1]), but they're not applicable to describe neither iptables nor firewalld (I
couldn't figure out how to model rule ordering in chain with given classes).
I can see a couple of options what to do with this problem:
1) Model FirewallD API closely
Using same model as underlying service has one big advantage - it doesn't
disrupt local configuration - one can use both remote and local API (command
line, GUI) simultaneously, and one big disadvantage - model won't be
compatible with other firewall implementations.
2) Reuse as much of existing model (CIM classes) as possible
We could take what's already there and alter it to suit our needs, but I'm
afraid that the result will be quite ugly. And it still won't be compatible
with others.
3) Try to create new model that would be (more) universal
It might be possible to create a model that would cover some common
functionality of typical firewall on normal linux box (not some specialized
firewall device), but it would be a lot of work and still it wouldn't cover
advanced features of all firewall solutions out there.
4) Some other approach
Feel free to suggest something.
Personally, I would go with 1). There is no model that would bring
compatibility with other systems, so IMHO it would be best to create model
that will be simple and understandable and it's usage won't disrupt other
usage (cmdline, gui, ...).
Let me know what do you think. Or at least post some usecases that the
provider must/should cover.
Thank you.
Radek Novacek
[1] http://dmtf.org/sites/default/files/cim/cim_schema_v2390/Visio-CIM_Networ...
8:41 a.m.
On 01/30/2014 03:26 PM, Radek Novacek wrote:
Hi,
I'm going to write a provider for firewall as a part of OpenLMI project.
My current plan is to use FirewallD (via DBus) as a backend for this provider.
I'm now facing the most difficult part: Model.
As far as I know there is no DMTF profile for firewall. There are few classes
in the CIM schema that seem to describe some kind of firewall (see page 11 of
[1]), but they're not applicable to describe neither iptables nor firewalld (I
couldn't figure out how to model rule ordering in chain with given classes).
I can see a couple of options what to do with this problem:
1) Model FirewallD API closely
Using same model as underlying service has one big advantage - it doesn't
disrupt local configuration - one can use both remote and local API (command
line, GUI) simultaneously, and one big disadvantage - model won't be
compatible with other firewall implementations.
2) Reuse as much of existing model (CIM classes) as possible
We could take what's already there and alter it to suit our needs, but I'm
afraid that the result will be quite ugly. And it still won't be compatible
with others.
3) Try to create new model that would be (more) universal
It might be possible to create a model that would cover some common
functionality of typical firewall on normal linux box (not some specialized
firewall device), but it would be a lot of work and still it wouldn't cover
advanced features of all firewall solutions out there.
4) Some other approach
Feel free to suggest something.
Personally, I would go with 1). There is no model that would bring
compatibility with other systems, so IMHO it would be best to create model
that will be simple and understandable and it's usage won't disrupt other
usage (cmdline, gui, ...).
Yes, 1) is my favorite too. IMHO there is no CIM firewall management
implementation we know about and we want to be compatible with. So let's
model it around _our_ firewall mgmt tools, which is currently firewalld.
Jan
9:21 a.m.
On Thu, 2014-01-30 at 15:41 +0100, Jan Safranek wrote:
On 01/30/2014 03:26 PM, Radek Novacek wrote:
> Hi,
>
> I'm going to write a provider for firewall as a part of OpenLMI project.
>
> My current plan is to use FirewallD (via DBus) as a backend for this provider.
>
>
> I'm now facing the most difficult part: Model.
>
> As far as I know there is no DMTF profile for firewall. There are few classes
> in the CIM schema that seem to describe some kind of firewall (see page 11 of
> [1]), but they're not applicable to describe neither iptables nor firewalld (I
> couldn't figure out how to model rule ordering in chain with given classes).
>
>
> I can see a couple of options what to do with this problem:
>
> 1) Model FirewallD API closely
>
> Using same model as underlying service has one big advantage - it doesn't
> disrupt local configuration - one can use both remote and local API (command
> line, GUI) simultaneously, and one big disadvantage - model won't be
> compatible with other firewall implementations.
>
>
> 2) Reuse as much of existing model (CIM classes) as possible
>
> We could take what's already there and alter it to suit our needs, but I'm
> afraid that the result will be quite ugly. And it still won't be compatible
> with others.
>
>
> 3) Try to create new model that would be (more) universal
>
> It might be possible to create a model that would cover some common
> functionality of typical firewall on normal linux box (not some specialized
> firewall device), but it would be a lot of work and still it wouldn't cover
> advanced features of all firewall solutions out there.
>
>
> 4) Some other approach
>
> Feel free to suggest something.
>
>
> Personally, I would go with 1). There is no model that would bring
> compatibility with other systems, so IMHO it would be best to create model
> that will be simple and understandable and it's usage won't disrupt other
> usage (cmdline, gui, ...).
Yes, 1) is my favorite too. IMHO there is no CIM firewall management
implementation we know about and we want to be compatible with. So let's
model it around _our_ firewall mgmt tools, which is currently firewalld.
This
approach has Product Management approval.
Russ
Jan
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
6:21 a.m.
On Thu, 30 Jan 2014 15:41:47 +0100
Jan Safranek <jsafrane(a)redhat.com> wrote:
On 01/30/2014 03:26 PM, Radek Novacek wrote:
<...>
> 1) Model FirewallD API closely
>
> Using same model as underlying service has one big advantage - it doesn't
> disrupt local configuration - one can use both remote and local API
> (command line, GUI) simultaneously, and one big disadvantage - model
> won't be compatible with other firewall implementations.
<...>
> Personally, I would go with 1). There is no model that would
bring
> compatibility with other systems, so IMHO it would be best to create
> model that will be simple and understandable and it's usage won't disrupt
> other usage (cmdline, gui, ...).
Yes, 1) is my favorite too. IMHO there is no CIM firewall management
implementation we know about and we want to be compatible with. So let's
model it around _our_ firewall mgmt tools, which is currently firewalld.
Firewalld is (still) very Fedora-specific tool, whereas a firewall management
is quite universally demanded feature. Even though it's probably a bit
premature consideration: we may make it harder for OpenLMI to become part of
other distributions.
But since the firewall provider is going to be difficult enough anyway I
don't have that strong opinion on reflecting the firewalld API in the
model.
Regards,
--
Tomáš Smetana
Platform Engineering, Red Hat
8:44 a.m.
On Jan 31, 2014, at 1:21 PM, Tomáš Smetana
<tsmetana(a)redhat.com> wrote:
On Thu, 30 Jan 2014 15:41:47 +0100
Jan Safranek <jsafrane(a)redhat.com> wrote:
> On 01/30/2014 03:26 PM, Radek Novacek wrote:
<...>
>> 1) Model FirewallD API closely
>>
>> Using same model as underlying service has one big advantage - it doesn't
>> disrupt local configuration - one can use both remote and local API
>> (command line, GUI) simultaneously, and one big disadvantage - model
>> won't be compatible with other firewall implementations.
<...>
>> Personally, I would go with 1). There is no model that would bring
>> compatibility with other systems, so IMHO it would be best to create
>> model that will be simple and understandable and it's usage won't
disrupt
>> other usage (cmdline, gui, ...).
>
> Yes, 1) is my favorite too. IMHO there is no CIM firewall management
> implementation we know about and we want to be compatible with. So let's
> model it around _our_ firewall mgmt tools, which is currently firewalld.
Firewalld is (still) very Fedora-specific tool, whereas a firewall management
is quite universally demanded feature. Even though it's probably a bit
premature consideration: we may make it harder for OpenLMI to become part of
other distributions.
But since the firewall provider is going to be difficult enough anyway I
don't have that strong opinion on reflecting the firewalld API in the
model.
My recommendation is to follow 1) but name it the FirewallD provider instead of simply the
firewall provider. It makes it very clear what it supports while also offering us the
ability to build a more generic Firewall provider in the future (one that might be a
wrapper for distro-specific tools).
Also, Russ: can you look into whether any of Cisco, et al have a CIM interface to their
firewall/router appliances? We may want to see if a de facto standard already exists.
8:56 a.m.
On Fri, 2014-01-31 at 09:44 -0500, Stephen Gallagher wrote:
> On Jan 31, 2014, at 1:21 PM, Tomáš Smetana <tsmetana(a)redhat.com> wrote:
>
> On Thu, 30 Jan 2014 15:41:47 +0100
> Jan Safranek <jsafrane(a)redhat.com> wrote:
>
>> On 01/30/2014 03:26 PM, Radek Novacek wrote:
>
> <...>
>
>>> 1) Model FirewallD API closely
>>>
>>> Using same model as underlying service has one big advantage - it
doesn't
>>> disrupt local configuration - one can use both remote and local API
>>> (command line, GUI) simultaneously, and one big disadvantage - model
>>> won't be compatible with other firewall implementations.
>
> <...>
>
>>> Personally, I would go with 1). There is no model that would bring
>>> compatibility with other systems, so IMHO it would be best to create
>>> model that will be simple and understandable and it's usage won't
disrupt
>>> other usage (cmdline, gui, ...).
>>
>> Yes, 1) is my favorite too. IMHO there is no CIM firewall management
>> implementation we know about and we want to be compatible with. So let's
>> model it around _our_ firewall mgmt tools, which is currently firewalld.
>
> Firewalld is (still) very Fedora-specific tool, whereas a firewall management
> is quite universally demanded feature. Even though it's probably a bit
> premature consideration: we may make it harder for OpenLMI to become part of
> other distributions.
>
> But since the firewall provider is going to be difficult enough anyway I
> don't have that strong opinion on reflecting the firewalld API in the
> model.
>
>
My recommendation is to follow 1) but name it the FirewallD provider instead of simply
the firewall provider. It makes it very clear what it supports while also offering us the
ability to build a more generic Firewall provider in the future (one that might be a
wrapper for distro-specific tools).
Good suggestion - any objections to doing this?
Also, Russ: can you look into whether any of Cisco, et al have a CIM interface to their
firewall/router appliances? We may want to see if a de facto standard already exists.
Doubtful, but we can check.
_______________________________________________
openlmi-devel mailing list
openlmi-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
8:54 a.m.
On Fri, 2014-01-31 at 13:21 +0100, Tomáš Smetana wrote:
On Thu, 30 Jan 2014 15:41:47 +0100
Jan Safranek <jsafrane(a)redhat.com> wrote:
> On 01/30/2014 03:26 PM, Radek Novacek wrote:
<...>
> > 1) Model FirewallD API closely
> >
> > Using same model as underlying service has one big advantage - it doesn't
> > disrupt local configuration - one can use both remote and local API
> > (command line, GUI) simultaneously, and one big disadvantage - model
> > won't be compatible with other firewall implementations.
<...>
> > Personally, I would go with 1). There is no model that would bring
> > compatibility with other systems, so IMHO it would be best to create
> > model that will be simple and understandable and it's usage won't
disrupt
> > other usage (cmdline, gui, ...).
>
> Yes, 1) is my favorite too. IMHO there is no CIM firewall management
> implementation we know about and we want to be compatible with. So let's
> model it around _our_ firewall mgmt tools, which is currently firewalld.
Firewalld is (still) very Fedora-specific tool, whereas a firewall management
is quite universally demanded feature. Even though it's probably a bit
premature consideration: we may make it harder for OpenLMI to become part of
other distributions.
Anything preventing other distros from adopting firewalld?
We've already
got dependencies on underlying tools, such as Network Manager and
Blivet, which are at least somewhat distro dependent.
I recognize that firewall is different in that this is the first time we
have to write our own model, rather than use a CIM model. Can we make
the firewall model "similar" to the rest of the models? Hopefully not as
complex as the DMTF models, but follow the general conventions, look and
feel, and behavior as the rest of the system?
This might make the firewall model a bit more complex than it would
otherwise be, but having it cleanly integrate with the rest of the
system (from a design perspective) would be good.
But since the firewall provider is going to be difficult enough anyway I
don't have that strong opinion on reflecting the firewalld API in the
model.
Regards,
3748
days inactive
3749
days old
openlmi-devel@lists.fedorahosted.org
6 comments
5 participants
participants (5)
-
Jan Safranek -
Radek Novacek -
Russell Doty -
Stephen Gallagher -
Tomáš Smetana