>> 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!
>> 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).
>
>>> 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!
>
>> 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.
>
>>> 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.
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!
> 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Š.
>
It is rather annoying!
>> 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.
>> 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!
------------------------------------------------------------------------------
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
