I believe that 2.4.0 is about ready to be sent out the door. I''ve made a couple of small changes since RC2 but I don''t believe that they warrant another RC. There remains the issue of what to do about support for Shorewall 2.0 given that 2.2 has only been available since March. It would be my recommendation to make 2.4 the new "stable" release but continue to support 2.0 and 2.2 until 2.6 comes out. My reasoning is as follows: a) I suspect that there are still a lot of users on 2.0, given the rather recent availability of 2.2. b) The differences between 2.0 and 2.2 are largely additive so people shouldn''t find it too confusing to continue to support 2.0. Also, we still have a single set of documentation covering all three releases so it''s not as if one has to go back to old versions of the docs to research how 2.0 worked. c) The differences between 2.2 and 2.4 are almost entirely additive (there are only two minor upgrade issues). The above is only my recommendation and should be taken as such. It is you folks that are going to have to support Shorewall going forward and this should be your decision. I think that we need to resolve this issue before announcing 2.4.0 to avoid confusion among the user base. -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050602/644716b5/attachment.bin
Tom Eastep wrote:> > It would be my recommendation to make 2.4 the new "stable" release but > continue to support 2.0 and 2.2 until 2.6 comes out.I just noticed on Sourceforge that Paul has published an opposing viewpoint. That''s fine with me also. We also need to iron out how web publishing is going to work. It would be good if we did that before the 2.4.0 release so that you folks can do your own web publishing to http://shorewall.net and to the mirrors. You will also need to be able to update the ftp download sites. In the absence of any other proposal, I can handle the web publishing issue by setting up a cron job that updates from Sourceforge CVS periodically (Shorewall-Website and Shorewall-docs2) and publishes the changes (I''ve been doing that manually with Cristian''s changes anyway). That won''t work for the download stuff though. -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 -------------- 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/20050602/571f5317/signature.bin
Cristian Rodriguez
2005-Jun-02 16:19 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
2005/6/2, Tom Eastep <teastep@shorewall.net>:> Tom Eastep wrote: > > > > > It would be my recommendation to make 2.4 the new "stable" release but > > continue to support 2.0 and 2.2 until 2.6 comes out. > > I just noticed on Sourceforge that Paul has published an opposing > viewpoint. That''s fine with me also.And fine for me too. but I think your points are very good,and this problem should be discussed.> We also need to iron out how web publishing is going to work. It would > be good if we did that before the 2.4.0 release so that you folks can do > your own web publishing to http://shorewall.net and to the mirrors. You > will also need to be able to update the ftp download sites. > > In the absence of any other proposal, I can handle the web publishing > issue by setting up a cron job that updates from Sourceforge CVS > periodicallyyep, This is a temporal(?) good solution. abou the downloads..maybe will be a good idea to use the sourceforge release system.
Tom Eastep wrote:> ... >>It would be my recommendation to make 2.4 the new "stable" release but >>continue to support 2.0 and 2.2 until 2.6 comes out. > > > I just noticed on Sourceforge that Paul has published an opposing > viewpoint. That''s fine with me also.I published that before you started any discussion. I think given the short lifetime of 2.2, we may need to consider doing it the way you proposed. One question: is 2.4.0 really that different from 2.2.5? (I haven''t done a CVS diff yet.) Should we be calling it 2.2.6 instead? -- 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/20050603/4e8907dc/signature.bin
Paul Gear wrote:> Tom Eastep wrote: >>... >>>It would be my recommendation to make 2.4 the new "stable" release but >>>continue to support 2.0 and 2.2 until 2.6 comes out. >> >>I just noticed on Sourceforge that Paul has published an opposing >>viewpoint. That''s fine with me also. > > I published that before you started any discussion. I think given the > short lifetime of 2.2, we may need to consider doing it the way you > proposed. > > One question: is 2.4.0 really that different from 2.2.5? (I haven''t > done a CVS diff yet.) Should we be calling it 2.2.6 instead? >I''ve considered that Paul. The change to support ipsets is quite invasive. Plus: teastep@tipper:~/Shorewall> diff -au STABLE2/firewall Shorewall2/firewall | wc -l 1753 teastep@tipper:~/Shorewall> Add to that the fact that there are upgrade considerstions and I don''t believe that it is right to call it 2.2.6. -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
Karsten Bräckelmann
2005-Jun-03 09:45 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
On Thu, 2005-06-02 at 07:32 -0700, Tom Eastep wrote:> I believe that 2.4.0 is about ready to be sent out the door. I''ve made a > couple of small changes since RC2 but I don''t believe that they warrant > another RC. > > There remains the issue of what to do about support for Shorewall 2.0 given > that 2.2 has only been available since March. > > It would be my recommendation to make 2.4 the new "stable" release but > continue to support 2.0 and 2.2 until 2.6 comes out. My reasoning is as > follows:I agree -- although I really am not responsible for the major support on the users list. Other projects don''t even have officially unsupported versions on the mailing lists. And I personally always try to help, if I still remember the facts and details of that old version. (If anyone wonders that''s Evolution primarily.) Considering Toms reasoning, we should continue supporting 2.0 -- as all 2.x versions do share the basic code. If no one remembers a particular old version, support will be unavailable evolutionary anyways. ;) Just IMHO, please keep in mind that I don''t solve a lot of support issues... karsten -- Davision - Atelier fuer Gestaltung / Internet / Multimedia UNIX / Linux Netzwerke und Schulungen Telefon 06151/273859 Fax 06151/273862 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050603/bcb3601d/attachment.bin
Cristian Rodriguez
2005-Jun-03 11:13 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
2005/6/2, Tom Eastep <teastep@shorewall.net>:> Paul Gear wrote: > > Tom Eastep wrote: > >>... > >>>It would be my recommendation to make 2.4 the new "stable" release but > >>>continue to support 2.0 and 2.2 until 2.6 comes out. > >> > >>I just noticed on Sourceforge that Paul has published an opposing > >>viewpoint. That''s fine with me also.Tom: I actually suggest an "extended support period" of 3 months, for Shorewall version 2.0.x and a new statement in the website about that. do you like my idea?
Cristian Rodriguez wrote:> ... > Tom: > I actually suggest an "extended support period" of 3 months, for > Shorewall version 2.0.x > and a new statement in the website about that. > > do you like my idea?Yes. :-) -- Paul <http://paulgear.webhop.net> -- Did you know? If you use two dashes followed by a space as your signature separator, good email programs will chop them off automatically, reducing noise in email replies. -------------- 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/20050604/85f13479/signature.bin
Tom Eastep wrote:> ... >>One question: is 2.4.0 really that different from 2.2.5? (I haven''t >>done a CVS diff yet.) Should we be calling it 2.2.6 instead? >> > > > I''ve considered that Paul. > > The change to support ipsets is quite invasive. Plus: > > teastep@tipper:~/Shorewall> diff -au STABLE2/firewall Shorewall2/firewall | > wc -l > 1753 > teastep@tipper:~/Shorewall> > > Add to that the fact that there are upgrade considerstions and I don''t > believe that it is right to call it 2.2.6.I came to the same conclusion after doing ''cvs diff -rShorewall_2_2_1''. :-) -- Paul <http://paulgear.webhop.net> -- Did you know? Many viruses specifically target Microsoft Outlook and Outlook Express. You can help to keep your computer free of viruses by using one of the more secure alternatives from <http://mozilla.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/20050604/4e811a58/signature.bin
Tom Eastep wrote:> I believe that 2.4.0 is about ready to be sent out the door. I''ve made a > couple of small changes since RC2 but I don''t believe that they warrant > another RC.Agreed - they looked pretty simple to me.> There remains the issue of what to do about support for Shorewall 2.0 given > that 2.2 has only been available since March. > > It would be my recommendation to make 2.4 the new "stable" release but > continue to support 2.0 and 2.2 until 2.6 comes out. > ... > The above is only my recommendation and should be taken as such. It is you > folks that are going to have to support Shorewall going forward and this > should be your decision. > > I think that we need to resolve this issue before announcing 2.4.0 to avoid > confusion among the user base.For the reasons you and Karsten listed, i think we should support 2.0 for a time. I would like to see the time limited to 6 months or whenever we release 2.6, whichever is sooner, because we really do not want people still on 2.0 when 2.6 comes out. Perhaps we need to say something like: We believe 2.4.0 is a stable release and should cause no major problems for existing installations. We recommend users of previous stable releases to upgrade as soon as practical. Along with this, we need to make a statement about how we''re going to support 2.2. Will it reach end of life at the same time as 2.2? My gut says it should. One other issue: I''ve looked at the crossbeam stuff in 2.4.0, and i''m really not sure it warrants a separate feature from routestopped. If we''re going to drop it for something more generalised in the near future, i''d rather it didn''t go into a stable release. Juan, what are the actual connectivity requirements of the crossbeam? Could the same rules it uses be provided by the latest changes to routestopped? -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. -------------- 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/20050604/987beaa6/signature.bin
Paul Gear wrote:> > One other issue: I''ve looked at the crossbeam stuff in 2.4.0, and i''m > really not sure it warrants a separate feature from routestopped. If > we''re going to drop it for something more generalised in the near > future, i''d rather it didn''t go into a stable release. > > Juan, what are the actual connectivity requirements of the crossbeam? > Could the same rules it uses be provided by the latest changes to > routestopped?I got the impression (Juan, correct me if I''m wrong) that on the crossbeam interface, "I''m alive" packets are sent and that if even one of those gets dropped, the crossbeam will cause the box to be rebooted. So it is important to sequence the operations during [re]start so that no packets on the crossbeam interface can be dropped. I don''t think that sort of "never drop a packet" is required or appropriate for /etc/shorewall/routestopped in general because it opens up the firewall completely for a small window during [re]start. Adding that sort of logic to /etc/shorewall/routestopped IS possible (new option "crossbeam") but I am personally not up to adding it for 2.4. I think that the current implementation provided by Juan is probably simpler. -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 -------------- 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/20050603/85996926/signature.bin
Tom Eastep wrote:> Paul Gear wrote: > > >>One other issue: I''ve looked at the crossbeam stuff in 2.4.0, and i''m >>really not sure it warrants a separate feature from routestopped. If >>we''re going to drop it for something more generalised in the near >>future, i''d rather it didn''t go into a stable release. >> >>Juan, what are the actual connectivity requirements of the crossbeam? >>Could the same rules it uses be provided by the latest changes to >>routestopped? > > I got the impression (Juan, correct me if I''m wrong) that on the > crossbeam interface, "I''m alive" packets are sent and that if even one > of those gets dropped, the crossbeam will cause the box to be rebooted. > So it is important to sequence the operations during [re]start so that > no packets on the crossbeam interface can be dropped. I don''t think that > sort of "never drop a packet" is required or appropriate for > /etc/shorewall/routestopped in general because it opens up the firewall > completely for a small window during [re]start.What i was thinking is that it seems from my (brief) impressions of the crossbeam that the requirement is really only for connectivity to/from the firewall, not open access in general, and this is almost identical to the requirements for heartbeat. If the routestopped configuration were limited appropriately (e.g. only specific IP addresses or interfaces), then that should be adequate.> Adding that sort of logic to /etc/shorewall/routestopped IS possible > (new option "crossbeam") but I am personally not up to adding it for > 2.4. I think that the current implementation provided by Juan is > probably simpler.I''m happy to do the work to integrate the "right solution" (i.e. my solution ;-) if Juan can provide details. -- Paul <http://paulgear.webhop.net> -- Did you know? Email addresses can be forged easily. This message is signed with GNU Privacy Guard <http://www.gnupg.org> and Enigmail <http://enigmail.mozdev.org> so you can be sure it comes from me. -------------- 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/20050604/b9af1646/signature-0001.bin
Paul Gear wrote:> > > What i was thinking is that it seems from my (brief) impressions of the > crossbeam that the requirement is really only for connectivity to/from > the firewall, not open access in general, and this is almost identical > to the requirements for heartbeat. If the routestopped configuration > were limited appropriately (e.g. only specific IP addresses or > interfaces), then that should be adequate. > >>Adding that sort of logic to /etc/shorewall/routestopped IS possible >>(new option "crossbeam") but I am personally not up to adding it for >>2.4. I think that the current implementation provided by Juan is >>probably simpler. > > I''m happy to do the work to integrate the "right solution" (i.e. my > solution ;-) if Juan can provide details.Ok -- I''ll rip out Juan''s code and you can implement the solution of choice. -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
Cristian Rodriguez wrote:>> >>In the absence of any other proposal, I can handle the web publishing >>issue by setting up a cron job that updates from Sourceforge CVS >>periodically > > yep, This is a temporal(?) good solution."Temporary" maybe? I''ve gone ahead and set that up. It uses anonymous access to the cvs pserver at sourceforge so it is subject to the five hour delay currently inherent in that server. Once the pserver runs off of the "live" CVS repository, that delay will be eliminated.> > abou the downloads..maybe will be a good idea to use the sourceforge > release system. >Unless someone steps forward to create a new primary download site, that would seem to be our only solution. -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 -------------- 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/20050604/e2b2fc13/signature.bin
Hi all, Juan is going to have a pretty busy week so I try to answer it myself.> I got the impression (Juan, correct me if I''m wrong) that on the > crossbeam interface, "I''m alive" packets are sent and that if even one > of those gets dropped, the crossbeam will cause the box to be rebooted.Exactly. I dont know how the signal was sent or received, but when we restarted shorewall the firewall module restarted (hardware) asap.> Adding that sort of logic to /etc/shorewall/routestopped IS possible > (new option "crossbeam") but I am personally not up to adding it for > 2.4. I think that the current implementation provided by Juan is > probably simpler.Actually we try to code this kind of features very simply, and surelly will be other (more powerful) ways of doing the same. In our case, we just try to cover what our client / project needs. Regards. -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Hi,> What i was thinking is that it seems from my (brief) impressions of the > crossbeam that the requirement is really only for connectivity to/from > the firewall, not open access in general, and this is almost identical > to the requirements for heartbeat.I guess so.> If the routestopped configuration > were limited appropriately (e.g. only specific IP addresses or > interfaces), then that should be adequate. > > > Adding that sort of logic to /etc/shorewall/routestopped IS possible > > (new option "crossbeam") but I am personally not up to adding it for > > 2.4. I think that the current implementation provided by Juan is > > probably simpler. > > I''m happy to do the work to integrate the "right solution" (i.e. my > solution ;-) if Juan can provide details.OK, I will try to get Juan in touch with you guys. Currently he is at a clients site all the morning. I guess this afternoon (in Spain ... :) -- Jaime Nebrera - jnebrera@eneotecnologia.com Consultor TI - ENEO Tecnologia SL Telf.- 95 455 40 62 - 619 04 55 18
Jaime Nebrera wrote:> ... >>If the routestopped configuration >>were limited appropriately (e.g. only specific IP addresses or >>interfaces), then that should be adequate. >> >> >>>Adding that sort of logic to /etc/shorewall/routestopped IS possible >>>(new option "crossbeam") but I am personally not up to adding it for >>>2.4. I think that the current implementation provided by Juan is >>>probably simpler. >> >>I''m happy to do the work to integrate the "right solution" (i.e. my >>solution ;-) if Juan can provide details. > > > OK, I will try to get Juan in touch with you guys. Currently he is at > a clients site all the morning. I guess this afternoon (in Spain ... :)Thanks, Jaime. If it''s possible, a tcpdump/ethereal packet log of the normal communication between the crossbeam and the firewall host would also be appreciated. -- Paul <http://paulgear.webhop.net> -- Did you know? OpenOffice.org has built-in PDF creation. Better yet, it''s compatible with Microsoft Office, and free! Find out more at <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/20050606/be103b09/signature.bin
Tom Eastep wrote:> ... > We also need to iron out how web publishing is going to work. It would > be good if we did that before the 2.4.0 release so that you folks can do > your own web publishing to http://shorewall.net and to the mirrors. You > will also need to be able to update the ftp download sites.Sorry we didn''t get much discussion happening on this before you released 2.4.0. Perhaps the simplest thing at the moment would be to change the address of shorewall.net to point to www.shorewall.net, and provide appropriate ssh access for publishing. Then no changes would need to be made to the mirror sites, and everything should just work the same. Alex (Martin), does this sound reasonable to you? I expect one user account for documentation publishing and another for file publishing would be all that''s necessary.> In the absence of any other proposal, I can handle the web publishing > issue by setting up a cron job that updates from Sourceforge CVS > periodically (Shorewall-Website and Shorewall-docs2) and publishes the > changes (I''ve been doing that manually with Cristian''s changes anyway). > That won''t work for the download stuff though.How does your current download system work? What work needs to be done to create a new release besides the actual code? (And on a related note, is there really a need to have the version number of shorewall in every configuration file? It seems like a maintenance overhead to me.) -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead. -------------- 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/20050606/23d11896/signature.bin
Paul Gear wrote:> Tom Eastep wrote: >>... >>We also need to iron out how web publishing is going to work. It would >>be good if we did that before the 2.4.0 release so that you folks can do >>your own web publishing to http://shorewall.net and to the mirrors. You >>will also need to be able to update the ftp download sites. > > Sorry we didn''t get much discussion happening on this before you > released 2.4.0. Perhaps the simplest thing at the moment would be to > change the address of shorewall.net to point to www.shorewall.net, and > provide appropriate ssh access for publishing. Then no changes would > need to be made to the mirror sites, and everything should just work the > same. Alex (Martin), does this sound reasonable to you? I expect one > user account for documentation publishing and another for file > publishing would be all that''s necessary.Then Alex also needs to set up www.shorewall.net as an rsync server and I need to swing DNS for rsync.shorewall.net. Currently, www.shorewall.net is just another mirror of shorewall.net (A.K.A rsync.shorewall.net).> >>In the absence of any other proposal, I can handle the web publishing >>issue by setting up a cron job that updates from Sourceforge CVS >>periodically (Shorewall-Website and Shorewall-docs2) and publishes the >>changes (I''ve been doing that manually with Cristian''s changes anyway). >>That won''t work for the download stuff though. > > How does your current download system work? What work needs to be done > to create a new release besides the actual code?After I run ''makeshorewall <old version> <newversion>'' on one of my desktop/laptop systems, on the server I: mkdir /var/ftp/pub/shorewall/2.x/shorewall-2.x.x mkdir /var/ftp/pub/shorewall/2.x/shorewall-2.x.x/errata echo "There are no known problems in Shorewall 2.x.x" > \ /var/ftp/pub/shorewall/2.x/shorewall-2.x.x/known_problems.txt I then use scp to copy the patch, the release notes and the packages to the new directory (as root -- all of the published files on the server are owned by root and are readable by all users). Then back on the server: cd /var/ftp/pub/shorewall/2.x/shorewall-2.x.x md5sum > 2.x.x-md5sums cd .. ln -s shorewall-2.x.x CURRENT_VERSION_IS_2.x.x rm <old CURRENT_VERSION_... symlink> I then fiddle around for 20 minutes to half an hour using the incredibly cumbersome Sourceforge download system to release there as well. (And on a related> note, is there really a need to have the version number of shorewall in > every configuration file? It seems like a maintenance overhead to me.) >It''s a once-a-year PITA (only the major version is there) and it gives an indication of how out of date the documentation comments might be. -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 -------------- 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/20050606/6ff4eac6/signature.bin
On Mon, 2005-06-06 at 02:52, Paul Gear wrote:> Tom Eastep wrote: > > ... > > We also need to iron out how web publishing is going to work. It would > > be good if we did that before the 2.4.0 release so that you folks can do > > your own web publishing to http://shorewall.net and to the mirrors. You > > will also need to be able to update the ftp download sites. > > Sorry we didn''t get much discussion happening on this before you > released 2.4.0. Perhaps the simplest thing at the moment would be to > change the address of shorewall.net to point to www.shorewall.net, and > provide appropriate ssh access for publishing. Then no changes would > need to be made to the mirror sites, and everything should just work the > same. Alex (Martin), does this sound reasonable to you? I expect one > user account for documentation publishing and another for file > publishing would be all that''s necessary.Paul, SF provides project website VHOST, and project members have shell access to a FC2 system. There is a compile farm too. http://leaf-project.org/ == http://leaf.sourceforge.net/ E07. Project Web, Shell and Database Services (en) https://sourceforge.net/docman/display_doc.php?docid=4297&group_id=1#vhost https://sourceforge.net/docman/display_doc.php?docid=4297&group_id=1#shell E02. Compile Farm (en) https://sourceforge.net/docman/display_doc.php?docid=762&group_id=1> > In the absence of any other proposal, I can handle the web publishing > > issue by setting up a cron job that updates from Sourceforge CVS > > periodically (Shorewall-Website and Shorewall-docs2) and publishes the > > changes (I''ve been doing that manually with Cristian''s changes anyway). > > That won''t work for the download stuff though. > > How does your current download system work? What work needs to be done > to create a new release besides the actual code? (And on a related > note, is there really a need to have the version number of shorewall in > every configuration file? It seems like a maintenance overhead to me.)G4. Guide to the File Release System (FRS) https://sourceforge.net/docman/display_doc.php?docid=6445&group_id=1 -- Mike Noyes <mhnoyes at users.sourceforge.net> http://sourceforge.net/users/mhnoyes/ SF.net Projects: leaf, phpwebsite, phpwebsite-comm, sitedocs
Nerijus Baliunas
2005-Jun-06 08:00 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
On Mon, 06 Jun 2005 07:29:26 -0700 Tom Eastep <teastep@shorewall.net> wrote:> I then fiddle around for 20 minutes to half an hour using the incredibly > cumbersome Sourceforge download system to release there as well.There''a a project to help it - http://releaseforge.sourceforge.net/ ReleaseForge is an open source utility designed for the administrators and release engineers of SourceForge projects. ReleaseForge allows you to easily create new SourceForge project releases and edit existing releases in a quicker and friendlier manner than the usual SourceForge web interface. After using ReleaseForge once, you''ll wonder how you ever could''ve lived without it. Regards, Nerijus
On Monday 06 June 2005 07:56, Nerijus Baliunas wrote:> On Mon, 06 Jun 2005 07:29:26 -0700 Tom Eastep <teastep@shorewall.net> wrote: > > I then fiddle around for 20 minutes to half an hour using the incredibly > > cumbersome Sourceforge download system to release there as well. > > There''a a project to help it - http://releaseforge.sourceforge.net/ > > ReleaseForge is an open source utility designed for the administrators and > release engineers of SourceForge projects. ReleaseForge allows you to > easily create new SourceForge project releases and edit existing releases > in a quicker and friendlier manner than the usual SourceForge web > interface. After using ReleaseForge once, you''ll wonder how you ever > could''ve lived without it.Groan -- I find this AFTER I''ve made my last SourceForge release. Thanks, -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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.shorewall.net/pipermail/shorewall-devel/attachments/20050606/41cd66ab/attachment.bin
Cristian Rodriguez
2005-Jun-06 10:47 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
2005/6/6, Tom Eastep <teastep@shorewall.net>:> On Monday 06 June 2005 07:56, Nerijus Baliunas wrote: > > On Mon, 06 Jun 2005 07:29:26 -0700 Tom Eastep <teastep@shorewall.net> wrote: > > > I then fiddle around for 20 minutes to half an hour using the incredibly > > > cumbersome Sourceforge download system to release there as well. > > > > There''a a project to help it - http://releaseforge.sourceforge.net/ > > > > ReleaseForge is an open source utility designed for the administrators and > > release engineers of SourceForge projects. ReleaseForge allows you to > > easily create new SourceForge project releases and edit existing releases > > in a quicker and friendlier manner than the usual SourceForge web > > interface. After using ReleaseForge once, you''ll wonder how you ever > > could''ve lived without it. >nice to know this.:-) ps: on SUSE PyQt comes in the kdebindings3-python package.
Juan J. Prieto
2005-Jun-10 02:34 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
hi all, sorry for the delay...> I got the impression (Juan, correct me if I''m wrong) that on the > crossbeam interface, "I''m alive" packets are sent and that if even one > of those gets dropped, the crossbeam will cause the box to be rebooted. > So it is important to sequence the operations during [re]start so that > no packets on the crossbeam interface can be dropped. I don''t think thatYes, this is the way it works. The crossbeam machine is very configurable and you can make all the virtuals network interfaces that you need (eth0 in not necessarily a real network interface, and you can create it with the name tha you want). normally the crossbeam use a backplain to interconnect the APMs and CPMs, and the O.S. installed on any APM normally mount his HDs via network (NFS, ...) using the backplain. It is common to apply ACCEPT in INPUT and OUTPUT and ACCEPT in FORWARD for packets arriving and leaving the network interface attached to the backplain because the CPM is very ''sensitive''. But you can make all the rules and policies that you want for this interface (including DROP in general).> sort of "never drop a packet" is required or appropriate for > /etc/shorewall/routestopped in general because it opens up the firewall > completely for a small window during [re]start. > > Adding that sort of logic to /etc/shorewall/routestopped IS possible > (new option "crossbeam") but I am personally not up to adding it for > 2.4. I think that the current implementation provided by Juan is > probably simpler.Yes, i guess so. Crossbeam only need to permit tracking connection control first and then add the DROP policy second, not the other way round.> -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-- Juan Jes?s Prieto - Consultor?a TI jjprieto@eneotecnologia.com http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5
Juan J. Prieto
2005-Jun-10 02:54 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
Hi Paul, sorry for the delay, El lun, 06-06-2005 a las 19:49 +1000, Paul Gear escribi?:> Jaime Nebrera wrote: > > ... > >>If the routestopped configuration > >>were limited appropriately (e.g. only specific IP addresses or > >>interfaces), then that should be adequate. > >> > >> > >>>Adding that sort of logic to /etc/shorewall/routestopped IS possible > >>>(new option "crossbeam") but I am personally not up to adding it for > >>>2.4. I think that the current implementation provided by Juan is > >>>probably simpler. > >> > >>I''m happy to do the work to integrate the "right solution" (i.e. my > >>solution ;-) if Juan can provide details.I think "CROSSBEAM" feature should go on in the configuration file (shorewall.conf), but if you can implement "CROSSBEAM_BACKBONE" in the routestopped then it will be a perfect solution. The problem in crossbeam is at the moment when shorewall set POLICY to DROP and then apply continuity on the connections. With my patch, first set ACCEPT, then continuity and then DROP in the INPUT, OUTPUT and FORWARD chains. Regards. -- Juan Jes?s Prieto - Consultor?a TI jjprieto@eneotecnologia.com http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5
Juan J. Prieto wrote:> > I think "CROSSBEAM" feature should go on in the configuration file > (shorewall.conf), but if you can implement "CROSSBEAM_BACKBONE" in the > routestopped then it will be a perfect solution. The problem in > crossbeam is at the moment when shorewall set POLICY to DROP and then > apply continuity on the connections. With my patch, first set ACCEPT, > then continuity and then DROP in the INPUT, OUTPUT and FORWARD chains.In my private CVS repository (http://cvs.shorewall.net/cgi-bin/cvs/cvsweb.cgi/), I have code that implements an /etc/shorewall/criticalhosts file. The idea is that communication with hosts listed in this file cannot be interrupted even momentarily. Besides Crossbeam, this feature is useful for allowing an NFS-mounted root file system on a diskless firewall (something I''m considering building). -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 -------------- 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/20050610/888ca8b9/signature.bin
Juan J. Prieto
2005-Jun-10 07:40 UTC
[Shorewall-devel] One Remaining Issue Regarding 2.4.0
Hi Tom, El vie, 10-06-2005 a las 06:51 -0700, Tom Eastep escribi?:> In my private CVS repository > (http://cvs.shorewall.net/cgi-bin/cvs/cvsweb.cgi/), I have code that > implements an /etc/shorewall/criticalhosts file. The idea is that > communication with hosts listed in this file cannot be interrupted even > momentarily. Besides Crossbeam, this feature is useful for allowing an > NFS-mounted root file system on a diskless firewall (something I''m > considering building).Yes, it looks the correct way for crossbeam and other systems like crossbeam. In a few days we will have the opportunity to test it over a new crossbeam client. Regards. -- Juan Jes?s Prieto - Consultor?a TI jjprieto@eneotecnologia.com http://www.eneotecnologia.com --------------------------------------- fingerprint: BFC2 0370 7708 F800 0BEC 60A4 EC71 4BB1 CC85 99F5 http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xCC8599F5
Hi Juan, Juan J. Prieto wrote:> Hi Tom, > > El vie, 10-06-2005 a las 06:51 -0700, Tom Eastep escribi?: >>In my private CVS repository >>(http://cvs.shorewall.net/cgi-bin/cvs/cvsweb.cgi/), I have code that >>implements an /etc/shorewall/criticalhosts file. The idea is that >>communication with hosts listed in this file cannot be interrupted even >>momentarily. Besides Crossbeam, this feature is useful for allowing an >>NFS-mounted root file system on a diskless firewall (something I''m >>considering building). > > Yes, it looks the correct way for crossbeam and other systems like > crossbeam. In a few days we will have the opportunity to test it over a > new crossbeam client. >I think that a separate file is an overkill, though -- the lastest code in my CVS replaces /etc/shorewall/criticalhosts with a CRITICALHOSTS option in shorewall.conf. Feel free to run with whichever implementation you are most confortable with. When you have tested, please go ahead and submit the tested patch to the list. I''ll bow out of this discussion now. -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 -------------- 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/20050610/a2db0ed5/signature.bin
Tom Eastep wrote:> > I''ll bow out of this discussion now. >After one more warning about my CVS tree (which I will repeat once the list is up at Sourceforge). My tree contains patches that may not be suitable for general consumption: a) I''ve removed the DISPLAY and COMMENTS columns from the zones file. b) I''ve removed the "monitor" command from /sbin/shorewall (it hasn''t been maintained for some time). c) I''ve made error and warning messages more emphatic. The modified files are: /etc/shorewall/shorewall.conf /usr/share/shorewall/firewall /sbin/shorewall /usr/share/shorewall/functions /etc/shorewall/zones /usr/share/shorewall/help -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 -------------- 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/20050610/8417b5d2/signature.bin