Skip to content

Upgrading

What to do when upgrading NSClient++, newest release first. Most upgrades are in place — defaults are preserved and the default install is usually unaffected — but the items below change observable behaviour or want a configuration touch. Read the entries between the version you are on and the version you are moving to.

Each entry carries an icon for the area it touches. 🔒 is the one that matters: those entries are security-relevant, and the Security notices page tracks them in one place. An entry badged Action required needs a change on every installation that runs the module; one badged Check your setup only if you use the feature it describes; the rest are informational. Full per-release detail lives in each GitHub release.

Use the filter below to narrow the list to your setup: pick the version you are coming from and tick the modules your nsclient.ini enables, and only the entries that concern that installation stay visible. The selection is shared with the Security notices page, remembered in your browser and reflected in the page address, so a filtered view can be bookmarked or shared.

0.23.0

  • 🔒 💥 Action required A listener verify mode it does not recognise now refuses to start. Check every listener you have configured for mutual TLS before upgrading. The parser used to drop a token it did not know, and fail-if-no-peer-cert — the spelling the documentation tells you to write — was one of those tokens. So verify mode = peer,fail-if-no-peer-cert resolved to bare peer: the listener asked for a client certificate and completed the handshake when none arrived, leaving an “NRPE with mutual TLS” that was really NRPE with an IP filter. Both spellings are now accepted, along with certificate for peer and client-certificate, and whitespace around a token is ignored. Anything else makes the listener log the offending token and refuse to start, which is the loud version of the same mistake. See the security notice.

  • 🔒 💥 Check your setup The NSCP and check_mk clients, and check_nsclient_web_online, now verify the server certificate by default. All three encrypted their connection but never authenticated the peer: verify mode defaulted to none on an NSCPClient target, was left unset on a CheckMKClient target (an empty verify mode parses the same as none), and check_nsclient_web_online defaulted verify to none. verify mode / verify now defaults to peer and ca to the agent’s own trust bundle (${ca-path} — the auto-generated ROOT store export on Windows, the distribution bundle elsewhere).

    Because an NSClient++ agent generates a self-signed certificate on first start, a relay or REST check pointed at a default agent will now fail the handshake where it used to connect. Pick one per target:

    Situation Configuration
    The remote agent uses a certificate from your own CA ca = <the CA> (the default verify mode = peer then works)
    The remote agent still uses its self-signed certificate ca = <that certificate> and verify mode = peer-cert
    You accept an unauthenticated link verify mode = none (encrypted, but an on-path attacker can impersonate the remote) 
    [/settings/NSCP/client/targets/web01]
address = nscp://192.168.56.103:8443
password = <the remote's admin password>
ca = /etc/nsclient/agent-web01.pem
verify mode = peer-cert

    For check_nsclient_web_online the same choice is made per check with ca= and verify=:

    check_nsclient_web_online host=agent.example.com password=... \
    ca=/etc/nsclient/agent.pem verify=peer-cert

    CheckMKClient targets are only affected when they enable TLS (use ssl = true); a stock check_mk agent listens in plain text and is unchanged.

    See the security notice.

  • 🔒 💥 Check your setup The op5 installer profile defaults to secure NRPE. Picking op5 on the MSI’s monitoring-tool page used to force NRPE into legacy mode — anonymous Diffie-Hellman, no peer verification — hide the mode radio group so the choice could not be seen or changed, and enable allow nasty characters for every NRPE-reachable check. The profile now defaults to the same secure mode the generic profile uses (verify mode = peer-cert, insecure = false), shows the NRPE mode radio group so legacy is a visible decision, and no longer sets allow nasty characters. allow arguments stays on, because op5’s check commands need it; what changes is that a caller has to present a certificate first. An op5 host monitored by a check_nrpe with no client certificate needs either a certificate or Insecure mode picked explicitly on that page. See the security notice.
  • 🔒 Check your setup A fleet management url that is not https:// is now refused. Nothing to do for a host enrolled against an https fleet server. The mtls_url in the enrollment manifest is where desired state and signed bundles come from, and on a plain socket neither the agent’s client certificate nor the pinned server certificate does anything — the whole management channel ran unauthenticated, silently. Enrollment now refuses a non-https management url, the sync loop refuses to start on a stored one, and the http client refuses to attach a client certificate or a pinned CA to a non-TLS transport at all. A url with no scheme counts as plaintext, because it is opened on a plain socket just the same. Where plaintext is what you want, nscp enroll --insecure records the decision in the manifest and [tls] allow plaintext = true in boot.ini allows it for an older manifest; the sync then logs INSECURE on every start. See the security notice.

  • 🔒 Check your setup You stay logged in to the web UI across a restart of the agent. Restarting the service, or upgrading it, no longer logs every web user out: a browser tab, and a script holding a key from /api/v2/login, keeps working. Sessions still expire eight hours after login, and only a hash of each session key is ever kept, in memory and on disk; see the security notice.

    To end a session, use the log out button in the web UI, or call DELETE /api/v2/login with the key. It stops working immediately and does not come back, not even if the agent is killed rather than stopped cleanly.

    Changing a user’s password or role also ends that user’s sessions, and removing the user ends theirs — but only from the next start of the agent. The running service keeps the users it read when it started, so until you restart it the new password does not work and the old sessions keep working. Reapplying settings from the UI is not enough; restart the service, or log the sessions out.

    If you relied on a restart to log everyone out, set persist sessions = false under [/settings/WEB/server]: sessions are then kept in memory only, as before, and every restart ends every session. Use the same switch to invalidate every session at once after a suspected leak (restart once with it off; switch it back on afterwards if you want sessions to survive the next restart).

    [/settings/WEB/server]
; Keep sessions in memory only, as before: every restart ends every session.
persist sessions = false

    One limitation: a user whose password is written in cleartext in [/settings/WEB/server/users/<user>] still has to log in again after a restart. Passwords stored in their hashed form (pbkdf2-sha256$…, which is what the agent writes for admin) are not affected. To convert a cleartext password, run nscp web add-user --user <user> --role <role> without --password: it keeps the password the user already has and stores it hashed.

  • 🔒 The Windows release build now verifies what it downloads. Nothing to do: this affects the release build, not a running agent. The checksum gate added last release was in place but every line in .github/dependency-checksums.txt read unrecorded, so each download warned and continued. The digests are recorded now for OpenSSL (cross-checked against OpenSSL’s own published .sha256), protobuf, Crypto++, miniz and the prebuilt check_nsclient.exe. TinyXML2, Mongoose and MariaDB Connector/C are no longer fetched as GitHub-generated tag archives but cloned and verified against a recorded commit, the way googletest already was. Lua stays unrecorded until its digest can be taken against the checksums lua.org publishes. Bumping a dependency version now means adding its line to that file first, because a missing line fails the build. See the security notice.

  • 🔧 Check your setup An unrecognised ${...} path token is now an error, and a [paths] override has to name an absolute location. Nothing to do if your paths are spelled correctly and your overrides are absolute — which is the normal case. If not, the agent now says so in the log instead of quietly using the wrong folder.

    Two related changes:

    • An unknown token is reported and the setting that carried it is skipped. It used to resolve to the installation directory, so a mistyped ${scripst}/check.bat was not rejected but turned into a real path under the install folder — and whatever depended on it went somewhere nobody was looking. This is the same silent failure that made a pre-0.17 ${host} in a path produce a mangled name rather than an error. The tokens are still open ended: anything you define in boot.ini’s [paths] section counts as known. Note that ${appdata} and ${common-appdata} are Windows-only and are now rejected on unix, where they previously resolved to the install directory.
    • A [paths] or --path-override entry that does not resolve to a location of its own is ignored, with an error naming it, and the built-in default applies. An override may still be written in terms of other tokens (scripts = ${shared-path}/mine); it is the resolved value that is judged. “A location of its own” is slightly wider than “absolute”: on Windows a drive-relative C:mine and a root-relative \mine are accepted, because the operator plainly named a drive or a root and it is not ours to move them — but note they still resolve against the process’s current drive or directory, so prefer a fully absolute path. A relative override would be read and written relative to the service’s working directory — C:\Windows\System32 for a Windows service, / under a bare init script, the package directory under the shipped systemd unit — so what it meant depended on how the agent happened to be started.

    If you scripted --path-override log-path=. or similar against a build tree, give it an absolute path instead.

    Check the log after upgrading: every rejected token and override is reported with the key that carried it.

  • 🔧 Check your setup A relative path in a setting that writes files is now taken relative to that setting’s own folder, not to the service’s working directory. Nothing to do if your paths are absolute or written with ${...} tokens. If any of the settings below is a bare relative name, the file it produces moves — on unix usually not at all, on Windows usually into the folder it should always have been in.

    Expanding a path substitutes ${tokens}; it never made anything absolute. A value with neither a token nor a leading / was therefore resolved against whatever the service’s working directory happened to be, which is C:\Windows\System32 for a Windows service, / under a bare init script, the package directory under the shipped systemd unit, and the shell’s directory for nscp test. Four different answers from the same configuration file.

    Settings whose consumers own a folder now say so, and a relative value lands there instead:

    Setting Relative values now land in
    [/attachments] target ${shared-path}
    [/settings/log] file name ${log-path}
    [/settings/crash] archive folder ${crash-folder}
    [/settings/fleet] managed path ${fleet-folder}
    [/settings/filewriter] file ${log-path}

    An absolute path, a UNC path or anything written with a token is used exactly as given — pointing one of these somewhere specific is still yours to decide. none still means “no file” wherever it was already accepted.

    One Windows value that did not used to be taken at its word now is. If [/settings/log] file name is literally /nsclient.log — a value carried forward from a version where a leading slash meant the installation directory — it was quietly rewritten to ${exe-path}/nsclient.log and the log appeared beside the executable. It now names a root like any other absolute path, so the log lands at C:\nsclient.log, on the root of the system drive, where the service may well not be permitted to write. The compiled default was never this value, so only a configuration that sets it explicitly is affected.

    Set it to what you actually want — ${log-path}/nsclient.log for the normal location, or a bare nsclient.log, which now means the same thing:

    [/settings/log]
file name = ${log-path}/nsclient.log

    On Linux the attachment case generally does not move: the shipped systemd unit sets WorkingDirectory to the package directory, which is what ${shared-path} resolves to, so relative attachments were already landing in the right place — by coincidence rather than by design. Windows services and any non-systemd launch are where this changes something.

    SimpleFileWriter’s default file = output.txt is affected by the same rule and now writes to ${log-path}/output.txt rather than to the working directory.

  • 🔧 Check your setup file name = none now really switches the log off on Windows. Nothing to do unless [/settings/log] file name is set to none. Unix installations already behaved correctly.

    none is documented as “no log file”, but the name was joined to the installation directory before the sentinel was tested. On Windows, where that directory is not empty, none became a real file called C:\Program Files\NSClient++none and file logging stayed on. On unix the join contributed nothing, so the sentinel survived and the setting worked.

    If this applied to you, the stray file is left where it is — delete it once you have checked you do not need its contents.

    none is now recognised by the path expander itself, so it is equally safe in every setting that accepts it, including every ca option where it means “use the TLS library’s own trust store”.

    Where a bare log file name ends up is a separate change with its own note — see the one about relative paths being taken relative to the folder their setting owns, which covers the log file on both platforms.

  • 🔧 Check your setup Windows: a relative external-script command is resolved against the installation directory. [/settings/external scripts/scripts] entries that carry a folder — the conventional check_foo = scripts\check_foo.bat, and what nscp ext-scr add --import writes — are now rooted at ${base-path} before they are launched. On Windows that is the same folder ${scripts} points at, so the script is found wherever the agent was started from.

    Previously such a command was measured against the working directory of the process, which is C:\Windows\System32 for the service and the shell’s directory for nscp test. The effect was easy to miss because it depended on how the command happened to be spelled: a single backslash (scripts\check_foo.bat) is not tokenisable as an argument vector, so it fell back to the legacy single-string launcher, where the lookup already honoured the installation directory and the command worked. A command that was argv-safe — a doubled backslash, a forward slash, a quoted path — ran with argv-isolation, where the executable is named separately and was resolved against the working directory, and it failed for the service with “the system cannot find the path specified”.

    Check your configuration if either applies:

    • You worked around this with an absolute path. Nothing to do — an absolute path, a UNC path, a drive-relative C:check.exe and a root-relative \tools\check.exe are all still used exactly as written.
    • You relied on the command resolving against the working directory — a relative command pointing at a folder outside the installation directory, with the agent started from somewhere that made it resolve. That no longer works; name the script with an absolute path, or with ${scripts}\<name> if it lives in the script folder.

    A command with no folder at all (cmd.exe, powershell.exe, cscript.exe — what the shipped [/settings/external scripts/wrappings] use) is not rooted; rooting it at the installation directory would point every one of them at a file that is not there. It now gets the system’s own executable search instead — the directory the agent loaded from, the working directory, the system and Windows directories, then PATH. On the argv-isolated path it previously got no search at all and resolved against the working directory alone, so command = cmd.exe /c … only ran when the agent happened to be started from a directory containing a copy of cmd.exe. The shipped wrappings were not affected, because their backslash paths put them on the legacy launcher, which has always done the search.

    Linux is unchanged: the unix launcher sets no working directory for the child and does not root the command, so a relative command still resolves against the agent’s working directory — which the shipped systemd unit sets to ${shared-path}.

  • 🔧 Check your setup nscp lua and nscp py now look in, and import into, the folder scripts are actually loaded from. Nothing to do unless you use those subcommands to manage scripts; loading scripts configured in nsclient.ini is unchanged, and existing configuration entries keep working.

    Both ext-scr CLIs derived their folder by appending a literal scripts segment to a root, rather than naming ${scripts} — the token that already means that folder. The two are the same thing only on Windows, where ${scripts} is ${exe-path}/scripts:

    Looked in / imported into (before) Now
    nscp lua list/show/add/delete ${base-path}/scripts/lua — right on Windows, /usr/sbin/scripts/lua on Linux ${scripts}/lua
    nscp py list/show/add/delete ${scripts}/scripts/python — a folder nothing creates ${scripts}/python

    So on Linux the Lua subcommands were looking beside the binary rather than in the package’s script folder, and the Python ones imported into a doubled path on every platform. nscp for external scripts (CheckExternalScripts) was already correct and is unchanged.

    add --import also records a different value in the configuration. It used to write scripts\python\<name> / scripts\lua\<name>, which paired with the old folders and only resolved on Windows, where a backslash is a separator. New imports record python/<name> / lua/<name>, relative to ${scripts} and resolving the same way on both platforms.

    list (and the script list in show and the web UI) names its entries the same way, relative to ${scripts}: lua/mycheck.lua rather than an absolute path or a scripts\lua\mycheck.lua that only resolved from the installation directory. So what list prints can be handed straight back to add from anywhere, which is what it is for.

    Entries written by an older version are not rewritten and keep resolving as before — the file they point at has not moved.

  • 🔧 Remote [/includes] and [/attachments] are now refreshed on their own. An agent configured from an http(s):// settings url re-downloads its whole configuration every settings maintenance interval (/settings/core settings maintenance interval, default 5m). Until now that pass stopped at the top-level file: a file pulled in by [/includes], and every [/attachments] target, was only re-fetched when the top-level file itself happened to change — so on a server where nsclient.ini is the stable part and the included file is the one that moves, the include stayed pinned to whatever it held when the agent started. Both are now fetched on every pass, and a change in either triggers the same reload a change in the top-level file does.

    Nothing to configure. Two things to be aware of:

    • The settings server now sees one request per included file and per attachment on every interval, not just one for the top-level file. The responses are hash-compared, so an unchanged file still costs nothing beyond the request itself — but if you serve a large attachment to a large fleet, size the interval accordingly.
    • A configuration change made only in an included file now takes effect within one interval instead of requiring a service restart. If you were touching the top-level file to force includes through, that workaround is no longer needed.

  • 🔧 The Windows installer creates scripts\custom\ again, and always. Nothing to do — it is a folder to put your own scripts in, created empty.

    It used to exist and was lost when a batch of outdated sample scripts was removed. Unlike the shipped examples it is not part of the Scripts (SampleScripts) installer feature, so REMOVE=SampleScripts no longer leaves an installation with no scripts\ directory at all — which previously meant an [/attachments] entry, or anything else writing a script, had nowhere to land.

    Nothing is installed into it, so an uninstall removes it again only if you have left it empty.

  • 🐛 ext-scr, py and lua add --import now work on a fresh install, and what they record is a path that resolves. Nothing to change: existing configuration is read exactly as before, and this only affects what the import writes from now on.

    Three things were wrong with importing a script, and each of them was silent in its own way:

    Symptom Was Now
    Import fails outright copy_file never created the destination folder, so the import died with a bare No such file or directory naming …/scripts/python the folder is created
    Imported command exits 127 on Linux ext-scr recorded scripts\<name> — a Windows spelling of a path this module never resolves anyway the destination’s absolute path is recorded
    add --import with no --script the destination collapsed onto the script folder itself and the copy overwrote that path with a file refused, naming the missing option

    ${scripts}/python and ${scripts}/lua only exist on Windows when the sample scripts feature is installed, and a ${scripts} override points wherever an operator chose, so “import into a folder that is not there” was the normal case, not the corner case. The Web UI’s script upload goes through the same add --import, so it failed the same way.

    The command ext-scr add --import writes on Linux is now absolute:

    [/settings/external scripts/scripts]
