Including Processes

You may #include (or #verbatim) process output within PIKT .cfg files, not just file content.  This variant was added to address the difficult question:  In a constantly changing systems environment, how do you manage, automatically if possible, to keep your PIKT configurations accurate and up-to-date?  Process includes make possible the dynamic and automatic updating of configuration files.

The formats are

#include [<proc>]                       [or: #verbatim]

#include "<file>" [<proc>]              [or: #verbatim]

#include <<file>> [<proc>]              [or: #verbatim]

As an example of the first format, you could do something like the following (in defines.cfg):

dst             // TRUE if Daylight Savings Time now applies,
                // FALSE otherwise
                // at our site, `date +%Z` returns "CDT" if DST is in
                // effect, "CST" otherwise; substitute your own time
                // zone string as needed
#verbatim [if [ `date +%Z` = "CDT" ]; then echo TRUE; else echo FALSE; fi]

The process (within enclosing [] brackets)

if [ `date +%Z` = "CDT" ]; then echo TRUE; else echo FALSE; fi

will output either TRUE or FALSE depending on whether Daylight Savings Time applies.  So, sometimes the preprocessor will see, in effect,

dst             TRUE

and at other times

dst             FALSE

In this example, you don't have to worry about keeping the dst define up-to-date. The #include [<proc>] feature will do it automatically for you.

Another thing hard to keep up-to-date is your down systems list.  Suppose you have a program, called downsys.pl, to determine your down systems.  When invoked as 'downsys.pl 10' (where 10 is a timeout factor in seconds), typical downsys.pl output might be

geneva
cracow
padua

You could then define down in your systems.cfg this way:

down                    // set '-H down' for these

        members
#indent
#include [/pikt/lib/programs/downsys.pl 10]
#unindent

Note that it is necessary to indent your [<proc>] output, whether implicitly with the #verbatim directive or explicitly by wrapping '#indent ... #unindent' around the #include directive (or perhaps by programming indentation into the process output itself), else the lack of indentation will cause a parser error.

downsys.pl might come up empty-handed, because it aborts due to a syntax error, or a timeout, or perhaps because there are no current down systems.  In most cases--a 'members' stanza in systems.cfg being one exception--this will cause a parse error.  To protect against this, it is entirely possible to intersperse #include [<proc>] directives with hard-coded components and other preprocessor directives:

down                    // set '-H down' for these

        members
                london
                rotterdam
                calais
#verbatim [/pikt/lib/programs/downsys.pl 10]
#include <systems/retiredsys_systems.cfg>

Suppose the retiredsys_systems.cfg file content were

        rheims
        orleans2

(Note that these systems are indented within the file, hence it is unnecessary to wrap '#indent ... #unindent' around the #include directive, nor is it necessary to use #verbatim.)

After all file and process inclusions, the preprocessor would see, in effect,

down
        members
                london
                rotterdam
                calais
                geneva
                cracow
                padua
                rheims
                orleans2

In the example just given, downsys.pl would be run every time the preprocessor sees that line in the configuration (in systems.cfg).  If you have many systems to poll, that would of course slow things down considerably.  You have the option to reference both an on-disk local file, as well as a process, with

#include "<file>" [<proc>] 

#include <<file>> [<proc>] 

Either of these will have the preprocessor reference the on-disk <file> unless you specify the '-I' option in the piktc (preprocessor) command, in which case the [<proc>] output will be referenced, and that output will update the current <file> contents.

You might think of the on-disk <file> as a sort of data cache for [<proc>].

In other words, suppose the directive were written as

#verbatim <systems/down_systems.cfg> [/pikt/lib/programs/downsys.pl 10]

If you specify the '-I' (for "update include files") piktc option, as in

# piktc -cI +H piktmaster

this will read from [/pikt/lib/programs/downsys.pl 10] and write that process output to the file <systems/down_systems.cfg>.  If you omit the '-I' option, piktc will just reference the <systems/down_systems.cfg> file.

Although you could use the '-I' routinely in all of your piktc commands, of course you shouldn't, for that would slow your piktc operations down dramatically.  Better to do this just occasionally, say once a day (overnight) only.

To auto-update your configuration and refresh your scripts and data sets with the very latest and most accurate information on all systems, you could regularly schedule (e.g., nightly) the sequence

piktc -cI +H piktmaster
piktc -iv ALL

either by cron'ing it or by having PIKT itself run it on the piktmaster machine.

When using '#include [<proc>]', you must be careful to use a <proc> that will not hang the whole 'piktc -I' process (because, for example, you are ssh'ing to a remote host and that host is down).  To force a timeout, you might use this Expect script (as it would appear in programs.cfg):

maxtime.exp     // put a time limit on an invoked command

        #!=expect

        set timeout [lindex $argv 0]
        eval spawn -noecho [lrange $argv 1 end]
        expect

You might use this Expect script in downsys.pl written as:

#if piktmaster

downsys.pl      // list all down systems

        #!=perl

        # downsys.pl -- list all down systems

        die "Usage:  downsys.pl <secs timeout>\n" if ($#ARGV != 0) ;

        foreach $sys (`=piktc -L +H all`) {
                chomp $sys ;
                next if (`=maxtime $ARGV[0] =ping $sys` =~ /is alive/) ;
                print "$sys\n" ;
        }

#endif

If you are not careful, it's very easy to get the <proc> wrong in various ways and screw up your #include or #verbatim files, therefore parts of your overall PIKT configuration.  It's worth taking the trouble, however, because auto-updating #include and #verbatim file directives is an elegant solution to the problem of keeping up-to-date various dynamic PIKT configuration components.

Refer to the Introduction and Samples pages (or possibly also 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) for many more examples of this technique.

prev page

1st page

next page

	Enter your search terms
	Web pikt.org Submit search form