Project

General

Profile

Actions

tickets #7942

closed

Find a way to provide a "whitelist" for the check_zypper monitoring check

Added by gschlotter almost 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Configuration management (CM)
Target version:
-
Start date:
2015-06-17
Due date:
% Done:

100%

Estimated time:

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': }

Actions #1

Updated by gschlotter over 8 years ago

  • Project changed from 28 to openSUSE admin
  • Category set to 150
Actions #2

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

Actions #3

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.

Actions #4

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 ;-)

Actions #5

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.

Actions

Also available in: Atom PDF