Shorewall devel - Jan 2005 - Idea: permit /etc/shorewall/masq to contain zones, as well as interfaces

Dear All,

Firstly, thank you very much - shorewall is great. I''m not a member of 
this list, and please forgive me if I am suggesting something stupid, but 
the following occurs to me, and I thought it might be useful.

Why no make it possible to specify zones as well as interfaces in the 
/etc/shorewall/masq file ?

Eg: instead of:

 	eth0	eth1

one might write:

 	net	loc			(or masq in Mandrake).


A reason this would be useful is for backup internet connectivity.

Eg: local network on eth1, masqueraded. ADSL modem on eth0. Backup dialup
modem on ppp0. ppp0 and eth0 are both part of the net zone (in 
/etc/shorewall/zones); usually only one of the interfaces is working.

Here is my /etc/shorewall/masq file. The result works fine, but I think it 
seems kludgy. It''s also unclear what might happen if both eth0 and ppp0
were up at the same time.

-----------------------------------
#Normally, we want to use eth0 (ADSL) for internet access
#But in emergencies, use ppp0 instead.
eth0                    eth1
ppp0                    eth1
------------------------------------


[I''m using shorewall-2.0.8-1mdk on Mandrake 10.1. I hope this is useful
rather than daft!]


Regards

Richard

Hello Richard,

Richard wrote:
> Firstly, thank you very much - shorewall is great.
You''re welcome. I''m glad that you find it useful.
> I''m not a member of
> this list, and please forgive me if I am suggesting something stupid,
> but the following occurs to me, and I thought it might be useful.
> 
> Why no make it possible to specify zones as well as interfaces in the
> /etc/shorewall/masq file ?
> 
> Eg: instead of:
> 
>     eth0    eth1
> 
> one might write:
> 
>     net    loc            (or masq in Mandrake).
> 
> 
> A reason this would be useful is for backup internet connectivity.
> 
> Eg: local network on eth1, masqueraded. ADSL modem on eth0. Backup dialup
> modem on ppp0. ppp0 and eth0 are both part of the net zone (in
> /etc/shorewall/zones); usually only one of the interfaces is working.
> 
> Here is my /etc/shorewall/masq file. The result works fine, but I think
> it seems kludgy.
What seems kludgy about it?
> It''s also unclear what might happen if both eth0 and
> ppp0 were up at the same time.
> 
It would work fine -- see Shorewall FAQ 32.
> -----------------------------------
> #Normally, we want to use eth0 (ADSL) for internet access
> #But in emergencies, use ppp0 instead.
> eth0                    eth1
> ppp0                    eth1
> ------------------------------------
> 
> 
> [I''m using shorewall-2.0.8-1mdk on Mandrake 10.1. I hope this is
useful
> rather than daft!]
>
Thank you for the suggestion. I''m inclined, however, to reject it on
two
grounds:

1. In Shorewall, Zones are defined based on security requirements
whereas Masquerading/SNAT is defined based on routing deficiencies
(including the use of RFC 1918 addresses which are not
internet-routable). So while the requirements for using MASQ/SNAT may
coincide with firewall security requirements in a particular case, there
is no reason that they should coincide in general.

2. It is not possible to use zone definitions directly in setting up
MASQ/SNAT rules. That is becuase zone definitions are typically tied to
interfaces and rules in the POSTROUTING chain (where MASQ/SNAT is
specified) cannot be qualified by source interface. So when you write
	
	eth0	eth1

in /etc/shorewall/masq, what Shorewall generates is:

	for each route out of eth1
		eth0	<target of the route>

That''s why the interface ("eth1" in this case) must be up and
running
when Shorewall starts and also why people get messed up if there are
hosts connected to eth1 that are managed by Proxy ARP or when they have
asymmetric routing.

Suppose that zone Z is based on these two /etc/shorewall/hosts entries:

	Z	eth1:0.0.0.0/0
	Z	eth2:192.168.4.9

In that case, Shorewall can''t configure Netfilter to match this
/etc/shorewall/entry:

	eth0	Z

Do you see why? (hint: consider traffic from 192l.168.4.9 arriving on
eth3). Then you also see that although Shorewall allows it, even this
entry cannot be matched exactly:

	eth0	eth1

