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 #endifThe '=aliases' macro would then resolve to '/etc/mail/aliases' on gentoo systems, and '/etc/aliases' on redhat systems.
<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.
<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 hyderabadAnd 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 solaris25The 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> // dittoYou 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.
|prev page||1st page||next page|