nscp

nscp copied to clipboard

Development and documentation has halted and barely moved.

Can it be declared that NSClient++ is dead?

It's not dead, merely resting I think :) @mickem has replied to a few issues over the past few months but I assume he's super busy and not had a chance to pick up development

No, I am atleast not dead... I have been busy working on some internal stuff (upgrading protobuf and other dependencies) which has takes ore time then it should due to being busy at my actual work...

No, I am atleast not dead... I have been busy working on some internal stuff (upgrading protobuf and other dependencies) which has takes ore time then it should due to being busy at my actual work...

OK, it just seems development has stopped so maybe it is time to switch to NCPA

Development have not stopped, but you are free to switch. Are there some feature you need or some specific issues?

What I am working on currently is updating a lot of the internal of NSClient++ this has taken longer then I hoped. I also last spring rewrote the webui using angular 2 which turned out to be a dead end so I need to re-do that which again will take toms time. But seems that people need a new update so maybe I should release the refactoring I have and not wait for the new UI?

So development has not stopped but is currently be done "unpublished" as the code is not ready yet... But I will clean up and push my changes over the weekend so there is proof :)

Although ncpa works fine, for us it's missing 1 critical feature and that is the real-time event log monitoring feature. Only using ncpa on 2008 sp2 as we still have issues with hanging nscp processes on those. What I feel is missing in Nsclient is full nrpev3 support.

Given than nrpev3 is a closed proprietary protocol I am hesitant to add support for it. I would advocate using the REST based protocol in NSClient++.

Development have not stopped, but you are free to switch. Are there some feature you need or some specific issues?

What I am working on currently is updating a lot of the internal of NSClient++ this has taken longer then I hoped. I also last spring rewrote the webui using angular 2 which turned out to be a dead end so I need to re-do that which again will take toms time. But seems that people need a new update so maybe I should release the refactoring I have and not wait for the new UI?

So development has not stopped but is currently be done "unpublished" as the code is not ready yet... But I will clean up and push my changes over the weekend so there is proof :)

A lot of people I dont think bother with the webgui.....

There are a lot of things broken or missing..... The other day I missed check_pagefile for a time parameter....for example.

Also, I really think that a webgui is not the main focus point; I think something that really needs attention and focus is documentation. It is really weak and lacking explaination and/or examples.

Dont think this as rude or harsh as there is no tone of voice in my text

Do you have any examples of sections in the documentation which you find especially lacking?

Regarding the web interface one of main reasons for it is to make NSClient++ more accessible, but I hear you.

Anyways, 0.6.0 will be out in beta in the next few weeks, so feel free to let me know anything you would like fixed for that version and I will try to accommodate as best as possible...

If you are using NCPA you should be aware of the license terms:

The Software may only be used in conjunction with products, projects, and other software distributed by the Company. Any standalone use of the Software, or use of the Software in conjunction with products, projects, or other software not authored or distributed by the Company - including third-party software that competes with the offerings of Company - is strictly prohibited and is a direct violation of the terms of the license.

If i understand it correctly you are not allowed to use it with icinga or any other monitoring software that is not from Nagios Enterprises, LLC

up !

It is not dead, but alas I have been waay too busy... I plan (as I often do) to resume a more active development "soon" but I have many other projects which have had more pressing needs. But all-in-all NSClient++ is something I do in my spare time so depending on how much spare time and we moved to a house two years ago which kind of took a lot of my spare time. But alas a lot of that stuff is no getting sorted so I hope to resume a more active role in the next few weeks...

I appreciate the challenge of open source development for sure. And your level of effort in the tool is clear. There seem to be some pressing needs surrounding TLSv1.1 & 1.2 support that is causing issues using this in a modern compliance environment. Would it be possible to spend some time triaging issues and focusing on the more important ones? Maybe processing some of the pull requests?

Are there any plans to release a new stable version, even if it's just a wrap up of existing bug fixes? We are in a situation where we are affected by a bug which was fixed in a nightly release 3 years ago (#549), there has been no stable release since, there is no chance of getting sign off to run a non-stable release in our environment but there are no alternatives to NSClient++ (NCPA license forbids its use with products from other vendors).

@adamsweet we were very much in the same boat as yourself and have started an internal (MIT licensed) project to create an HTTPS based replacement.

We've not marked it as a stable release as of yet however we are using it widely on our internal infrastructure; aiming for release reasonably soon and hopefully should fill that gap: https://github.com/infraweavers/monitoring-agent

@infraweavers thanks for mentioning that, very interesting. Having had a quick look at it, is it possible to define 'command name = command line' pairs in the configuration like NRPE/NSClient or do you just specify an arbitrary command to execute in the API request? I don't see anything about that in the config/docs so I assume not. Is that on the roadmap?

Not wanting to push people in any direction...

But this is a "spare time project" and last years has been very little of that unfortunetly due to the fact that I now have a family as well as a job which requires a lot. I hope to get a new version out over summer. The main culprit here is that is takes a lot of time setting up all compiler options for all the third part libraries that (unfortunetly changes) So getting this to state where it "compiles" is unfortunetly quite time consuming, but apart from one plugin I am pretty much there so expect builds in the next few weeks...

Thank you @mickem for the update. I didn't want to sound ungrateful, I was just looking for a solution and I don't think there's any shortage of appreciation for what you have contributed over time. NSCP is a key component of tens of thousands of monitoring environments around the world.

If there's anything the NSCP community can do to support you, please let us know. I'm not able to contribute code, but myself and others here will surely be willing to help if you can delegate tasks. I notice the NSClient website has a get involved section which points to Github (and forums but they are returning 502) but there's nothing which specifically says what anyone can do to help. There has been lots of discussion on how the demands of single developer open source projects can result in burnout, make the developer really miserable and go dormant.

Perhaps a poll would be useful in determining which features people use most (NRPE/REST API/web UI etc) so you know where your effort should be concentrated and which features are needed most (TLS was mentioned above and you mentioned the web UI needs to be started again). Then perhaps Github Sponsorships/Patreon/crowdfunder could sponsor your effort. Just thinking out loud, I hope you don't mind.

Let us know how we can help.

Thanks for the update @mickem. We all can see and appreciate your effort on this project over the years. Your priorities are good ones. We'll keep an eye out.

Hello @mickem

The NClient forums show a 502, https://forums.nsclient.org/ , a temporary issue hopefully?

In the meantime Centreon has forked the project and they are releasing new versions here: https://github.com/centreon/centreon-nsclient-build/releases

Please provide an update. Its more than a year since a new release has been announced. Issues queue up in a long list.

Any statement would help in plannibg for new systems.

Given than nrpev3 is a closed proprietary protocol I am hesitant to add support for it. I would advocate using the REST based protocol in NSClient++.

Dear @mickem,

Thank You for the NSClient++ software first !

We plan to install it on all our Windows servers and plan to monitor those servers using the REST API only. At this time, as I cannot login to the embedded WEB Interface in order to configure it as a PoC, we cannot go on on this project ... Could You please give to all the Centreon/NSClient++ customers a timeline of the planned coming updates for the 0.5.x and 0.6.x releases ?

Many thanks in advance, Jean

In the meantime Centreon has forked the project and they are releasing new versions here: https://github.com/centreon/centreon-nsclient-build/releases

Dear @hecko,

The latest release of the Centreon installer (Centreon-NSClient-0.5.2.41-20211102-x64) contains the NSClient++ client released in 2018 (https://github.com/mickem/nscp/releases/tag/0.5.2.41) bundeled with the latest up-to-date Centreon plugins. We have though the same issues regarding the NSClient++ software itself ...