I let myself get talked into allowing interface names in the SUBNET
column of /etc/shorewall/masq entries and I mildly regret it; I''m not
inclined to compound the problem by allowing zone names as well.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Dear Tom,

Thanks for your email,

Tom Eastep wrote:
> Hello Richard,
> 
> Richard wrote:
> 
> 
>>Firstly, thank you very much - shorewall is great.
> 
> 
> You''re welcome. I''m glad that you find it useful.
> 
> 
>>I''m not a member of
>>this list, and please forgive me if I am suggesting something stupid,
>>but the following occurs to me, and I thought it might be useful.
>>
>>Why no make it possible to specify zones as well as interfaces in the
>>/etc/shorewall/masq file ?
>>
>>Eg: instead of:
>>
>>    eth0    eth1
>>
>>one might write:
>>
>>    net    loc            (or masq in Mandrake).
>>
>>
>>A reason this would be useful is for backup internet connectivity.
>>
>>Eg: local network on eth1, masqueraded. ADSL modem on eth0. Backup
dialup
>>modem on ppp0. ppp0 and eth0 are both part of the net zone (in
>>/etc/shorewall/zones); usually only one of the interfaces is working.
>>
>>Here is my /etc/shorewall/masq file. The result works fine, but I think
>>it seems kludgy.
> 
> 
> What seems kludgy about it?

It seems a bit odd - Shorewall''s paradigm seemed to me to be about 
routing traffic from one zone to another, rather than from one interface 
to another. I wondered where exactly the packets would go, if they had 
two alternative destinations.
> 
> 
>>It''s also unclear what might happen if both eth0 and
>>ppp0 were up at the same time.
>>
> 
> 
> It would work fine -- see Shorewall FAQ 32.
Thanks. Sorry, I didn''t have net access at the time I was setting it
up,
and was relying only on the comments in the /etc/shorewall/masq file.
Perhaps this is an example worthy of inclusion?
> 
> 
>>-----------------------------------
>>#Normally, we want to use eth0 (ADSL) for internet access
>>#But in emergencies, use ppp0 instead.
>>eth0                    eth1
>>ppp0                    eth1
>>------------------------------------
>>
>>
>>[I''m using shorewall-2.0.8-1mdk on Mandrake 10.1. I hope this
is useful
>>rather than daft!]
>>
> 
> 
> Thank you for the suggestion. I''m inclined, however, to reject it
on two
> grounds:
> 
> 1. In Shorewall, Zones are defined based on security requirements
> whereas Masquerading/SNAT is defined based on routing deficiencies
> (including the use of RFC 1918 addresses which are not
> internet-routable). So while the requirements for using MASQ/SNAT may
> coincide with firewall security requirements in a particular case, there
> is no reason that they should coincide in general.
This makes sense - thank you for the explanation. However, perhaps using 
a zone could be parsed correctly in those situation where it is
meaningful.
> 
> 2. It is not possible to use zone definitions directly in setting up
> MASQ/SNAT rules. That is becuase zone definitions are typically tied to
> interfaces and rules in the POSTROUTING chain (where MASQ/SNAT is
> specified) cannot be qualified by source interface. So when you write
> 	
> 	eth0	eth1
> 
> in /etc/shorewall/masq, what Shorewall generates is:
> 
> 	for each route out of eth1
> 		eth0	<target of the route>
> 
> That''s why the interface ("eth1" in this case) must be
up and running
> when Shorewall starts and also why people get messed up if there are
> hosts connected to eth1 that are managed by Proxy ARP or when they have
> asymmetric routing.
So, why does this work if I bring up ppp0 after shorewall has started? 
The following sequence works:

start eth0
start shorewall
stop eth0
start ppp0.
> 
> Suppose that zone Z is based on these two /etc/shorewall/hosts entries:
> 
> 	Z	eth1:0.0.0.0/0
> 	Z	eth2:192.168.4.9
> 
> In that case, Shorewall can''t configure Netfilter to match this
> /etc/shorewall/entry:
> 
> 	eth0	Z
> 
> Do you see why? (hint: consider traffic from 192l.168.4.9 arriving on
> eth3). Then you also see that although Shorewall allows it, even this
> entry cannot be matched exactly:
> 
> 	eth0	eth1
> 
> I let myself get talked into allowing interface names in the SUBNET
> column of /etc/shorewall/masq entries and I mildly regret it; I''m
not
> inclined to compound the problem by allowing zone names as well.
> 
> -Tom
I see!

