Reports play an important role in effectively managing systems with BCFG. There are two primary functions they fulfill; providing otherwise unobtainable information, and presenting common information in a compact, effective format that allows for easier admistration. Reports can contain system statistics, discrepancies between specified and actual configuration, invalid configuration notices, and auditing information, among other things. The flexible XML configuration file allows reports to be configured to deliver only the information that is important. Additional reports can easily be created, providing site-specific capability to manage at record effiency. The capability to harvest information regarding statistics, configuration, and problems in a single location should prove to be powerful.

The BCFG2 Reporting System consists of a number of elements including the bcfg2-build-reports Executable, a configuration file, and XSLT transform files. bcfg2-build-reports reads a default configuration file (or a config file specified on the command line) then prepares and delivers the reports according to the format defined in the transform files. It is expected that this executable will be run by the adminstrator periodically via cron or similar facility. The executable can also be run manually on demand for a special sort of report that needs to be generated immediately. bcfg2-build-reports gets the data it reports from a number of sources. Metadata/clients.xml contains information about if a host is currently pingable or not. bcfg2-ping-sweep will be run automatically by bcfg2-build-reports if the Metadata/clients.xml file is out of date with pingability information. The next place bcfg2-build-reports gets data from is the statistics.xml file. This file is maintained by bcfgd, and is updated whenever a client updates, therefore is always up to date and no maintainance is required on this file. Most of the information in the predefined reports come from this file. Finally bcfg2-build-reports is able to pull information from the Metadata/groups.xml file as well. This allows reports to describe the configured profile for each client.

There are a number of report types and delivery styles to present and transmit the reported data. The reporting structure lends itself best to structuring reports around groups of machines. For any group of machines any number of reports are generated. Each report may be delivered via Mail, WWW, or RSS (or any combination of the three.) In the future additional report types will be added, and if necessary, additional types of deliveries will be created. It is easy to create your own custom report using XSLT. Tables describing report types and report delivery mechanisms follow: Report TypeDescriptionOverview-Stats This report provides information about a large number of machines and their states. It is often found to be useful when the constituent machines are simply specified as All Nodes, which gives an overall outlook on your network's health. It makes sense to get this report via any mechanism. Nodes-Digest This report includes details about each node, specifically what packages, files, etc are broken, and other node specific info. It makes sense to recieve this via any mechanism. Nodes-Individual This report includes details about each node, but information is separated in to separate sections (such as separate e-mails or RSS articles) for delivery. This works well with e-mail (using filters on the client side) and for error detection (getting e-mail when there is a problem. Currently WWW is not a supported delivery mechanism for this type of report, because it is not completely clear how such a report could be used. NameDescriptionwwwan XHTML filerssan RSS file (links do not point at real web links, since they may not exist)mailA plaintext e-mail message

The report-configuration.xml file is the standard file that the bcfg2-build-reports executable uses when it is run without any command line arguments. Alternate configuration files, formatted identically, can be used by specifing -c flag. This can be useful for running different types of reports at different intervals. For example: Run this hourly: bcfg2-build-reports -c WebAndRssReport-config.xml Run this daily: bcfg2-build-reports -c emailReports-config.xml The report-configuration.xml file is structured with a root ]]> tag at the top level. Within this tag any number of ]]> tags can be inserted. Each report is structured around a group of machines. ]]> tags may individually reference a machine by hostname, or by a Python Regular Expression describing a group of hostnames. ".*" is especially helpful to describe all hosts. More information can be found about such Regexes at: . Any number of ]]> elements can be defined for a given report. A delivery consists of a mechanism and type. The mechanism would be something like Mail or Web, and the type would describe the intended content of the report. Some are tailored to overall machine health, while others could be best fit for auditing purposes Finally, each ]]> element contains one or more ]]> elements. In the case of an RSS or WWW report, the destination should be a complete path to the output file including the file's name. In e-mail based reports the destination should be a valid e-mail address.

The following configuration will generate two separate reports and deliver them in a number of different ways. For more information on exactly what each section does, please refer to the Configuration section above. ]]> Once configured correctly, just wait for the e-mail or view the outputed html files with a web browser. bcfg2-build-reports to recieve your reports immediately, or configure cron to run it perodically. E-mail reports will deliver the appropriate content directly to your mail client, and the html files should be viewable with any web browser. It is suggested those files be accessable via a webserver for convenience to other interested parties. Examples of the performance and overview reports.