thold cites wrong host in notifications (thold table corrupt

[jmb]

We've encountered this symptom a good few times over the years - some thold notifications include the wrong host name in the email subject line - but only recently characterized it properly.

It seems that thold keeps a copy of the host ID in the thold_data table (!?) and after we change (in the UI) the host a datasource is associated with, thold maintains the old host association and uses that for (at least) notification email generation. We can see via a DB query that thold_data.host_id doesn't match host.id following the rra id through data_local:

Code: Select all

SELECT thold_data.id,
    thold_data.name,
    stale_host.description AS stale_host,
    thold_data.host_id AS stale_host_id,
    data_local.host_id AS active_host_id,
    active_host.description AS active_host,
    thold_data.thold_enabled 
FROM thold_data 
    LEFT JOIN data_local ON thold_data.rra_id = data_local.id 
    LEFT JOIN host AS stale_host ON thold_data.host_id = stale_host.id
    LEFT JOIN host AS active_host ON data_local.host_id = active_host.id
WHERE thold_data.host_id != data_local.host_id

This shows a large number of host ID mismatches on our systems. We're using a rather old version in production but I've verified it with the 0.8.8c codebase.

Digging into the code it looks like the main Cacti data_sources.php doesn't call any hook on a DS-host reassignment (unless it's buried further down the call chain than I've seen) so thold doesn't ever get a chance to fix up its copy of the host ID. That's kind of beside the point though - thold should not need to keep its own copy, it can easily JOIN to host to get it - golden rule, store the data once.

It's probably safe for us to just update the old entries to match the new ones, can anyone confirm that? Of course, new ones will creep in after that - another thing to add to our "gotchas" list.

There are probably other situations where this mismatch manifests, that we've not encountered (or noticed). It might be relevant, for example, to this unanswered report: Thold - User perms working? I see other peoples hosts!!!

[jmb]

Actually - just verified the "I see other people's hosts" aspect - created a user with view access to only one host, and it's showing tholds for DS which have long since been reassigned to other hosts.

[jmb]

Another possible artifact: thold_api_device_save will be broken by mismatches in the database - the intent is to enable/disable thresholds on hosts when the hosts are enabled/disabled, but it compares the host id given with thold_data.host_id, so when a host is disabled and saved, a threshold will be changed if it is defined on a DS originally associated with that host but since changed.