Highlights of the third pre-release(beta) of the 1.15.0 series:
- Completely revamped the configs_samples, increasing modularity,
maintainability, clarity, ease of use, comprehensiveness, and accuracy.
- Improved random key generation in rkey.
- Improved script parse error messages.
- Fixed a bug involving omitting a '>' character in #include <file>
directives.
- Fixed a bug where, under very unusual circumstances, changing %foo-style
history value attributes might dump core.
pikt-1.15.0pre3 introduces a complete revamp of the configs_samples.
First off, we have removed all '#ifndef generic ... #endifdef' wrappers.
As a consequence, you may no longer use 'piktc -iv +D generic ...' to extract
a "generic," ready-to-go (in theory) PIKT configuration. Many users run
afoul of the numerous #ifdef and #if constructs in the PIKT configuration.
Debugging a parse error at the #ifdef and #if levels can be a bewildering,
labyrinthian ordeal. #ifdef and #if have important purposes, of course,
but one should use them sparingly.
We are now of the opinion that Pikt scripts should be as simple and
straightforward as practical. We now prefer to hide away as much of the
#ifdef and #if complexity in the *_macros.cfg and *_objects.cfg files as
possible.
If you want to make use of the new-and-improved configs samples, you will
have to edit its pieces into your own configuration by hand. Sorry!
We have also removed all traces of script code and data pertinent to operating
systems other than the ones we actually use on a day-to-day basis: Solaris,
Linux (Debian, Mandrake), and SunOS. We feel that we were doing users of
other OSes a disservice by suggesting direct applicability of our configuration
to their OS environment(s). The fact is, you must take responsibility for
ensuring that your scripts, objects sets, and macro definitions are right for
your situation. Unless we have intimate, ongoing familiarity with an OS,
we can't hope to Get It Right.
We have modularized the configuration. Gone are the big, monolithic .cfg
files of the past. We have instead chopped up the configuration into many
smaller #include files, organized around themes. For instance, all scripts
related to disk monitoring and management are grouped under the separate
file alarms/disk_alarms.cfg. NIS alarms are confined to alarms/nis_alarms.cfg.
The top-level alarms.cfg file is now just a sequence of #include directives:
...
///////////////////////////////////////////////////////////////////////////////
#include <alarms/disk_alarms.cfg>
///////////////////////////////////////////////////////////////////////////////
#include <alarms/dir_system_alarms.cfg>
#include <alarms/dir_user_alarms.cfg>
///////////////////////////////////////////////////////////////////////////////
...
///////////////////////////////////////////////////////////////////////////////
#include <alarms/nis_alarms.cfg>
///////////////////////////////////////////////////////////////////////////////
...
If you don't use NIS, removing it from the configuration is as simple as
commenting out its #include directive, as in
//#include <alarms/nis_alarms.cfg>
or removing that line altogether. (You might also rm the alarms/nis_alarms.cfg
as well.)
Most of the other top-level .cfg files--systems.cfg, files.cfg, objects.cfg,
and programs.cfg--are similarly laid out: a sequence of #include directives
referencing smaller program and data sets organized by subject matter.
(Some more examples: programs/mailquota_programs.cfg, files/sudoers_files.cfg,
files/inetd_conf_files.cfg, objects/proccounts_objects.cfg,
objects/ipaddrs_objects.cfg, objects/sysprocs_debian_objects.cfg, etc.)
One advantage of grouping together into one separate file all scripts
relating to, say, process monitoring and management is that you can see more
clearly what's covered and what's not. In our previous 8,500-line alarms.cfg,
it was difficult to know what's what and where, to say the least. Now, we
can much more easily spot gaps in our coverage, not to mention duplication
of effort.
The macros.cfg files is somewhat of an exception. We continue to confine
OS-specific listings of command paths within separate #include files, as in
macros/unixcmds_solaris_macros.cfg. Most macros are still kept, however,
in one long, monolithic, top-level macros.cfg file. Why? It's because,
unlike the other .cfg files, where the ordering of stanzas doesn't matter,
the sequence in which you define your macros in macros.cfg is important.
If you nest macros, you can't reference one macro inside another unless the
referenced macro was defined earlier in the configuration. Initially, we
had chopped macros.cfg into smaller #include *_macros.cfg files, just like
the other *.cfg files. It just got to be too confusing, however, to order
the macro definitions just right, so we reconsolidated most macro defs back
into the one big macros.cfg file. Within macros.cfg, we have done a better
job of grouping together macro defs by function (grouping together, for
instance, all macro defs relating to script output, or relating to date and
time, etc.).
One benefit of chopping up the configuration into smaller #include files
is that when you make a mistake in your #ifdef ... #endifdef and #if ... #endif
constructs, diagnosing and fixing the resulting parse errors becomes much
easier. It's much simpler following the #ifdef and #if logic through a
500-line .cfg file than a 5,000-line file!
One disadvantage of all of these #include files: It becomes harder to
find individual pieces. Before, you would know to look for an alarm script
in the one alarms.cfg file. Now, exactly where again is that RunawayProc
script located? It's somewhere within the now couple dozen different
alarms/*_alarms.cfg files. We make use of the following find command
extensively:
find alarms -exec egrep -il "runawayproc" {} ; | egrep -iv "diffing|staging|.bak|~"
We might just include a little shell script for this purpose in the official
PIKT 1.15.0 release. (Better still, wouldn't it be nice to have a windowing,
hyper-linking text editor where one could click on an identifier reference
and jump to its definition instantly!)
Another big change: We have redone many of the identifiers, making their
purpose and effect much more obvious. FileStatChkEmergency was renamed
SystemFileNotExistEmergency, for example. MailQueueChkUrgent became
MailQueueLengthyUrgent. Before there were too many "Chk" this and "Chk"
that. What is being "Chk'ed"? We are on a mission (still ongoing) to
make the identifiers as informative as possible.
In addition to all of the above, we have:
- added new macros, scripts, and objects sets
- redone many of the standard scripts, especially in the areas of disk,
process, and log file monitoring
- demonstrated some clever new techniques
- filled in some gaps
- cleaned out all cruft
- clarified the layout
- fixed some outright mistakes and embarrassments
This new-style configs may not be to everyone's taste. You might prefer the
"good old days" where there were just eight basic .cfg files (and perhaps
a few extra #include files like macros/unixcmds_redhat_macros.cfg). No
problem, continue to manage your setup that way if you want.
In fact, in time for the 1.15.0 release, we also hope to redo the
configs_starter. The revamped configs_starter will be done in the "traditional"
manner, with a minimum of #include files and other fanciness. The objective
here will be to offer a kinder, gentler, more easy to understand and
maintain--but much more limited in extent--configuration of a half dozen to
a dozen basic sysadmin and monitoring tasks.
For the 1.15.0 release, we intend to have a "What's New" guide for the
new configs_samples, including an identifier cross-reference between the
old and the new.
The new-style configs lays the basis for the much-longed-for, and much-
delayed PIKT configs "standard library." We might begin work in this area
Real Soon Now.
Moving on to an entirely separate matter, Michel Blanc has sent along his
updated rkey. rkey is not yet finished. The current version outputs line
after line of diagnostic trace messages by default. We haven't decided yet
exactly where we want to include rkey and its component .pm files in the
PIKT distribution. For now, we list all rkey files here:
[code omitted in the interest of saving space]
In order to make use of this, put all four files--rkey, MD5.pm, Random.pm,
and TT800.pm--in your PIKT bin directory.
There is very little in the way of new "core PIKT" code or bug fixes in
this latest beta release. Most of the effort has gone into the
configs_samples revamp and rkey.
We'll have more to say about the new-style configs in messages sent to the
pikt-users list over the next several weeks.
We anticipate releasing PIKT 1.15.0 "official" early in October.
Thanks for reading along this far. And thanks for your interest in PIKT!