Perhaps it might be worth adding a sentence like the following (but 
better written!) into /etc/shorewall/masq, to prevent against this sort 
of confusion:

---------
# Example 6:
#
#       You want all traffic from the local zone to be masqueraded
#	and sent out to the net zone. In this case, it is necessary
#	to specify interfaces rather than zones, but it is OK to
#	have more than one destination. Eg eth1 is the internal network; # 
eth0 and/or ppp0 are connected to the Internet. For example,
#	a DSL internet connection with a dialup system for backup.
#
#		eth0	eth1
#		ppp0	eth1
#
---------


Best wishes

Richard

Richard Neill wrote:
> ...
> 
> It seems a bit odd - Shorewall''s paradigm seemed to me to be about
> routing traffic from one zone to another, rather than from one interface 
> to another. I wondered where exactly the packets would go, if they had 
> two alternative destinations.
Shorewall doesn''t control where your packets go - routing does.  All 
shorewall is doing is saying, "For packets that are going from A to B, 
masquerade them."  It doesn''t control the fact that they go from A
to B.
> ...
> Thanks. Sorry, I didn''t have net access at the time I was setting
it up,
> and was relying only on the comments in the /etc/shorewall/masq file.
> Perhaps this is an example worthy of inclusion?
Install the shorewall documentation - it includes the FAQ.
> ...
> Perhaps it might be worth adding a sentence like the following (but 
> better written!) into /etc/shorewall/masq, to prevent against this sort 
> of confusion:
> 
> ---------
> # Example 6:
> #
> #       You want all traffic from the local zone to be masqueraded
> #    and sent out to the net zone. In this case, it is necessary
> #    to specify interfaces rather than zones, but it is OK to
> #    have more than one destination. Eg eth1 is the internal network; # 
> eth0 and/or ppp0 are connected to the Internet. For example,
> #    a DSL internet connection with a dialup system for backup.
> #
> #        eth0    eth1
> #        ppp0    eth1
> #
I think that would be a useful addition regardless, since it''s a
typical
situation.  Of course, that means it needs to be maintained like 
documentation, which brings its own problems, right Tom?  :-)

-- 
Paul
<http://paulgear.webhop.net>
--
Tired of paying $600 for Microsoft Office?  Running an illegal copy and
want to make it legal?  Try OpenOffice.org!  It''s free and does most of
the things Microsoft Office does.  <http://www.openoffice.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050125/3399f60c/signature.bin

