On Monday, 23 בApril 2012 18:56:23 Reindl Harald wrote:
Am 23.04.2012 17:32, schrieb Miloslav Trmač:
> On Tue, Apr 17, 2012 at 10:40 PM, Reindl Harald <h.reindl(a)thelounge.net>
>>> An explicit transition is planned after Fedora 18 with dropping support
>>> static firewall with system-config-firewal/lokkit. A
migration from the
>>> firewall model will be needed then.
Looks like this transition (as is currently planned) is going to
break many setups. I want to show the three following use-cases
which may be severely broken by this transition.
1. The simplest desktop case (firewalld is designed for such users).
This is what I personally use on most of my desktops/laptops:
* The user previously only used system-config-firewall (without
custom rules -- we talk about simplest case)
* The firewalld package does not even try to convert existing rules
(just looked at the .spec file for the post*/pre*/trans*)
- The user looses all her existing firewall settings without a warning
- If they had NAT (masquarading) -- pooof, no more Internet for you...
- Almost all record of their previous settings is lost (sans .rpmsave)
- If the poor user make another mistake (e.g: tries to re-install
system-config-firewall), it may even clobber the .rpmsave
[this is DATA-LOSS!]
2. Custom made firewall (e.g: hand-written script. I personally
use this in rare/complex cases):
* It obviously cannot be migrated automatically.
* That's OK, as someone that can maintain the custom script, can
migrate it manually.
- Just like item 1. above, we cannot take the risk that old
data (e.g: existing /etc/sysconfig/iptables) would be somehow
clobbered by install/upgrade/re-install of
[although the "customization" user is more likely to have backup
of said script, unlike the naive user from item 1.]
- As others mentioned before, this use-case may contain features
not (yet/ever?) in firewalld. So they need a (long-term) way
to keep using their custom scripts (yes, even in F-21 unless
by that time firewalld can have the full power of raw
[note: however, this use-case does *not* need system-config-firewall]
3. Complex firewall made by external tools (similar to 2.)
My personal example is fwbuilder (packaged in Fedora):
* I use it to centrally manage several firewalls
* If firewalld becomes default after some upgrade, then:
- Poof, some of these cannot be accessed (NAT...)
- ... and alternative access (physical) is Hmmm.... problematic
- I would call this super "uncool" (just a bit less uncool
than the potential data-loss I mentioned before...)
* Regretfully, I think it's clear that firewalld as *default* is
a complete show-stopper (for now).
* One (not hard) improvement is to preserve old data. E.g:
- During firewalld postinst (in install, upgrade is not
the problem here), save a copy of all previous iptables
config in a well defined location -- e.g:
- Make this data time-stamped to prevent overwriting in
repeated (maybe mistaken) install/remove attempts. E.g:
- Also echo a message about it to stderr (I know its against
the policy, but critical data-loss is more important IMO).
* Try to migrate system-config-firewall data:
- That is harder, but even doing only the "no-custom-rules" case
would prevent tons of problems for most (normal/naive) users.
- This would help even without/before firwalld is default.
* Make installation/activate of firewalld optional even after
it is good enough to be default:
- Custom/complex setups will not be migrated (surely not before
firewalld cannot cover the flexibility of raw iptables)
- So when people install servers, they may not want firewalld
at all (regardless of system-config-firewall existance)
- Don't assume a "live-cd" is only used only for desktop installs.
Many people (me included) install servers from a live-cd
and add the rest later.
Why? Because many times these are isolated servers (not on my
kickstart-configured network), the live-cd image is smaller
to download than a DVD, its already in my pocket on a DOK,
- So I think that even when firewalld is (eventually) good enough
for a *default* install and even when system-config-firewall will
already be a relic from the past -- we should allow power-users
not to install it in the first place.
I.e: it should be a *suggested* option.
From a (future) UI perspective its installation should IMO behave
similar to smolt. I.e: ask for install (default=yes), allow to
choose "no", if "no" is chosen, re-confirm with an explanation.
* Wishfull thinking for longer-term:
- Existing high-level tools, may be persuaded to generate firewalld
commands/config instead of low-level iptables config.
- As an example fwbuilder already has plugins to generate rules for
several engines (iptables, ipfilter, cisco, etc.) in some futuristic
pipe-dream it may have a firewalld plugin.
Oron Peled Voice: +972-4-8228492
Make it idiot proof and someone will make a better idiot.