About host.cf
|
syntax
|
- Whitespace is generally ignored, unless otherwise noted.
- boldface denotes keywords.
- [brackets] denote optional keywords.
- Separators (|) denote mutually exclusive keywords.
- Comments begin with a # symbol, and may appear anywhere.
Comments must be terminated with newlines.
<name> : [a-zA-Z0-9\.+%@_-]+
|
host.cf defines HostClasses, which are distinct sets of hosts
with common basic characteristics, Groups, which are sets of hosts that are monitored
for a given Check, and Group Aliases,
which duplicate a Group under another name.
A preparsing utility is available to
verify host.cf before installation.
HostClasses
|
syntax
|
class <name> {
hosts {
<name>
[...]
}
[check on <name> schedule]
[alert on <name> alertplan]
}
|
About HostClasses
A class stanza defines the default check and alert
characteristics of its member hosts. Any host monitored by the
scheduler must be defined in exactly one HostClass.
Dependencies
- The Schedule specified by the check keyword in a hostclass
definition must be defined in schedule.cf.
- The Alert Plan specified by the alert keyword in a hostclass
definition must be defined in schedule.cf.
HostClass Stanza Keywords
class <name>
|
Define a new HostClass, which defines the default Check
Schedule and Alert Plan for its hosts. The HostClass all is
reserved.
|
hosts <name>
|
Define the set of hosts in the HostClass. A host must be a member of
exactly one HostClass in order to be monitored.
|
check on <name> schedule
|
Define the default Check Schedule
for the members of the HostClass. Individual Checks can override this default.
|
alert on <name> alertplan
|
Define the default Alert Plan
for the members of the HostClass. Individual Checks can override this default.
|
Examples
- In the following example, server1 and server2
will by default have all of their Checks run on
the critical Schedule and alert notifications will be
transmitted according to the critical Alert Plan.
class servers {
hosts {
server1
server2
}
check on critical schedule
alert on critical alertplan
}
Groups
|
syntax
|
group <name> {
<name>
[...]
}
|
About Groups
A Group is a set of zero or more hosts. A host may be a member of
zero or more Groups. If a host is specified in a Group but not
defined in a HostClass, it may be silently ignored.
Group names are used to select which Checks are executed for
which hosts. A Check is executed on a host when the following
conditions are met:
- A host is a member of a Group.
- There is a corresponding Check
defined in check.cf with the same name as that Group.
- The host is defined in a HostClass.
Dependencies
- The hosts specified in a Group definition must be defined by a
Host Class definition before the Group definition that references
them.
Group Stanza Keywords
group <name>
|
Define a new Group. The Group name all is reserved.
|
Examples
- In the following example, if a Check named http is
defined, it will be run for hosts server1 and
server2.
group http {
server1
server2
}
Group Aliases
|
syntax
|
alias <name> to <name>
|
About Group Aliases
A Group Alias is simply another name for the identified set of hosts.
This is useful in order to have multiple Checks run on the same set
of hosts without having to maintain multiple identical Groups.
Dependencies
- The original Group specified in a Group Alias definition must be
defined before the Alias definition that references it.
Group Alias Stanza Keywords
alias <name> to <name>
|
Define a new Group Alias. The name by to is the name of the
"new" Group.
|
Examples
- In the following example, the imap Group is aliased to
pop and smtp so that imap, pop, and smtp may
be checked on the same set of hosts.
alias imap to pop
alias imap to smtp
- The following is equivalent to the first example:
alias imap to smtp
alias smtp to pop
Next: check.cf
$Date: 2006/11/19 14:16:53 $
$Revision: 0.3 $
|
keywords
alert on alertplan
alias
check on schedule
class
group
hosts
|