This update of xymonq fixes a bug in the xymondboard-mode that could lead to multiple matching hosts.

A preliminary “volume mode” in included too. This mode is automatically used in xymondboard-mode without requesting the HOST-separator (-S). It currently expects the shipped unescape-xymonq.awk in the same directory as the xymonq-script. Example usage:

xymonq -q xymondboard -T disk -f msg,line1,hostname

For more details see the project-page: xymonq.

Since Xymon v4.3.20 it is possible to configure the rrd-graphs shown on individual status pages. In previous versions it was only possible to configure this for the trends-column and the (single) graph on the status columns was hard coded into Xymon.

To change (replace or extend) the graphs shown on the status-columns add GRAPHS_<columnname>="graph1[,graph2,...]" to xymonserver.cfg1. This setting overrides the default graph for the column, so that has to be included in the configuration if just an additional graph should be shown.

The default for the cpu column is to show the load graph la. If we want to show a detailed CPU-usage graph with I/O-wait along with the standard graph we can add vmstat1


In the previous article we had a look at extracting status-data from Xymon via the CLI. That status-data represents processed data — like color, status message, IP the message was received from, … This is the data that is (mostly) shown on the status-columns of the web interface.

But there is more: The Xymon clients do send raw data to the server that gets evaluated and processed into the status-data we already know. This raw data can be viewed on the web interface by following the Client data link on the built-in status columns (e.g. disk). This article shows how to query this data from the CLI, similar to the “already processed” status data.

The original BigBrother design, that introduced the great plain-text protocol, the clear web-interface and much more that is still used, was implemented in shell-script. That did not only limit performance due to forking problems but also required to write a lot of data to disk in order to persist state. So it was possible to grep trough that on-disk files to create custom reports.

The design of Xymon is optimised for speed and scaling. One of the consequences is the attempt to avoid disk-IO whenever possible and thus most of the transient states are only held in memory.

Integrating the Ikiwiki myiki created in the earlier articles with a Xymon Server now only requires one configuration addition on the Xymon side. As the wiki might be used for other content we put the host documentation in a separate place.

We will also create a “sitemap”-like page for all xymon files that is kept up-to-date automatically.

This update of shorewall-monitor for Xymon fixes a status text error. The shorewall status command exits only with a zero exit-code in the “started” case. For “stopped” and “cleared” the exit-code is non-zero.

The check if shorewall is executable at all was implemented without testing this properly. Nothing particularly bad happend, but the status-messages were a bit ugly to read and every state execept “started” reported red instead of differentiating “cleared” (red) and “stopped” (yellow).

For more details see the project-page: shorewall-monitor for Xymon.

Ever tried to track down the time of a reboot for a UNIXoid (Linux, *BSD, …) machine digging through the history-page of the cpu-column of the Xymon webinterface? The Windows-clients for Xymon have a separate column for uptime by default but *nix clients uptime is traditionally reported mixed with the cpu-status since the BigBrother days.

For UNIXoid systems these mix makes searching for boot-events unnecessary complicated as you have to check every yellow status …

Today we release a new extension: shorewall-monitor for Xymon:

If you run shorewall or shorewall-lite on your systems this may help you monitoring the state of your firewalls. It is installed as a local extension on the client and reports the state of shorewall, some metrics about the currently active ruleset (version, hashes, …) and optionally even the full ruleset.

Especially in environments with many (satellite) shorewall-lite installations Xymon can serve as a central point of information about their states and rulesets with this extension.

For more details see the project-page: shorewall-monitor for Xymon.

The default theming of ikiwiki is described as an anti theme and that’s right to the point: it looks like from the early 90s. To avoid loosing potential users too early in the process due to the very basic look we switch to a different theme now.

In general there are two ways to adjust the look of ikiwiki:

  1. use a pre-built theme
  2. create a local.css for complete custom theming with CSS and/or adjust the included template files (install in /usr/share/ikiwiki/templates/*.tmpl).

After we have set up our Ikiwiki myiki in the first part of this series we are now enabling the search function.

The search functionality is based on xapian-omega and provides full text search and some advanced features known from other search engines.