9:56 p.m.
In case anyone noticed minimal install got rather bigger between Alpha
and Beta - I did too. And I finally got around to figuring out why and
filing a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=874378
long story short, it's firewalld. Its deps are pretty heavy for
something that's supposed to be in minimal. I'm sure twoerner would
welcome help in pruning the deps if it's possible. it should at least be
possible for it not to depend on both pygobject2 and pygobject3, one
would think :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:35 p.m.
On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote:
long story short, it's firewalld. Its deps are pretty heavy for
something that's supposed to be in minimal. I'm sure twoerner would
welcome help in pruning the deps if it's possible. it should at least be
possible for it not to depend on both pygobject2 and pygobject3, one
would think :)
Maybe we could have a release criterion which states that the minimal
install doesn't have anything which pulls in the X libraries (or Wayland)?
That's not a _completely_ arbitrary line in the sand. Probably the issue
here is just a matter of what goes in what subpackage.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
12:47 a.m.
On Thu, Nov 8, 2012 at 4:35 AM, Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote:
> long story short, it's firewalld. Its deps are pretty heavy for
> something that's supposed to be in minimal. I'm sure twoerner would
> welcome help in pruning the deps if it's possible. it should at least be
> possible for it not to depend on both pygobject2 and pygobject3, one
> would think :)
Maybe we could have a release criterion which states that the minimal
install doesn't have anything which pulls in the X libraries (or Wayland)?
That's not a _completely_ arbitrary line in the sand. Probably the issue
here is just a matter of what goes in what subpackage.
Problem with that is that you get into flame wars about what's
necessary. I would argue that on a minimal install for cloud where you
have no web browser to view localhost that a web service for logs
isn't minimal and hence isn't necessary, it seems others disagree.
Peter
6:41 a.m.
On Thu, Nov 08, 2012 at 06:47:58AM +0000, Peter Robinson wrote:
> Maybe we could have a release criterion which states that the
minimal
> install doesn't have anything which pulls in the X libraries (or Wayland)?
> That's not a _completely_ arbitrary line in the sand. Probably the issue
> here is just a matter of what goes in what subpackage.
Problem with that is that you get into flame wars about what's
necessary. I would argue that on a minimal install for cloud where you
Well, that's the point of making a line at X11. I hope we can pretty much
agree on that. :)
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
11:37 a.m.
Matthew Miller (mattdm(a)fedoraproject.org) said:
On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote:
> long story short, it's firewalld. Its deps are pretty heavy for
> something that's supposed to be in minimal. I'm sure twoerner would
> welcome help in pruning the deps if it's possible. it should at least be
> possible for it not to depend on both pygobject2 and pygobject3, one
> would think :)
Maybe we could have a release criterion which states that the minimal
install doesn't have anything which pulls in the X libraries (or Wayland)?
That's not a _completely_ arbitrary line in the sand. Probably the issue
here is just a matter of what goes in what subpackage.
Nod, this is more due to how pygobject3 is packaged rather than firewalld
itself.
Bill
1:33 p.m.
On 11/08/2012 06:37 PM, Bill Nottingham wrote:
Matthew Miller (mattdm(a)fedoraproject.org) said:
> On Wed, Nov 07, 2012 at 07:56:30PM -0800, Adam Williamson wrote:
>> long story short, it's firewalld. Its deps are pretty heavy for
>> something that's supposed to be in minimal. I'm sure twoerner would
>> welcome help in pruning the deps if it's possible. it should at least be
>> possible for it not to depend on both pygobject2 and pygobject3, one
>> would think :)
>
>
> Maybe we could have a release criterion which states that the minimal
> install doesn't have anything which pulls in the X libraries (or Wayland)?
>
> That's not a _completely_ arbitrary line in the sand. Probably the issue
> here is just a matter of what goes in what subpackage.
Nod, this is more due to how pygobject3 is packaged rather than firewalld
itself.
Bill
firewalld has been in base for F-18 alpha and now is in standard group
after rework of the package groups. anaconda pulls it in directly to be
able to configure the firewall.
The firewall server only needs GLib, GObject and Gio from pygobject3, so
if cairo support could be sub-packaged in pygobject3, we have a small
requirement list:
+dbus-python
+ebtables
+firewalld
+gobject-introspection
+libselinux-python
+pygobject2
+pygobject3
+python-decorator
+python-slip
+python-slip-dbus
pygobject2 is needed by python-slip, maybe we can get rid of this.
gobject and gi.repository.GObject are exchangeable. I do not know about
the libselinux-python requirement, but the package is fairly small.
Would this requirement set be ok?
Thomas
1:18 p.m.
Adam Williamson (awilliam(a)redhat.com) said:
In case anyone noticed minimal install got rather bigger between
Alpha
and Beta - I did too. And I finally got around to figuring out why and
filing a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=874378
long story short, it's firewalld. Its deps are pretty heavy for
something that's supposed to be in minimal. I'm sure twoerner would
welcome help in pruning the deps if it's possible. it should at least be
possible for it not to depend on both pygobject2 and pygobject3, one
would think :)
FYI, re: firewalld & minimal install.
firewalld isn't in the minimal comps groups. However, it's pulled in
by anaconda, see pyanaconda/install.py:
# anaconda requires storage packages in order to make sure the target
# system is bootable and configurable, and some other packages in order
# to finish setting up the system.
packages = storage.packages + ["authconfig", "firewalld"]
Bill
2:19 p.m.
On Thu, Nov 08, 2012 at 02:18:09PM -0500, Bill Nottingham wrote:
firewalld isn't in the minimal comps groups. However, it's
pulled in
by anaconda, see pyanaconda/install.py:
# anaconda requires storage packages in order to make sure the target
# system is bootable and configurable, and some other packages in order
# to finish setting up the system.
packages = storage.packages + ["authconfig", "firewalld"]
I see the case for making the storage packages conditional, but I think it'd
be more transparent and less "magical" if we just put authconfig and
firewalld in @core.
https://bugzilla.redhat.com/show_bug.cgi?id=874763
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:12 a.m.
On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote:
FYI, re: firewalld & minimal install.
firewalld isn't in the minimal comps groups. However, it's pulled in
by anaconda, see pyanaconda/install.py:
# anaconda requires storage packages in order to make sure the target
# system is bootable and configurable, and some other packages in order
# to finish setting up the system.
packages = storage.packages + ["authconfig", "firewalld"]
Why do anaconda dependencies end up in the minimal install ? That
shouldn't really be necessary, right ? It has always bugged me the we
end up with anaconda on the installed system when installing from a live
cd.
7:34 a.m.
On Fri, Nov 09, 2012 at 07:12:50AM -0500, Matthias Clasen wrote:
> firewalld isn't in the minimal comps groups. However,
it's pulled in
> by anaconda, see pyanaconda/install.py:
> # anaconda requires storage packages in order to make sure the target
> # system is bootable and configurable, and some other packages in order
> # to finish setting up the system.
> packages = storage.packages + ["authconfig", "firewalld"]
Why do anaconda dependencies end up in the minimal install ? That
shouldn't really be necessary, right ? It has always bugged me the we
end up with anaconda on the installed system when installing from a live
cd.
The storage packages are going to be needed for the system to boot.
Anaconda could probably add some smarts to remove authconfig if it wasn't
pulled in by anything in the selected comps, but I'm not sure it'd be worth
the special logic -- we might as well just put it in @core (even though it's
not super-tiny).
Firwealld I don't know about, though. If anaconda sets up the firewall using
firewalld but then doesn't install it, will the old iptables scripts load
the configuration? It'd be nice if it could, because firewalld is *another*
big change that it'd be nice to have a reasonable back-out plan for.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:41 a.m.
On 11/09/2012 01:34 PM, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 07:12:50AM -0500, Matthias Clasen wrote:
>> firewalld isn't in the minimal comps groups. However, it's pulled in
>> by anaconda, see pyanaconda/install.py:
>> # anaconda requires storage packages in order to make sure the target
>> # system is bootable and configurable, and some other packages in order
>> # to finish setting up the system.
>> packages = storage.packages + ["authconfig",
"firewalld"]
> Why do anaconda dependencies end up in the minimal install ? That
> shouldn't really be necessary, right ? It has always bugged me the we
> end up with anaconda on the installed system when installing from a live
> cd.
The storage packages are going to be needed for the system to boot.
Anaconda could probably add some smarts to remove authconfig if it wasn't
pulled in by anything in the selected comps, but I'm not sure it'd be worth
the special logic -- we might as well just put it in @core (even though it's
not super-tiny).
Firwealld I don't know about, though. If anaconda sets up the firewall using
firewalld but then doesn't install it, will the old iptables scripts load
the configuration? It'd be nice if it could, because firewalld is *another*
big change that it'd be nice to have a reasonable back-out plan for.
You might want to remove plymouth from the minimal install since it does
not make sense having it there anyway
JBG
7:53 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, Nov 09, 2012 at 01:41:08PM +0000, "Jóhann B. Guðmundsson" wrote:
You might want to remove plymouth from the minimal install since it
does not make sense having it there anyway
Yes probably. Anyone know why it's there?
I'm starting to think that a dedicated list for the minimal core sig makes
sense after all.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:16 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 9 Nov 2012 08:53:19 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Fri, Nov 09, 2012 at 01:41:08PM +0000, "Jóhann B.
Guðmundsson"
wrote:
> You might want to remove plymouth from the minimal install since it
> does not make sense having it there anyway
Yes probably. Anyone know why it's there?
IIRC, even if you 'disable' it, plymouth is still the thing handing the
text mode output. Perhaps some plymouth folks would chime in here...
I'm starting to think that a dedicated list for the minimal core
sig
makes sense after all.
I'm thinking the opposite. ;) For example, as above plymouth folks read
the devel list, you would have to find and invite them to a new
list. ;)
Can't we just use this list and try and add more signal to it for those
that killed off the long threads?
kevin
10:20 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote:
> Yes probably. Anyone know why it's there?
IIRC, even if you 'disable' it, plymouth is still the thing handing the
text mode output. Perhaps some plymouth folks would chime in here...
I removed it from my test vm with no apparent ill effects....
> I'm starting to think that a dedicated list for the minimal
core sig
> makes sense after all.
I'm thinking the opposite. ;) For example, as above plymouth folks read
the devel list, you would have to find and invite them to a new
list. ;)
Eh, I'm willing to try either way.
Can't we just use this list and try and add more signal to it for
those
that killed off the long threads?
Mailman needs a feature where it automatically redirects super-long threads
to a separate mailing list.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
10:35 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 9 Nov 2012 11:20:08 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote:
> > Yes probably. Anyone know why it's there?
> IIRC, even if you 'disable' it, plymouth is still the thing handing
> the text mode output. Perhaps some plymouth folks would chime in
> here...
I removed it from my test vm with no apparent ill effects....
Does a kernel upgrade work as expected? (dracut might want plymouth to
put in the initramfs?)
> > I'm starting to think that a dedicated list for the
minimal core
> > sig makes sense after all.
> I'm thinking the opposite. ;) For example, as above plymouth folks
> read the devel list, you would have to find and invite them to a new
> list. ;)
Eh, I'm willing to try either way.
:)
> Can't we just use this list and try and add more signal to
it for
> those that killed off the long threads?
Mailman needs a feature where it automatically redirects super-long
threads to a separate mailing list.
Yeah, although you could also just not pay attention to it at the
client end.
kevin
10:42 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
Le Ven 9 novembre 2012 17:35, Kevin Fenzi a écrit :
On Fri, 9 Nov 2012 11:20:08 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
> On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote:
> > > Yes probably. Anyone know why it's there?
> > IIRC, even if you 'disable' it, plymouth is still the thing handing
> > the text mode output. Perhaps some plymouth folks would chime in
> > here...
>
> I removed it from my test vm with no apparent ill effects....
Does a kernel upgrade work as expected? (dracut might want plymouth to
put in the initramfs?)
It works fine. The only thing that used to peg plymouth were some package
deps, and they've been removed lately
Regards,
--
Nicolas Mailhot
12:26 p.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
Am 09.11.2012 17:35, schrieb Kevin Fenzi:
On Fri, 9 Nov 2012 11:20:08 -0500
Matthew Miller <mattdm(a)fedoraproject.org> wrote:
> On Fri, Nov 09, 2012 at 09:16:24AM -0700, Kevin Fenzi wrote:
>>> Yes probably. Anyone know why it's there?
>> IIRC, even if you 'disable' it, plymouth is still the thing handing
>> the text mode output. Perhaps some plymouth folks would chime in
>> here...
>
> I removed it from my test vm with no apparent ill effects....
Does a kernel upgrade work as expected? (dracut might want plymouth to
put in the initramfs?)
kernel-line: rd.plymouth=0 plymouth.enable=0
[root@srv-rhsoft:~]$ cat /etc/dracut.conf.d/90-plymouth.conf
omit_dracutmodules+="plymouth"
11:41 a.m.
New subject: plymouth in @core? [was Re: Attention, dependency fighters]
On Fri, 09.11.12 08:53, Matthew Miller (mattdm(a)fedoraproject.org) wrote:
On Fri, Nov 09, 2012 at 01:41:08PM +0000, "Jóhann B.
Guðmundsson" wrote:
> You might want to remove plymouth from the minimal install since it
> does not make sense having it there anyway
Yes probably. Anyone know why it's there?
In rc.sysinit-times ply was the only way how LUKS passwords and suchlike
could be prompted during boot. Hence rc.sysinit in a way relied on
plymouth to be around to fully function. In systemd we have a non-ply
fallback in place however, so prompting passwords on the text console
without ply around should work fine nowadays.
We regularly test systemd upstream with and without plymouth, to make
sure both ways to boot is well supported. Dropping plymouth from the
minimal install set should hence be unproblematic and well supported.
Note that even on systemd without a display plymouth used to be highly
useful since it collected the boot status output from the console and
stored it away in log files. With systemd we now connect all boot
services (that means stdout/stderr and syslog() of all services in the
initrd and early boot) to the journal anyway, so this really useful
functionality of plymouth is not necessary anymore. (In case you wonder,
to get these boot outputs just run "journalctl -b").
Lennart
--
Lennart Poettering - Red Hat, Inc.
11:22 a.m.
"Jóhann B. Guðmundsson" (johannbg(a)gmail.com) said:
>The storage packages are going to be needed for the system to
boot.
>
>Anaconda could probably add some smarts to remove authconfig if it wasn't
>pulled in by anything in the selected comps, but I'm not sure it'd be worth
>the special logic -- we might as well just put it in @core (even though it's
>not super-tiny).
>
>Firwealld I don't know about, though. If anaconda sets up the firewall using
>firewalld but then doesn't install it, will the old iptables scripts load
>the configuration? It'd be nice if it could, because firewalld is *another*
>big change that it'd be nice to have a reasonable back-out plan for.
The point here is that both authconfig and firewalld are used by anaconda to
configure the installed system, via either the old code (pre-F18) or the
kickstart code (older releases, and F18+). anaconda would need to grow more
complicated checks to ensure that certain things weren't set in the install
before laying them down.
You might want to remove plymouth from the minimal install since it
does not make sense having it there anyway
You filed a bug about that, actually... I'll respond here and paste there.
plymouth was added to the minimal install as a consistent method for
handling encrypted passphrases and boot-time logs at the time. Since this
has moved out into other components since then, it can be reconsidered.
There's something to be said for having a consistent boot-time interface
though, rather than one that changes whether or not plymouth is installed.
Bill
5:06 p.m.
On Fri, 2012-11-09 at 07:12 -0500, Matthias Clasen wrote:
On Thu, 2012-11-08 at 14:18 -0500, Bill Nottingham wrote:
> FYI, re: firewalld & minimal install.
>
> firewalld isn't in the minimal comps groups. However, it's pulled in
> by anaconda, see pyanaconda/install.py:
>
> # anaconda requires storage packages in order to make sure the target
> # system is bootable and configurable, and some other packages in order
> # to finish setting up the system.
> packages = storage.packages + ["authconfig", "firewalld"]
Why do anaconda dependencies end up in the minimal install ? That
shouldn't really be necessary, right ? It has always bugged me the we
end up with anaconda on the installed system when installing from a live
cd.
This is a different thing. It's a somewhat complex area, actually. We
have:
* things that anaconda needs in its own environment
* things that anaconda needs or *may* need in the installed system
Things that anaconda needs in its own environment are specified as
dependencies of the anaconda package, generally. These are not
transferred to the installed system as a matter of course. If you
install from DVD or netinst, you don't get the anaconda package or any
of its dependencies installed. This only happens when you install from
live, simply because of how live installs work: they take the live
environment and image it to the target system's hard disk. You need
anaconda to be in the live image to do the install, obviously, so it
also winds up in the installed system.
When doing a live install anaconda can tweak the installed system after
writing it, so I think it'd be theoretically possible for someone to
contribute a bit for anaconda's post-install code that would remove the
anaconda package and its dependencies after the installed system has
been written, but someone needs to write that code. I may be missing
some reason why this is impossible, in which case someone on the
anaconda team will surely let us know.
Moving on, we have things that anaconda actually knows need to be in the
deployed package set - either always, or sometimes. firewalld is one of
these. This is a different case to the 'why is anaconda on my installed
system' case, these things are actually being intentionally put into the
installed system.
There is a comps group named 'anaconda-tools' which lists all these. The
DVD compose pulls this group so anaconda will definitely have them
available to add to the to-be-installed package set if necessary. Most
live spins also include them for the same reason, though I think the
minimal spin (and therefore SoaS, which is based on minimal) doesn't
include the group but instead specifies just a few of the packages
directly; this means that live spins based on the minimal spin are
actually lacking some capabilities.
Not all these packages actually get installed in all cases, however.
anaconda internally maintains a list of the packages it thinks need to
_actually_ get added to the to-be-installed package set, and throws
things onto the list according to circumstances. So if you're doing an
x86 BIOS install, it adds 'grub2' to the list; if you're doing an x86
EFI install, it adds 'grub2-efi' to the list; if you're doing a PPC or
s390 install, it'd add a different bootloader. If you're doing a
multipath install, it adds device-mapper-multipath to the list. And so
on.
Right now it seems like anaconda actually just throws firewalld into the
target package set in absolutely all cases, like it does with
authconfig, which I think is wrong. As the above makes clear, it only
really makes sense to use anaconda's mechanism for adding packages to
the to-be-installed set when they may or may not need to be installed
depending on the path taken through installation. If we really want
these to be in all installs, unconditionally, we should just put them in
the @core group in comps. For authconfig, this may be the correct way to
go. But for firewalld, it seems to me that so far as anaconda is
concerned, it only needs to go into the installed system if the user has
requested firewall configuration as part of the install, which I don't
believe is the default and in fact is only available through kickstarts
(so it's probably an uncommon case). It should be made conditional in
anaconda, anaconda should not be forcing it into the to-be-installed
package set in all cases.
We already have firewalld in the 'standard' set in comps, which seems
like about the right place for it - it'll be in most installs, but not
minimal ones, if anaconda gets fixed up.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
5:24 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, 2012-11-09 at 15:06 -0800, Adam Williamson wrote:
Right now it seems like anaconda actually just throws firewalld into
the
target package set in absolutely all cases, like it does with
authconfig, which I think is wrong. As the above makes clear, it only
really makes sense to use anaconda's mechanism for adding packages to
the to-be-installed set when they may or may not need to be installed
depending on the path taken through installation. If we really want
these to be in all installs, unconditionally, we should just put them in
the @core group in comps. For authconfig, this may be the correct way to
go. But for firewalld, it seems to me that so far as anaconda is
concerned, it only needs to go into the installed system if the user has
requested firewall configuration as part of the install, which I don't
believe is the default and in fact is only available through kickstarts
(so it's probably an uncommon case). It should be made conditional in
anaconda, anaconda should not be forcing it into the to-be-installed
package set in all cases.
We already have firewalld in the 'standard' set in comps, which seems
like about the right place for it - it'll be in most installs, but not
minimal ones, if anaconda gets fixed up.
So I just followed this up in IRC. It turns out that right now, anaconda
always (or at least by default) *does* touch the firewall: it opens up
port 22. So that's why firewalld is getting added to the to-be-installed
package set unconditionally. Given the current behaviour, that's
correct.
However, it seems like somewhat silly behaviour. If our default firewall
configuration is supposed to be 'port 22 open' we should express that in
our firewall package, not set a default in the firewall package then
have the installer change it. That's just needless complexity (and
results in the problem of firewalld being in the minimal install, where
it maybe doesn't actually need to be). So perhaps we should change
firewalld to default to opening port 22.
Jesse points out that this kind of discussion usually gets derailed in
spectacularly unhelpful directions:
<jlk> right
this usually gets us into an argument with the "community"
and people suggesting, then arguing against, packages shipping their
own firewall config
so whether ssh is open or not depends on if you install ssh
<jlk> then somebody mentions German privacy laws and the whole thread
goes nowhere.
So if you're going to follow up on this - there are fun discussions to
be had about the pros and cons of letting packages ship firewall
configs, but please don't do it in this thread, start a new one if you
must. Having firewalld ship a 'port 22 open' default may not be the best
way to do things in the best of all possible worlds, but it is at least
_more_ sensible than having the installer set the default firewall
policy. And for the love of God, please don't bring up German privacy
laws.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:39 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote:
it maybe doesn't actually need to be). So perhaps we should
change
firewalld to default to opening port 22.
+1, even having read the rest of this message.
Same with iptables if firewalld is not installed by default.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:46 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Fri, 2012-11-09 at 20:39 -0500, Matthew Miller wrote:
On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote:
> it maybe doesn't actually need to be). So perhaps we should change
> firewalld to default to opening port 22.
+1, even having read the rest of this message.
Same with iptables if firewalld is not installed by default.
Somehow it took me 45 minutes to notice the giant logic fail in my
thinking: if what we're trying to achieve is 'don't install firewalld in
a minimal install', obviously firewalld's default firewall configuration
is entirely irrelevant. To achieve the above, we don't need to make sure
that the default configuration leaves port 22 open when firewalld is
installed, but that the default configuration leaves port 22 open when
firewalld is *not* installed. D'oh.
We can still not bother poking the firewall configuration by default in
anaconda if firewalld's package default leaves port 22 open and
firewalld is being installed, which would still be a valuable
simplification of what anaconda has to do and is still a sensible
change, but obviously, we can't use that as a reason not to install
firewalld in a minimal install.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:15 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On 9 November 2012 18:46, Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2012-11-09 at 20:39 -0500, Matthew Miller wrote:
> On Fri, Nov 09, 2012 at 03:24:02PM -0800, Adam Williamson wrote:
> > it maybe doesn't actually need to be). So perhaps we should change
> > firewalld to default to opening port 22.
>
> +1, even having read the rest of this message.
>
>
> Same with iptables if firewalld is not installed by default.
Somehow it took me 45 minutes to notice the giant logic fail in my
thinking: if what we're trying to achieve is 'don't install firewalld in
a minimal install', obviously firewalld's default firewall configuration
is entirely irrelevant. To achieve the above, we don't need to make sure
that the default configuration leaves port 22 open when firewalld is
installed, but that the default configuration leaves port 22 open when
firewalld is *not* installed. D'oh.
Well with firewalld not installed and no iptables configs.. I would
believe that the default would be everything open... unless some other
program is there to set some defaults.
--
Stephen J Smoogen.
"Don't derail a useful feature for the 99% because you're not in it."
Linus Torvalds
"Years ago my mother used to say to me,... Elwood, you must be oh
so smart or oh so pleasant. Well, for years I was smart. I
recommend pleasant. You may quote me." —James Stewart as Elwood P. Dowd
1:40 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Sat, Nov 10, 2012 at 11:15:31AM -0700, Stephen John Smoogen wrote:
> is entirely irrelevant. To achieve the above, we don't need
to make sure
> that the default configuration leaves port 22 open when firewalld is
> installed, but that the default configuration leaves port 22 open when
> firewalld is *not* installed. D'oh.
Well with firewalld not installed and no iptables configs.. I would
believe that the default would be everything open... unless some other
This is indeed the case.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:31 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Sat, 2012-11-10 at 14:40 -0500, Matthew Miller wrote:
On Sat, Nov 10, 2012 at 11:15:31AM -0700, Stephen John Smoogen
wrote:
> > is entirely irrelevant. To achieve the above, we don't need to make sure
> > that the default configuration leaves port 22 open when firewalld is
> > installed, but that the default configuration leaves port 22 open when
> > firewalld is *not* installed. D'oh.
> Well with firewalld not installed and no iptables configs.. I would
> believe that the default would be everything open... unless some other
This is indeed the case.
And that's clearly not what we want. I thought it kind of went without
saying both that this would be the consequence of simply dropping
firewalld from the default install entirely, and that this would not be
acceptable :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:44 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Tue, Nov 13, 2012 at 04:31:46PM -0800, Adam Williamson wrote:
> > Well with firewalld not installed and no iptables configs..
I would
> > believe that the default would be everything open... unless some other
> This is indeed the case.
And that's clearly not what we want. I thought it kind of went without
saying both that this would be the consequence of simply dropping
firewalld from the default install entirely, and that this would not be
acceptable :)
Agreed. *Particularly* if Firewalld is the default but does not nicely cover
all needs. In the ideal world, one codebase would cover everything for all
of Fedora. I don't think we're ready for that for F18, even if we do go
ahead with making it the default, so we need to make sure that the fallback
position is secure.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
6:52 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Tue, 2012-11-13 at 19:44 -0500, Matthew Miller wrote:
On Tue, Nov 13, 2012 at 04:31:46PM -0800, Adam Williamson wrote:
> > > Well with firewalld not installed and no iptables configs.. I would
> > > believe that the default would be everything open... unless some other
> > This is indeed the case.
> And that's clearly not what we want. I thought it kind of went without
> saying both that this would be the consequence of simply dropping
> firewalld from the default install entirely, and that this would not be
> acceptable :)
Agreed. *Particularly* if Firewalld is the default but does not nicely cover
all needs. In the ideal world, one codebase would cover everything for all
of Fedora. I don't think we're ready for that for F18, even if we do go
ahead with making it the default, so we need to make sure that the fallback
position is secure.
Well, sure, but you seem to be drifting the discussion a bit (or I did,
I've been out of town for the weekend, it gets confusing). As I recall
things, the basic goal we were working towards in this thread was the
reduction of the size of the minimal install. And I was suggesting
taking firewalld out entirely as a way of achieving that, until I
realized that would be stupid.
I don't think that maintaining iptables/s-c-f forever as a 'lightweight
alternative' to firewalld is the way to go, here. I'm not advocating
that we put iptables in @core and firewalld in @standard, or anything
like that. Someone else might want to advocate that, but I'm not. Since
I now figured out to my own satisfaction that we can't just ditch
firewalld from the minimal install, the focus in the context of this
goal should be on reducing its dependency load.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
7:35 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Tue, Nov 13, 2012 at 04:52:47PM -0800, Adam Williamson wrote:
Well, sure, but you seem to be drifting the discussion a bit (or I
did,
I've been out of town for the weekend, it gets confusing). As I recall
things, the basic goal we were working towards in this thread was the
reduction of the size of the minimal install.
Sorry... I was drifting it into the other thread.
And I was suggesting taking firewalld out entirely as a way of
achieving
that, until I realized that would be stupid.
Well. I may be a little bit cynical on this, but I think the unsteered drift
of this kind of thing goes like this:
1. Shiny new feature covers the desktop case, so let's make it the default
in Fedora.
2. "Don't worry, if you have other needs, the old way still works".
3. So many things get updated to the new way that the old way isn't
reasonable anymore, but *those other use cases never get consideration*.
It's like step 2 magically covers the end game. But of course it doesn't.
I'm not against progress. The static firewall scripts don't cover a lot of
cases, and are particularly a pain with virt. But let's not jump ahead of
ourselves without at _least_ a plan.
So that's a little bit of a tangent, but, as outlined in the other thread, I
don't think firewalld is at a point where making it the default would be
a good for Fedora. Maybe it could be by F19. Reducing the dependency load is
just one part of that.
In the meantime, I think we should make sure a newly installed system with
either firewalld or the old thing (now called iptables-service) has a
sensible firewall out of the box. (Same all-closed-but-ssh as we've had
forever, I expect.)
like that. Someone else might want to advocate that, but I'm not.
Since
I now figured out to my own satisfaction that we can't just ditch
firewalld from the minimal install, the focus in the context of this
goal should be on reducing its dependency load.
I don't think we can "ditch" it, but we can certainly revert.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
7:50 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Tue, 2012-11-13 at 20:35 -0500, Matthew Miller wrote:
> like that. Someone else might want to advocate that, but I'm
not. Since
> I now figured out to my own satisfaction that we can't just ditch
> firewalld from the minimal install, the focus in the context of this
> goal should be on reducing its dependency load.
I don't think we can "ditch" it, but we can certainly revert.
Let's keep the threads separate then, to avoid my poor tiny brain
getting overheated. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:34 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 2:35 AM, Matthew Miller
<mattdm(a)fedoraproject.org> wrote:
Well. I may be a little bit cynical on this, but I think the
unsteered drift
of this kind of thing goes like this:
1. Shiny new feature covers the desktop case, so let's make it the default
in Fedora.
2. "Don't worry, if you have other needs, the old way still works".
3. So many things get updated to the new way that the old way isn't
reasonable anymore, but *those other use cases never get consideration*.
It's like step 2 magically covers the end game. But of course it doesn't.
That's not at all the case with firewalld. 2 ouf of 4 of the concerns
that led to firewalld being postponed in F17 were
server/enterprise-related, and AFAIK are now resolved. Yes, the
documentation is still not great, but that's something that can
realistically be improved before GA.
I'm not against progress. The static firewall scripts don't
cover a lot of
cases, and are particularly a pain with virt. But let's not jump ahead of
ourselves without at _least_ a plan.
AFAIK the major things for our usual use cases are covered, at least
going by the F17 criteria. Sure, there may be more things missing.
Looking at hour original warning flag: Squeezing every last megabyte
out of the running system for cloud is a really new thing that we
haven't historically required. Sure, it would be great to make
firewalld smaller (and rewriting firewalld to C is one of those things
that have been promised a long time ago and never happened), but I
don't really see that as a blocker.
So that's a little bit of a tangent, but, as outlined in the
other thread, I
don't think firewalld is at a point where making it the default would be
a good for Fedora. Maybe it could be by F19. Reducing the dependency load is
just one part of that.
In the meantime, I think we should make sure a newly installed system with
either firewalld or the old thing (now called iptables-service) has a
sensible firewall out of the box. (Same all-closed-but-ssh as we've had
forever, I expect.)
We _cannot_ have two different firewalls equally supported, each with
its own command line and API. Applications won't support both
equally, documentation won't support both equally, QA won't cover both
equally, users will be confused.
We'd get the 8-years duplication of init.d/network vs. NetworkManager
all over again, and I personally strongly want to avoid that (this was
a third of my FESCo election platform).
Mirek
6:43 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Wed, Nov 14, 2012 at 11:34:56AM +0100, Miloslav Trmač wrote:
AFAIK the major things for our usual use cases are covered, at least
going by the F17 criteria. Sure, there may be more things missing.
Adam asked to keep those other things to the other thread, so I'll just
touch on the dependency bloat issue here. I think there are other reasons it
is harmful to Fedora to go ahead before this is ready, though, which I'll
continue to address separately.
Looking at hour original warning flag: Squeezing every last megabyte
out of the running system for cloud is a really new thing that we
haven't historically required. Sure, it would be great to make
firewalld smaller (and rewriting firewalld to C is one of those things
that have been promised a long time ago and never happened), but I
don't really see that as a blocker.
Making it absolutely minimal isn't a blocker, but pulling X libraries into
the minimal install is. I think that will be resolved, reducing this
particular issue to being something for future improvement. If that can't be
resolved, then it alone should be sufficient cause to postpone the feature.
We _cannot_ have two different firewalls equally supported, each
with
its own command line and API. Applications won't support both
equally, documentation won't support both equally, QA won't cover both
equally, users will be confused.
I agree. That's why I'm so concerned that firewalld needs to be ready for
all reasonable cases before we switch to it. Again, more on that in the
other thread.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
8:23 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Miloslav Trmač wrote:
Looking at hour original warning flag: Squeezing every last megabyte
out of the running system for cloud is a really new thing that we
haven't historically required. Sure, it would be great to make
firewalld smaller (and rewriting firewalld to C is one of those things
that have been promised a long time ago and never happened), but I
don't really see that as a blocker.
The C rewrite should be treated as a requirement for being considered
anything other than a prototype.
We'd get the 8-years duplication of init.d/network vs.
NetworkManager
all over again, and I personally strongly want to avoid that (this was
a third of my FESCo election platform).
Well, I'm not too happy about having 2 ways of doing things either. However,
I really don't see the point of running a Python daemon to dynamically
control something I never change in the first place. Now, sure, firewalld
also does connection tracking and I'd personally have no problems running a
lightweight C daemon to handle that, but why on Earth does it have to be in
Python? And what about the many system administrators using handwritten
rules (see Harald Reindl's reply)? system-config-firewall is a Fedora-
specific UI with limited functionality which it makes sense to replace with
something more flexible, but iptables rules are a long-established cross-
distribution interface, won't firewalld stomp on those rules, by the way it
works?
Kevin Kofler
2:17 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, Nov 15, 2012 at 3:23 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
And what about the many system administrators using handwritten
rules (see Harald Reindl's reply)?
There is a --direct option that is supposed
to provide a
compatibility/escape mechanism with full iptables functionality (and
mostly same syntax). Last release cycle it appeared to work; testing
it with some demanding real-world scripts would be interesting.
Mirek
6:33 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Le jeudi 15 novembre 2012 à 03:23 +0100, Kevin Kofler a écrit :
iptables rules are a long-established cross-
distribution interface
Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian
offered several frontend, but IIRC, didn't use one by default.
And I have worked as firewall admin and developper, and while netfilter
is a impressive piece of work, this is more used as a framework than
anything. For example, one of the client wrote a script with automated
roolback in case of issue, and we ( my company ) wrote a tool to edit
rules without having to reload the whole firewall ( cause waiting 1
minutes to see if you crashed the whole network is not fun the 10 first
time ).
--
Michael Scherer
7:48 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 13:33, schrieb Michael Scherer:
Le jeudi 15 novembre 2012 à 03:23 +0100, Kevin Kofler a écrit :
> iptables rules are a long-established cross-
> distribution interface
Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian
offered several frontend, but IIRC, didn't use one by default
and they ALL using iptables/netfilter
so if you write a iptables.sh you get it run on ANY distribution
and that was the point
11:06 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, 2012-11-15 at 14:48 +0100, Reindl Harald wrote:
Am 15.11.2012 13:33, schrieb Michael Scherer:
> Le jeudi 15 novembre 2012 à 03:23 +0100, Kevin Kofler a écrit :
>> iptables rules are a long-established cross-
>> distribution interface
>
> Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian
> offered several frontend, but IIRC, didn't use one by default
and they ALL using iptables/netfilter
so if you write a iptables.sh you get it run on ANY distribution
and that was the point
Right. I hate to say it, but Harald is correct here: AFAIK, all those
and other firewall configuration mechanisms were ultimately just
UI/abstraction layers wrapped around iptables. They wrote iptables
rules. firewalld is very different.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:16 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 18:06, schrieb Adam Williamson:
On Thu, 2012-11-15 at 14:48 +0100, Reindl Harald wrote:
>
> Am 15.11.2012 13:33, schrieb Michael Scherer:
>> Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian
>> offered several frontend, but IIRC, didn't use one by default
>
> and they ALL using iptables/netfilter
>
> so if you write a iptables.sh you get it run on ANY distribution
> and that was the point
Right. I hate to say it, but Harald is correct here: AFAIK, all those
and other firewall configuration mechanisms were ultimately just
UI/abstraction layers wrapped around iptables. They wrote iptables
rules. firewalld is very different.
and that is why i hardly hope "iptables.service" will be available
parallel to "firewalld" because both satisfy different needs
* firewalld: desktops, standard-setups
* iptables: users maintaining since forever their rules per shellscripts
i am one of the second groups and doing DISTRIBUTED iptables-configurations
for whole infrastructures since many years and using here any capability
of iptables which can be hardly covered with abstraction layers
firewalld is helpful for most average users and a fine idea
iptables.service is for the pople needing 100% control of each
netfilter-rule and it would be a great fault to try include any
capability in firewalld because it would be too complex to use
and finally not satifsy both user groups
if it supports any comination you can do with a script containing
some hundret iptables-commands it would became overloaded for the
average user while most likely my usage could still only be covered
partly
the only things i need are:
* /usr/sbin/iptables
* /sbin/iptables-save > /etc/sysconfig/iptables
* a service loading "/etc/sysconfig/iptables" at startup
* not collide with firewalld or forced to use it
if this is possible and firewalld is the default i am
happy, my workload stays fine and firewalld satisfies
other user-types - a perfect combination and a real
improvement at all
12:02 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, Nov 15, 2012 at 6:16 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 15.11.2012 18:06, schrieb Adam Williamson:
> Right. I hate to say it, but Harald is correct here: AFAIK, all those
> and other firewall configuration mechanisms were ultimately just
> UI/abstraction layers wrapped around iptables. They wrote iptables
> rules. firewalld is very different.
(Side-reply to Adam:) I can't see the difference; /sbin/iptables still
works if you have firewalld running.
i am one of the second groups and doing DISTRIBUTED
iptables-configurations
for whole infrastructures since many years and using here any capability
of iptables which can be hardly covered with abstraction layers
It would be very helpful for judging the maturity/suitability of
firewalld if you could try converting your iptables script to
firewall-cmd --direct (which, at least I hope, should be possible to
do with a few sed commands), and report back whether the pass-through
capability is good enough.
Mirek
12:08 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 19:02, schrieb Miloslav Trmač:
On Thu, Nov 15, 2012 at 6:16 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 15.11.2012 18:06, schrieb Adam Williamson:
>> Right. I hate to say it, but Harald is correct here: AFAIK, all those
>> and other firewall configuration mechanisms were ultimately just
>> UI/abstraction layers wrapped around iptables. They wrote iptables
>> rules. firewalld is very different.
(Side-reply to Adam:) I can't see the difference; /sbin/iptables still
works if you have firewalld running.
> i am one of the second groups and doing DISTRIBUTED iptables-configurations
> for whole infrastructures since many years and using here any capability
> of iptables which can be hardly covered with abstraction layers
It would be very helpful for judging the maturity/suitability of
firewalld if you could try converting your iptables script to
firewall-cmd --direct (which, at least I hope, should be possible to
do with a few sed commands), and report back whether the pass-through
capability is good enough.
you CAN NOT easily convert iptables.sh scripts containing
hundrets of commands in a specific order which are well tested
over years and your replacment for any hardware firewall/router
this things are not written at once
this things are growed, optimized and maintained over years
this things are tested in zones where security is hardly needed
it is a bad idea to touch them and re-test it all in production
as you can IMPOSSIBLE build a infrastructure with tons of severs
and clients with very specific block/reject/allow in a test
environment without wasting hundrests of hours of your work
and the main problem: this thinhs are working fine since forever
you will have no benefit to convert them to something else
it is one thing to develop new tools and abstraction layers
a whole different story is throw away perfect workloads for nothing
in the time we discuss this here someone could maintain iptables.service
the next 20 years at all!
12:27 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, Nov 15, 2012 at 7:08 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 15.11.2012 19:02, schrieb Miloslav Trmač:
> It would be very helpful for judging the maturity/suitability of
> firewalld if you could try converting your iptables script to
> firewall-cmd --direct (which, at least I hope, should be possible to
> do with a few sed commands), and report back whether the pass-through
> capability is good enough.
you CAN NOT easily convert iptables.sh scripts containing
hundrets of commands in a specific order which are well tested
over years and your replacment for any hardware firewall/router
Have you actually _tried_? It's supposed to be as easy as
s/iptables/firewall-cmd --direct --passthrough ipv4/
I don't know for a fact whether it is good enough. You seem to have a
script that could tell us.
Mirek
12:30 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 19:27, schrieb Miloslav Trmač:
On Thu, Nov 15, 2012 at 7:08 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 15.11.2012 19:02, schrieb Miloslav Trmač:
>> It would be very helpful for judging the maturity/suitability of
>> firewalld if you could try converting your iptables script to
>> firewall-cmd --direct (which, at least I hope, should be possible to
>> do with a few sed commands), and report back whether the pass-through
>> capability is good enough.
>
> you CAN NOT easily convert iptables.sh scripts containing
> hundrets of commands in a specific order which are well tested
> over years and your replacment for any hardware firewall/router
Have you actually _tried_? It's supposed to be as easy as
s/iptables/firewall-cmd --direct --passthrough ipv4/
I don't know for a fact whether it is good enough. You seem to have a
script that could tell us.
i posted a script realier this day as .txt file with
masked network details, but it did not go trough list
moderation AFAIK until now
12:37 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, 15 Nov 2012 19:30:27 +0100
Reindl Harald <h.reindl(a)thelounge.net> wrote:
Am 15.11.2012 19:27, schrieb Miloslav Trmač:
> On Thu, Nov 15, 2012 at 7:08 PM, Reindl Harald
> <h.reindl(a)thelounge.net> wrote:
>> Am 15.11.2012 19:02, schrieb Miloslav Trmač:
>>> It would be very helpful for judging the maturity/suitability of
>>> firewalld if you could try converting your iptables script to
>>> firewall-cmd --direct (which, at least I hope, should be possible
>>> to do with a few sed commands), and report back whether the
>>> pass-through capability is good enough.
>>
>> you CAN NOT easily convert iptables.sh scripts containing
>> hundrets of commands in a specific order which are well tested
>> over years and your replacment for any hardware firewall/router
>
> Have you actually _tried_? It's supposed to be as easy as
> s/iptables/firewall-cmd --direct --passthrough ipv4/
>
> I don't know for a fact whether it is good enough. You seem to
> have a script that could tell us.
i posted a script realier this day as .txt file with
masked network details, but it did not go trough list
moderation AFAIK until now
Everyone on this list doesn't need a copy of your (lengthy) iptables
script, IMHO.
Perhaps the two of you could continue this off line and test and report
back to the list?
kevin
12:46 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 19:37, schrieb Kevin Fenzi:
>> Have you actually _tried_? It's supposed to be as easy
as
>> s/iptables/firewall-cmd --direct --passthrough ipv4/
>>
>> I don't know for a fact whether it is good enough. You seem to
>> have a script that could tell us.
>
> i posted a script realier this day as .txt file with
> masked network details, but it did not go trough list
> moderation AFAIK until now
Everyone on this list doesn't need a copy of your (lengthy) iptables
script, IMHO.
Perhaps the two of you could continue this off line and test and report
back to the list?
your argumentation is NOT helpful
i can NOT test a iptables.sh replace for a whole INFRASTRUCTURE
i can NOT post a unmasked version with ip-addresses and hostnames
i can NOT simulate a whole network with around 100 machines
even i could do this all, it wozld be VERY difficult to RE-AUDIT
the whole configuration and security-layers which are hardly
to explain because usually infrastructure and network-segments
you want to isolate in both directions is grwoing over years
and not there at once
and this is why REMOEV iptables.service would cause A LOT of work
and auditing while you risk security troubles while you are at
working on this for a more or less non existing benfit
this is why it would be NOT a good idea to remove "iptables.service"
some of this setups are hunderts of kilometers away
the "iptables.sh" there is the ROUTER
you can not test this remote because if you make a small mistake
you have lost the game and the remote network is down and having
everywhere lights-out-managment is a nice wish but in reality
you do NOT want LOM exposed to the internet, so it is BEHIND this
iptables-etups you play around
REALLY: there is nothing more i can say to this topic
it is not my decision if people drop iptables.service and make a
big wasting of ressources and security while doing this all over
the world - but people should keep in mind what damage they are
doing if acting this way
12:58 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, 2012-11-15 at 19:46 +0100, Reindl Harald wrote:
Am 15.11.2012 19:37, schrieb Kevin Fenzi:
>>> Have you actually _tried_? It's supposed to be as easy as
>>> s/iptables/firewall-cmd --direct --passthrough ipv4/
>>>
>>> I don't know for a fact whether it is good enough. You seem to
>>> have a script that could tell us.
>>
>> i posted a script realier this day as .txt file with
>> masked network details, but it did not go trough list
>> moderation AFAIK until now
>
> Everyone on this list doesn't need a copy of your (lengthy) iptables
> script, IMHO.
>
> Perhaps the two of you could continue this off line and test and report
> back to the list?
your argumentation is NOT helpful
i can NOT test a iptables.sh replace for a whole INFRASTRUCTURE
i can NOT post a unmasked version with ip-addresses and hostnames
i can NOT simulate a whole network with around 100 machines
I don't think anyone asked you to do any of those things. Fedora
obviously does not have the power to replace iptables with firewalld on
your router, so the question is not 'can you replace iptables with
firewalld on everything in your network and see if it works'. The
question is more 'can you see if firewalld does a good job of imitating
iptables on a single Fedora machine on your network, or a small amount
of them'. The whole point is it should be able to imitate an
iptables-type setup fairly transparently, so it should 'play nice' with
the rest of your setup. Can't you just test that?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:06 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 19:58, schrieb Adam Williamson:
I don't think anyone asked you to do any of those things. Fedora
obviously does not have the power to replace iptables with firewalld on
your router, so the question is not 'can you replace iptables with
firewalld on everything in your network and see if it works'. The
question is more 'can you see if firewalld does a good job of imitating
iptables on a single Fedora machine on your network, or a small amount
of them'. The whole point is it should be able to imitate an
iptables-type setup fairly transparently, so it should 'play nice' with
the rest of your setup. Can't you just test that?
and that is why i posted earlier this day a masked copy of the script
ONE script distributed from a admin-server is deplayoed to ANY
machine and exuted with "ssh root@machine /scripts/iptables.sh"
this thing was written, optimized and maintained for many years
it containes rules to block specific outgoing AND incoming
connections in a more or less dynmic infrastructure
there is no "this is the iptables of machine X"
i am not only responsible for ONE network, there are finally
MANY networks, they are more or less based on this one script
the reason is simply that if you have, can and do maintain
larger environemnts more or less a a one-man-show you need to
find workloads and solutions to surivive this which is achievd
since years - starting tis from scratch means wasting weeks of
lifetime
don't get me wrong: force this would be no improvement
finally: i am pretty sure that my environments are even SMALL
compared with many others out there, iptables-service is a one-shot
thing at startup, low-level this all is netfilter of the kernel
so i refuse to understand any sense removing the iptables command
and "iptables.service" to replace it for the sake of replacment
if your argumentation would be this direction i would say
"so why do we not remove XFCE, GNOME whatever because KDE exists"
12:10 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, 2012-11-15 at 19:02 +0100, Miloslav Trmač wrote:
On Thu, Nov 15, 2012 at 6:16 PM, Reindl Harald
<h.reindl(a)thelounge.net> wrote:
> Am 15.11.2012 18:06, schrieb Adam Williamson:
>> Right. I hate to say it, but Harald is correct here: AFAIK, all those
>> and other firewall configuration mechanisms were ultimately just
>> UI/abstraction layers wrapped around iptables. They wrote iptables
>> rules. firewalld is very different.
(Side-reply to Adam:) I can't see the difference; /sbin/iptables still
works if you have firewalld running.
Sure, but the background here was the 'replace vs. augment' question -
is firewalld actually planned to replace iptables in the long run, or
are we committed to maintaining iptables as an alternative mechanism? It
sounds like harald would be happy if the latter is the case.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
12:16 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, Nov 15, 2012 at 7:10 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
On Thu, 2012-11-15 at 19:02 +0100, Miloslav Trmač wrote:
> On Thu, Nov 15, 2012 at 6:16 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote:
> > Am 15.11.2012 18:06, schrieb Adam Williamson:
> >> Right. I hate to say it, but Harald is correct here: AFAIK, all those
> >> and other firewall configuration mechanisms were ultimately just
> >> UI/abstraction layers wrapped around iptables. They wrote iptables
> >> rules. firewalld is very different.
>
> (Side-reply to Adam:) I can't see the difference; /sbin/iptables still
> works if you have firewalld running.
Sure, but the background here was the 'replace vs. augment' question -
is firewalld actually planned to replace iptables in the long run, or
are we committed to maintaining iptables as an alternative mechanism? It
sounds like harald would be happy if the latter is the case.
(as far as I understand the situation:) iptables as a kernel
interface and a low-level command will exist, but applications will
expect the existence of the firewalld D-Bus service (as opposed to the
system-config-firewall D-Bus service, at least; I'm not sure what this
implies about systems where the firewalld D-Bus service is not
available), and firewall-cmd, not iptables, will be the recommended
user tool.
In fact, not "applications will expect...", but "applications already
expect" - this is already the case with anaconda, control-center and
perhaps other applications.
Mirek
12:23 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 15.11.2012 19:16, schrieb Miloslav Trmač:
(as far as I understand the situation:) iptables as a kernel
interface and a low-level command will exist, but applications will
expect the existence of the firewalld D-Bus service (as opposed to the
system-config-firewall D-Bus service, at least; I'm not sure what this
implies about systems where the firewalld D-Bus service is not
available), and firewall-cmd, not iptables, will be the recommended
user tool
and this is the reason why i say CAUTIOn
i do not want nor can i accept anything on MY machines
expect anything to deal with iptables-rules. i am the only
on e instance to define what is open and closed and with
which REJECT or DROP answer what is closed
nobody and nothing has to touch this dynamically
if a application needs a port open i am the one to open it and
if not you can be sure there is a good reason why it stays
closed - the reason is security and professional it-managment
i am responsible for my data, comanies data and data of many
customers so i have to be the instance to control every piece
of software - on servers and static setups there is no need for
dynmaic connifurations - the opposite is true: you need to disable
and close ANYTHING and allow NOTHING where you are not 100% sure
that you aware what is done
these things will not change tomorrow nor in 20 years and the
palces where they are changed you read regulary in the newspaper
because intrusions and security leaks!
12:17 p.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
On Thu, Nov 15, 2012 at 10:10:43AM -0800, Adam Williamson wrote:
Sure, but the background here was the 'replace vs. augment'
question -
is firewalld actually planned to replace iptables in the long run, or
are we committed to maintaining iptables as an alternative mechanism? It
sounds like harald would be happy if the latter is the case.
One approach: firewalld could have a "direct-only" mode. If that mode were
enabled, it'd load a static script from from /etc/sysconfig/iptables on
launch, and respond to any commands other than the "direct" api with an
"in
direct-only mode" error. Then, firewalld-aware applications could choose to
raise a user error or to go to whatever fallback they have.
--
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>
3:15 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Le jeudi 15 novembre 2012 à 09:06 -0800, Adam Williamson a écrit :
On Thu, 2012-11-15 at 14:48 +0100, Reindl Harald wrote:
>
> Am 15.11.2012 13:33, schrieb Michael Scherer:
> > Le jeudi 15 novembre 2012 à 03:23 +0100, Kevin Kofler a écrit :
> >> iptables rules are a long-established cross-
> >> distribution interface
> >
> > Not really. For example, ubuntu use ufw, mandriva used shorewall. Debian
> > offered several frontend, but IIRC, didn't use one by default
>
> and they ALL using iptables/netfilter
>
> so if you write a iptables.sh you get it run on ANY distribution
> and that was the point
Right. I hate to say it, but Harald is correct here: AFAIK, all those
and other firewall configuration mechanisms were ultimately just
UI/abstraction layers wrapped around iptables. They wrote iptables
rules. firewalld is very different.
Usually, if you use shorewall, nuface, ufw, etc and iptables side by
side, there is inconsistency.
As long iptables exist, you will have to do the exact same thing :
- disable the firewall of the distribution ( which is already a non
portable part of the installation )
- run either :
- a script with lots of iptables calls ( quite awful, slow and
unauditable in practice as Reindl explained in another mail, and as I
too often seen at customers deployment )
- a script that run 1 command, iptables-restore < file. Which is
equally as awful and unauditable, but faster.
I do not see what firewalld would change to that. Disable it, run what
you want instead.
The only issue is always the same, if you want to run 2 systems side by
side, you have to make work to integrate them. For example, shorewall
will set the default policy for a table, create new one, flush the
current one, etc. So as a sane iptables scripts will do the same, you
cannot run them one after the other and expect things to work smoothly.
And for firewalld, the problem is that firewalld do stuff that a simple
script cannot, namely offering a dbus interface, and so the script
cannot simply replace firewalld ( and never will ). Previous systems
were simple enough that you could just remove them and do the work by
hand. Firewalld provides more and if applications do not cope with non
existant firewalld, then this will be bad.
However, I do not expect having a hard dependency on it for a few years,
since this would mean that such applications no longer work on
distribution that do not ship firewalld ( like for example current
version of RHEL ).
--
Michael Scherer
1:35 p.m.
New subject: Setting the default firewall configuration
Michael Scherer <misc(a)zarb.org> writes:
- a script with lots of iptables calls ( quite awful, slow and
unauditable in practice as Reindl explained in another mail, and as I
too often seen at customers deployment )
- a script that run 1 command, iptables-restore < file. Which is
equally as awful and unauditable, but faster.
Or (because you mention some flaws of plain 'iptables'),
- create input for iptables-restore; this is fast, maintainable and
(depending on your environment) auditable. E.g.:
| [root@siggi ~]# time service firewall restart
| Logging current iptables counters [ OK ]
| firewall beenden: [ OK ]
| firewall starten: [ OK ]
| Recording fallback firewall-ipv4 configuration [ OK ]
|
| real 0m2.070s
| user 0m1.453s
| sys 0m0.258s
(the critical phase of flushing + creating rules takes <1 second)
| [root@siggi ~]# iptables -L -n | wc -l
| 1963
Parts of these rules (in total, there are >2000 lines of (commented!)
shell code) are shown in
http://ensc.de/fedora/gw.rules
Workstations and servers get a more simple version of this like
http://ensc.de/fedora/firewall-ipv4.rules
'./firewall.simple' is deployed company-wide but contains too much
internal information to publish it; sorry...
Mentioned functions are defined in
http://ensc.de/fedora/functions.firewall
and there is not needed more than bash and iptables tools.
I do not have problems with firewalld being installed by default. But it
must never be mandatory (e.g. not pulled in by anaconda implicitly) and
it must be easy to disable it when it was installed for other purposes
(e.g. to have its man-pages on the system).
Enrico
3:54 a.m.
New subject: Setting the default firewall configuration (was Re: Attention, dependency fighters)
Am 14.11.2012 01:52, schrieb Adam Williamson:
I don't think that maintaining iptables/s-c-f forever as a
'lightweight
alternative' to firewalld is the way to go
IT IS the way to go!
not as default, not supported via GUI is OK
but iptables.service and "configuration" with shellscripts is what
in many professional usecases is needed, the only thing which is
needed by administrators is the iptables-command and iptables.service
loading "/etc/sysconfig/iptables" at startup
so you can satisfy the desktop users with GUI/firewalld and
do not punish professional users with iptables-rules you
never can put in any GUI
4189
days inactive
4198
days old
52 comments
16 participants
participants (16)
-
Adam Williamson -
Bill Nottingham -
Enrico Scholz -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Kevin Kofler -
Lennart Poettering -
Matthew Miller -
Matthias Clasen -
Michael Scherer -
Miloslav Trmač -
Nicolas Mailhot -
Peter Robinson -
Reindl Harald -
Stephen John Smoogen -
Thomas Woerner