When PERLLIBDIR=/path/to/sw-perl-mods/ is configured for a SW build, the
install's perl5 mods are installed, as expected, in "/path/to/sw-perl-mods/".
If PERLLIBDIR is NOT in the installed perl's @INC, it can be trivially added to
@INC's head in global ENV with
~/.bashrc
+ export PERL5LIB="/path/to/sw-perl-mods/"
or, limited to context of SW's (s)bins by prepending SW commands
PERL5LIB="/path/to/sw-perl-mods/" shorewall ...
IIUC, neither may be necessary.
Looking @
./share/shorewall/lib.cli-std
...
if [ ${PERLLIBDIR} = ${LIBEXECDIR}/shorewall ]; then
$PERL $debugflags $pc $options $@
else
PERL5LIB=${PERLLIBDIR}
export PERL5LIB
$PERL $debugflags $pc $options $@
fi
...
that stanza appears to functionally prepend all user-land exec of SW (s)bins
with PERL5LIB=${PERLLIBDIR}, the perl-mod dir-path config'd at build time.
Is that correct?
If so, does that also hold true for the daemon as launched in a systemd unit,
with no "Environment=PERL5LIB=/path/to/sw-perl-mods/" required?
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
