Shorewall users - Feb 2012 - Shorewall 4.5.0

The Shorewall Team is pleased to announce the availability of Shorewall
4.5.0.

----------------------------------------------------------------------------
     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)  This release includes all defect repair included in
    4.4.27.1-4.4.27.3.

2)  The start and restart commands in Shorewall Lite and Shorewall6
    Lite now correctly handle the ''trace'' and
''debug''
    keywords. Previously, those keywords were ignored.

3)  The ''ip route list'' command on recent Linux systems
(Ubuntu 11.10,
    for example) displays the IPv4 routing table in a seemingly random
    order. In the ''show routing'' and ''dump''
commands, Shorewall and
    Shorewall-lite now sort the output into the traditional
    ''Most-specific to most-general'' order.

4) Previously, specifying ''No'' in the HAVEROUTE column of
    /etc/shorewall6/proxyndp resulted in a run-time error. The code has
    been corrected so that no error occurs.

----------------------------------------------------------------------------
            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)  The rules generated by the following interface options are now
    traversed after those generated by the blrules file.

    dhcp
    maclist
        nosmurfs
    sfilter
        tcpflags

    As part of this change, the BLACKLIST section in the rules file has
    been eliminated. If you have rules in that section, you must move
    them to the blrules file prior to installing this Shorewall
    version.

2)  The timeout interval after which the previous state is restored
    may now be specified in the safe-start and safe-restart commands.

3)  The packing of the Shorewall products has been changed. Beginning
    with this release, the packages are:

    - Shorewall Core  -- Core libraries installed in
                       /usr/share/shorewall/

    - Shorewall       -- Requires Shorewall Core. Together with
                         Shorewall Core, provides IPv4 firewalling.

    - Shorewall6      -- Requires Shorewall. Provides IPv6 firewalling.

    - Shorewall Lite  -- Requires Shorewall Core. As before.

    - Shorewall6 Lite -- Requires Shorewall Core. As before.

    - Shorewall Init  -- As before.

4)  Shorewall and Shorewall6 now share a single install.sh file as do
    Shorewall Lite and Shorewall6 Lite.

5)  Functions common to both /usr/share/shorewall/prog.header and
    /usr/share/shorewall/prog.header6 are now in a new library -
    lib.core. The files /usr/share/shorewall/prog.footer is now used
    for both IPv4 and IPv6.

6)  Run-time address variables (e.g., &eth0) may now be used in the
    SOURCE column of the rtrules files.

7)  The route_rules file has been renamed to ''rtrules''. The
Shorewall
    and Shorewall6 installers will perform the rename on an existing
    file.

    If both files exist, route_rules will be processed and rtrules
    will be ignored with a warning.

8)  A ''PROBABILITY'' column has been added to the tcrules
files. It
    causes the rule to match randomly with the probability specified in
    the column. See shorewall-tcrules(5) and shorewall6-tcrules(5) for
    details.

9)  An alternative to the balance=<weight> option in the providers file
    is now available. This alternative works when there are multiple
    links to the same ISP where both links use an ethernet interface (as
    opposed to PPP0E) and have the same default gateway.

    As part of this change, the generated firewall script now
    automatically maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.

    See http://www.shorewall.net/MultiISP.html#load for additional
    information.

    Example that sends 1/3 of the connections to the ComcastC provider
    and the rest to ComcastB:

    /etc/shorewall/shorewall.conf

    MARK_IN_FORWARD_CHAIN=No
    ...
    USE_DEFAULT_RT=Yes

    /etc/shorewall/providers:

    #NAME    NUMBER MARK DUP  INTERFACE GATEWAY       OPTIONS
    ComcastB 1      -    -    eth1      70.90.191.126
loose,balance,load=0.66666667
    ComcastC 2      -    -    eth0      67.170.120.1 
loose,fallback,load=0.33333333

    Note: The ''loose'' option is specified so that the compiler