imported = /usr/lib/nsclient/scripts/imported.sh

    That is not a style preference. CheckExternalScripts hands the value to the shell verbatim — no ${...} expansion, no search of the script folder — and on Linux the launcher does not set a working directory for the child at all, so only an absolute path can work. On Windows the child does start in ${base-path} with ${scripts} directly below it, so the relative scripts\<name> still resolves and is still what gets recorded there.

    ext-scr list, py list and lua list had a matching defect: a path that did not begin with ${base-path} still had its leading separator sliced off, producing a rootless usr/lib/nsclient/scripts/check_x.sh that named no file. Those entries are what the Web UI’s script list shows and what show is called back with, so they now stay absolute when they are not below the install base.

0.22.0

  • 🔒 💥 Action required Fleet bundle signatures changed shape: upgrade the fleet server before the agents. Only affects hosts enrolled against a fleet server (nscp enroll); an installation that does not use fleet management is unaffected.

    A bundle’s Ed25519 signature used to cover the bare SHA-256 digest of its bytes, which bound nothing about which bundle those bytes were — an old signed blob could be re-advertised under a new id, name or version and still verify. It now covers a canonical descriptor of the bundle’s identity:

    nsclient-fleet/bundle-sig/v2 \0 tenant_id \0 id \0 name \0 version \0 format \0 sha256

    signed directly (Ed25519 hashes internally), with the fields taken verbatim from the desired-state response. The response therefore carries a new top-level tenant_id, which the agent needs to rebuild the descriptor and cannot derive from its certificate.

    The two sides must agree, so:

    • Upgrade the fleet server first, or at the same time. A server that signs the descriptor is already re-signing its stored bundles on startup, so no bundle needs re-uploading.
    • An agent on this version talking to an older server logs Bundle <id> failed verification: signature verification failed on every poll and keeps the configuration it last applied. Nothing unverified is applied and nothing already applied is removed, so the host keeps working — it simply stops picking up changes until the server is upgraded.
    • An older agent talking to an upgraded server fails the same way, which is the case to watch for if you upgrade the server first and the agents later.

    A desired-state response that carries bundles but no tenant_id is now rejected as malformed rather than failing later as a bad signature, so the log names the real problem.

    See the security notice.

  • 🔒 💥 Check your setup A settings source, include or attachment that is not https:// is now refused. Nothing to do if your agents read a local configuration or use an https:// settings server. The remote store is the agent’s whole configuration — [/modules], the external script definitions, the submit clients’ credentials — re-read at boot and on every housekeeping pass, and over plain http:// nothing authenticates the server, so anyone on the network path decides what every agent pointed at it runs. All three paths that fetch one (the [settings] url in boot.ini, an [/includes] entry inside a fetched file, and an [/attachments] source) now refuse a url that is not https:// — a url with no scheme included — and log why. An agent that already has a cached copy keeps running on it rather than booting empty. Where plain http is what you want, opt in per host in boot.ini:

    [tls]
allow plaintext = true

    Every plaintext fetch is then logged as INSECURE.

    On Windows, boot.ini’s location is now the ${boot-conf} path token rather than a literal baked into the build, so --path-override boot-conf=... relocates it the way the command line already documented and the way it has always worked on Linux. The default is unchanged: next to the executable.

    See http settings and the security notice.

  • 🔒 💥 Check your setup The raw protobuf web API is gone, and agent-to-agent checking now uses the versioned REST API — which means it works. POST /query.pb and POST /settings/query.pb have been removed. The first handed the agent’s core a message whose header the caller wrote, and the core reads the calling module and user out of that header, so a caller could pick the identity its request was attributed to; the second had been unreachable for several releases. Nothing that talks to an agent over HTTP used them: Icinga’s check_nscp_api asks for GET /query/{name}, which is untouched, and the web UI uses /api/v2.

    Their only consumer was NSClient++ itself, through NSCPClient — and that never worked: it passed the serialized message as the HTTP request target, so every request it made was malformed, and the password it read from the configuration was never sent at all. check_remote_nscp, remote_nscp_query and remote_nscpforward now run the command on the remote agent through GET /api/v2/queries/{command}/commands/execute, authenticating with the same password header check_nscp_api uses. If you have an NSCP target configured, check three things:

    Setting Was Now
    path /query.pb (a single endpoint) /api/v2/queries (the collection the command is appended to)
    TLS off unless ssl = true on unless no ssl = true — the REST API listens on TLS
    password read, never sent sent, and the remote’s admin user needs the queries.execute grant

    If you set path explicitly, remove it or point it at /api/v2/queries. verify mode still defaults to none, because an agent generates a self-signed certificate on first start; point ca at the issuing certificate and set verify mode = peer where you can.

    exec_remote_nscp and submit_remote_nscp are removed rather than ported: both posted an NRPE-style command!arg!arg string to the protobuf route, which the remote parsed as an empty message and answered with nothing — and the submit path then reported success regardless. The REST API has no endpoint for either, so they now refuse with an explanation instead of discarding results silently. Use NSCA, NRDP or another submit client to send passive results.

    See the security notice.

  • 🔒 💥 Check your setup check_tcp and check_ssh now verify the server certificate by default. verify defaulted to none, so a TLS check completed its handshake against any certificate at all and reported ok. It now defaults to peer, and ca= defaults to the agent’s own trust bundle (${ca-path}, the same one check_http has always used), falling back to the trust store OpenSSL was built with when that is empty. Checks against publicly issued certificates start validating out of the box; checks against a self-signed or internal certificate that used to report ok now report tls_handshake_failed.

    • If you check an internal or self-signed service, either point ca= at the issuing CA — a PEM bundle or a hashed directory both work — or add verify=none to keep the previous behaviour. The certificate keywords (ssl_expiry_days, cert_cn, cert_sans, cert_verify, …) are readable either way: they are properties of what the peer served, not a trust decision.
    • Only TLS checks are affected, which means ssl=true, a starttls= protocol, or one of the implicit-TLS service= presets (spop, simap, ssmtp). A plain check_tcp is unchanged.
    • sni= is now rejected when the connection is not TLS, instead of being silently ignored. It named the certificate to ask for and to verify against, so without TLS it asserted nothing while still reporting ok.
    • sans= on a plain connection now reports san_missing rather than ok. A connection that served no certificate covers no required name — which is what forgetting starttls= on a submission port looks like.

    Both commands are marked experimental, which is the flag that reserves exactly this: their options, keywords and output may still change while the shape of the check settles.

    See the security notice.

  • 🔒 Check your setup A request may no longer weaken the transport security of a credentialed target, or re-address submit_smtp mail. The client override guard now covers the keys that decide how a connection is protected — verify, insecure, insecure-skip-verify, no-psk, security, ssl, no ssl, tls-version, ca, certificate, certificate-key, allowed-ciphers, dh — and, for SMTP, recipient and sender. Nothing to do unless callers pass one of those to a target that carries a password or token; repeating what the target configured is still fine, and the remedies are the same as for host=: supply the credentials with the request, configure the variant as its own target and select it with target=, or set allow host override = true. The addressing keys have their own, narrower opt-in, allow recipient override = true. payload-length / buffer-length are clamped to what each protocol accepts, 65536 for NSCA and 1 MiB for NRPE, so an absurd value can no longer allocate gigabytes while every supported payload size keeps working. A failed CA load reports a generic message with the path and reason in the log. See the security notice.
  • 🔒 Check your setup A request may no longer reroute a credentialed NRDP target through its own proxy. The client host-override guard now treats proxy= and no-proxy= as moving the request, since a caller-chosen proxy receives it whole, configured token included (see the security notice). Nothing to do unless callers pass proxy= on submit_nrdp against a target that carries a token; repeating the configured proxy is still fine, and the remedies are those of host= — pass the token with the request, configure the proxied route as its own target and select it with target=, or set allow host override = true.
  • 🔒 Check your setup The fleet certificate pin is enforced as a pin. A pinned PEM that is the server’s leaf certificate is now matched by its public key at every handshake; one that is itself a CA keeps hostname verification, because a CA certificate cannot identify a server on its own — previously either kind was simply trusted for any name. If enrollment handed out a CA rather than the leaf, that connection now requires the certificate to match the name in mtls_url. A pinned PEM that does not parse is refused rather than quietly falling back to ordinary verification. See the security notice.
  • 🔒 Check your setup host= on a docker check must now match the configured endpoint. Which daemon the agent talks to is decided by endpoint under [/settings/docker]; a request repeating that value is accepted, one naming a different socket or pipe is refused. The agent would otherwise connect to any local socket or \\.\pipe\<name> a caller named and report back what happened, which is a read-only probe of the host as SYSTEM or root. Check definitions that spell out host= keep working as long as they name the configured endpoint; otherwise drop the argument or change the setting. See the security notice.
  • 🔒 Check your setup A NUL in a script argument is refused, and ext-scr add --import reads only from the script folders. CreateProcessW reads the command line as a C string, so an argument containing a NUL truncated it and silently dropped every operator-fixed argument after the substitution point; that is refused now whatever allow nasty characters says, because it changes what the launcher was asked to run rather than what the script sees. add --import copied from any path the service account could read into the script folder, where show then returned the bytes — which made the show/delete sandbox hold only until someone carried a file inside it. Import sources are confined to the script root, ${shared-path} and the upload staging area; copy a script into one of those first if a workflow relied on importing from elsewhere. PUT /api/v2/scripts is unaffected. On Windows, a script that prints in exact buffer-sized chunks no longer parks a worker thread past the timeout, and a timed-out or forked script no longer leaks a process handle. See the security notice.
  • 🔒 External scripts no longer inherit the service’s handles. A script now receives only its own stdin and stdout/stderr pipe ends: on Windows through an explicit inherit list (spawns are serialised on the XP build, which has no such list), on Unix through close-on-exec pipes and a close of every descriptor above stderr in the child. Previously a concurrently running script’s output pipe, and every other inheritable handle of the service, crossed into each child (see the security notice). Nothing to do.

  • 🔒 Check your setup External scripts with user, domain or password set are refused on Linux. The run-as keys of a script section are implemented by the Windows launcher only; the Linux launcher ignored them and ran the script as the service account (root on a manual nscp service run), so a script sandboxed with user = nobody was not sandboxed at all. Such a command now returns UNKNOWN with a message pointing at sudo and the script does not run. If you set these keys on Linux, remove them and put the identity change in the command itself, granting it in sudoers:

    [/settings/external scripts/scripts/check_as_nobody]
