Re: raising warning flag on firewalld-default feature

Hi Simon, On 28.11.2012 14:43, Simon Lukasik wrote: I can't see how this is related to my latest post. And I can't see what leads you to think that cross-platform scanning is feasible today (standard-wise and performance-wise). Please check this very informative post from Steve (OVAL board me

Re: raising warning flag on firewalld-default feature

On Wed, Nov 28, 2012 at 01:43:48PM +0100, Simon Lukasik wrote: > On 11/26/2012 12:15 PM, Richard W.M. Jones wrote: > > You're asking for something very open-ended, and which is not even > > possible to implement in general -- what if the inspecting operating > > system is Linux, and the inspected o

Re: raising warning flag on firewalld-default feature

On 11/26/2012 12:15 PM, Richard W.M. Jones wrote: > You're asking for something very open-ended, and which is not even > possible to implement in general -- what if the inspecting operating > system is Linux, and the inspected operating system needs custom Mac OS X > libraries? > Perhaps I am jus

Re: raising warning flag on firewalld-default feature

You're asking for something very open-ended, and which is not even possible to implement in general -- what if the inspecting operating system is Linux, and the inspected operating system needs custom Mac OS X libraries? In any case, the correct place to request this is with the SCAP standards tea

Re: raising warning flag on firewalld-default feature

On 11/25/2012 05:12 PM, Richard W.M. Jones wrote: > On Fri, Nov 23, 2012 at 11:43:01AM +0100, Simon Lukasik wrote: >> On 11/22/2012 09:07 PM, Richard W.M. Jones wrote: >>> On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote: Interpreters do not preclude simple data: they just sca

Re: raising warning flag on firewalld-default feature

On Sun, Nov 25, 2012 at 04:12:36PM +, Richard W.M. Jones wrote: > systems. Steve will correct me if I'm wrong here, but I don't believe > there's no room for it to be calling out to arbitrary custom s/no/any/ > libraries. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people

Re: raising warning flag on firewalld-default feature

On Fri, Nov 23, 2012 at 11:43:01AM +0100, Simon Lukasik wrote: > On 11/22/2012 09:07 PM, Richard W.M. Jones wrote: > > On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote: > >> Interpreters do not preclude simple data: they just scale better, > >> from simple linear declarative data t

Re: raising warning flag on firewalld-default feature

On 11/22/2012 09:07 PM, Richard W.M. Jones wrote: > On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote: >> Interpreters do not preclude simple data: they just scale better, >> from simple linear declarative data to complex, Turing-cranking >> swamp. The only argument against it is ru

Re: raising warning flag on firewalld-default feature

On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote: > Interpreters do not preclude simple data: they just scale better, > from simple linear declarative data to complex, Turing-cranking > swamp. The only argument against it is runtime overhead, which isn't > a problem in many, if not

Re: raising warning flag on firewalld-default feature

Przemek Klosowski wrote: > You say it yourself---if you need Turing, you have to put him in > somewhere. You argue that the complex logic HAS to go in the native > code, but that is inflexible. PolicyKit needed flexibility so they used > weird data; they combined inflexibility of native code with >

Re: raising warning flag on firewalld-default feature

On 11/21/2012 05:50 AM, Rahul Sundaram wrote: On Tue, Nov 20, 2012 at 3:39 PM, Przemek Klosowski wrote: It can be made simple, if you look at it the right way. One wouldn't start with a generic interpreter, but rather evaluate the config script in a domain-specific context. I thi

Re: raising warning flag on firewalld-default feature

Hi On Tue, Nov 20, 2012 at 3:39 PM, Przemek Klosowski wrote: > It can be made simple, if you look at it the right way. One wouldn't start > with a generic interpreter, but rather evaluate the config script in a > domain-specific context. > I think you just agreed in a roundabout way It *could*

Re: raising warning flag on firewalld-default feature

On 11/20/2012 01:39 PM, Rahul Sundaram wrote: " Interpreters do not preclude simple data: they just scale better, from simple linear declarative data to complex, Turing-cranking swamp. The problem is that, this design makes complex things possible but it doesn't do enough to keep simple things

Re: raising warning flag on firewalld-default feature

Hi " Interpreters do not preclude simple data: they just scale better, from simple linear declarative data to complex, Turing-cranking swamp. The only argument against it is runtime overhead, which isn't a problem in many, if not most, cases." The problem is that, this design makes complex things

Re: raising warning flag on firewalld-default feature

On 11/17/2012 12:26 PM, Kevin Kofler wrote: Przemek Klosowski wrote: Remember also that data is code: any config files could be seen as tiny specialized interpreted languages, so it's not like you can avoid interpretation anyway. That's a bad view of things, it leads to WTFs like PolicyKit usi

Re: raising warning flag on firewalld-default feature

Przemek Klosowski wrote: > Remember also that data is code: any config files could be seen as tiny > specialized interpreted languages, so it's not like you can avoid > interpretation anyway. That's a bad view of things, it leads to WTFs like PolicyKit using rules written in JavaScript. A simple

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 2:48 AM, Jan Zelený wrote: > On 12. 11. 2012 at 17:59:00, Chris Adams wrote: > > Once upon a time, Richard Vickery said: > > > Change still frightens people to varying degree s., and many busy > > > end-users > > > may not have time to read pages in order to learn a new c

Re: raising warning flag on firewalld-default feature

On 11/12/2012 02:15 PM, Miloslav Trmač wrote: On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler wrote: Right. We need to stop writing core system components in scripting languages! Well, there _are_ significant advantages to using a higer-level language than C.[1] Using one of the higher-level

Re: raising warning flag on firewalld-default feature

On Thu, 15.11.12 10:06, Matthew Miller (mat...@fedoraproject.org) wrote: > On Thu, Nov 15, 2012 at 01:53:32AM +0100, Lennart Poettering wrote: > > In fact, all system bus services should be configured to defer > > activation to systemd, so that all services regardless how they are > > triggered ar

Re: raising warning flag on firewalld-default feature

On Thu, Nov 15, 2012 at 04:15:25PM +0100, Matej Cepl wrote: > > I was looking for resources on systemd and dbus activation. I realized > > that > > the documentation here is very scarce -- there's this tutorial on just dbus > > activation a

Re: raising warning flag on firewalld-default feature

On 2012-11-15, 15:06 GMT, Matthew Miller wrote: > I was looking for resources on systemd and dbus activation. I realized > that > the documentation here is very scarce -- there's this tutorial on just dbus > activation and our > wiki page <

Re: raising warning flag on firewalld-default feature

On Thu, Nov 15, 2012 at 01:53:32AM +0100, Lennart Poettering wrote: > In fact, all system bus services should be configured to defer > activation to systemd, so that all services regardless how they are > triggered are executed in the same clean execution environment, and can > be manipulated with

Re: raising warning flag on firewalld-default feature

On 15.11.2012 04:32, Kevin Kofler wrote: Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be

Re: LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)

