Kosta Velikov | 21 Oct 10:57 2014
Picon

exclude DESTINATION network from masq?

Hi fiolks,
I've been using Sorewall for more than a year, and I am happy with it.

I have a subnet that is router via the external interface of a linux router, running shorewall. The internal network is masqed. I want the internal network to be able to reach the subnet (routed via the external interface) without masq. The rest must remain masqed.

With iptables, I accomplish that with 1 line rule, placed BEFORE the NAT rule - excluding destination 10.20.30.0/24:
iptables -A POSTROUTING -s 10.16.0.0/24 -d 10.20.30.0/24 -o bond0.3113 -m comment --comment "exclude destination 10.20.30.0/24 from NAT" -j RETURN

How do I accomplish this with Shorewall? In the masq file, I can exclude only source addresses, and I cannot state any destinations?


Some info:

altadmin <at> vn-frog-01:/share$ /sbin/shorewall version
4.4.26.1

altadmin <at> vn-frog-01:/share$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1f:29:5e:5c:40 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21f:29ff:fe5e:5c40/64 scope link
       valid_lft forever preferred_lft forever
3: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 00:1f:29:5e:5c:41 brd ff:ff:ff:ff:ff:ff
    inet 10.16.254.2/24 brd 10.16.254.255 scope global eth2
4: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1546 qdisc mq master bond0 state UP qlen 1000
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
5: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1546 qdisc mq master bond0 state UP qlen 1000
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1546 qdisc noqueue state UP
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21f:29ff:fee9:e15c/64 scope link
       valid_lft forever preferred_lft forever
7: eth3.3214 <at> eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1f:29:5e:5c:40 brd ff:ff:ff:ff:ff:ff
    inet 87.121.90.148/28 brd 87.121.90.159 scope global eth3.3214
    inet 87.121.90.150/32 scope global eth3.3214:vrrp
    inet6 fe80::21f:29ff:fe5e:5c40/64 scope link
       valid_lft forever preferred_lft forever
8: bond0.1 <at> bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1546 qdisc noqueue state UP
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
    inet 10.16.0.2/24 brd 10.16.0.255 scope global bond0.1
    inet 10.16.0.1/32 scope global bond0.1:vrrp
    inet6 fe80::21f:29ff:fee9:e15c/64 scope link
       valid_lft forever preferred_lft forever
9: bond0.2 <at> bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1546 qdisc noqueue state UP
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
    inet 10.248.0.2/24 brd 10.248.0.255 scope global bond0.2
    inet 10.248.0.1/32 scope global bond0.2:vrrp
    inet6 fe80::21f:29ff:fee9:e15c/64 scope link
       valid_lft forever preferred_lft forever
10: bond0.3113 <at> bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1f:29:e9:e1:5c brd ff:ff:ff:ff:ff:ff
    inet 31.13.248.2/22 brd 31.13.251.255 scope global bond0.3113
    inet 31.13.248.1/32 scope global bond0.3113:vrrp
    inet6 fe80::21f:29ff:fee9:e15c/64 scope link
       valid_lft forever preferred_lft forever

altadmin <at> vn-frog-01:/share$ ip route show
default via 87.121.90.147 dev eth3.3214  metric 100
10.16.0.0/24 dev bond0.1  proto kernel  scope link  src 10.16.0.2
10.16.254.0/24 dev eth2  proto kernel  scope link  src 10.16.254.2
10.20.30.0/24 via 87.121.90.151 dev eth3.3214
10.248.0.0/24 dev bond0.2  proto kernel  scope link  src 10.248.0.2
31.13.248.0/22 dev bond0.3113  proto kernel  scope link  src 31.13.248.2
87.121.90.144/28 dev eth3.3214  proto kernel  scope link  src 87.121.90.148
172.17.17.0/24 via 87.121.90.151 dev eth3.3214
192.168.127.0/24 via 87.121.90.151 dev eth3.3214

--

Thanks.
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Tom Eastep | 19 Oct 18:07 2014
Picon

Shorewall 4.6.4.3

Thomas D has discovered that the fix for LOG_BACKEND released in 4.6.4.2
does not correct the problem on newer kernels. 4.6.4.2 corrected the
problem on Debian Squeeze and RHEL6 and derivatives, but it did not
correct Fedora, RHEL7, Debian Jessie and Gentoo. I suspect that OpenSuSE
was also not corrected.

