defining firewalld services

[Rex Dieter]

I'm looking into providing a predefined firewalld service definition for 
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547

Looks like it's as easy as dropping an xml snippet into 
/usr/lib/firewalld/services/

I'm also noticing currently that the only package besides fallwalld itself 
doing this is cockpit, which includes a %post scriptlet:

# firewalld only partially picks up changes to its services files 
# without this
test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true


Is this the recommended approach?  If so, I'll follow this lead, and maybe 
start work on drafting some packaging guidelines.

-- Rex

[Stef Walter]

On 03.07.2014 15:39, Rex Dieter wrote:
>  I'm looking into providing a predefined firewalld service
> definition for 
>  kde-connect, per
>  https://bugzilla.redhat.com/show_bug.cgi?id=1115547
>  
>  Looks like it's as easy as dropping an xml snippet into 
>  /usr/lib/firewalld/services/
>  
>  I'm also noticing currently that the only package besides fallwalld itself 
>  doing this is cockpit, which includes a %post scriptlet:
>  
>  # firewalld only partially picks up changes to its services files 
>  # without this
>  test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true
>  
>  
>  Is this the recommended approach?  If so, I'll follow this lead, and maybe 
>  start work on drafting some packaging guidelines. 
Thomas Woerner would be the one to work out those guidelines.

But to explain ... apparently there are two firewalld "environments".
When you install a service file it only affects the installed
environment (used after a reboot) and not the current "runtime environment".

This means that a user can't immediately use your service definition in
a command like:

$ firewall-cmd --add-service=cockpit

The command:

$ firewall-cmd --reload

... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl daemon-reload'.

Stef

[Thomas Woerner]

On 07/03/2014 09:32 PM, Stef Walter wrote:
>  On 03.07.2014 15:39, Rex Dieter wrote:
> > I'm looking into providing a predefined firewalld service definition for
> > kde-connect, per
> > https://bugzilla.redhat.com/show_bug.cgi?id=1115547
> >
> > Looks like it's as easy as dropping an xml snippet into
> > /usr/lib/firewalld/services/
> >
> > I'm also noticing currently that the only package besides fallwalld itself
> > doing this is cockpit, which includes a %post scriptlet:
> >
> > # firewalld only partially picks up changes to its services files
> > # without this
> > test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true
> >
> >
> > Is this the recommended approach?  If so, I'll follow this lead, and maybe
> > start work on drafting some packaging guidelines.
>
>  Thomas Woerner would be the one to work out those guidelines.
>  
Yes.

>  But to explain ... apparently there are two firewalld
> "environments".
>  When you install a service file it only affects the installed
>  environment (used after a reboot) and not the current "runtime environment".
>
>  This means that a user can't immediately use your service definition in
>  a command like:
>
>  $ firewall-cmd --add-service=cockpit
>
>  The command:
>
>  $ firewall-cmd --reload
>
>  ... makes newly installed service files available in the runtime
>  environment. I guess this is sorta analogous to 'systemctl daemon-reload'.
>  
Newly added services and zones are available in the permanent 
environment of firewalld, where they can be used with the UI and command 
line tools.

To have a newly added service or zone in the runtime environment it is 
needed to reload firewalld: firewall-cmd --reload or systemctl reload 
firewalld.service.

>  Stef
>  
Thomas

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/04/2014 07:36 AM, Thomas Woerner wrote:
>  On 07/03/2014 09:32 PM, Stef Walter wrote:
> > On 03.07.2014 15:39, Rex Dieter wrote:
> >> I'm looking into providing a predefined firewalld service
> >> definition for kde-connect, per 
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1115547
> >> 
> >> Looks like it's as easy as dropping an xml snippet into 
> >> /usr/lib/firewalld/services/
> >> 
> >> I'm also noticing currently that the only package besides
> >> fallwalld itself doing this is cockpit, which includes a %post
> >> scriptlet:
> >> 
> >> # firewalld only partially picks up changes to its services
> >> files # without this test -f %{_bindir}/firewall-cmd &&
> >> firewall-cmd --reload --quiet || true
> >> 
> >> 
> >> Is this the recommended approach?  If so, I'll follow this
> >> lead, and maybe start work on drafting some packaging
> >> guidelines.
> > 
> > Thomas Woerner would be the one to work out those guidelines.
> > 
>  Yes.
>  
> > But to explain ... apparently there are two firewalld
> > "environments". When you install a service file it only affects
> > the installed environment (used after a reboot) and not the
> > current "runtime environment".
> > 
> > This means that a user can't immediately use your service
> > definition in a command like:
> > 
> > $ firewall-cmd --add-service=cockpit
> > 
> > The command:
> > 
> > $ firewall-cmd --reload
> > 
> > ... makes newly installed service files available in the runtime 
> > environment. I guess this is sorta analogous to 'systemctl 
> > daemon-reload'.
> > 
>  Newly added services and zones are available in the permanent 
>  environment of firewalld, where they can be used with the UI and
>  command line tools.
>  
>  To have a newly added service or zone in the runtime environment it
>  is needed to reload firewalld: firewall-cmd --reload or systemctl
>  reload firewalld.service.
>   

