System Lists

[posted 2000/07/29]

The new 'piktc -L' feature (in the latest 1.11.0 dev releases) is a small but still useful addition to the PIKT toolkit. Like me, perhaps you maintain, or have maintained, files with customized system lists for various purposes. So, at our site for example, we have

/usr/local/etc/hpsys*
/usr/local/etc/lnxsys*
/usr/local/etc/nxtsys*
/usr/local/etc/solsys*
/usr/local/etc/sunsys*
/usr/local/etc/upsys*
...

We would make use of these typically (and when 'piktc -x' isn't suitable for some reason, like when doing PIKT binary installs and all piktc_svc's are down) in for loops like so:

# for sys in `cat /usr/local/etc/solsys`
> do
> echo $sys
> ssh $sys ...
> done

Or, we might refer to `cat <file>` output in our shell and Perl scripts.

Some of these are dynamic lists, generated and updated automatically, while others are specified manually and are now way out of date. In any case, they don't cover all contingencies, for example, when we just want to send commands to the "perf" or "mus" systems, for which there are no comparable lists. And there is no handy way of avoiding systems down or unreachable without editing them out of those files (and hopefully remembering to add them back in when those systems come back up).

Our systems.cfg file, however, is kept continually up-to-date. (We could easily have much of our systems.cfg refer to systems/*_systems.cfg #include files, which themselves are updated by some automatic process, a Pikt script, say.) And it is loaded with custom system lists that, using the new 'piktc -L' option, we can now access in a convenient way at the command line. Excluding down systems is as easy as: 'piktc -L +H ... -H downsys'.

We also have PIKT-generated files like /pikt/lib/objects/PiktHostsSolaris.obj, but these are by no means as many and as varied as the custom host lists that 'piktc -L' can generate directly. Indeed, I might just retire the /pikt/lib/objects/PiktHosts*.obj files altogether, since 'piktc -L' is just so much handier.

It always tickles me when I chance upon a neat new twist to the PIKT paradigm. The uses for this thing really are limited only by your imagination!

On the subject of Partial Configurations, note that just

the piktc binary
a systems.cfg file
a PIKT.conf file
the requisite PIKT directory structure, including a log directory for piktc.log
(did I forget something else?)

should give you 'piktc -L' functionality. To repeat: You don't have to use the whole package. Make use of all or only parts of it as you will. I know of one site where they use PIKT just for files management and remote command execution and don't bother to use the Pikt scripting language and system monitoring functions at all. Now that's flexibility!

For more examples, see Developer's Notes.