Re: [opennms-discuss] Only some services detected

[Les M. <les...@gm...>]

On Thu, Jul 5, 2012 at 3:47 AM, Klaus Vink Slott <gq...@hu...> wrote:
>>>
>>> Reading the mail list I wonder if my predecessor have changed to
>>> provisiond and disabled capsd. Where is this selected?
> Any opinion on this. Is my understanding correct that provisiond will
> replace capsd? Is this shift done in > 1.8 versions. Is there a way to
> verify which process is currently enabled/doing the work.

The big win for provisiond is where you have some other inventory or
configuration management program tracking the devices/services and you
want to let it control the opennms settings to match.   Also, capsd
tries to do too many things and provisiond splits the operations up a
little more sensibly.    For a quick check to see what is running,
look at capsd.log and provisiond.log.  And if you bump the log level
from INFO to DEBUG for them, you can probably see why they are failing
on services you think they should detect.

>> But, my real recommendation would be to start from
>> scratch with a 1.10.x install and back in the local changes you can
>> identify.
>
> I have been quite tempted to go for this solution, but I was confused by
> the text on page http://www.opennms.org/wiki/Tutorial_Choosing_a_Release
> "The current stable series is 1.8" So I was sort of hoping to keep the
> old version running until 10 series got stable.
>
> Searching a bit more today I found that
> http://www.opennms.org/get-opennms/ claims 1.10.3 as stable, so I guess
> that the wiki is lacking behind.

I just use the rpm packages via yum from the stable repository on a
centos box and it is delivering 1.10.3.  I would expect the .deb
equivalent to do likewise.  The 1.10.x configs have several files that
used to be monolithic split into a directory of smaller files, making
it easier to maintain your local changes across upgrades (once you
make the change yourself), and the packaged installs add a separate
pristine copy of the config files so it is easy to "diff -r " against
them later.    If you are going to start over from scratch, note that
jrobin/.jrb is still the default data storage format but the current
jrrd/rrdtool implementation is probably more efficient  (particularly
with storeByGroup) and you can't switch formats later without losing
data or at least a complex conversion process.

-- 
   Les Mikesell
     les...@gm...