Shorewall 4.6.4.3 corrects the problem on these remaining systems.

My apologies for the rapid-fire point releases.

-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 \________________________________________________

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Tom Eastep | 18 Oct 18:10 2014
Picon

Shorewall 4.6.4.2

Shorewall 4.6.4.2 is now available for download.

Problems corrected since 4.6.4.1:

1)  Setting LOGBACKEND=ipt_LOG could result in the following startup
    failure at boot:

       Starting shorewall ...
       /var/lib/shorewall/firewall: line 2080: echo: write error: No
                  such file or directory
          WARNING: Unable to set log backend to ipt_LOG

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 \________________________________________________

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Filippo Carletti | 17 Oct 12:18 2014
Picon

NFQUEUE --queue-bypass

Hi,
I'd like to use the --queue-bypass option of NFQUEUE. From iptables man page:

      --queue-bypass
              By  default,  if no userspace program is listening on an
NFQUEUE, then all packets that are to be queued are dropped.  When
this option is used, the NFQUEUE rule is silently bypassed instead.
The packet will move on to the next rule.

I tried to create a new action in embedded perl, but I can't figure
out the syntax to add an option to a target.
Moreover, I think I can't use a custom action in a policy (now, I have
"loc net NFQUEUE").

What's the best way to add the --queue-bypass option to nfqueue?

I quickly patched Rules.pm and it works as expected, but
--queue-bypass should be optional based on capabilities.

P.S. The final target of this work is to have snort/suricata setup
like described here:
http://www.spinics.net/lists/netfilter/msg55072.html

--

-- 
Ciao,
Filippo

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Vernon Fort | 15 Oct 20:41 2014

VPN and sfilter

I have a strongswan vpn working ‘almost’ file.  Its connects and traffic does pass but I have one problem.

 

Shorewall:sfilter1:DROP:IN=enp3s7 OUT=enp3s7 MAC=00:02:b3:08:05:d2:00:18:fe:81:24:97:08:00 SRC=192.168.1.50 DST=192.168.1.165

 

The above was an attempt to browse via windows explorer over the VPN.

 

Can someone point me to the correct documentation?  Below is the relevant configurations.

 

Thanks

 

Vernon

Interfaces:

#ZONE   INTERFACE       BROADCAST       OPTIONS

net     enp2s0            detect          tcpflags,routefilter,nosmurfs,logmartians

loc     enp3s7            detect          tcpflags,nosmurfs

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE

 

Hosts:

#ZONE   HOST(S)                                 OPTIONS

vpn     enp2s0:0.0.0.0/0                ipsec

 

Tunnels

#TYPE                   ZONE    GATEWAY(S)                      GATEWAY

#                                                               ZONE(S)

ipsec                   net     0.0.0.0/0               vpn

 

Policy:

# VPN roadwarrior

vpn             $FW             ACCEPT

$FW             vpn             ACCEPT

loc             vpn             ACCEPT

vpn             loc             ACCEPT

vpn             net             ACCEPT

 

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Tom Eastep | 10 Oct 20:41 2014
Picon

Shorewall 4.6.4

The Shorewall team is pleased to announce the availability of Shorewall
4.6.4.

Problems Corrected:

1)  This release includes defect repair through release 4.6.3.4.

2)  Two corrections have been made to the .service files:

    - The .service files now correctly specify

          WantedBy=basic.target

    - Conflicting services have been added.

3)  A warning message generated during stoppedrules processing
    previously referred to the file as routestopped.

4)  Previously, the stoppedrules file did not work properly when
    ADMINISABSENTMINDED=No.

    - A warning message was issued stating that the file would be
      processed as if ADMINISABSENTMINDED=Yes, and it was.

    - Unfortunately, part of the surrounding rule-generating logic
      proceded as if ADMINISABSENTMINDED=No, leading to an unusable
      ruleset.

    This problem has been corrected by changing the way that
    stoppedrules works with ADMINISABSENTMINDED=No. In the new
    implementation:

    - All existing connections continue to work.
    - Response packets and related connection requests to new accepted
      connections are accepted (in other words, the resulting ruleset
      is stateful).

    See shorewall[6].conf(5) for additional details.

