Previous Up

7  Real life examples

Here are some real life examples of PICA distribution files explained. With PICA comes a tiny (not-so-real-life) example which will make you understand how the Perl PreProcessor can be used. The file is called pica-rules.

7.1  Two files from the same source

Let’s begin with an example for distributing two files from the same source. At the Network Division we run the University’s primary nameservers. But we also give support to people that run secondary servers. In one of our primary servers, we also wanted to publish the configuration file needed to run a secondary server. We wanted to use the same source to keep both files consistent. This apparently simple task has created a lot of problems with other tools we have used. With PICA the solution is simple:

In the case of the masters, we have to install one version for production (the master server file) and one for documentation (the slave DNS server file). Thus, we defined, in hosts.conf, the following:

hostgroup dnsservers {
    members { fobos, deimos, mercurio, ulpnet, ulpnet2 }
}
hostgroup dnsmaster {
    members { ulpnet, ulpnet2 }
}
hostgroup doc {
    members { ulpnet, ulpnet2 }
}

This way we can differentiate between documentation, DNS master and DNS slave servers. Thus, in objects.conf, we can define the relevant files as:

#if (ingroup('dnsservers'))
group DNS {
    file named.conf {
         path = '/etc/named.conf';
         source = "DNS/named_conf.cfg";
    }

    ## Documentation for this Service
#  if (ingroup('doc'))
    # ...
    file named.conf.sample {
       path = '<#$docdir#>/Servicios/DNS/named.conf.sample';
       source = 'DNS/named_conf.cfg';
    }
#  fi
}
#fi

The only thing left to do is defining the named.conf file contents. The trick is checking the name of the object: if it ends with “.sample”, it’s a slave sample file; it not, then it’s a master file.

# ...
zone "ulpgc.es" {
#if ((ingroup('dnsmaster')) && ($picaobject !~ /\.sample$/))
   type master;
   file "mydb.db";
   also-notify {
      # ...
   };
#else
   type slave;
   file "mydb.db.bak";
   masters {
      # ...
   };
#fi
};
# ...

This shows the power of using arbitrary perl code in PICA conditions.

7.2  Installing RSA authentication files within PICA

When you start administering a new server with PICA, one of the first things you should do is configuring SSH’s RSA authentication, to be able to access that server without typing any password.

This task can be simplified by distributing the needed files using PICA. We use SSHv2, so we will assume this version of SSH. First of all, every sysadmin needs to have their private/public key pair. Let’s say we are two sysadmins and our public keys are in SSHv2 format in the files sysadm1.pub and sysadm2.pub. We will add the following entries to the objects.conf file:

# SSH RSA authentication files
group RSAAuth {
    # SSHv2 authorization file
    file ssh_auth {
         path = '/root/.ssh2/authorization';
         source = "SSH/authorization.cfg";
    }
    file sysadm1.pub {
         path = '/root/.ssh2/sysadm1.pub';
         source = "SSH/sysadm1.pub";
    }
    file sysadm2.pub {
         path = '/root/.ssh2/sysadm2.pub';
         source = "SSH/sysadm2.pub";
    }
}

Different versions of SSH (SSHv2 or SSHv1) can be used in different hosts and use conditionals in the previous entries. This is left as an exercise to the challenged student ;-).

We could even generate the authorization file on-the-fly with the needed Key entries with the following code snippet:

#perl
my @return;
# Get key files reading group members and skipping 'ssh_auth'
my @keys=grep(/\.pub$/,members('SSHAuth'));
foreach my $key (@keys) {
  push @return,"Key $key\n";
}
# Return the array (will be printed)
@return;
#lrep

This code will generate one “Key file.pub” entry for each public key file we define in the group, thus allowing access to the server with that key. This is really outside the scope of this article, but is a good example of what can be done with the #perl/#lrep environment.

With this configuration, after adding the new host to the hosts.conf file you could run the command:

pica -iv +F SSHAuth +H new_server

You will then have to type the server’s password only this time, because after installing this files both sysadmins will be able to access the server without typing any password (assuming they are running ssh-agent).

7.3  Execution of perl code within configuration files

Here at Network Division, we have a very handy script to restart critical services via Web, just in case SSH is down on a given server. Of course, it has a secret password to allow access only to authorized administrators.

Before PICA, we had to manually create the password’s MD5 hash using the crypt perl function, and include the hash in the source file. Now, we can resort to something as elegant as this:

$passwd='<# crypt('secret-key-that-you-wont-ever-figure-out','salt') #>';

This way, just before sending the data, the command is executed and the encrypted key is put automagically in the distributed file. This saves time and work, and is a perfect example of the inmense power of PICA (and Perl, of course).


Previous Up