News

For a history of PIKT software revisions, see Changes.

For developer commentary and older news, see Developer's Notes.


[posted 2008/05/20]

Release 1.19.1pre1, 2008/05/20

This is to announce the release of PIKT 1.19.1pre1, a beta release.

Highlights of this beta release (differences from the latest official release, pikt-1.19.0, marked in purple):

• Ported to Mac OS X.
• Fixed several Solaris 10 issues.
• All log entries should now identify PIKT binary pids (process ids) more properly.
• Minor bug fixes.

We are successfully using PIKT 1.19.1pre1 on a Mac Pro running Mac OS X 10.5 (Leopard), also several Solaris 10 & 9 systems. We also continue to run PIKT without problems on numerous SUSE Linux and Gentoo Linux PIKT master and slave systems, and one FreeBSD 7.0 slave system.

NOTE: Although the PIKT 'make check' is currently somewhat broken (on some OSes and systems, it might fail on startup in phases ii & iii), this relates more to the difficulty of setting up a proper testing environment and usually doesn't indicate any problems with actual PIKT operations.

As always, remember: pikt-1.19.1pre1 is beta code. One purpose of issuing pre-releases is to give users the chance to test beta code before we adopt it in official releases. So, we encourage users, especially OS X and Solaris users, to give pikt-1.19.1pre1 a try and report back any problems and suggestions.


[posted 2008/05/05]

We are delayed in releasing a new version porting PIKT to the Solaris and Mac OS X platforms, mainly due to some nagging system issues with OS X.  In the meantime, here are some simple instructions for achieving Solaris 10 compatibility.

In the file src/lib/crypt.c, simply replace all instances of

u_int32_t

with

uint32_t

Also, in the file src/piktd/piktd.c, add the following near the beginning:

const signed char err[]    = { ERROR, '\0' };
const signed char nil[]    = { NIL, '\0' };

That's it!  With those simple changes, we believe that PIKT should compile successfully under Solaris 10.

Although we personally haven't used PIKT as a piktmaster with Solaris 10, we have used PIKT (with the above described changes) successfully in a production environment with several Solaris 10 PIKT slaves.

Please report any Solaris 10 PIKT problems to: 

[posted 2007/10/27]

We have a new Wikipedia PIKT page.  Wikipedia has several references to PIKT.  For a complete list, visit the Related Projects and Products page.

Also, we have discovered several problems that break compilation under both Solaris 9 & 10.  Expect a 1.19.1 release to address this issue (and probably only this Solaris issue) soon.  In the meantime, write to robert.osterlund@comcast.net if you need a sneak preview.

Finally, we anticipate adding a Macintosh to our stable of systems (11 actual systems, more if you count dual boot and virtual systems) at pikt.org by the end of the year.  We plan on porting PIKT to Mac OS X and issuing a Macintosh-port release sometime this winter.


[posted 2007/09/10]

Release 1.19.0, 2007/09/10

We are pleased to announce the release of PIKT 1.19.0!

Highlights of this new release (significant changes since 1.18.2):

• Substantially revised the PIKT Reference, adding many more examples (including links to new web pages at pikt.org detailing function usage), expanding on several sections, and updating to reflect details in recent software versions.
• piktc '-x' & '-X' operations may now piggyback onto other piktc operations (e.g., '-i'), so that one can now, for example, install and execute a post-install command in one go.
• Added a new piktc & pikt command-line option, '-U', for running in "urgent mode" (where no lock file blocks operation).
• Added a new piktc command-line option, '-p#', for pausing # seconds between successive piktc operations.  Also added the '-p#' option to piktx.
• Implemented per-host (set in keys.conf) data_encryption_type & auth_encryption_type.
• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added the doexec Pikt script statement.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways, =piktdataenctyp, =piktauthenctyp.
• Added several new script functions: $status(), $mailcmd(), $lpcmd().
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Implemented the retention of history info (in .hst files) in script quit situations.
• For the #age() & #fileage() functions, added the option to specify a file path argument (instead of, as before, some date arguments).
• In 'output log' statements, the logfile name may now be a computable string.
• 'piktc -G' debug output is now much more useful and relevant.
• Improved error handling and logging.
• Fixed some issues that broke authentication on 64-bit systems.
• Fixed a FreeBSD compile problem.
• Minor bug fixes.
• Made other code improvements.

We have substantially revised the PIKT Reference.  More examples were added, including links to newly created web pages at pikt.org detailing Pikt function usage.  (See Numerical Functions and String Functions.)  Several sections were expanded, and in general, everything was brought up to date with the latest software versions.