How much Python code are you proposing "someone" ports to Lua? ;-) On Wed, Nov 14, 2012 at 4:49 PM, Alek Paunov wrote: > On 12.11.2012 21:34, Steve Grubb wrote: >> >> >> But the problem I see is a lot of libraries are wrapped by swig, which >> leaks >> memory like a sieve. If swig didn't generat

Re: raising warning flag on firewalld-default feature

Alek Paunov wrote: > On 13.11.2012 18:35, Richard W.M. Jones wrote: >> This seems about right to me: Both ocamlopt & gcc generate native >> x86-64 programs, but there's a small amount of overhead in the OCaml >> binary (initializing the minor heap of the GC). >> > > luajit too (it is one of the f

Re: raising warning flag on firewalld-default feature

On Tue, 13.11.12 18:03, Thomas Woerner (twoer...@redhat.com) wrote: > The security team asked me not to make firewalld a D-BUS driven > mechanism, because of security concerns and also because of SELinux. Uh? If you write a new D-Bus service and want to use bus activation, then you should Systemd

LuaJIT - an alternative for current Python C bindings (was: Re: raising warning flag on firewalld-default feature)

On 12.11.2012 21:34, Steve Grubb wrote: But the problem I see is a lot of libraries are wrapped by swig, which leaks memory like a sieve. If swig didn't generate such leaky code, Python based daemons wouldn't be as scary. IMHO, Python is one of the best ways to express management logic. As

Re: raising warning flag on firewalld-default feature

On 13.11.2012 18:35, Richard W.M. Jones wrote: Hmmm: $ echo '' > true.ml $ ocamlopt.opt true.ml -o true $ time ./true real 0m0.002s user 0m0.000s sys0m0.001s time luajit -e "require'os'; os.exit(42)" real0m0.001s user0m0.000s sys 0m0.000s But, check here for a far more

