This Reference is succinct and to the point.  It assumes that you already know something about systems administration, and know how to program using one or more of the other well-known scripting languages.  Since the Pikt script language follows many of the usual scripting language conventions, this Reference leans toward highlighting the unusual or obscure and away from repeating what is standard or obvious.

The Reference Guide is short on examples.  For real-world examples, see the Introduction pages, the Samples pages, or the lib/configs_samples files in the latest official software release, pikt-current.tar.gz (but view the cautionary README file in the configs_samples directory).

Some notes about nomenclature:  "PIKT" (all caps) refers to the PIKT package in its entirety.  "Pikt" (first letter only capitalized) refers to the Pikt script language.  "pikt" (all lower-case) refers to the Pikt script interpreter (the binary program).
 

Overview

PIKT ("Problem Informant/Killer Tool"; rhymes with "ticket") attempts to solve some of the problems observed in more traditional methods of monitor scripting and managing system configurations.  PIKT is an embedded scripting language and accompanying script interpreter.  PIKT is also a sophisticated script and system configuration file preprocessor for use with the Pikt scripting language or any other scripting language of your choice.  Finally, PIKT is a cross-platform, centrally run script scheduler (like cron), customizing installer (like rdist), command shell enhancement, and total script and configuration file management facility.  PIKT's primary purpose is to monitor systems, report problems, and fix those problems whenever possible, but its flexibility lends itself to quite a few other uses as well.

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 that 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 either a combination of C, lex (flex), and yacc (bison), otherwise Perl.  Most of the sample scripts are written in the Pikt script language, although several auxiliary Perl, Expect, and shell scripts are also provided.

Home | News | Introduction | Samples | Tutorial | Reference | Software | Authors | Licensing
Forum | Marketplace | Links | SiteSearch | FAQ | Contribute | Donate | ContactUs
Top of Page

Please visit our sponsors.