systems.cfg

This config file specifies system hostnames, host aliases, and host groups. You use these systems specifications together with the '#if <machine class>' preprocessor directive to customize your PIKT configurations on a per-machine(s) basis and/or by operating system.

For example, here is a simple systems.cfg:

///////////////////////////////////////////////////////////////////////////////
// 
// PIKT systems.cfg -- host systems, aliases, and groups
// 
///////////////////////////////////////////////////////////////////////////////

// hosts

gentoo  hosts           copenhagen
                        rouen

redhat  hosts           barcelona

///////////////////////////////////////////////////////////////////////////////

// host aliases

copenhagen
        aliases         copenhagen.pikt.org     
                        piktmaster

rouen
        aliases         rouen.pikt.org
                        webserver

barcelona
        aliases         barcelona.pikt.org

///////////////////////////////////////////////////////////////////////////////

// host groups

linux
        members         gentoo
                        redhat

nfsclient
        members         rouen
                        barcelona

///////////////////////////////////////////////////////////////////////////////

Suppose in macros.cfg (or one of its #include files) you specify:

aliases
#if gentoo
        /etc/mail/aliases
#elsif redhat
        /etc/aliases
#endif

The '=aliases' macro would then resolve to '/etc/mail/aliases' on gentoo systems, and '/etc/aliases' on redhat systems.

In systems.cfg, firstly, all hosts systems should be registered, usually by operating system. Host registration stanzas are signaled by the "hosts" keyword:

<osname>
        hosts         <host> <host> <host> ...

Next, as an option, come host aliases, signaled by the "aliases" keyword:

<host>
        aliases       <alias> <alias> <alias> ...

The <host> in an aliases stanza must be registered in a previous hosts stanza. Note that these hosts aliases may be, but don't have to be, DNS aliases (specified in CNAME records). PIKT host aliases may be anything you want.

Finally, also as an option, come host groups, signaled by the "members" keyword:

<group>
        members       <host|alias|group|osname>
                      <host|alias|group|osname>
                      ...

Here, too, member hosts, aliases, groups, and osnames must be pre-registered.

The usual way of registering hosts is by operating system, then subcategorizing by OS version in host groups as necessary. It is possible, however, to do it the opposite way--registering by OS version subcategories, then aggregating in a host group stanza. For example, this is one way to register hosts:

// hosts

solaris
        hosts           newdelhi bangalore amritsar raipur agra bhopal
                        bombay madras srinagar puri calcutta hyderabad

...

// host groups

solaris27
        members         newdelhi bangalore amritsar raipur agra bhopal

solaris26
        members         bombay madras srinagar puri

solaris25
        members         calcutta hyderabad

And here is another way you can do it:

// hosts

solaris27
        hosts           newdelhi bangalore amritsar raipur agra bhopal

solaris26
        hosts           bombay madras srinagar puri

solaris25
        hosts           calcutta hyderabad

...

// host groups

solaris
        members         solaris27 solaris26 solaris25

The second way involves less typing and helps ensure against your forgetting to subcategorize one or more hosts.

There is an automatic, implicit definition of so-called "non" groups (set complements) for every explicit OS and hostgroup defined in systems.cfg. For example, if you have defined the hostgroup "linux", the "nonlinux" hostgroup--consisting of all PIKT systems not in the "linux" hostgroup--is automatically defined. The implicitly defined "nonnfsserver" group would include all systems not in the "nfsserver" group.

An explicit definition of a "non" group in systems.cfg overrides any implicit definition.

The chief use of the "non" hostgroups is to provide a finer degree of control when specifying 'piktc ... +H ... -H ...'.

A standard PIKT hostgroup is down, as in

down                    // set '-H down' for these

        members
#include <systems/down_systems.cfg>

But what if you have no down systems, i.e., the down_systems.cfg file is empty? That's no problem, because PIKT also supports empty hosts, aliases, and members stanzas. So, you may do things like

aix
        hosts           // empty

...

testsys
        members

...

Although you are advised to list all of your hosts stanzas first, aliases stanzas second, and members stanzas third, you may in fact freely intermix stanzas, and in just about any order.

Therefore, you can prepare #include files, for example linux_systems.cfg, putting all of your linux hosts, aliases, and groups together in one file.

Or you might organize your systems information by organizational unit, for example:

#include <systems/computing_systems.cfg>   // hosts, aliases & groups
#include <systems/engineering_systems.cfg> // ditto
#include <systems/production_systems.cfg>  // ditto
#include <systems/marketing_systems.cfg>   // ditto
#include <systems/finance_systems.cfg>     // ditto

You must still be careful, however, to register hosts and aliases before mention in any host groups. If you do this, for example,

printserver
        members         ... mickey roger yogi whitey ...

#include <systems/linux_systems.cfg>

where the mickey, roger, yogi, and whitey systems are first registered in linux_systems.cfg after the printserver specification--this would be an error.

Also, you must register a hostname in a hosts stanza before registering any aliases for it.

Host and alias (and group) names may include .'s (dots), allowing your setup to span more than one network domain. For example:

// host aliases

turing          aliases         turing.computing.acme.com
                                piktmaster

knuth           aliases         knuth.computing.acme.com firewall
hopper          aliases         hopper.computing.acme.com dnsserver
...

edison          aliases         edison.engineering.acme.com
...

hammer          aliases         hammer.production.acme.com
...

blimp           aliases         blimp.marketing.acme.com
...

drachma         aliases         drachma.finance.acme.com
...

For every system listed in a host (operating system) stanza as a fully qualified domain name, you will probably want to give those hosts aliases, for easier referencing in the config files and at the command line. So, for example, by giving the host "turing.computing.acme.com" the alias "turing", you can use the second shorter form subsequently in all your config files and piktc commands.

Refer to the sample systems.cfg for more examples.

1st page