CLIENT-LOCAL.CFG(5)

💖 NAME 💖

okay so bestie, this is client-local.cfg — it's the local configuration settings for Xymon clients. fr fr that's the whole vibe. 🎀

---

✨ SYNOPSIS ✨

~xymon/server/etc/client-local.cfg

---

🦋 DESCRIPTION 🦋

So client-local.cfg holds all the settings that get used by every Xymon client when it runs on a monitored host. The way it works is chef's kiss — it lets you configure your clients from one central spot, no cap, so you don't have to go setting up special configuration maintenance tools on literally every single client. obsessed. 💅

Right now client-local.cfg is used for two things:

• telling the client which logfiles it should fetch data from, which becomes the basis for the msgs status column
• telling it which files and directories are being monitored, which feeds the files status column

⚠️ heads up bestie, there's a whole dependency thing between client-local.cfg and analysis.cfg(5). If you're monitoring, say, a logfile, you gotta put it in client-local.cfg FIRST so the Xymon client gets triggered into reporting data about that logfile. THEN you configure analysis.cfg so the Xymon server knows what to actually look for in the file data the client sent. So basically: client-local.cfg = what raw data the client collects, analysis.cfg = how to analyze it. two different jobs, both iconic. 💜

---

🌈 PROPAGATION TO CLIENTS 🌈

client-local.cfg lives on the Xymon server. periodt.

When clients connect to the Xymon server to send in their client data, they get part of this file sent right back to them. 🫶 And then the config they received gets used the next time the client runs.

