IPASTAT.CONF(5) IPASTAT.CONF(5)
NAME
ipastat.conf -- ipastat(8) configuration file
DESCRIPTION
The ipastat.conf file is a configuration file for ipastat(8). This
file or any other one, specified in the -f option in the ipastat(8)
command line, is read when ipastat(8) starts working.
FILE FORMAT
Almost after each paragraph there is an example. Since IPA distribution
does not have any module, ipa_st_sdb module is used in examples, just
because this was the first statistics module designed for IPA.
General syntax.
Any logical line in the configuration file can be written in several
text lines for indenting purpose. There is not any rule in which line
to place reserved words, arguments and special symbols. If some format
allows one space character (a space character and a tab character),
then as much as needed space characters can be written there for
indenting. All elements in a configuration file are case sensitive. A
configuration file consists of sections, parameters and comments.
Comments.
There are shell-like and C-like comments. If you use a C-like comment
in a shell-like comment, then a C-like comment is ignored.
Example:
# Shell-like comment.
/* C-like comment. */
/*
* Another C-like comment.
*/
Sections and parameters.
A section consists of its name, optional arguments and its body. A sec-
tion's body should be placed in curly braces:
section [[=] argument] {
/* Parameters and sections. */
}
A parameter consists of its name and optional arguments. Every parame-
ter should have the `;' character at the end of its arguments list:
parameter [[=] argument];
The `=' character after the section's or parameter's name is optional.
Some parameters look like variables (it is naturally to use the `='
character for such parameters), another ones look like instructions. In
any case, you can choose a syntax you like more.
An argument can contain strings:
"string"
It is possible to use ``\t'', ``\n'', ``\\'' and ``\"'' sequences to
represent tab, newline, back-slash and double quote characters inside a
string. If it is needed to split a string to several lines, then use
one `\' character at the end of the current line (do not put extra
space characters after the back-slash character). If a string is writ-
ten in several lines without `\' characters, then each newline charac-
ter is added to a string.
Macro variables.
It is possible to define macro variables and then use them almost any-
where in the configuration file:
${variable} = "string";
A name of any macro variable can consist of characters, digits and dol-
lar signs. What is a character is checked with isalpha(3) function,
which uses locale.
A value of any macro variable should be a string, when a macro variable
is expanded then first and last double quotes of its value are removed.
Macro variables can be local or global. A macro variable is global if
it is defined outside any section, else a macro variable is local. A
local macro variables are local for all nested sections and for all
external sections. Local macro variables can hide global ones.
There are some predefined macro variables:
${$} - expands to a `$' character;
${rule} - expands to the name of current rule section;
${limit} - expands to the name of current limit section;
${threshold} - expands to the name of current threshold section.
Any macro variable (including predefined ones) except ${$} can be rede-
fined if needed. It is not recommended to redefine or delete prede-
fined macro variables in modules.
Macro variable ${$} cannot be used for constructing macro variables
names (see an example).
Macro variables are expanded at the moment of their usage and not at
the moment of their definition. Macro variables are expanded also in
strings.
Example:
${a} = "${b}"; # Definition of ${a}.
${b} = "1"; # Definition of ${b}.
param = ${a}; # Expands to 1.
${b} = "2"; # Redefine ${b}.
param = ${a}; # Expands to 2.
param = "${$}{b}"; # Expands to "${b}" (sequence of characters
# inside string).
section {
${a} = "1"; # Definition of local ${a}, which hides
# global ${a}.
${c} = "4"; # Definition of local ${c}.
param = ${a}; # Expands to 1.
subsection {
${a} = "2";# Redefine local ${a}.
${b} = "3";# Redefine global ${b}.
}
param = ${a}; # Expands to 2.
param = ${b}; # Expands to 3.
}
# param = ${c}; <-- Error: ${c} is not defined as global.
Including files.
It is possible to keep configuration information in several configura-
tion files. Files are included with the help of following parameters:
include "/path/file";
include_files "/directory/pattern";
The include parameter includes one file. The include_files parameter
includes some files from the specified directory, names of which match
the given shell pattern.
These parameters can be used anywhere in the configuration file, except
inside modules' sections, and included files will be included at once.
It is possible to include files from included files, and so on. Each
included file should have correctly specified parameters with argu-
ments, comments and sections with arguments, but it can have not closed
sections.
It is possible to use POSIX extended regular expressions as patterns in
include_files parameters, for this set the posix_re_pattern parameter
to ``yes'' before parameters, which include files with POSIX regular
expression patterns, by default the value of this parameter is ``no'':
posix_re_pattern = <boolean>;
This parameter should not be placed in any section.
Included files must be owned by the user, who run ipa(8) and must not
be writable for group and other users. If files are included with the
help of the include_files parameter, then a directory in this parameter
also should have the same properties.
Examples:
posix_re_pattern = yes;
include "/usr/local/etc/ipastat.local.conf";
include_files "/usr/local/etc/ipastat/LAN/.";
First parameter includes one file, second parameter includes each file
in the given directory, the ``.'' POSIX regular expression means any
character.
/* posix_re_pattern = no; */
include_files "/usr/local/etc/ipastat/LAN/*";
Here a shell pattern is used. First string should be uncommented if
previously POSIX regular expressions were used.
Using statistics modules.
There are special statistics modules, which are used for querying sta-
tistics. ipastat(8) uses such external statistics modules with the help
from the special ipa_st_mod API, described in the ipa_mod(3) manual
page.
The st_mod parameter tells ipastat(8) to load the given IPA statistics
module:
st_mod "file_name";
This parameter should not be placed in any section. It is possible to
use several statistics modules at once.
Example:
st_mod "ipa_st_sdb.so";
This parameter loads one statistics module.
Configuring modules.
Documentations for some IPA module should give all information how to
configure it, but usually configuration of some IPA module is inte-
grated to the configuration file ipastat.conf(5).
Each module has a configuration prefix, which is used for distinguish-
ing module's sections and parameters. If there is a parameter like this
one:
prefix:parameter [[=] argument];
then ipastat(8) will try to find a loaded module, which has configura-
tion prefix ``prefix'', then ipastat(8) will give this parameter for
parsing to the found module.
Sections also can have prefixes:
prefix:section [[=] argument] {
/* Module's parameters and sections. */
}
In this case parameters and sections inside such section should be
written without a prefix and this section and all its internal sections
and parameters will be passed to the appropriate module for parsing.
Documentation for some module should describe a module itself, module's
configuration prefix, statistics name and all module's parameters and
sections.
Example:
global {
sdb:db_dir = "/var/db/ipa_sdb";
}
Here the global section has one module's parameter.
Statistics rules.
ipastat(8) queries statistics based on rules. There are two types of
rules: static and dynamic. A static rule is described in the rule sec-
tion. A dynamic rule does not have description in the configuration
file, any dynamic rule is generated on-the-fly by ipastat(8), according
to the settings in the command line and in the configuration file.
Several rules (static, dynamic) can share the same settings. There are
several ways to do this. First way is to use the global section. Sec-
ond way is to use rulepat (rules patterns) sections. And the third way
is specifying settings for dynamic rules in the command line.
If some rule (static, dynamic) does not have settings for some section
or parameter, then it inherits settings from matched rulepat section,
then it inherits settings from the global section, if there are still
some unspecified sections or parameters, then default settings are
used. Run ipastat(8) with -tt switches to see real values of all
parameters.
Following parameters can be used in global, rulepat and rule sections:
st_list.
Using statistics systems.
Above the st_mod parameter was introduced, which tells to load a module
and allows it to parse its configuration. The st_list parameter speci-
fies a list of used statistics systems:
st_list = <list>;
<List> is a set of names separated by space characters. To get names of
statistics systems read manual pages for modules you specified in
st_mod parameters.
If some rule (limit, threshold) has the st_list parameter, then statis-
tics systems listed in its value will be used for querying statistics
for this rule (limit, threshold). This parameter allows to create per
rule (limit, threshold) statistics systems list.
First statistics system which will be able to perform asked query will
be used for querying particular type of statistics. Note that the order
of statistics systems is important.
There is one built-in statistics system null in ipastat(8): it does not
return any statistics. If the st_list parameter is not specified, then
the null statistics system is used.
Example:
st_mod "ipa_st_sdb.so";
global {
st_list = sdb;
}
Here one statistics system is specified.
Static rules.
Static rules are called ``static'' just because they exist in the con-
figuration file.
The rule section describes settings for one static rule:
rule <rule-name> {
/* Rule's parameters and sections. */
}
You should give such names for rules, which are also valid rules names
for statistics systems you use.
The rule section does not have any mandatory settings. If some rule
does not have any sections and parameters, then it is called an empty
rule. It is obvious, that empty rules are senseless, so any rule usu-
ally has some parameters (own or inherited).
Example:
st_mod "ipa_st_sdb.so";
rule local.traf {
st_list = sdb;
sdb:db_dir = "/somewhere/${rule}";
}
Here a rule uses one statistics system, it also has module's specific
parameter.
Limits.
A limit is described in the limit section:
limit <limit-name> {
/* Limit's parameters and sections. */
}
You should give such names for limits, which are also valid limits
names for statistics system you use.
The limit section does not have any mandatory settings.
Limits have names, hence it is possible to use several limits in one
rule and they are distinguished by names.
Using separate statistics systems for limits.
There is the st_list parameter, which determines a list of statistics
systems used by a rule. By default a limit uses the same list of sta-
tistics systems, which is specified for its rule (it inherits this
list). But it is possible to use the st_list parameter in the limit
section:
rule <rule-name> {
/* Rule's parameters and sections. */
st_list <list1>;
limit <limit-name> {
/* Limit's parameters and sections. */
st_list <list2>;
}
}
<List1> and <list2> can contain common elements, in any case <list1> is
used only for a rule and <list2> is used only for a limit.
Why to use separate statistics systems lists for a rule and its limit?
Not all statistics systems work with limits and even if some statistics
system works with limits, it can support not all functions (methods)
for limits. See implementation details in the ipa_mod(3) manual page.
Read in the documentation for a statistics system module you use for
information if it can work with limits and what exactly a module sup-
ports when works with limits.
Thresholds.
A threshold is described in the threshold section:
threshold <threshold-name> {
/* Threshold's parameters and sections. */
}
You should give such names for thresholds, which are also valid thresh-
olds names for statistics system you use.
The threshold section does not have any mandatory settings.
Thresholds have names, hence it is possible to use several thresholds
in one rule and they are distinguished by names.
Using separate statistics systems for thresholds.
Like limits, it is possible to use the st_list parameter in the thresh-
old section and have different lists of statistics systems for a rule
and its threshold.
Dynamic rules, limits and thresholds.
By default if some rule is not found in the configuration file, then
this rule is considered as nonexistent. But number of rules can be very
big and rules cannot exist at the moment when the configuration file
was created. In this case it is impossible or inconvenient to keep all
possible rules in the configuration file.
To solve this problem there is one optional feature called dynamic
rules. It is possible to create dynamic rules on-the-fly and these
dynamic rules will inherit settings from the matched rulepat section
and the global section like any static rule. To turn on this feature,
set the value of the dynamic_rules parameter to ``yes'':
dynamic_rules = <boolean>;
By default the value of this parameter is ``no''.
There are similar parameter for limits and thresholds: dynamic_limits
and dynamic_thresholds respectively:
dynamic_limits = <boolean>;
dynamic_thresholds = <boolean>;
Dynamic limits and dynamic thresholds can be created for dynamic and
static rules.
Example:
dynamic_limits = yes;
In this example only creating of dynamic limits is allowed.
Rules patterns.
Using rules patterns is an effective method for sharing common settings
for rules. As it was said above, the global section allows to specify
some common settings for any rules. Rules patterns allow to specify
common settings for classes of static and dynamic rules.
If some static or dynamic rule does not have some parameter or section,
then it inherits this parameter or section from the matched rule pat-
tern. Rules patterns are defined in the rulepat sections:
rulepat "<regexp>" {
/* Parameters and sections. */
}
Each rule pattern is named by POSIX extended regular expression. Having
parsed the configuration file, ipastat(8) finds a matched rule pattern
for each static rule and applies unspecified settings from a rule pat-
tern to a static rule. Similarly, having created a dynamic rule, ipas-
tat(8) finds a matched rule pattern and applies unspecified settings
from a rule pattern to a dynamic rule. By default when a matched rule
pattern is found the search terminates. To continue search for other
rule patters, set the value of the check_next_rulepat parameter to
``yes'':
check_next_rulepat = <boolean>;
This parameter can be used only in the rulepat section, and its default
value is ``no''.
Any parameter and any section (including limit and threshold sections),
which is allowed to use in the rule section, can be used in the rulepat
section.
Rules patterns can be placed anywhere in the configuration file, but
their order is important, because theirs regular expressions are
checked in the same order as rules patters are placed in the configura-
tion file.
Modules also can expect their parameters and sections in rulepat sec-
tions.
Example:
st_mod "ipa_st_sdb.so";
rulepat "^client" {
st_list sdb;
}
Here the rulepat section ``catches'' all rules with ``client'' sub-
string at the beginning of their names.
Debugging.
Sometime it is necessary to find out why something goes wrong. There
are some parameters, which should be used for debugging ipastat(8):
debug_st_null - report about usage of null statistics system (alone,
1).
Each debugging parameter accepts a debug level as an argument, maximum
debug level for each debug parameter is specified as a number in paren-
thesis. If there is a word ``alone'' in parenthesis, then a parameter
should be placed alone.
By default debugging is off for everything.
Example:
debug_st_null = 1;
If no statistics is outputted, then ask ipastat(8) to report if built-
in null statistics system is used.
FILES
ipastat.conf
(run ipastat(8) with the -h switch and check default configuration file
pathname)
SEE ALSO
ipa(8), ipactl(8), ipastat(8), ipa.conf(5), ipa_mod(3)
AUTHOR
Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua>
BUGS
If you find any, please send email me.
April 16, 2005 IPASTAT.CONF(5)