[Xymon] RES: Is the xymon Dead? Future

[Bruce Ferrell]

On 3/8/19 7:08 AM, Axel Beckert wrote:
> Hi,
>
> On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
>> On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
>>> Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote
>>> community  contributions.
> I think you meant CVS instead of VCS. VCS (Version Control System) is
> the general term for CVS, SVN, Git, Mercurial, etc.
>
>>> Git, specifically GitHub, has replaced SVN as the best thing to
>>> promote community contributions, and I think it would be
>>> beneficial if the official Xymon code repos are migrated to
>>> GitHub.
> Definitely, but it's also not the only thing which is needed for
> getting contributions from external contributors. It's also a social
> thing.
>
> Reviewing and accepting contributions — or maybe even giving
> trustworthy contributors commit access is also necessary for a FLOSS
> project. But as far as I can tell, this happens in the Xymon project,
> although not on a daily base.
>
>> but github would allow the community to report issues,
> SF does allow that, too, it's just not enabled for the Xymon project
> on SF. Example of an SF project where it is enabled:
> https://sourceforge.net/p/nfsen/bugs/
>
>> provide updates/patches via pull requests,
> Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
>
>> and download either released versions via the tags
> Possible, too, example:
> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
>
>> if necessary or the latest code via the 'develop' (or
>> whatever) branch.
> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master
> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
>
> Don't get me wrong: I think SF degraded from once the best place to
> host FLOSS to a website with tons of outdated trash and the most
> horrible UI I ever saw from a code hosting site. Not to mention that
> it is far too overladen with ads and popup.
>
> My personal preference in VCS hosters is also GitHub as — from my
> point of view — they currently provide the best user experience. OTOH
> there might be some qualms about Github being not completely open
> source and being owned by Microsoft.
>
> And with regards to being dead or not: Development greatly sped up
> when J.C. Cleaver took over release management, but it indeed seems to
> have stalled a little bit again. Then again, IIRC J.C. mostly took
> over release management so that Henrik can focus on long-time
> development. And if there is not much to fix in the current stable
> releases, not having a stable release every few months is not
> necessarily "dead", but might also be "stable, no relevant open
> issues".
>
> (And yes, I'm still hoping and waiting for IPv6 support, too,
> especially in xymonnet-based checks. Reporting to IPv6-only servers is
> no issue though, if you anyways use stunnel to encrypt the
> client-reporting traffic.)
>
> 		Kind regards, Axel
I've been using Xymon and it's predecessor BB, since 2002, administering 
*IX systems since the mid 80's and Linux since '93.

Xymon is far from dead and is most definitely more useful, flexible and 
stable than most of the tools advocated by the kewl kids... Especially 
once extensibility via add-ons is factored in.  I'm not sure where the 
idea comes from that a tool has to be constantly and actively churning 
to be useful and current.

IPv6... eh.  No matter how much people scream that "we gotta have 
it!!!", as has been mentioned, it's really not much used in real life.  
And I think I can make that statement authoritatively... To pay my 
bills, I do enterprise level support for a major vendor.  I see hundreds 
of customer networks annually and see almost no ipv6 and very little 
demand for it.  That said, it's most likely I good idea long term to get 
that kind of support into xymon.

The politics of where to host repositories and what VCS to use... ALL 
public hosting sites are a pain in one way or another and that is an 
entirely separate issue from the VCS technology used.

GIT, CVS and SVN (to name only a few) inherently don't offer bug 
tracking. github does, gitlab does and so does sourceforge.

Much as a dislike what SF became, it tends to offer the most variety in 
the tools offered and we needn't mention the owner of github.

Container monitoring, MIGHT be a good idea... If someone can say what 
specific things they want to be monitored/reported.... Not just holler 
they want monitoring.

When I can see something I need/want tracked and monitored, I do the 
following:

   1.)  Start from the assumption I'm neither the first only only one to 
do this -- Who else has done this before and what did they do? Is there 
something close to what I need? ( xymonton/deadcat anyone )
   2.)  If I find I am a snowflake (not very often), then I look at what 
sort of test I need.  At this point, it's usually a VERY simple thing to 
test from a shell script.  Add that to $XYMONHOME/ext and the tasks file 
and I'm done.

What I HAVE seen done around containers looks insane to me... Something 
not too unlike strace on steroids and then passing the output to splunk 
like tools and things like graphite... Neither of which do I agree with 
especially for tools like Xymon.

Given recent findings around security  of "off the shelf containers" 
that are loaded with insecure and unmaintained libraries, that LOOKS 
like something that might be a target... But it also makes me look with 
a very jaundiced eye at containers. If not the concept, then the 
practice and that's a whole different discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190308/249ddf79/attachment.html>