tickets #7942
closedFind a way to provide a "whitelist" for the check_zypper monitoring check
100%
Description
Background¶
We will install the monitoring-plugins-zypper package now on nearly all our hosts this plugin is able to detect if a package comes from a not officially supported repository (like our NPI repo) and will issue a warning in Nagios in that case.
Reason for this:
- detect unwanted changes on a host (someone installed additional packages)
- notify the user that there is a package that might never ever see an update as it is not officially supported
If the user/admin is aware of this, he can (per host) define a "whitelist" of packages, that are ignored by the plugin in that case this whitelist can be given as additional option to the call of the plugin in that case, the plugin will NOT warn about the unsupported package any more
and now to the question¶
As we manage the list of packages via puppet can we define a variable for a package that is clearly not from a supported repo that can then be used by puppet to create the whitelist file ?
Something like packagename { unsupported:true; } ? and puppet will create the file /etc/monitoring-plugins/check_zypper-ignores.txt for us ?
The file itself is a plain text file (permissions: root.root 644) - just have a look on lists.opensuse.org - with entries like:
whitelist:$packagename
/usr/lib/nagios/plugins/check_zypper -h
would give you more information about possible entries in that file - but for us the example with the whitelist should be enough.
Two different ways on how to do this¶
One is using a metaparameter that puppet has, called tag we collect packages with tag => whitelist and generate the list out of them
The second solution that requires puppetdb is to use the exported resources feature in short, puppetdb has this cool feature, where it collects data from clients when a client finishes a puppet agent run, it sends a full report to the master then the master collects stuff like the ipaddress so we can use it in nagios.
The package whitelist will still be defined by the human, we will define an exported custom resource @@whitelist_package { 'packagename': }
Updated by gschlotter over 8 years ago
- Project changed from 28 to openSUSE admin
- Category set to 150
Updated by tampakrap about 7 years ago
- Category changed from 150 to Configuration management (CM)
so since we migrated to salt, we are not going to do it as described above. I don't have technical specifications yet, I'll think about it and report back
Updated by Anonymous over 6 years ago
- Status changed from New to Rejected
- % Done changed from 0 to 100
tampakrap wrote:
so since we migrated to salt, we are not going to do it as described above. I don't have technical specifications yet, I'll think about it and report back
No results/progress since 9 months. Assuming this is no doable. Please re-open, if I'm wrong.
Updated by cboltz over 6 years ago
- Status changed from Rejected to In Progress
- Assignee changed from tampakrap to cboltz
Lars, I never thought you are that pessimistic - or was this only an evil trick to find someone who finally does the work? ;-)
This is of course doable - the technical / salt part is already in https://gitlab.infra.opensuse.org/infra/salt/merge_requests/96
I have some questions about the content of the whitelists (checking a few examples with Theo showed that they are probably outdated and contain too much) and in which way (per role? per distribution? per host?) they should be applied. Please ping me whenever you see me on IRC so that we can sort this out ;-)
Updated by cboltz over 6 years ago
- Status changed from In Progress to Closed
I just merged this into production, and already applied it on riesling and water.
The whitelists got a big update and cleanup, as discussed in the merge request.