Werk #18937: Expanded System Command Wrappers for OpenSSL Compatibility

Component Linux distributions
Title Expanded System Command Wrappers for OpenSSL Compatibility
Date Dec 16, 2025
Level Trivial Change
Class Bug Fix
Compatibility Incompatible - Manual interaction might be required
Checkmk versions & editions
2.4.0p18
Not yet released
Checkmk Cloud (CCE), Checkmk MSP (CME)

This affects the following operating systems:

SLES 15 SP5, 15 SP6, 15 SP7 RHEL 9, 10 Debian 13

The Core Problem: Library Conflicts

Checkmk sites operate in a self-contained environment. To ensure stability, the site environment sets the LD_LIBRARY_PATH to prioritize Checkmk’s local libraries (found in the sites ~/lib directory).

However, a conflict arises on modern Linux distributions when the site user calls system executables that depend on a different version of OpenSSL than the one shipped with Checkmk. Because LD_LIBRARY_PATH is set, the system executable (e.g., /usr/bin/dig) incorrectly tries to use Checkmk's libcrypto.so.3 instead of the system's version. This results in a fatal error like the following:

/omd/sites/main/lib/libcrypto.so.3: version 'OPENSSL_3.4.0' not found (required by /lib64/libisc-9.16.23-RH.so)

The Workaround (until 2.5.0)

To temporarily fix this, Checkmk now provides "wrappers" in the site's bin/ directory for common system commands. These wrappers execute the system command while temporarily removing the LD_LIBRARY_PATH environment variable to ensure the system's own libraries are used.

This update (extending Werk #18935) includes wrappers for:

  • dig
  • host
  • nc
  • nmap
  • php
  • php-cgi
  • php5-cgi
  • php5
  • resolvectl

Critical Incompatibility: Absolute Paths and Custom Scripts

This change is marked as incompatible because the fix only works if the command is called by its short name (relying on the site's PATH). If a script or configuration uses an absolute path, it bypasses the wrapper and will fail.

Where this may fail:

When openssl-linked system binaries are called in:

  • Individual Program Call Rules: e.g., using /usr/bin/ssh $HOST instead of just ssh.
  • Custom Notification Scripts: Any script calling system binaries via absolute paths or without a wrapper.
  • MKPs/Extensions: Any third-party extensions calling system binaries via absolute paths or without a wrapper.
  • Event Console Actions: Custom scripts triggered by the EC calling system binaries via absolute paths or without a wrapper.
  • Alert Handlers: Custom scripts triggered by the EC calling system binaries via absolute paths or without a wrapper.

Workarounds and Manual Fixes

1. Avoid Absolute Paths

Wherever possible, update your scripts and rules to use the command name (e.g., dig) instead of the full path (e.g., /usr/bin/dig). This allows the site's wrapper to handle the library transition correctly.

2. Manually Unsetting the Environment

If you must use an absolute path, or if you are calling a binary for which no wrapper exists, you must manually clear the LD_LIBRARY_PATH environment variable in your script:

# Example in a custom shell script
LD_LIBRARY_PATH= /usr/bin/dig -v

3. Creating New Wrappers (Root Required)

If you identify a system command that is missing a wrapper, you can manually create one. Navigate to the site's bin directory as the root user and copy an existing wrapper:

cd /opt/omd/sites/SITE_NAME/bin
cp ./dig ./NEW_COMMAND_NAME

4. Perspective for 2.5.0

We're working on removing the need to to set LD_LIBRARY_PATH in 2.5.0, such that wrappers and workarounds are no longer needed.

To the list of all Werks