On 03/21/2012 06:03 PM, Mr Dash Four wrote:
>>> 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've been beavering away at such a thing which will be in the next Beta. > >>> 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? That is a destination column. > >> 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! Patches cheerfully accepted. > >>> 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)? There is currently code generated for creating ipsets (as hash:ip) that don't exist. Unfortunately, that code is broken in the current releases :-( I've corrected the code and have added a warning message. > 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. It's on its way. -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
