Tom Eastep wrote: > ... > Activity on the mailing lists and IRC channel has been steadily declining > for the last couple of years. This signals to me that the rate at which > people are adopting Shorewall is waning (I grant that the documentation has > gotten better over the years which helps lower the noise level somewhat). > While I've never had any ambitions toward dominating the OSS firewall > market, Shorewall takes a lot of work so I would prefer to spend my effort > on something that people want to use. Maybe it is still Shorewall -- maybe > it is something else.
Tom, sorry i haven't had a chance to comment on this yet. I think it's important that we target Shorewall at the right features for our audience. (Perhaps we're due for another survey? :-) > ... > My list of the major Shorewall shortcomings: > > 1) No GUI (other than Webmin). That is something that I personally am > unlikely to change because I have no interest in spending my time > developing one. Besides, first attempts at GUI creation tend to have > disappointing results at best. I really don't get this. I've never understood why people think it's an issue. Shorewall's configuration files don't lend themselves to GUIs. I mean, presenting things in a spreadsheet-like table isn't *that* critical, is it? Any focus on GUIs should be directed towards Webmin, IMO. > ... > 2) Performance and scaling issues. Shorewall is being used in larger and > more complex configurations and the time required to run the generated > script increases non-linearly with configuration complexity. This has > been a common theme on the mailing list recently. Performance of the > shell-based compiler is also awful when dealing with large complex > configurations. I think this is the biggie. It's one of the most common complaints (along with 4 below), and experienced IT professionals are our biggest user base. > 3) No IPv6 Support. We've talked about this before. I would rate this as important, but not as high a priority as 2 & 4. > 4) Lack of an ability to make quick "on the fly" configuration changes (this > is closely related to the performance problem -- if "shorewall restart" > always took less that a second, I don't believe that this would be an > issue). I agree. > Resolving these issues will require considerable change to the current > shell-based product and I suspect that just adding IPv6 support would make > the performance problem even worse. My feeling is that the current > shell-based implementation has gone about as far as it can go and that > adding additional major function to it while trying to maintain even the > current mediocre level of performance will be difficult. My gut feel is to leave off IPv6 until after the rewrite. > I have begun some experimentation with rewriting the compiler in Perl and > that is looking promising. Converting to Perl will unfortunately present > migration/compatibility issues with compile-time extension scripts although > I've been able to retain shorewall.conf and /etc/shorewall/params > functionality for the most part. You know my feelings about perl - it is so much better a language for string processing than shell. I think it would cut your code size substantially, and thus result in much more maintainable and bug-free code, as long as you don't write it like a typical perl programmer (which i already know you aren't ;-). > ... > Here are a couple of possible approaches to the run-time performance problem. > > a) Keep the current zone-policy-rule paradigm but have the > compiler generate 'iptables-restore' input. > > This is clearly preferable to the current approach of running > iptables repeatedly in the compiled script. We would still be stuck > with the order (n**2) scaling issues inherent in that paradigm > (see http://www.shorewall.net/ScalabilityAndPerformance.html). I suspect iptables-restore would give us enough of a performance boost that the O(n**2) issues could be ignored for a bit longer. :-) > b) Consider other paradigms which do not suffer from the scaling issues > implicit in zone-policy-rule. > > For example, I'm familiar with one organization that has created a > firewall configuration tool based on a service-policy-rule > paradigm which scales much better. Can you explain the service-policy-rule paradigm a little more (pointing us to some documentation would be fine)? The zone-policy-rule paradigm is the main reason i was first attracted to Shorewall, and i wouldn't depart from it without being thoroughly convinced of the merits of a different approach. > Both approaches present migration/compatibility issues. Approach a) > maintains compatibility with the tabular config files from earlier Shorewall > releases but would likely invalidate most runtime extension scripts. We > could probably continue to call the product "Shorewall" though as the > changes would be more evolutionary than revolutionary. Approach b) is > clearly a new product -- "Shorewall-ng" or something. It may eventually come to that, but i'm not sure it's time for a new Shorewall product just yet. You've managed mostly to maintain backwards compatibility for much longer than most Free Software projects exist. That is a good thing, and has resulted in a lot of people saving a lot of time. > Approach a) is not as straight-forward as it might first appear. To > accommodate Shorewall Lite, the compiler cannot simply create a single > monolithic iptables-restore file because part of the contents of that file > cannot be determined until run-time (all uses of 'detect' for example). So > at run-time, the script still has to perform some configuration analysis > then glue together an iptables-restore file that is appropriate for the > current configuration. Obviously, if the complexity of this approach makes it infeasible, another approach may be needed, but it seems like the next logical step. > So long as we are discussing what to add to Shorewall, it is also worth > asking what the next version of the product can leave behind. Given that > BRIDGING=Yes won't work with kernel version 2.6.20 and later, that feature > is a rather obvious choice for elimination. ECN is now widely deployed on > the Internet so /etc/shorewall/ecn might also be a candidate for extinction. > Are there others? I've never used either of them, so i don't mind. One thing that i think would be good to add, however, would be some more idiot proofing of the multi-ISP support (initially, an option to set up all of the masqing automatically - there may be other improvements that could be made as well). This isn't a high priority, but i think it would reduce the support load. -- Paul <http://paulgear.webhop.net> -- A: Because it breaks the logical sequence of discussion. Q: Why shouldn't i write my replies at the top of emails?
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