5)  The .spec files now set SBINDIR correctly.

6)  The -lite installers now create INITDIR if it doesn't exist.

7)  The installers no longer attempt to create a symbolic link to the
    init script when no init script is installed.

8)  A large number of defects in the uninstallers have been corrected.

New Features:

1)  Install support for Centos 7 and Foobar 7 has been added (Tuomo
    Soini).

2)  A 'terminating' option has been added to shorewall[6].actions.
    this option, when used with the 'builtin' option, indicates to the
    compiler that the built-in action is terminating. This allows the
    optimizer to omit rules after an unconditional jump to the
    built-in.

3)  A LOG_BACKEND option has been added to allow specification of the
    default logging backends. See shorewall.conf(5) and
    shorewall6.conf(5) for details.

4)  The SAVE_IPSETS option may now specify a list of ipsets to be
    saved. When such a list is specified, only those ipsets together
    with the ipsets supporting dynamic zones are saved.

    Shorewall6 now supports the SAVE_IPSETS option. When
    SAVE_IPSETS=Yes, only ipv6 ipsets are saved. For Shorewall, if
    SAVE_IPSETS=ipv4, then only ipv4 ipsets are saved. Both features
    require ipset version 5 or later.

    Note that shorewall.conf and shorewall6.conf may now both specify
    SAVE_IPSETS.

5)  The SBINDIR setting for SuSE now defaults to /usr/sbin/.

6)  With the exception of Shorewall-core, the tarball installers and
    uninstallers now support a -n option which inhibits any attempt to
    change the startup configuration. The -n option can be
    automatically invoked by setting the SANDBOX variable to a
    non-empty value, either in the environment or in your shorewallrc
    file.

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 \________________________________________________

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://p.sf.net/sfu/Zoho
PGNd | 9 Oct 16:03 2014
Picon

Re: SW 4.6.4+' systemd service files' Before=/After= dependency on 'network.target' -- should that be 'network-pre.target' and 'network-online.target'?

On Thu, Oct 9, 2014, at 06:27 AM, Bruno Friedmann wrote:
> > Another, is providing a fallback
> > 
> >   Before=network.target network-ore.target
> >   Wants=network.target network-pre.target
> > 
> > I _think_ that should fail gracefully in the case of no available network-pre ... but I am not at all sure of
the effects under systemd.
> 
> Well Before and After are not mandatory, so if doesn't exist simply continue the job
> Requires (Want too?) are mandatory so if not there systemd will just fail -> mean going to rescue console
> which is the worse case for a remote connected system :-)

Asking  <at>  #systemd

	Q:
		Deploying a unit file for firewall, I'd like to use "Before=network-pre.target;
Wants=network-pre.target" as discussed on the ML.  the -pre target is not available until systemd v=214. 
Some current distro(s) are, and will be for awhile, at v < 214 (e.g., openSUSE v13.2  <at>  systemd v = 210).

		Can a unit file be safely deployed *now* to fallback to network.target in the absence of
network-pre.target?  I.e., is this safe/workable "Before=network.target network-pre.target;
Wants=network.target network-pre.target" ?

	A:
		if you are deploying it anyway, just deploy the network-pre target
		...
		just deploy the changes that added network-pre target
		since its basically just modifying unit files

The systemd commit that adds network-pre.target is found  <at> 

	http://lists.freedesktop.org/archives/systemd-commits/2014-June/006332.html

Having a SW install apply that systemd patch is a bad idea, as is expecting the user to do so.

Asking further,

	Q:
		In the case that one does NOT patch the existing systemd, does systemd safely, and preferably quietly,
fail in the presence of a missing Before=/Wants= dependency? 

	A:
		no idea, i would guess that if dont have the unit specified in Wants=, the service in question will simply
not run

	Q:
		that'd be true for mandatory Requires= ... but not for optional Wants= (?)

	A:
		true

I can't yet find an *authoritative* answer for how systemd fails by design if a specific Before=/Wnats=
dependency is non-existent.  It *sounds* like it should fail more-or-less gracefully.  If so,

	Before=network.target network-pre.target
	Wants=network.target network-pre.target

