/ 
RackMan-1.19
River stage zero No dependents
/ racktables-check

NAME

racktables-check - Perform various consistency checks on RackTables objects

SYNOPSIS

racktables-check [--config /etc/rack.conf] ...
racktables-check { --help | --man | --version }

OPTIONS

Program options

-c, --config path

Specify the path to the configuration file. Default to /usr/local/etc/rack.conf

-F, --filter list of tokens

Specify a comma-separated list of tokens, defining tags and attribute values. This option overrides the [cfengine-tags]/filter config parameter. See the corresponding documentation for more details.

-t, --format json|yaml

Specify the format for printing or storing the results. Available formats are json and yaml. Default is yaml.

-o, --output path

Specify the file to store the results. If none is specified, the results are printed on standard output.

-v, --verbose

Run the program in verbose mode.

Help options

-h, --help

Print a short usage description, then exit.

--man

Print the manual page of the program, then exit.

-V, --version

Print the program name and version, then exit.

Arguments

The rest of the argument, if any, are used as device names to perform the checks upon. If none is given, process all known devices (minus the filter).

DESCRIPTION

This program is a small consistency checking engine for RackTables objects. You can control what to check and how by defining rules in the configuration file.

CONFIGURATION

racktables-check's configuration is stored in rack(1)'s configuration, with the following additional definitions.

Section [racktables-check]

  • filter - specify a filter; will be overridden by the --filter option. See "FILTER SYNTAX" for details and examples.

    When defined, only the devices with the matching tags and attributes will be included in the input lists. When no tag or attribute pair is defined, the filtering fot that particular type is disabled.

  • rule - define a rule; see "RULES SYNTAX"

  • enforce_interface_match - make the program check if each logical network interface (that is, with a defined IP address) has a corresponding physical interface (a "port", in RackTables terminology) with the same name

RULES SYNTAX

The general syntax of a rule is:

[selector] property-name operator operand

The property-name is the only mandatory part. It defines the RackObject property (in a very broad sense of the term) to check. Valid properties are:

  • any RackTables attribute, written as attr:name

  • any RackMan::Device attribute, like object_name or object_type

  • addresses, addrs or ipv4_addrs return the list

  • gateway returns the IP address, in quad form, of the default IPv4 gateway

  • interfaces returns the list of the names of the regular network interfaces

  • mac_addrs returns the list of the MAC addresses (as a big hex number, not colon-separated)

When a property returns a list of values, the rule simply is applied to each value. In case of failure, the value is indicated in the message.

The selector makes the rule only check objects corresponding to the given criterion, written as [property-name=value]. valid properties are the same as in the main part of the rule. Multiple values can be given by separating them with a pipe (|).

For example, [type=Server] selects only the servers, [type=PDU|Switch] selects both PDUs and switches. [attr:Use=prod] selects objects with the attribute Use set to prod.

The operator and operand defines the check operation. If none is given, the property is checked to have a defined value. Valid operators are:

  • = - check for equality against the value given in operand

  • ~ - check for matching against the pattern given in operand; the pattern follows usual Perl regular expression syntax and must be bounded in slashes (/.../); flags, like /i, are also recognized.

  • % - check with a function call, whose name is given as operand; currently available check functions are:

    • check_dns - for a given name, checks that it can be resolved, that the resulting IP address can be reverse resolved, and that the resulting name is the same as the one originally given. For example, attr:FQDN % check_dns applies this check function to the FQDN attribute.

Note: To keep the code simple, all names and values in the rules are case sensitive, and must match the way they are entered in RackTables.

EXAMPLES

This set of rules makes sure that most network properties of servers are correctly defined. It only assumes that servers have a FQDN attribute which contains, obviously, their FQDN:

[racktables-check]
enforce_interface_match = 1
rule = [type=Server] attr:FQDN %check_dns
rule = [type=Server] gateway
rule = [type=Server] addresses
rule = [type=Server] interfaces ~ /(bce|bge|em|eth|fxp|lagg|re|vlan|xl)\d+/

FILTER SYNTAX

A filter is a comma-separated list of tokens, defining tags and attribute values used as criteria to determine which device to keep. The general syntax is:

token, token, ...

with no arbitrary limits on the number of tokens. The syntax of a token works like this:

  • a token in the form tag:name defines the tag with the given name

  • a token in the form attr=value defines the pair (attribute, value)

Examples

  • only keep the devices with the tags generic and infra (no attribute filtering):

    tag:generic, tag:infra

  • only keep the devices with the attribute Use set to prod or preprod (no tag filtering):

    Use=prod, Use=preprod

  • only keep the devices with the tag cfengine and the attribute Use set to prod or preprod:

    tag:cfengine, Use=prod, Use=preprod

AUTHOR

Sebastien Aperghis-Tramoni (sebastien@aperghis.net)