New features include:
1) "shorewall refresh" now reloads the traffic shaping rules (tcrules
and tcstart).
2) "shorewall debug [re]start" now turns off debugging after an error
occurs. This places the point of the failure near the end of the
trace rather than up in the middle of it.
3) "shorewall [re]start" has been speeded up by more than 40% with
my configuration. Your milage may vary.
4) A "shorewall show classifiers" command has been added which shows
the current packet classification filters. The output from this
command is also added as a separate page in "shorewall monitor"
5) ULOG (must be all caps) is now accepted as a valid syslog level and
causes the subject packets to be logged using the ULOG target rather
than the LOG target. This allows you to run ulogd (available from
www.gnumonks.org/projects/ulogd) and log all Shorewall messages to
a separate log file.
6) If you are running a kernel that has a FORWARD chain in the mangle
table ("shorewall show mangle" will show you the chains in the
mangle table), you can set MARK_IN_FORWARD=Yes in
shorewall.conf. This allows for marking inbound packets based on
their destination even when you are using Masquerading or SNAT.
7) I have cluttered up the /etc/shorewall directory with empty
''init'',
''start'', ''stop'' and
''stopped'' files. If you already have a file with
one of these names, don''t worry -- the upgrade process
won''t
overwrite your file.
8) I have added a new RFC1918_LOG_LEVEL variable to
shorewall.conf. This variable specifies the syslog level at which
packets are logged as a result of entries in the
/etc/shorewall/rfc1918 file. Previously, these packets were always
logged at the ''info'' level.
Happy New Year!
-Tom
--
Tom Eastep \ Shorewall - iptables made easy
Shoreline, \ http://shorewall.sf.net
Washington USA \ teastep@shorewall.net
Geesh, Spent the entire day, today, upgrading to the beta version... Ok, is there any big changes between the beta version, and this version..... If not, then I''ll just keep the beta running until 1.3.13 comes out, seeing that shorewall gets an update every other 2 months.. Have a nice new year> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net]=20 > Sent: Friday, December 27, 2002 21:11 > To: Shorewall Users; Shorewall Announcements > Subject: [Shorewall-users] Shorewall 1.3.12 Released >=20 >=20 > New features include: >=20 > 1) "shorewall refresh" now reloads the traffic shaping rules (tcrules > and tcstart). >=20 > 2) "shorewall debug [re]start" now turns off debugging after an error > occurs. This places the point of the failure near the end of the > trace rather than up in the middle of it. >=20 > 3) "shorewall [re]start" has been speeded up by more than 40% with > my configuration. Your milage may vary. >=20 > 4) A "shorewall show classifiers" command has been added which shows > the current packet classification filters. The output from this > command is also added as a separate page in "shorewall monitor" >=20 > 5) ULOG (must be all caps) is now accepted as a valid syslog level and > causes the subject packets to be logged using the ULOG=20 > target rather > than the LOG target. This allows you to run ulogd (available from > www.gnumonks.org/projects/ulogd) and log all Shorewall messages to > a separate log file. >=20 > 6) If you are running a kernel that has a FORWARD chain in the mangle > table ("shorewall show mangle" will show you the chains in the > mangle table), you can set MARK_IN_FORWARD=3DYes in > shorewall.conf. This allows for marking inbound packets based on > their destination even when you are using Masquerading or SNAT. >=20 > 7) I have cluttered up the /etc/shorewall directory with empty ''init'', > ''start'', ''stop'' and ''stopped'' files. If you already have a=20 > file with > one of these names, don''t worry -- the upgrade process won''t > overwrite your file. >=20 > 8) I have added a new RFC1918_LOG_LEVEL variable to > shorewall.conf. This variable specifies the syslog level at which > packets are logged as a result of entries in the > /etc/shorewall/rfc1918 file. Previously, these packets were always > logged at the ''info'' level. >=20 > Happy New Year! > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.sf.net > Washington USA \ teastep@shorewall.net >=20 > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@shorewall.net=20 > http://www.shorewall.net/mailman/listinfo/shor> ewall-users >=20
--On Friday, December 27, 2002 09:58:45 PM +0100 "Reginald R. Richardson" <whiz.kid@tyarosh.homeip.net> wrote:> Geesh, > > Spent the entire day, today, upgrading to the beta version... > > Ok, is there any big changes between the beta version, and this > version.....This version is identical to Beta 3 with the exception of some cleanup of the documentation and comments in the config files. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
--On Friday, December 27, 2002 01:01:11 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > > --On Friday, December 27, 2002 09:58:45 PM +0100 "Reginald R. Richardson" > <whiz.kid@tyarosh.homeip.net> wrote: > >> Geesh, >> >> Spent the entire day, today, upgrading to the beta version... >>I''m curious why it takes you an entire day to upgrade -- it takes me a couple of minutes using the RPM. Are you running LEAF/Bering? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
Yep, using bearing.... But u see, don''t know exactly what your change in your settings files, I know I can just copy my old setting, such as, params, zones,rules etc, over to the new version, but I have noticed in your past upgrades, that u does put some new examples, and different comments in these files, so I love to keep them attached, so I can read them letter on, when adding more changes.. So basically what I does, I copy the params, zones, and the rest I does manually key all over again, untill I''m a shorewall guru, then I can just merge, copy, paste, etc But actually didn''t take the entire day..., I did it on a test system first, validate it, make sure it was working, but it took some time longer today, cause after the upgrade, my DNS server started playing stupid, and since, I upgrade the FIREWALL, I spent some 2 hour looking for the problem on the firewall, after the battle, I just restart the w2k DNS server, and problem was solved, probably I should have done that from the beginning, knowing, that it''s Microsoft.....> -----Original Message----- > From: Tom Eastep [mailto:teastep@shorewall.net]=20 > Sent: Friday, December 27, 2002 22:07 > To: Reginald R. Richardson; Shorewall Users > Subject: RE: [Shorewall-users] Shorewall 1.3.12 Released >=20 >=20 >=20 >=20 > --On Friday, December 27, 2002 01:01:11 PM -0800 Tom Eastep=20 > <teastep@shorewall.net> wrote: >=20 > > > > > > --On Friday, December 27, 2002 09:58:45 PM +0100 "Reginald R.=20 > > Richardson" <whiz.kid@tyarosh.homeip.net> wrote: > > > >> Geesh, > >> > >> Spent the entire day, today, upgrading to the beta version... > >> >=20 > I''m curious why it takes you an entire day to upgrade -- it=20 > takes me a=20 > couple of minutes using the RPM. Are you running LEAF/Bering? >=20 > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://shorewall.sf.net > Washington USA \ teastep@shorewall.net >=20 >=20
--On Friday, December 27, 2002 11:18 PM +0100 "Reginald R. Richardson" <whiz.kid@tyarosh.homeip.net> wrote:> Yep, using bearing.... > > But u see, don''t know exactly what your change in your settings files, I > know I can just copy my old setting, such as, params, zones,rules etc, > over to the new version, but I have noticed in your past upgrades, that > u does put some new examples, and different comments in these files, so > I love to keep them attached, so I can read them letter on, when adding > more changes..I personally take a different approach. I use the comments in the config files when initially configuring a product. Once the product is running to my satisfaction, I strip all comments from the files. This does two things: a) It makes the product [re]start a little faster. b) It makes me refer to the current product documentation when I want to make a change later and prevents me from misconfiguring the product based on stale comments in my config files. For me, it makes a lot more sense then spending my time tediously updating comments in configuration files.> > So basically what I does, I copy the params, zones, and the rest I does > manually key all over again, untill I''m a shorewall guru, then I can > just merge, copy, paste, etcI don''t think that you need to do that -- you just need to use the documentation more effectively.> > But actually didn''t take the entire day..., I did it on a test system > first, validate it, make sure it was working, but it took some time > longer today, cause after the upgrade, my DNS server started playing > stupid, and since, I upgrade the FIREWALL, I spent some 2 hour looking > for the problem on the firewall, after the battle, I just restart the > w2k DNS server, and problem was solved, probably I should have done > that from the beginning, knowing, that it''s Microsoft.....You''re not the first to fall into the "I just changed that so it must be the source of all problems" syndrome :-) -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
cheers( Tom );> I personally take a different approach. I use the comments in the config > files when initially configuring a product. Once the product is running to > my satisfaction, I strip all comments from the files. This does two things: > > a) It makes the product [re]start a little faster. > b) It makes me refer to the current product documentation when I want to > make a change later and prevents me from misconfiguring the product based > on stale comments in my config files. > > For me, it makes a lot more sense then spending my time tediously updating > comments in configuration files.Yeah, that seems to be a good idea on config-files with a lot of documentation -- like the files is /etc/shorewall. But what about those files exactly? There are at least the last lines, telling me, _not_ to delete them. Are they really used? Or can I just safely delete them? .karsten -- char *t="\10pse\0r\0dtu\0.@ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4"; main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1: (c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}
upps( sorry ); Forgot to switch my from address -- luckily this list accepts posts from unsubscribed email addresses. (Or is this a misconfiguration, Tom?) .karsten -- Hi, I''m a signature virus. Copy me into your ~/.signature to help me spread!
--On Saturday, December 28, 2002 02:25:06 PM +0100 kb <kb@bluehash.de> wrote:> upps( sorry ); > > Forgot to switch my from address -- luckily this list accepts posts from > unsubscribed email addresses. (Or is this a misconfiguration, Tom?) >No, I don''t insist that folks subscribe to ask a question. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
--On Saturday, December 28, 2002 01:54:18 PM +0100 guenther <guenther@rudersport.de> wrote:> But what about those files exactly? There are at least the last lines, > telling me, _not_ to delete them. Are they really used? Or can I just > safely delete them? >The reason for those lines is that the bash ''read'' command will ignore the last line of a file if the line isn''t terminated with a ''newline'' (linefeed) character. By having a comment line at the end of the file, I''m ensuring that the last line containing configuration information is so terminated. You are free to remove it -- just don''t send any problem reports claiming that Shorewall is ignoring a line in that config file.... FWIW, I leave those lines in my files because I''ve been bitten by that problem myself. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://shorewall.sf.net Washington USA \ teastep@shorewall.net
cheers();> > But what about those files exactly? There are at least the last lines, > > telling me, _not_ to delete them. Are they really used? Or can I just > > safely delete them? > > > > The reason for those lines is that the bash ''read'' command will ignore the > last line of a file if the line isn''t terminated with a ''newline'' > (linefeed) character. By having a comment line at the end of the file, I''m > ensuring that the last line containing configuration information is so > terminated. You are free to remove it -- just don''t send any problem > reports claiming that Shorewall is ignoring a line in that config file....Ah, I see. Then I can safely delete those next time. I always leave a really blank line at the end of every config file for readability with cat. Thanks for that info. Fast as always, Tom... .karsten -- Hi, I''m a signature virus. Copy me into your ~/.signature to help me spread!