Thomas, the real question here is this: If a package wants to install
(and maintain) its own set of firewalld service definitions, is the
approach Stef took the best one? If so, we should submit a Packaging
Guidelines edit to the FPC and get this codified where others can find it.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO6mLwACgkQeiVVYja6o6MnWgCfT9Nle/gfxrmsBu13mIS03f4J
> n+sAn2oMz8nlbBukQ1Y+/R9VkrKV9JO7
> =9yrD
> -----END PGP SIGNATURE-----

[Thomas Woerner]

On 07/07/2014 02:55 PM, Stephen Gallagher wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 07/04/2014 07:36 AM, Thomas Woerner wrote:
> > On 07/03/2014 09:32 PM, Stef Walter wrote:
> >> On 03.07.2014 15:39, Rex Dieter wrote:
> >>> I'm looking into providing a predefined firewalld service
> >>> definition for kde-connect, per
> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1115547
> >>>
> >>> Looks like it's as easy as dropping an xml snippet into
> >>> /usr/lib/firewalld/services/
> >>>
> >>> I'm also noticing currently that the only package besides
> >>> fallwalld itself doing this is cockpit, which includes a %post
> >>> scriptlet:
> >>>
> >>> # firewalld only partially picks up changes to its services
> >>> files # without this test -f %{_bindir}/firewall-cmd &&
> >>> firewall-cmd --reload --quiet || true
> >>>
> >>>
> >>> Is this the recommended approach?  If so, I'll follow this
> >>> lead, and maybe start work on drafting some packaging
> >>> guidelines.
> >>
> >> Thomas Woerner would be the one to work out those guidelines.
> >>
> > Yes.
> >
> >> But to explain ... apparently there are two firewalld
> >> "environments". When you install a service file it only affects
> >> the installed environment (used after a reboot) and not the
> >> current "runtime environment".
> >>
> >> This means that a user can't immediately use your service
> >> definition in a command like:
> >>
> >> $ firewall-cmd --add-service=cockpit
> >>
> >> The command:
> >>
> >> $ firewall-cmd --reload
> >>
> >> ... makes newly installed service files available in the runtime
> >> environment. I guess this is sorta analogous to 'systemctl
> >> daemon-reload'.
> >>
> > Newly added services and zones are available in the permanent
> > environment of firewalld, where they can be used with the UI and
> > command line tools.
> >
> > To have a newly added service or zone in the runtime environment it
> > is needed to reload firewalld: firewall-cmd --reload or systemctl
> > reload firewalld.service.
> >
>
>
>  Thomas, the real question here is this: If a package wants to install
>  (and maintain) its own set of firewalld service definitions, is the
>  approach Stef took the best one? If so, we should submit a Packaging
>  Guidelines edit to the FPC and get this codified where others can find it.
>  
Yes, this is the best approach right now.

I can write some documentatoin for this. What is the proper way to get 
it in the Packaging guidelines?

> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >  iEYEARECAAYFAlO6mLwACgkQeiVVYja6o6MnWgCfT9Nle/gfxrmsBu13mIS03f4J
> >  n+sAn2oMz8nlbBukQ1Y+/R9VkrKV9JO7
> >  =9yrD
> >  -----END PGP SIGNATURE----- 
>

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/07/2014 01:03 PM, Thomas Woerner wrote:
>  On 07/07/2014 02:55 PM, Stephen Gallagher wrote: On 07/04/2014
>  07:36 AM, Thomas Woerner wrote:
> >>> On 07/03/2014 09:32 PM, Stef Walter wrote:
> >>>> On 03.07.2014 15:39, Rex Dieter wrote:
> >>>>> I'm looking into providing a predefined firewalld
> >>>>> service definition for kde-connect, per 
> >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1115547
> >>>>> 
> >>>>> Looks like it's as easy as dropping an xml snippet into 
> >>>>> /usr/lib/firewalld/services/
> >>>>> 
> >>>>> I'm also noticing currently that the only package
> >>>>> besides fallwalld itself doing this is cockpit, which
> >>>>> includes a %post scriptlet:
> >>>>> 
> >>>>> # firewalld only partially picks up changes to its
> >>>>> services files # without this test -f
> >>>>> %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet
> >>>>> || true
> >>>>> 
> >>>>> 
> >>>>> Is this the recommended approach?  If so, I'll follow
> >>>>> this lead, and maybe start work on drafting some
> >>>>> packaging guidelines.
> >>>> 
> >>>> Thomas Woerner would be the one to work out those
> >>>> guidelines.
> >>>> 
> >>> Yes.
> >>> 
> >>>> But to explain ... apparently there are two firewalld 
> >>>> "environments". When you install a service file it only
> >>>> affects the installed environment (used after a reboot) and
> >>>> not the current "runtime environment".
> >>>> 
> >>>> This means that a user can't immediately use your service 
> >>>> definition in a command like:
> >>>> 
> >>>> $ firewall-cmd --add-service=cockpit
> >>>> 
> >>>> The command:
> >>>> 
> >>>> $ firewall-cmd --reload
> >>>> 
> >>>> ... makes newly installed service files available in the
> >>>> runtime environment. I guess this is sorta analogous to
> >>>> 'systemctl daemon-reload'.
> >>>> 
> >>> Newly added services and zones are available in the
> >>> permanent environment of firewalld, where they can be used
> >>> with the UI and command line tools.
> >>> 
> >>> To have a newly added service or zone in the runtime
> >>> environment it is needed to reload firewalld: firewall-cmd
> >>> --reload or systemctl reload firewalld.service.
> >>> 
>  
>  
>  Thomas, the real question here is this: If a package wants to
>  install (and maintain) its own set of firewalld service
>  definitions, is the approach Stef took the best one? If so, we
>  should submit a Packaging Guidelines edit to the FPC and get this
>  codified where others can find it.
>  
> > Yes, this is the best approach right now.
>  
> > I can write some documentatoin for this. What is the proper way
> > to get it in the Packaging guidelines?
>   



