Hi, I was wondering if someone else thought about going deeper into the dynamic approach. For example, it whould be nice to have some statement/configuration control embebbed on config files:
Today: #----------------------------------- #Rules to my not-always-up device: INCLUDE rules-eth6.inc #----------------------------------- Tomorrow :) ----------------------------------- #Rules to my not-always-up device: INCLUDE <maybe-a-shell-based-test> rules-eth6.inc ----------------------------------- I know this kind of thing would make shorewall much more complex but I think It whould bring some nice new possibilities. I think 'doing things on-the-fly' helps a lot on other problems like 'improving shorewall suppport for automated (non-human) dynamic reconfiguration', and suddenly, I´m not so sure it´s only about speed. Tanks, Longarai Thursday, March 1, 2007, 7:46:55 PM, you wrote: > 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. ------------------------------------------------------------------------- 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