Paul Gear wrote:
> Richard Neill wrote:
> 
>> ...
>>
>> It seems a bit odd - Shorewall''s paradigm seemed to me to be
about
>> routing traffic from one zone to another, rather than from one
>> interface to another. I wondered where exactly the packets would go,
>> if they had two alternative destinations.
> 
> 
> Shorewall doesn''t control where your packets go - routing does. 
All
> shorewall is doing is saying, "For packets that are going from A to B,
> masquerade them."  It doesn''t control the fact that they go
from A to B.
> 
>> ...
>> Thanks. Sorry, I didn''t have net access at the time I was
setting it
>> up, and was relying only on the comments in the /etc/shorewall/masq
file.
>> Perhaps this is an example worthy of inclusion?
> 
> 
> Install the shorewall documentation - it includes the FAQ.
> 
>> ...
>> Perhaps it might be worth adding a sentence like the following (but
>> better written!) into /etc/shorewall/masq, to prevent against this
>> sort of confusion:
>>
>> ---------
>> # Example 6:
>> #
>> #       You want all traffic from the local zone to be masqueraded
>> #    and sent out to the net zone. In this case, it is necessary
>> #    to specify interfaces rather than zones, but it is OK to
>> #    have more than one destination. Eg eth1 is the internal network;
>> # eth0 and/or ppp0 are connected to the Internet. For example,
>> #    a DSL internet connection with a dialup system for backup.
>> #
>> #        eth0    eth1
>> #        ppp0    eth1
>> #
> 
> 
> I think that would be a useful addition regardless, since it''s a
typical
> situation.  Of course, that means it needs to be maintained like
> documentation, which brings its own problems, right Tom?  :-)
And this is covered completely in the Quickstart Guides -- sounds like
the OP failed to find those also. I haven''t a clue how people find and
install Shorewall but miss the documentation -- the download page is
plastered with links to the docs. The INSTALL file in the .rpm and .tgz
contains links to the docs. Is someone running around the world writing
the download URL on men''s room walls????? They must be writing the
address of the mailing list too, because people seem to be able to find
THAT also without being able to find the documentation.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep wrote:
> Paul Gear wrote:
> 
>>Richard Neill wrote:
>>
>>
>>>...
>>>
>>>It seems a bit odd - Shorewall''s paradigm seemed to me to
be about
>>>routing traffic from one zone to another, rather than from one
>>>interface to another. I wondered where exactly the packets would go,
>>>if they had two alternative destinations.
>>
>>
>>Shorewall doesn''t control where your packets go - routing does.
All
>>shorewall is doing is saying, "For packets that are going from A to
B,
>>masquerade them."  It doesn''t control the fact that they
go from A to B.
>>
>>
>>>...
>>>Thanks. Sorry, I didn''t have net access at the time I was
setting it
>>>up, and was relying only on the comments in the /etc/shorewall/masq
file.
>>>Perhaps this is an example worthy of inclusion?
>>
>>
>>Install the shorewall documentation - it includes the FAQ.
>>
>>
>>>...
>>>Perhaps it might be worth adding a sentence like the following (but
>>>better written!) into /etc/shorewall/masq, to prevent against this
>>>sort of confusion:
>>>
>>>---------
>>># Example 6:
>>>#
>>>#       You want all traffic from the local zone to be masqueraded
>>>#    and sent out to the net zone. In this case, it is necessary
>>>#    to specify interfaces rather than zones, but it is OK to
>>>#    have more than one destination. Eg eth1 is the internal
network;
>>># eth0 and/or ppp0 are connected to the Internet. For example,
>>>#    a DSL internet connection with a dialup system for backup.
>>>#
>>>#        eth0    eth1
>>>#        ppp0    eth1
>>>#
>>
>>
>>I think that would be a useful addition regardless, since it''s
a typical
>>situation.  Of course, that means it needs to be maintained like
>>documentation, which brings its own problems, right Tom?  :-)
> 
> 
> And this is covered completely in the Quickstart Guides -- sounds like
> the OP failed to find those also. I haven''t a clue how people find
and
> install Shorewall but miss the documentation -- the download page is
> plastered with links to the docs. The INSTALL file in the .rpm and .tgz
> contains links to the docs. Is someone running around the world writing
> the download URL on men''s room walls????? They must be writing the
> address of the mailing list too, because people seem to be able to find
> THAT also without being able to find the documentation.
> 
I shouldn''t write email responses before my first coffee. The case that
the OP is talking about is NOT covered in the Quickstart Guides. I''ll
consider adding it to the docs at least, after 2.2.0 is out.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

I''m using: shorewall-2.0.8-2mdk (Mandrake 10.2 Limited Edition 2005)
My comments below apply equally to latest shorewall CVS.

http://shorewall.net/FAQ.htm#faq1d
http://shorewall.net/FAQ.htm#faq2b