Re: raising warning flag on firewalld-default feature

Roberto Ragusa wrote: > Just for fun, let's see who is the worst. Challenge accepted. :-) $ cat nothing.adb procedure Nothing is begin null; end Nothing; $ gnatmake nothing.adb -o true gcc -c nothing.adb gnatbind -x nothing.ali gnatlink nothing.ali -o true $ time ./true real0m0.001s use

Re: raising warning flag on firewalld-default feature

On 11/13/2012 05:35 PM, Richard W.M. Jones wrote: > On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: >> >> It could be argued that python is more suited to long lived programs: >> >> $ time /bin/true >> real 0m0.002s > > Hmmm: > > $ echo '' > true.ml > $ ocamlopt.opt true.ml -o true

Re: raising warning flag on firewalld-default feature

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 runni

Re: raising warning flag on firewalld-default feature

Matthew Miller (mat...@fedoraproject.org) said: > On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote: > > >That's not correct. You can modify the firewall just fine without > > >restarting it. > > This is related to system-config-firewall/lokkit. You are right, if > > you are using ipt

Re: raising warning flag on firewalld-default feature

On Tue, 2012-11-13 at 10:03 -0500, Matthew Miller wrote: > On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: > > > > - no way to run once and exit for cloud guests with *non-dynamic* > > > > firewall > > > > needs, and it's a non-trivial user of system resources > > > You can u

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 06:37:37PM +0100, Thomas Woerner wrote: > >That's not correct. You can modify the firewall just fine without > >restarting it. > This is related to system-config-firewall/lokkit. You are right, if > you are using iptables directly then you do not have this > limitation. fire

Re: raising warning flag on firewalld-default feature

On 11/13/2012 06:16 PM, 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 d

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 06:03:18PM +0100, Thomas Woerner wrote: > >I understand that some services work that way. However, I don't think that > >this is the best design for a firewall service. Is there some way to force > >the internal state to be recorded? > >Let's say there is a security fix for

Re: raising warning flag on firewalld-default feature

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

Re: raising warning flag on firewalld-default feature

On 11/13/2012 05:36 PM, Matthew Miller wrote: On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote: If you want to recreate rules, use reload. If you restart the service with systemd, the servce gets stopped and started again, so you will loose internal state. This is how services are

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 05:28:42PM +0100, Thomas Woerner wrote: > If you want to recreate rules, use reload. If you restart the > service with systemd, the servce gets stopped and started again, so > you will loose internal state. This is how services are working. I understand that some services w

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: > On 11/12/2012 07:53 PM, Matthew Miller wrote: > >On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: > >>I really don't understand why a core system component such as firewalld is > >>implemented in Python! > > > >Here, I mo

Re: raising warning flag on firewalld-default feature

On 11/13/2012 04:02 PM, Matthew Miller wrote: On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: - no way to run once and exit for cloud guests with *non-dynamic* firewall needs, and it's a non-trivial user of system resources You can use the old firewall environment for st

Re: raising warning flag on firewalld-default feature

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

Re: raising warning flag on firewalld-default feature

On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: > > > - no way to run once and exit for cloud guests with *non-dynamic* > > > firewall > > > needs, and it's a non-trivial user of system resources > > You can use the old firewall environment for static firewall use > > cases.

Re: raising warning flag on firewalld-default feature

On Fri, Nov 09, 2012 at 11:57:12AM -0500, Matthew Miller wrote: > > > - no way to run once and exit for cloud guests with *non-dynamic* > > > firewall > > > needs, and it's a non-trivial user of system resources > > You can use the old firewall environment for static firewall use > > cases.

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 08:51:59AM -0600, Chris Adams wrote: > > $ time /bin/true > > real0m0.002s > > $ time python -c True > > real0m0.049s > Aside from that being a meaningless, worst case example, an "overhead" > of .047 seconds is hardly worth worrying about unless the command

Re: raising warning flag on firewalld-default feature

Once upon a time, Pádraig Brady said: > It could be argued that python is more suited to long lived programs: > > $ time /bin/true > real 0m0.002s > $ time python -c True > real 0m0.049s Aside from that being a meaningless, worst case example, an "overhead" of .047 seconds is hardly worth worr

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 02:41:44PM +, Pádraig Brady wrote: > > And for reducing space use: I think it might also be nice to break python > > 2to3 and idle out of the python-libs package. > splitting python-libs (25MB here), seems worthwhile. > python-libs can bb changed to a subpackage that jus