We also did a major overhaul of the PIKT Introduction pages at pikt.org.  (See Introduction.)

Based on innovations in PIKT 1.19.0 and a reconsideration of earlier existing capabilities, the revised Introduction describes powerful new techniques for enhancing PIKT's effectiveness and easing its configuration and management.

For a more detailed listing of 1.19.0 additions, changes, bug fixes, etc., see the PIKT Changes page, also the distribution ChangeLog.

(The 1.19.0pre beta release news items following have been folded into the PIKT Reference.  If you choose to read the 1.19.0pre announcements, you might want to start with the 1.19.0pre1 item, and read back up from there.)

Thank you for your continuing interest in and support of PIKT.

Enjoy!


[posted 2007/08/09]

Release 1.19.0pre5, 2007/08/09

This is to announce the release of PIKT 1.19.0pre5, a beta release.

Highlights of the fifth pre-release (beta) of the 1.19.0 series (differences from the latest official release, pikt-1.18.2; additional differences from the previous pre-release, 1.19.0pre4, marked in purple):

• Substantially revised the PIKT Reference, adding many more examples (including links to new web pages at pikt.org detailing function usage), expanding on several sections, and updating to reflect details in recent software versions.
• piktc '-x' & '-X' operations may now piggyback onto other piktc operations (e.g., '-i'), so that one can now, for example, install and execute a post-install command in one go.
• Added a new piktc & pikt command-line option, '-U', for running in "urgent mode" (where no lock file blocks operation).
• Added a new piktc command-line option, '-p#', for pausing # seconds between successive piktc operations.
• Added the '-p#' (pause) option to piktx.
• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added the doexec Pikt script statement.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways.
• Added several new script functions: $status(), $mailcmd(), $lpcmd().
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Implemented the retention of history info (in .hst files) in script quit situations.
• For the #age() & #fileage() functions, added the option to specify a file path argument (instead of, as before, some date arguments).
• In 'output log' statements, the logfile name may now be a computable string.
• 'piktc -G' debug output is now much more useful and relevant.
• Improved error handling and logging.
• Fixed some issues that broke authentication on 64-bit systems.
• Fixed a FreeBSD compile problem.
• Minor bug fixes.
• Made other code improvements.

We have substantially revised the PIKT Reference.  More examples were added, including links to newly created web pages at pikt.org detailing Pikt function usage.  (See Numerical Functions and String Functions.)  Several sections were expanded, and in general, everything was brought up to date with the latest software versions.

We also did a major overhaul of the PIKT Introduction pages at pikt.org.  The revised Introduction describes powerful new techniques for enhancing PIKT's effectiveness and easing its configuration and management.

We have added a new #age()/#fileage() variant, for specifying a file name directly instead of (as before) specifying a file's date attributes.

The release of pikt-1.19.0 official is further delayed, mainly due to the arduous work of expanding and updating the documentation both on-line and off.  We still have to test the latest version against several Linux distros, also FreeBSD, and maybe also Solaris.  (A PIKT port to the Macintosh platform is planned for this winter.)  Please be patient a while longer...


[posted 2007/04/17]

Release 1.19.0pre4, 2007/04/17

This is to announce the release of PIKT 1.19.0pre4, a beta release.

Highlights of the fourth pre-release (beta) of the 1.19.0 series (differences from the latest official release, pikt-1.18.2; additional differences from the previous pre-release, 1.19.0pre3, marked in purple):

• piktc '-x' & '-X' operations may now piggyback onto other piktc operations (e.g., '-i'), so that one can now, for example, install and execute a post-install command in one go.
• Added a new piktc & pikt command-line option, '-U', for running in "urgent mode" (where no lock file blocks operation).
• Added a new piktc command-line option, '-p#', for pausing # seconds between successive piktc operations.
• Added the '-p#' (pause) option to piktx.
• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added the doexec Pikt script statement.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways.
• Added several new script functions: $status(), $mailcmd(), $lpcmd().
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Implemented the retention of history info (in .hst files) in script quit situations.
• In 'output log' statements, the logfile name may now be a computable string.
• 'piktc -G' debug output is now much more useful and relevant.
• Improved error handling and logging.
• Fixed some issues that broke authentication on 64-bit systems.
• Fixed a FreeBSD compile problem.
• Minor bug fixes.
• Made other code improvements.

