shorewall-devel — Shoreline Firewall development

Re: [Shorewall-devel] send patchs (for CROSSBEAM)

[Tom E. <te...@sh...>]

Paul Gear wrote:
> Tom Eastep wrote:
>>...
>>Thanks, Juan
>>
>>Guys: I'll put Juan's patch in 2.4.0 and I'll let you decide if you want
>>to release it in 2.0 and 2.2.
>>...
>>I have added the CROSSBEAM patch to 2.4.0 but I'm withholding the 
>>POLICY_ACCEPT_STARTING patch for now. I really don't like the idea of
>> an option that opens the firewall completely like this one does.
>>
>>I suspect that an option in shorewall.conf that works in conjunction 
>>with /etc/shorewall/routestopped would be more appropriate for both 
>>the 2.2 and 2.4 series (since 2.2.3, communication *between* hosts 
>>listed in routestopped is now enabled during [re]start).
> 
> It seems to me that both of these are very similar circumstances to my
> issue a few weeks/months back about restarting shorewall on a
> high-availability firewall running heartbeat.  In that case, it seems
> that a more general approach that works in conjunction with routestopped
> would be warranted.  Once we get CVS converted over to sf.net, i'll do a
> bit of work on integrating them.
> 

In -RC1, I extended the routestopped options to include 'source' and 'dest'
to indicate that all traffic from or to a host or set of hosts respectively
should be accepted. I'm not sure that my changes solve the entire problem
that Juan's customers are seeing but I think that it is in the right
direction. If folks on the list disagree, I'll back out that change in -RC2
and the new maintainers can decide how best to address this issue.

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

RE: FAQ structure WAS:[Shorewall-devel] port forwarding ...

[Ron S. <rsh...@cr...>]

 
> 
> 2005/5/22, Paul Gear <pa...@ge...>:
> 
> > 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

FAQ structure WAS:[Shorewall-devel] port forwarding ...

[Cristian R. <jud...@gm...>]

2005/5/22, Paul Gear <pa...@ge...>:

> Perhaps using something like FAQ-O-Matic or a FAQ wiki would make
> maintenance easier.  What think y'all?
>=20
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 ;)

Re: [Shorewall-devel] port forwarding and use of ORIGINAL DEST - FAQ #1D and #2B

[Paul G. <pa...@ge...>]

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>.

Re: [Shorewall-devel] send patchs (for CROSSBEAM)

[Paul G. <pa...@ge...>]

Tom Eastep wrote:
> ...
> Thanks, Juan
> 
> Guys: I'll put Juan's patch in 2.4.0 and I'll let you decide if you want
> to release it in 2.0 and 2.2.
> ...
> I have added the CROSSBEAM patch to 2.4.0 but I'm withholding the 
> POLICY_ACCEPT_STARTING patch for now. I really don't like the idea of
>  an option that opens the firewall completely like this one does.
> 
> I suspect that an option in shorewall.conf that works in conjunction 
> with /etc/shorewall/routestopped would be more appropriate for both 
> the 2.2 and 2.4 series (since 2.2.3, communication *between* hosts 
> listed in routestopped is now enabled during [re]start).

It seems to me that both of these are very similar circumstances to my
issue a few weeks/months back about restarting shorewall on a
high-availability firewall running heartbeat.  In that case, it seems
that a more general approach that works in conjunction with routestopped
would be warranted.  Once we get CVS converted over to sf.net, i'll do a
bit of work on integrating them.

-- 
Paul
<http://paulgear.webhop.net>
--
Did you know?  Most email-borne viruses use a false sender address, so
you cannot track down the sender using that address.  Instead, keep your
virus scanning software up-to-date and just delete any suspicious emails
you receive.

Re: [Shorewall-devel] port forwarding and use of ORIGINAL DEST - FAQ #1D and #2B

[Tom E. <te...@sh...>]

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  \ te...@sh...
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

Re: [Shorewall-devel] port forwarding and use of ORIGINAL DEST - FAQ #1D and #2B

[Ian! D. A. <id...@id...>]

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: id...@id...   Home Page: http://www.idallen.com/
       College professor (Linux) via: http://teaching.idallen.com/
       Support free and open public digital rights:  http://eff.org/

Re: [Shorewall-devel] port forwarding and use of ORIGINAL DEST - FAQ #1D and #2B

[Tom E. <te...@sh...>]

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  \ te...@sh...
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key

[Shorewall-devel] port forwarding and use of ORIGINAL DEST - FAQ #1D and #2B

[Ian! D. A. <id...@id...>]

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.

[Shorewall-devel] Multiple Internet connections with Dynamic IP addresses

[Tom E. <te...@sh...>]

Cristian and Alex,