Re: raising warning flag on firewalld-default feature

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 l

Re: raising warning flag on firewalld-default feature

On 11/12/2012 07:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be db

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 01:19:36PM +, Richard W.M. Jones 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

Re: raising warning flag on firewalld-default feature

On Tue, Nov 13, 2012 at 12:53:10PM +0100, Thomas Woerner wrote: > On 11/12/2012 08:53 PM, Matthew Miller wrote: > >On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: > >>I really don't understand why a core system component such as firewalld is > >>implemented in Python! > > > >Here, I m

Re: raising warning flag on firewalld-default feature

On 11/12/2012 08:53 PM, Matthew Miller wrote: On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: I really don't understand why a core system component such as firewalld is implemented in Python! Here, I mostly don't see the reason for it to be running all the time. Couldn't it be db

Re: raising warning flag on firewalld-default feature

On 12. 11. 2012 at 17:59:00, Chris Adams wrote: > Once upon a time, Richard Vickery said: > > Change still frightens people to varying degree s., and many busy > > end-users > > may not have time to read pages in order to learn a new command > > It is in _development_ and is just in F18 as a previ

Re: raising warning flag on firewalld-default feature

Once upon a time, Richard Vickery said: > Change still frightens people to varying degree s., and many busy end-users > may not have time to read pages in order to learn a new command It is in _development_ and is just in F18 as a preview. If/when it is ready to replace yum, it may get a symlink

Re: raising warning flag on firewalld-default feature

Change still frightens people to varying degree s., and many busy end-users may not have time to read pages in order to learn a new command On Nov 12, 2012 1:46 PM, "Chris Adams" wrote: > Once upon a time, Richard Vickery said: > > If dnf is no improvement, then I'd rather we stick with yum; mes

Re: raising warning flag on firewalld-default feature

Once upon a time, Richard Vickery said: > If dnf is no improvement, then I'd rather we stick with yum; messing with > something new just means spending time that I don't have trying to learn > that new command. This is incredibly cumbersome. If at all possible, please > stay with yum. You should

Re: raising warning flag on firewalld-default feature

If dnf is no improvement, then I'd rather we stick with yum; messing with something new just means spending time that I don't have trying to learn that new command. This is incredibly cumbersome. If at all possible, please stay with yum. On Nov 12, 2012 10:53 AM, "Kevin Kofler" wrote: > Seth Vida

Re: raising warning flag on firewalld-default feature

On Mon, Nov 12, 2012 at 02:53:01PM -0500, Matthew Miller wrote: > On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: > > I really don't understand why a core system component such as firewalld is > > implemented in Python! > > Here, I mostly don't see the reason for it to be running al

Re: raising warning flag on firewalld-default feature

On Sat, Nov 10, 2012 at 09:53:13PM +0100, Kevin Kofler wrote: > I really don't understand why a core system component such as firewalld is > implemented in Python! 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

Re: raising warning flag on firewalld-default feature

Once upon a time, Miloslav Trmač said: > Sure. Now create a hash table indexed by a tuple, or for more > challenge by an unordered set of strings. Or have all items of the > same type hashed by three different fields for fast lookups. If I were trying to do all that, I'd probably just go with a

Re: raising warning flag on firewalld-default feature

On Mon, Nov 12, 2012 at 8:25 PM, Chris Adams wrote: > Once upon a time, Miloslav Trmač said: >> - Much easier access to higher-level (and more efficient!) data >> structures. C programs frequently use linked lists instead of e.g. >> hash tables simply because maintaining hash tables and the asso

Re: raising warning flag on firewalld-default feature

On Monday, November 12, 2012 08:15:48 PM Miloslav Trmač wrote: > On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler wrote: > > Jan Zelený wrote: > >> Yes, that's the plan. But dnf is still Python. So if we really want to > >> get Python out of minimal install, there is a room for possible > >> alternat

Re: raising warning flag on firewalld-default feature

Once upon a time, Miloslav Trmač said: > - Much easier access to higher-level (and more efficient!) data > structures. C programs frequently use linked lists instead of e.g. > hash tables simply because maintaining hash tables and the associated > memory allocation is just too complex. Hash tabl

Re: raising warning flag on firewalld-default feature

On Mon, Nov 12, 2012 at 7:54 PM, Kevin Kofler wrote: > Jan Zelený wrote: >> Yes, that's the plan. But dnf is still Python. So if we really want to get >> Python out of minimal install, there is a room for possible alternatives I >> guess. > > Right. We need to stop writing core system components i