We need to combine FAQ #1D and FAQ #2B - they are the same thing and
repeat exactly the same shorewall code.  The code given is:
> DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176
Although it doesn''t say so explicitly, the above two FAQs must be
referring to a three-interface router with separate "net",
"dmz", and
"loc" networks.  (The case of the two-interface router is FAQ #2.)

Why is the "ORIGINAL DEST" (and all the ETH0_IP code given for a
dynamic
IP) needed in the above three-interface example?  I''m running an FTP
server in the DMZ and my local clients (on a different interface from
the DMZ) can see the FTP server in the DMZ just fine using the external
address, without giving the ORIGINAL DEST IP in the shorewall rule.
I think both these FAQs should say just this:

 DNAT loc dmz:192.168.2.4 tcp 80

Isn''t the external IP needed only if we want to match a *particular*
original destination IP (using --ctorigdst)?  If we only have one
external IP address, we don''t need to specify it in the rule.

All the code given to set ETH0_IP can be moved to a separate FAQ ("How
do I port forward only one of my multiple external addresses"?) for
both these FAQs.  It isn''t needed unless we want to match a particular
external IP (which I would think is fairly rare).

The key point to get across in both these FAQs is that we need a simple
rule to DNAT the local net to the DMZ as well as a rule to DNAT the
external net to the DMZ.  The fine point about selecting which external IP
to use is a secondary concern, not the direct issue raised by these FAQs.


Sending router traffic into the DMZ via the external addresses
--------------------------------------------------------------

We might mention at the same time that we need a third rule to DNAT the
router packets into the DMZ, if we also want the router to access our
DMZ servers by their external addresses:

 DNAT fw dmz:192.168.2.4 tcp 80


Sending DMZ traffic into the DMZ via the external addresses
-----------------------------------------------------------

For completeness, we could finally mention that if we want our DMZ clients
to access servers in the DMZ using the server external addresses, we
need a fourth rule in the router to DNAT the DMZ to the DMZ.  You might
wonder if the fact that both the clients and the server are on the same
DMZ network might cause problems; it does.

The first problem is that shorewall needs to permit traffic that comes
from the DMZ to return to the DMZ.  The "routeback" option must be set
on the dmz zone in shorewall/interfaces, to allow packets coming into
the router from the DMZ to be routed right back out to the DMZ again:

 dmz eth1 detect routeback

The second problem is that a packet arriving in the DMZ via the router
with a source address in the DMZ will not have reply packets routed
correctly, since the reply will go directly to the client on the same
network and will not return via the router.

There are two ways to work around the reply problem - both ways force
the source address of the DMZ client packet to appear to come from the
router instead of from the actual DMZ client (using SNAT).  The SNAT
is needed because the (web) server is on the same network as the DMZ
client, and return packets would not pass through the router unless the
source address were set this way.  (For a full explanation of this see:
http://idallen.com/dnat.txt )


Reply packet fix method 1:
--------------------------

We can add this complex rule to shorewall/rules to get the SNAT we need:

 DNAT dmz:192.168.2.0/24 dmz:192.168.2.4 tcp 80 - 206.124.146.176:192.168.2.254

The above line is complicated because it is doing two things at the
same time.  It''s a combination of a simple DNAT of the DMZ to the DMZ
mixed with the extra addresses that tell shorewall to SNAT to the router
address (192.168.2.254) all packets that (a) come from the DMZ and (b)
go back out the DMZ to the web server.


Reply packet fix method 2:
--------------------------

This is cleaner than the above but it means adding a line to the
shorewall/interfaces file something like this (192.168.2.254 is the
router address for eth1, eth1 is the DMZ network):

 # shorewall/interfaces:
 # SNAT to 192.168.2.254 all traffic coming from the DMZ that goes back
 # to the DMZ (which happens when DMZ clients access DMZ servers using
 # external interface IP addresses on the router):
 #
 eth1  eth1  192.168.2.254

With the above line in shorewall/interfaces, the fourth DNAT line in
shorewall/rules becomes much simpler and familiar:

 DNAT dmz dmz:192.168.2.4 tcp 80

Note that the necessary use of SNAT means that packets from any DMZ
clients that go to DMZ services via the router (via the external IP
addresses) will appear, to the service, to be from the router, not from
the DMZ client, and replies to those packets will return via the router.

Ian! D. Allen wrote:
> I''m using: shorewall-2.0.8-2mdk (Mandrake 10.2 Limited Edition
2005)
> My comments below apply equally to latest shorewall CVS.
> 
> http://shorewall.net/FAQ.htm#faq1d
> http://shorewall.net/FAQ.htm#faq2b
> 
> We need to combine FAQ #1D and FAQ #2B - they are the same thing and
> repeat exactly the same shorewall code.
#1d was recently cloned from 2b because people couldn''t seem to find 2b
reliably. You can change it back to the way it was before -- fine with
me as I don''t have to answer the user questions any more...

The code given is:
> 
>>DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176
> 
> Although it doesn''t say so explicitly, the above two FAQs must be
> referring to a three-interface router with separate "net",
"dmz", and
> "loc" networks.  (The case of the two-interface router is FAQ
#2.)
The number of interfaces is irrelevant although you are correct that it
must be three or more -- the point is that the server and the clients
are on different internal LANs.
> 
> Why is the "ORIGINAL DEST" (and all the ETH0_IP code given for a
dynamic
> IP) needed in the above three-interface example?  I''m running an
FTP
> server in the DMZ and my local clients (on a different interface from
> the DMZ) can see the FTP server in the DMZ just fine using the external
> address, without giving the ORIGINAL DEST IP in the shorewall rule.
Tried to access any external FTP servers from your local LAN lately?
I''ll bet that they all seem to have exactly the same content as your
own
server :-)
> I think both these FAQs should say just this:
> 
>  DNAT loc dmz:192.168.2.4 tcp 80
> 
> Isn''t the external IP needed only if we want to match a
*particular*
> original destination IP (using --ctorigdst)?  If we only have one
> external IP address, we don''t need to specify it in the rule.
With the rule "DNAT loc dmz:192.168.2.4 tcp 80", there are two
possibilities:

a) DETECT_DNAT_ADDRS=Yes in shorewall.conf. Shorewall determines the
first IP address of each interface to the ''loc'' zone and for
HTTP
traffic destined for each of those IP addresses, it generates a DNAT
rule to 192.168.2.4.

b) DETECT_DNAT_ADDRS=No in shorewall.conf. All HTTP traffic from the loc
zone (to any IP address whatsoever) is redirected to 192.168.2.4.

Without attaching meaning to zone names, Shorewall cannot suddenly
decide that neither of those is appropriate and that it should look at
interfaces to the ''net'' zone to determine which traffic to
redirect?;
''net'' doesn''t even appear in the rule. Hence, it is
necessary to specify
the original destination IP address.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep wrote:
> Tried to access any external FTP servers from your local LAN lately?
> I''ll bet that they all seem to have exactly the same content as
your own
> server :-)
Indeed they do.  I missed that.  That''s why we pay you the big bucks! 
:-)

