Re: OpenNMS update version 21.0.5 to version 22.0.2

Jonathan Heard <[email protected]> Mon, 30 Jul 2018 17:03:16 +0100
Newsgroups gmane.network.opennms.general
Message-ID <[email protected]>
Hi Fulvio,

     First-off: Are you still having the same problem with the blank web 
page? It's all very well me talking about config from scratch but I 
appreciate that you probably need help to fix the running config for now.

I don't see your logs in any of the mailing list emails although Graeme 
Fowler has cited a Maven resolution issue. This certainly could still 
point to a Maven cache issue - it could be worth checking that you've 
flushed the correct cache directories, and that you can reach the 
repository in question using something like cUrl from your OpenNMS 
hosts; just in case it is some kind of network/dns issue.

I'm happy to also take a look at your logs if you're able to share them. 
I think for now output.log, web.log, jetty-server.log and karaf.log 
would be a good start.

In response about my approach to config:

Automating the configuration is certainly not a simple task. I think we 
ultimately decided that the time invested in automating our 
configuration would quickly be paid off versus the hours spent trying to 
fix problems every time we upgraded. It probably didn't help that we 
were using git to manage the raw configuration files which led to 
hideous merge conflicts. XML can be semantically the same but 
syntactically different e.g. <x y=1 z=2> vs <x z=2 y=1>) and this caught 
us out a few times, where a core OpenNMS moved the order of attributes 
and made the whole file appear to have changed.

In case it helps you at all here's a couple of notes which might help:

Surveillance Categories:
All of ours are set automatically during automatic provisioning. We use 
NodeCategorySettingPolicy to automatically assign surveillance 
categories based upon hostname and/or whether a particular SNMP OID exists.
I've also set up code which builds the front page Availability dashboard 
to display a breakdown by category.

Special Notification:
I presume you're talking about customisations to notifications.xml and 
things like destinationPaths.xml? If so, then I've scripted this to 
build these files from a template using Hieradata from a Yaml source 
file. In this particular case I've captured all default notifications in 
the Yaml as well as my customised ones.

SNMP Mib Compiler:
We only use a handful of custom mibs, however in this instance I compile 
the MIBs and add them to my Puppet repository so that they're copied 
into place on the OpenNMS server. When creating the datacollection 
config files, I add the builtin-MIBs followed by the custom ones.

Topology:
Our network is essentially flat so I've never used this but I'm sure it 
could be automated.

Hope this is of interest and good luck with your future upgrades
Jonathan

On 30/07/18 16:29, [email protected] wrote:
>
> Hi Jonathan,
>
> I also thought about your solution, but it becomes really difficult to 
> do a new installation.
> I use heavily, for example: Surveillance Categories, SNMP Mib 
> Compiler, Special Notification, Topology ...
>
> Regards,
>
> Fulvio
>
>> Il 30 luglio 2018 alle 13.27 Jonathan Heard 
>> <[email protected]> ha scritto:
>>
>> I'm inclined to agree, Chris.. My experience with OpenNMS is that 
>> there is a tangled mess of defaults, customisations and code in the 
>> vast number of XML config files which makes upgrading a very 
>> haphazard task. There's a long-standing support ticket to restructure 
>> the config and make upgrading easier but progress is slow and will 
>> likely require a massive overhaul of the configuration files to 
>> achieve it.
>>
>> In our environment I've used Puppet to create all my OpenNMS config 
>> (although I've since seen a tutorial using Rake which looks like a 
>> really nice approach). We never 'upgrade' but instead we trash the 
>> running version, rebuild, auto-reconfigure and rediscover everything. 
>> This isn't a particularly scalable approach so it would depend on the 
>> size of your estate, plus we don't need to retain historic data so we 
>> have the luxury of wiping it and starting afresh. However, it could 
>> be tailored to retain provisioned nodes and data, making it far more 
>> scalable.
>>
>> If you're able to trust the 'A' records to be an authoritative 
>> starting point as to all the hosts that need to be monitored, then 
>> the DNS Provisioner from OpenNMS is great. From scratch, OpenNMS 
>> takes a zone copy, provisions all nodes and performs service 
>> detection. It takes about an hour from start to finish to have our 
>> network of ~300 nodes fully discovered.
>>
>> It's on my todo list to see if I can share my Puppet code, although 
>> it may not be generic enough for other environments.
>>
>> HTH
>>
>> Jonathan
>>
>>
>> On 20/07/18 17:03, Chris Burt wrote:
>>>
>>> I do not and this mailing list was no help at all.  I wiped out the 
>>> install and started over.  Which seems par for the course with 
>>> OpenNMS.   The need a real community.
>>>
>>>
>>> On 7/20/2018 8:52 AM, fmposta--- via opennms-discuss wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I have several installations of OpenNMS on CentOS6/7 and I have 
>>>> updated to the latest release.
>>>>
>>>> The update was successful without problems and both the db and 
>>>> OpenNMS services were started regularly, but when I try the 
>>>> webpage nothing appears; obviously I tried another update with the 
>>>> same result.
>>>>
>>>> Did you have similar problems? You can help me?
>>>>
>>>> Thank you
>>>>
>>>> Fulvio
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>>>
>>>>
>>>> _______________________________________________
>>>> Please read the OpenNMS Mailing List FAQ:
>>>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>>>
>>>> opennms-discuss mailing list
>>>>
>>>> To *unsubscribe* or change your subscription options, see the bottom of this page:
>>>> https://lists.sourceforge.net/lists/listinfo/opennms-discuss
>>>
>>> -- 
>>> Chris Burt
>>> Generic Network Systems
>>> 503-342-4044 x728
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org!http://sdm.link/slashdot
>>>
>>>
>>> _______________________________________________
>>> Please read the OpenNMS Mailing List FAQ:
>>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>>
>>> opennms-discuss mailing list
>>>
>>> To *unsubscribe* or change your subscription options, see the bottom of this page:
>>> https://lists.sourceforge.net/lists/listinfo/opennms-discuss
>>
>
>> ------------------------------------------------------------------------------ 
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! 
>> http://sdm.link/slashdot_______________________________________________
>> Please read the OpenNMS Mailing List FAQ:
>> http://www.opennms.org/index.php/Mailing_List_FAQ
>>
>> opennms-discuss mailing list
>>
>> To *unsubscribe* or change your subscription options, see the bottom 
>> of this page:
>> https://lists.sourceforge.net/lists/listinfo/opennms-discuss
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Please read the OpenNMS Mailing List FAQ:
http://www.opennms.org/index.php/Mailing_List_FAQ

opennms-discuss mailing list

To *unsubscribe* or change your subscription options, see the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/opennms-discuss