Configuring a Network

(NOTE:  Some of the techniques shown or described on this page--marked in purple--require new features in the latest official PIKT 1.19.0 release (pikt-current.tar.gz) that are unavailable in any previous version.)

Continuing our exploration of PIKT configuration management, in this example, we demonstrate how to manage some network configurations.

In the piktmaster files.cfg, we have the following #include directive:

#include <files/resolv_conf_files.cfg>
Here is the resolv_conf_files.cfg #include file:
//////////////////////////////////////////////////////////////////////////
//
// resolv_conf_files.cfg
//
//////////////////////////////////////////////////////////////////////////

resolv.conf             path "/etc/resolv.conf" mode 644 uid 0 gid 0

#include <files/adm/resolv_conf_common_files.cfg>

//////////////////////////////////////////////////////////////////////////

#if mandriva

resolv.conf_postfix     path "/var/spool/postfix/etc/resolv.conf"
                        mode 644 uid 0 gid 0

#include <files/adm/resolv_conf_common_files.cfg>

#endif

//////////////////////////////////////////////////////////////////////////
We have two instances of resolv.conf to manage: one in its usual place, the /etc directory, and a second--for Mandriva Linux systems--in a special Postfix config directory.  Except for their location, these resolv.conf files are identical.  We get their content from a common #include file, resolv_conf_common_files.cfg:
//////////////////////////////////////////////////////////////////////////
//
// resolv_conf_common_files.cfg
//
//////////////////////////////////////////////////////////////////////////

        domain pikt.org
        nameserver 192.168.3.50
#if earthlink
        nameserver 11.22.33.44
        nameserver 44.33.22.11
        search earthlink.net
#else
#  if ! ottawa
        nameserver 123.100.222.3
        nameserver 123.100.111.3
#  endif
#endif

//////////////////////////////////////////////////////////////////////////
We have a rather complicated network arrangement, and depending on who's on what network, we get our name service from several different sources--a local name server on the 192.168.3.0 private subnet, nameservers on the Earthlink consumer network, and still other nameservers on the Road Runner commercial network.  We have "earthlink" (and "roadrunner") defined as hosts groups (with associated hostnames) in the piktmaster systems.cfg file.

Here is a piktc command to install resolv.conf on the Linux systems (in /etc everywhere, in /var/spool/postfix/etc only on the Mandriva Linux systems):

# piktc -iv +F resolv.conf resolv.conf_postfix +H linux

processing calgary...
installing file(s)...
resolv.conf installed

processing winnipeg...
installing file(s)...
resolv.conf installed
resolv.conf_postfix installed

processing ottawa...
installing file(s)...
resolv.conf installed

...
Just to be clear:  Post-installation, the Earthlink-connected SuSE Linux calgary system would have an /etc/resolv.conf file with contents
domain pikt.org
nameserver 192.168.3.50
nameserver 11.22.33.44
nameserver 44.33.22.11
search earthlink.net
The Road Runner-connected Mandriva Linux winnipeg system would have identical resolv.conf copies in both /etc and /var/spool/postfix/etc/ with contents
domain pikt.org
nameserver 192.168.3.50
nameserver 123.100.222.3
nameserver 123.100.111.3
And the SuSE Linux ottawa system, which is only on the local private subnet, would have an /etc/resolv.conf file with contents of simply
domain pikt.org
nameserver 192.168.3.50
Post-installation, we could use the many piktc command options to reconfigure, reinstall, backup, and restore the resolv.conf files, also check their file integrity using the diff and checksum options as needed.

Moving from client to server, in the next example we specify some named configurations. 

First, named.conf.  Here is the named_conf_files.cfg file:

///////////////////////////////////////////////////////////////////////////////
//
// named_conf_files.cfg
//
///////////////////////////////////////////////////////////////////////////////

#if dnsserver

named.conf
        path "/etc/named.conf"  mode 640 uid =rootuid gid 44

        # Copyright (c) 2001-2003 SuSE Linux AG, Nuernberg, Germany.
        # All rights reserved.