should be a safe approach -- for both current and future systemd versions.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
PGNd | 8 Oct 17:04 2014
Picon

SW 4.6.4+' systemd service files' Before=/After= dependency on 'network.target' -- should that be 'network-pre.target' and 'network-online.target'?

In current SW git sources, systemd service files assign dependency order with respect to the "network.target",

	cd ./code
	grep network `find . | grep service`                                
		./Shorewall-init/shorewall-init.service:Before=network.target
		./Shorewall6-lite/shorewall6-lite.service:After=network.target
		./Shorewall-lite/shorewall-lite.service:After=network.target
		./Shorewall/shorewall.service:After=network.target
		./Shorewall6/shorewall6.service:After=network.target

As I undertstand intent, shorewall-init.service is to start/exec before any network functionality is
up, and shorewall{,6}{,-lite}.service are to start after the network is up.

In the case of shorewall configs that have mandatory/required interface dependencies for multiple
interfaces, "after the network is up" needs to be after ALL of the interfaces are up.

The dependency on network.target, however, enables the parallelized start after network functionality
is 1st available -- i.e., after any/single interface is initialized.  If a multi-interface SW config to
fail, e.g., on 'isusble' tests ...

Reading  <at> 

	 <at>  http://www.freedesktop.org/software/systemd/man/systemd.special.html

there are *three* network-related targets,

	network-pre.target

		This passive target unit may be pulled in by services that want to run before any network is set up, for
example for the purpose of setting up a firewall. All network management software orders itself after
this target, but does not pull it in.

	network.target

		This unit is supposed to indicate when network functionality is available, but it is only very weakly
defined what that is supposed to mean, with one exception: at shutdown, a unit that is ordered after
network.target will be stopped before the network -- to whatever level it might be set up then -- is shut
down. It is hence useful when writing service files that require network access on shutdown, which should
order themselves after this target, but not pull it in. Also see Running Services After the Network is up
for more information. Also see network-online.target described above.

		systemd automatically adds dependencies of type After= for this target unit to all SysV init script
service units with an LSB header referring to the "$network" facility.

	network-online.target

		Units that strictly require a configured network connection should pull in network-online.target
(via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a
service that delays further execution until the network is sufficiently set up. What precisely this
requires is left to the implementation of the network managing service.

		Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by
the consumer rather than the provider of this functionality) and pulls in a service which possibly adds
substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in
by the provider of the functionality, rather than the consumer) that usually does not delay execution
much. Usually, network.target is part of the boot of most systems, while network-online.target is not,
except when at least one unit requires it. Also see Running Services After the Network is up for more information.

		All mount units for remote network file systems automatically pull in this unit, and order themselves
after it. Note that networking daemons that simply provide functionality to other hosts generally do not
need to pull this in.

With those definitions, and the need to correctly accommodate multi-interface SW configs, is it not more
appropriate to

		./Shorewall-init/shorewall-init.service
			...
-			Before=network.target
+			Before=network-pre.target
			...