When using the pikt '-T' (Test) command-line switch, or if the alarm status is set to 'testing', alarm 'exec' and 'exec wait' statements become effectively 'output' (or 'output mail'), and command strings are reported and/or logged rather than executed.  But what about the following situation?

dmesg_scan(BYPASSES)

        init
                status =piktstatus
                level =piktlevel
                task "Scan the dmesg output for troublesome or noteworthy entries"
                input proc "if [ -e =hstdir/log/dmesg=piktalert=_.bak ]; then
                           =diff =hstdir/log/dmesg=piktalert=_.bak
                           =hstdir/log/dmesg=piktalert | =egrep '>' |
                           =cut -b 3- 2>/dev/null;
                           else =cat =hstdir/log/dmesg=piktalert 2>/dev/null; fi"

        begin
                exec wait "=dmesg | =uniq > =hstdir/log/dmesg=piktalert"

        rule
                [... input processing follows ...]

In the 'begin' section 'exec' statement, the intent is to send dmesg output to a file, which is then used as script input in the 'input proc' statement. In testing mode, the 'exec' would in fact not execute, there would be no saved dmesg output, and the script would be rendered useless.

To fix this, we have added a new script statement, 'doexec', to force command execution in all cases.  If instead you have

                doexec wait "=dmesg | =uniq > =hstdir/log/dmesg=piktalert"

the dmesg output will be written to the file whether or not the script is in testing mode.

So, use 'doexec' where essential to the script operation and ordinary 'exec' where the indicated command execution is optional (or for safety's sake during the script development and testing phase you want a command to be reported rather than executed).

Suppose a script is in the middle of processing new logfile input when it encounters a 'quit' (or 'die') statement.  Before pikt-1.19.0pre4, all history info (in the alert .hst file) for that script would be lost, including the current log file position.  The effect of this would be that in the next script run, there being no saved log file position, the script would start over and begin input processing at the very beginning of the log file.  Very annoying!

Now, in pikt-1.19.0pre4, history info (in .hst files) is retained in script quit situations.  So, for example, suppose a script begins input processing at line 500 in a 600 line log file.  At line 550, say, the script quits for some reason.  The next time the script runs, it will again begin input processing at line 500 (and not at the very beginning of the log file).

For 'output log' statements, we have implemented computable logfile names.  You are no longer forced to use a fixed logfile name string, for example,

                output log "=logdir/SyslogKernelScan.log" $inlin

Instead, you could generalize this to, say,

                output log "=logdir/" . $alarm() . ".log" $inlin

So if you used this macro

output_alarm_log(M)     output log "=logdir/" . $alarm() . ".log" (M)

in the SyslogKernelScan alarm script, the logfile name would resolve to

                output log "=logdir/SyslogKernelScan.log" $inlin

as above, but in the SyslogCriticalScan script, it would resolve to

                output log "=logdir/SyslogCriticalScan.log" $inlin

and similarly for other Syslog*Scan scripts.

Computable logfile names open up all sorts of possibilities, for example,

                output log "=logdir/" . $proc . $alarm() . "=piktalert=_.log"
                           $inlin

which might result in a logfile named

                /pikt/var/log/firefox-binRunawayCPUProcsStatsUrgent.log

or, instead of 'firefox-bin', some other arbitrary process name.

'piktc -G' output is now much more useful and relevant.  In particular, it will now report each file preprocessing as it happens, also complete authentication information, as in

# piktc -ivG +A \=alerts +H copenhagen

Apr 17 01:54:41 copenhagen piktc[32016]: [ID 0 DEBUG] (../../../src/piktc/piktc.c,
line 1089, preprocess()) preprocessing file /pikt/lib/configs/systems.cfg
Apr 17 01:54:41 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/include.c, line 53, instrmopen()) preprocessing file
/pikt/lib/configs/systems/down_systems.cfg

...

Apr 17 01:54:47 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/include.c, line 53, instrmopen()) preprocessing file
/pikt/lib/configs/alarms/test_alarms.cfg
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 0 DEBUG] (../../../src/piktc/piktc.c,
line 1089, preprocess()) preprocessing file /pikt/lib/configs/alerts.cfg