We need to add a note explaining this good stuff into the FAQ - unless
you''ve already explained this somewhere and I missed it?

-- 
-IAN!  Ian! D. Allen       Ottawa, Ontario, Canada - www.ottawa.ca
       EMail: idallen@idallen.ca   Home Page: http://www.idallen.com/
       College professor (Linux) via: http://teaching.idallen.com/
       Support free and open public digital rights:  http://eff.org/

Ian! D. Allen wrote:
> Tom Eastep wrote:
>>Tried to access any external FTP servers from your local LAN lately?
>>I''ll bet that they all seem to have exactly the same content as
your own
>>server :-)
> 
> Indeed they do.  I missed that.  That''s why we pay you the big
bucks!  :-)
> 
> We need to add a note explaining this good stuff into the FAQ - unless
> you''ve already explained this somewhere and I missed it?
> 
I don''t believe that it is explained in the FAQ -- OTOH, the FAQ is
getting
pretty large and it certainly isn''t feasible to explain everything
about
Shorewall in that single document.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Tom Eastep wrote:
> Ian! D. Allen wrote:
> 
>>Tom Eastep wrote:
>>
>>>Tried to access any external FTP servers from your local LAN lately?
>>>I''ll bet that they all seem to have exactly the same
content as your own
>>>server :-)
>>
>>Indeed they do.  I missed that.  That''s why we pay you the big
bucks!  :-)
>>
>>We need to add a note explaining this good stuff into the FAQ - unless
>>you''ve already explained this somewhere and I missed it?
>>
> 
> 
> I don''t believe that it is explained in the FAQ -- OTOH, the FAQ
is getting
> pretty large and it certainly isn''t feasible to explain everything
about
> Shorewall in that single document.
Perhaps using something like FAQ-O-Matic or a FAQ wiki would make
maintenance easier.  What think y''all?

