Once we have built our hosts and objects definitions, we can start using PICA to do something useful. Basically, PICA always does “something” to a list of objects on each of the given hosts. As the the help option “-h” states, PICA has the following command line syntax:
(PICA) Perl Installation and Configuration Agent Version: 0.3.4 Usage: ../pica -[ixtflh] [-n] [-v] [--with-picaconf newpica.conf] [--with-hostsconf newhosts.conf] [--with-objectsconf newobjects.conf] +D defines +|-F objects +|-H hosts -i : Install objects -x : Execute object/command -t : Delete object -f : Diff object -l : List objects -h : Shows this help -n : Debug. Do not install/delete things, just testing -v : Be verbose --with-picaconf : Changes pica.conf path --with-hostsconf : Changes hosts.conf path --with-objectsconf : Changes objects.conf path +D : Build defines list +|-F : Build object list +|-H : Build hosts list
The command line has three different mandatory parts:
Moreover, there is an environment variable, called PICAARGS, that will be pasted at the end of the command line (useful for having some parameters fixed at the end of every PICA call).
The object and host list on which we want to operate is built with +F/-F and +H/-H. With +H/-H we add/delete hosts or groups to the hosts list in the same order they are entered. For example, the expression:
+H dnsservers solaris -H deimos
will result in the host list “fobos mercurio sar” since PICA will add the members in groups dnsservers and solaris and delete host deimos2. Note that you can specify hosts not defined in hosts.conf. Those hosts will belong to no group, and connections will be made to that name. Moreover, only “common” objects will be seen. But it’s a start.
One more feature you will want to know of is the “automatic exclusion”. Before doing the actual host count, an implicit -H sysdown is added at the end of the list. This allows the sysadmin to automatically delete some hosts that can be down at a given time.
The object list is built the same way using +F/-F, but the object arithmetic is evaluated for every host, since the objects available for every host can be different because we can use conditionals in the objects file. For example, in the objects file above, all documentation objects will only be seen by members of the group “doc”.
Since we always need at least one host and object, options +F and +H are mandatory. If after doing the host/object arithmetic PICA gets an empty list (either objects or groups) it gives an error message and aborts execution.
Implicit groups are groups defined automatically by PICA to ease host and group arithmetic. Currently, there are only two implicit groups defined:
Moreover, if sysdown is not defined, PICA will define it automatically (to a empty list, of course).
We can also use +D/-D to build an optional list of definitions that can be used to preprocess files and as variables in object definitions, as if they where defined in the “defaults” environment of the hosts.conf file. Actually there is a little but very important difference, since they are defined before reading the hosts.conf file, these are the only variables that can be used to conditionally preprocess this file.
Right now PICA supports five different internal commands, but more could be added in the near future since we are still adding new features.
With each of these commands we can use the -v option for verbosity, and -n for debug (as with make, it does nothing, simply print information and "simulate" it’s working). Option -n gives a lot of output and doesn’t really do anything, just prints what it would do.
All these commands are executed using SSH connections to the remote hosts. Right now PICA doesn’t have any access control system, and will probably never have one. We like SSH and it gives us everything we need to access remote servers securely, so we used it for PICA. You know, as they say: KISS3.
Just one suggestion, if you are willing to use PICA, you better configure properly the RSA authentication, or be ready to type a lot of passwords... One nice trick is to distribute the SSH’s RSA authentication files using PICA as explained in one of the real life examples described later.
This command will install the given objects in each of the given hosts. The install command first generates the objects it will install in a local dir ($picaroot/tmp/$picahost), and then install them in the remote host.
PICA supports three different methods for remote file installation:
To change the installation method, set the attribute “method” per machine, in hosts.conf (you can set it globally or individually, distinct for each machine). To use methods tar and rsync, you must also set the binary path to this utils with the attributes “tar” and “rsync”.
The command:
pica -iv +F NTP -F step-tickers +H all -H deimos
Will install all objects in the group NTP except step-tickers in all servers except deimos.
This command will execute the given list of commands in each of the given hosts. If PICA finds an object with the given name, it will read its path attribute and use it for remote execution. This way we don’t have to remember the location of the script. If it doesn’t find an object with that name, PICA assumes it’s a Unix command and tries to run it.
For example, the command
pica -xv +F DNSChkUrgent +H servers
will execute /var/lib/pica/alarms/Urgent/DNSChkUrgent in all servers, since the object DNSChkUrgent exists and PICA can build the remote path using the object’s attributes.
On the other hand, the command
pica -xv +F "ndc reload" +H dnsservers
will run the command “ndc reload” in each member of the dnsservers group. Since PICA can’t find an object named ndc, it assumes it’s a Unix command and tries to execute.
This command lists the given objects. It basically executes “ls -l” for every object’s path. It can be used to see if an object is installed, and if the uid/gid and file permissions for that object are correct.
This command deletes the given objects in each of the given hosts.
The diff command finds differences between the object that should be installed in a host, and the one really installed. It basically generates the object for that host, and makes a “diff -u” between this object and the one installed in the remote host.
It’s very useful to see if a host has the latest version of an object.