>> Any setup, which isn't using "standard" path names hard-coded in
>> unistall.sh - have a look!
>
> Okay -- so we can summarize by saying that Shorewall currently doesn't
> handle platforms that don't follow the Linux FHS.
If we do that, we won't do it justice! uninstall.sh has most, if not all of its
removal paths hard-coded, like so:
rm -f /etc/rc*.d/*$(basename $FIREWALL)
rm -f /sbin/shorewall
rm -f /sbin/shorewall-*.bkout
rm -rf /usr/share/shorewall/version
rm -rf /etc/shorewall
rm -rf /etc/shorewall-*.bkout
rm -rf /var/lib/shorewall
rm -rf /var/lib/shorewall-*.bkout
rm -rf ${PERLLIB}/Shorewall/*
rm -rf ${LIBEXEC}/shorewall
rm -rf /usr/share/shorewall/configfiles/
rm -rf /usr/share/shorewall/Samples/
rm -rf /usr/share/shorewall/Shorewall/
rm -f /usr/share/shorewall/lib.cli-std
rm -f /usr/share/shorewall/lib.core
rm -f /usr/share/shorewall/compiler.pl
rm -f /usr/share/shorewall/prog.*
rm -f /usr/share/shorewall/module*
rm -f /usr/share/shorewall/helpers
rm -f /usr/share/shorewall/action*
rm -f /usr/share/shorewall/init
rm -rf /usr/share/shorewall-*.bkout
This not going to work on all platforms supported by shorewall. Removal of the
shorewall "product" (shorewall-lite/shorewall/shorewall6/shorewall-lite6 etc
etc) won't be complete. "custom" configuration (similar to the one I pointed
out to in my previous post) won't be fully removed either.
"Upgrade" by uninstalling/installing is therefore out of the question without
spending some extra time delving in and this is also prone to errors.
I know you've heard that from me once or twice before, but if you had a single
file describing various paths on the host used for shorewall installation, that
won't be a problem at all.
>> I am open to suggestions then as to how to make this work, also bearing
>> in mind that due to Netfilter stupidity I have to always specify the
>> protocol (the nf devs might change that as I already raised that issue,
>> but when - I have no idea).
>
> This should work:
>
> eth0:+ntp-ports[dst] 10.1.1.7/30 41000-42000 udp
If I do that, I am bound to get one of those daft warnings telling me to sod
off using 'dst' in the SOURCE column - but you already knew that, didn't you?
> I've added a new option in 4.5.2 that allows you to turn this on and off
> as you choose. But the implementation will remain consistent across all
> configuration files.
So, employing - quite legitimately - 'dst' in the SOURCE column (and
vice-versa) in the rules file or doing something similar (as in your example
above) is going to be treated by shorewall in exactly the same way as any other
nonsensical - and outright wrong - combination I care to put in any of my other
configuration files (I used masq as an example, but I am sure there are others
too), instead of shorewall doing the right thing and issuing warnings *only* in
cases where this is wrong? Wow! Brilliant thinking that, congratulations!
>> Try again! I remember asking to have a warning when a given ipset _does
>> not exist_, not when _it is not used yet_ as is the case with the
>> example I've given above.
>
> These warnings may also be suppressed using the same option mentioned above.
What good would that do? Absolutely nothing, nada!
What is the point of suppressing warnings when I want to *only* be notified
when a given ipset name does not exist and not when it is not found by
shorewall for whatever reason - prior to executing init (or any other
startup/compilation file)?
>>>> 3. Crap status messages included in the compiled "firewall" file for use
>>>> on the remote machine, messages like:
>>>> progress_message2 Processing /home/mr-4/shorewall/init ... - it
>>>> should be just "Procesing init" as that directory is on my BUILD, not
>>>> HOST ("/home/mr-4/shorewall/" does *not* exist on HOST)
>>>>
>>> SighŠ.
>>>
>
> Will be fixed in 4.5.2.
Thanks!
>> I have managed to fix most of the issues I was getting, but then if/when
>> I need to upgrade, I have to go through all this again and I simply
>> don't have the inclination, nor desire to go through with it - I don't
>> have a couple of hours to spend messing about with patch/diff/sed/grep
>> etc. to fix this - I'd rather have a single file where all my
>> shorewall(-lite) settings/paths are and tweak those!
>
> I hear you.
OK, I managed to create a small test case and I think I found what is causing
these DNAT errors - there is something odd/weird in my capabilities file which
is seriously tripping shorewall. I tried to use my own "standard" capabilities
file (the one I deploy on the dev machine here) and everything works as
expected.
I am privately-attaching an archive (don't know whether the ML could handle
attachments) which contains my whole test case setup as well as the output I am
getting when compiling my firewall{.conf} files. Let me know if you need
anything else from me.
Just in case it isn't clear - the reason I am using an "older" capabilities
file is because I can't afford to spend hours upgrading shorewall on that
system until either I find that time or a better (understand easier to use and
less time-consuming) alternative for upgrading of shorewall becomes available.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
