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).