Overview

In the usual PIKT configuration, you manage the monitored client ("slave") machines from a central ("master") control machine. On the central control machine, there are eight controlling config files: systems.cfg, defines.cfg, macros.cfg, alerts.cfg, alarms.cfg, objects.cfg, programs.cfg, files.cfg. They define your entire setup. You invoke the overseeing management utility, piktc (for "pikt control") to preprocess those files, to install client target files, and to perform other management functions, such as stopping and restarting daemons.

Two daemons run on each client, piktc_svc and piktd. piktc_svc listens for and responds to piktc requests. piktd launches Pikt scripts at specified intervals.

On all clients, piktd wakes up every minute to check if one or more groups of scripts, also known as "alarms", are due to run that minute. Alarm scripts are grouped together as "alerts". Alerts run at specific intervals, e.g., hourly, once daily, once weekly, etc. At the appropriate time, piktd summons the pikt interpreter to run the Pikt scripts for that alarm group. You can also run Pikt scripts manually at the command line, but usually they are invoked by piktd.

pikt is the Pikt scripting language interpreter. Individual Pikt scripts usually monitor just one aspect of a system. You can monitor a single object, or collections of things listed in the object files, for example: system processes, disks, devices, lists, etc.

Each Pikt alarm script gets its input from processes, files, or log files. For log files, only new log entries since the last alarm run are considered.

A typical alarm consists of a sequence of logical tests. If the current input line satisfies one or more conditions, actions may or may not be triggered. Conditions might also refer to data in the previous input line, to data for this line remembered from the prior alarm run, even to data coming from outside the current alarm and pikt process.

Triggered actions might include generating a line of e-mail. At the end of the current pikt run, queued lines are e-mailed in a single problem report to one or more sysadmins. Queued lines might be printed or logged, whether to syslog, to this alert's log file, or to some other special log file. Or commands might be executed, for example to restart a detected dead system process, to chown a file, or perhaps to page the sysadmins.

For generating alarm script input, for taking action, also for serving as subroutines, you can employ auxiliary programs and scripts written in other, non-Pikt languages.

All external commands are logged for debugging and auditing purposes. If your alarm script makes reference to data from the prior alarm run, current data is stored in history files for looking up next time. And, very importantly, all errors are logged (including errors generated by invoked scripts written in other languages), giving you a complete audit trail when things go wrong.

You may also employ PIKT to manage system configuration files, such as inetd.conf, syslog.conf, sudoers, etc. It becomes much easier, for example, to enforce consistent access rights across your many systems.

The PIKT binaries are written using a combination of C, lex (flex), and yacc (bison). Most of the sample scripts are written in the Pikt script language, although several auxiliary Perl, expect, and shell scripts are also provided.

1st page