[Xymon] Is this thing on?

[Bruce Ferrell]

On 8/17/23 1:27 PM, J.C. Cleaver wrote:
> On Tue, August 15, 2023 09:34, Bruno Manzoni wrote:
>> Hi Xymon Lovers,
>>
>> Glad to see everyone still loves Xymon and ready to give more!
>> *I've summarized this discussion *"Is this thing on"
>>
>> *To move forward:**
>> **Non-technical needs:*
>>
>> *  Mailing list migration*, not possible to sign up for the Xymon user
>> group anymore (*URGENT PROBLEM*)
>>       Share community developed plugins/monitors (it seems some people
>> may have a lot to share)
>>       Several resources available if needed (developer, server web, demo
>> platform, infra, maybe also money)
>>       More than one enthusiastic developer (probably not only devs...)
>>       Need a caretaker: updates to fix bugs, adapt to new OS versions,
>> Terabithia RPM
>>       Henrik won't be able to contribute much (but a little might also
>> be
>> good!)
>>       A clearer organization
>>       Wikibook information udpate
>>
>> *Technical needs*
>> *New features that we would like to have or that were planned*
>>
>>       Reports, communication encrypted, or at least authenticated,
>> Direct
>> SSL support and/or message signing (*MOST REQUESTED*)
>>       Introductory document for developers
>>       IPv6 (some of which is working in the 4.4 alpha branch)
>>       Abstraction of remaining formatting to simple CSS to allow for
>> skinning and dashboarding
>>       JSON endpoint version of xymondx{log|board}
>>       REST-based C shim .cgi, both of which could help folks integrating
>> Xymon with other monitoring systems out there
>>       Forklifting of the many performance enhancements and tweaks from
>> the Terabithia RPMs into the source tarball.
>>       Move the source to Github in the hopes of creating an easier
>> onramp
>> for patch submissions via PRs, bug reports
>>       Rocky package.
>>       Missing in the base, arp, netstat, ifconfig and route are supposed
>> to be replaced by "ip" and "ss" commands.
>>       Moving away from C as the primary language. Python would probably
>> have a lot more potential developers (*MAIN SUGGESTION FROM HENRIK*)
>>       Consider replacing the proprietary Xymon protocol with a REST API
>> instead - then you could use standard http modules to talk to Xymon.
>> Look at what each tool does, and reimplement it in a more modern way.
>>       Fix all string management warnings reported by gcc.
>>
>>
>>
>> *1. Please, let us know if all your info is in these lists *or *if you
>> have other ideas *and *what do you think of all this now that you have
>> an summary ?*
> Thank you for this write-up! I think this aptly summarizes where things are.
>
> I suspect with the number of sysadmins on the list, we should be able to
> solve any questions of domains, hosting, and email fairly quickly. I use
> my own builders for the Terabithia RPMs, but as development picks back up
> it will be helpful to set some formal targets for the main release to
> ensure that we maintain compatibility with the various systems we're
> intending to. (GCC warnings in particular may cause more strife.)
>
> The rest broadly does seem like it comes down to technical vs
> non-technical issues. While *I'm* personally OK with the man2html look,
> I'm pretty sure that's not what The Kids like today :) I had looked at
> things like ReadTheDocs and other .io projects, which could provide a
> useful re-structuring of the existing introductory material, and then form
> the basis for renewed walkthroughs, FAQs, and the like in a more
> approachable manner. (While still keeping the comprehensive man pages
> available.)
>
> While I'm a competent enough technical writer, as these emails make clear
> I'd sorely need an editor :) But if someone with an eye for documentation
> and more aligned with modern tech sensibilities could take the lead on
> site design and structure I think that would be something very helpful for
> the project.
>
>
> I would also second that unifying the wiki materials is probably a good
> thing, including making sure links to xymonton and any other BB resources
> are prominently available.
>
>
> The technical directions are a big chunk to chew, but I think the
> documentation and front-door experience is probably more directly relevant
> to revitalizing interest (barring the SSL issues brought up elsewhere).
>
> Regards,
> -jc
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon

In the beginning there was port 1984 and shell scripts... And it was good;

So good that Dell devoured it whole without a burp and it was never seen again.

C was an improvement, but also introduced all sorts of odd little bugs that shell never was vulnerable to (some called them hobbits until people lacking a sense of humor told them 
to knock it off) and those had to be solved and gave us some interesting new capabilities at the same time like SNMP monitoring built in (IF you could gather all the bits and 
pieces and get it to work;  I did it once and the next upgrade broke it and I had no to time to sort it out again).

Now someone is suggesting python or rust.  Which python?  Which rust?  As someone who fights with questions like this for both a living and a hobby, I shudder and pale at the 
suggestion and begin considering what other tools I should start thinking about. Starting adding funky dependencies and admins start walking away.

The iproute2 family of tools (the "ip" and "ss" commands) have introduced a similar set of issues.  These aren't terrible, but they ARE irritating.

Adding secure communications (ssl/tls and certificates/signing) is possibly the simplest enhancement to make... And most likely to break everything for someone if done wrong in 
either the code or config.

Replacing the "the proprietary Xymon protocol with a REST API"?

  Is it really a proprietary protocol?

Let's look at that;  I want a new test -- I knock together something that collects/senses what I need to know about and tells $XYMONHOME/bin/xymon to transmit it.

I don't need to know ANYTHING about how to get it to the display and I don't care.  I do have to know how to tell the display what to do when the data get's there and how to chart 
it.  I've spent a number of hours digging through rrdtool docs, but those are pretty clear.

How much of the existing ecosystem might a REST API destroy? Is that destruction worth it?  What is the actual gain?

The friendliest and most useful enhancement, I believe, is documentation.

As an example, I just installed snap package management on a VM that sets up some mounts that are 100 percent all the time. Solution: Ignore them... Yeah, right!  I cannot make 
them be silent. When I have a BIT more time, I know I'll solve the issue, but for now, I've simply suppressed them.  There a LOT of this type of issue and lack of documentation has 
led to a lot more re-invention of the wheel.

SSL/TLS used to be handled by freely available stunnel... But the method was never documented well (it was obvious!  Was it?) and is now lost in the mists of time.

I already mentioned the SNMP monitor configuration.  Trust me, devmon sucks, but it's what is consistently/readily workable... As long as I restart it regularly otherwise it swells 
like a poisoned animal.

Documentation is the least "sexy" thing to do, so I suspect the kewl sexy things will happen... Python/rust/REST, and the documentation will be ignored

Just my old neck beard view of this, worth every penny that you paid for it.