<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 8, 2019, at 11:14, Bruce Ferrell <<a href="mailto:bferrell@baywinds.org" class="">bferrell@baywinds.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" class="">
<div text="#000000" bgcolor="#FFFFFF" class="">
On 3/8/19 7:08 AM, Axel Beckert wrote:<br class="">
<blockquote type="cite" cite="mid:20190308150849.GH10429@sym.noone.org" class="">
<pre class="moz-quote-pre" wrap="">Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote
community contributions.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think you meant CVS instead of VCS. VCS (Version Control System) is
the general term for CVS, SVN, Git, Mercurial, etc.
</pre>
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">but github would allow the community to report issues,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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:
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/nfsen/bugs/">https://sourceforge.net/p/nfsen/bugs/</a>
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">provide updates/patches via pull requests,
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Exists on SF, too, example: <a class="moz-txt-link-freetext" href="https://sourceforge.net/p/nfsen/patches/">https://sourceforge.net/p/nfsen/patches/</a>
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">and download either released versions via the tags
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Possible, too, example:
<a class="moz-txt-link-freetext" href="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</a>
</pre>
<blockquote type="cite" class="">
<pre class="moz-quote-pre" wrap="">if necessary or the latest code via the 'develop' (or
whatever) branch.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="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</a>
<a class="moz-txt-link-freetext" href="https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk">https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk</a>
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
</pre>
</blockquote>
I've been using Xymon and it's predecessor BB, since 2002,
administering *IX systems since the mid 80's and Linux since '93. <br class="">
<br class="">
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. <br class=""></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
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.<br class=""></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
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. <br class="">
<br class="">
GIT, CVS and SVN (to name only a few) inherently don't offer bug
tracking. github does, gitlab does and so does sourceforge. <br class="">
<br class="">
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.<br class="">
<br class="">
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. <br class=""></div></div></blockquote><div><br class=""></div><div>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. </div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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.</div><br class=""><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class="">
When I can see something I need/want tracked and monitored, I do the
following:<br class="">
<br class="">
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 )<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
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.<br class="">
<br class="">
</div>
_______________________________________________<br class="">Xymon mailing list<br class=""><a href="mailto:Xymon@xymon.com" class="">Xymon@xymon.com</a><br class="">http://lists.xymon.com/mailman/listinfo/xymon<br class=""></div></blockquote></div><br class=""></body></html>