where network-pre target was added to specifically deal with fw 'leaks',

	[systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
	http://lists.freedesktop.org/archives/systemd-devel/2014-June/019772.html

and

		./Shorewall/shorewall.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall-lite/shorewall-lite.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall6/shorewall6.service
			...
-			After=network.target
+			After=network-online.target
			...

		./Shorewall6-lite/shorewall6-lite.service
			...
-			After=network.target
+			After=network-online.target
			...

deal with the multi-interface use case

?

Locally, I'm currently using these changes -- in conjunction with additional fail2ban and openvpn
dependencies -- and they eliminate the  <at> boot SW startup failure due to missing/not-yet-initialized interfaces.

I do not yet know the issues this might cause, if any, with distro-packaging.

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
PGNd | 8 Oct 07:46 2014
Picon

SW upstream & distro pkgs specify different 'WantedBy=..." targets in default unit files. Rationale?

The systemd unit files provided by my current distro's (openSUSE) SW pkgs include

	/shorewall*.service
		...
		[Install]
		WantedBy=multi-user.target

The service files in SW upstream's source contain, instead,

	/shorewall*.service
		...
		[Install]
		WantedBy=basic.target

Not sure yet what other distros are using.

Given the systemd docs at

	http://www.freedesktop.org/software/systemd/man/systemd.special.html

the reason for the different choice in the two SW unit files is unclear.

Reading at

	[systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
	http://lists.freedesktop.org/archives/systemd-devel/2014-June/019908.html 

		"...
		Before=basic.target means lots of totally unrelated units can't be > started in parallel to the firewall.
		..."

seems to indicate that there's a tradeoff between systemd simplicity and parallelization.  Not sure if
that's relevant here.

What's the current rationale/preference for using  

	WantedBy=multi-user.target

vs

	WantedBy=basic.target

?

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
PGNd | 5 Oct 02:01 2014
Picon

install of tarball's shorewall-lite FAILs if shorewall(-lite) prerequisite is not 1st installed

cd /usr/local/src/shorewall-TARBALLS/
rm -rf /usr/local/shorewall-custom
cd  ./shorewall-core-4.6.4-Beta2-34-ge36b34c/
./install.sh shorewallrc.suse
cd ../shorewall-init-4.6.4-Beta2-34-ge36b34c/
sh -x ./install.sh shorewallrc.suse
	+ echo 'Installing Shorewall Init Version 4.6.4-Beta2-34-ge36b34c'
	Installing Shorewall Init Version 4.6.4-Beta2-34-ge36b34c
	+ '[' -f /usr/local/shorewall-custom/share/shorewall-init/version ']'
	+ first_install=Yes
	+ '[' -n '' ']'
	+ '[' -n shorewall-init ']'
	+ install_file init.suse.sh /usr/local/shorewall-custom/etc/init.d/shorewall-init 0544
	+ run_install -T -o root -g root -m 0544 init.suse.sh /usr/local/shorewall-custom/etc/init.d/shorewall-init
	+ install -T -o root -g root -m 0544 init.suse.sh /usr/local/shorewall-custom/etc/init.d/shorewall-init
	install: cannot create regular file
‘/usr/local/shorewall-custom/etc/init.d/shorewall-init’: No such file or directory
	+ echo

	+ echo 'ERROR: Failed to install -T -o root -g root -m 0544 init.suse.sh /usr/local/shorewall-custom/etc/init.d/shorewall-init'
	ERROR: Failed to install -T -o root -g root -m 0544 init.suse.sh /usr/local/shorewall-custom/etc/init.d/shorewall-init
	+ exit 1

cd ../shorewall-lite-4.6.4-Beta2-34-ge36b34c/
./install.sh shorewallrc.suse
cd ../shorewall-init-4.6.4-Beta2-34-ge36b34c/
./install.sh shorewallrc.suse
	Installing SuSE-specific configuration...
	Installing Shorewall Init Version 4.6.4-Beta2-34-ge36b34c
	SysV init script init.suse.sh installed in /usr/local/shorewall-custom/etc/init.d/shorewall-init
	Service file shorewall-init.service installed as /usr/local/shorewall-custom/etc/systemd/shorewall-init.service
	CLI installed as /usr/local/shorewall-custom/usr/sbin/shorewall-init
	sysconfig installed in /usr/local/shorewall-custom/etc/sysconfig/shorewall-init
	shorewall Init Version 4.6.4-Beta2-34-ge36b34c Installed

if shorewall(-lite) is a prereq, then perhaps the install.sh's ERROR could be handled more cleanly --
checking for the prereq, and failing gracefully with an informative notification

alternative is to have the -init install handle it's own creation of missing file/directory 

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
Shorewall-users <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
PGNd | 5 Oct 01:34 2014
Picon

checking dependency of -lite products on 'full' products

When installing tarball builds on a remote, the installer seems perfectly happy to install ONLY the

	shorewall-core shorewall-lite shorewall6-lite shorewall-init

products.

Nothing in the installer output that I've noticed, nor any output of cursory checks of

	shorewall-lite version

etc, indicate that the 'full' shorewall/shorewall6 must be installed.

I've noticed, at least on openSUSE, that distro packaging does require prerequisites of

	shorewall shorewall6

to successfully install

	shorewall-lite shorewall6-lite

What's actually the design-intended dependency set by upstream SW?

Does any part of a remote-only install -- products = shorewall-core shorewall-lite shorewall6-lite
shorewall-init -- require the install of the full products as well?

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

Gmane