command = sudo -n -u nobody /usr/lib/nagios/plugins/check_something

    Windows is unaffected. See the security notice.

  • 🔒 Check your setup The web server sends browser hardening headers, can negotiate TLS 1.3 on Linux, and stops minting a session token per request. Every response now carries X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: no-referrer and a content security policy, plus Strict-Transport-Security over TLS — so a page that embeds the agent’s UI in a frame will stop working, which is the point. [/settings/WEB/server] gains tls version (default 1.2+) and allowed ciphers, honoured on the beast backend that every Linux package uses; it was pinned to TLS 1.2 only before, and ignored both keys. The vocabulary is the one the NRPE and NSCA listeners use, with one exception: tls version = sslv3 is refused rather than started, because this listener never serves SSL 3.0 and pinning the range to it would mean a listener that accepts no handshake at all. A value this listener cannot honour — an unknown version, or a cipher list OpenSSL rejects — stops it starting rather than silently leaving the defaults in place. The mongoose backend cannot apply either key and logs that it is ignoring a value the operator set; it stays quiet about one left at its default. A token is issued only by the login routes now, so a monitoring poll authenticating with Basic auth no longer fills the 4096-entry store and evicts live UI sessions — a script that logs in through Basic auth and reuses a token must take it from GET /api/v2/login. The session credential is no longer echoed back as a cookie nothing read, and the UI keeps its bearer in sessionStorage, so a new browser tab asks for credentials again. /api/v2/scripts/<runtime> accepts only ext, py and lua (which now works); anything else is 400. See the security notice.
  • 🔒 The web server’s in-memory log buffer is capped, logging out revokes the session token, and nscp web install-ui no longer stages its download in ${temp}. Nothing to do. The log view keeps the newest 1000 entries instead of growing without bound (an unauthenticated peer could previously add one entry per rejected request, for the life of the process); the error count on the badge still counts every error the agent reported. Logging out of the web UI now calls DELETE /api/v2/login, so the bearer token stops working immediately rather than at the end of its eight-hour life — worth knowing if you have a script that logs in, logs out, and then reuses the token. nscp web install-ui verifies the bundle in memory and writes it once into a private directory under the web path, so nothing lands in the shared temp directory. See the security notice.
  • 🔧 🔒 Check your setup nscp nrpe install writes use ssl, and the insecure preset’s cipher string says what it is. The install command used to write ssl = true, a key the server never reads: on a host where use ssl = false had been set previously, it claimed encryption and client-certificate authentication while the listener stayed in plaintext. Check that value if you ran the command on such a host. The legacy (insecure = true) cipher default drops its !ADH, which never excluded the anonymous elliptic-curve suites and could not have excluded them without breaking a mode that loads no certificate; the string now matches what nrpe install --insecure writes. The secure default gains !aNULL beside !ADH, which changes nothing in practice — OpenSSL’s default security level already refuses anonymous suites. See the security notice.
  • 🔧 🔒 allowed hosts finally understands the * ranges it has always advertised. 192.168.1.* means 192.168.1.0/24, 192.168.* means /16, 10.* means /8, and a bare * is every address. Until now such an entry threw out of the address parser and — with the default cache allowed hosts = true — took the whole module with it, so the listener never started. A * in the middle of an address (192.*.1.1), or one combined with an explicit /mask, is reported as a configuration error, and an unparseable numeric entry is now an error beside the others rather than an exception. Nothing to do; if you have been avoiding * because it stopped a listener, it works. See the security notice.

  • 🔒 Check your setup The shared /settings/default/password is always redacted, and follows use credentials. Nothing to do on a default install. The key is now registered sensitive by the core rather than by whichever of WEBServer, NSCAServer and NSClientServer happens to be loaded, so nscp test’s settings dump, nscp settings --list / --show and the REST read paths answer *** for it on every agent instead of only those running one of those modules. Read the value out of nsclient.ini when you need the secret itself. Two consequences if you rely on the old behaviour:

    • Tooling that scraped the shared password back out of one of those listings now receives ***.
    • On Windows with use credentials = true, the next write of the key (a nscp settings --update, or any change made through the REST or CLI settings writers) moves it into the Credential Manager and leaves a reference in nsclient.ini, the same as every other sensitive key. Agents that do not enable credentials are unaffected, and the key is not rewritten until something writes it.

    See the security notice.

  • 🔒 🔧 Check your setup A round-robin counter with a zero buffer size is now refused. From the security notice; nothing to do unless you have one of these:

    • A Windows counter with collection strategy = rrd and buffer size = 0, or a buffer size that does not parse, is skipped and named in the log instead of being loaded with a buffer that holds nothing. Remove the setting to get the 60m default, or set a real window.
    • A Lua binding given a word where it expects a number reads it as 0 rather than terminating the agent. Settings():get_int(path, key, "n/a") returns the key’s value with 0 as the default, where it used to be fatal.
    • A Python string that cannot be encoded as UTF-8 comes back with the offending characters replaced instead of crashing the agent.
  • 🔒 An Elastic or Op5 submission over an unverified https link now says so in the log. When the endpoint’s verify mode resolves to no peer verification and credentials are configured, both modules log a message naming the endpoint — the credentials then go to whichever server answers — matching what the Icinga, NRDP and NRPE clients already do. It is logged once per module load, and the connection itself is unchanged. The Icinga client’s own warning was repeated on every submission and is now logged once per target instead. The shared --verify, --ca, --certificate-key and --allowed-ciphers help texts (NRPEClient, NSCPClient, NSCAClient, CheckMKClient, NSCANgClient) were corrected at the same time: three of them read “Client certificate format”. See the security notice.
  • 🔒 Check your setup The DEB and RPM packages now install nsclient.ini and the log directory owner-readable. /etc/nsclient becomes root:nsclient 0750, /etc/nsclient/nsclient.ini root:nsclient 0640, /var/log/nsclient nsclient:nsclient 0750 and the log file 0640; they were world-readable, and the configuration file holds the web admin password, the NRPE/NSCA passwords and the submit-client tokens in plaintext. The post-install scripts apply this on upgrade as well, so an existing host is fixed by upgrading. If a local script or a monitoring user reads either path without being root or in the nsclient group, add it to that group first — otherwise it will start getting permission denied. Windows is unaffected. See the security notice.
  • 🔒 The Windows release build pins every third-party action to a commit and verifies what it downloads. Nothing to do — this concerns how the released artifacts are built, not an installed agent. Third-party actions are pinned to commit SHAs (one ran from a branch, in the same job that holds the code-signing credentials), Google Test is checked against the commit its tag names, and every downloaded dependency goes through .github/dependency-checksums.txt: a mismatched digest fails the build, and so does bumping a version without recording one. See the security notice.

  • 💥 📊 Check your setup /api/v2/openmetrics now serves a conformant, self-describing OpenMetrics document, and every metric name changes. Only affects scrapes of /api/v2/openmetrics. The JSON endpoints (/api/v2/metrics, /metrics), the web UI dashboard, Graphite, collectd and Python submit_metrics report the same keys and the same values as before — the metric key is untouched and stays authoritative for all of them.

    The endpoint used to paste the JSON keys into the exposition verbatim, so names carried ., %, spaces and colons (system_mem_commited.avail, system_cpu_core 0.idle, disk_free_C:.total), there was no # TYPE and no # EOF, values were truncated to six significant digits — 16 GB of memory scraped as 1.6554e+10 — no module declared what any of its readings meant, monotonic counts were typed as gauges so rate() was unsafe on them, and string-valued metrics (uptime, boot time, MAC address, power source) were dropped entirely. A strict parser rejected the body, and the scenario page told you to repair the names with metric_relabel_configs.

    Three things changed, and each of them renames families.

    1. Names are rewritten to the OpenMetrics grammar.

    JSON key Metric name
    system.mem.physical.% system_mem_physical_percent
    system.cpu.core 0.idle system_cpu_core_0_idle
    disk.free.C:.total disk_free_C_total

    % becomes the word percent, everything else outside [a-zA-Z0-9_] becomes _, runs collapse to one, and a name that would not start with a letter borrows a metric_ prefix (a leading underscore is reserved). Every family carries a # TYPE line, the body ends with # EOF, values keep their full precision, and the response is typed application/openmetrics-text; version=1.0.0 when the scraper asks for it.

    2. Every metric carries a description, a type and a unit, and declaring a unit renames its family again:

    • # HELP on every built-in family, and # UNIT wherever the value is measured in something.
    • Counters are typed as counters — workers.{jobs,submitted,errors}, scheduler.{jobs,submitted,errors}, system.process_history.<exe>.times_seen and the real-time filter counts. Their sample carries the _total suffix the specification reserves for them.
    • Strings come back as an _info family, the node_uname_info shape: system_uptime_info{uptime="1d 12:30",boot="2026-09-13 01:15"} 1.

    A family that declares a unit has to end in it, so the name the key alone would give gains a suffix:

    Name from the key alone Name it is served under
    system_mem_physical_total system_mem_physical_total_bytes
    system_cpu_total_idle system_cpu_total_idle_percent
    system_uptime_ticks_raw system_uptime_ticks_raw_seconds
    disk_free_C_total disk_free_C_total_bytes
    workers_jobs workers_jobs_total

    A name that already ends in its unit keeps it, which covers every .% key (system_mem_physical_percent) and the clock frequencies. A per-second rate declares no unit and gains no suffix either (system_network_eth0_received, disk_io_sda_read_bytes_per_sec).

    3. Per-instance metrics are one family with a label, so every per-core, per-NIC, per-drive and per-process family name changes again. Rewriting the key alone would leave one family per core, which is what the endpoint has always served: the family names then depend on how many cores a host has, sum by (core) has nothing to group on, and a Grafana variable has no label to bind to.

    # one family per core, as a name-only rewrite would leave it
system_cpu_core_0_idle_percent 93
system_cpu_core_1_idle_percent 91
system_cpu_total_idle_percent 95

# what is served
# TYPE system_cpu_idle_percent gauge
system_cpu_idle_percent{core="0"} 93
system_cpu_idle_percent{core="1"} 91
system_cpu_idle_percent{core="total"} 95

    The same move applies to every producer with an instance in its key:

    Bundle Label Value
    system.cpu core 0, 1, … and total for the aggregate
    system.cpu_frequency cpu the sysfs core on Linux; the processor DeviceID (CPU0) on Windows
    system.network nic the interface as the OS names it — the adapter description on Windows
    system.temperature zone the thermal zone or sensor
    system.battery battery the battery; absent for a single unnamed battery
    system.process_history exe the executable name
    system.metrics pdh_instance the PDH instance, for a counter configured with instances
    disk.io disk the device
    disk.free drive the drive or mount point

    pdh_instance rather than instance: Prometheus attaches its own instance label (the scrape target) to every sample, and under the default honor_labels: false an exported instance is renamed exported_instance, so a query against instance would match the host rather than the counter.

    The _info families gain the same labels, which is what splits them per instance: one NIC’s link state, MAC address and speed now share a series keyed by nic="…", instead of every NIC’s strings piling onto one series under label names like eth0_status. Windows and Linux spell a CPU core differently in the JSON key (core 0 and core_0); neither spelling reaches the label, which is the bare 0 on both, so one query works across a mixed fleet.

    What to do:

    • Drop any metric_relabel_configs block that rewrote dots to underscores. The agent does exactly that itself now, so the rule no longer matches.
    • Update dashboards, recording rules and alerts that name the old series. Every name moves at least once, and a per-instance one turns into a label: system_cpu_core 0.idle becomes system_cpu_idle_percent{core="0"}, disk_free_C:.total becomes disk_free_total_bytes{drive="C:"} and workers_jobs becomes workers_jobs_total. Most of them get shorter, and a query that used to enumerate instances can now aggregate.
    • Exclude core="total" from anything that aggregates over cores. It is the all-cores aggregate, mirroring the system.cpu.total.* JSON key, so sum without (core) (system_cpu_idle_percent) double-counts. Write system_cpu_idle_percent{core!="total"} instead.
    • Check what you are taking a rate() of. Only the counters listed above are monotonic. system_network_<nic>_total is a per-second rate and system_os_updates_count is how many updates are pending right now; both go down again, and a rate() of either was always nonsense — it is just visible now that the honest counters are labelled as such.

    • If dashboards cannot be updated before the upgrade, set

      [/settings/WEB/server]
