piktc & piktc_svc
PIKT is managed through the combined action of the interactive control program, piktc (on the central master machine only), and the piktc_svc service daemon (on all slave machines).
The piktc command options are shown in Appendix 1.
When specifying items, you include items with "+" and exclude with "-". For example, "+A all" includes all alerts. "+A all -A EMERGENCY Info" includes all alerts except EMERGENCY and Info. Another way to achieve the same effect is with just "-A EMERGENCY Info" (leaving out the "+A all", which is implicit).
This sample command checksums (using MD5) all files on all user systems except the Linux machines and any down systems:
# piktc -m5v ALL -H nonusersys linux downsys
You use piktc to preprocess source configuration (*.cfg) files on the master machine, and send the post-processing alert (.alt), object (.obj), program, and other files over the network to receiving piktc_svc daemons for installation on the slave systems. Preprocessing entails:
- stripping out meta-comments (comments of the form // or /* */)
- #include'ing auxiliary files (e.g., a list of Unix command macros)
- using #if <os|host|hostgroup> #endif preprocessor directives, filtering through lines pertaining only to the current client (e.g., '#if solaris')
- using #ifdef <define> #endifdef preprocessor directives, for including/excluding portions of the text (e.g., '#ifdef debug')
- making macro substitutions (e.g., substituting a Unix command path, with command options, appropriate to the current client)
- performing an across-the-board syntax check
Note that, in addition to the Pikt script and config files, it is possible to use meta-comments, #include's, #if's, #ifdef's, and macros in managed system configuration files and scripts written in other languages (e.g., Perl , Python , AWK ). Note, too, that scripts may rewrite config #include files, raising interesting possibilities for maintaining dynamic system configuration files.
You can customize config files by means of the #if, #elif, #else, and #endif preprocessing directives. The format is
#if <machine class> <lines> #elif <machine class> <lines> #else <lines> #endif
where <machine class> can be a series of host names, host aliases, or host groups, separated by the |, &, or ! set operators. | indicates set union, & set conjunction, and ! set negation. You can also use parentheses, ( and ), in the class specifications.
Akin to #if, a second class of preprocessor directives consists of: #ifdef, #ifndef, #elifdef, #elifndef, #elsedef, #endifdef, #define, and #undefine. The format is
#ifdef <define> <lines> #elifdef <define> <lines> #elsedef <lines> #endifdef
where <define> is an identifier representing a type of logical switch that is either defined (true) or undefined (false).
Logical defines are set (to TRUE) or unset (to FALSE) in any of three ways: (a) in the file defines.cfg; (b) in any config file, except systems.cfg or defines.cfg, by means of the #define and #undefine directives; or (c) at the command line, by means of either the +D or -D switches.
Observe that you can set and unset defines on a per-machine basis in the defines.cfg file, for example
#if dbserver paranoid TRUE #else paranoid FALSE #endif
as well as nest #ifdef's within #if's, and vice-versa, throughout the config files.
A config file can incorporate one or more other files by means of the #include directive. Included files may themselves include other files, but only of the same basic configuration type (macro files include macro files, for example). Here is an example #include directive:
Includes are especially useful for compartmentalizing across different systems administrators (where each has his/her own sub-config file), and across functions (e.g., security alarms in one file, network alarms in another), and for including files contributed by outsiders. Includes are also good for quarantining information particular to different operating systems.
There are other preprocessing directives, but the ones described above are
the most common.
|prev page||1st page||next page|