will not
          generate and rules based on interface IP addresses. That way
      we have complete control over the priority of such rules
      through entries in the rtrules file.

    /etc/shorewall/rtrules

    #SOURCE             DEST  PROVIDER  PRIORITY
    70.90.191.120/29    -     ComcastB  1000
    &eth0            -     ComcastC  1000

    Note: eth0 has a dynamic address, so &eth0 is used in the SOURCE
          column.

    Note: Priority = 1000 means that these rules will come before rules
          that select a provider based on marks.

10) The Shorewall files in /etc/default and /etc/sysconfig now support
    two new options that affect how ''/etc/init.d/shorewall
start''
    and ''/etc/init.d/shorewall restart'' behave:

    STARTOPTIONS   -- options to the start commmand.
    RESTARTOPTIONS -- options to the restart command.

    For example, if you always want ''start'' to flush the
conntrack
    table, then you would have:

           STARTOPTIONS="-p"

11) The Git repository has been reorganized to place the samples and
    manpages under their corresponding product directories. For
    example, trunk/manpage6 was moved to trunk/Shorewall6/manpages.

----------------------------------------------------------------------------
                          M I G R A T I O N   I S S U E S
----------------------------------------------------------------------------

1)  If you are migrating from Shorewall 4.2.x or earlier, please see
   
http://www.shorewall.net/pub/shorewall/4.4/shorewall-4.4.27/releasenotes.txt

2)  The BLACKLIST section of the rules file has been eliminated.
    If you have entries in that file section, you must move them to the
    blrules file.

3)  This version of Shorewall requires the Digest::SHA1 Perl module.

        Debian: libdigest-sha1-perl
        Fedora: perl-Digest-SHA1
        OpenSuSE: perl-Digest-SHA1

4)  The generated firewall script now maintains the
    /var/lib/shorewall[6][-lite]/interface.status files used by SWPING
    and by LSM.

Thank you for using Shorewall.
-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/

> The Shorewall Team is pleased to announce the availability of Shorewall
> 4.5.0.
Hi Tom and Team,

Thanks for the new release!
It looks like the LIBEXEC / PERLLIB handling is broken now :)
I hope attached patch fixes it.

Thanks,
Simon

------------------------------------------------------------------------------
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/13/2012 05:30 AM, Simon Matter wrote:
>
> Thanks for the new release!
> It looks like the LIBEXEC / PERLLIB handling is broken now :)
> I hope attached patch fixes it.
Looks like it does -- thanks, Simon.

-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

So will there be Shorewall 4.5.1, or what ?

On 2/13/2012 07:01, Tom Eastep wrote:
> On 02/13/2012 05:30 AM, Simon Matter wrote:
>> Thanks for the new release!
>> It looks like the LIBEXEC / PERLLIB handling is broken now :)
>> I hope attached patch fixes it.
> Looks like it does -- thanks, Simon.
>
> -Tom
>
>
>
------------------------------------------------------------------------------
> 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
>
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users

------------------------------------------------------------------------------
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 2/13/12 8:06 PM, Christ Schlacta wrote:
> So will there be Shorewall 4.5.1, or what ?
>
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.

-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

> 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!

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
#! [...]

#
# Determine where to install the firewall script
#
if [ -n "$DESTDIR" ]; then
    if [ -z "$CYGWIN" ]; then
    if [ `id -u` != 0 ] ; then
        echo "Not setting file owner/group permissions, not running as 
root."
        OWNERSHIP=""
    fi
    fi

    install -d $OWNERSHIP -m 755 ${DESTDIR}/sbin
    install -d $OWNERSHIP -m 755 ${DESTDIR}${DEST}

    CYGWIN    MACelse