openmetrics format = legacy

      which reproduces the pre-0.21 body byte for byte, with no metadata at all. It is deprecated and will be removed in a future release, so use it as a migration window rather than a setting to leave in place.

    Two keys can now want the same metric name (mem.used.% and mem.used percent both render as mem_used_percent). The first metric of the snapshot keeps the name and the rest are dropped — emitting both would be the same series twice, which costs the scraper the whole body rather than one metric. Each distinct collision is logged once (again after a settings reload) naming the metric that was dropped and the name it collided on. Nothing shipped produces such a pair; a predefined PDH counter or a Python script can.

    Smaller changes that come with it:

    • Windows only: system.mem.page.% and system.mem.physical.% report different numbers now, because they were reporting the wrong thing. Both divided the commit charge by the commit limit while checking their own total for zero, so they published the commit figure under a page-file and a physical-memory name — and divided by zero on a machine that reported a page file or physical memory but no commit limit. Each reads its own numbers now. The JSON keys and the metric names are unchanged; only the values are, and they were wrong before. An alert threshold tuned against the old reading needs re-checking.

    • The two negotiated bodies are no longer identical. The endpoint already answered application/openmetrics-text; version=1.0.0 or text/plain; version=0.0.4 depending on the request’s Accept header. The two specifications disagree about what a counter’s metadata lines name — the family in OpenMetrics (# TYPE workers_jobs counter, sample workers_jobs_total), the sample in the older format (# TYPE workers_jobs_total counter) — so the agent renders both and serves the one matching the type it answers with. Sample lines are identical in both. Nothing to do; a scraper that negotiates gets the richer form as it always did.

    • Predefined PDH counters can describe themselves. [/settings/system/windows/counters/<name>] takes two new optional keys, help and unit, which become the # HELP and # UNIT lines of that counter’s metric. help defaults to the counter path. Nothing else reads them, and a counter that sets neither behaves exactly as before.

    • Python fetch_metrics accepts a dict per value. {"value": 42, "help": "…", "unit": "bytes", "type": "counter"} in place of a bare number, and "labels": {"queue": "inbound"} to label a metric. Plain numbers and strings keep meaning exactly what they did, and an out-of-tree C++ module calling nscapi::metrics::add_metric() is unaffected.

    • /api/v2/metrics?meta=1 serves the same keys and values with their help text, unit, type and labels under a metadata object, for a dashboard that wants to print a unit rather than a bare number. Without meta the endpoint is byte for byte what it was.

    • GraphiteClient can send the labels as carbon tags. metric tags = true on a target appends ;core=0 to the metric path, which is otherwise unchanged. Off by default: a carbon older than 1.1 has no tag support and stores path;core=0 as the metric name.

    • CollectdClient mappings can read the labels and the types. A variable set to label:core expands to every distinct value of that label, instead of a regular expression over the flat keys that has to know whether the platform spells a core core 0 or core_0; and a metric expression spelled auto: sends whatever the producing module declared a counter as a collectd DERIVE and everything else as a GAUGE. The built-in default mappings are unchanged. Note that a label includes the aggregates the exposition labels — label:core yields total alongside 0, 1, … — so a template built from it can name a metric that does not exist, which is skipped rather than sent.

    • A collectd value list naming a metric the snapshot does not carry is no longer sent as a zero. The value expression resolved a missing key to an empty string and forwarded the 0 that parsed out of it, so a mapping naming a metric this platform or configuration never produces reported a measurement nobody took — which is what the platform-specific default mappings exist to avoid. Such a value list is now skipped, in whole: a collectd value list is positional, so dropping one value of several would have the receiver read the next metric’s number under this one’s type. A derive: expression also splits on , like gauge: always did, instead of looking the whole a,b string up as one key and sending a single zero. Only hand-written mappings are affected, and only where they were reporting zeroes.

    See the REST metrics reference and the Prometheus scenario for the full rules.

  • 📥 New module: GearmanClient, a Mod-Gearman worker and result channel. Nothing to do on an existing install — the module is optional and disabled by default. Enabling it lets a Naemon or Nagios Core keep scheduling its checks while this agent pulls them off a gearmand job server and answers them as native queries, with no inbound port on the monitored host. It speaks both flavours of the protocol: ConSol’s Mod-Gearman (Naemon) and Nagios Enterprises’ Nagios-Mod-Gearman (Nagios Core 4.5+).

    Two ways to deploy it, both configured under /settings/gearman/worker:

    • mode = agent (the default) answers only for the host it runs on; a job for any other host_name is answered UNKNOWN rather than executed.
    • mode = proxy answers every check on the queues it registered, whichever host the core meant it for — one domain-joined Windows box running the checks of a whole hostgroup through check_nrpe, check_wmi and the rest. A proxy reaches everything its own credentials reach, so keep the key to those queues to the hosts that should have it.

    The same module submits passive results into the core’s result queue (/settings/gearman/client, channel GEARMAN, command submit_gearman), which is what lets a Mod-Gearman installation drop NSCA. The two halves are independent: configure either one and leave the other empty.

    Two things a Nagios operator usually has to unlearn when writing the check_command on the core, since neither fails in a way that names the cause:

    • write host=$HOSTADDRESS$, not -H $HOSTADDRESS$ — a two-character first token puts the agent’s argument parser into key-value mode and the check answers with a help screen;
    • write warning=load gt 80, not warning=load>80 — > is a metacharacter and allow nasty characters is false by default, as in NRPEServer.

    On Windows the module is part of the Various client plugins feature of the installer. See Mod-Gearman for the full setup on either core, and Securing NSClient++ for the shared-key model.

    The module is marked experimental, and beyond the usual meaning of that mark — settings, queue handling and output may still change — it has not been tested at scale. It is verified end to end against a real gearmand on both cores, but not against hundreds of hosts, a deep job backlog, or a proxy answering for a large hostgroup. Roll it out to a slice of the estate first and keep the transport you have until you are satisfied.

  • 🧪 New modules and check commands are now marked experimental. Nothing to do on an upgrade: every check keeps working exactly as before. A module or check command that is new enough that its options, filter keywords and output may still change now says so — nscp test appends (experimental) to the name in queries, aliases, list and plugins (and shows a Status: line in desc), the web UI shows an Experimental chip on the module and query pages, the REST API reports it as an experimental field on modules, queries and aliases, and the reference documentation renders a marker in the command tables plus a note on the command itself.

    The recently added check_* commands of CheckDisk, CheckDocker, CheckNet, CheckNSCP and Scheduler are marked, as are the CheckMSSQL, CheckMySQL, CheckSecurity, CheckWindowsApps, GearmanClient and NSCANgClient modules in full.

    The marker is not a warning that a check is broken — it is a statement about stability: pin the options and syntax you depend on, and re-read the command’s reference page after an upgrade. Marks are removed as the commands settle.

    If you build your own modules, declare it in module.json — "experimental": true inside "module" for the whole module, which covers every command it registers, or on a single command entry when only that check is new:

    "commands": {
    "check_new_thing": { "description": "…", "experimental": true }
}

  • 📦 Check your setup Common code moved out of the individual plugins into shared libraries. Code that every plugin used to compile privately now lives in one place, so the install is smaller: about a fifth on Debian and RedHat, and on Windows every TLS-capable module sheds the private copy of OpenSSL that used to make up most of it. New libraries ship next to nscp.exe: nscp_net.dll (socket and TLS helpers), nscp_client.dll (the client-side command line handling the sender modules share), nscp_json.dll (Boost.JSON), and OpenSSL itself as libcrypto-3-x64.dll and libssl-3-x64.dll (libcrypto-3.dll and libssl-3.dll on 32-bit) — one copy for the whole service, where before each of NRPE, NSCA, check_mk, the web server, the HTTP clients and the checksum checks carried its own. plugin_api.dll also grew, having taken over the settings helpers and the program-options helpers that each plugin used to carry its own copy of. The legacy Windows XP build is not affected: it still links everything statically.

    Nothing to do when installing from the MSI or from the Debian/RedHat packages — they install the new libraries for you, and the modules themselves are unchanged from the outside. Only a hand-rolled deployment needs to check: if you copy modules\*.dll into place yourself rather than installing a package, copy the new libraries (the OpenSSL DLLs included) from the installation root as well, or the modules that need them will fail to load.

  • 📦 Windows on ARM is packaged again, without the Python module. Releases carry NSCP-<version>-ARM64.msi and NSCP-<version>-ARM64.zip once more; ARM64 was built for one release in April 2026 and then withdrawn because the build failed. Nothing to do on x64 or 32-bit Windows, and an ARM64 machine running the x64 package under emulation keeps working — the native package is simply faster.

    One difference from the x64 package: the ARM64 build does not include PythonScript, nor the embedded Python runtime that comes with it. The package is cross-compiled on an x64 runner and there is no ARM64 CPython to embed, so the module and its python*.dll / python*.zip are absent from the MSI and the Python Scripting feature does not appear in the installer. An ARM64 host that needs internal Python scripts should run the x64 package under emulation. CheckExternalScripts is unaffected and can still run a system-installed python.exe.

    One more difference, and this one needs action on a fresh machine: the ARM64 MSI does not install the Visual C++ runtime. The x64 and 32-bit installers bundle it as a merge module, but Microsoft ships no ARM64 merge module for the toolset this is built with, so there is nothing to bundle. Install the Visual C++ Redistributable for ARM64 before the agent, or the service will fail to start with a missing vcruntime140.dll. Most machines already have it — anything that has run a recent ARM64 desktop application will — and upgrades over an existing install are unaffected.

  • 📦 A Raspberry Pi OS package. Releases now carry NSCP-<version>-debian-trixie-arm64.deb, built on Debian 13 (Trixie) — the base of current Raspberry Pi OS 64-bit — for Raspberry Pi 3 and newer, and for Debian 13 arm64 in general. Nothing to do on an existing install; the Ubuntu packages are unchanged and keep working where they already do.

    There is no 32-bit package. Raspberry Pi OS has defaulted to 64-bit since Bookworm, and a 32-bit build would have to be either a slow emulated one or a Debian armhf package that still leaves the ARMv6 boards (Pi 1, Pi Zero W) out. On a 32-bit Raspberry Pi OS install, either reimage to 64-bit or build from source.

    The Debian package is built without the .NET SDK, which Debian does not package, so it ships without the managed (C#) plugin API. The Ubuntu packages still include it.

  • 🔧 The web bundle is built with npm ci and gated on npm audit. npm install tolerates a lockfile that has drifted from package.json and rewrites it, so the bytes in the web zip and in the MSI’s bundled web/dist were not guaranteed to match package-lock.json — the .sha256 manifest the installer verifies proved integrity in transit, not provenance of the dependency tree. npm ci fails on drift instead, and a new step runs npm audit --omit=dev --audit-level=high so a known-vulnerable runtime dependency stops the release build. Nothing to do; contributors whose package-lock.json is out of date will see the build fail rather than see it quietly rewritten.

  • ⏱️ 🔧 Check your setup Reloads now wait for the checks that are running, and a module can no longer unload or restart itself from inside a request it is serving. Nothing to do on a default install; the changes are visible only in a few specific setups.

    • A settings reload holds new checks off a module while its loadModuleEx applies the new configuration, and waits up to five seconds for the checks already inside it to return. A reload is therefore no longer instantaneous on a busy agent, and a check arriving during one waits rather than running against half-applied settings. If a check holds a module for longer than five seconds the reload proceeds anyway and logs which module it was.
    • Unloading the module that is serving the request is refused and answers with an error. In practice this is POST /api/v2/modules/WEBServer/commands/unload (or the same through put_module or the console), which previously took the agent down with it. Unload WEBServer from the command line or restart the service instead.
    • Reloading a listener module from inside a check that the same listener is serving - a script calling core.reload("NRPEServer") from a check invoked over NRPE - is refused with an error instead of leaving that listener dead. Reload it from another transport, or reload the service as a whole. A reload that does not touch the module serving the request is unaffected and still applies before the call returns.
    • Configuration downloaded over HTTP ([/settings] 1 = http://...) now gives up on a read or write that stalls for 30 seconds instead of waiting indefinitely. A settings server that used to take longer than that to answer will now fail the refresh and keep the cached copy.
    • Submissions over NRPE, NSCA, NSCP and check_mk apply the configured timeout to connecting and to the TLS handshake, not just to the exchange. A target that accepts a connection and then goes quiet now fails its timeout instead of holding a scheduler thread.

  • 💥 Check your setup check_nt FILEAGE now checks one file instead of a directory of them. FILEAGE answers with a single age, taken from the first performance value the underlying check produced. The legacy request mapped onto check_files, which walks a whole tree, so a directory argument reported whichever file the walk happened to emit first — not the oldest, not the newest, just arbitrary. The number looked authoritative and meant nothing.

    The request now maps onto check_single_file, which stats exactly one path, so there is only ever one candidate and the age is defined. A FILEAGE naming a single file, which is what the check was always for, is unaffected and reports the same age as before. A FILEAGE naming a directory now fails with an error instead of returning an arbitrary file’s age, and one naming a missing file reports that it was not found. If a check depends on passing a directory, point it at the file it actually means.

    check_single_file lives in CheckDisk, as check_files did, so no extra module needs enabling.

  • 🔧 Check your setup The Windows installer no longer rewrites NRPE transport security it did not configure. The MSI offers two NRPE presets, insecure and secure, and used to apply one whenever it could not recognise the mode an existing or imported configuration was in. It recognised only insecure = true and verify mode = peer-cert, so two perfectly ordinary setups fell through:

    • A listener running TLS without client certificates (verify mode = none). msiexec /i NSCP-….msi IMPORT_CONFIG=… came back with four keys under [/settings/NRPE/server] that the imported file never asked for: verify mode forced to peer-cert, tls version lowered to tlsv1.2+, plus insecure = false and an empty ssl options (#1558).
    • A listener configured without either key — port = 5666 and nothing more, running on NRPEServer’s own defaults. An upgrade read that as “nothing configured here” and wrote the secure preset, so a listener that had never required client certificates started demanding them.

    A configuration whose mode was recognised kept its mode, but still had tls version and ssl options rewritten.

    The installer now reads what the configuration says and applies a preset only where it would overwrite nothing: a fresh install with no NRPE listener configured, or an operator who moves the radio button or passes NRPEMODE=LEGACY / NRPEMODE=SECURE on the command line. It also no longer writes tls version or ssl options at all — both were being set to the value NRPEServer already defaults to, so they added nothing to a new install while overwriting an explicit choice on an existing one.

    Check [/settings/NRPE/server] after upgrading if you install or upgrade on Windows with an NRPE configuration of your own, in particular one imported with IMPORT_CONFIG:

    • verify mode is now left as your configuration has it, and is no longer added where you never set it. If an earlier install silently moved you to peer-cert and you have since issued client certificates, keep it by leaving the setting in your configuration — it will not be re-added for you.
    • tls version is left alone, so a pinned tls1.3 survives the install instead of being replaced with tlsv1.2+.
    • A fresh install is unchanged: it still gets verify mode = peer-cert, or insecure = true with NRPEMODE=LEGACY.

  • 🔧 Check your setup The PDH counter browser now narrows on every filter, and ignores case. Nothing to do unless you have a script or a habit built on the counter browser (nscp sys -- --list …, or exec CheckSystem --list … at the nscp test prompt). Two things changed about which counters it lists:

    • --list, --filter and --counter used to share one variable, so whichever came last won and the others were silently discarded: --list SQL --filter Databases listed everything matching Databases, including counters with no SQL in them at all. Every filter now has to match, so the same command lists what matches both — a narrower result than before. --filter is also repeatable now, so a listing can be cut down one word at a time.
    • Matching is now case insensitive, where it used to be case sensitive. --list disk used to find nothing at all; it now finds the same counters as --list Disk — a wider result than before. PDH capitalises its own names inconsistently and a localised Windows spells them in another language, so having to guess the casing before getting any output was a trap rather than a feature. (The fold is ASCII: the non-ASCII part of a localised name still has to be typed as it is spelled.)
    nscp sys -- --list disk --all --filter queue --filter avg.
\PhysicalDisk(_Total)\Avg. Disk Queue Length
\PhysicalDisk(_Total)\Avg. Disk Read Queue Length
\PhysicalDisk(_Total)\Avg. Disk Write Queue Length

    Unchanged otherwise: a substring test against the whole \object(instance)\counter path, and a --filter with no value is still accepted and still filters nothing.

0.21.0

  • 🔒 🔧 The checks whose argument decides what data is read can now be told which files, queries and counters a caller may ask for. Nothing to do on upgrade: they all default to any, which is exactly what earlier releases did. Those checks take an argument that decides what data is read, and the agent reads it with its own privileges — so where callers choose the argument (NRPE with allow arguments = true, or a REST user not on the no-arguments restricted role) an unrestricted file= is a general file-read primitive. Each module gained a mode setting and an allow list:

    Check Section Mode setting Allow list
    check_logfile [/settings/logfile] file access allowed files
    check_wmi [/settings/wmi] query access allowed classes, allowed namespaces
    check_pdh [/settings/system/windows] counter access allowed counters
    check_files, check_single_file, check_disk_write [/settings/disk] file access allowed files
    check_registry_key, check_registry_value [/settings/system/windows] registry access allowed registry keys
    check_eventlog [/settings/eventlog] log access allowed logs

    The modes are any, allowed (only what matches the list; experimental, since it parses what the caller sent) and predefined (the secure option: only names you configured — [/settings/logfile/files], [/settings/wmi/queries], [/settings/disk/files], [/settings/system/windows/registry], [/settings/eventlog/logs], and for check_pdh the counters already in [/settings/system/windows/counters]). Registry and event-log entries are hierarchical: an entry covers that key or channel and everything below it, matched on whole name segments. Configured names resolve in every mode, so you can name your checks first and tighten the mode afterwards. Some arguments only tighten once a mode is set: a check_wmi namespace= may then no longer be moved off root\cimv2 unless allowed namespaces says so, check_wmi target= must name a target defined in [/settings/wmi/targets], check_registry_* refuses computer= so only the local registry is read, and check_eventlog’s default Application/System channels go through the gate like any other. See Restricting what a check may read, the securing guide and the security notice.

  • 🔒 🔧 Check your setup A new built-in WEB role, metrics, and a monitoring role that can finally scrape. The metrics endpoints are gated by metrics.list (/api/v2/metrics) and openmetrics.list (/api/v2/openmetrics), but the bundled monitoring role granted metrics.get — a privilege nothing checks, so a monitoring user was answered 403 on both endpoints. monitoring now grants the two real ones instead:

    [/settings/WEB/server/roles]
monitoring = public,queries.execute,aliases.list,login.get,metrics.list,openmetrics.list
metrics    = public,metrics.list,openmetrics.list,login.get

    The new metrics role is for a Prometheus scraper: it reads the two endpoints and holds no queries.execute, so it cannot run checks.

    Roles already written to nsclient.ini are never rewritten, so an existing install keeps the role strings it has — including a monitoring line still carrying the inert metrics.get. Update that line by hand (or assign the new metrics role) if you want those users to scrape. Nothing widens by itself on upgrade; see the security notice.

  • 🔒 Check your setup Fleet: encrypted bundles are now opened by the agent. Nothing to do unless you use the fleet server’s Encryption key feature. A bundle the operator seals in the browser (format: enc-v1) used to be refused by the agent as an unreadable archive; the agent now opens it with a key you hand it out of band, and the server never sees that key. Give the key at enrollment with nscp enroll --bundle-key <key> or the FLEET_BUNDLE_KEY installer property, or to an already enrolled host with nscp enroll --update-bundle-keys --bundle-key <key> (several --bundle-key while rotating; on Windows, re-running the installer with only FLEET_BUNDLE_KEY does the same). The key is stored in the enrollment manifest (agent-state.json) beside the host’s private key, never in nsclient.ini. nscp enroll --require-encrypted-bundles (or FLEET_REQUIRE_ENCRYPTED_BUNDLES=1) refuses every bundle that is not sealed, for a fleet server you do not trust with plaintext configuration; it is stored in the manifest too, so the server cannot switch it off. See Central management with NSClient Fleet and the security notice.
  • 🔒 Check your setup check_files no longer follows file symbolic links on Windows. The scan already skipped directory reparse points (junctions, mount points, directory links); it now skips file symlinks too, as the Linux scanner always has, so a link planted inside a scanned tree can no longer make the checksum, line_count or version keywords read a file outside it. Deduplicated and cloud-backed files are still counted. If you relied on check_files counting file symlinks, point it at the link targets instead. Path allow-list wildcards also changed: * and ? in an allowed files entry no longer cross a directory separator, so C:/logs/*.log covers the files in C:/logs only; write C:/logs/**.log for the subtree. See Restricting what a check may read.

  • 🔧 A new built-in WEB role, restricted, runs checks without arguments. Nothing to do on an existing install: the role is added to [/settings/WEB/server/roles] but no user is assigned to it, and client, monitoring and any custom role holding queries.execute keep passing arguments exactly as before. The new role holds queries.execute.noargs instead of queries.execute, which is the REST equivalent of the NRPE server’s allow arguments = false: the caller may run the checks the agent defines, but a request carrying any query-string parameter is refused with 403 Arguments are not allowed for this user. Neither grant implies the other, so the role can never widen into the full privilege; full (*) still confers both.

    [/settings/WEB/server/users/monitor]
role = restricted

[/settings/check helpers/alias]
check_root_disk = check_drivesize drive=/ warning=free<10% critical=free<5%

    Give a restricted caller the checks that need arguments as aliases, as above, so the arguments live in your configuration. Note that every query parameter counts as an argument, including a session token passed the legacy way as ?TOKEN=, so such a client must authenticate with a header.

  • 🔧 Fleet: nscp enroll --unenroll leaves the fleet. Nothing to do. Until now leaving meant deleting the enrollment manifest, the fleet directory and the [/includes] fleet entry by hand; nscp enroll --unenroll does all three and reports each, then a service restart stops the sync. It is a local act: the host stays listed on the fleet server until you remove it there. See Central management with NSClient Fleet.
  • 🔧 Check your setup check_logfile files= now does what it says. The comma-separated form of file= was parsed before the check read its arguments, so it has been ignored for as long as anyone is likely to have tried it: a check passing only files= failed with Need to specify at least one file, and one passing both file= and files= silently read only the file= entries. Both now work, and the two are one list rather than one overriding the other. If a check of yours passes both, it will read the union from this release on - and every name goes through file access in [/settings/logfile] exactly like a file= one. Nothing to do unless you were relying on the entries being dropped.
  • 📅 Check your setup check_installed_software takes dpkg install dates from dpkg-query. Nothing to do on a current Debian or Ubuntu host: the date is the same as before, now read from dpkg-query’s db-fsys:Last-Modified field instead of from dpkg’s internal database. That field needs dpkg 1.19.3 or later; with an older dpkg install_date is now left unset, so an expression on it such as warning=install_date > -7d no longer matches anything there. The check also returns UNKNOWN when dpkg cannot read a package’s file list for a reason other than the file being missing, where it used to leave only that package undated.

0.20.0

  • 🔒 Action required Generated TLS private keys are now created readable only by the agent, and a generated CA no longer ships its private key to clients. Certificates NSClient++ generates itself — including the one a default NRPE start creates when certificate points at a missing file — used to land at 0644 with an unencrypted key inside; they are now 0600 (restricted DACL on Windows), and a generated CA keeps its key in ca-key.pem beside the distributable ca.pem. Existing files are not touched: run chmod 600 /etc/nscp/security/certificate.pem, and if you distributed a generated ca.pem, regenerate that CA and re-issue client certificates — anyone holding the old file can mint certificates that pass verify mode = peer-cert. See the security notice.
  • 🔒 Check your setup The client host-override guard now also covers a credential kept inside the target’s address. Two ways past the 0.19.0 guard are closed (see the security notice): a secret carried in the URL — address = https://h/submit.php?token=SECRET or https://user:password@h/ — now counts as the configured credential it is, and a target that supplies a credential but no address no longer adopts the caller’s host= as its own. Nothing to do unless you relied on one of those to point a credentialed target at several hosts; the remedies are unchanged — pass the credential with the request, configure each destination as its own target and select it with target=, or set allow host override = true.

  • 🔒 Check your setup Undefined-behaviour audit: some inputs that used to misbehave are now rejected. From the security notice; nothing to do unless you relied on one of these:

    • check_cpu time=0 is an error — the window must be at least one second.
    • A threshold or unit suffix that overflows 64 bits (used > 1.0e30T, time=5000000w) is reported as an error instead of silently wrapping.
    • A module whose load fails is dropped from the plugin list instead of lingering half-loaded, and no longer answers exec.
    • NSClientServer (check_nt) and CheckMKServer restart their listener on a settings reload, so a changed port or password takes effect as it already did for NRPEServer. Connections open at that moment are dropped.
    • A Python script can no longer unload the PythonScript module it runs in.
  • 🔒 ⏱️ Inbound TLS handshakes are now bounded by the listener’s timeout. The connection deadline was armed only after the handshake had completed, so the handshake phase itself was unbounded: a host permitted by allowed hosts could open sockets, send nothing, and pin one connection object, file descriptor and buffer each, indefinitely. The plain-TCP path was bounded by timeout (30 s by default) all along; the SSL path — the NRPE default — was not. A client on a slow or lossy link that cannot complete a handshake within timeout is now dropped instead of lingering; raise timeout on the listener if that is too tight for your network. See the security notice.
  • 🔒 Check your setup The NRPE client now says so when it is not authenticating the server, and generated certificates carry a usable SAN. verify mode defaults to none, so ssl = true alone gives encryption with no peer authentication and undetectable on-path impersonation. The default is unchanged, but the client now logs one error line per target at its first check; set verify mode = peer-cert with ca pointing at the issuer to silence it and actually authenticate the server. Generated certificates now name the machine itself rather than only localhost, so verification is possible at all — regenerate an existing one to use it. See the security notice.
  • 🔒 Check your setup The 512-bit Diffie-Hellman parameter file is no longer shipped. security/nrpe_dh_512.pem was installed alongside nrpe_dh_2048.pem and was the default of an unused settings helper. Nothing in the agent used it — the NRPE server has defaulted to nrpe_dh_2048.pem — but 512-bit DH is Logjam-broken, and an operator copying the shipped default into dh inherited it. The file and the dead default are gone. If you set dh to nrpe_dh_512.pem explicitly, change it to ${nrpe-dh}/nrpe_dh_2048.pem before upgrading; otherwise the listener will fail to start with a missing DH file. An existing copy on disk is left where it is by the upgrade. See the security notice.
  • 🔌 .NET plugins are back, on Windows and Linux. The DotnetPlugins module is built again, now hosting an installed .NET runtime (8.0 or newer) through hostfxr instead of the old Windows-only C++/CLI build, so it also works on Linux. Nothing to do on a default install: the module is not loaded unless you add DotnetPlugins = enabled to [/modules], and no runtime is bundled. The Windows installer regained the “.NET plugin support” feature (selected by default, installs modules/DotnetPlugins.dll and the managed API in modules/dotnet/); the Linux packages ship the same files when they were built with the dotnet SDK. Plugins are configured under [/settings/dotnet/plugins] (<alias> = <assembly>), see the DotnetPlugins reference and Extending with .NET. Plugins written against the pre-0.6 C++/CLI API (NSCP.Core.dll for the .NET Framework) must be rebuilt against the new net8.0 NSCP.Core.dll; the interfaces are the same.

  • 📤 The WEB server can now cache passive results and serve them over REST. Nothing to do: the feature is off by default and an existing install is unchanged. Set enabled = true under [/settings/WEB/server/results] and restart the service — enabled and channel are read when the web server starts, because a submission channel cannot be registered by a settings reload — and WEBServer registers a submission channel (WEB by default), keeping whatever is submitted to it in memory so a monitoring system that cannot reach the agent can poll the results back out of it. While it is off no channel is registered and the endpoints answer 503.

    Only one result is kept per key (${host}/${alias-or-command} by default); mode picks which of two results for a key survives — last (the default, the newest wins) or worst (the most severe wins, so a problem that recovered before the next poll is still reported). GET /api/v2/results drains what it returns unless clear on poll = false, which is what makes worst mean “worst since the last poll”.

    Four endpoints expose the cache — GET /api/v2/results, GET /api/v2/results/{key}, DELETE /api/v2/results and DELETE /api/v2/results/{key} — behind the new results.list, results.get and results.delete privileges. Those privileges are not part of any bundled role except full, so grant them explicitly to whoever polls:

    nscp web add-role --role poller --grant results.list,results.get,login.get

    The cache is bounded (max entries, default 1000 keys; max age, default no expiry). See the REST API results page for the full contract.

    The check_nsclient binary bundled with the packages (Windows MSI and the Linux DEB/RPM alike) moves from 1.0.1 to 1.1.0, which is the version that gained the results commands — results list, results show, results delete, results clear and results feed, the last of which polls an agent’s cache and submits everything in it to Nagios as passive check results. Nothing else about the plugin changes and no existing invocation is affected.

  • 🔧 tls version now accepts every spelling it documents. tlsv1.0+, tls1.0+, 1.0+, tlsv1.3+, tls1.3+, 1.3+, sslv3+, ssl3+ and any were rejected with “Invalid tls version” — for an NRPE listener that surfaced as “listener failed to start”. Four separate copies of the table of accepted spellings had drifted apart: the maximum-version lookup never stripped the trailing + the way the minimum-version lookup does and listed only some of the + forms literally, and the floor lookup the listener validates through was missing sslv3 entirely. They now share one table. Nothing to do; the default tlsv1.2+ was never affected.

0.19.0

  • 🔒 A check_service filter that matched no service no longer kills the agent. On Windows, check_service "filter=name = 'nosuchservice'" terminated the whole nscp process instead of returning a result; check_logfile’s column() keyword could be driven into the same fault. Both now return the documented empty-result contract (UNKNOWN: No services found). Nothing to configure — if you worked around it with service=<exact name> and no filter=, service name patterns are usable again. See the security notice.
  • 🔒 Check your setup A client target no longer lets a request send its configured credentials to a destination the request names. host=, port= and address= used to move the destination while the target’s password or token came along, so anyone able to run a client module’s submit_*/check_* command — a REST user in the seeded monitoring role, or an NRPE peer with allow arguments = true — could have the agent send that credential to a host of their choosing. That combination is now refused. A target with no credential, a request supplying its own password=/token=, and a request that does not move the destination are unaffected. If you relied on one credentialed target plus host= to reach several servers: pass the credential with the request, configure each server as its own target and select it with target= (which now works for queries too), or set allow host override = true on the target. See the security notice.
  • 🔒 REST script uploads are staged in a private, randomly named file. PUT /api/v2/scripts/… no longer writes the upload to ${temp}/<name>, where a local user could plant a file of the same name and have it imported as a command. No configuration change; a staging failure is now reported as an HTTP 500 instead of importing whatever was on disk. See the security notice.
  • 🔒 Check your setup Modern layout (opt-in, experimental): the shared folder must be a real directory. A %ProgramData%\NSClient++ that is a junction or symbolic link is refused by the installer, by nscp settings --migrate-layout modern, and at service start (which fails rather than loading a configuration from behind a link). Relocate the folder with a [paths] override in boot.ini instead. Legacy (default) installs are unaffected. See the security notice.
  • 🔒 💥 Check your setup A multicast collectd target now sends through one interface, not all of them. A CollectdClient target with no address goes to collectd’s default multicast group (239.192.74.66:25826), and every such target used to send a copy of the metrics through every local interface of the matching address family — putting them on segments the operator never meant to reach. The new per-target multicast interface setting decides this: auto (the default) sends one copy through the interface the routing table picks, all restores the previous fan-out, and a comma-separated list of local IP addresses sends through exactly those. Unicast targets are unaffected. If you depend on a multicast target reaching several segments, set multicast interface = all on it. See the security notice.
  • 🔒 Repeated rapid-fire failed WEB logins from one IP are now blocked for longer each time. The block that follows auth rate limit max failures consecutive failures used to be a fixed auth rate limit block seconds window (default 60 s) that let an attacker resume guessing at a steady rate forever. A further block now doubles the wait, up to an hour, and resets after a successful authentication or an hour of quiet. Only failures arriving at machine speed escalate: a client retrying a stale password on a schedule keeps the base delay, so it cannot lock out everyone sharing its address behind NAT or a proxy. Nothing to do on a default install. auth rate limit max failures = 0 still disables the limiter outright. See the security notice.
  • 🔒 An NRDP submission over an unverified https link now says so in the log. When a target’s verify mode resolves to no peer verification, the module logs a message naming the endpoint — the token then goes to whichever server answers — matching what the Icinga client already does. The connection itself is unchanged. The verify mode help text was corrected at the same time: it listed three values the client-side parser rejects (client-once, workarounds, single) and recommended none for self-signed certificates; use peer-cert with ca pointing at the certificate instead. See the security notice.

  • 🔧 Check your setup nscp test now has a real prompt, and writes a command history file. On a terminal the prompt gained line editing, persistent history, tab completion against the command registry, syntax highlighting that shows an unknown query or module name in red before you press enter, and log messages that redraw around what you are typing instead of landing in the middle of it. See Test mode. Two things to know:

    • History is written to a per-user file — %APPDATA%\NSClient++\console-history.txt on Windows, $XDG_STATE_HOME/nscp/console-history or ~/.nscp_history elsewhere (created mode 0600 on POSIX). Commands typed at the prompt can carry credentials, so if you would rather keep nothing on disk set history size = 0 under [/settings/cli]. That section also holds history file and color.
    • With stdin not a terminal nothing changes — no prompt, no history, no colour, and the core keeps writing the log itself. Piping commands in does now work on Windows, where the readiness check used a console-only API and silently ignored a file or pipe; an exhausted stdin no longer spins at 100% CPU on POSIX; and end of input is no longer treated as a reason to exit, which is how the agent is normally started under a supervisor.

    Completion after load/enable offers the modules that are not already loaded or enabled, and unload/disable the ones that are. The first such completion in a session pauses while the agent reads the module directory, once per process.

  • 🔧 The console log is no longer held back in a buffer. Nothing to do. The console log backend installs a 64 KB buffer on standard output and nothing emptied it, so on Windows log output sat there until something else happened to flush the stream — in nscp test the only thing that did was reading the next line of input, which is why the log appeared to catch up only when you pressed a key. Every message is flushed as it is written now.

    The same fix means a redirected console log streams instead of accumulating: nscp test > log.txt, a container, or a supervisor capturing standard output now see each line as it is logged rather than nothing until 64 KB has built up or the process exits.

  • 🔧 --no-stderr and the oneline log format now take effect. Nothing to do unless you were working around the old behaviour. Both were passed to the log level parser, which does not know them, so they were rejected with Invalid log level: no-std-err in the log and never applied. They reach the log driver now.
  • 🔧 target= now selects a configured target on the query path as well. The shared client machinery only ever applied target= / -t when a command was run as an exec; as a query — which is what a REST or NRPE caller gets for check_* and submit_* — the argument was accepted and then ignored, so the call silently went to the default target. It is applied on both paths now, with any explicit option (host=, timeout=, …) still winning over what the selected target says. A query that passed target= and relied on reaching default anyway will now reach the target it named.
  • ⏱️ Check your setup collectd submissions now honour timeout and retries, and report failed sends. Both target settings were read into the connection but never used on the UDP path, and the send discarded its result entirely — an unreachable target, a full socket buffer or an oversized datagram looked exactly like a successful send, so metrics that never arrived left nothing in the log. A failed send is now retried up to retries times (default 3, 20 ms apart) and logged once per distinct failure; the whole send — name resolution included — is bounded by timeout (default 30 seconds), after which the remaining datagrams are abandoned with a message. Retries apply to sends that failed locally, so no datagram the receiver already has is ever sent twice. Nothing to do unless you set a large retries on a collectd target — it now costs real time, bounded by timeout.
  • 🔧 Check your setup An Icinga target address with a path prefix is now honoured. The path of a target address (https://proxy.example.com/icinga/) was parsed and then dropped: every call went to /v1/... on the host, so an Icinga 2 master published under a reverse-proxy subpath could not be reached and requests landed on a path the operator did not intend. The prefix is now prepended to every API path (/icinga/v1/actions/process-check-result). Addresses without a path — the normal https://icinga.example.com:5665 form, with or without a trailing / — are unaffected. If a target address carries a path that is not a subpath of the API (a leftover from another client’s configuration, say), remove it: it is now sent.

0.18.1

  • 🔒 Check your setup Icinga API submissions now honour the configured timeout, and credentials no longer reach the trace log. The IcingaClient module’s HTTP calls previously waited forever — the target’s timeout setting (default 30 s) was read but never applied — so a stalled Icinga endpoint could silently wedge passive-result submission; set timeout = 0 on the target if you depend on the old unbounded wait. The same pass masked password/token values in the trace-level target dump (this also covers the other client modules sharing that machinery) and added a log message when an https submission runs with certificate verification disabled (verify mode empty or none). See Security notices.
  • 🔒 Filter expressions are now bounded in length and nesting depth. A filter / warning / critical expression — and a %(...) expression placeholder inside a syntax template — longer than 1024 characters or nested more than 64 parentheses deep is now rejected at parse time instead of being evaluated, failing with a clear “exceeds the maximum length/depth” error. The where-parser and the expression evaluator both recurse with the shape of the input, so an unbounded or deeply nested expression could exhaust the stack and crash the agent. Real filters are a small fraction of these limits, so the default install and every normal configuration are unaffected — only a pathologically large or deeply nested expression is refused. See the security notice.
  • 🔒 Check your setup CheckExternalScripts hardening. A hardening pass over the external scripts module tightened several rough edges: the ext-scr install argument lockdown now writes to the setting the module actually reads (previously it was a no-op, so a lockdown could silently not apply), the command timeout is enforced on every execution path with output capped, the show/delete sandbox resolves symlinks, and %/^ are blocked on the shell-fallback path. The default install is unaffected (arguments are off by default). If you rely on ext-scr install to disable arguments, re-run it after upgrading so the effective setting is written. See the security notice.
  • 🔒 Check your setup NSCA-NG cert mode now actually verifies the server (and presents the client certificate). In 0.18.0 the NSCANgClient cert mode (use psk = false) applied its TLS configuration to the OpenSSL context after the connection object had been created from it, and OpenSSL copies the verify mode, client certificate, cipher list and TLS-version bounds out of the context at creation time — so verify mode = peer-cert was silently ignored, any certificate the server presented was accepted, and the configured client certificate was never sent. The configuration is applied before the connection is created now. Two operator-visible consequences: a cert-mode target that “worked” against a server whose certificate does not chain to the configured ca (or does not match the host name) will now fail to connect — that is the verification working; fix the server certificate, or opt out explicitly with insecure = true if you accept the MITM risk. And servers that require a client certificate will start seeing it. The default PSK mode (use psk = true) is unaffected. See Security notices.
  • 🔒 Check your setup NSCA: an unrecognized encryption value is now a hard error instead of silently running without encryption. A typo’d algorithm name (aes-256), or one not compiled into the build, used to fall back to no encryption on the end carrying it. Since the ciphers must match, a one-sided typo showed up as the peer rejecting every submission with a CRC error rather than as accepted plaintext — but that failure gave no hint of its cause, and a value broken the same way on both ends did run plaintext while looking encrypted. Now the NSCAServer module refuses to load and an NSCAClient submission fails, each naming the problem and listing the available algorithms. Default installs (aes256) are unaffected. Breaking only for setups relying on the fallback: fix the algorithm name, or set encryption = none explicitly if plaintext was intended — this includes builds compiled without crypto++, where any cipher name previously degraded to plaintext and the server now refuses to start. See the security notice.
  • 🔒 Check your setup NSCA hardening: empty-password warning, performance data = false honoured, wire-field validation. Enabling NSCA encryption with an empty password now logs an error on both ends (the password is the key, so an empty one is a well-known key) — set the same password on both ends to clear it. NSCAServer’s performance data = false now actually strips perfdata from forwarded submissions (it was silently ignored). Inbound host/service names are stripped of control characters and out-of-range status codes are clamped to UNKNOWN. No action needed on a default install. See the security notice.
  • 🔒 Check your setup NRDP submissions now honour timeout and retry. Both settings were parsed but never applied: a submission to a server that accepted the connection and then stalled hung the submission thread forever, and failed submissions were never retried. Every step of the exchange (connect, TLS handshake, proxy tunnel, request, response) now runs under the configured timeout (default 30 seconds for configured targets, 10 for one-shot nscp client submissions), and transport failures are retried up to retry times. Nothing to do unless your NRDP endpoint legitimately takes longer than the timeout to answer — raise timeout on that target. The response body is also capped at 5 MB, far above any real NRDP reply. See the security notice.
  • 🔒 A tls version with a trailing + now means “that version or later”. 1.2+ (the common default) previously negotiated TLS 1.2 only; it now also permits TLS 1.3, and any is accepted as the documentation always claimed. This applies everywhere the setting exists: NRDP and the other HTTP-based clients, the NRPE/NSCA clients and servers, and check_tcp. No action needed; pin an exact version (tls version = 1.2) if a peer misbehaves when TLS 1.3 is offered. See the security notice.
  • 🔒 Check your setup The Elastic module now verifies HTTPS server certificates and can authenticate. ElasticClient previously hardcoded TLS verification off; an https:// address now defaults to verify mode = peer against the platform CA bundle, with new tls version, verify mode and ca settings to tune it. New user/password and api key settings authenticate against secured clusters (Elasticsearch 8+ defaults), and a new timeout (default 30s) bounds each submission. If you rely on a self-signed certificate, point ca at it or set verify mode = none explicitly. See Security notices.
  • 📤 Check your setup The Elastic module no longer sends the legacy _type parameter by default. Mapping types were removed in Elasticsearch 8, which rejects bulk requests carrying them, so the event type, metrics type and nsclient log type defaults are now empty. Only Elasticsearch 6.x or older needs them: set the old values (eventlog, metrics, nsclient log) explicitly to keep the previous behaviour. Batched documents also now get distinct ids — previously all documents in one bulk request shared an id and overwrote each other, so multi-entry events show up completely now.
  • 🔒 Check your setup check_mk client targets: configured TLS settings are honoured again. check_mk_target_object::read() added the SSL keys (use ssl, certificate, verify mode, ca, …) to its settings registry but never called register_all()/notify(), so values set on a [/settings/check_mk/client/targets/…] section were silently ignored and the client connected in plaintext regardless of configuration. The keys are read (and documented) again. If you configured use ssl = true on a check_mk target, the connection becomes TLS on upgrade — make sure the server side actually speaks TLS, or the check starts failing. Details in the security notice.
  • 📨 Check your setup Syslog client targets: configured severities and templates are honoured again. The same defect existed in the syslog client’s target object: the severity, facility, tag_syntax, message_syntax and per-status severity keys on a [/settings/syslog/client/targets/…] section were never read, so the built-in defaults (error/kernel/…) always won. Values you configured — perhaps years ago, without effect — now apply; if your syslog routing depends on the previously effective defaults, review the target sections for stale keys.

  • 📨 🔒 Check your setup Syslog messages now carry the RFC 3164 HOSTNAME field, and several syslog options work for the first time (see the security notice). What changes on the wire and in behaviour:

    • Datagrams now read <PRI>TIMESTAMP HOSTNAME TAG MESSAGE. The hostname setting under [/settings/syslog/client] — until now read but never used — fills the HOSTNAME field (default auto, the machine name). Receivers that promoted the tag (default NSCA) to origin host will now file records under the real host name; adjust any log-parsing rule that keyed on the old, hostname-less format.
    • The tag_syntax and message_syntax target settings now reach the wire. They were stored under keys the sender never read, so a settings-defined target sent an empty tag and dropped the message text.
    • The per-state severity options (ok-severity, warning-severity, critical-severity, unknown-severity) passed as command arguments now take effect; they too were stored under keys that were never read.
    • An unknown severity or facility name now degrades to priority <13> (user.notice) instead of <0> — which is kernel.emergency, a priority many receivers page or broadcast on. A missing per-state severity now falls back to the base severity instead of tripping that fallback.
    • All C0 control bytes and DEL in the outgoing line are replaced with spaces (previously only CR, LF and NUL), so check output cannot smuggle ANSI escape sequences into the receiver’s log.
  • ⏱️ Check your setup The Graphite timeout is now enforced — as a budget for the whole submission. It was doubly dead before: the value the operator configured never reached the connection (the lookup read a map the well-known timeout key is not stored in, so the default 30 always won), and the connection did not use even that — resolution, connect, the TLS handshake and every write ran with no deadline, so a stalled carbon endpoint could hold the submitting thread for the OS-level TCP timeout, or indefinitely on a stuck write. The configured timeout (default 30s) is read now and bounds the whole submission as one budget, like the SMTP client’s. A target whose submissions previously completed by quietly taking longer will now fail at the configured value; raise timeout on targets talking to a slow relay. See Security notices.
  • 🧹 The Graphite retry setting is not honoured and is no longer read. The module always made exactly one attempt per submission; reading the value made it look otherwise, and a retry loop would multiply the worst-case time a stalled endpoint can hold the submitting thread by the retry count. retry/retries are registered for every client module centrally, so they still appear in the GraphiteClient reference, but GraphiteClient does not act on them. Mirrors the SMTP retry change in 0.18.0.

0.18.0

  • 💥 Check your setup check_nscp is now a filter check, and it can see crash reports again. Crash reporting itself has always worked — the agent has archived crash dumps since 0.4.x — but check_nscp’s count of them has not, for two independent reasons that accumulated over the years:

    • The count matched files whose extension equalled txt, while the helper it used returns the extension with its leading dot (.txt). That comparison has been false since the check was written in 0.4.2, so the crash count read 0 whatever was in the folder.
    • 0.6.10 dropped Google Breakpad, whose vendored submodule and build machinery had become a dependency burden, along with the separate crash-report sender tool that shipped with it. The handler that replaced it writes one plain-text <timestamp>.crash file per crash — the exception, the faulting address and the module it landed in — where breakpad left a <guid>.dmp minidump plus a <guid>.dmp.txt description. From 0.6.10 on, even a corrected .txt match would have found nothing.

    Separately, 0.4.3 stopped the module reading the archive folder from [/settings/crash] archive folder and hardcoded the compile-time default instead, so on any installation that had moved the archive folder the check was looking in the wrong place as well.

    All of that is fixed. Crash reports are recognised by .crash, and still by .dmp and .txt so pre-0.6.10 archives keep counting; the configured archive folder is read again; and check_nscp now exposes crashes, last_crash, crash_age, errors, last_error, uptime, version and date as filter keywords, accepts the usual filter / warning / critical and top-syntax / detail-syntax options, and emits perfdata for whichever keywords the thresholds name.

    The default verdict is unchanged — any crash report or any logged error is CRITICAL — but two things change for existing users. The message is now N crash(es), M error(s), uptime <duration> without the appended last crash: / last error: fragments. To put them back, pass a detail-syntax:

    check_nscp "detail-syntax=${crashes} crash(es) (${last_crash}), ${errors} error(s) (${last_error}), uptime ${uptime}"

    And because the crash count now works, an agent with an old report still sitting in the crash archive folder will start reporting CRITICAL where it previously read 0 — threshold on crash_age (for example "crit=crash_age < 7d") if you only care about recent crashes, or clean the folder out. Crash reports remain a Windows-only concept; on Linux there is no crash handler, so crashes is always 0.

  • 📤 Check your setup check_and_forward now actually submits the result. The command ran the wrapped check, answered Message submitted and delivered nothing: the submission was built in a form the channels could not read, so NSCA, NRDP, Graphite and every other client module received a message with no results in it. It now submits like a scheduled check does. If you had given up on the command, it works — and if you built a workaround around its silence (for instance a schedule that exists only to be triggered), that workaround is no longer needed. The command also gained channel (target still works as a synonym), alias, destination and source options, and names the result after the command when no alias is given.

    Breaking: the command no longer accepts positional arguments for the wrapped command. check_and_forward command=check_cpu warn=load>80 used to (try to) hand the bare trailing tokens to the wrapped command; it now fails to parse. Pass each wrapped-command argument through arguments= instead, one per argument:

    check_and_forward command=check_cpu "arguments=warn=load>80" "arguments=crit=load>90"

    The positional form had to go because its parser also swallowed the CLI’s own --argument key=value tokens, which is what fed the wrapped command garbage and made it fail. If a submission is rejected by the channel the command now reports that failure instead of Message submitted — including when only one channel of a comma list (channel=NSCA,GRAPHITE) fails, which previously was silently reported as success.

  • ⚙️ A reload now loads modules enabled in an included file since the last one. An [/includes] file is read once when the configuration is loaded and served from memory after that, so a module switched on in one — most importantly fleet.ini, which the fleet sync rewrites whenever a bundle changes — was not actually loaded until the service next restarted. Nothing said so: the file on disk was right and a fleet host reported itself in sync, while the module quietly did nothing. The visible case was a fleet bundle turning on NRDPClient and Scheduler to start passive submissions, which then never arrived. A reload now re-reads the included files first, so settings changed in them take effect and newly enabled modules are loaded; modules already running are left alone. Two things are unchanged: a module disabled since the last load keeps running until the service restarts, and [/modules] in the main nsclient.ini is still only read at startup.
  • 📅 New: run scheduled checks on demand with run_schedules. After editing nsclient.ini you no longer have to wait out the interval to see the new result on the monitoring server — nscp client --boot --query run_schedules (optionally --argument schedule=<alias>) runs the configured schedules now and submits their results on their normal channel. It is a regular check command, so it also works over NRPE, REST and in nscp test. Nothing changes for existing configurations; the timers are untouched. See Passive monitoring → Step 6.
  • 🚫 A denied check is no longer submitted as a passive result. The permission layer answers a denied query as a successful query carrying an UNKNOWN “Permission denied” payload, and both run_schedules and check_and_forward forwarded that to the monitoring server — overwriting the last real result for that service while telling the caller it had succeeded. Both now refuse with Permission denied: not allowed to run <command>, nothing was submitted and touch no channel. If you restrict what a REST or NRPE identity may run, expect the denial as an error where you previously saw a stale UNKNOWN appear on the server. See Permissions.
  • 🔧 Check your setup settings --update --add-defaults --use-samples now writes the sample objects. The flag was parsed and never read, so it behaved exactly like the plain invocation. It now writes the registered /sample sections, and --remove-defaults strips them again — the two are now exact inverses. An edited sample is still never overwritten or removed, and without the flag the output is byte-for-byte what it was. If you have scripted --add-defaults --use-samples expecting today’s (sample-free) output, drop the flag.
  • 💬 Check your setup nscp client --query <cmd> no longer appends “No module was specified…”. The line was appended to every result when no --module was named. Scripts that stripped or matched it can stop; naming a module is unchanged.
  • 🔧 Settings writes work again when [/includes] names a directory. Saving handed the directory path to the INI writer, and the resulting “Is a directory” error aborted the whole save — so nscp settings --set and the web UI failed and the main file was never written. Directory includes are read-only by nature and are now skipped when saving. If you worked around this by removing a directory include, you can put it back.
  • 🔒 Check your setup NRDP HTTPS submissions now verify the server certificate by default on the nscp client/REST path. Previously an https:// submission made that way with no verify mode set trusted any certificate silently (configured targets already defaulted to peer). If you submit to a self-signed NRDP endpoint that way and want to keep skipping verification, pass --verify none (or point --ca at the certificate) explicitly. Plain http:// is unaffected. Two further NRDP hardening fixes ship in the same release — a malformed server response can no longer crash the agent, and the NRDP token and any proxy-URL credentials are redacted from the trace log. See Security notices.
  • 📡 Check your setup --source-host / --sender-host now name the sending host, on every client module. They were registered against the destination container, where the well-known host key is routed into the typed address field — so naming a source host silently redirected the connection to it, and the sender the handler reads was never set. SMTPClient and NRDPClient had each worked around this by registering their own copies, which made the option name ambiguous and so unusable on those two modules (option '--source-host' is ambiguous). The options are registered once now, against the sender. If you had scripted around the old behaviour by passing --source-host to redirect a connection, use --host or --address for that instead.
  • 🔒 Check your setup SMTP submissions now verify the server certificate against the agent’s CA bundle. SMTPClient relied on OpenSSL’s built-in default verify paths, which on Windows do not include the Windows certificate store — so the default security=starttls failed verification against Gmail, Microsoft 365 and every other public provider there, and insecure-skip-verify was the only way through. A new ca target setting (and --ca argument) defaults to ${ca-path}, the same trusted bundle the other TLS clients use: the distribution’s CA store on unix, the exported Windows ROOT store on Windows. If a Windows SMTP target was only working because you set insecure-skip-verify = true, remove it and retry — verification should now succeed. For an internal relay with a private CA, point ca at that bundle instead of waiving verification. Set ca = none to restore the old behaviour. A bundle that cannot be loaded now fails the submission with a message naming the file, rather than failing the handshake later with an unrelated-looking issuer error. A target that names no ca at all — a one-shot command line, or a default target — falls back to the same bundle, resolved once at module load, so no submission path is left on OpenSSL’s built-in verify paths by accident.
  • 🔒 SMTP client security hardening. The same pass closed a set of trust gaps in SMTPClient: data pipelined into the STARTTLS greeting is refused rather than trusted as post-handshake input, the EHLO name is validated for command injection before it reaches the wire, and ESMTP capabilities are matched per reply line instead of by substring search. No configuration change is needed. See Security notices.
  • ⏱️ Check your setup The SMTP timeout is now a budget for the whole submission rather than a fresh deadline per operation (and per resolved address). A target that previously completed by using several times its configured timeout across a slow session will now give up at the configured value; raise timeout on targets talking to a slow relay.
  • ✉️ SMTP messages now carry a Message-ID header. Nothing to do — it improves deliverability and gives mail administrators a handle to trace a notification by.
  • 🧹 The SMTP retry setting is not honoured and is no longer read. The module always made exactly one attempt per submission; reading the value made it look otherwise. retry/retries are registered for every client module centrally, so they still appear in the SMTPClient reference, but SMTPClient does not act on them.
  • 🔒 NRPE hardening: a new expose version setting, and the metachar guard now also checks decoded input. Nothing to do on a default install. Two things are worth knowing. NRPEServer gained expose version (default true, which keeps the legacy banner check_nrpe expects); set it to false to answer the unauthenticated _NRPE_CHECK ping with a generic message instead of the exact build. And allow nasty characters = false now re-checks the decoded command and arguments, not just the raw wire bytes — with a non-UTF-8 encoding set, a multi-byte sequence could previously decode into a metacharacter that was never literally on the wire, so a request the guard was always meant to block may now be rejected. Separately, nscp nrpe install reads the stored verify mode again instead of silently resetting it on a re-run. See the security notice.
  • 🔒 Check your setup WEB server security hardening. A review of the WEBServer module produced several defense-in-depth fixes (session tokens now come from the OpenSSL CSPRNG, cookie-name matching requires a name boundary, the installer refuses an HTTPS→HTTP redirect, and the legacy grant’s startup warning now names /settings/query.pb). The default install needs no action. Two changes touch observable behaviour: a script or module name that begins with - is now rejected (rename it; interior dashes are fine), and the legacy POST /auth/logout route now enforces allowed hosts like the rest of the API (a caller outside the perimeter gets 403). A third only bites on a broken system: if the OpenSSL CSPRNG fails, the server now refuses to issue a session token (HTTP 500, logged as SECURITY:) rather than falling back to a weaker generator. See the security notice.
  • 🔒 The bundled OpenSSL is updated from 3.5.4 to 3.5.8 in the Windows builds, picking up the fixes from four upstream security releases on the 3.5 LTS line. The most relevant fix for NSClient++ is CVE-2025-11187, a stack buffer overflow parsing a crafted PKCS#12 file — reachable through check_certificate when it scans certificate files that less-trusted principals can write to — alongside further PKCS#12/ASN.1 and TLS-stack fixes. No configuration change is needed. The Linux packages link the distribution’s OpenSSL and are unaffected. See Security notices.

0.17.0

  • 🏷️ Check your setup Check-specific filter keywords that clashed with the generic summary keywords are renamed. A handful of checks registered their own keyword named status, count or total — the same names as the built-in summary keywords (%(status), %(count), …). The check-specific value won in filter/warning/critical and detail-syntax, while top-syntax and the reference documentation showed the generic one, which was confusing. Each such keyword now has a distinct, documented name:

    Check Old New
    check_cpu, check_cpu_utilization total usage
    check_battery status battery_status
    check_network status, total link_status, throughput
    check_os_updates count updates
    check_patch_age count patches
    check_pending_reboot count signals
    check_printjobs status job_status
    check_printqueue status printer_status
    check_installed_software (Linux) status package_status
    check_activation status activation_status
    check_docker status container_status
    check_connections count, total connections, total_connections
    check_dns count records
    check_http status status_message
    check_shadowcopy count copies
    check_disk_health total size

    Existing configurations keep working: the old names remain as undocumented deprecated aliases with unchanged behaviour, so filters like check_cpu "warn=total > 80" still work. Migrate to the new names at your convenience; only they appear in the reference documentation. A few behaviour changes ride along:

    • check_os_updates’ default output now reports the actual number of updates (rendered from the detail line via ${list}) instead of the matched-row count the old default showed.
    • Three default perfdata keys change because the default perf-config lists the renamed keyword: check_cpu_utilization (Linux) cpu_total → cpu_usage, check_patch_age patch_count → patch_patches, check_pending_reboot reboot_count → reboot_signals. Pass your own perf-config=extra(...) with the old (alias) keyword to keep the old key. All other perfdata keys are unchanged (the renames keep their original perf suffixes, and check_connections’ default perf-config intentionally still uses the alias for series continuity).
  • 🔒 Check your setup ${host} and friends now resolve in attachment paths and in [/includes]. Host name placeholders were only expanded in settings urls and in the url an attachment is fetched from, not in the path it is written to nor in an included file name. An unknown ${...} token in a path is not an error - it resolves to the installation directory - so a configuration such as [/attachments] ${shared-path}/${host}.ini = ... did not fail, it quietly wrote one file with the installation directory in its name. Those paths now name the host, which changes where such a file lands: check any ${host}, ${hostname} or ${domain} you already have under [/attachments] or [/includes], and remove the workaround if you scripted around this. Configurations without a host name placeholder are unaffected. When the substitution lands in a local path, the value is sanitized to the characters a legal host name can contain (see the security notice). Like nscp settings --switch, nscp settings --migrate-to (and the REST migrate) now keeps a placeholder you pass it as-is in boot.ini while migrating into the expanded per-host file, so the template survives on a fleet-managed machine.
  • 🔢 Check messages can now be told how to render their numbers. Every filter check gained four options - decimals, byte-unit, decimal-separator and thousands-separator - so check_drivesize can report 141.06GB/1006.85GB (or 141,06GB/1.006,85GB) instead of 140.293GB/0.983TB. The defaults are unchanged, so an installation that does not set them renders exactly what it rendered before. The options only touch the message: performance data keeps its full precision and its . radix, and so do the numbers you write in a filter or a threshold. Real-time filters take the same settings as decimals, byte unit, decimal separator and thousands separator keys, inheritable from the default template. decimals is capped at 15 (a double carries no more than that): the query option and the format_bytes()/format_number() argument reject a larger value, and the settings key clamps it, so a typo like decimals=1000000 can no longer make a check try to render a multi-megabyte number. Note that setting any of the four options also moves plain float keywords in the message onto the number format: with decimals unset they then render with up to three decimals (trailing zeros stripped) instead of the legacy 6-significant-digit form — 2.71094 becomes 2.711, and large values stop rendering scientific (1.23457e+07). A pipeline that matches float text in the message may need its pattern relaxed when you first set one of these options; leave all four unset and the message is byte-for-byte unchanged.
  • 🔢 Check your setup An unknown unit in format_bytes() is now reported instead of rendering nonsense. format_bytes(used, 'gb') used to render 1.27055e-10 because the unit comparison was case sensitive, and any misspelled unit rendered value/1024^7. Lowercase units now work, and a unit that names nothing (say 'ZB') makes the check report Filter processing failed: format_bytes failed: Unknown byte unit: ZB. A syntax string with such a typo returns UNKNOWN rather than a quietly wrong number - fix the unit, or the check will stay UNKNOWN.
  • 📊 Check your setup A unit: in perf-config that names no unit no longer divides the metric by 1024⁷. An unrecognised unit now leaves the value alone. If a graph of yours has been flat at a near-zero value, check the unit: spelling in its perf-config: the metric will jump to its real magnitude on upgrade.
  • 📊 Check your setup perf-config’s unit: now converts plain byte series instead of relabelling them. On series that are byte counts but do not auto-scale (most byte keywords outside check_drivesize), unit:KB used to change the label only, shipping =1536KB for a value of 1536 bytes - a metric off by the unit ratio to any consumer that trusts the label. The value and the warn/crit bounds now convert into the requested unit, matching what the auto-scaling series always did. A dashboard that compensated for the mislabelling will see the metric drop by that ratio on upgrade. Series not measured in bytes (ms, %, s, …) and explicit minimum:/maximum: overrides are unaffected, and a unit: that names no byte unit still only changes the label.
  • 🧩 Check your setup Errors raised while a template renders are now reported. A function that failed inside detail-syntax or top-syntax used to leave the placeholder empty and say nothing; the check now returns UNKNOWN with Filter processing failed: …. This surfaces template mistakes that have been silently producing incomplete messages.
  • 🪟 Check your setup check_pending_reboot’s default message now names the pending-since time. When the reboot was queued by Component Based Servicing or Windows Update, the message gains a suffix: Reboot required: Windows Update became Reboot required: Windows Update (pending since 2026-08-16 09:41:12). Notification pipelines that match the exact message text (an anchored regex, a string equality) need their pattern relaxed; thresholds, states and existing keywords are unchanged.
  • 🔢 Check your setup Filter comparisons between a text keyword and a bare number are now numeric. A string-typed keyword compared against an unquoted number used to order lexically — filter=value > 90 on filter_perf matched value=100 as false (“100” sorts before “90”) — or, with the operands reversed (90 > value), failed to evaluate at all. Both now compare as numbers, whichever side the keyword is on: the row’s text is parsed per record, and a value that is not a number simply never matches (the check logs one warning naming the value; the result stays a certain non-match, not UNKNOWN). This applies to keywords such as value/warn/crit/min/max (filter_perf, render_perf), speed (check_network), string_value (check_registry_value) and the column() function (check_logfile). Quoted literals keep the lexical comparison — version < '8' still orders as text — as do like, regexp and in, keyword-specific converters (state = 'running', age > 30m), and the = 'unknown' / = 'never' sentinels for optional values. Review any filter that deliberately relied on text ordering against a bare number: quote the number to keep the old behaviour.
  • 🔢 Check your setup Fractional numbers in thresholds are no longer truncated or rounded. count > 2.5 used to evaluate as count > 3 (the literal was rounded into the counter’s integer domain); unit literals lost their fraction entirely, so working_set > 1.5g meant 1g and uptime < 2.5h meant 2h. Fractions now mean what they say. Whole-number thresholds are unchanged; only expressions that already used a decimal point can behave differently.
  • 📊 Check your setup filter_perf/render_perf/xform_perf: the max and min filter keywords were swapped. max read the perf-data minimum bound and min the maximum. They now read the bounds they name — a filter that compensated for the swap needs the two names exchanged back.
  • 📨 Check your setup Syslog submission works again, so a configured syslog server will start receiving traffic. SyslogClient read its connection settings from the wrong place, so the target’s address, port, facility, severity and templates were all ignored: the agent logged Undefined facility: and sent nothing. Broken since 0.4.3 (2015). If you have a syslog target configured, check it still points where you want before upgrading - it has not been delivering, and it will now. CheckMKClient had the same defect on its query path.
  • ✉️ Check your setup SMTP notifications now announce this host in EHLO instead of localhost. The sender’s host name was read from the wrong place, so it was always empty and the EHLO fell back to localhost. If your mail server applies HELO/EHLO policy (SPF checks, or a rule that rejects localhost), the agent will now identify itself properly - set ehlo-hostname on the target if you need a specific name.
  • 🔧 Check your setup nscp settings --show now says so when --key is missing. --show --path /some/path without a --key used to print nothing and exit 0; it now reports Invalid command line please use --path and --key with show and exits non-zero. A bare --show still describes the active settings store, and --show --path … --key … is unchanged. Scripts that relied on the silent success need the missing --key added.
  • 💬 Client commands shorter than eight characters work again. A command such as cpu or run answered Exception processing command line: basic_string::substr … instead of running, in every module built on the shared client machinery (NRPE, NSCA, NRDP, Graphite, …). Remove any workaround that renamed such commands to a longer alias; no configuration change is needed.
  • 🔧 The settings diff no longer reports changes that were already saved. get_changes() — behind the REST settings diff endpoint and any operator-facing “what am I about to save?” view — kept listing an edit for the lifetime of the process after it had been written, reporting it as a modified entry whose old value equalled its new one. Tooling that treated a non-empty diff as “unsaved work pending” no longer needs to special-case that; no configuration change is needed.

0.16.4

  • 🔒 The bundled Mongoose web server is upgraded to 7.23, fixing two critical (CVSS 9.1) HTTP request-smuggling vulnerabilities in its HTTP parser (CVE-2026-73256, CVE-2026-73257). This affects the Windows builds of the WEBServer module (REST API / web UI) and is exploitable when NSClient++ sits behind a reverse proxy or WAF — upgrade promptly in that topology. The Linux packages use the Boost.Beast backend and are unaffected. No configuration change is needed. See Security notices.

0.16.3

  • 🔌 check_nt (NSClientServer) answers the real nagios-plugins client again. Requests without a trailing newline used to hang until the client timed out (No data was received from host!) — broken since 0.12.2. Remove any client-side timeout/retry workarounds; no configuration change is needed. If you expose this legacy endpoint, see the new guidance on securing it (password, allowed hosts and the allow command list).

0.16.2

  • 🔒 Check your setup Sensitive settings values are redacted on read. The REST settings read endpoints (GET /api/v2/settings/..., /descriptions) and nscp settings --list / --show now return *** for keys registered sensitive, matching the diff endpoint. No action required; tooling that read such a value back now receives ***. See Security notices.
  • 🔒 The built-in legacy WEB role is no longer seeded on fresh installs, and any role granting the legacy permission now triggers a SECURITY warning at startup (and from nscp web add-role / add-user). Existing installs are unaffected — the role stays in their config. The legacy grant unlocks the deprecated /query.pb and /query/{name} query-dispatch endpoints, so a token with it can run any registered check/command; only grant it to trusted legacy systems. See Security notices.

0.16.1

  • 🐧 RHEL/SUSE: workaround ca= arguments can be dropped — ${ca-path} now resolves on its own (the explicit form still works). Packagers cross-building for another distribution should set -DCONFIG_CA_PATH=.
  • 📄 check_logfile is unchanged unless you opt in to bookmark / max-lines. Adopting bookmark is a trade-off: a line is consumed when the check runs (not when its result is submitted) and positions are saved on clean shutdown, so a crash re-reports the backlog. Prefer an explicit bookmark name for a check whose filter changes often.
  • 🔧 Check your setup Settings URLs with a query string now send it. A server that relied on receiving the bare path will now see the parameters. The offline-boot cache file is migrated to the query-aware name once on first start.
  • 🏷️ Check your setup ${hostname} in an existing config changes meaning — it is now expanded everywhere expand_hostname is used (including submit clients’ hostname), where it used to be left as literal text.
  • ⏱️ run on startup is off by default so the default install is unaffected; if you enable it for the default schedule use startup window to avoid a thundering herd.
  • 📚 Check your setup Building the HTML docs on non-Windows now needs -DNSCP_BUILD_DOCS_HTML=ON.

0.14.1

  • ⚖️ Licence change: now distributed as Apache-2.0 OR GPL-2.0-only — a clarification/relicensing with no code or runtime behaviour change. Review it if your organisation tracks bundled-software licences.
  • 📊 Check your setup CheckNet perfdata is on by default. If you added perfdata manually, make sure you are not now emitting it twice.
  • ☑️ Boolean check arguments (option=true / option=false) now work from the CLI as well as REST; bare-flag usage is unchanged.
  • 🔒 Action required CheckSecurity is not loaded by default. Enable it before using its checks (nscp settings --active-module CheckSecurity). Windows-only checks return UNKNOWN elsewhere.

0.12.6

  • 🔒 New permission policy layer, disabled by default. Existing installs behave exactly as before until an operator sets /settings/permissions/enabled = true. If you opt in: per-command rules apply to queries only (exec is gated by the separate allow exec boolean, which defaults true); roll out with log allows = true first to inventory real traffic. See Permissions.
  • 🔒 NRPEServer client identity source defaults to none (previous behaviour). Set to cn only after configuring verify_mode = peer-cert and a ca path pinned to your private monitoring CA — the system trust store would accept any public cert’s CN.
  • 📁 Check your setup [/paths] overrides from an older install moved to [paths] in boot.ini (same section name, different file). No automatic migration — copy each entry across and delete the old section.
  • 🔒 WEB disable admin user = true is a new opt-in for status-only WEB exposure; existing installs keep their admin unchanged.
  • 🔌 Check your setup NRPEServer now survives a failed listener (logs an ERROR, leaves the module loaded) instead of failing the whole module. Add “NRPE listener failed” as a signal if you alerted on module-load failure.
  • 🔊 Check your setup insecure = true on NRPEServer now logs at ERROR (louder, behaviour unchanged) — whitelist the message on agents intentionally run insecure.

0.12.5

  • 📁 Check your setup [/paths] users: copy entries into [paths] in boot.ini; the settings-side section is no longer consulted. Default installs are unaffected.
  • 🧩 Check your setup Custom-plugin authors: implement the new optional prepare_shutdown callback if your module manages sockets or background threads — unload is now a last-resort teardown.
  • 🔒 Monitoring-only WEB deployments: disable admin user = true under [/settings/WEB/server] suppresses the built-in admin even on first boot; define your own read-only users (or a tightly scoped anonymous role).

0.12.4

  • 🔒 Icinga check_nscp_api works again after upgrade with no config change. For a non-stock probe, set [/settings/WEB/server] legacy query auth user agents to a substring of its User-Agent. For the strict 0.12.3 behaviour (no query-string credentials at all), set that key to empty.

0.12.3

  • 🔒 Action required Audit allowed hosts on every node — empty values now reject everything.
  • 🔒 Action required check_nt (NSClientServer) now defaults to ssl = true; set ssl = false explicitly if your clients don’t speak TLS.
  • 🔒 Check your setup Replace clients that call /auth/token or /auth/logout with the /api/v2/login flow, and any that pass ?TOKEN= / ?__TOKEN= in the query string with a header-based token.
  • ⏱️ Action required Scheduler cron expressions on non-UTC hosts shift to local time — update them or set [/settings/scheduler] timezone = utc.
  • 🔧 Check your setup Review check_service / check_process / check_files filters that relied on the old (now corrected) behaviours.
  • 📋 Action required Restart and review the log for new “refused alias” / “rejected connection” warnings — configurations that were previously silently accepted.

0.11.33

  • ✅ Check your setup No configuration migration required (new proxy keys are opt-in). The check_files fixes change a few corner cases: max-depth=0 now scans the top directory (#730); missing paths return UNKNOWN (#613); junction loops are not double-counted (#605); empty results return OK instead of UNKNOWN (#717). Review alerting that relied on the old corner-case behaviour.