Create a draft with an example on the Wiki and then send an email to
packaging(a)lists.fedoraproject.org to ask them to review it.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO63GAACgkQeiVVYja6o6OF9QCffdDLUE2dUtaQU7vQjGVvVZsx
> xKQAoIaUi5ym7iRpxF4eBkx16BqGCrqn
> =xVgQ
> -----END PGP SIGNATURE-----

[Ian Pilcher]

On 07/07/2014 12:03 PM, Thomas Woerner wrote:
>  On 07/07/2014 02:55 PM, Stephen Gallagher wrote:
> > Thomas, the real question here is this: If a package wants to install
> > (and maintain) its own set of firewalld service definitions, is the
> > approach Stef took the best one? If so, we should submit a Packaging
> > Guidelines edit to the FPC and get this codified where others can find
> > it.
> >
>  Yes, this is the best approach right now. 
Hmm.  If I've made a temporary change to my firewall settings, I might
be a bit annoyed if an (apparently unrelated) package installation
caused the configuration to revert to the permanent configuration.

Is there not a more specific command that adds the service definition to
the current environment without a full reload?

-- 
========================================================================
Ian Pilcher                                         arequipeno(a)gmail.com
           Sent from the cloud -- where it's already tomorrow
========================================================================

[Thomas Woerner]

On 07/08/2014 01:20 AM, Ian Pilcher wrote:
>  On 07/07/2014 12:03 PM, Thomas Woerner wrote:
> > On 07/07/2014 02:55 PM, Stephen Gallagher wrote:
> >> Thomas, the real question here is this: If a package wants to install
> >> (and maintain) its own set of firewalld service definitions, is the
> >> approach Stef took the best one? If so, we should submit a Packaging
> >> Guidelines edit to the FPC and get this codified where others can find
> >> it.
> >>
> > Yes, this is the best approach right now.
>
>  Hmm.  If I've made a temporary change to my firewall settings, I might
>  be a bit annoyed if an (apparently unrelated) package installation
>  caused the configuration to revert to the permanent configuration.
>
>  Is there not a more specific command that adds the service definition to
>  the current environment without a full reload?
>  
No, there is no command for this. Changes to (also addition and removal 
of) services are done in the permanent environment only to have a 
consistent state in the runtime environment. I have done this because 
the adoption of changes to zone, services etc. might lead into problems.

Please think of these examples:

- A service definition has been removed.
- A service definition has been changed in an incompatible way: 
Different port number or range.

The adoption of a changed port number for a service should be done in 
the service and in firewalld at the same time. There is no interface for 
this.

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 03, 2014 at 08:39:08AM -0500, Rex Dieter wrote:
>  Looks like it's as easy as dropping an xml snippet into 
>  /usr/lib/firewalld/services/
>  
>  I'm also noticing currently that the only package besides fallwalld itself 
>  doing this is cockpit, which includes a %post scriptlet:
>  
>  # firewalld only partially picks up changes to its services files 
>  # without this
>  test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true 
Can we wrap this in a macro provided by firewalld.rpm? This will make
updates later on easier.

Zbyszek

[Jiri Popelka]

On 07/16/2014 04:04 PM, Zbigniew Jędrzejewski-Szmek wrote:
>  On Thu, Jul 03, 2014 at 08:39:08AM -0500, Rex Dieter wrote:
> > Looks like it's as easy as dropping an xml snippet into
> > /usr/lib/firewalld/services/
> >
> > I'm also noticing currently that the only package besides fallwalld itself
> > doing this is cockpit, which includes a %post scriptlet:
> >
> > # firewalld only partially picks up changes to its services files
> > # without this
> > test -f %{_bindir}/firewall-cmd && firewall-cmd --reload --quiet || true
>
>  Can we wrap this in a macro provided by firewalld.rpm? This will make
>  updates later on easier. 
Added upstream:
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=9200667fd6f43b...

Will be in next firewalld release, thanks for the idea.

--
Jiri

[Jiri Popelka]

On 07/24/2014 04:35 PM, Jiri Popelka wrote:
>  Added upstream:
>
> https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=9200667fd6f43b...
and :-)
https://git.fedorahosted.org/cgit/firewalld.git/commit/?id=445a1475a671ff...

--
Jiri