Merge branch '4.5.8'

Shorewall-core/install.sh

@@ -164,11 +164,15 @@ else
     usage 1
 fi
 
+update=0
+
 if [ -z "${VARLIB}" ]; then
     VARLIB=${VARDIR}
     VARDIR="${VARLIB}/${PRODUCT}"
+    update=1
 elif [ -z "${VARDIR}" ]; then
     VARDIR="${VARLIB}/${PRODUCT}"
+    update=2
 fi
 
 for var in SHAREDIR LIBEXECDIR PERLLIBDIR CONFDIR SBINDIR VARLIB VARDIR; do
@@ -353,9 +357,25 @@ ln -sf lib.base ${DESTDIR}${SHAREDIR}/shorewall/functions
 echo "$VERSION" > ${DESTDIR}${SHAREDIR}/shorewall/coreversion
 chmod 644 ${DESTDIR}${SHAREDIR}/shorewall/coreversion
 
-[ $file != "${SHAREDIR}/shorewall/shorewallrc" ] && cp $file ${DESTDIR}${SHAREDIR}/shorewall/shorewallrc
+if [ -z "${DESTDIR}" ]; then
+    if [ $update -ne 0 ]; then
+	echo "Updating $file - original saved in $file.bak"
 
-[ -z "${DESTDIR}" ] && [ ! -f ~/.shorewallrc ] && cp ${SHAREDIR}/shorewall/shorewallrc ~/.shorewallrc
+	cp $file $file.bak
+
+	echo '#'                                             >> $file
+	echo "# Updated by Shorewall-core $VERSION -" `date` >> $file
+	echo '#'                                             >> $file
+
+	[ $update -eq 1 ] && sed -i 's/VARDIR/VARLIB/' $file
+
+	echo 'VARDIR=${VARLIB}/${PRODUCT}' >> $file
+    fi
+
+    [ ! -f ~/.shorewallrc ] && cp ${SHAREDIR}/shorewall/shorewallrc ~/.shorewallrc
+fi
+
+[ $file != "${DESTDIR}${SHAREDIR}/shorewall/shorewallrc" ] && cp $file ${DESTDIR}${SHAREDIR}/shorewall/shorewallrc
 
 if [ ${SHAREDIR} != /usr/share ]; then
     for f in lib.*; do

Shorewall-init/init.fedora.sh

@@ -136,14 +136,10 @@ case "$1" in
 	status_q || exit 0
 	$1
 	;;
-    restart|reload|force-reload)
+    restart|reload|force-reload|condrestart|try-restart)
 	echo "Not implemented"
 	exit 3
 	;;
-    condrestart|try-restart)
-	echo "Not implemented"
-	exit 3
-        ;;
     status)
 	status $prog
 	;;

Shorewall/Perl/Shorewall/Chains.pm

@@ -4326,7 +4326,7 @@ sub do_user( $ ) {
 
     require_capability 'OWNER_MATCH', 'A non-empty USER column', 's';
 
-    assert ( $user =~ /^(!)?(.*?)(:(.*))?$/ );
+    assert( $user =~ /^(!)?(.*?)(:(.+))?$/ );
     my $invert = $1 ? '! ' : '';
     my $group  = supplied $4 ? $4 : '';
 

Shorewall/Perl/Shorewall/Compiler.pm

@@ -34,7 +34,6 @@ use Shorewall::Accounting;
 use Shorewall::Rules;
 use Shorewall::Proc;
 use Shorewall::Proxyarp;
-use Shorewall::IPAddrs;
 use Shorewall::Raw;
 use Shorewall::Misc;
 

Shorewall/Perl/Shorewall/Config.pm

@@ -174,7 +174,7 @@ our %EXPORT_TAGS = ( internal => [ qw( create_temp_script
 				       CONFIG_CONTINUATION
 				       DO_INCLUDE
 				       NORMAL_READ
-				     ) ] ,
+				     ) , ] ,
 		   protocols => [ qw (
 				       TCP
 				       UDP
@@ -184,7 +184,7 @@ our %EXPORT_TAGS = ( internal => [ qw( create_temp_script
 				       IPv6_ICMP
 				       SCTP
 				       GRE
-				    ) ],
+				    ) , ],
 		   );
 
 Exporter::export_ok_tags('internal');

