For ipacc to run, it must be told which hosts perform what
functions, and when. The ipacc supervisor process launches
collection daemons and schedules various processing as required.
The host hostname ... end host block defines the functions
of a particular host. The hostname parameter should be either the
fully qualified domain name of the host (i.e. that displayed by the
hostname command), or the first part of the host name, before the
first '.'.
The daemon source ... statement controls which collector daemons
should be run on the host. Daemons are required for real-time sources
writing flows to ring-buffers, such as the BPF and NetFlow interfaces.
Daemons are run on the host for each source specified. The daemons
are started by the ipacc supervisor process.
The process object ... statement binds a processing of an object
to the host. Objects in this context include source and summary
processing, route-file extraction and file generation. The actual
scheduling of the processing is up to the frequency statements in the
objects' definitions.
The ipacc supervisor process can manage distribution of
configuration files from a master host to a series of slave hosts. To
configure this, provide file ... statements must be included in
the host block of the master host (unless the file is already
mentioned in a process statement), and in the host blocks of all
slave hosts (i.e. the hosts to which the file(s) should be copied),
require file ... statements should be included.
If a file listed in a provide statement is defined in a
route-file or generate block, the appropriate processing will be
run to generate the file. Otherwise, the provide statement simply
indicates the host(s) which have an authoritative copy of the file. See
Configuration file generation.
The provide statement can be used alone to generate files on a given
host; a require statement is only necessary if a file is provided or
generated on another host and must be transferred across before it can
be made available.
Note that starting daemons and processing will be delayed until any files
that must be generated on this host are available. However, files that
are replicated from other hosts will not be checked, and care must be
taken to ensure that remote hosts that provide replicated files have in
fact done so prior to starting ipacc on the local host.
The connect statement specifies the shell command to use to connect
to the host. By default, this is ssh hostname, where
hostname is the name of the host specified in the host
statement. The connect statement allows other commands, e.g.
rsh to be used, or to specify different or additional authentication
parameters to the defaults.
source, summary, route-file and generate blocks
all have a frequency frequency delay statement which states
the frequency with which data should be extracted, and the delay. Both
are specified as
intervals.
The frequency parameter states at what intervals data should be
processed. The delay parameter imposes a delay after the expiry of
that interval before the actual processing is run; this is to allow
processing of earlier stages to complete. Delays have appropriate
defaults if omitted, but these make assumptions that may be invalid for
specific configurations.
The default frequency for data sources is 10 minutes, for summary
blocks one day, for routing table extractions, one hour and file
generation is not scheduled by default.
Logging is done using the log type to level statement, either
globally or within a host block.
The type parameter can be one of file, syslog or email.
The to parameter depends on the type parameter: if type is
file, to is the name of the file to write into; if it is
syslog, to is the facility to send the messages to (e.g.
daemon, local0 etc, see the syslog(3) man page); if it is
email, to is the email address to send to.
level can be one of debug, info, warning, error or fatal.
The log action will match all messages of equal or higher priority to
the level provided.
Multiple log statements can be provided to allow different levels of
logging depending on priority. For example, to log routine stuff to
syslog and email errors, one could use:
log syslog daemon info
log email root error
File specifications can contain
strftime(3) arguments
to write unique files based on time of day.