It would be nice if shorewall checked that at least the mandatory options are turned on in the kernel so that one does not need to go hunting for them.
(In reply to comment #0) > It would be nice if shorewall checked that at least the mandatory options are > turned on in the kernel so that one does not need to go hunting for them. It's difficult to define what is "mandatory" and what is not. It all depends on the type of connection you're using. A user might "require" MPPE for a PPTP connection (as in "mandatory requirement" since without it his/her system wouldn't connect) but then most users usually don't need this feature in the kernel or as a module. Also, the minimal setup is the "standalone firewall" as described here: http://www.shorewall.net/standalone.htm The "default kernel" should work out-of-the-box in this setup. (correct me if I'm wrong) Another issue would be to document all netfilter-related kernel options within the ebuild and optionally allow the user to auto-filter the kernel's .config file with a quick menu (eg. ebuild shorewall.ebuild config). But I think that would be hard to maintain as new kernel options keep appearing, some go obsolete and sometimes others change their names (personally I've seen that for SCSI controllers). This said, I too believe that it's a bit of a drag hunting down all kernel options. Fortunately, kernel compilations aren't that frequent :-)
betelgeuse: which ones would you consider "required"?
(In reply to comment #2) > betelgeuse: which ones would you consider "required"? > Modules marked as essential in /etc/shorewall/modules at least. I would make the error description show that these are probably not enough.
What about the situation where you install shorewall as a binpkg? The package builder may not have any of the firewalling kernel modules enabled, and why should it? Failing those modules will cause the package to fail to build; is that the right thing?
(In reply to comment #4) > What about the situation where you install shorewall as a binpkg? The package > builder may not have any of the firewalling kernel modules enabled, and why > should it? Failing those modules will cause the package to fail to build; is > that the right thing? > That would be an argument against any package that currently tests kernel config. I think there could be support for user disabling those tests as this has come up before.
Delaying it a bit, net kernel interface has quite some renamings atm. Let's do this when things have settled