Shorewall/Perl/Shorewall/Tc.pm

@@ -983,7 +983,7 @@ sub validate_tc_device( ) {
 			    mtu           => $mtu,
 			    mpu           => $mpu,
 			    tsize         => $tsize,
-			    filterpri     => 1,
+			    filterpri     => 0,
 			  } ,
 
     push @tcdevices, $device;
@@ -1425,11 +1425,11 @@ sub process_tc_filter() {
     my ( $prio, $filterpri ) = ( undef, $devref->{filterpri} );
 
     if ( $priority eq '-' ) {
-	$prio = $filterpri++;
+	$prio = ++$filterpri;
 	fatal_error "Filter priority overflow" if $prio > 65535;
     } else {
 	$prio = validate_filter_priority( $priority, 'filter' );
-	$filterpri = $prio + 1 if $prio >= $filterpri;
+	$filterpri = $prio if $prio > $filterpri;
     }
 
     $devref->{filterpri} = $filterpri;

Shorewall/Perl/getparams

@@ -25,12 +25,12 @@
 #
 #      $1 = Path name of params file
 #      $2 = $CONFIG_PATH
-#      $3 = Address family (4 o4 6)
+#      $3 = Address family (4 or 6)
 #
 if [ "$3" = 6 ]; then
-    g_program=shorewall6
+    PRODUCT=shorewall6
 else
-    g_program=shorewall
+    PRODUCT=shorewall
 fi
 
 #
@@ -38,11 +38,12 @@ fi
 #
 . /usr/share/shorewall/shorewallrc
 
+g_program=$PRODUCT
 g_libexec="$LIBEXECDIR"
-g_sharedir="$SHAREDIR"/shorewall
+g_sharedir="$SHAREDIR/shorewall"
 g_sbindir="$SBINDIR"
 g_perllib="$PERLLIBDIR"
-g_confdir="$CONFDIR"/shorewall
+g_confdir="$CONFDIR/$PRODUCT"
 g_readrc=1
 
 . $g_sharedir/lib.cli

Shorewall/manpages/shorewall-tcfilters.xml

@@ -205,22 +205,21 @@
 
           <itemizedlist>
             <listitem>
-              <para>For Shorewall versions prior to 4.5.8, all filters have
+              <para>For Shorewall versions prior to 4.5.8 - all filters have
               priority 10.</para>
             </listitem>
 
             <listitem>
-              <para>For Shorewall 4.5.8 and later, the compiler maintains a
-              <firstterm>high-water priority</firstterm> that has an initial
-              value of 1. When a filter has no
+              <para>For Shorewall 4.5.8 and later - for each device, the
+              compiler maintains a <firstterm>high-water priority</firstterm>
+              with an initial value of 0. When a filter has no
               <replaceable>priority</replaceable>, the high-water priority is
-              assigned to the filter and the high-wanter priority is
-              incremented by 1. When a <replaceable>priority</replaceable>
-              greater than or equal than the high-water priority is entered in
-              this column, the high-water priority is set to the specified
-              <replaceable>priority</replaceable> plus 1. An attempt to assign
-              a priority value greater than 65535 (explicitly or implicitly),
-              an error is raised.</para>
+              incremented by 1 and assigned to the filter. When a
+              <replaceable>priority</replaceable> greater than the high-water
+              priority is entered in this column, the high-water priority is
+              set to the specified <replaceable>priority</replaceable>. An
+              attempt to assign a priority value greater than 65535
+              (explicitly or implicitly) raises an error.</para>
             </listitem>
           </itemizedlist>
 

Shorewall6/manpages/shorewall6-tcfilters.xml

@@ -199,22 +199,21 @@
 
           <itemizedlist>
             <listitem>
-              <para>For Shorewall versions prior to 4.5.8, all filters have
+              <para>For Shorewall versions prior to 4.5.8 - all filters have
               priority 11.</para>
             </listitem>
 
             <listitem>
-              <para>For Shorewall 4.5.8 and later, the compiler maintains a
-              <firstterm>high-water priority</firstterm> that has an initial
-              value of 1. When a filter has no
+              <para>For Shorewall 4.5.8 and later - for each device, the
+              compiler maintains a <firstterm>high-water priority</firstterm>
+              with an initial value of 0. When a filter has no
               <replaceable>priority</replaceable>, the high-water priority is
-              assigned to the filter and the high-wanter priority is
-              incremented by 1. When a <replaceable>priority</replaceable>
-              greater than or equal than the high-water priority is entered in
-              this column, the high-water priority is set to the specified
-              <replaceable>priority</replaceable> plus 1. An attempt to assign
-              a priority value greater than 65535 (explicitly or implicitly),
-              an error is raised.</para>
+              incremented by 1 and assigned to the filter. When a
+              <replaceable>priority</replaceable> greater than the high-water
+              priority is entered in this column, the high-water priority is
+              set to the specified <replaceable>priority</replaceable>. An
+              attempt to assign a priority value greater than 65535
+              (explicitly or implicitly) raises an error.</para>
             </listitem>
           </itemizedlist>
 

docs/Internals.xml

@@ -40,13 +40,439 @@
     <para>This document provides an overview of Shorewall internals. It is
     intended to ease the task of approaching the Shorewall code base by
     providing a roadmap of what you will find there.</para>
+
+    <section>
+      <title>History</title>
+
+      <para>Shorewall was originally written entirely in Bourne Shell. The
+      chief advantage of this approach was that virtually any platform
+      supports the shell, including small embedded environments. The initial
+      release was in early 2001. This version ran iptables, ip, etc.
+      immediately after processing the corresponding configuration entry. If
+      an error was encountered, the firewall was stopped. For this reason, the
+      <filename>routestopped</filename> file had to be very simple and
+      foolproof.</para>
+
+      <para>In Shorewall 3.2.0 (July 2006), the implementation was changed to
+      use the current compile-then-execute architecture. This was
+      accompilished by modifying the existing code rather than writing a
+      compiler/generator from scratch. The resulting code was fragile and hard
+      to maintain. 3.2.0 also marked the introduction of
+      Shorewall-lite.</para>
+
+      <para>By 2007, the compiler had become unmaintainable and needed to be
+      rewritten. I made the decision to write the compiler in Perl and
+      released it as a separate Shorewall-perl packets in Shorewall 4.0.0
+      (July 2007). The shell-based compiler was packaged in a Shorewall-shell
+      package. An option (SHOREWALL_COMPILER) in shorewall.conf specified
+      which compiler to use. The Perl-based compiler was siginificantly
+      faster, and the compiled script also ran much faster thanks to its use
+      of iptables-restore.</para>
+
+      <para>Shorewall6 was introduced in Shorewall 4.2.4 (December
+      2008).</para>
+
+      <para>Support for the old Shell-based compiler was eliminated in
+      Shorewall 4.4.0 (July 2009).</para>
+
+      <para>Shorewall 4.5.0 (February 2012) marked the introduction of the
+      current architecture and packaging.</para>
+    </section>
+
+    <section>
+      <title>Architecture</title>
+
+      <para>The components of the Shorewall product suite fall into five broad
+      categories:</para>
+
+      <orderedlist>
+        <listitem>
+          <para>Build/Install subsystem</para>
+        </listitem>
+      </orderedlist>
+
+      <orderedlist>
+        <listitem>
+          <para>Command Line Interface (CLI)</para>
+        </listitem>
+
+        <listitem>
+          <para>Run-time Libraries</para>
+        </listitem>
+
+        <listitem>
+          <para>Compiler</para>
+        </listitem>
+
+        <listitem>
+          <para>Configuration files (including actions and macros)</para>
+        </listitem>
+      </orderedlist>
+
+      <section>
+        <title>Build/Install Subsystem</title>
+
+        <para>The Shorewall Build/Install subsystem packages the products for
+        release and installs them on an end-user's or a packager's system. It
+        is diagrammed in the following graphic.</para>
+
+        <graphic fileref="images/BuildInstall.png" />
+
+        <para>The build environment components are not released and are
+        discussed in the <ulink url="Build.html">Shorewall Build
+        Article</ulink>.</para>
+
+        <para>The end-user/packager environment consists of the
+        <filename>configure</filename> and <filename>configure.pl</filename>
+        programs in Shorewall-core and an <filename>install.sh</filename>
+        program in each product.</para>
+      </section>
+
+      <section>
+        <title>CLI</title>
+
+        <para>The CLI is written entirely in Bourne Shell so as to allow it to
+        run on small embedded systems within the -lite products. The CLI
+        programs themselves are very small; then set global variables then
+        call into the CLI libraries. Here's an example
+        (/sbin/shorewall):</para>
+
+        <programlisting>PRODUCT=shorewall
+
+#
+# This is modified by the installer when ${SHAREDIR} != /usr/share
+#
+. /usr/share/shorewall/shorewallrc
+
+g_program=$PRODUCT
+g_libexec="$LIBEXECDIR"
+g_sharedir="$SHAREDIR"/shorewall
+g_sbindir="$SBINDIR"
+g_perllib="$PERLLIBDIR"
+g_confdir="$CONFDIR"/shorewall
+g_readrc=1
+
+. $g_sharedir/lib.cli
+
+shorewall_cli $@</programlisting>
+
+        <para>As you can see, it sets the PRODUCT variable, loads the
+        shorewallrc file, sets the global variables (all of which have names
+        beginning with "g_", loads <filename>lib.cli</filename>, and calls
+        shorewall_cli passing its own arguments.</para>
+
+        <para>There are two CLI libraries: <filename>lib.cli</filename> in
+        Shorewall Core and <filename>lib.cli-std </filename>in Shorewall. The
+        <filename>lib.cli</filename> library is always loaded by the CLI
+        programs; <filename>lib-cli-std</filename> is also loaded when the
+        product is 'shorewall' or 'shorewall6'.
+        <filename>lib.cli-std</filename> overloads some functions in
+        <filename>lib.cli</filename> and also provides logic for the
+        additional commands supported by the full products.</para>
+
+        <para>The CLI libraries load two additional Shell libraries from
+        Shorewall.core: <filename>lib.base</filename> and
+        <filename>lib.common</filename> (actually,
+        <filename>lib.base</filename> loads <filename>lib.common</filename>).
+        These libraries are separete from <filename>lib.cli</filename> for
+        both historical and practicle reasons. <filename>lib.base</filename>
+        (aka functions) can be loaded by application programs, although this
+        was more common in the early years of Shorewall. In addition to being
+        loaded by the CLIs, <filename>lib.common</filename> is also copied
+        into the generated script by the compilers.</para>
+      </section>
+
+      <section>
+        <title>Run-time Libraries</title>
+
+        <para>Thare are two libraries that are copied into the generated
+        script by the compiler: <filename>lib.common</filename> from
+        Shorewall-core and <filename>lib.core</filename> from Shorewall. The
+        "outer block" of the generated script comes from the Shorewall file
+        <filename>prog.footer</filename>.</para>
+      </section>
+
+      <section id="Compiler">
+        <title>Compiler</title>
+
+        <para>With the exception of the <filename>getparams</filename> Shell
+        program, the compiler is written in Perl. The compiler main program is
+        compiler.pl from Shorewall.conf; it's run-line arguments are described
+        in the <ulink url="Shorewall-perl.html%23compiler.pl">Shorewall Perl
+        Article</ulink>. It is invoked by the <emphasis>compiler</emphasis>
+        function in <filename>lib.cli-std</filename>.</para>
+
+        <para>The compiler is modularized as follows:</para>
+
+        <itemizedlist>
+          <listitem>
+            <para><filename>Accounting.pm</filename> (Shorewall::Accounting).
+            Processes the <filename>accounting</filename> file.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Chains.pm</filename> (Shorewall::Chains). This is
+            the module that provides an interface to iptables/Netfilter for
+            the other modules. The optimizer is included in this
+            module.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Config.pm</filename> (Shorewall::Config). This is
+            a multi-purpose module that supplies several related
+            services:</para>
+
+            <itemizedlist>
+              <listitem>
+                <para>Error and Progress message production.</para>
+              </listitem>
+
+              <listitem>
+                <para>Pre-processor. Supplies all configuration file handling
+                including variable expansion, ?IF...?ELSE...?ENDIF processing,
+                INCLUDE directives and embedded Shell and Perl.</para>
+              </listitem>
+
+              <listitem>
+                <para>Output script file creation with functions to write into
+                the script. The latter functions are no-ops when the
+                <command>check</command> command is being executed.</para>
+              </listitem>
+
+              <listitem>
+                <para>Capability Detection</para>
+              </listitem>
+            </itemizedlist>
+          </listitem>
+
+          <listitem>
+            <para><filename>Compiler.pm</filename> (Shorewall::Compiler). The
+            compiler() function in this module contains the top-leve of the
+            compiler.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>IPAddrs.pm</filename> (Shorewall::IPAddrs) - IP
+            Address validation and manipulation (both IPv4 and IPv6). Also
+            interfaces to NSS for protocol/service name resolution.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Misc.pm</filename> (Shorewall::Misc) - Provides
+            services that don't fit well into the other modules.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Nat.pm</filename> (Shorewall::Nat) - Handles all
+            nat table rules. Processes the <filename>masq</filename>,
+            <filename>nat</filename> and <filename>netmap</filename>
+            files.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Proc.pm</filename> (Shorewall::Proc) - Handles
+            manipulation of <filename>/proc/sys/</filename>.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Providers.pm</filename> (Shorewall::Providers) -
+            Handles policy routing; processes the
+            <filename>providers</filename> file.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Proxyarp.pm</filename> (Shorewall::Proxyarp) -
+            Processes the <filename>proxyarp</filename> file.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Raw.pm</filename> (Shorewall::Raw) - Handles the
+            raw table; processes the <filename>conntrack</filename> (formerly
+            <filename>notrack</filename>) file.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Rules.pm</filename> (Shorewall::Rules) - Contains
+            the logic for process the <filename>policy</filename> and
+            <filename>rules</filename> files, including
+            <filename>macros</filename> and
+            <filename>actions</filename>.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Tc.pm</filename> (Shorewall::Tc) - Handles traffic
+            shaping.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Tunnels.pm</filename> (Shorewall::Tunnels) -
+            Processes the <filename>tunnels</filename> file.</para>
+          </listitem>
+
+          <listitem>
+            <para><filename>Zones.pm</filename> (Shorewall::Zones) - Processes
+            the <filename>zones</filename>, <filename>interfaces</filename>
+            and <filename>hosts</filename> files. Provides the interface to
+            zones and interfaces to the other modules.</para>
+          </listitem>
+        </itemizedlist>
+
+        <para>Because the params file can contain arbitrary shell code, it
+        must be processed by a shell. The body of
+        <filename>getparams</filename> is as follows:</para>
+
+        <programlisting>#  Parameters:
+#
+#      $1 = Path name of params file
+#      $2 = $CONFIG_PATH
+#      $3 = Address family (4 or 6)
+#
+if [ "$3" = 6 ]; then
+    PRODUCT=shorewall6
+else
+    PRODUCT=shorewall
+fi
+
+#
+# This is modified by the installer when ${SHAREDIR} != /usr/share
+#
+. /usr/share/shorewall/shorewallrc
+
+g_program="$PRODUCT"
+g_libexec="$LIBEXECDIR"
+g_sharedir="$SHAREDIR"/shorewall
+g_sbindir="$SBINDIR"
+g_perllib="$PERLLIBDIR"
+g_confdir="$CONFDIR/$PRODUCT"
+g_readrc=1
+
+. $g_sharedir/lib.cli
+
+CONFIG_PATH="$2"
+
+set -a
+
+. $1 &gt;&amp;2 # Avoid spurious output on STDOUT
+
+set +a
+
+export -p</programlisting>
+
+        <para>The program establishes the environment of the Shorewall or
+        Shoreall6 CLI program since that is the environment in which the
+        <filename>params</filename> file has been traditionally processed. It
+        then sets the -<option>a</option> option so that all newly-created
+        variables will be exported and invokes the
+        <filename><filename>params</filename></filename> file. Because the
+        STDOUT file is a pipe back to the compiler, no spurious output must be
+        sent to that file; so <filename>getparams</filename> redirect
+        <filename>params</filename> output to STDOUT. After the script has
+        executed, an <command>export -p</command> command is executed to send
+        the contents of the environ array back to the compiler.</para>
+
+        <para>Regrettably, the various shells (and even different versions of
+        the same shell) produce quite different output from <command>export
+        -p</command>. The Perl function Shorewall::Config::getparams() detects
+        which species of shell was being used and stores the variable settings
+        into the %params hash. Variables that are also in %ENV are only stored
+        in %params if there value in the output from the
+        <filename>getparams</filename> script is different from that in
+        %ENV.</para>
+      </section>
+
+      <section>
+        <title>Configuration Files</title>
+
+        <para>The configuration files are all well-documented. About the only
+        thing worth noting is that some macros and actions are duplicated in
+        the Shorewall and Shorewall6 packages. Because the Shorewall6 default
+        CONFIG_PATH looks in ${SHAREDIR}/shorewall6 before looking in
+        ${SHARDIR_/shorewall, this allows Shorewall6 to implement
+        IPv6-specific handling where required.</para>
+      </section>
+    </section>
+
+    <section>
+      <title>The Generated Script</title>
+
+      <para>The generated script is completely self-contained so as to avoid
+      version dependencies between the Shorewall version used to create the
+      script and the version of Shorewall-common installed on the remote
+      firewall.</para>
+
+      <para>The operation of the generated script is illustrated in this
+      diagram.</para>
+
+      <graphic fileref="images/RunningScript.png" />
+
+      <para>The Netfilter ruleset is sometimes dependent on the environment
+      when the script runs. Dynamic IP addresses and gateways, for example,
+      must be detected when the script runs. As a consequence, it is the
+      generated script and not the compiler that creates the input for
+      iptables-restore. While that input could be passed to iptables-restore
+      in a pipe, it is written to
+      <filename>${VARDIR}/.iptables_restore-input</filename> so that it is
+      available for post-mortem analysis in the event that iptables-restore
+      fails. For the other utilities (ip, tc, ipset, etc), the script runs
+      them passing their input on the run-line.</para>
+    </section>
   </section>
 
   <section>
-    <title>Overall Architecture</title>
+    <title>Compiler Internals</title>
 
-    <para>Shorewall was originally written entirely in Bourne Shell. The chief
-    advantage of this approach was that virtually any platform supports the
-    shell, including small embedded environments. The </para>
+    <para>Because the compiler is the most complex part of the Shorewall
+    product suite, I've chosen to document it first. Before diving into the
+    details of the individual modules, lets take a look at a few general
+    things.</para>
+
+    <section>
+      <title>Modularization</title>
+
+      <para>While the compiler is modularized and uses encapsulation, it is
+      not object-oriented. This is due to the fact that much of the compiler
+      was written by manually translating the earlier Shell code.</para>
+
+      <para>Module data is not completely encapsulated. Heavily used tables,
+      most notably the Chain Table (%chain_table) in Shorewall::Chains is
+      exported for read access. Updates to module data is always
+      encapsulated.</para>
+    </section>
+
+    <section>
+      <title>Module Initialization</title>
+
+      <para>While currently unused and untested, the Compiler modules are
+      designed to be able to be loaded into a parent Perl program and the
+      compiler executed repeatedly without unloading the modules. To
+      accomodate that usage scenario, variable data is not initialized at
+      declaration time or in an INIT block, but is rather initialized in an
+      <firstterm>initialize</firstterm> function. Because off of these
+      functions have the same name ("initialize"), they are not exported but
+      are rather called using a fully-qualified name (e.g.,
+      "Shorewall::Config::initialize").</para>
+
+      <para>Most of the the initialization functions accept arguements. Those
+      most common argument is the address family (4 or 6), depending on
+      whether an IPv4 or IPv6 firewall is being compiled. Each of the modules
+      that are address-family dependent have their own $family private (my)
+      variable.</para>
+    </section>
+
+    <section>
+      <title>Module Dependence</title>
+
+      <para>Here is the module dependency tree. To simplify the diagram,
+      direct dependencies are not shown where there is also a transitive
+      dependency.</para>
+
+      <graphic fileref="images/ModuleDepencency.png" />
+    </section>
+
+    <section>
+      <title>Config Module</title>
+
+      <para></para>
+    </section>
   </section>
 </article>