On Sun, 14 Jun 2009 18:34:52 +0100 Matthew Garrett <mjg@xxxxxxxxxx> wrote: > On Sun, Jun 14, 2009 at 06:13:51PM +0200, Julian Aloofi wrote: > > > So, solving this is pretty easy, even for newbies. But I agree that > > the error message will not help someone without advanced knowledge. > > Although I think people running Samba generally will know where to > > look for the problem. > > I think this is actually a problem that needs solving. We have > several network services that are either installed by default or > might be expected to be part of a standard setup, but which don't > work because of the default firewall rules. The Anaconda people have > (sensibly, IMHO) refused to simply add further exceptions to the > firewall policy. > > So, what should happen here? Should we leave the firewall enabled in > these cases* by default and require admins to open them? If so, is > there any way that we can make this easier in some > Packagekit-oriented manner? If not, how should we define that > packages indicate that they need ports opened? Should this be handled > at install time or run time? > > * The case that I keep hitting is mDNS resolution, which requires > opening a hole in the firewall I keep wondering if we couldn't come up with something like a /etc/iptables.d/ type setup somehow that would work for these cases. In the case of a package that does not need any configuration done and only needs a firewall rule to function, we could add a file in there to add it's rule. For cases of packages that DO need to be configured, add a file, but have it disabled/commented until the service is configured. This could be done by hand, or when someone runs a system-config-whatever and finishes configuring, the rules could be enabled by the tool as part of a 'make live' or 'activate' or something. If we had something like this, packages could ship their own /etc/iptables.d files. Just a thought. kevin
Attachment:
signature.asc
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list