processing copenhagen...
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 1 INFO] probing rpcinfo on copenhagen
Apr 17 01:54:47 copenhagen piktc[32016]: [ID 1 INFO] program 392205847 version 1
ready and waiting
installing file(s)...
Apr 17 01:54:50 copenhagen piktc[32016]: [ID 1 INFO] install_file request to host
copenhagen
Apr 17 01:54:50 copenhagen piktc[32016]: [ID 0 DEBUG]
(../../../src/piktc/rpcclnt.c, line 2510, get_key()) key (keysan) is
59b8a3f4cd6a15422c8e6d4b8465af2f, keysum
is 1dcd8112e16df70c8e4ddb433f02a461, keyenc (keyencsan) is
v....[..u..3A}..2..L\.......N+.?, keyenclen is 32

...

At pikt.org, we use PIKT as a content management system (CMS) for several web sites.  When generating and installing web pages, piktc can plow through hundreds and hundreds of configuration files and takes minutes to complete.  With the revised 'piktc -G' operation, we can now monitor the progress of piktc as it goes about its file preprocessing.  Equally important, if piktc were to hang on some #include'd process, we can now use 'piktc -G' to determine the point of the hang.

After installing some new 64-bit Linux systems at pikt.org, we found that piktc master to piktc_svc slave authentication and encryption was broken in some instances.  We have, for the most part, fixed that.  (We have not, however, fixed the problem of authenticating from a 64-bit piktmaster to 32-bit slave systems.  There are workarounds, in particular setting auth_encryption_type to 0 in both master and slave PIKT.conf, but this is not the best long-term solution.  We are still working on a more general fix.)

Finally, previous releases in the pikt-1.19.0pre* series would not successfully compile on systems running the latest FreeBSD.  We have fixed that.

The release of pikt-1.19.0 official has been delayed.  There are so many new features and twists in the pikt-1.19.0pre* series that it will take a while longer to document all the new PIKT capabilities.  In the meantime, we encourage users, guided by the notes in this NEWS file, to play with all the recent new features and report back any problems and suggestions before the impending official PIKT release.


[posted 2007/01/22]

Release 1.19.0pre3, 2007/01/22

This is to announce the release of PIKT 1.19.0pre3, a beta release.

Highlights of the third pre-release (beta) of the 1.19.0 series (differences from the latest official release, pikt-1.18.2; additional differences from the previous pre-release, 1.19.0pre2, marked in purple):

• piktc '-x' & '-X' operations may now piggyback onto other piktc operations (e.g., '-i'), so that one can now, for example, install and execute a post-install command in one go.
• Added a new piktc & pikt command-line option, '-U', for running in "urgent mode" (where no lock file blocks operation).
• Added a new piktc command-line option, '-p#', for pausing # seconds between successive piktc operations.
• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways.
• Added several new script functions: $status(), $mailcmd(), $lpcmd().
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Improved error handling and logging.

In many of your alarm scripts, you might be running instances of piktc, either in the script 'input' statement, else in an 'exec' or 'exec wait' statement (or possibly other ways), each of which would apply a lock file to block other piktc runs.  So your current command-line piktc operation might fail with the complaint

Jan 18 15:23:20 vienna piktc[29375]: [ID 2900 ERROR]
(../../../src/piktc/piktc.c, line 408, main()) /pikt/etc/piktc.lock found!
Another piktc session may be in progress.  Try again later (else rm the
/pikt/etc/piktc.lock lockfile).

But what if you had an urgent piktc operation that you needed to run, no matter what?  Or what if you are confident that in no way should your current command-line piktc operation, say

# piktc -ivT +A Test +H vienna

interfere with another piktc operation (including one launched by a fellow sysadmin elsewhere on the network)?

Or suppose that, while Pikt scripts are launching automatically in the background (by way of the PIKT scheduling daemon, piktd), you want to run a Pikt script interactively at the command line, say

# pikt +A DownSystems

(a script to poll all systems for signs of crashes or network downages)?  A script running in the background might interfere with the current DownSystems run attempt, and a similar error message would appear on-screen announcing the run failure and warning of a blocking lock file.

Now, you may overcome these lock file blocks using the '-U' option.  So, for example, you might do

# piktc -ivTU +A Test +H vienna

or

# pikt -U +A DownSystems

and either would run, regardless of any other PIKT activity elsewhere on the network.

Note that you should not get in the habit of using '-U' in a knee-jerk fashion or unthinkingly.  Often there are good reasons to block concurrent piktc or pikt operations.  Try to use '-U' only in situations of special urgency or where you are fully confident that forging full speed ahead will not get you into trouble.

We anticipate releasing pikt-1.19.0 official in the very near future.  We encourage users to play with this and other recent new features and report back any problems and suggestions before the impending official PIKT release.


[posted 2007/01/16]

Release 1.19.0pre2, 2007/01/16

