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
------------------------------------------------------------------------------
(Continue reading)

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.
(Continue reading)

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
PGNd | 3 Oct 21:24 2014
Picon

./isntall.sh in /shorewall-init fails 1st time through; succeeds 2nd time

missed this one earlier :=/

installing from tarballs

	rm -rf /usr/local/shorewall-custom

	cd ./shorewall-core-4.6.4-Beta2-22-g8a5e71a
	./install.sh shorewallrc.suse

	cd ../shorewall-4.6.4-Beta2-22-g8a5e71a
	./install.sh -n shorewallrc.suse 

	cd ../shorewall-init-4.6.4-Beta2-22-g8a5e71a
	mkdir -p /usr/local/shorewall-custom/etc/sysconfig/network/if-{up,down}.d/

a FIRST install of shorewall-init fails

	./install.sh -n shorewallrc.suse 
		Installing SuSE-specific configuration...
		Installing Shorewall Init Version 4.6.4-Beta2-22-g8a5e71a
		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
!!!		Failed to execute operation: No such file or directory
		shorewall Init Version 4.6.4-Beta2-22-g8a5e71a Installed

but an IMMEDIATE re-attempt succeeds

	./install.sh -n shorewallrc.suse 
		Installing SuSE-specific configuration...
		Installing Shorewall Init Version 4.6.4-Beta2-22-g8a5e71a
		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
		shorewall Init Version 4.6.4-Beta2-22-g8a5e71a Installed

where,

	tree -xC /usr/local/shorewall-custom/etc/sysconfig
		/usr/local/shorewall-custom/etc/sysconfig
		├── network
		│   ├── if-down.d
		│   │   └── shorewall
		│   └── if-up.d
		│       └── shorewall
		└── shorewall-init

------------------------------------------------------------------------------
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 | 3 Oct 15:35 2014
Picon

tarball's ./install.sh installs bins with incorrect paths, ignores shorewallrc's DESTDIR=

starting from an extracted tarball build's dir

	cd shorewall-lite-4.6.4-Beta2-19-g205dd6e/

with

	cat shorewall-core-4.6.4-Beta2-19-g205dd6e/shorewallrc.suse
		HOST=suse
		PREFIX=/usr
		SHAREDIR=${PREFIX}/share
		LIBEXECDIR=${PREFIX}/lib
		PERLLIBDIR=${PREFIX}/lib/perl5
		CONFDIR=/etc
		SBINDIR=/usr/sbin
		MANDIR=${PREFIX}/man/
		INITDIR=/etc/init.d
		INITSOURCE=init.suse.sh
		INITFILE=${PRODUCT}
		AUXINITSOURCE=
		AUXINITFILE=
		SYSTEMD=/etc/systemd
		SERVICEFILE=${PRODUCT}.service
		SYSCONFFILE=sysconfig
		SYSCONFDIR=/etc/sysconfig
		SPARSE=
		ANNOTATED=
		VARLIB=/var/lib
		VARDIR=${VARLIB}/${PRODUCT}
		DESTDIR=/usr/local/shorewall-custom

cleaning

	rm -rf /usr/local/shorewall-custom

installing with specific rc target

	./install.sh shorewallrc.suse

populates correctly

	tree -dxC /usr/local/shorewall-custom
		/usr/local/shorewall-custom
		├── etc
		│   ├── init.d
		│   ├── logrotate.d
		│   ├── shorewall
		│   ├── shorewall6
		│   ├── shorewall6-lite
		│   ├── shorewall-lite
		│   ├── sysconfig
		│   │   └── network
		│   │       ├── if-down.d
		│   │       └── if-up.d
		│   └── systemd
		├── usr
		│   ├── lib
		│   │   ├── perl5
		│   │   │   └── Shorewall
		│   │   ├── shorewall
		│   │   ├── shorewall6
		│   │   ├── shorewall6-lite
		│   │   ├── shorewall-init
		│   │   └── shorewall-lite
		│   ├── man
		│   │   ├── man5
		│   │   └── man8
		│   ├── sbin
		│   └── share
		│       ├── man
		│       │   ├── man5
		│       │   └── man8
		│       ├── shorewall
		│       │   ├── configfiles
		│       │   └── Shorewall
		│       ├── shorewall6
		│       │   └── configfiles
		│       ├── shorewall6-lite
		│       ├── shorewall-init
		│       └── shorewall-lite
		└── var
		    └── lib
		        ├── shorewall
		        ├── shorewall6
		        ├── shorewall6-lite
		        └── shorewall-lite

bin exists

	ls -al /usr/local/shorewall-custom/usr/sbin/shorewall-lite
		-r-xr--r-- 1 root root 1.5K Oct  3 06:05 /usr/local/shorewall-custom/usr/sbin/shorewall-lite*

checking

	/usr/local/shorewall-custom/usr/sbin/shorewall-lite version
		4.6.3.4

reports INCORRECT version.  That's the *system*-installed version, not THIS just-installed version

checking

	cat /usr/local/shorewall-custom/usr/sbin/shorewall-lite
		...
		PRODUCT=shorewall-lite

		#
		# This is modified by the installer when ${SHAREDIR} != /usr/share
		#
		. /usr/share/shorewall/shorewallrc

		g_program=$PRODUCT
		g_sharedir="$SHAREDIR"/shorewall-lite
		g_confdir="$CONFDIR"/shorewall-lite
		g_readrc=1

		. ${SHAREDIR}/shorewall/lib.cli

		shorewall_cli $ <at> 

paths should be (?) relative to the executable, as specified in the correct shorewallrc with DESTDIR= set

e.g.,

	vi /usr/local/shorewall-custom/usr/sbin/shorewall-lite
		...
		PRODUCT=shorewall-lite

		#
		# This is modified by the installer when ${SHAREDIR} != /usr/share
		#
-		. /usr/share/shorewall/shorewallrc
+		. ./usr/share/shorewall/shorewallrc

		g_program=$PRODUCT
-		g_sharedir="$SHAREDIR"/shorewall-lite
-		g_confdir="$CONFDIR"/shorewall-lite
+		g_sharedir="${DESTDIR}/$SHAREDIR"/shorewall-lite
+		g_confdir="${DESTDIR}/$CONFDIR"/shorewall-lite
		g_readrc=1

-		. ${SHAREDIR}/shorewall/lib.cli
+		. ${DESTDIR}/${SHAREDIR}/shorewall/lib.cli

		shorewall_cli $ <at> 

now, correctly

	/usr/local/shorewall-custom/usr/sbin/shorewall-lite version
		4.6.4-Beta2-19-g205dd6e

true for, at least, all installed /usr/local/shorewall-custom/usr/sbin/shorewall-*

only currently an issue if DESTDIR=, the 'preferred' method of location-targeted install, is used

not a problem if, instead, ${PREFIX} etc in build-time shorewallrc* is hard-coded, per prior discussion

also,

		g_confdir="${DESTDIR}/$CONFDIR"/shorewall-lite

may NOT be (?) correct/sufficient -- as the used config file/dir needs to be override-able from shell cmd
line, within systemd service file, etc.

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

Gmane