> + g_confdir=/etc/shorewall-lite
> + g_product="Shorewall Lite"
> + g_program=shorewall-lite
> + g_basedir=/usr/share/shorewall-lite
> + CONFIG_PATH="/etc/shorewall-lite:/usr/share/shorewall-lite"
> + [ -n "${VARDIR:=/var/lib/shorewall-lite}" ]
Exactly!
Why is g_confdir hard-coded and not set as ${CONFDIR}/shorewall-lite? Why is
g_basedir also hard-coded and not set as ${SHAREDIR}/shorewall-lite? Finally,
since VARDIR is not set yet, it would also be hard-coded to
/var/lib/shorewall-lite.
This is what I have in my "compile" make target for shorewall-lite:
# Contains one hell of an ugly hack!
compile:
@echo "Compiling shorewall and building '$(FIREWALL_FILE)' and
'$(FIREWALL_CONFIG_FILE)'"
@shorewall compile -T -p -e . $(FIREWALL_FILE)
&>>$(SCREEN_OUTPUT_FILE_NAME)
@sed -i "s:g_family=4:g_family=4\n\t. $(SHOREWALLRC):" $(FIREWALL_FILE)
&>>$(SCREEN_OUTPUT_FILE_NAME)
@sed -i
"s:g_confdir=/etc/shorewall-lite:g_confdir=\$${CONFDIR}/shorewall-lite:"
$(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME)
@sed -i
"s:g_basedir=/usr/share/shorewall-lite:g_basedir=\$${SHAREDIR}/shorewall-lite:"
$(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME)
@sed -i
"s/CONFIG_PATH=\"\/etc\/shorewall-lite:\/usr\/share\/shorewall-lite\"//"
$(FIREWALL_FILE) &>>$(SCREEN_OUTPUT_FILE_NAME)
As you can see from the above, I source shorewallrc first and then set the
appropriate directories. This isn't done in shorewall-lite's "firewall" script,
at least not in version 4.5.6 which is what I am using.
> The PATH variable is set in the same area as the differences shown
> above. It is set from the value in the .conf.
lib.cli:3106: PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
>
>>> If shorewall was honouring the path variables as I specified in my
>>> shorewall.conf file, it would have executed *my* version of
>>> modprobe (which, incidentally, was in /opt/sbin and compiled
>>> *specifically* to look for kernel modules in
>>> /opt/lib/modules/<kernel-version>, together with the correct
>>> modules.dep), thus avoiding the problem I described above.
>>>
>
> Which could have been accomplished using the MODULESDIR option in
> shorewall.conf.
Except that it won't. It would have executed the busybox modprobe with my own
(new) kernel modules directory, which would also fail. I want to execute *my*
modprobe with *my* kernel modules directory. WHen the PATH is hard-coded it is
hard to do that.
>>>> I really should deprecate the 'try' command as it duplicates the
>>>> functionality of the 'safe-start' and 'safe-restart' commands.
>>> Are they the same? What I like about "try" is that it starts the
>>> firewall regardless of the state it was in (perfect when I don't
>>> care what that state was). Can I achieve the same with safe-start
>>> then?
>
> You can achieve the same thing with safe-restart and with just plain
> restart.
So, restart will start shorewall even if it has not been started? That's good
if so.
>
>>> OK, let me explain my use case.
>
> Okay -- for Shorewall and Shorewall6, I can compile the script if it
> doesn't exist.
You mean shorewall-init? Please explain.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
