Major update form Nagios 3.5.1 to Nagios 4.2.2

[danjoh]

Moderator Edit: This thread has been split from another - https://support.nagios.com/forum/viewto ... =7&t=41059
In the future, please create a new thread and link to the old one instead of adding on.

Hi,

We are planning about the same thing, although from a "bit" older version (3.0.6 !!!), so I am also interested in feedback regarding this.
We have one extra "quirk", we are running a distributed environment, so I have an additional question: Do we update the "master" first and then the "slaves" or the other way around?
My plan is like this:
1. Setup a new host ("master" or "slave") with the new Nagios (4.2.2)
2. Copy the configuration-files from the old host and run nagios -v .... to "check" the config
3. shutdown the old host
4. "rename" the new host to the original name and change it's IP too the original IP (this is so I do not have to change FW rules).
5. Restart the "new" host as the original

Regards,
Dan

[rkennedy]

Do we update the "master" first and then the "slaves" or the other way around?

What are you using for a distributed setup? The reason I ask is because built in to Nagios, we do not have any distributed options, and this may be a better question for whomever wrote what you're utilizing.

All of your steps sound fine, but you may want to do a bit of testing because there have been some depredations between 3.0.6 -> 4.2.2. I would also test to make sure you have all the applicable dependencies for whatever plugins you're using. With this, you'll most likely want to copy the /libexec/ folder to your new machine as well to catch any additional plugins.

[danjoh]

For the distributed setup we are using NSCA like this:

Code: Select all

            Firewall
               //
+--------+     //     +--------+       +-----------------+
| Nagios |     //     | Nagios |       |     Client-1    |
| Master | <--NSCA--- | Slave  |------>| "active" checks |
| (NSCA) |     //     |        |       |                 |
+--------+     //     +--------+       +-----------------+
               //

Yes, of cause we are planning to do some test and we only want to "move" the plugins that are actually used (trying to clean up an old install with a lot of old unused plugins).

[avandemore]

We don't really have a formal procedure for this as there are just so many different variables.

If it was me doing this, I would ensure I had complete backups prior to anything. Then I would migrate to a new Nagios slave keeping the old and new active at the same time until functionality can be confirmed. After that transition is successful, I would move to the Nagios master.

Remember NSCA has different versions and the versions needs to be consistent as well.

[danjoh]

That was my thought as well, first do the slaves (one by one) and then the master.
And as I setup new Hosts and do an "IP-change" to "activate" the new and deactivate the old, the problem with backup is so to say solved.
Only on the Master have I planned to copy more than just the configuration files (pnp-performance-data).

Regarding NSCA:
Today we have 2.7.2 installed and that is also the version that is labelled "Stable version" (whereas 2.9.1 is labelled "Current version") on Nagios Exchange, so if I install 2.7.2 on the new HW I should be OK?
One question mark is that on Nagios Exchange both versions are listed as only compatible to Nagios 1.x, 2.x and 3.x, and NOT 4.x. Is this info correct and 4.x is not supported?
If that is the case what are the alternatives to NSCA in 4.x?

[avandemore]

Today we have 2.7.2 installed and that is also the version that is labelled "Stable version" (whereas 2.9.1 is labelled "Current version") on Nagios Exchange, so if I install 2.7.2 on the new HW I should be OK?

Yes, should be fine aside from the issues with 2.7.2 you'd get on anything. This is the current one with most relevant changes:

https://github.com/NagiosEnterprises/ns ... a-2-9-2RC1

You are also free to interact there with developers, they may be able to answer questions that we do not have easy answers to.

The information concerning Nagios Core 4.x and NSCA was incorrect, it has been updated.

[dwhitfield]

So, NSCA certainly works, but it is not really under active development. I would suggest you take a look at NRDP: https://assets.nagios.com/downloads/nrd ... erview.pdf

The following is in the PDF document, but worth pasting here so you don't think I am sending you on a pointless mission:

NRDP has several benefits over NSCA, including:
• NRDP uses standard ports and web protocols, which means that firewall configuration and client development is simplified
• NRDP uses the Apache web server to provide optional SSL encryption and authentication
• NRDP supports multi-line host and service check output
• NRDP write check output directly to the Nagios Core spool directory – bypassing the external command file for increased performance

I know this adds complexity to your upgrade, but better now than later in my view.

[danjoh]

Tanks for you feedback regarding NSCA.
I will certainly have to take a look into replacing NSCA with NRDP (we are already using NRDP to "feed" some of the slaves).
One advantage with moving to NRDP would be that I could configure the existing master to accept NRDP and then setup the new slaves to use NRDP instead of NSCA (I just hope that NSCA and NRDP can co-exist on the master).
One thing that I do not seem to find in the documentation is how to setup NRDP on the slaves to "forward" data to the master (pushing data from a host to the slave works OK, but how to make the slave forward it to the master?).

[dwhitfield]

We probably need a little more information before recommending Linbit. For one thing, it's built for XI, but it might be worth taking a look at so you can get an idea of what options are out there: http://www.linbit.com/en/technical-publications/ (the appropriate link is on the left).

Also, https://www.youtube.com/watch?v=KW5Qkl8brcA might be useful, even though, again, it is nominally for XI.

[danjoh]

Just for completeness sake:
We ended up using just one Nagios instance with mod_gearman instead of seven Nagios instances with "forwarding".