#!
#! Since DESTDIR is ALWAYS set this branch will NEVER execute,
#! therefore arch-specific settings (DEBIAN/FEDORA/SLACKWARE/ARCHLINUX 
etc) will NEVER get set,
#! triggering the rather crappy version of the init.d shorewall script 
being included in the final built (see below)!
#!
    if [ $PRODUCT = shorewall ]; then
        #
        # Verify that Perl is installed
        #
    if ! perl -c Perl/compiler.pl; then
        echo "ERROR: $Product $VERSION requires Perl which either is not 
installed or is not able to compile the $Product perl code" >&2
        echo "       Try perl -c $PWD/Perl/compiler.pl" >&2
        exit 1
    fi
    else
    [ -x /usr/share/shorewall/compiler.pl ] || \
        { echo "   ERROR: Shorewall >= 4.3.5 is not installed"
>&2; exit
1; }
    fi

    if [ -n "$CYGWIN" ]; then
    echo "Installing Cygwin-specific configuration..."
    elif [ -n "$MAC" ]; then
    echo "Installing Mac-specific configuration..."
    else
    if [ -f /etc/debian_version ]; then
        echo "Installing Debian-specific configuration..."
        DEBIAN=yes
        SPARSE=yes
    elif [ -e /etc/redhat-release ]; then
        echo "Installing Redhat/Fedora-specific configuration..."
        FEDORA=yes
    elif [ -f /etc/slackware-version ] ; then
        echo "Installing Slackware-specific configuration..."
        DEST="/etc/rc.d"
        MANDIR="/usr/man"
        SLACKWARE=yes
        INIT="rc.firewall"
    elif [ -f /etc/arch-release ] ; then
        echo "Installing ArchLinux-specific configuration..."
        DEST="/etc/rc.d"
        INIT="$PRODUCT"
        ARCHLINUX=yes
    fi
    fi
fi

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

#! [...]

#
# Install the Firewall Script
#
if [ -n "$DEBIAN" ]; then
#!
#! Never happening!
#!
    install_file init.debian.sh ${DESTDIR}/etc/init.d/$PRODUCT 0544
elif [ -n "$FEDORA" ]; then
#!
#! Never happening!
#! Besides, the proper destination for FEDORA distribution is 
${DESTDIR}${DEST},
#! particularly if ${DEST} is already set - not just hard-coded 
"${DESTDIR}/etc/init.d/"!
#! If anything, it should be "${DESTDIR}/etc/rc.d/init.d/".
#!
    install_file init.fedora.sh ${DESTDIR}/etc/init.d/$PRODUCT 0544
elif [ -n "$ARCHLINUX" ]; then
#!
#! Never happening!
#!
    install_file init.archlinux.sh ${DESTDIR}${DEST}/$INIT 0544
elif [ -n "$SLACKWARE" -a $PRODUCT = shorewall ]; then
#!
#! Never happening!
#!
    install_file init.slackware.firewall.sh 
${DESTDIR}${DEST}/rc.firewall 0644
    install_file init.slackware.$PRODUCT.sh 
${DESTDIR}${DEST}/rc.$PRODUCT 0644
elif [ -n "$INIT" ]; then
#!
#! This is what I get installed in all cases - a rather crappy version 
of the shorewall init.d script
#!
    install_file init.sh ${DESTDIR}${DEST}/$INIT 0544
#!
#! BUG number 2: if any of "${DESTDIR}" or "${DEST}" have
spaces in them
you are royally screwed!
#!
fi

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!
#!

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!

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.


------------------------------------------------------------------------------
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 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/

