2014-03-06 22:43 GMT+01:00 Stephen Gallagher <sgallagh@redhat.com>:
On 03/06/2014 04:28 PM, Reindl Harald wrote:
> Am 06.03.2014 22:13, schrieb Miloslav Trmač:
>> 2014-03-06 22:03 GMT+01:00 Simo Sorce <simo@redhat.com
>> <mailto:simo@redhat.com>>: Sorry I do not understand what you are
>> saying here.
>>
>> $ fedora-role-deploy postgresql # Huh, it is refusing
>> connections?
>> # Ah, firewall...
>> $ fedora-role-deploy --open-firewall-ports potgresql
>> # That's how it is done in Fedora, then.  Good to know.
<snip>
So I have no problems at all with Miloslav's suggestion that we just
require an additional argument (which will have to be translated to
the API layer in a sensible way) as part of the configuration.

So the above was confusing, that's not what I wanted to suggest.  The --open-firewall-ports was to be basically "firewall-cmd --permanent --add-service=postgresql", i.e. change the firewall, not a re-deploy of the role.  (Though it could have actually been a re-deploy, given our earlier conversation about cattle-like deployment.)
 
Of course, the question becomes one of granularity: I doubt that
- --open-firewall-ports is necessarily sufficient. In the case of
multi-homed servers, you still may want to have the service visible
only on a subset of interfaces. I'd suggest
- --open-firewall-ports[=iface1,...] as a reasonable compromise (and
again translated acceptably into the Role config API).

Wouldn't it be simplest to just use (firewall-cmd --permanent --zone=$my_zone ...) directly?  We could of course build a "fedora-role-firewall" facade over it if necessary, but firewalld already has all the necessary functionality AFAICS.

And finally, the config API must also be capable of changing the set
of open interfaces (such as when local testing has passed and the
admin now wants to expose the services publicly).
That's a firewalld command away, as well.
    Mirek