-- 
Paul
<http://paulgear.webhop.net>
--
Did you know?  Using Microsoft Internet Explorer can make your computer
less secure.  Find out more at <http://browsehappy.com>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050523/9f401cf6/signature.bin

2005/5/22, Paul Gear <paul@gear.dyndns.org>:
> Perhaps using something like FAQ-O-Matic or a FAQ wiki would make
> maintenance easier.  What think y''all?
> 
yes; I ''ll propose a similar thing.
a wiki-FAQ will be very nice.
the "problem" is the mirrors,since wikis are dinamically generated,The
FAQ needs to be linked to the master site in the mirrors.( or database
replication will be needed.)

ideas are _really_ welcome ;)

> 
> 2005/5/22, Paul Gear <paul@gear.dyndns.org>:
> 
> > Perhaps using something like FAQ-O-Matic or a FAQ wiki would make 
> > maintenance easier.  What think y''all?
> > 
> yes; I ''ll propose a similar thing.
> a wiki-FAQ will be very nice.
> the "problem" is the mirrors,since wikis are dinamically 
> generated,The FAQ needs to be linked to the master site in 
> the mirrors.( or database replication will be needed.)
> 
> ideas are _really_ welcome ;)
DocuWiki (http://wiki.splitbrain.org/wiki:dokuwiki) is file based, so it
should mirror easily.

Ron

Paul Gear wrote:
> 
> Perhaps using something like FAQ-O-Matic or a FAQ wiki would make
> maintenance easier.  What think y''all?
> 
In the spirit of "Those who fail to study history are doomed to re-live
it",
I would remind you that Alex Martin hosted a Shorewall FAQ Wiki for some
months then abandoned it. The list may wish to review the outcome of that
unhappy experiment before establishing another Wiki.

Maybe there is more community involvement now and things will be different
-- I hope so.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

On Sun, 2005-05-22 at 18:18, Tom Eastep wrote:
> In the spirit of "Those who fail to study history are doomed to
re-live it",
> I would remind you that Alex Martin hosted a Shorewall FAQ Wiki for some
> months then abandoned it. The list may wish to review the outcome of that
> unhappy experiment before establishing another Wiki.
Tom,
I remember well. :-(

Alex did a fine job setting up MediaWiki though. :-)
> Maybe there is more community involvement now and things will be different
> -- I hope so.
Maybe, but it sounds like people are talking toward a CMS. A CMS is
dynamic and powerful, but not easily mirrored. Also, SF recently changed
its policy on web writable files and directories. This complicates the
use and mirroring of any file based web script/application.

        SourceForge.net: Project Web, Shell and Database Services
        Group Directories are Read-Only
        https://sourceforge.net/docs/E07/#environment

        CMS Matrix
        http://cmsmatrix.org/

-- 
Mike Noyes <mhnoyes at users.sourceforge.net>
http://sourceforge.net/users/mhnoyes/
SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs

Tom Eastep wrote:
> ...
>>Perhaps using something like FAQ-O-Matic or a FAQ wiki would make
>>maintenance easier.  What think y''all?
> 
> In the spirit of "Those who fail to study history are doomed to
re-live it",
> I would remind you that Alex Martin hosted a Shorewall FAQ Wiki for some
> months then abandoned it. The list may wish to review the outcome of that
> unhappy experiment before establishing another Wiki.
> 
> Maybe there is more community involvement now and things will be different
> -- I hope so.
I hope so too.  I think one way of encouraging this would be to put
*all* of the official documentation in a Wiki.  We really have no
choice - either we find a true documentation champion, or we all have
to contribute a little, and a wiki (or CMS, as Mike suggests) is a
good way to do it.

-- 
Paul Gear, Manager IT Operations, Redlands College
38 Anson Road, Wellington Point 4160, Australia
(Please send attachments in portable formats such as PDF, HTML, or
OpenOffice.)
-- 
The information contained in this message is copyright by Redlands
College.  Any use for direct sales or marketing purposes is expressly
forbidden.  This message does not represent the views of Redlands
College.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url :
http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050523/f45d5562/signature.bin