Both of you have asked about this. A routing table can only have one default
route so when the second link comes up, adding the second default route will
fail. So in general, Shorewall can only reliably detect the gateway for
P-T-P connections which is what the CVS current code does.

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

Re: [Shorewall-devel] send patchs

[Tom E. <te...@sh...>]

Juan J. Prieto wrote:
>
> 
>   Also, some of our clients need to permit all new traffic during
> iptables compilling (shorewall start or restart) because they have a
> great number of zones and rules, so I have had to add a new
> configuration variable POLICY_ACCEPT_STARTING. If it is set to 'Yes',
> then DROP default policy will be added at the end of compilling period.
> 

I have added the CROSSBEAM patch to 2.4.0 but I'm withholding the
POLICY_ACCEPT_STARTING patch for now. I really don't like the idea of an
option that opens the firewall completely like this one does.

I suspect that an option in shorewall.conf that works in conjunction with
/etc/shorewall/routestopped would be more appropriate for both the 2.2 and
2.4 series (since 2.2.3, communication *between* hosts listed in
routestopped is now enabled during [re]start).

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

Re: [Shorewall-devel] send patchs

[Tom E. <te...@sh...>]

Juan J. Prieto wrote:
> Hi,
> 
>   Here is the shorewall.conf patch.
> 


Thanks, Juan!

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

Re: [Shorewall-devel] send patchs

[Juan J. P. <jjp...@en...>]

Hi,

  Here is the shorewall.conf patch.

Enjoy ;-) !

El vie, 20-05-2005 a las 10:57 -0700, Tom Eastep escribi=F3:
> Juan J. Prieto wrote:
> > Hi,
> >=20
> >   Here is the patch for shorewall-2.0 and 2.2.
> >=20
>=20
> Juan -- Isn't a patch required for shorewall.conf also? Or do you want
> this feature to be undocumented?
>=20
> Thanks,
> -Tom
--=20
Juan Jes=FAs Prieto - Consultor=EDa TI
jjp...@en...
http://www.eneotecnologia.com
---------------------------------------
fingerprint: BFC2 0370 7708 F800 0BEC  60A4 EC71 4BB1 CC85 99F5
http://pgp.rediris.es:11371/pks/lookup?op=3Dget&search=3D0xCC8599F5

Re: [Shorewall-devel] send patchs

[Juan J. P. <jjp...@en...>]

Hi Tom,

El vie, 20-05-2005 a las 10:57 -0700, Tom Eastep escribi=F3:
> Juan J. Prieto wrote:
> > Hi,
> >=20
> >   Here is the patch for shorewall-2.0 and 2.2.
> >=20
>=20
> Juan -- Isn't a patch required for shorewall.conf also? Or do you want
> this feature to be undocumented?

  Ok (sorry ;-)), I'll make a patch for shorewall.conf.

Regards.
--=20
Juan Jes=FAs Prieto - Consultor=EDa TI
jjp...@en...
http://www.eneotecnologia.com
---------------------------------------
fingerprint: BFC2 0370 7708 F800 0BEC  60A4 EC71 4BB1 CC85 99F5
http://pgp.rediris.es:11371/pks/lookup?op=3Dget&search=3D0xCC8599F5

Re: [Shorewall-devel] send patchs

[Tom E. <te...@sh...>]

Juan J. Prieto wrote:
> Hi,
> 
>   Here is the patch for shorewall-2.0 and 2.2.
> 

Juan -- Isn't a patch required for shorewall.conf also? Or do you want
this feature to be undocumented?

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

Re: [Shorewall-devel] send patchs

[Tom E. <te...@sh...>]

Juan J. Prieto wrote:
> Hi,
> 
>   Here is the patch for shorewall-2.0 and 2.2.
> 
> Regards.

Thanks, Juan

Guys: I'll put Juan's patch in 2.4.0 and I'll let you decide if you want
to release it in 2.0 and 2.2.

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

Re: [Shorewall-devel] send patchs

[Juan J. P. <jjp...@en...>]

Hi,

  Here is the patch for shorewall-2.0 and 2.2.

Regards.

El vie, 20-05-2005 a las 10:25 -0700, Tom Eastep escribi=F3:
> Juan J. Prieto wrote:
>=20
> >   I'm working on a patch for shorewall to make it run with a Crossbeam
> > X40 machine (www.crossbeamsystems.com) and I would like to know where t=
o
> > send it, is this list the correct location?.
> >=20
>=20
> Yes,
>=20
> Thanks, Juan
> -Tom
--=20
Juan Jes=FAs Prieto - Consultor=EDa TI
jjp...@en...
http://www.eneotecnologia.com
---------------------------------------
fingerprint: BFC2 0370 7708 F800 0BEC  60A4 EC71 4BB1 CC85 99F5
http://pgp.rediris.es:11371/pks/lookup?op=3Dget&search=3D0xCC8599F5

