holm/shorewall_code
1
0
Fork 0
forked from extern/shorewall_code
Code Pull Requests Activity

Process config options in file order during update.

Browse Source 
Signed-off-by: Tom Eastep <teastep@shorewall.net>
This commit is contained in:
Tom Eastep 2017-03-12 09:01:22 -07:00
parent b13014c9ab
commit a8d7675322
No known key found for this signature in database
GPG Key ID: 96E6B3F2423A4D10
2 changed files with 21 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Shorewall/Perl/Shorewall/Config.pm
View File

@ -5432,6 +5432,7 @@ EOF
sub process_shorewall_conf( $$ ) {
my ( $update, $annotate ) = @_;
my $file = find_file "$product.conf";
my @vars;
if ( -f $file ) {
$globals{CONFIGDIR} = $configfile = $file;
@ -5448,7 +5449,11 @@ sub process_shorewall_conf( $$ ) {
if ( $currentline =~ /^\s*([a-zA-Z]\w*)=(.*)$/ ) {
my ($var, $val) = ($1, $2);
expand_variables( $val ) unless $update || $val =~ /^'.*'$/;
if ( $update ) {
push @vars, $var;
} else {
expand_variables( $val ) unless $val =~ /^'.*'$/;
}
if ( exists $config{$var} ) {
if ( $eliminated{$var} && ! $update ) {
@ -5493,19 +5498,12 @@ sub process_shorewall_conf( $$ ) {
# Config file update requires that the option values not have
# Shell variables expanded. We do that now.
#
# We must first make LOG_LEVEL a variable because the order in which
# the values are processed below is not the order in which they appear
# in the config file.
# To handle options like LOG_LEVEL, we process the options
# in the order in which they appear in the .conf file.
#
$config{LOG_LEVEL} = '' unless defined $config{LOG_LEVEL};
my %log_level = ( LOG_LEVEL => $config{LOG_LEVEL} );
add_variables( %log_level );
for ( values %config ) {
if ( supplied $_ ) {
expand_variables( $_ ) unless /^'.*'$/;
for ( @vars ) {
if ( supplied( my $val = $config{$_} ) ) {
expand_variables( $config{$_} ) unless $val =~ /^'.*'$/;
}
}
}

21
docs/KVM.xml
View File

@ -50,7 +50,7 @@
Linux Distributions. The following diagram shows the entire
network.</para>
<graphic align="center" fileref="images/Network2008a.png" />
<graphic align="center" fileref="images/Network2008a.png"/>
<para>My personal laptop (Ursa) hosts the virtual machines. As shown in
the diagram, Ursa has routes to the Internet through both the
@ -66,12 +66,12 @@
<section>
<title>Networking Configuration</title>
<para>I use a network configuration where each VM has its own VNET and
tap device and the tap devices are all configured as ports on a Linux
Bridge. For clarity, I've only shown four of the virtual machines
available on the system.</para>
<para>I use a network configuration where each VM has its own VNET and tap
device and the tap devices are all configured as ports on a Linux Bridge.
For clarity, I've only shown four of the virtual machines available on the
system.</para>
<graphic align="center" fileref="images/KVM1.png" />
<graphic align="center" fileref="images/KVM1.png"/>
<para>I run <ulink url="???">dmsmasq</ulink> to act as a DHCP server and
name server for the VMs.</para>
@ -82,11 +82,10 @@
<para>With this configuration, and with only a single network interface on
the laptop, this is just a simple <ulink
url="two-interface.html">two-interface masquerading setup</ulink> where
the local network interface is <filename
class="devicefile">br0</filename>. As with all bridges, <filename
class="devicefile">br0</filename> must be configured with the
<option>routeback</option> option in <ulink
url="two-interface.htm">two-interface masquerading setup</ulink> where the
local network interface is <filename class="devicefile">br0</filename>. As
with all bridges, <filename class="devicefile">br0</filename> must be
configured with the <option>routeback</option> option in <ulink
url="manpages/shorewall-interfaces.html">shorewall-interfaces</ulink>(5).</para>
<para>For additional information about this setup, including the Shorewall