[Xymon] RES: Is the xymon Dead? Future

[Richard L. Hamilton]

> On Mar 8, 2019, at 11:14, Bruce Ferrell <bferrell at baywinds.org> wrote:
> 
> 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/ <https://sourceforge.net/p/nfsen/bugs/>
>> 
>>> provide updates/patches via pull requests,
>> Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/ <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 <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=/branches/4.x-master>
>> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk <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. 

Certainly the price is right compared to commercial alternatives.  Some places can't seem to get $$ for system monitoring.  Of course, it costs regardless (you need either someone in-house or a vendor to set up a product, and someone in-house to update it and the configuration data it needs).  And it definitely costs if you don't monitor, assuming it matters enough to have something working that you want to fix problems quickly.

> 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.

One can't count on remote clients having IPv6 capability, so everyone that deals with end users over the Internet still needs to support IPv4.  And for private addresses, running out of them is a non-issue.  Still, sooner or later, the IoT will mean billions of connected gadgets, which will sooner or later require IPv6.  Quite a lot of major sites do support IPv6 outward-facing.  (some examples: Apple, Facebook, Oracle, YouTube, Google, Instagram...but not Twitter)  Plenty of ISPs support it, at least if the client isn't running ancient modems and/or routers.  Everything that adds IPv6 support takes away another excuse for not using it.  Phones may use IPv6 if available; I see both WiFi and cellular IPv6 addresses for mine, at the moment.

> 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. 

One aspect is info regarding relationship between host and VM or container, and the type of VM or container technology (which implies the commands used to probe it).  It would be useful to be able to show e.g. all VMs/containers on a host, or the (current, since they may be able to live migrate) host running a VM/container, and the technology used (be it Docker, VMware, VirtualBox, Parallels, Solaris LDOMS or zones, etc)...since some fixes will require knowing that.  It's worse when you consider that some of those can be live-migrated, so the host to VM or container relationship isn't constant.  I would think that that, along with resource management, would be the main issues.  Of course, large-scale virtualization solutions probably have a lot of that anyway, but at least a partial view via Xymon would IMO be very handy.  

Other than that, what's really different about a container or VM, compared to a physical system?  There may be an extra level of resource management, but I'm not sure it's useful for Xymon to know about and report that.

And how far do you really want to go?  Xymon is a monitoring tool, not a configuration management tool (although for dubiously managed systems, I might make sure history is retained and some non obvious configuration data is captured in tests, so that it may help document what's needed to put Humpty back together again).  But containers and VMs in principle have their own configuration management, or at any rate the ability to re-create them new with the latest tested combo of what they need; so maybe some extra tag that's to containers or VMs what [clientversion] is to Xymon client software tarballs distributed via Xymon, would be good enough to let one see what (local, I suppose) rev a container or VM build is at; the containers/VM's might need to be built to have that  pre-stored in a file that the client script can check for.

> 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.
> 
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon

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