On 2/14/12 8:45 AM, Mr Dash Four wrote:
>> There will be 4.5.0.1 in a few days. In the meantime, there is a simple
>> workaround posted in the 'Known Problems' on the web site.
>>
> I see that you finally came to your senses and implemented a proper
> blacklisting in shorewall. Congratulations!
It's based on the approach that I tried to explain to you the last time
the topic came up. Glad you like it.
> Any chance you could fix the init.d script bug I have raised over 18
> months ago? No matter what I do I always get the crappy version of the
> init.d shorewall script and the problem is in your install.sh file. In
> all shorewall* packages the following "logic" is present in install.sh
> (my own comments are shown with "#!"):
>
> [ -n "$DESTDIR" ] || DESTDIR="$PREFIX"
> #! so, DESTDIR is always set, no matter what
> #! [...]
It is only set if you set it explicitly or you set PREFIX explicitly; If
you specify neither, then DESTDIR is undefined.
There are two scenarios supported by install.sh:
a) Install on the current system. In this case, no PREFIX or DISTDIR
should be specified. An attempt is made to determine the running
distribution and apply the correct settings.
cd shorewall-4.5.0
./install.sh
b) Install into a directory using defaults. The defaults are geared
toward OpenSuSE since that is the distribution for which I originally
developed the RPM and
cd shorewall-4.5.0
DESTDIR=/tmp/foo ./install.sh
Since what you have written seems to focus on ridiculing the code rather
than discussing your requirements that the scripts don't meet, I'm
having to read between the lines. But it sounds like you are asking for
the ability to install into a directory while applying distribution
settings?
I have a requirement to be able to install into a directory on one
distribution while applying settings for another distribution (I build
Shorewall exclusively on Debian or OS X).
So I can envision something like:
cd shorewall-4.5.0
DISTDIR-/tmp/foo FEDORA=Yes ./install.sh
I can change the install scripts so that the detected settings will be
applied within the directory as well.
>
> if [ -z "$DESTDIR" ]; then
> #!
> #! ... and neither will this branch, thus SYSTEMD NEVER gets set!
> #!
> if [ -f /lib/systemd/system ]; then
> SYSTEMD=Yes
> fi
> elif [ -n "$SYSTEMD" ]; then
> mkdir -p ${DESTDIR}/lib/systemd/system
> fi
Although you can:
cd shorewall-4.5.0
SYSTEMD=Yes ./install.sh
>
> #! [...]
>
> #
> # Install the Firewall Script
> #
> if [ -n "$DEBIAN" ]; then
> #!
> #! Never happening!
> #!
I beg your pardon, but it happens every time I install or update a
Shorewall product on any of my systems.
> #!
> #! BUG number 2: if any of "${DESTDIR}" or "${DEST}" have spaces in them
> you are royally screwed!
> #!
> fi
I frankly don't care.
>
> The above is valid for all install.sh files, *except* shorewall-init -
> there is a special case there - in addition to the above, we have this
> little gem:
>
> elif [ -n "$FEDORA" ]; then
> install_file init.debian.sh ${DESTDIR}/etc/init.d/shorewall-init 0544
> #!
> #! Wrong on so many levels!
> #!
Indeed -- corrected.
>
> While I am at it, there are a few other bugs in the newest version of
> shorewall (4.5.0). I am listing them below - you could fix these, if you
> are so inclined:
>
> 1. lib.cli has a hard-coded "g_libexec=/usr/share" value, which is wrong
> - on my distribution at least, g_libexec is "/usr/libexec", so shorewall
> should not assume anything about that directory and that value should
> either be "/usr/libexec", or, better still "g_libexec=${LIBEXEC}", which
> is a variable usually set prior to shorewall being built. ${LIBEXEC} is
> also used in the various places in the install.sh script, but "eval sed
> -i \'s\|g_libexec=.\*\|g_libexec=$LIBEXEC\|\' ${DESTDIR}/bin/$PRODUCT"
> is not functioning for some reason!
That is the defect that Simon reported and that will be corrected in
4.5.0.1.
Previously,
LIBEXEC=/usr/libexec ./install.sh
worked because the product's cli was modified by the install script.
Now, the shorewall-core install script needs to make a similar change in
lib.cli.
>
> 2. masq
> - add provision for ipsets inclusion in INTERFACE:DEST, SOURCE and PORT
> columns and update the man page (there is no mention of ipsets being
> allowed at all), with examples as well shown in that man page. For
> example, if I have this in my masq file:
>
> #############################################################################################
> #INTERFACE:DEST SOURCE ADDRESS PROTO PORT(S)
> IPSEC MARK USER/
> #
>
> GROUP
> eth0::+test[dst,dst] 10.1.1.1 detect
>
> The above is properly translated by shorewall, though this feature needs
> to be documented.
>
> - Using the above example, if I have "+test[src,src]" (which makes no
> sense whatsoever) - compilation passes without even a warning and the
> above statement is "translated" by shorewall to:
>
> -A eth0_masq -s 10.1.1.1 -m set --match-set test src,src -j SNAT
> --to-source $SW_ETH0_ADDRESS
>
> That is never going to match anything and it is plainly wrong.
>
> - Not a bug, but a feature: enable/add a separate column - SWITCH - to
> allow SNAT rules to be switched on/off as desired (this feature already
> exists in other places);
>
> 3. blrules conversion (blacklist ->blrules) - the "-a" option is not
> shown when "shorewall" or "shorewall help" is executed (just "update [
> -b ] [ -r ] [ -T ] [ <directory> ]" is presented), but the same option
> is indeed documented in man shorewall.
>
> 4. Last, but not least, there are some WHITELIES in the
> shorewall-blrules man page - I thought you ought to know and correct
> this so that nothing but the plain truth is only shown on that page.
Okay, I'll work on those as time permits.
-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/
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
