On 03/18/2012 03:57 PM, Mr Dash Four wrote: > > >>> Is there a definite list of all arch-dependent variables used to define >>> these various "profiles"? If so, what are they? >>> >> >> http://www.shorewall.net/Install.htm#Locations >> > Yeah, I see. Rather grim this, particularly that none of this is > remotely configurable. Most embedded devices (routers, smartphones etc) > do not use this type of hierarchy at all. If I had a single file, which > shorewall was using, then all I have to do is tweak this and proceed. As > it is, I need to muck about with various shorewall components to get it > working, just! > >>> In addition, shorewall's uninstall.sh is bound to fail miserably, >>> because it is littered with absolute/assumed path names, so it is >>> completely useless given the above setup. Not to mention that if I want >>> to update a remote installation (say, shorewall-lite on embedded device) >>> there is currently no way I could do that easily without messing about >>> and wasting hours of my time. >>> >> >> Above setup? >> > 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.
>
>>> masq:
>>> ~~~~~
>>> eth0 10.1.1.7/30 41000-42000 udp +ntp-ports[dst,dst]
>>> Compiling /etc/shorewall/masq...
>>> ERROR: Invalid/Unknown tcp port/service (+ntp-ports[dst)
>>>
>>> ntp-ports is 2 dimensional: proto:port
>>> the following iptables statement is perfectly legit (given the above
>>> SNAT bug for having to always specify the protocol):
>>> iptables -t nat -A eth0_masq -p 17 -s 10.1.1.7/30 -m set --match-set
>>> ntp-ports dst,dst -j MASQUERADE --to-ports 41000-42000
>>>
>>
>> Currently, Shorewall does not accept an ipset name in *any* PORT column.
>>
> 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
>
>>
>>>> 7) 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.
>>>>
>>>>
>>> Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
>>> is used in a Source column : /etc/shorewall/rules (line 21)
>>> Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
>>> is used in a Source column : /etc/shorewall/rules (line 22)
>>> Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
>>> is used in a Source column : /etc/shorewall/rules (line 23)
>>> Mar 18 02:02:19 test1 shorewall[28538]: WARNING: The 'dst' ipset flag
>>> is used in a Source column : /etc/shorewall/rules (line 24)
>>>
>>> The above warnings are produced as a result of completely legitimate use
>>> of the 'dst' column in statements like "ACCEPT $FW:+some-set[dst]
>>> net:+some-other-set", so shorewall should be amended to *not* issue these!
>>>
>>
>> These warnings were added in response to you railing about Shorewall
>> accepting [src] in the INTERFACE column of the masq file which is a
>> destination column. So decide what you really want.
>>
> That is correct - and you've done a rather splendid job, but I don't
> seem to remember telling you to change things in the rules file - the
> use of mixed 'src' and 'dst' identifiers in the rules file is perfectly
> reasonable/legitimate as I've illustrated in the example above. So, make
> your mind up whether you wish to deploy this throughout shorewall (and
> restrict legitimate uses) or whether you wish to do the right thing and
> restrict it only in cases where it makes no sense. It is up to you now!
>
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.
>>
>>> Also, I am still getting these during compilation:
>>>
>>> shorewall[1439]: Compiling /etc/shorewall/blrules...
>>> shorewall[1439]: WARNING: Ipset whitelist does not exist
>>> shorewall[1439]: Compiling /etc/shorewall/rules...
>>> shorewall[1439]: WARNING: Ipset voip-blacklist does not exist
>>> shorewall[1439]: WARNING: Ipset XXX does not exist
>>> [...ad nauseum...]
>>> shorewall[1439]: WARNING: Ipset ZZZ does not exist
>>>
>>> The above still has not been fixed, though it was reported to you
>>> before. It is true that these ipsets "do not exists", but are created as
>>> a result of execution of "init", so in effect they do exists.
>>>
>>
>> Again, you asked for this warning and you got it. But this warning and the
>> one above are removed in commit
>>
> 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.
>
>>
>>>> 10) The 'update' command now omits non-default settings of
>>>> WIDE_TC_MARKS and HIGH_ROUTE_MARKS from the updated .conf file.
>>>>
>>>>
>>> "shorewall update" does not function if files are in a non-standard
>>> directory (.back files renamed, but new files placed in the default
>>> directory). For example, if I just have a placeholder shorewall.conf
>>> file in /etc/shorewall and everything else is in, say, /opt/shorewall,
>>> "shorewall update" is royally screwed!
>>>
>>
>> Patient: "Dr., it hurts when I do this".
>> Doctor: "Then don't do that"
>>
> What is that supposed to mean? Your "shorewall update" command is not
> working, so smart-arse comments like the one above won't get you far.
Again -- Shorewall currently doesn't handle non-standard file
hierarchies; I get it!
>
> On all my systems I have shorewall.conf file in /etc/shorewall,
> consisting of a single line - "INCLUDE <real_path>/shorewall.conf" - to
> include my own shorewall.conf file used for that particular
> configuration (this was your idea by the way, if I remember correctly!).
>
> When I execute "shorewall update", it is not doing what's supposed to be
> doing, so I doubt that you getting rather upset or cracking smart-arse
> comments like the one above would help fixing that particular bug!
Again -- Shorewall currently doesn't handle non-standard file
hierarchies; I get it!
>
>> I'm unable to reproduce this -- please send me a test case with
>> capabilities file.
>>
> I will, but it won't be today as I'll be rather busy in the coming days
> - will see if I could get it done by mid-week, if I can.
>
>>> 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.
>
>>> I also get this:
>>>
>>> /usr/share/shorewall/lib.cli-std: line 61: id: command not found
>>>
>>> which is also nonsensical as "id" does exist, but it is in a different
>>> location.
>>>
>>> This all stems from the fact that throughout shorewall, various paths
>>> are "assumed" and there is no central place from where those are picked
>>> up - the whole thing is a mess!
>>>
>>
>> You are talking out of the wrong orifice -- Line 61 in lib.cli-std reads:
>>
>> if [ -z "$g_export" -a "$(id -u)" = 0 ]; then
>>
>> Do you get the above diagnostic when using the '-e' option?
>>
> As I already pointed out in the above post, I have turned on all tracing
> and debugging when running this, but I'll prepare a test case with
> capabilities file for you.
In my tests, the message is suppressed when using the -e option; which
is the proper procedure
>
>>> It would be nice if shorewall had a single file (maybe similar to
>>> shorewall-pkg.config, but on the installed machine where shorewall
>>> functions) where it stores various path names and program names etc and
>>> not have them scattered all over the place. Not to mention that if I
>>> want to remove shorewall this would be nigh-impossible without messing
>>> with my system for hours!
>>>
>>
>> Yeah, I've been considering that for a while, but haven't mustered the
>> energy to do it.
>>
> Installing/uninstalling/upgrading shorewall(-lite) on systems which do
> not have standard FHS is particularly painful!
>
> 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.
-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