This is to announce the release of PIKT 1.19.0pre2, a beta release.

Highlights of the second pre-release (beta) of the 1.19.0 series (differences from the latest official release, pikt-1.18.2; additional differences from the previous pre-release, 1.19.0pre1, marked in purple):

• piktc '-x' & '-X' operations may now piggyback onto other piktc operations (e.g., '-i'), so that one can now, for example, install and execute a post-install command in one go.
• Added a new piktc command-line option, '-p#', for pausing # seconds between successive piktc operations.
• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways.
• Added several new script functions: $status(), $mailcmd(), $lpcmd().
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Improved error handling and logging.

Before, if for example you wanted to install a new aliases file, then run the newaliases command, you would have to do it in two separate piktc operations, something like this:

# piktc -iv +F =aliases +H vienna ...

processing vienna...
installing file(s)...
/etc/aliases installed

...

# piktc -xv +C "=newaliases" +H vienna ...

processing vienna...
executing command(s)...
"=newaliases" executed

...

You may now install and execute in a single piktc command as follows:

# piktc -ixv +F =aliases +C "=newaliases" +H vienna ...

processing vienna...
installing file(s)...
/etc/aliases installed
executing command(s)...
"=newaliases" executed

...

'-x' (also '-X') may be combined with many other piktc options, such as '-B' (for restoring from backup), '-e' (for enabling alerts), '-t' (deleting files), and so on.

Note that, when combined with other piktc operations in this way, commands are always exec'ed after the other operation.  (So, for example, 'newaliases' would always be exec'ed after the aliases file install.)

In certain situations, for example restarting server processes in a complex production environment, you might want to allow some arbitrary time between restarts.  That is to say, if you did something like this:

# piktc -x +C "=svcfoo restart" +H servers

(or even more so, with '-X', exec without wait), the svcfoo restarts might happen in such rapid succession that problems might result.

With the new '-p#' command-line option, you may now insert an arbitrary pause of # seconds between any successive piktc operation (from system to system).  So, for example, you might do this:

# piktc -xp15 +C "=svcfoo restart" +H servers

With that command, piktc would send the '=svcfoo restart' command to the first server, then pause for 15 seconds, then send the restart command to the second server, then pause 15 seconds, and so on.

You may add a '-p#' pause to any piktc operation, not just command execs ('-x' & '-X').

(Note that the before, '-p' was used for PIKT.conf installs.  You would now use 'piktc -Q' for that operation.)

Finally, we have added several new Pikt script functions, including $status(), $mailcmd() & $lpcmd().

In your Pikt scripts, you might now do something like this:

        rule
                if $status() eq "debugging"
                        output piktlog "[some diagnostic output]"
                fi

Or this:

        rule
                if $status() eq "suspended"
                        output mail "$alarm() is suspended"
                fi

Or suppose for some reason you don't want to bother one or more fellow sysadmins with certain alert messages.  You might have

        rule
                if $mailcmd() !~ "tom|dick|harry"
                        output mail "[some message]"
                else
                        output piktlog "[some message]"
                fi

So, if you have specified the current alert's mailcmd (in alerts.cfg) to include the email addresses for tom, dick, and/or harry, the given message string would not be sent; rather, that message string would be logged.  (Perhaps other message strings in that same alarm script might be sent to everyone, including tom, dick & harry.)  Only if mailcmd excluded tom, dick, and/or harry would that particular message string be emailed (to other sysadmins or personnel listed in the mailcmd string).

It's a good bet that pikt-1.19.0 official will be released soon.  We encourage users to play with all of these new features and report back any problems and suggestions before the impending official PIKT release.


[posted 2007/01/08]

Release 1.19.0pre1, 2007/01/08

This is to announce the release of PIKT 1.19.0pre1, a beta release.

Highlights of this beta release (differences from the latest official release, pikt-1.18.2, marked in purple):

• Introduced several new alarm status settings: suspended, testing, debugging.
• Implemented a new built-in define, pikttest.
• Reformulated the '-T' command-line option to activate the new pikttest define, also to report actions rather than exec them, and in general to set up special test environments.
• Added several new built-in macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, =piktalways.
• Alarm status & severity level may now be specified alert-wide in alerts.cfg.
• Repositioned 'input' statements in the run-script sequence (from before to just after the begin section).
• Improved error handling and logging.

Most of the recent PIKT development has been devoted to deepening and easing the administration of test environments.  What follows is rather advanced material.  PIKT beginners should probably ignore many of these new features and only make use of them later when they are experienced and have greater understanding of the PIKT system as a whole.

