upgrade nagios 1.4.1 to nagios 3.2.3

[Allan Clark]

On Mon, Nov 22, 2010 at 01:12, Andreas Ericsson <ae at op5.se> wrote:
> On 11/22/2010 09:58 AM, Sunny Jaisinghani wrote:
>> Well, it's worth to check with Nagios experts if they have a documented
>> procedure, before i go and experiment on my production box.
>> Also, it is obvious for anyone to search online for documents before
>> asking for help on forums.
>> Since, i did not find "much" information, i had to seek help from the
>> blessed ones. May be, i need to tweak my search queries.
>>
>
> Could be. There are two scripts floating around that can be quite helpful
> to modify your configuration from 1.x to 2.x. The changes between 2.x and
> 3.x are much less significant and touch primarily nagios.cfg, except for
> some host object parameters which you can almost certainly get away with
> setting in your templates.
>
> I can't recall the names of the scripts now (which is weird, since I wrote
> them), but trying +nagios +1to2 +retention +contact should at least get you
> started.
>
>> Anyways, it seems i am on my own. I liked your last suggestion btw; i'll
>> clone my production box and experiment on it.
>>
>
> Always a good idea. Don't forget to disable checks and/or notifications
> while you're experimenting.

In development self-tests (using autotest) I get a lot of mileage from
"nagios -v /etc/nagios/nagios.cfg" to check that the parsing succeeds.

I also get mileage form the following which catches when the upstream
moves my binaries around -- it might also help you if plugins drop
executables or install in a different location:

define command{
        command_name                    check_runnable
        command_line                    /usr/bin/check_runnable $USER1$/$ARG1$
        }

define command{
        command_name                    check_runnable_fullpath
        command_line                    /usr/bin/check_runnable $ARG1$
        }

...
...
# dependency configures the on-demand running when dependent fails: if
check_users fails, this dependency
# causes "is it even there and runnable?" to be confirmed
define servicedependency{
        dependent_host_name             localhost
        dependent_service_description   Total Processes
        host_name                       localhost
        service_description             Runnable check_users
        execution_failure_criteria      w,c,u
        notification_failure_criteria   w,c,u
        }

#  run twice daily -- shouldn't have execs changing too often, and
really this runs when a dependent fails
define service{
        use                             bidaily-service         ; Name
of service template to use
        host_name                       localhost
        service_description             Runnable check_users
        check_command                   check_runnable!check_users
        notifications_enabled           0
        }

Checking that your binaries are there may seem a bit silly, but I
spent a bit long trying to see why something was failing only to see
that the RPM no longer provided some executables.  Defining them as
dependencies means they'll only be run if the actual test fails, so
they incur no load in the event of no exception, but ask as a quick
check-for-existence when a failure occurs.  Since you're moving
versions, you may get some mileage of checking that your executables
are there before and after.

Allan
-- 
allanc at chickenandporn.com  "金鱼" http://linkedin.com/in/goldfish

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today
http://p.sf.net/sfu/msIE9-sfdev2dev
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null