You can subscribe to this list here.
2002 |
Jan
(16) |
Feb
(1) |
Mar
(4) |
Apr
(13) |
May
(33) |
Jun
(34) |
Jul
(9) |
Aug
(4) |
Sep
(7) |
Oct
(14) |
Nov
(9) |
Dec
(28) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(39) |
Feb
(11) |
Mar
(32) |
Apr
|
May
(13) |
Jun
(1) |
Jul
(24) |
Aug
(30) |
Sep
|
Oct
(19) |
Nov
(3) |
Dec
(165) |
2004 |
Jan
(75) |
Feb
(31) |
Mar
(24) |
Apr
(29) |
May
(16) |
Jun
(10) |
Jul
(26) |
Aug
(27) |
Sep
(22) |
Oct
(24) |
Nov
(15) |
Dec
(4) |
2005 |
Jan
(30) |
Feb
(4) |
Mar
(5) |
Apr
(26) |
May
(260) |
Jun
(65) |
Jul
(130) |
Aug
(70) |
Sep
(91) |
Oct
(51) |
Nov
(34) |
Dec
(17) |
2006 |
Jan
(42) |
Feb
(63) |
Mar
(11) |
Apr
(13) |
May
(4) |
Jun
(14) |
Jul
(8) |
Aug
(25) |
Sep
(19) |
Oct
(17) |
Nov
(32) |
Dec
(18) |
2007 |
Jan
(42) |
Feb
(25) |
Mar
(23) |
Apr
(32) |
May
(259) |
Jun
(125) |
Jul
(39) |
Aug
(12) |
Sep
(29) |
Oct
(111) |
Nov
(32) |
Dec
(79) |
2008 |
Jan
(41) |
Feb
(21) |
Mar
(45) |
Apr
(28) |
May
(13) |
Jun
(9) |
Jul
(11) |
Aug
(2) |
Sep
(3) |
Oct
(6) |
Nov
(19) |
Dec
(47) |
2009 |
Jan
(8) |
Feb
(20) |
Mar
(6) |
Apr
(37) |
May
(7) |
Jun
(37) |
Jul
(2) |
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
(14) |
2010 |
Jan
(25) |
Feb
(10) |
Mar
(7) |
Apr
(4) |
May
(10) |
Jun
(10) |
Jul
(36) |
Aug
(40) |
Sep
(125) |
Oct
(10) |
Nov
(18) |
Dec
(74) |
2011 |
Jan
(43) |
Feb
(122) |
Mar
(50) |
Apr
(34) |
May
(123) |
Jun
(47) |
Jul
(126) |
Aug
(80) |
Sep
(83) |
Oct
(43) |
Nov
(33) |
Dec
(64) |
2012 |
Jan
(13) |
Feb
(34) |
Mar
(93) |
Apr
(51) |
May
(24) |
Jun
(23) |
Jul
(25) |
Aug
(8) |
Sep
(119) |
Oct
(22) |
Nov
(129) |
Dec
(85) |
2013 |
Jan
(123) |
Feb
(172) |
Mar
(127) |
Apr
(229) |
May
(145) |
Jun
(48) |
Jul
(22) |
Aug
(32) |
Sep
(55) |
Oct
(13) |
Nov
(13) |
Dec
(5) |
2014 |
Jan
(10) |
Feb
(15) |
Mar
(7) |
Apr
(2) |
May
(5) |
Jun
(8) |
Jul
(7) |
Aug
(20) |
Sep
(23) |
Oct
(29) |
Nov
(48) |
Dec
(14) |
2015 |
Jan
(22) |
Feb
(2) |
Mar
(11) |
Apr
(16) |
May
(20) |
Jun
(11) |
Jul
(10) |
Aug
(8) |
Sep
(3) |
Oct
(4) |
Nov
(23) |
Dec
(8) |
2016 |
Jan
(6) |
Feb
(14) |
Mar
(14) |
Apr
(43) |
May
(18) |
Jun
(14) |
Jul
(2) |
Aug
(3) |
Sep
(3) |
Oct
(51) |
Nov
(35) |
Dec
(25) |
2017 |
Jan
(8) |
Feb
(46) |
Mar
(26) |
Apr
(10) |
May
(5) |
Jun
(4) |
Jul
(7) |
Aug
(28) |
Sep
(13) |
Oct
(15) |
Nov
(6) |
Dec
(10) |
2018 |
Jan
(21) |
Feb
(5) |
Mar
(34) |
Apr
(18) |
May
(91) |
Jun
(5) |
Jul
(14) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(8) |
Dec
(6) |
2019 |
Jan
(20) |
Feb
(10) |
Mar
(2) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(5) |
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(5) |
May
|
Jun
(5) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(20) |
Nov
(3) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Matt D. <ma...@sh...> - 2021-06-03 09:54:00
|
Shorewall Community, Following the Freenode hostile takeover, the Shorewall Project Committee has decided to move to Libera.Chat. Starting now, support will no longer be offered on Freenode. You can find us on Libera.Chat at '#shorewall'. -- Matt Darfeuille <ma...@sh...> Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/ SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/ Homepage: https://shorewall.org |
From: Matt D. <ma...@sh...> - 2021-04-06 08:08:45
|
Bottom posting. On 4/6/2021 5:47 AM, Thom M Eastep wrote: > I can come out of retirement enough to fix the issues in upstream... It sure would be great if we could get the final stable Shorewall packages into Debian. > > On March 30, 2021, at 7:09 AM, "Roberto C. Sanchez" <ro...@co...> wrote: > > Package: wnpp > Severity: normal > > I request assistance with maintaining the shorewall package. > The below is one fragile temporary solution for quickly addressing bugs and getting out 5.2.8: 1) Make building of *.deb pkgs possible locally 2) Address bugs 3) Let Roberto do the final build and upload the pkgs At the time I looked at reworking the pkgs, I was not able to find a way to programatically change the maintainer name and other information. So assuming that the bugs are worked out and the fixes are committed in the Debian repo, Roberto would simply have to use 'pkg.py' to do 5.2.8. -- Matt Darfeuille <ma...@sh...> Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/ SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/ Homepage: https://shorewall.org |
From: Thom M E. <te...@sh...> - 2021-04-06 04:15:14
|
I can come out of retirement enough to fix the issues in upstream... It sure would be great if we could get the final stable Shorewall packages into Debian. Tom On March 30, 2021, at 7:09 AM, "Roberto C. Sanchez" <ro...@co...> wrote: Package: wnpp Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I request assistance with maintaining the shorewall package. The package description is: Shorewall allows firewall/gateway requirements to be described using entries in a set of configuration files. It reads those configuration files and, with the help of the iptables utility, configures netfilter to match these requirements. . Shorewall supports a wide range of router/firewall/gateway applications, traffic shaping and almost every type of VPN. I have maintained the Shorewall packages in Debian for quite a few years now, but my time to work on them has diminished. The reality is that there are several issues that require attention, which I cannot at the moment attend to. Over time the severity of these issues will likely increase and the eventual result is that the Shorewall packages could be removed from Debian. If someone were to be able to devote some effort toward helping, I could help with reviewing patches, sponsoring uploads, etc. It is still my hope that I will find additional time to work on the Shorewall Debian packages, but I do not want to make my inability to find enough time now cause users of Debian to lose out on access to good quality Shorewall packages. Note that this RFH really encompasses the shorewall, shorewall6, shorewall-lite, shorewall6-lite, shorewall-doc, and shorewall-core source packages. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmBjLvUACgkQldFmTdL1 kUI9pA/9FqVYHab6iWdVfUpMm8hzCDYLEs1SRk3cIDWyMWWkGS5Me/gXKi0tok+0 EIN/I6jjaTctM/atDFuq3u8c8exdqrCszeIrrjjPiS1uKhUwYPc0N+obu5RHohOt ns2F2vhg9C/pSMH1J4g1JWwQA5sqjxXWoP4WxhS8H5JdcxBI48pPETFuG4dsJQQx SiwmA53PqrBao8c1p3c0Z+efDhIZgUp5GRANS9lbzCtNsj0s7zH/tHqsjtP82Jy+ IKJccPv5u1X/ChRf6AITD7fI9Xsn3qcxikfZgD5O0Yd9/AGJtbsR590yw4jZHFYZ qIYFEOGJslYOXx4brAq5Cweevw9VzvIyjPeBjtKoOGYbSadH7+A357UIOqBUWvji ZEaMVeO2V0s29+2RYE4A1bvbqOSkuuDQ6WG9z1z8qE2UhN4G65sljw6tYPtDOGZ3 N2jkBHo1N+9+OuC2rjKkuCfF1yfgVNbvlSUjMidNnjWRiW+PA6o7cVK8c8fuYQK3 ML/Pvib2LvEoyeetTPWijcnePr/Wrw5U0OeRxCNAXxfFBw4/JSyqudF/wiuvEfUV hqEjttomIEkcSF8bf81DvQoxzjBnnQjrFS566esUR71VAjGuqEk4WVaL0ENhPNxL Fjkjt5xIckCJIdvmCDPaRz66MrSPMGY+JX3eBjvGp33wgKJLVsY= =apRC -----END PGP SIGNATURE----- _______________________________________________ Shorewall-devel mailing list Sho...@li... https://lists.sourceforge.net/lists/listinfo/shorewall-devel |
From: Roberto C. S. <ro...@co...> - 2021-03-30 14:09:28
|
Package: wnpp Severity: normal -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I request assistance with maintaining the shorewall package. The package description is: Shorewall allows firewall/gateway requirements to be described using entries in a set of configuration files. It reads those configuration files and, with the help of the iptables utility, configures netfilter to match these requirements. . Shorewall supports a wide range of router/firewall/gateway applications, traffic shaping and almost every type of VPN. I have maintained the Shorewall packages in Debian for quite a few years now, but my time to work on them has diminished. The reality is that there are several issues that require attention, which I cannot at the moment attend to. Over time the severity of these issues will likely increase and the eventual result is that the Shorewall packages could be removed from Debian. If someone were to be able to devote some effort toward helping, I could help with reviewing patches, sponsoring uploads, etc. It is still my hope that I will find additional time to work on the Shorewall Debian packages, but I do not want to make my inability to find enough time now cause users of Debian to lose out on access to good quality Shorewall packages. Note that this RFH really encompasses the shorewall, shorewall6, shorewall-lite, shorewall6-lite, shorewall-doc, and shorewall-core source packages. -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEIYZ1DR4ae5UL01q7ldFmTdL1kUIFAmBjLvUACgkQldFmTdL1 kUI9pA/9FqVYHab6iWdVfUpMm8hzCDYLEs1SRk3cIDWyMWWkGS5Me/gXKi0tok+0 EIN/I6jjaTctM/atDFuq3u8c8exdqrCszeIrrjjPiS1uKhUwYPc0N+obu5RHohOt ns2F2vhg9C/pSMH1J4g1JWwQA5sqjxXWoP4WxhS8H5JdcxBI48pPETFuG4dsJQQx SiwmA53PqrBao8c1p3c0Z+efDhIZgUp5GRANS9lbzCtNsj0s7zH/tHqsjtP82Jy+ IKJccPv5u1X/ChRf6AITD7fI9Xsn3qcxikfZgD5O0Yd9/AGJtbsR590yw4jZHFYZ qIYFEOGJslYOXx4brAq5Cweevw9VzvIyjPeBjtKoOGYbSadH7+A357UIOqBUWvji ZEaMVeO2V0s29+2RYE4A1bvbqOSkuuDQ6WG9z1z8qE2UhN4G65sljw6tYPtDOGZ3 N2jkBHo1N+9+OuC2rjKkuCfF1yfgVNbvlSUjMidNnjWRiW+PA6o7cVK8c8fuYQK3 ML/Pvib2LvEoyeetTPWijcnePr/Wrw5U0OeRxCNAXxfFBw4/JSyqudF/wiuvEfUV hqEjttomIEkcSF8bf81DvQoxzjBnnQjrFS566esUR71VAjGuqEk4WVaL0ENhPNxL Fjkjt5xIckCJIdvmCDPaRz66MrSPMGY+JX3eBjvGp33wgKJLVsY= =apRC -----END PGP SIGNATURE----- |
From: Tom E. <te...@sh...> - 2020-11-03 18:53:15
|
On 11/3/20 10:51 AM, Tom Eastep wrote: > On 11/1/20 11:10 PM, Simon Matter wrote: > >> >> Why not remove the option completely? Since StandardOutput=journal is >> usually the default anyway, why not get rid of it here? >> > > Even better idea. > Thanks, _Simon_ :-) -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Tom E. <te...@sh...> - 2020-11-03 18:51:24
|
On 11/1/20 11:10 PM, Simon Matter wrote: > > Why not remove the option completely? Since StandardOutput=journal is > usually the default anyway, why not get rid of it here? > Even better idea. Thanks, Matt -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Simon M. <sim...@in...> - 2020-11-02 07:11:30
|
> On 10/30/20 4:10 AM, Aurélien Oudelet wrote: >> Hi, >> >> Since systemd 246 release, each time shorewall (and shorewall6) is >> started at >> boot, systemd complains about an obsolete option. >> In facts, upstream systemd has deprecated diverting standard output to >> syslog. >> >> >> Here is output: >> ----------------------------------------------------------------------------- >> systemd[1]: /usr/lib/systemd/system/shorewall6.service:17: Standard >> output >> type syslog is obsolete, automatically updating to journal. Please >> update your >> unit file, and consider removing the setting altogether. >> systemd[1]: /usr/lib/systemd/system/shorewall.service:16: Standard >> output type >> syslog is obsolete, automatically updating to journal. Please update >> your unit >> file, and consider removing the setting altogether. >> ----------------------------------------------------------------------------- >> It seems that under [Service]: >> >> s/StandardOutput=syslog/StandardOutput=journal/ >> >> Us at Mageia, we can change this for our distribution, but this must be >> upstreamed. >> >> Joined modified shorewall{6}.service >> > > Upstream has been updated, including shorewall-lite.service, > shorewall6-lite.service and shorewall-init.service. Why not remove the option completely? Since StandardOutput=journal is usually the default anyway, why not get rid of it here? Regards, Simon |
From: Tom E. <te...@sh...> - 2020-10-30 16:32:34
|
On 10/30/20 4:10 AM, Aurélien Oudelet wrote: > Hi, > > Since systemd 246 release, each time shorewall (and shorewall6) is started at > boot, systemd complains about an obsolete option. > In facts, upstream systemd has deprecated diverting standard output to syslog. > > > Here is output: > ----------------------------------------------------------------------------- > systemd[1]: /usr/lib/systemd/system/shorewall6.service:17: Standard output > type syslog is obsolete, automatically updating to journal. Please update your > unit file, and consider removing the setting altogether. > systemd[1]: /usr/lib/systemd/system/shorewall.service:16: Standard output type > syslog is obsolete, automatically updating to journal. Please update your unit > file, and consider removing the setting altogether. > ----------------------------------------------------------------------------- > It seems that under [Service]: > > s/StandardOutput=syslog/StandardOutput=journal/ > > Us at Mageia, we can change this for our distribution, but this must be > upstreamed. > > Joined modified shorewall{6}.service > Upstream has been updated, including shorewall-lite.service, shorewall6-lite.service and shorewall-init.service. Thanks Aurélien, -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Aurélien O. <oua...@gm...> - 2020-10-30 11:10:47
|
Hi, Since systemd 246 release, each time shorewall (and shorewall6) is started at boot, systemd complains about an obsolete option. In facts, upstream systemd has deprecated diverting standard output to syslog. Here is output: ----------------------------------------------------------------------------- systemd[1]: /usr/lib/systemd/system/shorewall6.service:17: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. systemd[1]: /usr/lib/systemd/system/shorewall.service:16: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. ----------------------------------------------------------------------------- It seems that under [Service]: s/StandardOutput=syslog/StandardOutput=journal/ Us at Mageia, we can change this for our distribution, but this must be upstreamed. Joined modified shorewall{6}.service Best regards, Aurélien Oudelet Mageia Bugsquad and QA Team. |
From: Aurélien O. <oua...@gm...> - 2020-10-30 11:09:07
|
Hi, Since systemd 246 release, each time shorewall (and shorewall6) is started at boot, systemd complains about an obsolete option. In facts, upstream systemd has deprecated diverting standard output to syslog. Here is output: ----------------------------------------------------------------------------- systemd[1]: /usr/lib/systemd/system/shorewall6.service:17: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. systemd[1]: /usr/lib/systemd/system/shorewall.service:16: Standard output type syslog is obsolete, automatically updating to journal. Please update your unit file, and consider removing the setting altogether. ----------------------------------------------------------------------------- It seems that under [Service]: s/StandardOutput=syslog/StandardOutput=journal/ Us at Mageia, we can change this for our distribution, but this must be upstreamed. Joined modified shorewall{6}.service Best regards, Aurélien Oudelet Mageia Bugsquad and QA Team. |
From: Tom E. <te...@sh...> - 2020-10-09 16:28:21
|
On 10/8/20 11:13 PM, Simon Matter wrote: >> On 10/8/2020 7:12 PM, Simon Matter wrote: >>>> On 10/8/20 3:19 AM, Simon Matter wrote: >>>>> Hi, >>>>> >>>>> It happened recently to me when moving a firewall to a new location... >>>>> >>>>> Before moving I adapted VLAN config and Shorewall configuration. The >>>>> TC >>>>> config was blindly modified by me to use 'gbit' units. >>>>> >>>>> In the new location nothing seemed to work - you can think of headless >>>>> firewall and headless admin - and I had a hard time to find out that >>>>> changing the TC config from 'mbit' to 'gbit' didn't work. :( >>>>> >>>>> Attached patch against 5.2.8 is my proposal to add support for >>>>> g,gb,gbit >>>>> and gbps. >>>>> >>>>> From what I saw on my systems is that not all 'tc' versions support >>>>> 'gbit' >>>>> but AFAIK Shorewall always converts the units to 'kbit' for >>>>> compatibility. >>>>> >>>>> Am I right assuming so? >>>>> >>>>> As always, feedback an testing is appreciated. >>>>> >>>> >>>> Thanks, Simon. >>>> >>>> Note that in the Shorewall/code git repository >>>> (https://gitlab.com/shorewall/code), there are no .annotabed sample >>>> files. Those files are created during the build process by combining >>>> each plain config file with its associated manpage. >>>> >>>> Also, the manpages are generated from .xml files; so when modifying a >>>> manpage, the patch must be against the XML file and not the resulting >>>> manpage. >>>> >>>> So you only need to provide patches for Tc.pm, tcinterfaces.xml, >>>> tcdevices.xml and tcclasses.xml. >>> >>> Thanks Tom, now that you say it I remember there were XLM doc files :-) >>> >>> I'll redo the patch tomorrow. >>> >> >> The clone command for the code repository is at (1). >> >> Sending the patches formatted with 'git format-patch' is best but 'git >> diff' will also do it! :) > > Since I'm not really a developer and never used git please allow me to > send a pure diff against master. > > @Tom, hope I got it right with the XLM files this time. > Looks good, Thanks, Simon! -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Simon M. <sim...@in...> - 2020-10-09 06:13:59
|
> On 10/8/2020 7:12 PM, Simon Matter wrote: >>> On 10/8/20 3:19 AM, Simon Matter wrote: >>>> Hi, >>>> >>>> It happened recently to me when moving a firewall to a new location... >>>> >>>> Before moving I adapted VLAN config and Shorewall configuration. The >>>> TC >>>> config was blindly modified by me to use 'gbit' units. >>>> >>>> In the new location nothing seemed to work - you can think of headless >>>> firewall and headless admin - and I had a hard time to find out that >>>> changing the TC config from 'mbit' to 'gbit' didn't work. :( >>>> >>>> Attached patch against 5.2.8 is my proposal to add support for >>>> g,gb,gbit >>>> and gbps. >>>> >>>> From what I saw on my systems is that not all 'tc' versions support >>>> 'gbit' >>>> but AFAIK Shorewall always converts the units to 'kbit' for >>>> compatibility. >>>> >>>> Am I right assuming so? >>>> >>>> As always, feedback an testing is appreciated. >>>> >>> >>> Thanks, Simon. >>> >>> Note that in the Shorewall/code git repository >>> (https://gitlab.com/shorewall/code), there are no .annotabed sample >>> files. Those files are created during the build process by combining >>> each plain config file with its associated manpage. >>> >>> Also, the manpages are generated from .xml files; so when modifying a >>> manpage, the patch must be against the XML file and not the resulting >>> manpage. >>> >>> So you only need to provide patches for Tc.pm, tcinterfaces.xml, >>> tcdevices.xml and tcclasses.xml. >> >> Thanks Tom, now that you say it I remember there were XLM doc files :-) >> >> I'll redo the patch tomorrow. >> > > The clone command for the code repository is at (1). > > Sending the patches formatted with 'git format-patch' is best but 'git > diff' will also do it! :) Since I'm not really a developer and never used git please allow me to send a pure diff against master. @Tom, hope I got it right with the XLM files this time. Regards, Simon |
From: Matt D. <ma...@sh...> - 2020-10-08 17:29:16
|
On 10/8/2020 7:12 PM, Simon Matter wrote: >> On 10/8/20 3:19 AM, Simon Matter wrote: >>> Hi, >>> >>> It happened recently to me when moving a firewall to a new location... >>> >>> Before moving I adapted VLAN config and Shorewall configuration. The TC >>> config was blindly modified by me to use 'gbit' units. >>> >>> In the new location nothing seemed to work - you can think of headless >>> firewall and headless admin - and I had a hard time to find out that >>> changing the TC config from 'mbit' to 'gbit' didn't work. :( >>> >>> Attached patch against 5.2.8 is my proposal to add support for g,gb,gbit >>> and gbps. >>> >>> From what I saw on my systems is that not all 'tc' versions support >>> 'gbit' >>> but AFAIK Shorewall always converts the units to 'kbit' for >>> compatibility. >>> >>> Am I right assuming so? >>> >>> As always, feedback an testing is appreciated. >>> >> >> Thanks, Simon. >> >> Note that in the Shorewall/code git repository >> (https://gitlab.com/shorewall/code), there are no .annotabed sample >> files. Those files are created during the build process by combining >> each plain config file with its associated manpage. >> >> Also, the manpages are generated from .xml files; so when modifying a >> manpage, the patch must be against the XML file and not the resulting >> manpage. >> >> So you only need to provide patches for Tc.pm, tcinterfaces.xml, >> tcdevices.xml and tcclasses.xml. > > Thanks Tom, now that you say it I remember there were XLM doc files :-) > > I'll redo the patch tomorrow. > The clone command for the code repository is at (1). Sending the patches formatted with 'git format-patch' is best but 'git diff' will also do it! :) 1) https://shorewall.org/Development.html -- Matt Darfeuille <ma...@sh...> Community: https://sourceforge.net/p/shorewall/mailman/message/37107049/ SPC: https://sourceforge.net/p/shorewall/mailman/message/36596609/ Homepage: https://shorewall.org |
From: Simon M. <sim...@in...> - 2020-10-08 17:13:19
|
> On 10/8/20 3:19 AM, Simon Matter wrote: >> Hi, >> >> It happened recently to me when moving a firewall to a new location... >> >> Before moving I adapted VLAN config and Shorewall configuration. The TC >> config was blindly modified by me to use 'gbit' units. >> >> In the new location nothing seemed to work - you can think of headless >> firewall and headless admin - and I had a hard time to find out that >> changing the TC config from 'mbit' to 'gbit' didn't work. :( >> >> Attached patch against 5.2.8 is my proposal to add support for g,gb,gbit >> and gbps. >> >> From what I saw on my systems is that not all 'tc' versions support >> 'gbit' >> but AFAIK Shorewall always converts the units to 'kbit' for >> compatibility. >> >> Am I right assuming so? >> >> As always, feedback an testing is appreciated. >> > > Thanks, Simon. > > Note that in the Shorewall/code git repository > (https://gitlab.com/shorewall/code), there are no .annotabed sample > files. Those files are created during the build process by combining > each plain config file with its associated manpage. > > Also, the manpages are generated from .xml files; so when modifying a > manpage, the patch must be against the XML file and not the resulting > manpage. > > So you only need to provide patches for Tc.pm, tcinterfaces.xml, > tcdevices.xml and tcclasses.xml. Thanks Tom, now that you say it I remember there were XLM doc files :-) I'll redo the patch tomorrow. Regards, Simon |
From: Tom E. <te...@sh...> - 2020-10-08 16:59:56
|
On 10/8/20 1:12 AM, Bruno Friedmann wrote: > > Also you have to think of all usage people can deploy shorewall. > The most tricky one is what your package will have to do if the admin has a > local shorewall primary build system with a distributed shorewall-lite devices > in the network ;-) > > Not all will have put their configuration away of the traditional directory > layout. > The AUTOMAKE setting is ignored by the remote-* commands. Those commands unconditionally compile before copying the firewall and firewall.conf files to the remote system. So the issue at hand doesn't apply to distributed shorewall-lite installations. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Tom E. <te...@sh...> - 2020-10-08 16:16:46
|
On 10/8/20 3:19 AM, Simon Matter wrote: > Hi, > > It happened recently to me when moving a firewall to a new location... > > Before moving I adapted VLAN config and Shorewall configuration. The TC > config was blindly modified by me to use 'gbit' units. > > In the new location nothing seemed to work - you can think of headless > firewall and headless admin - and I had a hard time to find out that > changing the TC config from 'mbit' to 'gbit' didn't work. :( > > Attached patch against 5.2.8 is my proposal to add support for g,gb,gbit > and gbps. > > From what I saw on my systems is that not all 'tc' versions support 'gbit' > but AFAIK Shorewall always converts the units to 'kbit' for compatibility. > > Am I right assuming so? > > As always, feedback an testing is appreciated. > Thanks, Simon. Note that in the Shorewall/code git repository (https://gitlab.com/shorewall/code), there are no .annotabed sample files. Those files are created during the build process by combining each plain config file with its associated manpage. Also, the manpages are generated from .xml files; so when modifying a manpage, the patch must be against the XML file and not the resulting manpage. So you only need to provide patches for Tc.pm, tcinterfaces.xml, tcdevices.xml and tcclasses.xml. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Simon M. <sim...@in...> - 2020-10-08 10:19:37
|
Hi, It happened recently to me when moving a firewall to a new location... Before moving I adapted VLAN config and Shorewall configuration. The TC config was blindly modified by me to use 'gbit' units. In the new location nothing seemed to work - you can think of headless firewall and headless admin - and I had a hard time to find out that changing the TC config from 'mbit' to 'gbit' didn't work. :( Attached patch against 5.2.8 is my proposal to add support for g,gb,gbit and gbps. >From what I saw on my systems is that not all 'tc' versions support 'gbit' but AFAIK Shorewall always converts the units to 'kbit' for compatibility. Am I right assuming so? As always, feedback an testing is appreciated. Thanks, Simon |
From: Bruno F. <br...@io...> - 2020-10-08 08:13:25
|
On jeudi, 8 octobre 2020 09.19:06 h CEST Simon Matter wrote: > > On mercredi, 7 octobre 2020 18.26:36 h CEST Matt Darfeuille wrote: > >> Following Tom's advice, moving this (entire thread (1)) to the devel > >> list. > >> > >> Any thoughts on the below (the patch in question (2) is reattached > >> here)? > >> > >> 1) > >> https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/d83aa9 > >> a26 > >> 26c6459f58f671af768b570.squirrel%40webmail.bi.corp.invoca.ch/#msg3712174 > >> 3 2) > >> > >> Release repository, master branch, patch file: > >> release-master-1-20.10.07.17.04.57-rfc.patch > >> > >> -------- Forwarded Message -------- > >> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? > >> Date: Wed, 7 Oct 2020 08:49:47 -0700 > >> From: Tom Eastep <te...@sh...> > >> Reply-To: Shorewall Users <sho...@li...> > >> To: sho...@li... > > > > Moving files in a pre/post section is normally creating orphan files, > > which > > afterward belong to no packages, which is not what we have as rules at > > least > > on openSUSE. > > Well, in most shorewall packages I've seen they don't control anything in > /var/lib/shorewall so moving files there doesn't make anything worse. > > The only way to handle it would be to define %ghost files in the RPM and > I've never tried that because the files in /var/lib/shorewall changed > between releases and it's too much work to find them out. > Also you have to think of all usage people can deploy shorewall. The most tricky one is what your package will have to do if the admin has a local shorewall primary build system with a distributed shorewall-lite devices in the network ;-) Not all will have put their configuration away of the traditional directory layout. > > I agree with Simon point of view. Upgrade the system, but no automatic > > upgrade, as you can too easily lockup everyone out if a problem occur. > > Better save than sorry, yes :-) > > Regards, > Simon > -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch GPG KEY : D5C9B751C4653227 irc: tigerfoot |
From: Simon M. <sim...@in...> - 2020-10-08 07:19:31
|
> On mercredi, 7 octobre 2020 18.26:36 h CEST Matt Darfeuille wrote: >> Following Tom's advice, moving this (entire thread (1)) to the devel >> list. >> >> Any thoughts on the below (the patch in question (2) is reattached >> here)? >> >> 1) >> https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/d83aa9a26 >> 26c6459f58f671af768b570.squirrel%40webmail.bi.corp.invoca.ch/#msg37121743 >> 2) >> Release repository, master branch, patch file: >> release-master-1-20.10.07.17.04.57-rfc.patch >> >> -------- Forwarded Message -------- >> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? >> Date: Wed, 7 Oct 2020 08:49:47 -0700 >> From: Tom Eastep <te...@sh...> >> Reply-To: Shorewall Users <sho...@li...> >> To: sho...@li... > > Moving files in a pre/post section is normally creating orphan files, > which > afterward belong to no packages, which is not what we have as rules at > least > on openSUSE. Well, in most shorewall packages I've seen they don't control anything in /var/lib/shorewall so moving files there doesn't make anything worse. The only way to handle it would be to define %ghost files in the RPM and I've never tried that because the files in /var/lib/shorewall changed between releases and it's too much work to find them out. > > I agree with Simon point of view. Upgrade the system, but no automatic > upgrade, as you can too easily lockup everyone out if a problem occur. > Better save than sorry, yes :-) Regards, Simon |
From: Simon M. <sim...@in...> - 2020-10-08 07:12:51
|
> On 10/7/20 1:41 PM, Roberto C. Sánchez wrote: >> On Wed, Oct 07, 2020 at 01:38:15PM -0700, Tom Eastep wrote: >>> On 10/7/20 12:20 PM, Simon Matter wrote: >>>>> On Wed, 7 Oct 2020 18:26:36 +0200 >>>>> Matt Darfeuille <ma...@sh...> wrote: >>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? >>>>>> Date: Wed, 7 Oct 2020 08:49:47 -0700 >>>>>> From: Tom Eastep <te...@sh...> >>>>>> Reply-To: Shorewall Users <sho...@li...> >>>>>> To: sho...@li... >>>>>> >>>>> >>>>> Hmh. shorewall6 part of patch has a typo, easy to fix, just add >>>>> missing >>>>> / char. >>>>> >>>>> I don't like this work-around. It is not a real solution, it is just >>>>> work-around. >>>>> >>>>> Better solution would be to do compile after package upgrade. >>>>> >>>> >>>> I don't understand why you think of it as a work-around? It's a fix >>>> for >>>> the problem that in some cases, shorewall reload doesn't reload >>>> because >>>> the logic to detect changes fails on package updates which don't set >>>> current timestamps. >>>> >>>> I'd never want to have automatic recompilation on package upgrade - >>>> not >>>> for firewall code which may cut my line I'm using while doing the >>>> upgrade. >>>> >>>> On package upgrade, you don't see any error messages (with rpm, deb is >>>> different). How do you handle cases where compilaton fails? >>>> >>>> For me that's too dangerous. I do package upgrade, merge config files, >>>> reload, diff generated firewall and be happy. >>>> >>> >>> Another approach would be to simply 'touch' a file in >>> /usr/share/shorewall (/usr/share/shorewall/version, for example). >>> >>> That would allow 'reload' to force recompilation. >>> >> I'm not sure if that would work for RPM, but I am fairly certain that it >> would be considered a policy violation to do that from a Debian package >> maintainer script. Would touching a file in /var/lib/shorewall work? Touching /usr/share/shorewall/version would work but then the RPM package would fail verification, as long as you don't exclude timestamp checking of the /usr/share/shorewall/version file in the RPM. Touching anything in /var/lib/shorewall[6]/ won't work as this directory is not checked when finding out if something has changed. Therefore I thought making a copy of the firewall file is the easiest thing which also has the benefit to have a backup of the currently running configuration in case something fail with the upgrade. Regards, Simon |
From: Bruno F. <br...@io...> - 2020-10-08 06:57:47
|
On mercredi, 7 octobre 2020 18.26:36 h CEST Matt Darfeuille wrote: > Following Tom's advice, moving this (entire thread (1)) to the devel list. > > Any thoughts on the below (the patch in question (2) is reattached here)? > > 1) > https://sourceforge.net/p/shorewall/mailman/shorewall-users/thread/d83aa9a26 > 26c6459f58f671af768b570.squirrel%40webmail.bi.corp.invoca.ch/#msg37121743 2) > Release repository, master branch, patch file: > release-master-1-20.10.07.17.04.57-rfc.patch > > -------- Forwarded Message -------- > Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? > Date: Wed, 7 Oct 2020 08:49:47 -0700 > From: Tom Eastep <te...@sh...> > Reply-To: Shorewall Users <sho...@li...> > To: sho...@li... Moving files in a pre/post section is normally creating orphan files, which afterward belong to no packages, which is not what we have as rules at least on openSUSE. I agree with Simon point of view. Upgrade the system, but no automatic upgrade, as you can too easily lockup everyone out if a problem occur. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch GPG KEY : D5C9B751C4653227 irc: tigerfoot |
From: Tom E. <te...@sh...> - 2020-10-08 04:31:31
|
On 10/7/20 1:41 PM, Roberto C. Sánchez wrote: > On Wed, Oct 07, 2020 at 01:38:15PM -0700, Tom Eastep wrote: >> On 10/7/20 12:20 PM, Simon Matter wrote: >>>> On Wed, 7 Oct 2020 18:26:36 +0200 >>>> Matt Darfeuille <ma...@sh...> wrote: >>>> >>>>> -------- Forwarded Message -------- >>>>> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? >>>>> Date: Wed, 7 Oct 2020 08:49:47 -0700 >>>>> From: Tom Eastep <te...@sh...> >>>>> Reply-To: Shorewall Users <sho...@li...> >>>>> To: sho...@li... >>>>> >>>> >>>> Hmh. shorewall6 part of patch has a typo, easy to fix, just add missing >>>> / char. >>>> >>>> I don't like this work-around. It is not a real solution, it is just >>>> work-around. >>>> >>>> Better solution would be to do compile after package upgrade. >>>> >>> >>> I don't understand why you think of it as a work-around? It's a fix for >>> the problem that in some cases, shorewall reload doesn't reload because >>> the logic to detect changes fails on package updates which don't set >>> current timestamps. >>> >>> I'd never want to have automatic recompilation on package upgrade - not >>> for firewall code which may cut my line I'm using while doing the upgrade. >>> >>> On package upgrade, you don't see any error messages (with rpm, deb is >>> different). How do you handle cases where compilaton fails? >>> >>> For me that's too dangerous. I do package upgrade, merge config files, >>> reload, diff generated firewall and be happy. >>> >> >> Another approach would be to simply 'touch' a file in >> /usr/share/shorewall (/usr/share/shorewall/version, for example). >> >> That would allow 'reload' to force recompilation. >> > I'm not sure if that would work for RPM, but I am fairly certain that it > would be considered a policy violation to do that from a Debian package > maintainer script. Would touching a file in /var/lib/shorewall work? > No. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Roberto C. S. <ro...@co...> - 2020-10-07 20:41:12
|
On Wed, Oct 07, 2020 at 01:38:15PM -0700, Tom Eastep wrote: > On 10/7/20 12:20 PM, Simon Matter wrote: > >> On Wed, 7 Oct 2020 18:26:36 +0200 > >> Matt Darfeuille <ma...@sh...> wrote: > >> > >>> -------- Forwarded Message -------- > >>> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? > >>> Date: Wed, 7 Oct 2020 08:49:47 -0700 > >>> From: Tom Eastep <te...@sh...> > >>> Reply-To: Shorewall Users <sho...@li...> > >>> To: sho...@li... > >>> > >> > >> Hmh. shorewall6 part of patch has a typo, easy to fix, just add missing > >> / char. > >> > >> I don't like this work-around. It is not a real solution, it is just > >> work-around. > >> > >> Better solution would be to do compile after package upgrade. > >> > > > > I don't understand why you think of it as a work-around? It's a fix for > > the problem that in some cases, shorewall reload doesn't reload because > > the logic to detect changes fails on package updates which don't set > > current timestamps. > > > > I'd never want to have automatic recompilation on package upgrade - not > > for firewall code which may cut my line I'm using while doing the upgrade. > > > > On package upgrade, you don't see any error messages (with rpm, deb is > > different). How do you handle cases where compilaton fails? > > > > For me that's too dangerous. I do package upgrade, merge config files, > > reload, diff generated firewall and be happy. > > > > Another approach would be to simply 'touch' a file in > /usr/share/shorewall (/usr/share/shorewall/version, for example). > > That would allow 'reload' to force recompilation. > I'm not sure if that would work for RPM, but I am fairly certain that it would be considered a policy violation to do that from a Debian package maintainer script. Would touching a file in /var/lib/shorewall work? Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com |
From: Tom E. <te...@sh...> - 2020-10-07 20:38:28
|
On 10/7/20 12:20 PM, Simon Matter wrote: >> On Wed, 7 Oct 2020 18:26:36 +0200 >> Matt Darfeuille <ma...@sh...> wrote: >> >>> -------- Forwarded Message -------- >>> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? >>> Date: Wed, 7 Oct 2020 08:49:47 -0700 >>> From: Tom Eastep <te...@sh...> >>> Reply-To: Shorewall Users <sho...@li...> >>> To: sho...@li... >>> >> >> Hmh. shorewall6 part of patch has a typo, easy to fix, just add missing >> / char. >> >> I don't like this work-around. It is not a real solution, it is just >> work-around. >> >> Better solution would be to do compile after package upgrade. >> > > I don't understand why you think of it as a work-around? It's a fix for > the problem that in some cases, shorewall reload doesn't reload because > the logic to detect changes fails on package updates which don't set > current timestamps. > > I'd never want to have automatic recompilation on package upgrade - not > for firewall code which may cut my line I'm using while doing the upgrade. > > On package upgrade, you don't see any error messages (with rpm, deb is > different). How do you handle cases where compilaton fails? > > For me that's too dangerous. I do package upgrade, merge config files, > reload, diff generated firewall and be happy. > Another approach would be to simply 'touch' a file in /usr/share/shorewall (/usr/share/shorewall/version, for example). That would allow 'reload' to force recompilation. -Tom -- Tom Eastep \ Q: What do you get when you cross a mobster Shoreline, \ with an international standard? Washington, USA \ A: Someone who makes you an offer you http://shorewall.org \ can't understand \________________________________________ |
From: Simon M. <sim...@in...> - 2020-10-07 19:21:18
|
> On Wed, 7 Oct 2020 18:26:36 +0200 > Matt Darfeuille <ma...@sh...> wrote: > >> -------- Forwarded Message -------- >> Subject: Re: [Shorewall-users] Shorewall reload doesn't reload? >> Date: Wed, 7 Oct 2020 08:49:47 -0700 >> From: Tom Eastep <te...@sh...> >> Reply-To: Shorewall Users <sho...@li...> >> To: sho...@li... >> > > Hmh. shorewall6 part of patch has a typo, easy to fix, just add missing > / char. > > I don't like this work-around. It is not a real solution, it is just > work-around. > > Better solution would be to do compile after package upgrade. > I don't understand why you think of it as a work-around? It's a fix for the problem that in some cases, shorewall reload doesn't reload because the logic to detect changes fails on package updates which don't set current timestamps. I'd never want to have automatic recompilation on package upgrade - not for firewall code which may cut my line I'm using while doing the upgrade. On package upgrade, you don't see any error messages (with rpm, deb is different). How do you handle cases where compilaton fails? For me that's too dangerous. I do package upgrade, merge config files, reload, diff generated firewall and be happy. Regards, Simon |