Before, there were just two alarm status settings: active & inactive.  Now there are three more:  suspended, testing & debugging.

Suspended status is like inactive status.  Alarm scripts don't run in either case.  Here is the difference:  Suspended status is always logged, while inactive status is only logged if verbose_log (in PIKT.conf) is set to true.  (You might then schedule a log scanning script to remind you of suspended alarms on a regular basis.)

In testing status, alarm 'exec' and 'exec wait' statements become effectively 'output' (or 'output mail'), and command strings are reported and/or logged rather than executed.

In debugging status, it's as if the 'pikt -G' debuG option were set but only for the scope of that alarm.  In debuG mode, additional debugging information is output to stdout or logged.

A new built-in PIKT define has been implemented, pikttest.  It operates much like a regular test define, but with the following difference:  You would set an optional and user-specified test define in defines.cfg using 'test TRUE' and elsewhere using '#setdef test = TRUE'.  You might also specify 'test FALSE' in defines.cfg, and undefine test elsewhere using '#setdef test = FALSE'.  With pikttest, however, the piktc command-line option '-T' globally sets pikttest to TRUE, and once set, it remains set, i.e., cannot be changed in defines.cfg or anywhere else using #setdef.

The 'piktc -T' and pikttest tandem is therefore just a quicker and more convenient way to activate test mode globally.  Presumably you would have

#ifdef piktttest

        ...

#endifdef

positioned at various places around your PIKT configuration to activate (or not) special testing environments.  'piktc -T', together with the pikttest define, allows you to conveniently enter test mode site-wide.

Before, the '-T' command-line option was used during the PIKT 'make check' to test PIKT operations after the binary build but before the binary installation.  Now, '-z' performs that function, and '-T' has been reformulated to set general test environments for any PIKT binary operation.

So, for example, 'piktc -T' sets the global, built-in pikttest define (invariably) to TRUE; sets the new =pikttest built-in macro to "test" (or some other string you set in PIKT.conf using the pikttest_substitution parameter; otherwise, the =pikttest macro defaults to the null string); and appends '-T' to any pikt command string that piktc writes to piktd.conf.

'piktd -T' logs pikt commands at the specified times in piktd.conf but doesn't actually exec them.

'pikt -T +A Foo' effectively forces a 'status testing' across all alarms in the Foo alert group (and therefore command strings are reported and/or logged rather than executed).

('piktc_svc -T' has no special effect at this time.)

We have added several new pre-defined, built-in PIKT macros: =piktalert, =piktalarm, =piktstatus, =piktlevel, =piktprogram, =piktfile, =piktobject, =pikttest, and =piktalways.

=piktalert and =piktalarm resolve to the alert and alarm in the current piktc operation.  =piktalert is like the Pikt language function $alert(), and =piktalarm is like the $alarm() function, except that you may reference the macros in the Pikt script init section (while referencing $alert() or $alarm() in the init section would result in error).

Likewise, =piktprogram, =piktfile, and =piktobject resolve to the current program stanza (in programs.cfg), file stanza (in files.cfg), and objects stanza (in objects.cfg) respectively.

You may now specify alarm status and severity levels on a per-alert basis in alerts.cfg.  For example, in your Urgent alerts specification (in alerts.cfg), you might have

Urgent

...

#ifndef pikttest
        status          active
#elsedef
        status          testing
#endifdef

        level           urgent

...

Then, for any alarms you specify (in alarms.cfg), you might have

ScanSyslog

        init
                status =piktstatus
                level =piktlevel

...

When the ScanSyslog alarms is installed on the PIKT slave system, this would actually be written as

ScanSyslog

        init
                status testing
                level urgent

...

if 'piktc -T' were used and therefore 'pikttest = TRUE' were in effect.

The combination of specifying status and level in alerts.cfg and referencing =piktstatus and =piktlevel is thus a handy means of enforcing status and level consistency across all alarms in the alert group.  Note that you are not required to use =piktstatus and/or =piktlevel in your alarm definitions.  Override with specific status and level settings on a per-alarm basis if you wish.

With the new =pikttest macro, in alerts.cfg you might do something like the following:

SysAdminsUrgent=pikttest

#ifndef pikttest
        timing
                        35 */2 * * * 5
#elsedef
        timing          =testtiming(40)
#endifdef

        mailcmd         "=mailx -s 'PIKT Alert on =pikthostname: Urgent' =sysadmins-urgent"

        lpcmd           "=lp =piktprinter"

