[Xymon] RES: Is the xymon Dead? Future

[Richard L. Hamilton]

I don't have "large" at home, of course - not hundreds, but very low two digits, slightly less low if VM's that are only up intermittently are counted.  It is eclectic: three different Solaris versions (on SPARC and x86), two different macOS versions, one Windows physical, one SPARC Linux LDOM, and a couple of the latest of CentOS and Ubuntu on the intermittent VMs.  And I'm retired, so I don't have access to anything else to test on (and might have found it problematic to run test software at work when I wasn't retired).

I do have something for you to think about, though.  While IPv4 certainly isn't going to go away until everyone gives up on it, the use of IPv4 and IPv6 can only increase.  And physical connectivity doesn't mean both will work - my home router sometimes loses external IPv6 connectivity until I log into it and drop and renew the DHCPv6 lease.  (thank the network deities that there is some attempt to keep the /64 prefixes from changing too much, since I don't have DNS updates automated for IPv6)

So since I already have a server-side Xymon script that probes the router (using upnpc command, as home routers don't necessarily provide other non-web ways of finding out connectivity status and external IP), I also have it do an IPv6 ping of a public server, and turn yellow for router internet status if IPv4 is up but IPv6 is down.  (modem internet status is just a web scrape and inspection of the result, since my modem only provides status and not configuration to the user, and does not require a login for that)

But a more generic solution might be able to offer an enhanced version of conn= tag, and even an additional conn6= tag, allowing either consolidated address testing, or one column each for IPv4 and IPv6; that would let one better spot connectivity issues in a mixed IPv4/IPv6 environment!  


> On Mar 12, 2019, at 01:09, Japheth Cleaver <cleaver at terabithia.org> wrote:
> 
> On 3/11/2019 6:59 AM, SebA wrote:
>> 
>> On Fri, 8 Mar 2019 at 15:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote:
>> 
>> 
>> 
>> Well another option is just to convert the repo on SF from SVN to Git, but keep it hosted on SF.  And then also to enable the bugs and patches area - if someone is going to monitor and maintain those areas.  I have seen SF projects where no-one does.  But most active FLOSS projects are on GitHub these days.
>>  
>> 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".
>> 
>> Yes, development did greatly speed up, but it practically ceased when J.C., I think, found difficulty merging the patches he had been using in his RPMs with Henrik's new 4.4 code.  Or over 2 years ago (Jan 2016) when he released 4.3.28.  I know the idea was that Henrik could focus on long-time development, but I think that ceased over 3 years ago - his last commit was in Jan 2016, with the last development type commit being Dec 2015.  Both of them changed jobs (Henrik in Aug 2013 and J.C. in Sep 2015) and I'm guessing no longer used, or needed to develop, Xymon in their new roles and then their desire or capacity to keep putting time into the project dwindled.
> This is a fair criticism, unfortunately. The primary issue for me since then has been having access to sufficiently high-throughput performance and load testing, which had been a significant aspect of the feature and dev cycle. I'd been hesitant to release further absent a true shakedown of the new code, however that was /never/ intended to be an indication of lack of interest in the project. It had seemed to have gotten to a point where a lot of the low-hanging fruit had been hit and there was -- once again -- a large delta in the jump to the prospective next release  -- in fact, which I feel was similar to the previous stall.
> 
> (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
> 
> And I'm still hoping for TLS support in the client.  I did try https URL as the recipient (which should work - r7797) but I couldn't get it to work in the RPM version
> Knowing that there is still actually a demand for IPv6 is helpful. Simply put, what's most needed right now is a potentially large testbed for testing and validation of the code we have.
> 
> Regards,
> -jc
> 
> _______________________________________________
> 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/20190312/5a919903/attachment.html>