DGARM Nagios Core - Thruk Issue Rectification Summary
Appearance
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:
- Package install path was blocked by network restrictions:
dnf/subscription-managercommands against Red Hat's CDN failed repeatedly (cdn.redhat.com,subscription.rhsm.redhat.com— "Name or service not known";ping 8.8.8.8came back "Destination Net Unreachable" from an internal10.100.101.xhop). 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.organd installed withrpm -ivh <package>.rpm, bypassingdnfentirely. Confirmed installed viarpm -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.
- Workaround used: manually downloaded the Thruk RPMs directly from
- 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-livestatusand load it as a Nagios event broker module. Confirmed working via the Nagios log:
- Fix: build/install
<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 withid apache, and tested access as that user:
- Permission gotcha: the web server (
<syntaxhighlight lang="bash">
sudo -u apache /usr/local/bin/unixcat /usr/local/nagios/var/rw/livestatus/live
</syntaxhighlight>
restartinghttpd(systemctl restart httpd) after any group-membership change so it picks up the new group.
- NCPA plugin (Windows/Linux agent-based checks) confirmed present at
/root/nagios-4.5.9/nagios-plugins/plugins-python/check_ncpa.invialocate ncpa— same plugin referenced in the PNP4Nagios session, needed before device onboarding. - 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.
- 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]