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@xxxxxxxxxxxxx> wrote: > >> http://fedoraproject.org/wiki/Features/firewalld-default > >> > >>> An explicit transition is planned after Fedora 18 with dropping support for the > >>> static firewall with system-config-firewal/lokkit. A migration from the static > >>> 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*) * Results: - The user looses all her existing firewall settings without a warning (security). - 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. * But: - 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 firewalld/system-config-firewall. [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 iptables script). [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...) Summary: * 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: /etc/firewalld/old-iptables-data - Make this data time-stamped to prevent overwriting in repeated (maybe mistaken) install/remove attempts. E.g: /etc/firewalld/.../2012-04-24_02-28/iptables /etc/firewalld/.../2012-04-24_02-28/iptables-config - 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, etc, etc. - 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. Cheers, -- Oron Peled Voice: +972-4-8228492 oron@xxxxxxxxxxxx http://users.actcom.co.il/~oron Make it idiot proof and someone will make a better idiot. credit: http://www.jr.co.il/humor/signatur.txt -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