[...]

        options {

                # The directory statement defines the name server's
                # working directory

                directory "/var/lib/named";

[...]

        # The following zone definitions don't need any modification.
        # The first one is the definition of the root name servers.
        # The second one defines localhost while the third defines the
        # reverse lookup for localhost.

        zone "." in {
                type hint;
                file "db.cache";
        ##      file "root.hint";
        };

        zone "localhost" in {
                type master;
                file "db.localhost";
        ##      file "localhost.zone";
        };

        zone "0.0.127.in-addr.arpa" in {
                type master;
                file "db.127.0.0";
        ##      file "127.0.0.zone";
        };

[...]

        # pikt

        zone "pikt.org" in {
#if dnsmaster
                type master;
                file "master/db.pikt.org";
#elif dnsslave
                type slave;
                file "slave/db.pikt.org";
                masters { 192.168.2.132; };
#endif
        };

        zone "pikt.net" in {
#if dnsmaster
                type master;
                file "master/db.pikt.net";
#elif dnsslave
                type slave;
                file "slave/db.pikt.net";
                masters { 192.168.2.132; };
#endif
        };

        # earlymusichicago

        zone "earlymusichicago.org" in {
#if dnsmaster
                type master;
                file "master/db.earlymusichicago.org";
#elif dnsslave
                type slave;
                file "slave/db.earlymusichicago.org";
                masters { 192.168.2.132; };
#endif
        };

        zone "earlymusichicago.com" in {
#if dnsmaster
                type master;
                file "master/db.earlymusichicago.com";
#elif dnsslave
                type slave;
                file "slave/db.earlymusichicago.com";
                masters { 192.168.2.132; };
#endif
        };

[...]

#endif  // dnsserver

///////////////////////////////////////////////////////////////////////////////
Note how, by means of the #if ... #elif ... #endif directives, we customize the configuration for each master and slave name server.

On the piktmaster system, we would install the named.conf file to both master and slave name server system with, for example:

# piktc -iv +F named.conf +H dnsserver        [or: ... +H dnsmaster dnsslave]
Next, the BIND zone data files.  Here is another #include file, zone_data_files.cfg:
///////////////////////////////////////////////////////////////////////////////
//
// zone_data_files.cfg
//
///////////////////////////////////////////////////////////////////////////////

#if dnsmaster

///////////////////////////////////////////////////////////////////////////////

db.pikt.org
        path "=zondir/db.pikt.org"      mode 644 uid =rootuid gid =rootgid

        $ORIGIN org.
        =zonttl
        pikt            IN      SOA     pikt.org. root.pikt.org. (
                        2006061201      ; serial number
#  include <files/adm/zone_data_common_files.cfg>
                        IN      A       12.100.32.132
        $ORIGIN pikt.org.
        www             IN      A       12.100.32.132

///////////////////////////////////////////////////////////////////////////////

db.pikt.net
        path "=zondir/db.pikt.net"      mode 644 uid =rootuid gid =rootgid

        $ORIGIN net.
        =zonttl
        pikt            IN      SOA     pikt.net. root.pikt.net. (
                        2006061201      ; serial number
#  include <files/adm/zone_data_common_files.cfg>
                        IN      A       11.22.33.44
        $ORIGIN pikt.net.
        www             IN      A       11.22.33.44

///////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////////

db.earlymusichicago.org
        path "=zondir/db.earlymusichicago.org"  mode 644 uid =rootuid gid =rootgid

        $ORIGIN org.
        =zonttl
        earlymusichicago        IN      SOA     earlymusichicago.org.
                                                root.earlymusichicago.org. (
                        2006061201      ; serial number
#  include <files/adm/zone_data_common_files.cfg>
                        IN      A       11.22.33.44
        $ORIGIN earlymusichicago.org.
        www             IN      A       11.22.33.44
        dowland         IN      A       11.22.33.44
        london-bak      IN      A       192.168.3.60

///////////////////////////////////////////////////////////////////////////////

db.earlymusichicago.com
        path "=zondir/db.earlymusichicago.com"  mode 644 uid =rootuid gid =rootgid

        $ORIGIN com.
        =zonttl
        earlymusichicago        IN      SOA     earlymusichicago.com.
                                                root.earlymusichicago.com. (
                        2006061201      ; serial number
#  include <files/adm/zone_data_common_files.cfg>
                        IN      A       11.22.33.44
        $ORIGIN earlymusichicago.com.
        www             IN      A       11.22.33.44
        dowland         IN      A       11.22.33.44

///////////////////////////////////////////////////////////////////////////////

#endif  // dnsmaster

///////////////////////////////////////////////////////////////////////////////
zone_data_files.cfg refers to several PIKT macros, including (showing their definitions in macros.cfg):
#if dnsmaster
zondir          /var/lib/named/master
#elif dnsslave
zondir          /var/lib/named/slave
#endif
Note how, by means of the #if ... #elif ... #endif directives, the =zondir will auto-adapt for both DNS master and slave.
zonttl          $TTL 3600
If we want to change our ttl everywhere, we only have to change its macro definition in one place--in macros.cfg.

Note how the #include directives incorporate the zone_data_common_files.cfg file to achieve some commonality (for example, of refresh, retry, expire, and TTL, also NS and MX records) across every zone data file.  Here is that zone_data_common_files.cfg #include file:

///////////////////////////////////////////////////////////////////////////////
//
// zone_data_common_files.cfg
//
///////////////////////////////////////////////////////////////////////////////

#if dnsmaster
                        8h      ; refresh (8 hours) 
                        30m     ; retry   (1 hour) 
                        2d      ; expire  (1 week) 
                        1d  )   ; TTL     (1 day)
                        IN      NS      ns1.secondary.com.
                        IN      NS      ns2.secondary.com.
//                      IN      NS      bigfoot.everett.org.
                        IN      MX      0       handel.earlymusichicago.org.
#endif

///////////////////////////////////////////////////////////////////////////////
On the piktmaster system, we would install, for example, the db.pikt.org zone data file to the master name server system with the command:
# piktc -iv +F db.pikt.org +H dnsmaster
It would be entirely possible to have PIKT automate serial number updates.  Instead of hard-coding the serial numbers, as in
                        2006061201      ; serial number
by means of process includes, we could have PIKT handle the serial number updates for us, as in
#indent
#include [/bin/date +'%Y%m%M%S']
#unindent
Since PIKT stanza content must be indented, and since the output of the date command is not indented, we have to wrap #indent ... #unindent directives around the #include.

So every time we reinstall a zone data file, the process include would guarantee an up-to-date serial number for us automatically.

After a zone data file reconfiguration, you need to restart the named to finish the update.  You can both reinstall and restart in a single piktc command by combining the '-i' (install) and '-x') execute options, as in:

# piktc -ixv +F db.pikt.org +C "/etc/init.d/named restart" +H dnsmaster
Continuing our network configuration, we can also use PIKT to manage our firewall files.  See Iptables Firewall Script and Reset Iptables for details.

There are many other aspects of network configuration that PIKT might handle (not to mention that PIKT can also help you monitor your network and sift through the many network log files).  These examples should start you thinking of the possibilities.

prev page 1st page next page
 
Home | FAQ | News | Intro | Samples | Tutorial | Reference | Software
Developer's Notes | Licensing | Authors | Pikt-Users | Pikt-Workers | Related Projects | Site Index | Privacy Policy | Contact Us
Page best viewed at 1024x768 or greater.   Page last updated 2019-01-12.   This site is PIKT® powered.
Copyright © 1998-2019 Robert Osterlund. All rights reserved.
Home FAQ News Intro Samples Tutorial Reference Software
PIKT Logo
PIKT Page Title
See how to
automatically report
network service failures