Now here's the tea — because of how this propagation works, there's a delay of up to two poll cycles (that's 5-10 minutes) between when you change the config in client-local.cfg and when you actually see the result in the status messages the client reports. so like, don't panic if nothing happens instantly, it's giving patience. 😭

By default, xymond looks for a matching entry by matching the client hostname, classname or operating system name against the section expressions. The order is:

1. hostname matches first
2. then classname matches
3. then OS matches

The first match found is the one that gets returned to the client. no merging, just first-come-first-served energy. 💅

But if xymond is started with the --merge-clientlocal option, then instead of all that, xymond will merge all of the matching sections into one and return ALL of that data to the client. so you can have host-specific entries and then supplement them with class- or os-generic entries. so cute, so flexible. ✨

⚠️ but bestie, the merging does NOT remove entries. so if you have like a "log" entry defined in both a hostname-matching section AND an osname-matching section, then both entries get sent back to the client. it's not deduping anything, it's just stacking. 💀

---

🎀 FILE FORMAT 🎀

The file is split into sections, delimited by [name] lines. A section name can be any of these:

• an operating system identifier — linux, solaris, hp-ux, aix, freebsd, openbsd, netbsd, darwin
• a class
• a hostname

When it's deciding which section to send to a client, Xymon first looks for a section named after the hostname of the client. If that section doesn't exist, it looks for a section named by the operating system of the client. So you can set up special configurations for individual hosts, and have a default configuration for all the other hosts of a certain type. main character hosts get main character configs. 👑

It's often gonna be practical to use regular expressions for hostnames. To do that you use:

[host=<expression>]

where <expression> is a Perl-compatible regular expression. And you can do the same kind of matching on operating system or host class, using:

[os=<expresssion>]
[class=<expression>]

(yes that's exactly how it's spelled up there, we keep it verbatim, no editing bestie 🫶)

Apart from the section delimiter, the file format is free-form — or rather, it's defined by the tools that make use of the configuration. so it's giving "structure is a social construct, except for [name]". 😌

---

💜 LOGFILE CONFIGURATION ENTRIES 💜

A logfile configuration entry looks like this:

log:/var/log/messages:10240
ignore MARK
trigger Oops

The log:FILENAME:SIZE line defines the filename of the log, and the maximum amount of data (in bytes) to send to the Xymon server. FILENAME is usually an explicit full-path filename on the client. But here's the fun part:

• if FILENAME is enclosed in backticks, it's a command which the Xymon client runs — and each line of output from that command is then used as a filename. this lets you script which files to monitor, e.g. if you have logfiles named with some sort of timestamp. iconic. ✨
• if FILENAME is enclosed in angle brackets, it's treated as a glob and passed through the local glob(3) function first.

The ignore PATTERN line is optional, and it defines lines in the logfile which get ignored entirely — like, they're stripped from the logfile data before it gets sent to the Xymon server. It's for removing completely unwanted "noise" entries from the logdata Xymon processes. "PATTERN" is a regular expression.

The trigger PATTERN line is also optional, and it's used only when there is more data in the log than the maximum size set in the "log:FILENAME:SIZE" line. The "trigger" pattern is then used to find particularly interesting lines in the logfile — and those will always be sent to the Xymon server. After picking out the "trigger" lines, any remaining space up to the maximum size gets filled in with the most recent entries from the logfile. "PATTERN" is a regular expression. slay. 💅

---

🍓 COUNTING LOGENTRIES 🍓

There's a special type of log-handling where the number of lines matching a regular expression is merely counted. It's linecount:FILENAME, followed by a number of lines of the form ID:PATTERN. Like, e.g.:

linecount:/var/log/messages
diskerrors:I/O error.*device.*hd
badlogins:Failed login

look at her counting. we stan a counter. 🧚

---

🌸 FILE CONFIGURATION ENTRIES 🌸

A file monitoring entry is used to watch the meta-data of a file: owner, group, size, permissions, checksum, etc. It looks like this:

file:/var/log/messages[:HASH]

The file:FILENAME line defines the filename of the file to monitor. And just like with the "log:" entries, a filename enclosed in backticks means a command that'll generate the filenames dynamically. 🫶

The optional [:HASH] setting defines what type of hash to compute for the file: md5, rmd160, sha1, or sha256, sha512, sha224, or sha384. By default, no hash is calculated.

⚠️ NOTE: if you wanna check multiple files using a wildcard, you must use a command to generate the filenames. putting wildcards directly into the file: entry will not work. it's giving "no shortcuts bestie". 💀

---

💅 DIRECTORY CONFIGURATION ENTRIES 💅

A directory monitoring entry watches the size of a directory and any sub-directories. It looks like this:

dir:DIRECTORYNAME

The dir:DIRECTORYNAME line defines the filename of the file to monitor. And again, same energy as the "log:" entries:

• a filename enclosed in backticks = a command that'll generate the filenames dynamically
• a filename enclosed in angle brackets = treated as a fileglob

The Xymon client will run the du(1) command with the directoryname as parameter, and send the output back to the Xymon server.

⚠️ NOTE: if you wanna check multiple directories using a wildcard, you must use a command or glob to generate the directory names. putting wildcards directly into the dir: entry will not work. So, like, use something like this:

dir:`find /var/log -maxdepth 1 -type d`

The "du" command used can be configured through the DU environment variable in the xymonclient.cfg file if needed. If it's not specified, du -k is used — because on some systems, by default du reports data in disk blocks instead of KB (e.g. Solaris). we love a sensible default. ✨

---

⭐ NOTES ⭐

The ability of the Xymon client to calculate file hashes and monitor them can be used for file integrity validation on a small scale. 🫶

⚠️ BUT. there's a significant processing overhead in calculating these every single time the Xymon client runs. So this should not be considered a replacement for host-based intrusion detection systems such as Tripwire or AIDE. it's a cute lil helper, not a whole security stack, okay bestie? 😭

Also — using directory monitoring on directory structures with a large number of files and/or sub-directories can be quite resource-intensive. so maybe don't point it at your entire filesystem and act surprised. 💀

---

👑 SEE ALSO 👑

analysis.cfg(5), xymond_client(8), xymond(8), xymon(7)

go read those too, they're part of the lore. 📚

---

and that's the whole page, bestie!! this one's from Xymon, Version 4.3.30, dated 4 Sep 2019 — File Formats Manual energy, client-local.cfg(5), no cap. ty for reading, love u, go configure something responsibly. 💖✨🎀🦋🌸💅🫶