#973 "raising warning flag on firewalld-default feature"
Closed None Opened 11 years ago by mitr.

Matthew Miller has raised some concerns about firewalld on fedora-devel. Do we want to revisit this?

(I probably won't have time to take a detailed look before tomorrow's meeting.)


I've talked to Thomas, and my concerns are somewhat relaxed. Primarily, I think if we:

  1. Have a really strong test day where people shake out any remaining bugs
  2. Have a lot more friendly, user-facing documentation (in progress)
  3. Guarantee that that dependency chains are fixed so that firewalld doesn't pull X into @core [https://bugzilla.redhat.com/show_bug.cgi?id=874378 Bug 874378]
  4. Identify and fix or heavily document some key bugs (eg [https://bugzilla.redhat.com/show_bug.cgi?id=821938 Bug 821938], but there's possibly a number of others, including new ones discovered at test day)

we can go ahead and take the risk.

I would also very much like to see

  1. A medium-term plan for switching the service to be systemd/dbus activated and to exit when there's no activity [https://bugzilla.redhat.com/show_bug.cgi?id=876683 Bug 876683]. (I'm okay with this not being a blocker as long as there's at least a rudimentary plan.)
  2. A way for firewalld to do the initial config and get out of the way [https://bugzilla.redhat.com/show_bug.cgi?id=878889 Bug 878889] (This is probably not an F18 blocker; I think we're fine with shipping initscripts in parallel for the next couple of releases.)
  3. Firewalld needs to be able to save state when restarted or shut down (not just reloaded), and ideally, since this is a core security service, on crash as well. (I think this is an F18 blocker but as long as there's a plan for the future I'm willing to defer.)
  4. Usability work on the GUI tool. [https://bugzilla.redhat.com/show_bug.cgi?id=870979 Bug 876683], [https://bugzilla.redhat.com/show_bug.cgi?id=876661 Bug 876661] (Can always be improved later, but will reduce shock to users if it's closer to perfect on the first pass.)
  5. Better --help for the command line tool (and possibly user interface redesign) [https://bugzilla.redhat.com/show_bug.cgi?id=876394 876394] (Again, not a blocker, but we don't want sysadmins' heads to explode, and throwing pages of BNF at them will not be popular.)

On the usability part, there's already some good progress -- see the bugs. A full design / usability review might be a good F19 feature.

We have a network test week planned already (see https://fedoraproject.org/wiki/QA/Fedora_18_test_days) with a firewalld test day. We can add more tests according to the needs.

More documentation is in the works. Will work with Matthew and Eric H. Christensen to complete the documentation. Time frame: this month.

I will help to work on [https://bugzilla.redhat.com/show_bug.cgi?id=855346 Bug #855346] (to fix [https://bugzilla.redhat.com/show_bug.cgi?id=874378 Bug 874378]) as soon as I finished documentation and the work on firewall-applet and firewall-config ([https://bugzilla.redhat.com/show_bug.cgi?id=876661 Bug 876661]) and firewall-cmd ([https://bugzilla.redhat.com/show_bug.cgi?id=876394 Bug 876394]). Time frame: this month, at least before network test week

For [https://bugzilla.redhat.com/show_bug.cgi?id=821938 Bug 821938]: This will be documented. This is a result of a design request of the libvirt team.

For [https://bugzilla.redhat.com/show_bug.cgi?id=876683 Bug 876683]: This is a long term RFE and will not be addressed for F-18, see comment in bug.

For [https://bugzilla.redhat.com/show_bug.cgi?id=878889 Bug 878889]: Replacement for iptables and ip6tables static only firewall services. A mechanism to replace these services is planned for F-19.

No further FESCo action needed it seems.

Replying to [comment:3 twoerner]:

For [https://bugzilla.redhat.com/show_bug.cgi?id=821938 Bug 821938]: This will be documented. This is a result of a design request of the libvirt team.

I had glossed over this comment before, but on re-reading, I'm concerned. Is the documentation here going to be "FirewallD requires Network Manager"? This has some deeper implications than it might seem, because since Anaconda uses FirewallD to configure the initial firewall, it's actually not just default but ''required'', and that means that Network Manager ''also'' goes from default to mandatory, which is not okay, because it's not ready for that in many critical non-desktop use cases. (There's progress, but that next step is a feature all of its own.)

No offense to firewalld intended, but I would like somehow for systems without it to remain explicitly supported. Many people (myself included) want to create firewall configurations that this tool is never going to handle well, and with something as core as firewalling we don't want to start building up dependencies all over the place requiring firewalld. This is also hand-in-hand related to the NetworkManager comment because it is also not ready for many server use cases. Just recently, we've been configuring and installing ARM architectural models and emulators that have fancy bridging requirements NM would have no hope of handling, and firewalld would just make worse. So, my comment is to be careful before going down a rabbit hole from which it is hard to escape.

Separately, I would note that the default experience for enabling even inbound ssh (which I thought used to be default allowed on the local network, if the service was enabled) was terrible. I followed the wiki instructions (which were wrong), then the client hung, then I disabled and stopped firewalld, but it left various iptables state around, then I had to clean it up manually, etc. All in all, it wasted a good 30 minutes of my time making my life "easier" and in the process making a default Fedora install yet another level more complex.

Replying to [comment:5 mattdm]:

Replying to [comment:3 twoerner]:

For [https://bugzilla.redhat.com/show_bug.cgi?id=821938 Bug 821938]: This will be documented. This is a result of a design request of the libvirt team.

I had glossed over this comment before, but on re-reading, I'm concerned. Is the documentation here going to be "FirewallD requires Network Manager"? This has some deeper implications than it might seem, because since Anaconda uses FirewallD to configure the initial firewall, it's actually not just default but ''required'', and that means that Network Manager ''also'' goes from default to mandatory, which is not okay, because it's not ready for that in many critical non-desktop use cases. (There's progress, but that next step is a feature all of its own.)

FirewallD is not requiring NetworkManager, but there are some things only NetworkManager can do. For example to inform other services about activation and deactivation of network connections and also about interface renames. Renaming of interfaces is for example a big problem for netfilter based static firewalls, they do not and can not adapt automatically.

Replying to [comment:6 jcm]:

No offense to firewalld intended, but I would like somehow for systems without it to remain explicitly supported. Many people (myself included) want to create firewall configurations that this tool is never going to handle well, and with something as core as firewalling we don't want to start building up dependencies all over the place requiring firewalld. This is also hand-in-hand related to the NetworkManager comment because it is also not ready for many server use cases. Just recently, we've been configuring and installing ARM architectural models and emulators that have fancy bridging requirements NM would have no hope of handling, and firewalld would just make worse. So, my comment is to be careful before going down a rabbit hole from which it is hard to escape.

Separately, I would note that the default experience for enabling even inbound ssh (which I thought used to be default allowed on the local network, if the service was enabled) was terrible.
SSH is allowed all the time for all incoming connections in these zones: dmz, external, home, internal, public and work. SSH has been enabled in the static firewall for years.
With the "Avahi by Default on the Desktop" feature mdns has been enabled also for Fedora 18.

I followed the wiki instructions (which were wrong), then the client hung, then I disabled and stopped firewalld, but it left various iptables state around, then I had to clean it up manually, etc. All in all, it wasted a good 30 minutes of my time making my life "easier" and in the process making a default Fedora install yet another level more complex.
Which state information was left over?

This bug https://bugzilla.redhat.com/show_bug.cgi?id=884878 (and anything related to it in anaconda) increases the impact of the feature from "Make FirewallD enabled to default" to "Make FirewallD effectively mandatory".

Leaving completely aside the question of whether it's ready for default, it's ''definitely'' not ready for that. What's the best process to make sure this accidental scope creep doesn't bite us? I don't think it meets the defined rules for F18Blocker, so I'm just raising this here.

Also https://bugzilla.redhat.com/show_bug.cgi?id=874378 does not seem to have been addressed -- FirewallD still brings in a host of otherwise non-core packages, including X.

'''''And''''', the FirewallD test phase is now after the Final Change Deadline, making that a very poor decision point.

The documentation doesn't seem to be much different from before.

"firewall-cmd --enable" still puts the system into panic mode.

Y'all, this is just not ready, and we don't have the resources to make it ready for F18.

(FESCo note: if you want anything changed, we can't wait for the meeting.)

Sigh. We have 2 work days until the change deadline. Is it at all practical to revert now?

(repoquery --whatrequires firewalld) tells us nothing, per http://fedoraproject.org/wiki/Features/firewalld-default there are at least 5 packages that would be impacted by the revert.


Taking the items one at a time:
Replying to [comment:9 mattdm]:

This bug https://bugzilla.redhat.com/show_bug.cgi?id=884878 (and anything related to it in anaconda) increases the impact of the feature from "Make FirewallD enabled to default" to "Make FirewallD effectively mandatory".

If I understand this correctly - Live CD images that contain the "firewall" command now require firewalld installed. Can't a live CD kickstart bypass this by not using the firewall kickstart command, and configuring iptables manually in %post? Considering that firewalld is the default, using a non-default method to configure the non-default firewall may not be entirely unreasonable.

Replying to [comment:10 mattdm]:

Also https://bugzilla.redhat.com/show_bug.cgi?id=874378 does not seem to have been addressed -- FirewallD still brings in a host of otherwise non-core packages, including X.

I don't like the disk space use, but can't really see that as a blocker.

Replying to [comment:11 mattdm]:

'''''And''''', the FirewallD test phase is now after the Final Change Deadline, making that a very poor decision point.

Oops, apparently nobody in FESCo kept track of this timing dependency. Sorry.

The documentation doesn't seem to be much different from before.

Yeah, there wasn't a firewalld release since, or much visible activity, since this ticket was opened - there is a '''single! ''' relevant commit in upstream git. The commit touches the man pages, I haven't checked whether it covers everything necessary.

"firewall-cmd --enable" still puts the system into panic mode.

All intuition aside, randomly guessing what options do without reading documentation was never a safe thing to do, and GNU getopt's standard behavior is to accept unique prefix of an option name, so while it is not great design, it would be difficult to persuade me that this is even a bug, let alone a blocker.


So... (skipping an unproductive blame game):
* Let's discuss this more on Monday, when people are available and we can get more reliable information.
* Would releasing in the current state be such a disaster that we would want to slip the change freeze? I don't think so, although I can certainly see the risk of firewalld getting a bad reputation that would be difficult to overcome (like SELinux used to have).
* At this point, a complete plan to revert (list of affected packages, plan to deal with them, people willing and able to get this done by Tuesday) would get my +1, however I'm afraid I probably won't be able to help with doing the work.
* I'd love to hear other options proposed.

Replying to [comment:12 mitr]:

(FESCo note: if you want anything changed, we can't wait for the meeting.)
Sigh. We have 2 work days until the change deadline. Is it at all practical to revert now?

I did try to raise this a while ago.

If I understand this correctly - Live CD images that contain the "firewall" command now require firewalld installed. Can't a live CD kickstart bypass this by not using the firewall kickstart command, and configuring iptables manually in %post? Considering that firewalld is the default, using a non-default method to configure the non-default firewall may not be entirely unreasonable.

Currently, it errors if the firewalld-offline-cmd is not found . This is also true of anaconda itself. Possibly could be fixed by some fallback code. (Update: appliance-creator does this even if the firewall command is not used; have not tested anaconda in that situation yet.) (Anaconda devs would prefer to call some neutral command -- system-config-firewall, say.)

Replying to [comment:10 mattdm]:

Also https://bugzilla.redhat.com/show_bug.cgi?id=874378 does not seem to have been addressed -- FirewallD still brings in a host of otherwise non-core packages, including X.
I don't like the disk space use, but can't really see that as a blocker.

It's really miserable for the cloud images, and this one was brought up quite a long time ago.

[...]

  • I'd love to hear other options proposed.

If we could get what anaconda and the appliance tools need to configure a firewall generically, we'd at least go back to default instead of mandatory, which would make me less concerned. I still think we're shipping it before it's ready, which will be bad for both Fedora and for FirewallD (c.f. SELinux reputation issue you mention), but, well, sometimes things work out that way and we can move on and make it better as we go.

I'll take a look at what it'd take to do that in system-config-firewall-base. That now at least has code to say "firewalld detected -- use that instead". Maybe instead it could actually forward on the desired changes to firewalld-offline-cmd? I dunno... thinking as I write here. It'd be nicer if firewalld could use the lokkit-generation configuration if detected, and then anaconda could always just generate that, and if firewalld is installed it could start from that as a base.

Presumably this is where anaconda switched to using firewalld-offline-cmd: https://bugzilla.redhat.com/show_bug.cgi?id=815540

But note that Bill Nottingham's wording in the initial report there is "after Fedora 18", and the firewalld feature page actually says "after Fedora 19".

I agree with all of mitr's points in comment 12.

Additionally, would be good to hear from the feature owner here...

Do you think we are ready for f18, or should do a last minute revert in f18 and go for f19?

If we can bring the feature back into the scope definied in the actual feature (make it the default, not mandatory in appliance-creator, livemedia-creator, and anaconda, with a plan developed for full migration in the after-F19 timeframe), this is less of a crisis. I think Fedora ''and'' FirewallD would be better served waiting for another release for even that, but if FESCO decides that it's best at this point to plunge ahead, well, okay.

I'm not sure if the best approach for that is to:

  1. Quick, develop a new wrapper.
  2. Put a kludge into anaconda (and friends) falling back to the old lokkit code if need be (ugly, but probably least effort).
  3. Extend lokkit to forward to firewalld when available (this seems best for a migration plan, but may be non-trivial).

but I think it's one of those.

Alternately for the full rollback, I know that libvirtd has code for behaving differently if firewalld is enabled or not. In fact, I understand a race condition there to be one of the remaining rough edges. And there's an open bug on printer configuration not working with firewalld enabled. So as far as changes to other packages, it may again just come back to anaconda and the appliance-creator tools.

Replying to [comment:11 mattdm]:

'''''And''''', the FirewallD test phase is now after the Final Change Deadline, making that a very poor decision point.

The documentation doesn't seem to be much different from before.

"firewall-cmd --enable" still puts the system into panic mode.

Y'all, this is just not ready, and we don't have the resources to make it ready for F18.
The test day was before the final change deadline before the deadline was pushed one week before. It wasn't my decision and I was not aware that this will happen.

Replying to [comment:12 mitr]:

(FESCo note: if you want anything changed, we can't wait for the meeting.)

Sigh. We have 2 work days until the change deadline. Is it at all practical to revert now?

(repoquery --whatrequires firewalld) tells us nothing, per http://fedoraproject.org/wiki/Features/firewalld-default there are at least 5 packages that would be impacted by the revert.


Taking the items one at a time:
Replying to [comment:9 mattdm]:

This bug https://bugzilla.redhat.com/show_bug.cgi?id=884878 (and anything related to it in anaconda) increases the impact of the feature from "Make FirewallD enabled to default" to "Make FirewallD effectively mandatory".

If I understand this correctly - Live CD images that contain the "firewall" command now require firewalld installed. Can't a live CD kickstart bypass this by not using the firewall kickstart command, and configuring iptables manually in %post? Considering that firewalld is the default, using a non-default method to configure the non-default firewall may not be entirely unreasonable.

For firewalld there is already a tool to convert most of the system-config-firewall/lookit configuration over to firewalld: firewall-offline-cmd
This tool is also used in the installer currently to configure firewalld directly.
The conversion for firewalld would be possible in the post install script of firewalld.

Replying to [comment:10 mattdm]:

Also https://bugzilla.redhat.com/show_bug.cgi?id=874378 does not seem to have been addressed -- FirewallD still brings in a host of otherwise non-core packages, including X.

I don't like the disk space use, but can't really see that as a blocker.

Replying to [comment:11 mattdm]:

'''''And''''', the FirewallD test phase is now after the Final Change Deadline, making that a very poor decision point.

Oops, apparently nobody in FESCo kept track of this timing dependency. Sorry.

I did not know that FESCo was up to change the dead line.

The documentation doesn't seem to be much different from before.

Yeah, there wasn't a firewalld release since, or much visible activity, since this ticket was opened - there is a '''single! ''' relevant commit in upstream git. The commit touches the man pages, I haven't checked whether it covers everything necessary.

I am just pushing the documentation to the WIKI page. This will go on this day.

"firewall-cmd --enable" still puts the system into panic mode.

All intuition aside, randomly guessing what options do without reading documentation was never a safe thing to do, and GNU getopt's standard behavior is to accept unique prefix of an option name, so while it is not great design, it would be difficult to persuade me that this is even a bug, let alone a blocker.


So... (skipping an unproductive blame game):
* Let's discuss this more on Monday, when people are available and we can get more reliable information.
* Would releasing in the current state be such a disaster that we would want to slip the change freeze? I don't think so, although I can certainly see the risk of firewalld getting a bad reputation that would be difficult to overcome (like SELinux used to have).
Do you really want to push out everything that is not 100% of what all want? Then we can not add anything from now on. No bigger change in a new GNOME or KDE version.
* At this point, a complete plan to revert (list of affected packages, plan to deal with them, people willing and able to get this done by Tuesday) would get my +1, however I'm afraid I probably won't be able to help with doing the work.
* I'd love to hear other options proposed.
Just let me try to get this to an acceptable state now.

For firewalld there is already a tool to convert most of the system-config-firewall/lookit configuration over to firewalld: firewall-offline-cmd
This tool is also used in the installer currently to configure firewalld directly.
The conversion for firewalld would be possible in the post install script of firewalld.

So, is your suggestion that it this point, Anaconda should go back to using lokkit to configure the firewall, and firewalld will take care of the conversion on first boot if it is installed?

Do you really want to push out everything that is not 100% of what all want? Then we can not add anything from now on. No bigger change in a new GNOME or KDE version.

I don't think anyone has said anything like that. I know I've been very careful not to, as it does not represent my position.

But the plain fact is that we're a long way from 100% here, ''and'' this change affects the whole distribution (not just one desktop environment), ''and'' the change has become effectively mandatory (which is beyond what the accepted feature says is the plan), ''and'' there are a large number of important things which were commonplace before which are now difficult (making this a backwards step rather than just not being complete).

Having new stuff first is part of what Fedora is all about. I'm not saying it needs to be ripped out. However, given the above, shouldn't we wait to make it the default?

Replying to [comment:19 mattdm]:

For firewalld there is already a tool to convert most of the system-config-firewall/lookit configuration over to firewalld: firewall-offline-cmd
This tool is also used in the installer currently to configure firewalld directly.
The conversion for firewalld would be possible in the post install script of firewalld.

So, is your suggestion that it this point, Anaconda should go back to using lokkit to configure the firewall, and firewalld will take care of the conversion on first boot if it is installed?

Yes.

Do you really want to push out everything that is not 100% of what all want? Then we can not add anything from now on. No bigger change in a new GNOME or KDE version.

I don't think anyone has said anything like that. I know I've been very careful not to, as it does not represent my position.

But the plain fact is that we're a long way from 100% here, ''and'' this change affects the whole distribution (not just one desktop environment), ''and'' the change has become effectively mandatory (which is beyond what the accepted feature says is the plan), ''and'' there are a large number of important things which were commonplace before which are now difficult (making this a backwards step rather than just not being complete).

Having new stuff first is part of what Fedora is all about. I'm not saying it needs to be ripped out. However, given the above, shouldn't we wait to make it the default?

The documentation has been updated: WIKI [https://fedoraproject.org/wiki/FirewallD] and man pages. The bugs 876661 and 876394 have been fixed.

I am working on 821938. I already added a comment to the firewalld man page. I am adding a configuration switch that is turned on by default where unknown interfaces will automatically be part of the default zone.

FESCo decided to fix the issues with pygobject3 and proceed without further changes. A workaround for removing firewalld via kickstart exists.

We'll leave this ticket open until the pygobject3 issues are fixed.

pygobject3-3.4.2-4.fc18 built (http://koji.fedoraproject.org/koji/buildinfo?buildID=372640). Thank you halfline. It's being added to high priority NTH bug list to be included in Final release.

this pygobject3 is stable now, closing this ticket.

Login to comment on this ticket.

Metadata