Jump to content

DGARM Nagios Core - Thruk Issue Rectification Summary

From TetraWiki

Source video: DGARM-Infosys-Nagios-core-Deployment-Thruk-issue-rectification-2026-07-18_11-23-23.mkv (3h 39min)

Note on this summary: this recording's audio is heavily degraded/noisy for long
stretches (cross-talk, background audio, some non-work chatter picked up by the mic),
so long sections of the auto-transcript are unreliable. This summary leans on
on-screen terminal/browser evidence, which was clear and consistent throughout.
Security note: one frame in this video shows a Red Hat subscription-manager
username/password typed in plaintext in a terminal. That credential is not
reproduced here or on the wiki — recommend rotating it since it's now visible in a
recorded/analyzed file.

Summary[edit]

A long remote troubleshooting session (Zoom remote control, handed between engineers a few times) to get Thruk — the replacement web dashboard for Nagios Core's primitive default UI — fully working end-to-end, including its live data connection to Nagios.

Key technical findings:

  1. Package install path was blocked by network restrictions: dnf/subscription-manager commands against Red Hat's CDN failed repeatedly (cdn.redhat.com, subscription.rhsm.redhat.com — "Name or service not known"; ping 8.8.8.8 came back "Destination Net Unreachable" from an internal 10.100.101.x hop). This points to an outbound-internet restriction in the DGARM network (likely deliberate firewalling, not a misconfiguration on the Nagios host).
    • Workaround used: manually downloaded the Thruk RPMs directly from download.thruk.org and installed with rpm -ivh <package>.rpm, bypassing dnf entirely. Confirmed installed via rpm -qa | grep thruk: thruk-3.28-14373.1, thruk-base-3.28-14373.1, thruk-plugin-reporting-3.28-14373.1, libthruk-3.26-0.
  1. Root cause of "no data in Thruk" was a missing Livestatus broker module (referred to in speech as "life status", i.e. MK-Livestatus). Thruk is a pure front-end — it has no data of its own and needs a live socket connection into the running Nagios Core process. Until that module loads, Thruk's backend has literally nothing to query.
    • Fix: build/install mk-livestatus and load it as a Nagios event broker module. Confirmed working via the Nagios log:

<syntaxhighlight lang="text">

    Event broker module '/usr/local/lib/mk-livestatus.o' initialized successfully.
    livestatus: starting main thread and 10 client threads
    livestatus: default stack size is 8388608

</syntaxhighlight>

    This creates a Unix socket at /usr/local/nagios/var/rw/livestatus/live.
    • Verifying the socket directly (bypassing Thruk, straight against Nagios):

<syntaxhighlight lang="bash">

    printf 'GET hosts\nColumns: name state plugin_output\nLimit: 10\n\n' | \
      /usr/local/bin/unixcat /usr/local/nagios/var/rw/livestatus/live

</syntaxhighlight>

    If this returns host data, the Nagios-side backend is confirmed healthy and any remaining problem is on Thruk's/Apache's side.
    • Permission gotcha: the web server (apache) needs group access to the Livestatus socket. Checked with id apache, and tested access as that user:

<syntaxhighlight lang="bash">

    sudo -u apache /usr/local/bin/unixcat /usr/local/nagios/var/rw/livestatus/live

</syntaxhighlight>

    restarting httpd (systemctl restart httpd) after any group-membership change so it picks up the new group.
  1. NCPA plugin (Windows/Linux agent-based checks) confirmed present at /root/nagios-4.5.9/nagios-plugins/plugins-python/check_ncpa.in via locate ncpa — same plugin referenced in the PNP4Nagios session, needed before device onboarding.
  2. Outcome: by the end of the session, all four planned components were confirmed working together — Nagios Core, NagiosQL, PNP4Nagios, and Thruk — and the team did a side-by-side comparison of the old default Nagios Core UI vs. the new Thruk dashboard to confirm it was presentable for the client demo. Plan going forward: begin bulk device onboarding, plus deploy NCPA for Windows/Linux agent checks.
  3. Session had repeated remote-control/clipboard handoff friction over Zoom (control being passed between engineers, clipboard-sharing toggles needing to be re-enabled several times) — worth using a more stable remote-access method (the VPN discussed in the kick-off meeting) for future sessions like this.

Root cause & fix (for the runbook)[edit]

Symptom Root cause Fix
dnf/subscription-manager can't install Thruk packages Outbound internet/DNS blocked to Red Hat's CDN from this network Download RPMs manually from download.thruk.org (or an internal mirror) and install via rpm -ivh
Thruk shows no host/service data even though Nagios is running MK-Livestatus event broker module not built/loaded — Thruk has no backend to query Build/install mk-livestatus, load it as a Nagios broker module, confirm via Nagios log and a direct unixcat query against the livestatus socket
Thruk/Apache still can't read Livestatus data after the module loads apache user lacks group access to the livestatus Unix socket Add apache to the required group, systemctl restart httpd, re-test with sudo -u apache unixcat ...

Source recording[edit]