On 06/11/2018 16:56, Tom Eastep wrote:
Shouldn't all options accepting a "[directory]" argument set the
internal "${g_confdir}" variable to the specified directory?
No. Specifying a directory simply pushes that directory onto the front
of the CONFIG_PATH.
So basically I have no mean to include files in a deterministic way
relative to a custom configuration directory while ensuring that I'm
really including the files I want instead of those possibly already
existing in the hardcoded /etc/shorewall path :-(
I deal with some complex rulesets on servers installed in datacenters so
I really need to test Shorewall's configuration before applying them,
especially when migrating to new versions ("masq" vs "snat" for example).
My "rules" file looked like this :
for i in $( ls -1 "${g_confdir}/rules.d"/*.conf ) ; do
[ -r "$i" ] && . "$i"
done
and this allowed me to do the following : (at least I thought)
Shell# shorewall -v2 compile ~/sw_new ~/sw_new.firewall
but of course, this fails as Shorewall solely knows the hardcoded
/etc/shorewall directory for ${g_confdir} :-(
If you don't plan to provide some kind of way (a new env var perhaps?)
to know for sure Shorewall is using a custom directory for
configuration, please tell me and I'll craft something on my own to
circumvent this shortcoming.
I definitely can not blindly apply rules to a heavily modified
configuration without thorough testing first, especially on a machine I
can't reach, I'm sure you'll understand :-)
So, to get things straight : In the current state, outside of a FLAT
configuration directory (ie: no includes in any files relative to that
directory), all Shorewall commands accepting a "[directory]" option (ie:
ck, compile, export, etc.) can not work properly.
--
ObNox
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
