raising warning flag on firewalld-default feature

[Tomasz Torcz]

On Tue, Nov 13, 2012 at 06:16:49PM +0100, Dennis Jacobfeuerborn wrote:
> On 11/13/2012 05:28 PM, Thomas Woerner wrote:
> > On 11/13/2012 03:46 PM, Matthew Miller wrote:
> >> On Tue, Nov 13, 2012 at 02:28:17PM +0100, Tomasz Torcz wrote:
> >>>>>> Here, I mostly don't see the reason for it to be running all the time.
> >>>>>> Couldn't it be dbus activated, and then go away when it's not needed?
> >>>>>> Then,
> >>>>>> it would matter less what it was written in.
> >>>>> It would loose internal state if it would be D-BUS activated.
> >>>> Surely it could persist it somewhere?
> >>>    Like in the actual netfilter rules?
> >>
> >> Yes.
> >>
> >> It has to be able to save internal state *somehow*, because if restarting
> >> the service breaks everything, we're not gaining much over the old way, are
> >> we? Plus, for a critical service like this, the service needs to be designed
> >> to be as robust as possible in situations where it might crash or get killed
> >> arbitrarily.
> >>
> > With the old static firewall model every firewall change was a complete
> > firewall recreate with conntrack loss. With firewalld changes to the
> > firewall are done dynamically and conntrack is preserved.
> 
> That's not correct. You can modify the firewall just fine without
> restarting it.

  We are drifting away from the question.  We are trying to understand what
is the blocker for firewalld going away when not needed.  There is some “state”
to be preserved.  Apart from timers for “temporary” rules, what kind of
state firewalld has?  State that cannot be expressed by netfiler rules in
kernel, of course.

-- 
Tomasz Torcz                        To co nierealne -- tutaj jest normalne.
xmpp: zdzichubg at chrome.pl          Ziomale na życie mają tu patenty specjalne.