Beta 1 is now available for testing.
----------------------------------------------------------------------------
P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) The Shorewall-init installer now installs the proper init script on
Redhat and Fedora.
2) A typo has been corrected in the blrules man pages.
3) Previously, if the interface appearing in the HOSTS column of
/etc/shorewall6/hosts was not defined in
/etc/shorewall6/interfaces, then the compiler would terminate with
a Perl diagnostic:
Can''t use an undefined value as a HASH reference at
/usr/share/shorewall/Shorewall/Zones.pm line 1817,
<$currentfile> line ...
----------------------------------------------------------------------------
K N O W N P R O B L E M S R E M A I N I N G
----------------------------------------------------------------------------
1) On systems running Upstart, shorewall-init cannot reliably secure
the firewall before interfaces are brought up.
----------------------------------------------------------------------------
N E W F E A T U R E S I N T H I S R E L E A S E
----------------------------------------------------------------------------
1) Support is now included for IMQ. This takes the form of of
IMQ(<number>) in the MARK/CLASSIFY column of
/etc/shorewall/tcrules.
2) It is no longer necessary to specify a MARK value for the default
class under a device that does not specify the ''classify''
option. Simple set the MARK column to ''-'' in the default
class.
3) Previously, the install scripts included in the Shorewall packages
were very restrictive. They could either be run to install directly
onto the system in a distribution-dependent way, or they could
install into a directory in a distribution-independent way. This
limited their usefullness to packagers.
Beginning with this release, the install scripts handle the install
system and the target system independently. When running an
installer, the following environmental variables can be set:
a) INSTALLSYS - Describes the system where the installer is
running. Accepted values are:
CYGWIN - Cygwin running under a Microsoft OS
MAC - OS X
DEBIAN - Debian
REDHAT - Redhat,Centos,Foobar,etc.
FEDORA - Fedora
SLACKWARE - Slackware
ARCHLINUX - Arch Linux
LINUX - Generic Linux
INSTALLSYS is not set, then the installer uses its existing
algorithm for detecting the current OS and distribution.
b) TARGET - Describes the system where the installed package
will run.
- For Shorewall and Shorewall6, the possible values are
the same as for INSTALLSYS. The values REDHAT and FEDORA are
synonyms.
- If TARGET is not set, the value of INSTALLSYS (through
setting or detection) is used.
- For Shorewall-lite and Shorewall6-lite, the possible choices
are DEBIAN, FEDORA, REDHAT, SLACKWARE, ARCHLINUX and
LINUX. Again, REDHAT and FEDORA are synonyms.
- For Shorewall-init, the possible choices are DEBIAN, FEDORA,
REDHAT, and SUSE.
4) A SWITCH column has been added to /etc/shorewall/masq. This column
allows for enabling and disabling a rule based on a setting in
/proc/net/nf_condition. See shorewall-masq(5) for details.
5) The rules compiler now issues a warning when the ''src''
ipset flag
is used in a destination column or the ''dst'' ipset flag is
used in
a source column.
Thank you for testing,
-Tom
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
> 3) Previously, the install scripts included in the Shorewall packages > were very restrictive. They could either be run to install directly > onto the system in a distribution-dependent way, or they could > install into a directory in a distribution-independent way. This > limited their usefullness to packagers. > > Beginning with this release, the install scripts handle the install > system and the target system independently. When running an > installer, the following environmental variables can be set: > > a) INSTALLSYS - Describes the system where the installer is > running. Accepted values are: > > CYGWIN - Cygwin running under a Microsoft OS > MAC - OS X > DEBIAN - Debian > REDHAT - Redhat,Centos,Foobar,etc. > FEDORA - Fedora > SLACKWARE - Slackware > ARCHLINUX - Arch Linux > LINUX - Generic Linux > > INSTALLSYS is not set, then the installer uses its existing > algorithm for detecting the current OS and distribution. > > b) TARGET - Describes the system where the installed package > will run. > > - For Shorewall and Shorewall6, the possible values are > the same as for INSTALLSYS. The values REDHAT and FEDORA are > synonyms. > > - If TARGET is not set, the value of INSTALLSYS (through > setting or detection) is used. > > - For Shorewall-lite and Shorewall6-lite, the possible choices > are DEBIAN, FEDORA, REDHAT, SLACKWARE, ARCHLINUX and > LINUX. Again, REDHAT and FEDORA are synonyms. > > - For Shorewall-init, the possible choices are DEBIAN, FEDORA, > REDHAT, and SUSE. >Thanks for that. I just had a quick glance over the install.sh script in the main shorewall archive (will have a more thorough look towards the end of the week): 1. Line 128: case "$LIBEXEC" in /*) ;; *) LIBEXEC=/usr/${LIBEXEC} #! Why?! My understanding is that the LIBEXEC is specified in full (prefix/destdir excluding) - not just the bit after "/usr". This is also inconsistent with the same setting in uninstall.sh. It is also inconsistent with what you assume in line 380: "mkdir -p ${DESTDIR}${LIBEXEC}/$PRODUCT" - no "/usr" there! #! Besides uninstall.sh has an error on line 115: "rm -rf $PERLLIB}/Shorewall/*" should really be "rm -rf ${PERLLIB}/Shorewall/*" or "rm -rf $PERLLIB/Shorewall/*". #! In uninstall.sh you also use hard-coded values where shorewall was installed (/sbin/shorewall, /usr/share/shorewall etc) - I think that''s wrong. I am also unsure how uninstall.sh is going to cope with the arch-specific settings you use when install.sh does its job. ;; esac case "$PERLLIB" in /*) ;; *) PERLLIB=/usr/${PERLLIB} #! Same as above. ;; esac 2. INSTALLSYS and TARGET names: it would be better to rename them as "BUILD" and "HOST", makes more sense (and is also consistent with their automake value counterparts). 3. Line 144: if [ -z "$INSTALLSYS" ]; then case $(uname) in CYGWIN*) INSTALLSYS=CYGWIN ;; Darwin) INSTALLSYS=MAC ;; *) if [ -f /etc/debian_version ]; then INSTALLSYS=DEBIAN elif [ -f /etc/redhat-release ]; then if [ -d /etc/sysconfig/network-scripts/ ]; then #! I have /etc/sysconfig/network-scripts/ present, but my system cannot be classified as "REDHAT" - it is Fedora. Why the distinction by the way? Do you need it because of RHEL? INSTALLSYS=REDHAT else INSTALLSYS=FEDORA fi elif [ -f /etc/slackware-version ] ; then INSTALLSYS=SLACKWARE elif [ -f /etc/SuSE-release ]; then INSTALLSYS=SUSE elif [ -f /etc/arch-release ] ; then INSTALLSYS=ARCHLINUX else INSTALLSYS=LINUX fi ;; esac fi 4. Line 301: if [ -n "$DESTDIR" ]; then #![...] elif [ -z "$DESTDIR" ]; then #! if .. else - it is either one or the other, there isn''t a 3rd alternative .This is a common use you employ throughout the install.sh script 5. Line 355: FEDORA|REDHAT) install_file init.fedora.sh ${DESTDIR}/etc/init.d/$PRODUCT 0544 #! This WILL fail! Either use "${DESTDIR}${DEST}/$PRODUCT" or "${DESTDIR}/etc/rc.d/init.d/$PRODUCT" ;;> 4) A SWITCH column has been added to /etc/shorewall/masq. This column > allows for enabling and disabling a rule based on a setting in > /proc/net/nf_condition. See shorewall-masq(5) for details. > > 5) The rules compiler now issues a warning when the ''src'' ipset flag > is used in a destination column or the ''dst'' ipset flag is used in > a source column. > Thank you for testing,I will check/test everything more thoroughly towards the end of the week as I have a lot on my plate at the moment. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 02/20/2012 08:10 AM, Mr Dash Four wrote:> Thanks for that. I just had a quick glance over the install.sh script in > the main shorewall archive (will have a more thorough look towards the > end of the week): > > 1. Line 128: > case "$LIBEXEC" in > /*) > ;; > *) > LIBEXEC=/usr/${LIBEXEC} > #! Why?! My understanding is that the LIBEXEC is specified in full > (prefix/destdir excluding) - not just the bit after "/usr". This is also > inconsistent with the same setting in uninstall.sh.Please see http://www.shorewall.net/Install.sh. Prior to Shorewall 4.4.20, LIBEXEC and PERLLIB were assumed to be relative to /usr; the code above exists for backward compatibility. It is also> inconsistent with what you assume in line 380: "mkdir -p > ${DESTDIR}${LIBEXEC}/$PRODUCT" - no "/usr" there!By the time that code is executed, the code at line 128 will have already generated a fully-qualified path name.> #! Besides uninstall.sh has an error on line 115: "rm -rf > $PERLLIB}/Shorewall/*" should really be "rm -rf ${PERLLIB}/Shorewall/*" > or "rm -rf $PERLLIB/Shorewall/*".Corrected: thanks.> #! In uninstall.sh you also use hard-coded values where shorewall was > installed (/sbin/shorewall, /usr/share/shorewall etc) - I think that''s > wrong. I am also unsure how uninstall.sh is going to cope with the > arch-specific settings you use when install.sh does its job.> 2. INSTALLSYS and TARGET names: it would be better to rename them as > "BUILD" and "HOST", makes more sense (and is also consistent with their > automake value counterparts).I suspected that there were probably better names for these variables. I''ll switch them in Beta 2.> > 3. Line 144: > > if [ -z "$INSTALLSYS" ]; then > case $(uname) in > CYGWIN*) > INSTALLSYS=CYGWIN > ;; > Darwin) > INSTALLSYS=MAC > ;; > *) > if [ -f /etc/debian_version ]; then > INSTALLSYS=DEBIAN > elif [ -f /etc/redhat-release ]; then > if [ -d /etc/sysconfig/network-scripts/ ]; then > #! I have /etc/sysconfig/network-scripts/ present, but my system cannot > be classified as "REDHAT" - it is Fedora. Why the distinction by the > way? Do you need it because of RHEL?I need it in the Shorewall-init installer so I replicated the detection logic on all of the installers for compatibility and to handle any future deviations between RHEL (and derivatives) and Fedora.> 4. Line 301: > > if [ -n "$DESTDIR" ]; then > #![...] > elif [ -z "$DESTDIR" ]; then > #! if .. else - it is either one or the other, there isn''t a 3rd > alternative .This is a common use you employ throughout the install.sh > script >Duh -- corrected. Thanks.> 5. Line 355: > > FEDORA|REDHAT) > install_file init.fedora.sh ${DESTDIR}/etc/init.d/$PRODUCT 0544 > #! This WILL fail! Either use "${DESTDIR}${DEST}/$PRODUCT" or > "${DESTDIR}/etc/rc.d/init.d/$PRODUCT" > ;; >Hmmm -- on my Fedora 16 installation, /etc/init.d is a symbolic link to /etc/rc.d/init.d; ''rpm -qf /etc/init.d'' indicates that it is installed by chkconfig. So I guess the current code only fails if chkconfig isn''t installed. I''ll update all install scripts to assume /etc/rc.d/init.d for Fedora and RHEL. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
> Please see http://www.shorewall.net/Install.sh. Prior to Shorewall > 4.4.20, LIBEXEC and PERLLIB were assumed to be relative to /usr; the > code above exists for backward compatibility. > > It is also > >> inconsistent with what you assume in line 380: "mkdir -p >> ${DESTDIR}${LIBEXEC}/$PRODUCT" - no "/usr" there! >> > > By the time that code is executed, the code at line 128 will have > already generated a fully-qualified path name. >I see, so when I wish to build shorewall from source, I need to set LIBEXEC/PERLEXEC to their respective directory *names*, rather than their paths, is that how it is supposed to work? As for the backward compatibility aspect you mention above - I thought a major revision (4.5.0, I think, qualifies) warranted corrections of such magnitude. Getting rid of inaccuracies, inferior "features" used in previous revisions is one of the purposes of making a major release, isn''t that the case?>> #! Besides uninstall.sh has an error on line 115: "rm -rf >> $PERLLIB}/Shorewall/*" should really be "rm -rf ${PERLLIB}/Shorewall/*" >> or "rm -rf $PERLLIB/Shorewall/*". >> > > Corrected: thanks. >When I have more time, I''ll have a bit more detailed look at uninstall.sh as well.> I suspected that there were probably better names for these variables. > I''ll switch them in Beta 2. >Thanks.> I need it in the Shorewall-init installer so I replicated the detection > logic on all of the installers for compatibility and to handle any > future deviations between RHEL (and derivatives) and Fedora. >Well, if you do need to distinguish between Fedora and RedHat/RHEL, then I suggest you use a different "sniff" method, because this isn''t it - both Fedora Core and RedHat/RHEL deploy/use /etc/sysconfig/network-scripts.> Duh -- corrected. Thanks. >Thanks.> Hmmm -- on my Fedora 16 installation, /etc/init.d is a symbolic link to > /etc/rc.d/init.d; ''rpm -qf /etc/init.d'' indicates that it is installed > by chkconfig. So I guess the current code only fails if chkconfig isn''t > installed. I''ll update all install scripts to assume /etc/rc.d/init.d > for Fedora and RHEL. >You are quite right in your assumption that /etc/init.d is a symlink to /etc/rc.d/init.d, provided chkconfig is installed. If it isn''t, that directory is not present. Also, during build, especially using the current crop of .spec files available (I am talking about the FC ones here), this directory is not configured/created/present - only %{buildroot}/etc/rc.d/init.d is used. So, if install.sh tries to copy the appropriate init.d script, this will fail as well (it is the 2nd reason I started investigating install.sh more thoroughly last week). You also need to honour the DIST environment variable, if set - install.sh does not do that at present, so I think you should correct that as well. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 02/20/2012 11:14 AM, Mr Dash Four wrote:>> >> By the time that code is executed, the code at line 128 will have >> already generated a fully-qualified path name. >> > I see, so when I wish to build shorewall from source, I need to set > LIBEXEC/PERLEXEC to their respective directory *names*, rather than > their paths, is that how it is supposed to work?I assume that by "build shorewall from source", you mean running install.sh rather than running the build45 script from the shorewall/tools Git repository. When running install.sh, you can use either relative or absolute path names. If either of the settings is a relative pathname, then /usr/ is prepended to form an absolute pathname; otherwise the value is used as is.> > As for the backward compatibility aspect you mention above - I thought a > major revision (4.5.0, I think, qualifies) warranted corrections of such > magnitude. Getting rid of inaccuracies, inferior "features" used in > previous revisions is one of the purposes of making a major release, > isn''t that the case?Given that the scripts are changing so much for 4.5.1, it would probably be a good time to drop that compatibility, alright.> Well, if you do need to distinguish between Fedora and RedHat/RHEL, then > I suggest you use a different "sniff" method, because this isn''t it - > both Fedora Core and RedHat/RHEL deploy/use /etc/sysconfig/network-scripts. >I''ve taken another look at the previous Shorewall-init installer and it appears broken WRT Fedora/Redhat and Shorewall-init. Need to investigate. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On 02/20/2012 01:16 PM, Tom Eastep wrote:> > I''ve taken another look at the previous Shorewall-init installer and it > appears broken WRT Fedora/Redhat and Shorewall-init. Need to investigate. >The breakage occurred back in August when I began including the Fedora/Redhat-specific init scripts from Jonathan Underwood. Will be fixed in Beta 2 and in 4.5.0.2. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2
On Feb 20, 2012, at 8:10 AM, Mr Dash Four wrote:> I will check/test everything more thoroughly towards the end of the week > as I have a lot on my plate at the moment.As the week progresses, please give me an idea when you will be testing and I''ll release Beta 2. I''ve made a lot of changes today (holiday here in the US) and I would prefer that you test with those. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
> As the week progresses, please give me an idea when you will be testing and I''ll release Beta 2. > > I''ve made a lot of changes today (holiday here in the US) and I would prefer that you test with those. >Friday onwards is my guess! Before that won''t be possible. ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
> I assume that by "build shorewall from source", you mean running > install.sh rather than running the build45 script from the > shorewall/tools Git repository. > > When running install.sh, you can use either relative or absolute path > names. If either of the settings is a relative pathname, then /usr/ is > prepended to form an absolute pathname; otherwise the value is used as is. >Generally speaking, I use one method of compiling Shorewall and that is to build it using a .spec file. When I got the init.d problem (incidentally, that was the first time I tried to compile all shorewall packages instead of just the main ones - shorewall & shorewall-core), I used to unpack all package sources and run install.sh, mimicking what was done in the %build section of the .spec file. As far as the above goes - I find it confusing. Either use $PREFIX/$LIBEXEC (my preferred option - see below) or just $LIBEXEC irrespective of $PREFIX. If you have to use LIBEXEC as a name of the libexec directory, you might consider renaming this to LIBEXECNAME instead - it would be more clear that way. The reason I prefer $PREFIX/$LIBEXEC (and that is also valid for its perl counterpart) is because it would be more consistent and I won''t be looking in thousand different places to see where shorewall was installed. The $PREFIX also has one other important function - it would allow me to install shorewall in a "non-trivial" location (not just /usr) - it comes handy when you wish to deploy it on embedded systems or systems which do not follow FHS. I am assuming that for the shorewall to function properly, you do not rely on the FHS. If you do, then you probable won''t need $PREFIX at all and you may use "standard" location installation for shorewall, irrespective of what was specified. I am still not clear why do you need libexec though - why not use $PREFIX/sbin or $PREFIX/bin for example?> Given that the scripts are changing so much for 4.5.1, it would probably > be a good time to drop that compatibility, alright. >The ideal time for introducing major changes (and drop backward-compatibilities dragging you down) was with 4.5.0, but I guess, better late than never, eh? You may also wish to drop the "blacklist" as well in favour of the blrules file. On an unrelated note - I keep getting the following 3 types of warnings: 1. WARNING: Option EXPORTPARAMS=Yes is deprecated (what is the equivalent of this?) 2. WARNING: Shorewall no longer uses broadcast addresses in rule generation when Address Type Match is available I have this in my interfaces file: local usb0 192.168.0.255 tcpflags,logmartians,nosmurfs,optional the usb0 is used to connect/debug my android device. 3. ipset WARNINGS: shorewall[1439]: Compiling /etc/shorewall/blrules... shorewall[1439]: WARNING: Ipset AAA does not exist [...ad nauseum...] shorewall[1439]: WARNING: Ipset XXX does not exist shorewall[1439]: Compiling /etc/shorewall/rules... shorewall[1439]: WARNING: Ipset YYY does not exist [...ad nauseum...] shorewall[1439]: WARNING: Ipset ZZZ does not exist Now, I remember asking you to put these warnings a few mohts back, but what I did not account for was that shorewall will be screaming at me with these before executing "init" where these sets are loaded. Is there any way to rectify this? ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d
On 02/21/2012 07:13 AM, Mr Dash Four wrote:> Generally speaking, I use one method of compiling Shorewall and that is > to build it using a .spec file. When I got the init.d problem > (incidentally, that was the first time I tried to compile all shorewall > packages instead of just the main ones - shorewall & shorewall-core), I > used to unpack all package sources and run install.sh, mimicking what > was done in the %build section of the .spec file. > > As far as the above goes - I find it confusing. Either use > $PREFIX/$LIBEXEC (my preferred option - see below) or just $LIBEXEC > irrespective of $PREFIX. If you have to use LIBEXEC as a name of the > libexec directory, you might consider renaming this to LIBEXECNAME > instead - it would be more clear that way. > > The reason I prefer $PREFIX/$LIBEXEC (and that is also valid for its > perl counterpart) is because it would be more consistent and I won''t be > looking in thousand different places to see where shorewall was > installed. The $PREFIX also has one other important function - it would > allow me to install shorewall in a "non-trivial" location (not just > /usr) - it comes handy when you wish to deploy it on embedded systems or > systems which do not follow FHS. > > I am assuming that for the shorewall to function properly, you do not > rely on the FHS. If you do, then you probable won''t need $PREFIX at all > and you may use "standard" location installation for shorewall, > irrespective of what was specified. I am still not clear why do you need > libexec though - why not use $PREFIX/sbin or $PREFIX/bin for example?The sole purpose of PREFIX (a.k.a DESTDIR) is for building packages. $PREFIX specifies the root of the filesystem in which the installer will install the product (rpm/BUILDROOT/product-... for rpms). There was never any intention that a Shorewall product installed into a directory could actually run in that environment. LIBEXEC exists because some distributions don''t want to put executable shell scripts in /usr/share and prefer to put them in /usr/libexec/ instead. Similarly, some distributions object to Perl modules living in /usr/share, which is why PERLLIB was invented. Both of these specify an absolute pathname to be used at run-time.> >> Given that the scripts are changing so much for 4.5.1, it would probably >> be a good time to drop that compatibility, alright. >> > The ideal time for introducing major changes (and drop > backward-compatibilities dragging you down) was with 4.5.0, but I guess, > better late than never, eh?Yep.> You may also wish to drop the "blacklist" as > well in favour of the blrules file.I considered that but may users have scripts that load the existing blacklist file so I''ve maintained support for it.> > On an unrelated note - I keep getting the following 3 types of warnings: > > 1. WARNING: Option EXPORTPARAMS=Yes is deprecated (what is the > equivalent of this?)EXPORTPARAMS=Yes causes the entire params file script to be executed by the generated firewall script. That''s usually not what is wanted. When EXPORTPARAMS=No, the variables that the params file creates are automatically set in the generated script, allowing them to be used in the other user exits like init, started, etc.> > 2. WARNING: Shorewall no longer uses broadcast addresses in rule > generation when Address Type Match is available > I have this in my interfaces file: > local usb0 192.168.0.255 > tcpflags,logmartians,nosmurfs,optional > > the usb0 is used to connect/debug my android device.Simply use ''-'' in the BROADCAST column. I should create a new format interfaces file that simply omits that column; I''ve done similar things with other configuration files that support a FORMAT directive. I''ll add that before the first 4.5.1 RC.> > 3. ipset WARNINGS: > shorewall[1439]: Compiling /etc/shorewall/blrules... > shorewall[1439]: WARNING: Ipset AAA does not exist > [...ad nauseum...] > shorewall[1439]: WARNING: Ipset XXX does not exist > shorewall[1439]: Compiling /etc/shorewall/rules... > shorewall[1439]: WARNING: Ipset YYY does not exist > [...ad nauseum...] > shorewall[1439]: WARNING: Ipset ZZZ does not exist > > Now, I remember asking you to put these warnings a few mohts back, but > what I did not account for was that shorewall will be screaming at me > with these before executing "init" where these sets are loaded. Is there > any way to rectify this?I suppose that we could control generation of this message by a command option. Today, it is simply predicated on whether the user is root or not. e.g, ''shorewall check -i'' would issue the warnings if executed by root. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d