#ifndef pikttest
        status          active
#elsedef
        status          testing
#endifdef

        level           urgent

        alarms

#ifndef pikttest

                        ProcessSystemDead
                        LoadAverage
                        ProcZombieCounts
                        DmesgRedFlagsScan

#elsedef

                        CPUUsage

#endifdef

Using 'piktc -iv +A SysAdminsUrgent +H all', you would install a SysAdminsUrgent alert on all systems with the alarms ProcessSystemDead, LoadAverage, ProcZombieCounts, and DmesgRedFlagsScan, with all alarms in active status, and to run at the timings indicated.

Using 'piktc -ivT +A SysAdminsUrgentTest +H all', you would install a special test-mode SysAdminsUrgentTest alert on all systems with just the CPUUsage alarm, in testing status, and to run at the special =testtiming(40) interval (where =testtiming is a PIKT macro defined (in macros.cfg) as, say,

testtiming(M)   (M) 0-6/2 * * * 1

Presumably, you would also specify (in macros.cfg) the =sysadmins-urgent mail-recipient macro to send SysAdminsUrgent alert messages to all the usual people, but for SysAdminsUrgentTest, send test alert messages only to the =piktadmin (just one or maybe two persons, also specified in macros.cfg).  These are advanced topics, and beyond these hints we will have nothing more to say about them here.

The =piktalways macro is, like the =piktnever macro, used for alert timing specifications in alerts.cfg.  With a =piktalways timing (translating to '* * * * * 0' in the PIKT slaves piktd.conf), an alert would run every minute therefore.

Before, alarm input would be opened just before the begin section of the Pikt script.  Now, alarm input is opened just after the begin section and right before any rule statements.  This change now makes possible things like:

DmesgScan

        init
                status =piktstatus
                level =piktlevel
                task "Scan the dmesg output for new or noteworthy entries"
                input proc "if [ -e =hstdir/log/dmesg.bak ];
                            then =diff =hstdir/log/dmesg.bak =hstdir/log/dmesg |
                              =egrep '>' | =cut -b 3- 2>/dev/null;
                            else =cat =hstdir/log/dmesg 2>/dev/null; fi"

        begin
                exec wait "=dmesg | =uniq > =hstdir/log/dmesg"

        rule
                if (    $inlin =~~ "=redflags"
                     || $inlin =~~ "=yellowflags"
                   )
                        leave
                else
                        next
                fi

        ...

        [rule sections follow]

        ...

        end
                exec wait "=mv =hstdir/log/dmesg =hstdir/log/dmesg.bak"

In this code, in the begin section dmesg output is first captured to the file =hstdir/log/dmesg.  Then the saved dmesg file is diffed against a previously saved dmesg.bak file in the 'input proc' statement.  The effect is to feed to the rules statements only new dmesg output (new since the last script run).  (=redflags and =yellowflags are regular expressions set to, for example, 'fail|error|die|...' in macros.cfg.)  Note that in the end section, the latest dmesg file is mv'ed to dmesg.bak in anticipation of the next DmesgScan script run.

There is much more that could be said about all these new PIKT features.  Look for a fuller accounting in the PIKT Reference when the next version is published with the official PIKT 1.19.0 release.  Please also visit https://pikt.org in the weeks and months ahead where we will give additional explanations and examples of use.

As always, remember:  pikt-1.19.0pre1 is beta code.  One purpose of issuing pre-releases is to give users the chance to test beta code before we adopt it in official releases.  So, we encourage users to play with all of these new features and report back any problems and suggestions.


[posted 2006/11/06]

Release 1.18.2, 2006/11/06

This is to announce the release of PIKT 1.18.2, a minor bug-fix release.

We have fixed a problem that broke the pikt script interpreter in Gentoo Linux, a problem related to logfile input and changing POSIX standards, and a bug in the code for specifying piktd timings.

It used to be that (for example) 'tail +100c' would show output from the 100th character onward.  Under the latest POSIX standards, that no longer works in certain situations, and (for example) 'tail --bytes=+100' is now preferred.  This change caused the input.c file's openinput() function to break.  This has now been fixed.  If for some reason you need to revert to the previous tail standard, substitute the commented out line in src/piktd/input.c:

sprintf(inputcmd, "%s +%ld%c %s%s%s", tailcmd, poscurr+1, 'c',
inputsource, FILTER ? " | " : nullstring, FILTER ? FILTER : nullstring);

When specifying a range of step-wise timings in alerts.cfg, as in (for example)

0-59/10 * * * * 2

PIKT would complain, incorrectly, that

Nov  4 13:37:08 hamburg piktd[30736]: [ID 9900 ERROR] (../../../src/piktd/piktd.c, line 286,
readconf()) for alert Critical, +/- drift 2 equals or exceeds minimum alert interval 1

when in fact, the minimum alert interval in the above example should be 10.  This has now been fixed.

(Note that the more correct specification

0-50/10 * * * * 2

or, better,

*/10 * * * * 2

would not have generated the "error".)


[posted 2006/09/10]

Release 1.18.1, 2006/09/10

This is to announce the release of PIKT 1.18.1, a minor bug-fix release.

We have fixed several header file declarations and one other small problem that broke the compile in Red Hat Linux Fedora Core 5.

We have updated the HTML pages in the doc directory, also the CSS stylesheet, bringing them in conformity with the latest on-line versions at pikt.org.


[posted 2005/07/04]

Release 1.18.0c, 2005/07/04

This is to announce the release of PIKT 1.18.0c, another doc-fix release.

We have reformatted the .html docs using CSS.  Ads and other distractions have been removed.  The intro directory has also been removed.  Users must now visit https://pikt.org for the intro pages.  Now, just the ref and tutorial directories remain in the distribution docs.

No code has changed in pikt-1.18.0c, only the documentation.


[posted 2005/01/18]

Release 1.18.0b, 2005/01/18

This is to announce the release of PIKT 1.18.0b, another doc-fix release.

In the "#set, #setenv, #unset, #unsetenv" section of the 1.18.0 Reference, due to an HTML coding error, one of the examples was displayed incorrectly.  We have fixed this.

No code has changed in pikt-1.18.0b, only the documentation.


[posted 2005/01/12]

Release 1.18.0a, 2005/01/12

This is to announce the release of PIKT 1.18.0a, a doc-fix release.

In the 1.18.0 INSTALL file, we inadvertently left in comments suggesting that the INSTALL is not current.  In fact, it is up-to-date and accurately reflects changes introduced in pikt-1.18.0.  So, we simply removed those misleading remarks.

No code has changed in pikt-1.18.0a, only the documentation.

We regret this minor error and thank you for your patience.


[posted 2005/01/10]

Release 1.18.0, 2005/01/10

We are pleased to announce the release of PIKT 1.18.0!

Highlights of this new release (significant changes since 1.17.0):

• piktc_svc can now bind to a specific system port, facilitating PIKT's use in firewalled environments.
• Implemented the new piktc -w & -W vieW-file options.
• Implemented the new piktc +/-E option to set/unset environment variables.
• Implemented #unset & #unsetenv directives, and new #set & #setenv variants.
• Implemented new #setdef and defines.cfg variants.
• Added optional alarm message sorting by syslog level.
• Made other code improvements.

For a more detailed listing of 1.18.0 additions, changes, bug fixes, etc., see the Changes page, also the distribution ChangeLog.

Thank you for your continuing interest in and support of PIKT.

Enjoy!

For more detailed information about the 1.18.0 beta series and older news, see Developer's Notes.  For some especially important old news, see the following.


[posted 2003/05/15]

After a long association with the Graduate School of Business of the University of Chicago, where PIKT was initially hatched, the PIKT Project left the Business School in January 2003.  PIKT is now an independent project, no longer associated with the U of C's Business School, although it does retain ties with the University.  (The University has trademark rights to the PIKT name and owns the pikt.com domain.  The PIKT Project owns the pikt.org domain, and PIKT authors retain copyrights over their code.)  By agreement with the University, "core PIKT"--essentially everything in the pikt-current.tar.gz file up til now--is and will remain distributed under the GNU GPL.

Please note the Project's permanent home:  this site.  (The University has a redirect page at the legacy pikt.uchicago.edu address, but that page will not remain indefinitely.) We are slowly awakening from our recent dormancy.  We are reviewing the code with the intent of moving to develop the long-awaited PIKT Version 2.0.  We are also considering various options for possibly providing paid tech support and commercial PIKT add-ons and extensions.  As stated, however, "core PIKT" will remain GPLed, and development of the free, non-commercial core will continue.

We still have much setup to do, including recreating the various pikt- user and developer lists.  So little time, so much to do...

Rest assured that the PIKT Project is still alive.  Watch this space (here and the NEWS page at this site) for future developments.

Thank you for your patience and continuing interest in PIKT!