Re: [Shorewall-devel] send patchs

[Tom E. <te...@sh...>]

Juan J. Prieto wrote:

>   I'm working on a patch for shorewall to make it run with a Crossbeam
> X40 machine (www.crossbeamsystems.com) and I would like to know where to
> send it, is this list the correct location?.
> 

Yes,

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

[Shorewall-devel] send patchs

[Juan J. P. <jjp...@en...>]

Hi all,

  I'm working on a patch for shorewall to make it run with a Crossbeam
X40 machine (www.crossbeamsystems.com) and I would like to know where to
send it, is this list the correct location?.

  The patch is necesary because of Crossbeam X series running mode: when
you make a shorewall start, restart or clear, there are a packet
dropping until shorewall is Started or cleaned. At this moment the CPM
Crossbeam module send a reset signal to the APM module (where the Linux
system is running shorewall). With this patch, if you declare
CROSSBEAM=3Dyes in shorewall.conf, first shorewall will set main policies
to ACCEPT, then setcontinue in chains INPUT, FORWARD and OUTPUT, insert
particular rules for Crossbeam backbone, and finally set main policies
to DROP.

  Also, some of our clients need to permit all new traffic during
iptables compilling (shorewall start or restart) because they have a
great number of zones and rules, so I have had to add a new
configuration variable POLICY_ACCEPT_STARTING. If it is set to 'Yes',
then DROP default policy will be added at the end of compilling period.

  Regards.


cheer up, Tom!

--=20
Juan Jes=FAs Prieto - Consultor=EDa TI
jjp...@en...
http://www.eneotecnologia.com
---------------------------------------
fingerprint: BFC2 0370 7708 F800 0BEC  60A4 EC71 4BB1 CC85 99F5
http://pgp.rediris.es:11371/pks/lookup?op=3Dget&search=3D0xCC8599F5

Re: [Shorewall-devel] Multi ISP support restart/default route issue

[Tom E. <te...@sh...>]

Alexander Wilms wrote:
> Hi Tom,
> 
> as you requested via ICQ, here comes the "restart trace" file.
> 
> If I'm right, a restart or a clear/start cycle doesn't flush the default 
> routing entry, but shorewall tries to generate it again. 
> Result: RTNETLINK answers: File exists
> 

This problem is corrected by the 'firewall' script in
http://shorewall.net/pub/shorewall/2.3/shorewall-2.3.2/errata.

Thanks, Alex

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

[Shorewall-devel] Multi ISP support restart/default route issue

[Alexander W. <ale...@ad...>]

Hi Tom,

as you requested via ICQ, here comes the "restart trace" file.

If I'm right, a restart or a clear/start cycle doesn't flush the default 
routing entry, but shorewall tries to generate it again. 
Result: RTNETLINK answers: File exists

Thank you,
Alex

Re: [Shorewall-devel] patches

[Tom E. <te...@sh...>]

Jerry Vonau wrote:

> Patches attached, are they in the correct format?

They are perfect, Jerry. Thanks.

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

[Shorewall-devel] patches

[Jerry V. <jv...@sh...>]

Hi all:

The new providers file was not in the install.sh and shorewall.spec
files
Patches attached, are they in the correct format?
Jerry

Re: [Shorewall-devel] What happens now?

[Tom E. <te...@sh...>]

Mike Noyes wrote:
> On Thu, 2005-05-19 at 14:38, Tom Eastep wrote:
>>Mailing Lists: I'm currently running a later version of Mailman than are
>>SF. Mike tells me that SF are upgrading in the near future. Once they
>>have done so, it will be easier to do the move. When the mailing lists
>>move, the web site need to be updated to reflect the move. Just let me
>>know what I need to do here.
> 
> Tom,
> The issue becomes the SF meaning of "near future". How long are you
> willing to maintain the mailing lists?

Maintaining the lists is pretty easy now that I got rid of htdig. I'll
maintain them until SF upgrades.

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

Re: [Shorewall-devel] What happens now?

[Mike N. <mh...@us...>]

On Thu, 2005-05-19 at 14:38, Tom Eastep wrote:
> Mailing Lists: I'm currently running a later version of Mailman than are
> SF. Mike tells me that SF are upgrading in the near future. Once they
> have done so, it will be easier to do the move. When the mailing lists
> move, the web site need to be updated to reflect the move. Just let me
> know what I need to do here.

Tom,
The issue becomes the SF meaning of "near future". How long are you
willing to maintain the mailing lists?


Strategic Projects =C2=BB Mailing List Service=20
https://sourceforge.net/docman/display_doc.php?group_id=3D1&docid=3D2352

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