> It''s based on the approach that I tried to explain to you the last
time
> the topic came up. Glad you like it.
>   
As I already said - congratulations!
>> [ -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:
>   
[etc]

Your logic is completely fraud, I am afraid. What does specifying the 
destination directory has to do with the type of distribution I have or 
will use shorewall for? I''ll tell you what - absolutely nothing, nada! 
One is completely separate from the other.

Let me repeat that again - what destination directory I choose to use 
has absolutely nothing whatsoever to do with the type of distro I have/I 
am building shorewall for.
 
If your install.sh script is trying to determine what distro I am using 
(again, an entirely fraud premise as, as you rightly pointed out below, 
I could be building shorewall on one distro for another, in which case 
currently your install.sh will fall apart) should be entirely separate 
from the DESTDIR logic - completely different and separate issues. As it 
currently stands, that is not the case - both are lumped together, 
creating an unholy mess!
> 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.
Nope, I am just pointing out the error in your ways - nothing more, 
nothing less.
>  But it sounds like you are asking for
> the ability to install into a directory while applying distribution
> settings?
>   
Nope! About 18 months ago I have asked to get the right script included 
in my shorewall build (by the right script, I mean the proper init.d 
script - a version of that file usually sits in the main shorewall 
source directory) instead of getting the rather crappy version of it, 
which is of no use to me whatsoever.
> 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
>   
So, let me get this straight - in order to get the twisted logic in 
install.sh to work, I have to specify DESTDIR, <DISTRO>=yes as well as 
SYSTEMD=yes when running install.sh? You''d better run and tell all the 
shorewall distro maintainers out there, because I am not sure all of 
them are aware of this.

Besides (and I am judging this from Fedora''s perspective as this is the
distro I employ on all my machines - that and EL), hard-coding the 
initdir in your install.sh is going to cause all SRPMs distributed with 
Fedora to fail as there isn''t such directory in the buildroot called 
/etc/init.d - that directory is properly set via environment variable 
during the install.sh call and is duly ignored by that script.

So, even if I *do* set FEDORA=yes, even if I do set SYSTEMD=yes, even 
then the build is going to fail - miserably so, because the init.d 
directory is hard-coded in install.sh
> I can change the install scripts so that the detected settings will be
> applied within the directory as well.
>   
IMO, if you are going to do "target-distro sniffing", well, do it 
properly! As you rightly pointed out, I could be building on one distro 
for another and as all your packages are noarch-designated the 
install.sh "target-distro sniffing" will currently fail, miserably.

Rely on either the proper target distro variables 
(FEDORA/DEBIAN/ARCHLINUX etc) being set in advance (they should always 
take precedence of what install.sh determines to be "sane" values) or 
include "target-distro sniffing" as a default option if nothing has
been
set, in which case make it clear in the build log what is the result of 
that sniffing, and what install.sh has determined as target distro, 
directories, files (including sysv or systemd) etc that will be used, so 
that errors are easily corrected and not like as it is now, I had to 
spend about an hour debugging a bloody shell script to see what the hell 
is going on!

Regardless of whether the target distro option has been set up initially 
or "sniffed out" by install.sh, the application of the distro-specific
logic should be completely separate from whether or not the DESTDIR has 
being set - the one has absolutely nothing whatsoever to do with the 
other and should be treated as such by install.sh. That was the error in 
install.sh which caused me to get that crappy init.d script installed - 
it has been going on for year and a half!
>> 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
>   
As if!
>> #! [...]
>>
>> #
>> # 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.
>   
Yeah, when you don''t specify neither the prefix, nor the destdir and 
only if you use debian. If you use fedora instead, or specify either 
prefix or destdir - it fails, miserably, but you already know that, 
don''t you?
>> #!
>> #! BUG number 2: if any of "${DESTDIR}" or
"${DEST}" have spaces in them
>> you are royally screwed!
>> #!
>> fi
>>     
> I frankly don''t care.
>   
I know you do!
>> 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.
>   
Thank you! I hope you take into account the initdir setting and do not 
hard-code this stuff, because building srpm will definitely fail with 
"/etc/init.d" being hard-coded.
> That is the defect that Simon reported and that will be corrected in
> 4.5.0.1.
>   
I wasn''t aware of what Simon had posted until I read it on the ML,
don''t
be so precious!
>> 2. masq
>>
>> [...]
>>
>> 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.
>   
I hope it won''t take you 18 months to fix these. Let me know if you
need
a hand.


------------------------------------------------------------------------------
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/