Re: raising warning flag on firewalld-default feature

Jan Zelený wrote: > Yes, that's the plan. But dnf is still Python. So if we really want to get > Python out of minimal install, there is a room for possible alternatives I > guess. Right. We need to stop writing core system components in scripting languages! > But none of this is certainly happe

Re: raising warning flag on firewalld-default feature

Seth Vidal wrote: > Yum will likely be replaced with dnf afaik. I don't think zif is under > consideration at all. That's exactly what I'm complaining about. Dnf is no improvement over yum at all, zif would bring real advantages through the simple fact that it's native code, not Python. Native C

Re: raising warning flag on firewalld-default feature

On 11/12/2012 07:28 AM, Seth Vidal wrote: On Sat, 10 Nov 2012, Kevin Kofler wrote: Richard W.M. Jones wrote: - depends on Python stack +1, we really need to get Python out of the minimal installation. The focus should be on replacing the existing Python-based packages in the minimum set

Re: raising warning flag on firewalld-default feature

On 11/09/2012 07:45 PM, Reindl Harald wrote: Am 09.11.2012 17:45, schrieb Thomas Woerner: On 11/09/2012 05:24 PM, Eric H. Christensen wrote: Please have a look at the feature list for F-18. firewalld replaces system-config-firewall/lokkit, and the iptables and ip6tables services, not the ipt

Re: raising warning flag on firewalld-default feature

On 12. 11. 2012 at 01:28:10, Seth Vidal wrote: > On Sat, 10 Nov 2012, Kevin Kofler wrote: > > Richard W.M. Jones wrote: > >> - depends on Python stack > > > > +1, we really need to get Python out of the minimal installation. > > > > The focus should be on replacing the existing Python-based packag

Re: raising warning flag on firewalld-default feature

On Sat, 10 Nov 2012, Kevin Kofler wrote: Richard W.M. Jones wrote: - depends on Python stack +1, we really need to get Python out of the minimal installation. The focus should be on replacing the existing Python-based packages in the minimum set (e.g. yum) by native replacements (e.g. zi

Re: raising warning flag on firewalld-default feature

Richard W.M. Jones wrote: > - depends on Python stack +1, we really need to get Python out of the minimal installation. The focus should be on replacing the existing Python-based packages in the minimum set (e.g. yum) by native replacements (e.g. zif). Adding more Python stuff with additional

Re: raising warning flag on firewalld-default feature

On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: > - this turns out to be a big change! > - there's little to no documentation > - the UI is very confusing, with a large number of "zones" and no apparent > way to configure those zones > - toolset is not yet robust -- has

Re: raising warning flag on firewalld-default feature

Am 09.11.2012 17:45, schrieb Thomas Woerner: > On 11/09/2012 05:24 PM, Eric H. Christensen wrote: > Please have a look at the feature list for F-18. > > firewalld replaces system-config-firewall/lokkit, and the iptables and > ip6tables services, not the iptables package > and command. > > The

Re: raising warning flag on firewalld-default feature

On Fri, Nov 09, 2012 at 05:32:14PM +0100, Thomas Woerner wrote: > > - this turns out to be a big change! > > - there's little to no documentation > Have you had a look at the man pages? I missed the top-level man page and was looking at firewall-cmd, which is not very helpful on its own. Start

Re: raising warning flag on firewalld-default feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 05:45:23PM +0100, Thomas Woerner wrote: > >I'd happily help document it in the Fedora Security Guide if I could get the > >proper content or access to the developers. Heck, I'll even help write > >stand-alone documentation fo

Re: raising warning flag on firewalld-default feature

On 11/09/2012 05:24 PM, Eric H. Christensen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18.

Re: raising warning flag on firewalld-default feature

On 11/09/2012 03:33 PM, Matthew Miller wrote: https://fedoraproject.org/wiki/Features/firewalld-default We have an accepted feature for Firewalld to be the default in Fedora 18. The old scripts are primitive and can't handle dynamic environments very well, so having something new and modern is

Re: raising warning flag on firewalld-default feature

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 09, 2012 at 09:33:08AM -0500, Matthew Miller wrote: > https://fedoraproject.org/wiki/Features/firewalld-default > > We have an accepted feature for Firewalld to be the default in Fedora 18. This replaces iptables and ip6tables? Perhaps I