The Shorewall team is pleased to announce the availability of Shorewall 4.5.14. Please note that new capabilities are implemented in this release, so your capabilities file(s) must be regenerated after installation of the release. ---------------------------------------------------------------------------- I. P R O B L E M S C O R R E C T E D I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) Previously, a list of IPv6 host addresses where each address was enclosed in square brackets generated a fatal compile-time error. Such lists are now handled correctly. 2) The Shorewall ''load'', ''reload'' and ''export'' commands have now been modified to use a shorewallrc file in a remote system''s export directory. If the directory layout of the remote system differs from that of the administrative system, then the remote system''s export directory should contains a copy of that system''s shorewallrc file. 3) A syntax error in the Shorewall uninstall.sh file has been eliminated. 4) The contents of the various configpath files have been corrected. 5) The Shorewall uninstall.sh script previously failed to remove the macro files from ${SHAREDIR}/shorewall. Those files are now removed. 6) The ''version -a'' command now prints the correct shorewall-core version when it is run from shorewall6, shorewall-lite and shorewall6-lite. 7) It is now possible to specify a port or port range along with an address variable in the ADDRESSES column of /etc/shorewall/masq. Example: #INTERFACE SOURCE ADDRESS PROTO DEST # PORT(S) eth0 172.20.4.0/24 ð0:44 tcp 45 Previously, this usage generated a fatal compilation error. 8) Port numbers and service names may now be specified with the UDPLITE protocol. As part of this change, two new capabilities have been added. - Enhanced Multi-port Match Multi-port match (''-m multiport'') can operate on SCTP and DCCP - UDPLITE Port Redirection Currently, neither DNAT nor REDIRECT support port redirection of UDPLITE. This capability is added to detect that support in the future. 9) The SUBSYSLOCK setting in the default shorewall6.conf file has been changed from /var/lock/subsys/shorewall to /var/lock/subsys/shorewall6. 10) ''blackhole'' routes are now copied to provider tables when USE_DEFAULT_RT=No. Previously, these routes were not copied with the result that packets could be routed to blackholed addresses. 11) Duplicate interface names could previously appear in a case statement in the generated script. These duplicates are now suppressed. 12) Previously, a duplicate ''echo'' command could appear in the generated script. Now only a single command appears. ---------------------------------------------------------------------------- I I. K N O W N P R O B L E M S R E M A I N I N G ---------------------------------------------------------------------------- 1) On systems running Upstart, shorewall-init cannot reliably secure the firewall before interfaces are brought up. ---------------------------------------------------------------------------- I I I. N E W F E A T U R E S I N T H I S R E L E A S E ---------------------------------------------------------------------------- 1) Previously, when compiling for export to a Shorewall lite system, either /etc/shorewall/params was required to be readable by the user or the remote host''s configuration directory was required to include a (possibly empty) params file. Beginning with this release, when a directory name is specified in a ''compile'', ''check'', ''load'', ''reload'' or ''export'' command and the user is not root (euid is not zero), then /sbin/shorewall and /sbin/shorewall6 will only look in the specified directory for the params and shorewall[6].conf files. 2) The BLACKLIST_LOGLEVEL option has been renamed BLACKLIST_LOG_LEVEL to be consistent with the other log-level option names. BLACKLIST_LOGLEVEL continues to be accepted as a synonym for BLACKLIST_LOG_LEVEL, but a ''shorewall update'' or ''shorewall6 update'' command will replace BLACKLIST_LOGLEVEL with BLACKLIST_LOG_LEVEL in the new .conf file. 3) Rules in the ESTABLISHED section are now placed in separate chains. Rules for traffic from zone Za to zone Zb and placed in ^Za2Zb or ^Za-Zb, depending on the setting of ZONE2ZONE. Previously, they were placed in Za2Zb (Za-Zb). 4) When the effective VERBOSITY is 2, the compiler now produces a report as follows: Configuration uses these capabilities (''*'' denotes required): ADDRTYPE ARPTABLESJF AUDIT_TARGET* COMMENTS CONNTRACK_MATCH CT_TARGET ENHANCED_REJECT EXMARK FTP_HELPER* FWMARK_RT_MASK GOTO_TARGET IPSET_MATCH* IRC_HELPER* LOG_TARGET* MANGLE_ENABLED MANGLE_FORWARD MARK* MULTIPORT NETBIOS_NS_HELPER NEW_CONNTRACK_MATCH NFACCT_MATCH* NFLOG_TARGET* RAW_TABLE* RPFILTER_MATCH* XMULTIPORT* Shorewall configuration verified 5) While we understand the evils of NAT, it is required for proper failover handling in IPv6 multi-ISP configurations. To accommodate that limited use case, Shorewall6 now supports basic Masquerade, SNAT and DNAT. This feature requires a 3.7 or later kernel and iptables 1.4.17 or later. Note: The current Fedora 18 3.4.7 kernel does not support IPv6 MASQUERADE, so you must specify one or more addresses in the ADDRESSES column. To approximate masquerade when running that kernel, use an address variable in the ADDRESS column. Example /etc/shorewall6/masq: INTERFACE SOURCE ADDRESS p3p1 2001:470:b:227::0/24 &p3p1 DNAT rules that specify a port number in the DEST column, must enclose the server address (if any) in square brackets. Example: ACTION SOURCE DEST PROTO PORTS DNAT net fw:[2001:470:b:227::2]:22 tcp 1022 As part of this change, a new ''MASQUERADE Target'' capability as been added. 6) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE column empty. 7) The iptables/ip6tables ''multiport match'' feature allows for matching either the source or the destination port against a list of port numbers. Up to this time, Shorewall did not allow users to take advantage of that capability. Beginning with this release, placing an equal sign in a SOURCE PORT(S) column is interpreted as ''match the list specified in the DEST PORT(S) column against both the packet source and destination port in the packet. If there is any match, then the packet matches the rule. Example from the accounting file: #ACTION CHAIN SOURCE DEST PROTO DEST SOURCE # PORT(S) PORT(S) COUNT - br0 - tcp 80 This rule matches all TCP packets entering through br0 where either the source port or the destination port is 80. Thank you for using Shorewall, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev
> 10) ''blackhole'' routes are now copied to provider tables when > USE_DEFAULT_RT=No. Previously, these routes were not copied with > the result that packets could be routed to blackholed addresses. > > [...] > > 6) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. > Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE > column empty. >For anyone (myself included) using this approach, be aware of the following: When a network interface goes down, all routes defined for that interface simply disappear, *except* the blackhole routes! What this means in reality is when the interface goes back up again, the previous routes, which were added when shorewall was brought up/loaded/reloaded/restarted need to be re-defined somehow (see below), otherwise all subnets defined as "holes" in those blackhole routes will *not* be reachable! I have just fallen, again, into this trap and spent the best part of this morning clearing up the mess, simply because I forgot to add these. There are, as far as I know, two approaches for solving this problem: 1. In addition to the "standard" shorewall package (shorewall-lite, shorewall, etc), add shorewall-init to take care of this (Tom, I am certain that the routes defined in those files will be honoured by shorewall-init, could you confirm this please?); 2. Add all network-interface dependent routes (the ones which "disappear" when the interface goes down) to /etc/sysconfig/network-scripts/route-X (where "X" is the name of the interface in question). At least in Fedora''s case, these can be taken care of by using the *new* format (which is the "ip" command format, i.e. "ip route add ..."). For example - to add a route to 10.1.0.0/24 via 10.1.1.1 on eth0 using table dmz, the following needs to be added to /etc/sysconfig/network-scripts/route-eth0: 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz That way, when the eth0 interface goes up, the above route will be "automatically" defined by the OS. Tom, I am not sure whether there is a page on shorewall.net, which explains all this, but if it isn''t I think it is worth adding one as I can imagine I am not the only one who would fall in the above trap. I am willing to give it a go for the writing bit, if you prefer - just let me know. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 04:45 AM, Mr Dash Four wrote:> >> 10) ''blackhole'' routes are now copied to provider tables when >> USE_DEFAULT_RT=No. Previously, these routes were not copied with >> the result that packets could be routed to blackholed addresses. >> >> [...] >> >> 6) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. >> Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE >> column empty. >> > For anyone (myself included) using this approach, be aware of the following: > > When a network interface goes down, all routes defined for that > interface simply disappear, *except* the blackhole routes! What this > means in reality is when the interface goes back up again, the previous > routes, which were added when shorewall was brought > up/loaded/reloaded/restarted need to be re-defined somehow (see below), > otherwise all subnets defined as "holes" in those blackhole routes will > *not* be reachable! > > I have just fallen, again, into this trap and spent the best part of > this morning clearing up the mess, simply because I forgot to add these. > There are, as far as I know, two approaches for solving this problem: > > 1. In addition to the "standard" shorewall package (shorewall-lite, > shorewall, etc), add shorewall-init to take care of this (Tom, I am > certain that the routes defined in those files will be honoured by > shorewall-init, could you confirm this please?);Yes.> > 2. Add all network-interface dependent routes (the ones which > "disappear" when the interface goes down) to > /etc/sysconfig/network-scripts/route-X (where "X" is the name of the > interface in question). At least in Fedora''s case, these can be taken > care of by using the *new* format (which is the "ip" command format, > i.e. "ip route add ..."). For example - to add a route to 10.1.0.0/24 > via 10.1.1.1 on eth0 using table dmz, the following needs to be added to > /etc/sysconfig/network-scripts/route-eth0: > > 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmzAgain, shorewall-init will trigger an ''up'' command for the interface which reloads all routes for the interface that were originally loaded by start/restart.> > That way, when the eth0 interface goes up, the above route will be > "automatically" defined by the OS. > > Tom, I am not sure whether there is a page on shorewall.net, which > explains all this, but if it isn''t I think it is worth adding one as I > can imagine I am not the only one who would fall in the above trap. I am > willing to give it a go for the writing bit, if you prefer - just let me > know. >There is no single place where these points are explained. I also notice that the tables in http://www.shorewall.net/Shorewall-init.html are out of date. For optional interfaces, shorewall-init now triggers ''enable'' and ''disable'' operations rather than reloading the configuration. I think that article would be a good place to gather all of this information in one spot. If you agree and would like to give it a go, I would be grateful. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 13/03/13 11:45, Mr Dash Four wrote:>> 10) ''blackhole'' routes are now copied to provider tables when >> USE_DEFAULT_RT=No. Previously, these routes were not copied with >> the result that packets could be routed to blackholed addresses. >> >> [...] >> >> 6) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. >> Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE >> column empty. >> > For anyone (myself included) using this approach, be aware of the following: > > When a network interface goes down, all routes defined for that > interface simply disappear, *except* the blackhole routes! What this > means in reality is when the interface goes back up again, the previous > routes, which were added when shorewall was brought > up/loaded/reloaded/restarted need to be re-defined somehow (see below), > otherwise all subnets defined as "holes" in those blackhole routes will > *not* be reachable! > > I have just fallen, again, into this trap and spent the best part of > this morning clearing up the mess, simply because I forgot to add these. > There are, as far as I know, two approaches for solving this problem: > > 1. In addition to the "standard" shorewall package (shorewall-lite, > shorewall, etc), add shorewall-init to take care of this (Tom, I am > certain that the routes defined in those files will be honoured by > shorewall-init, could you confirm this please?); > > 2. Add all network-interface dependent routes (the ones which > "disappear" when the interface goes down) to > /etc/sysconfig/network-scripts/route-X (where "X" is the name of the > interface in question). At least in Fedora''s case, these can be taken > care of by using the *new* format (which is the "ip" command format, > i.e. "ip route add ..."). For example - to add a route to 10.1.0.0/24 > via 10.1.1.1 on eth0 using table dmz, the following needs to be added to > /etc/sysconfig/network-scripts/route-eth0: > > 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz > > That way, when the eth0 interface goes up, the above route will be > "automatically" defined by the OS. > > Tom, I am not sure whether there is a page on shorewall.net, which > explains all this, but if it isn''t I think it is worth adding one as I > can imagine I am not the only one who would fall in the above trap. I am > willing to give it a go for the writing bit, if you prefer - just let me > know. > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersThis is more of an issue at the OS level than shorewall''s just a case of having to deal with it, if an interface loses it''s primary IP address (Removed, Lease Expired, Down etc) it is the usual case that all routes through the interface and it''s secondary IP''s are removed with it. I''m thinking you might already be aware of that but just wanted to mention it as it wasn''t so clear in your post. I wonder if there isn''t a better solution to this than writing the same data in two places, I usually always prefer solutions that avoid data duplication as it can lead to issues later when things must be updated. Can anyone confirm if `shorewall disable ifname` causes shorewall to redo the routing configuration when `shorewall enable ifname` is executed. If so these in the ifupdown scripts would probably be better recommendations as the routes that get added will remain those sourced from the shorewall configuration files and there wont be two places needed to be updated in the future if there are changes to the network(s) the host is connected to. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 13/03/13 15:24, Tom Eastep wrote:> On 03/13/2013 04:45 AM, Mr Dash Four wrote: >>> 10) ''blackhole'' routes are now copied to provider tables when >>> USE_DEFAULT_RT=No. Previously, these routes were not copied with >>> the result that packets could be routed to blackholed addresses. >>> >>> [...] >>> >>> 6) ''blackhole'' routes may now be defined in /etc/shorewall[6]/routes. >>> Simply place ''blackhole'' in the GATEWAY column and leave the DEVICE >>> column empty. >>> >> For anyone (myself included) using this approach, be aware of the following: >> >> When a network interface goes down, all routes defined for that >> interface simply disappear, *except* the blackhole routes! What this >> means in reality is when the interface goes back up again, the previous >> routes, which were added when shorewall was brought >> up/loaded/reloaded/restarted need to be re-defined somehow (see below), >> otherwise all subnets defined as "holes" in those blackhole routes will >> *not* be reachable! >> >> I have just fallen, again, into this trap and spent the best part of >> this morning clearing up the mess, simply because I forgot to add these. >> There are, as far as I know, two approaches for solving this problem: >> >> 1. In addition to the "standard" shorewall package (shorewall-lite, >> shorewall, etc), add shorewall-init to take care of this (Tom, I am >> certain that the routes defined in those files will be honoured by >> shorewall-init, could you confirm this please?); > Yes. > >> 2. Add all network-interface dependent routes (the ones which >> "disappear" when the interface goes down) to >> /etc/sysconfig/network-scripts/route-X (where "X" is the name of the >> interface in question). At least in Fedora''s case, these can be taken >> care of by using the *new* format (which is the "ip" command format, >> i.e. "ip route add ..."). For example - to add a route to 10.1.0.0/24 >> via 10.1.1.1 on eth0 using table dmz, the following needs to be added to >> /etc/sysconfig/network-scripts/route-eth0: >> >> 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz > Again, shorewall-init will trigger an ''up'' command for the interface > which reloads all routes for the interface that were originally loaded > by start/restart. > >> That way, when the eth0 interface goes up, the above route will be >> "automatically" defined by the OS. >> >> Tom, I am not sure whether there is a page on shorewall.net, which >> explains all this, but if it isn''t I think it is worth adding one as I >> can imagine I am not the only one who would fall in the above trap. I am >> willing to give it a go for the writing bit, if you prefer - just let me >> know. >> > There is no single place where these points are explained. I also notice > that the tables in http://www.shorewall.net/Shorewall-init.html are out > of date. For optional interfaces, shorewall-init now triggers ''enable'' > and ''disable'' operations rather than reloading the configuration. > > I think that article would be a good place to gather all of this > information in one spot. If you agree and would like to give it a go, I > would be grateful. > > Thanks, > -Tom > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > > > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-usersI think our mails must have crossed in a que somewhere as your comment there seems to confirm my suspicion that shorewall disable and a later shorewall enable would have the same effect was looking for a solution other than the given example with the data duplication issue. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 08:48 AM, Matt Joyce wrote:> I think our mails must have crossed in a que somewhere as your comment > there seems to confirm my suspicion that shorewall disable and a later > shorewall enable would have the same effect was looking for a solution > other than the given example with the data duplication issue.Agreed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> Yes. >Good to know. However, I just checked my /etc/sysconfig/network-scripts directory on a machine where shorewall-init is installed, but can''t see anything that is from shorewall(-init) - there are only standard scripts included as part of the OS installation (Fedora in my case). I do have /usr/libexec/shorewall/ifupdown, as well as /etc/init.d/shorewall-init (shorewall init seems to have been started as I do have /var/lock/subsys/shorewall-init present), so how do I verify that shorewall executes the "appropriate scripts" (/var/lib/shorewall/firewall?) when the interface goes up or down?>> 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz >> > > Again, shorewall-init will trigger an ''up'' command for the interface > which reloads all routes for the interface that were originally loaded > by start/restart. >Could you elaborate on this a bit more please? I ran grep -r "ifupdown" /etc, but could not find any meaningful matches. Does shorewall-init auto-generate these up/down scripts depending on my shorewall configuration or does it use them to insert a callback to /usr/libexec/ifupdown? If not, is this done in some other way?> I think that article would be a good place to gather all of this > information in one spot. If you agree and would like to give it a go, I > would be grateful. >Yes, I would, but it is going to be a simple text file as my html editing skills are not up to scratch. All this could be started at the weekend when I have more time if that''s OK with you. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 12:42 PM, Mr Dash Four wrote:> >> Yes. >> > Good to know. > > However, I just checked my /etc/sysconfig/network-scripts directory on a > machine where shorewall-init is installed, but can''t see anything that > is from shorewall(-init) - there are only standard scripts included as > part of the OS installation (Fedora in my case). I do have > /usr/libexec/shorewall/ifupdown, as well as /etc/init.d/shorewall-init > (shorewall init seems to have been started as I do have > /var/lock/subsys/shorewall-init present), so how do I verify that > shorewall executes the "appropriate scripts" > (/var/lib/shorewall/firewall?) when the interface goes up or down?On Redhat/Fedora, Shorewall-init installs the ifupdown script as /sbin/ifup-local and /sbin/ifdown-local.> >>> 10.1.0.0/24 via 10.1.1.1 dev eth0 table dmz >>> >> >> Again, shorewall-init will trigger an ''up'' command for the interface >> which reloads all routes for the interface that were originally loaded >> by start/restart. >> > Could you elaborate on this a bit more please? I ran grep -r "ifupdown" > /etc, but could not find any meaningful matches. Does shorewall-init > auto-generate these up/down scripts depending on my shorewall > configuration or does it use them to insert a callback to > /usr/libexec/ifupdown? If not, is this done in some other way?ifupdown runs ${VARDIR}/firewall passing it either an ''up'' or ''down'' command. e.g., /var/lib/shorewall/firewall up eth0. The firewall script''s up/down processing is taylored to your configuration.> >> I think that article would be a good place to gather all of this >> information in one spot. If you agree and would like to give it a go, I >> would be grateful. >> > Yes, I would, but it is going to be a simple text file as my html > editing skills are not up to scratch. All this could be started at the > weekend when I have more time if that''s OK with you.That''s fine. The Shorewall document sources are maintained in Docbook XML, but the free WYSIWYG editor that I use (XXE from XMLMind) is no longer available for download. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> On Redhat/Fedora, Shorewall-init installs the ifupdown script as > /sbin/ifup-local and /sbin/ifdown-local. >I don''t have any of this. I do have /sbin/ifup and /sbin/ifdown, but that, again, seems to be a standard-issue scripts. Still, how are these 2 scripts called? Is it by the OS when an interface goes up/down?>> Could you elaborate on this a bit more please? I ran grep -r "ifupdown" >> /etc, but could not find any meaningful matches. Does shorewall-init >> auto-generate these up/down scripts depending on my shorewall >> configuration or does it use them to insert a callback to >> /usr/libexec/ifupdown? If not, is this done in some other way? >> > > ifupdown runs ${VARDIR}/firewall passing it either an ''up'' or ''down'' > command. e.g., /var/lib/shorewall/firewall up eth0. The firewall > script''s up/down processing is taylored to your configuration. >What I need to understand is how are the /sbin/*-local scripts called (see above). I also assume that /var/lib/shorewall/firewall needs to be compiled, so I presume that "shorewall compile" is called at some stage to create this file, is that the case?> That''s fine. The Shorewall document sources are maintained in Docbook > XML, but the free WYSIWYG editor that I use (XXE from XMLMind) is no > longer available for download. >If I create it in a plain text format would that be a bit too much hassle for you? ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 01:18 PM, Mr Dash Four wrote:> >> On Redhat/Fedora, Shorewall-init installs the ifupdown script as >> /sbin/ifup-local and /sbin/ifdown-local. >> > I don''t have any of this. I do have /sbin/ifup and /sbin/ifdown, but > that, again, seems to be a standard-issue scripts. Still, how are these > 2 scripts called? Is it by the OS when an interface goes up/down?How did you install shorewall-init?> >>> Could you elaborate on this a bit more please? I ran grep -r "ifupdown" >>> /etc, but could not find any meaningful matches. Does shorewall-init >>> auto-generate these up/down scripts depending on my shorewall >>> configuration or does it use them to insert a callback to >>> /usr/libexec/ifupdown? If not, is this done in some other way? >>> >> >> ifupdown runs ${VARDIR}/firewall passing it either an ''up'' or ''down'' >> command. e.g., /var/lib/shorewall/firewall up eth0. The firewall >> script''s up/down processing is taylored to your configuration. >> > What I need to understand is how are the /sbin/*-local scripts called > (see above)./sbin/ifup-local is invoked by /etc/sysconf/network-scripts/ifup-post. /sbin/ifdown-local is invoked by /etc/sysconf/network-scripts/ifdown-post.> I also assume that /var/lib/shorewall/firewall needs to be > compiled, so I presume that "shorewall compile" is called at some stage > to create this file, is that the case?A successful start or restart will populate that file (as will compile).> >> That''s fine. The Shorewall document sources are maintained in Docbook >> XML, but the free WYSIWYG editor that I use (XXE from XMLMind) is no >> longer available for download. >> > If I create it in a plain text format would that be a bit too much > hassle for you?Not at all; I can copy/paste the text into the editor. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 01:47 PM, Tom Eastep wrote:> On 03/13/2013 01:18 PM, Mr Dash Four wrote: >> >>> On Redhat/Fedora, Shorewall-init installs the ifupdown script as >>> /sbin/ifup-local and /sbin/ifdown-local. >>> >> I don''t have any of this. I do have /sbin/ifup and /sbin/ifdown, but >> that, again, seems to be a standard-issue scripts. Still, how are these >> 2 scripts called? Is it by the OS when an interface goes up/down? > > > How did you install shorewall-init? >I just installed on Fedora 18 using the tarball installer, and both /sbin/ifup-local and /sbin/ifdown-local were created. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
>> I don''t have any of this. I do have /sbin/ifup and /sbin/ifdown, but >> that, again, seems to be a standard-issue scripts. Still, how are these >> 2 scripts called? Is it by the OS when an interface goes up/down? >> > > > How did you install shorewall-init? >Compiled from sources to build rpm (using rpmbuild) and then made/installed as a Live image, which is then copied to the target machine (plenty of RAM, very limited amount of "disk" space). The target system has 9 interfaces. I see that the rpm you are distributing (shorewall-init-4.5.14-0base.noarch.rpm) doesn''t have these files either.> /sbin/ifup-local is invoked by /etc/sysconf/network-scripts/ifup-post. > /sbin/ifdown-local is invoked by /etc/sysconf/network-scripts/ifdown-post. >Yep, grep agrees, thanks!>> I also assume that /var/lib/shorewall/firewall needs to be >> compiled, so I presume that "shorewall compile" is called at some stage >> to create this file, is that the case? >> > > A successful start or restart will populate that file (as will compile). >In this case, I am assuming that "shorewall" (the service) needs to start prior to "shorewall-lite". I do remember having to alter the "shorewall-init" start up script to execute "shorewall compile" first (and I vaguely remember that you added a few alterations to shorewall(-init), as per my request, to accommodate this) as there was a chicken-and-egg scenario developing.> Not at all; I can copy/paste the text into the editor. >No problem for me then, thanks. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 02:04 PM, Mr Dash Four wrote:> >>> I don''t have any of this. I do have /sbin/ifup and /sbin/ifdown, but >>> that, again, seems to be a standard-issue scripts. Still, how are these >>> 2 scripts called? Is it by the OS when an interface goes up/down? >>> >> >> >> How did you install shorewall-init? >> > Compiled from sources to build rpm (using rpmbuild) and then > made/installed as a Live image, which is then copied to the target > machine (plenty of RAM, very limited amount of "disk" space). The target > system has 9 interfaces. I see that the rpm you are distributing > (shorewall-init-4.5.14-0base.noarch.rpm) doesn''t have these files either.They are created in the %post section.> >> /sbin/ifup-local is invoked by /etc/sysconf/network-scripts/ifup-post. >> /sbin/ifdown-local is invoked by /etc/sysconf/network-scripts/ifdown-post. >> > Yep, grep agrees, thanks! > >>> I also assume that /var/lib/shorewall/firewall needs to be >>> compiled, so I presume that "shorewall compile" is called at some stage >>> to create this file, is that the case? >>> >> >> A successful start or restart will populate that file (as will compile). >> > In this case, I am assuming that "shorewall" (the service) needs to > start prior to "shorewall-lite". I do remember having to alter the > "shorewall-init" start up script to execute "shorewall compile" first > (and I vaguely remember that you added a few alterations to > shorewall(-init), as per my request, to accommodate this) as there was a > chicken-and-egg scenario developing.Yes, if $VARDIR is not preserved across reboot, then the issue that you refer to arises -- that should now work correctly on a system with Shorewall installed. If $VARDIR persists across reboot, then no compilation is needed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> I just installed on Fedora 18 using the tarball installer, and both > /sbin/ifup-local and /sbin/ifdown-local were created. >shorewall-init-4.5.13-1.fc19.noarch.rpm (the latest offering from Fedora) doesn''t have /sbin/ifup-local or /sbin/ifdown-local in it and "rpm --scripts -qp shorewall-init-4.5.13-1.fc19.noarch.rpm" tells me: postinstall scriptlet (using /bin/sh): if [ $1 -eq 1 ] ; then # Initial installation /usr/bin/systemctl preset shorewall-init.service >/dev/null 2>&1 || : fi preuninstall scriptlet (using /bin/sh): if [ $1 -eq 0 ] ; then # Package removal, not upgrade /usr/bin/systemctl --no-reload disable shorewall-init.service > /dev/null 2>&1 || : /usr/bin/systemctl stop shorewall-init.service > /dev/null 2>&1 || : fi postuninstall scriptlet (using /bin/sh): /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : if [ $1 -ge 1 ] ; then # Package upgrade, not uninstall /usr/bin/systemctl try-restart shorewall-init.service >/dev/null 2>&1 || : fi So I don''t see how these two files could have been generated/installed using standard Fedora installation and I am pretty certain that "rpmbuild -bb shorewall.spec" doesn''t generate these either as that is what shorewall.spec tells me: %files init %doc shorewall-init-%{version}/{COPYING,changelog.txt,releasenotes.txt} %{_sbindir}/shorewall-init %{_sysconfdir}/NetworkManager/dispatcher.d/01-shorewall %config(noreplace) %{_sysconfdir}/sysconfig/shorewall-init %{_sysconfdir}/logrotate.d/shorewall-init %{_mandir}/man8/shorewall-init.8.* %{_datadir}/shorewall-init %{_libexecdir}/shorewall-init %{_unitdir}/shorewall-init.service As tou can notice, there is no %{_sbindir}/ifup-* - only "shorewall-init". ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> They are created in the %post section. >Nope - see my other post.> Yes, if $VARDIR is not preserved across reboot, then the issue that you > refer to arises -- that should now work correctly on a system with > Shorewall installed.That is indeed the case - as the whole root is Live image, nothing is preserved (for security reasons - everything is decrypted and then loaded into RAM), so I need to have a working/fresh copy of ${VARLIB}/shorewall/firewall present.> If $VARDIR persists across reboot, then no compilation is needed. >Yep. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 02:27 PM, Mr Dash Four wrote:> >> I just installed on Fedora 18 using the tarball installer, and both >> /sbin/ifup-local and /sbin/ifdown-local were created. >> > shorewall-init-4.5.13-1.fc19.noarch.rpm (the latest offering from > Fedora) doesn''t have /sbin/ifup-local or /sbin/ifdown-local in it and > "rpm --scripts -qp shorewall-init-4.5.13-1.fc19.noarch.rpm" tells me: > > postinstall scriptlet (using /bin/sh): > > if [ $1 -eq 1 ] ; then > # Initial installation > /usr/bin/systemctl preset shorewall-init.service >/dev/null 2>&1 > || : > fi > preuninstall scriptlet (using /bin/sh): > > if [ $1 -eq 0 ] ; then > # Package removal, not upgrade > /usr/bin/systemctl --no-reload disable shorewall-init.service > > /dev/null 2>&1 || : > /usr/bin/systemctl stop shorewall-init.service > /dev/null 2>&1 > || : > fi > postuninstall scriptlet (using /bin/sh): > > /usr/bin/systemctl daemon-reload >/dev/null 2>&1 || : > if [ $1 -ge 1 ] ; then > # Package upgrade, not uninstall > /usr/bin/systemctl try-restart shorewall-init.service >/dev/null > 2>&1 || : > fi > > > So I don''t see how these two files could have been generated/installed > using standard Fedora installation and I am pretty certain that > "rpmbuild -bb shorewall.spec" doesn''t generate these either as that is > what shorewall.spec tells me: > > %files init > %doc shorewall-init-%{version}/{COPYING,changelog.txt,releasenotes.txt} > %{_sbindir}/shorewall-init > %{_sysconfdir}/NetworkManager/dispatcher.d/01-shorewall > %config(noreplace) %{_sysconfdir}/sysconfig/shorewall-init > %{_sysconfdir}/logrotate.d/shorewall-init > %{_mandir}/man8/shorewall-init.8.* > %{_datadir}/shorewall-init > %{_libexecdir}/shorewall-init > %{_unitdir}/shorewall-init.service > > As tou can notice, there is no %{_sbindir}/ifup-* - only "shorewall-init".Okay -- that seems to be a Fedora packaging issue. The .spec file that I release is intended to work on both RedHat/Fedora and on SuSE. Because the installation requirements are so different on these two distro families, I use logic in %post to install the ifupdown script in the proper places. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> Okay -- that seems to be a Fedora packaging issue. The .spec file that I > release is intended to work on both RedHat/Fedora and on SuSE.Indeed! "rpm --scripts -qp shorewall-init-4.5.14-0base.noarch.rpm" confirms it: postinstall scriptlet (using /bin/sh): [...] if [ -f /etc/SuSE-release ]; then cp -pf /usr/lib/shorewall-init/ifupdown /etc/sysconfig/network/if-up.d/shorewall cp -pf /usr/lib/shorewall-init/ifupdown /etc/sysconfig/network/if-down.d/shorewall if [ -d /etc/ppp ]; then for directory in ip-up.d ip-down.d ipv6-up.d ipv6-down.d; do mkdir -p /etc/ppp/$directory cp -pf /usr/lib/shorewall-init/ifupdown /etc/ppp/$directory/shorewall done fi else if [ -f /sbin/ifup-local -o -f /sbin/ifdown-local ]; then if ! grep -q Shorewall /sbin/ifup-local || ! grep -q Shorewall /sbin/ifdown-local; then echo "WARNING: /sbin/ifup-local and/or /sbin/ifdown-local already exist; ifup/ifdown events will not be handled" >&2 else cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifup-local cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifdown-local fi else cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifup-local cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifdown-local fi [...] preuninstall scriptlet (using /bin/sh): [...] [ -f /sbin/ifup-local ] && grep -q Shorewall /sbin/ifup-local && rm -f /sbin/ifup-local [ -f /sbin/ifdown-local ] && grep -q Shorewall /sbin/ifdown-local && rm -f /sbin/ifdown-local [ -f /etc/ppp/ip-up.local ] && grep -q Shorewall-based /etc/ppp/ip-up.local && rm -f /etc/ppp/ip-up.local [ -f /etc/ppp/ip-down.local ] && grep -q Shorewall-based /etc/ppp/ip-down.local && rm -f /etc/ppp/ip-down.local rm -f /etc/NetworkManager/dispatcher.d/01-shorewall fi So, hopefully Jonathan G. Underwood will take notice and add the appropriate code to shorewall.spec in all Fedora distros. In the meantime, if I copy these two files (from your pre-packaged .rpm file) directly to /sbin on the target machine, would that do the trick?> Because the installation requirements are so different on these two distro > families, I use logic in %post to install the ifupdown script in the > proper places. >No problem, I just needed to make sure that I am not doing something wrong. I''ll modify my own .spec file (which is a bit different from the "standard" issue distributed by Fedora) to include the above logic. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> In the meantime, if I copy these two files (from your pre-packaged > .rpm file) directly to /sbin on the target machine, would that do the > trick?What I meant was: cp -pf /usr/libexec/shorewall-init/ifupdown /sbin/ifup-local cp -pf /usr/libexec/shorewall-init/ifupdown /sbin/ifdown-local ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 02:47 PM, Mr Dash Four wrote:> >> Okay -- that seems to be a Fedora packaging issue. The .spec file that I >> release is intended to work on both RedHat/Fedora and on SuSE. > Indeed! "rpm --scripts -qp shorewall-init-4.5.14-0base.noarch.rpm" > confirms it: > > postinstall scriptlet (using /bin/sh): > [...] > if [ -f /etc/SuSE-release ]; then > cp -pf /usr/lib/shorewall-init/ifupdown > /etc/sysconfig/network/if-up.d/shorewall > cp -pf /usr/lib/shorewall-init/ifupdown > /etc/sysconfig/network/if-down.d/shorewall > if [ -d /etc/ppp ]; then > for directory in ip-up.d ip-down.d ipv6-up.d ipv6-down.d; do > mkdir -p /etc/ppp/$directory > cp -pf /usr/lib/shorewall-init/ifupdown > /etc/ppp/$directory/shorewall > done > fi > else > if [ -f /sbin/ifup-local -o -f /sbin/ifdown-local ]; then > if ! grep -q Shorewall /sbin/ifup-local || ! grep -q Shorewall > /sbin/ifdown-local; then > echo "WARNING: /sbin/ifup-local and/or /sbin/ifdown-local > already exist; ifup/ifdown events will not be handled" >&2 > else > cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifup-local > cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifdown-local > fi > else > cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifup-local > cp -pf /usr/lib/shorewall-init/ifupdown /sbin/ifdown-local > fi > [...] > preuninstall scriptlet (using /bin/sh): > [...] > [ -f /sbin/ifup-local ] && grep -q Shorewall /sbin/ifup-local && > rm -f /sbin/ifup-local > [ -f /sbin/ifdown-local ] && grep -q Shorewall /sbin/ifdown-local && > rm -f /sbin/ifdown-local > > [ -f /etc/ppp/ip-up.local ] && grep -q Shorewall-based > /etc/ppp/ip-up.local && rm -f /etc/ppp/ip-up.local > [ -f /etc/ppp/ip-down.local ] && grep -q Shorewall-based > /etc/ppp/ip-down.local && rm -f /etc/ppp/ip-down.local > > rm -f /etc/NetworkManager/dispatcher.d/01-shorewall > fi > > So, hopefully Jonathan G. Underwood will take notice and add the > appropriate code to shorewall.spec in all Fedora distros. In the > meantime, if I copy these two files (from your pre-packaged .rpm file) > directly to /sbin on the target machine, would that do the trick?Yes -- or copy the ifupdown script in $LIBEXEC/shorewall-init/ to those two files. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 03/13/2013 02:52 PM, Mr Dash Four wrote:> >> In the meantime, if I copy these two files (from your pre-packaged >> .rpm file) directly to /sbin on the target machine, would that do the >> trick? > What I meant was: > > cp -pf /usr/libexec/shorewall-init/ifupdown /sbin/ifup-local > cp -pf /usr/libexec/shorewall-init/ifupdown /sbin/ifdown-local >Yep. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
> Yes -- or copy the ifupdown script in $LIBEXEC/shorewall-init/ to those > two files. >Yep, did that, thanks. I will alter ifupdown slightly when I have the time though, to remove the Debian/SuSe-related checks as they are not needed when I know I have Fedora installed. So, to conclude this - when the interface goes up/down, then the OS passes execution to /sbin/ifup-local or /sbin/ifdown-local and that is when shorewall takes over. If that is indeed the case, then I might abandon my previous configuration (when using the OS-provided scripts) and use shorewall-init instead as in such case all of my routes management is in one place and I won''t need to mess about with anything else. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar
On 3/13/13 3:02 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Yes -- or copy the ifupdown script in $LIBEXEC/shorewall-init/ to those >> two files. >> >Yep, did that, thanks. I will alter ifupdown slightly when I have the >time though, to remove the Debian/SuSe-related checks as they are not >needed when I know I have Fedora installed. > >So, to conclude this - when the interface goes up/down, then the OS >passes execution to /sbin/ifup-local or /sbin/ifdown-local and that is >when shorewall takes over. If that is indeed the case, then I might >abandon my previous configuration (when using the OS-provided scripts) >and use shorewall-init instead as in such case all of my routes >management is in one place and I won''t need to mess about with anything >else.That should work fine. Let me know if you run into problems. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar