An existing installation of checks can be replaced by a newer version quite easily as long as it is the same product, e.g.: check_netapp 2.1.0 by check_netapp 2.2.5. Equally, the same holds true for the pro version (e.g. check_netapp_pro 3.0.17 by check_netapp_pro 3.1.0). In these cases the update is nothing else than an installation in which existing files in the Nagios directory libexec/ are replaced by newer files. The configuration files (cfg or credential file) should be stored separately anyway, e.g. in /usr/local/nagios/etc/. With this method, it can happen that orphaned files still remain that are no longer needed. This rarely happens and causes no issues. E.g.: currently this is the case with DiskFailed that is being replaced by Disk
. If you want to avoid this, you have to delete all existing checks and corresponding files first. This could be done with the following command: $ cd .../libexec/ $ rm -rf check_netapp_pro* get_netapp_* check_netapp_*.pl list_apis.pl **Attention: **Depending on the monitoring system, it is not 100% safe to assume that the above command does not delete any other files. We recommend to double check using ls -l <globbing>. Any store files that are deleted during the process won’t cause any problems.
Delete Stores?
Since in the default configuration stores are deleted after 15 minutes (some even at the next pass of the getter), it is generally not necessary to delete stores. In rare occasions, it can happen that an updated check requires a new store format and that an error occurs when a store file from a previous version already exists. But in this case, the problem solves itself in a short period of time (see above).
Practical Tip
As always, when changes are made to a monitoring system, we recommend that for the period of transition, automatic messages should be limited to the group of people that is tasked with the migration. And don’t forget to activate the messages for everyone after the migration is completed!
Comments