Xymon, community, updates, and directions (was Re: Is this thing on?)
What is there works beautifully for me. To say I appreciate the work that everyone has done just doesn't begin to describe how it helped us grow.
In the near future I'd love to see a Rocky package. SSL would be kinda neat I guess, but I subscribe to the notion that if you've got a mitm on your system's network you have other problems to worry about anyway.
On Mon, Aug 14, 2023 at 6:39?PM Damien Martins via Xymon <xymon at xymon.com> wrote:
---------- Forwarded message ---------- From: Damien Martins <damien at makelofine.org> To: "J.C. Cleaver" <cleaver at terabithia.org> Cc: Damien via Xymon <xymon at xymon.com> Bcc: Date: Tue, 15 Aug 2023 00:38:28 +0200 Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?) If i had to vote for something: bring the code to a git(hub?) repo so people with required skills and time could contribute.
Regards, Damien Martins Le 14 ao?t 2023, ? 22:57, "J.C. Cleaver" <cleaver at terabithia.org> a ?crit:
Hello all,
Catching up with the thread from these past few days, this seems the proper place for me to chime back in.
While it's possible to call xymon simply a quiet, stable project (which it is, with many installs simply and quietly doing their jobs in the background out there), it's also very fair to say that the project -- or at least the plans I (and, I'll assume, Henrik) had for it has indeed reached a stalling point.
That doesn't mean it can't come out of a stall! But it does mean it takes effort to resume work on.
Following on with others' comments, the Xymon codebase is somewhat... intense. When I was performing near-daily performance enhancement and tweaks for Xymon for $dayjob, there was a solid ability to stay in the zone and I could add features as needed at a rapid clip. Since then, as I moved on to other positions and responsibilities, my day-to-day involvement with the code base dried up, and getting back into it can be difficult unless you're doing a lot of C elsewhere and not spending it cursing at kubernetes.
In short, there's a significant ramp-up and re-ramp-up involved, as one might expect from any mature codebase. While the underlying documentation for use and administration is extremely thorough IMHO, an Intro for Devs document was something we never followed through well on.
Development plans had at one point been something like:
- direct SSL support and/or message signing (probably the most frequently requested things, for those for whom stunnel-wrapping was not an option)
- 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
I'd also had in mind things like a JSON endpoint version of xymondx{log|board}, and a REST-based C shim .cgi, both of which could help folks integrating Xymon with other monitoring systems out there.
Of course, the initial target was simply the forklifting of the many performance enhancements and tweaks from the Terabithia RPMs into the source tarball. This got pretty far there in the 4.4 branch, with only a few major components not integrated. However debugging those components and patches stalled out, especially with the need to maintain robust pan-*nix compatibility.
That, ultimately, is where we are now.
To kick things off: In the past, there had been requests to move the source to Github in the hopes of creating an easier onramp for patch submissions via PRs, bug reports, and the like. While I personally feel like SF and svn would still work, I think this probably deserves to be back on the table.
In addition, Henrik had mentioned that we'll need a mailing list migration at some point coming up soon.
Beyond that, to be honest I'm not sure what the next, best step is to take. Life had indeed gotten in the way, to follow from the comment below, as $dayjob+=4 and other responsibilities cropped up.
I really welcome the entire community's input here going forward.
Regards, J.C. Cleaver
On Mon, August 14, 2023 09:58, Bruno Manzoni wrote:
Hellor Xymon Lovers I'm not a coder either, but I see there's quite a bit of brains out there (and I think if there are enough of us we can try to maintain and improve it). Perhaps the current officials could first tell us what their plans are and how we could help them. On our side, we can perhaps encourage them: it would be good to list what we can bring to the project, as some have done! - I try to maintain "devmon" (on the github repo) and some other xymon tool (I did try to understand how devmon is integrate to xymon, but I am not an expert in Xymon code) - I am a telecom engineer - I can give some some time - I am an independent and I have some infra to play with - Usually I speak swiss-french (so sorry for all my mistakes) Bruno
On 14.08.2023 18:36, James Louis wrote:
Is the Terabithia RPM also dead?
Jim
On Mon, Aug 14, 2023 at 10:03???AM Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com> wrote:
I would be OK with contributing some as well???. But that???s notwhat Xymon needs.? Xymon needs caretaker(s) to keep it relevant.? That means code updates to fix bugs, adapt it to new OS versions, etc.? Otherwise it will fade away to obscurity like many other open source projects.? I???m not a coder either, or I would gladly give some time to it.
*Scot Kreienkamp? | Senior Linux Systems Engineer | La-Z-BoyCorporate* One La-Z-Boy Drive | Monroe, Michigan 48162 |( (734) 384-6403 | | ) 1-734-915-1444 | Email: Scot.Kreienkamp at la-z-boy.com
*From:* Rod <rodbass63 at gmail.com> *Sent:* Monday, August 14, 2023 10:56 AM *To:* Ralph M <ralphmitchell at gmail.com> *Cc:* Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com>; xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* Re: [Xymon] Is this thing on? I would like to continue the legacy. I'm not a developer but I'm willing to pay for hosting space and the domain name to keep it going for as long as I'm alive. Its kept me employed for a longtime.
On Mon, Aug 14, 2023 at 10:32???AM Ralph M <ralphmitchell at gmail.com> wrote: I've been using Xymon at several different? employers since it was BigBrother owned by a couple of guys in Canada.? My current Senior VP wants Xymon to go away.? He hasn't actually told me that directly, but I've heard it via another channel.? We have SolarWinds on some machines, but I've never even seen the GUI for that.? We're also distributing Oracle Enterprise Manager (OEM) to a bunch of machines.? I don't know for sure, but I suspect a contracting company is whispering in my SVP's ear to sell support for OEM.? In the meantime, my Xymon server has 878 days uptime and they're still trying to figure out how to install and configure the OEM agents.? It's going to be tons of fun watching them try to replace all the little scripts I've written with OEM equivalents. @Cristoph - I don't know if I can use stunnel.? It's a military-related company and there are all kinds of restrictions that sometimes even make sense. Ralph Mitchell On Mon, Aug 14, 2023 at 9:41???AM Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com> wrote: No new release since 2019, no activity on the mailing list, I think it???s safe to say it???s flatlined.? Sad tosee it fade, I???ve been using it for a decade or more.
*Scot Kreienkamp? | Senior Linux Systems Engineer | La-Z-Boy Corporate* One La-Z-Boy Drive | Monroe, Michigan 48162|((734) 384-6403 | | )1-734-915-1444| *Scot.Kreienkamp at la-z-boy.com www.la-z-boy.com <http://www.la-z-boy.com>? | facebook.com/lazboy <http://facebook.com/lazboy>? ? | twitter.com/lazboy <http://twitter.com/lazboy>| youtube.com/lazboy <http://youtube.com/lazboy> Smaller LZB Only Logo for Sign.png *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of *Neil Simmonds *Sent:* Monday, August 14, 2023 5:29 AM *To:* xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* Re: [Xymon] Is this thing on? Is Xymon dying? No new release since 2019, There was a roadmap in 2015 that mention Versions 4.4 up to 5 but nothing seems to have moved on that. It feels like Xymon has become a static project that???s going to fade away. That would be a shame as I for one think it???s a great tool. *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of *Galen Johnson *Sent:* Sunday, August 13, 2023 3:01 AM *To:* xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* [Xymon] Is this thing on? *[CAUTION]*This is an external email. Do not click links or open any attachments unless you are sure they are safe. Nothing since May seems a bit suss. =G= Studio is a trading name of Studio Retail Trading Limited (Company no. 03994833), which is an introducer of credit not a lender. Studio Pay is provided by Frasers Group Financial Services Limited (Registered Company no. 00718151), which is authorised and regulated by the Financial Conduct Authority (FRN 311908) for consumer credit and general insurance and a member of the Finance and Leasing Association. Both companies are registered in England and their registered office is: Church Bridge House Henry Street Accrington BB5 4EE. *NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. The recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Studio Retail Trading Ltd and Frasers Group Financial Services Ltd reserve the right to monitor all e-mail communications through their internal and external networks. If you have received this email in error please let us know. You can find our available contact details by going to help.studio.co.uk <http://help.studio.co.uk> and clicking ???Contact Us???.* This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon-- *Jim Louis
? ? ? ? ? \\\\||//// ? ? ? ? ? \ ~ ~? / ? ? ? ? ? | @ @ | * *--oOo---(_)---oOo--
/???The part of life we really live is small. All the rest is not life, but merely time.?? /
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
---------- Forwarded message ---------- From: Damien Martins via Xymon <xymon at xymon.com> To: "J.C. Cleaver" <cleaver at terabithia.org> Cc: Damien via Xymon <xymon at xymon.com> Bcc: Date: Tue, 15 Aug 2023 00:38:28 +0200 Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Thanks JC for taking the time to chime in. Your efforts in recent years breathed new life into the project, and so many of us have benefited greatly. It would've been nice to have a way to have my employer contribute financially to a fund that made it more viable for you/Henrik to spend time on maintenance.
I agree with others on the need for SSL/TLS these days, or at least some form of encryption. Many organisations now require comms to be encrypted, or at least authenticated, using robust, modern cryptography. In my case, we're periodically asked about our comms, and receive raised eyebrows when we respond.
I am also sympathetic to the notion that if we have to rely on encryption on our network, then we have bigger problems. But there are still reasons why encryption is desirable. For example, when monitoring a device connected via someone else's network. Or even just to slow down an attacker that has made her way onto our network, and perhaps even set off alarm bells when she tries to talk BB in cleartext and without authenticating, with the attempts generating log messages. Another way to view it is, "perfect is the enemy of good". I'd prefer to have encryption and authentication on a network that has an APT ferreting around, than not.
The work-arounds are not ideal for a few reasons. But I suspect the main one is that there is no consistent and standardised workaround, that every deployment that requires it tends to use. If everyone simply used the stunnel solution, then it would end up being well supported by the community, with lots of help, documented experiences, how-tos and best practice guides. But I find myself not wanting to make a poor choice, so I haven't made any choice. I suspect the stunnel option is probably the best option, but I have a feeling there will be a performance impact.
Not wanting to de-rail the conversation, the main point is that encryption/authentication is an important factor for me, and the missing feature is present in alternatives to Xymon. Some of the proposed alternatives are inadequate, but are still given credence due to the ticking the "security" boxes. If Xymon had this one feature built-in (or standardised), and had the occasional bug fix, then it would be treated with much less scepticism.
J
On Tue, 15 Aug 2023 at 11:48, Josh Luthman <josh at imaginenetworksllc.com> wrote:
What is there works beautifully for me. To say I appreciate the work that everyone has done just doesn't begin to describe how it helped us grow.
In the near future I'd love to see a Rocky package. SSL would be kinda neat I guess, but I subscribe to the notion that if you've got a mitm on your system's network you have other problems to worry about anyway.
On Mon, Aug 14, 2023 at 6:39?PM Damien Martins via Xymon <xymon at xymon.com> wrote:
---------- Forwarded message ---------- From: Damien Martins <damien at makelofine.org> To: "J.C. Cleaver" <cleaver at terabithia.org> Cc: Damien via Xymon <xymon at xymon.com> Bcc: Date: Tue, 15 Aug 2023 00:38:28 +0200 Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?) If i had to vote for something: bring the code to a git(hub?) repo so people with required skills and time could contribute.
Regards, Damien Martins Le 14 ao?t 2023, ? 22:57, "J.C. Cleaver" <cleaver at terabithia.org> a ?crit:
Hello all,
Catching up with the thread from these past few days, this seems the proper place for me to chime back in.
While it's possible to call xymon simply a quiet, stable project (which it is, with many installs simply and quietly doing their jobs in the background out there), it's also very fair to say that the project -- or at least the plans I (and, I'll assume, Henrik) had for it has indeed reached a stalling point.
That doesn't mean it can't come out of a stall! But it does mean it takes effort to resume work on.
Following on with others' comments, the Xymon codebase is somewhat... intense. When I was performing near-daily performance enhancement and tweaks for Xymon for $dayjob, there was a solid ability to stay in the zone and I could add features as needed at a rapid clip. Since then, as I moved on to other positions and responsibilities, my day-to-day involvement with the code base dried up, and getting back into it can be difficult unless you're doing a lot of C elsewhere and not spending it cursing at kubernetes.
In short, there's a significant ramp-up and re-ramp-up involved, as one might expect from any mature codebase. While the underlying documentation for use and administration is extremely thorough IMHO, an Intro for Devs document was something we never followed through well on.
Development plans had at one point been something like:
- direct SSL support and/or message signing (probably the most frequently requested things, for those for whom stunnel-wrapping was not an option)
- 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
I'd also had in mind things like a JSON endpoint version of xymondx{log|board}, and a REST-based C shim .cgi, both of which could help folks integrating Xymon with other monitoring systems out there.
Of course, the initial target was simply the forklifting of the many performance enhancements and tweaks from the Terabithia RPMs into the source tarball. This got pretty far there in the 4.4 branch, with only a few major components not integrated. However debugging those components and patches stalled out, especially with the need to maintain robust pan-*nix compatibility.
That, ultimately, is where we are now.
To kick things off: In the past, there had been requests to move the source to Github in the hopes of creating an easier onramp for patch submissions via PRs, bug reports, and the like. While I personally feel like SF and svn would still work, I think this probably deserves to be back on the table.
In addition, Henrik had mentioned that we'll need a mailing list migration at some point coming up soon.
Beyond that, to be honest I'm not sure what the next, best step is to take. Life had indeed gotten in the way, to follow from the comment below, as $dayjob+=4 and other responsibilities cropped up.
I really welcome the entire community's input here going forward.
Regards, J.C. Cleaver
On Mon, August 14, 2023 09:58, Bruno Manzoni wrote:
Hellor Xymon Lovers I'm not a coder either, but I see there's quite a bit of brains out there (and I think if there are enough of us we can try to maintain and improve it). Perhaps the current officials could first tell us what their plans are and how we could help them. On our side, we can perhaps encourage them: it would be good to list what we can bring to the project, as some have done! - I try to maintain "devmon" (on the github repo) and some other xymon tool (I did try to understand how devmon is integrate to xymon, but I am not an expert in Xymon code) - I am a telecom engineer - I can give some some time - I am an independent and I have some infra to play with - Usually I speak swiss-french (so sorry for all my mistakes) Bruno
On 14.08.2023 18:36, James Louis wrote:
Is the Terabithia RPM also dead?
Jim
On Mon, Aug 14, 2023 at 10:03???AM Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com> wrote:
I would be OK with contributing some as well???. But that???s notwhat Xymon needs.? Xymon needs caretaker(s) to keep it relevant.? That means code updates to fix bugs, adapt it to new OS versions, etc.? Otherwise it will fade away to obscurity like many other open source projects.? I???m not a coder either, or I would gladly give some time to it.
*Scot Kreienkamp? | Senior Linux Systems Engineer | La-Z-BoyCorporate* One La-Z-Boy Drive | Monroe, Michigan 48162 |( (734) 384-6403 | | ) 1-734-915-1444 | Email: Scot.Kreienkamp at la-z-boy.com
*From:* Rod <rodbass63 at gmail.com> *Sent:* Monday, August 14, 2023 10:56 AM *To:* Ralph M <ralphmitchell at gmail.com> *Cc:* Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com>; xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* Re: [Xymon] Is this thing on? I would like to continue the legacy. I'm not a developer but I'm willing to pay for hosting space and the domain name to keep it going for as long as I'm alive. Its kept me employed for a longtime.
On Mon, Aug 14, 2023 at 10:32???AM Ralph M <ralphmitchell at gmail.com> wrote: I've been using Xymon at several different? employers since it was BigBrother owned by a couple of guys in Canada.? My current Senior VP wants Xymon to go away.? He hasn't actually told me that directly, but I've heard it via another channel.? We have SolarWinds on some machines, but I've never even seen the GUI for that.? We're also distributing Oracle Enterprise Manager (OEM) to a bunch of machines.? I don't know for sure, but I suspect a contracting company is whispering in my SVP's ear to sell support for OEM.? In the meantime, my Xymon server has 878 days uptime and they're still trying to figure out how to install and configure the OEM agents.? It's going to be tons of fun watching them try to replace all the little scripts I've written with OEM equivalents. @Cristoph - I don't know if I can use stunnel.? It's a military-related company and there are all kinds of restrictions that sometimes even make sense. Ralph Mitchell On Mon, Aug 14, 2023 at 9:41???AM Scot Kreienkamp <Scot.Kreienkamp at la-z-boy.com> wrote: No new release since 2019, no activity on the mailing list, I think it???s safe to say it???s flatlined.? Sad tosee it fade, I???ve been using it for a decade or more.
*Scot Kreienkamp? | Senior Linux Systems Engineer | La-Z-Boy Corporate* One La-Z-Boy Drive | Monroe, Michigan 48162|((734) 384-6403 | | )1-734-915-1444| *Scot.Kreienkamp at la-z-boy.com www.la-z-boy.com <http://www.la-z-boy.com>? | facebook.com/lazboy <http://facebook.com/lazboy>? ? | twitter.com/lazboy <http://twitter.com/lazboy>| youtube.com/lazboy <http://youtube.com/lazboy> Smaller LZB Only Logo for Sign.png *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of *Neil Simmonds *Sent:* Monday, August 14, 2023 5:29 AM *To:* xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* Re: [Xymon] Is this thing on? Is Xymon dying? No new release since 2019, There was a roadmap in 2015 that mention Versions 4.4 up to 5 but nothing seems to have moved on that. It feels like Xymon has become a static project that???s going to fade away. That would be a shame as I for one think it???s a great tool. *From:* Xymon <xymon-bounces at xymon.com> *On Behalf Of *Galen Johnson *Sent:* Sunday, August 13, 2023 3:01 AM *To:* xymon >> xymon at xymon.com <xymon at xymon.com> *Subject:* [Xymon] Is this thing on? *[CAUTION]*This is an external email. Do not click links or open any attachments unless you are sure they are safe. Nothing since May seems a bit suss. =G= Studio is a trading name of Studio Retail Trading Limited (Company no. 03994833), which is an introducer of credit not a lender. Studio Pay is provided by Frasers Group Financial Services Limited (Registered Company no. 00718151), which is authorised and regulated by the Financial Conduct Authority (FRN 311908) for consumer credit and general insurance and a member of the Finance and Leasing Association. Both companies are registered in England and their registered office is: Church Bridge House Henry Street Accrington BB5 4EE. *NOTE: This email and any information contained within or attached in a separate file is confidential and intended solely for the Individual to whom it is addressed. The information or data included is solely for the purpose indicated or previously agreed. Any information or data included with this e-mail remains the property of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. The recipient will refrain from utilising the information for any purpose other than that indicated and upon request will destroy the information and remove it from their records. Any views or opinions presented are solely those of the author and do not necessarily represent those of Studio Retail Trading Ltd or Frasers Group Financial Services Ltd. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. No warranties or assurances are made in relation to the safety and content of this e-mail and any attachments. No liability is accepted for any consequences arising from it. Studio Retail Trading Ltd and Frasers Group Financial Services Ltd reserve the right to monitor all e-mail communications through their internal and external networks. If you have received this email in error please let us know. You can find our available contact details by going to help.studio.co.uk <http://help.studio.co.uk> and clicking ???Contact Us???.* This message is intended only for the individual or entity to which it is addressed. It may contain privileged, confidential information which is exempt from disclosure under applicable laws. If you are not the intended recipient, you are strictly prohibited from disseminating or distributing this information (other than to the intended recipient) or copying this information. If you have received this communication in error, please notify us immediately by e-mail or by telephone at the above number. Thank you.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon-- *Jim Louis
? ? ? ? ? \\\\||//// ? ? ? ? ? \ ~ ~? / ? ? ? ? ? | @ @ | * *--oOo---(_)---oOo--
/???The part of life we really live is small. All the rest is not life, but merely time.?? /
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
---------- Forwarded message ---------- From: Damien Martins via Xymon <xymon at xymon.com> To: "J.C. Cleaver" <cleaver at terabithia.org> Cc: Damien via Xymon <xymon at xymon.com> Bcc: Date: Tue, 15 Aug 2023 00:38:28 +0200 Subject: Re: [Xymon] Xymon, community, updates, and directions (was Re: Is this thing on?)
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Mon, August 14, 2023 19:55, Jeremy Laidman wrote:
I agree with others on the need for SSL/TLS these days, or at least some form of encryption. Many organisations now require comms to be encrypted, or at least authenticated, using robust, modern cryptography. In my case, we're periodically asked about our comms, and receive raised eyebrows when we respond.
I am also sympathetic to the notion that if we have to rely on encryption on our network, then we have bigger problems. But there are still reasons why encryption is desirable. For example, when monitoring a device connected via someone else's network. Or even just to slow down an attacker that has made her way onto our network, and perhaps even set off alarm bells when she tries to talk BB in cleartext and without authenticating, with the attempts generating log messages. Another way to view it is, "perfect is the enemy of good". I'd prefer to have encryption and authentication on a network that has an APT ferreting around, than not.
I tend to agree with this as well. Although the interaction is what it is, having anything unencrypted on networks can be a red flag and a barrier to implementation.
The work-arounds are not ideal for a few reasons. But I suspect the main one is that there is no consistent and standardised workaround, that every deployment that requires it tends to use. If everyone simply used the stunnel solution, then it would end up being well supported by the community, with lots of help, documented experiences, how-tos and best practice guides. But I find myself not wanting to make a poor choice, so I haven't made any choice. I suspect the stunnel option is probably the best option, but I have a feeling there will be a performance impact.
Indeed. Performance comes into play with all the options here.
- Setup and teardown for small TCP connections hitting xymond directly
- Signing and authenticating messages received asynchronously (combo messages, xymonproxy, or messages read in from the BFQ), which should be tossed if invalid
As it currently stands, xymon is already very efficient, so it's worth pointing out that the complexity really doesn't have to come in until you start hitting things at scale. If you're on a modern core and handling 90 msg/s, xymond is going to be just fine. If you're trying to push 9000 msg/s, more needs to be taken into consideration.
Furthermore, ensuring that one-way messages are submitted asynchronously to the daemon means that SSL termination and/or authentication can still pretty easily be off-loaded architecturally, even while SSL features are still in development. (HTTPS message submission in particular, with apache handling the ugly part.)
I think a community solution and best practices can be drawn up, but it probably calls for something of a working group among those who are pushing the limits now (or still) and have already worked through some of the kinks in their SSL implementation.
(Memories of stunnel-wrapping qmail-smtpd coming into play here...)
Not wanting to de-rail the conversation, the main point is that encryption/authentication is an important factor for me, and the missing feature is present in alternatives to Xymon. Some of the proposed alternatives are inadequate, but are still given credence due to the ticking the "security" boxes. If Xymon had this one feature built-in (or standardised), and had the occasional bug fix, then it would be treated with much less scepticism.
Agreed.
-jc
On 17/08/2023 19:21, J.C. Cleaver wrote:
As it currently stands, xymon is already very efficient, so it's worth pointing out that the complexity really doesn't have to come in until you start hitting things at scale. If you're on a modern core and handling 90 msg/s, xymond is going to be just fine. If you're trying to push 9000 msg/s, more needs to be taken into consideration.
We see about ~100 msgs / second and CPU load on xymond has never even crossed our radar (we run xymond on a relatively low-spec VM with a single virtual CPU)
The place where we have historically encountered performance-related issues was writing data to rrd files. We have a lot of custom tests and like being able to store and graph numerical data. My colleague thus implemented a custom xymond_channel listener which lets us take all our custom messages that come in a whole range of different formats, parse the messages to extract the numerical fields we're interested in, and then store them in a postgresql backend database rather than rrd files. This did also mean a moderate amount of custom development work for the web frontend (including some external js libs to draw graphs) to extract the data from the backend.
That wouldn't have been possible without the xymond_channel architecture along with the simple and well-defined format of the xymon messages themselves.
Adam
On Fri, August 18, 2023 01:31, Adam Thorn wrote:
On 17/08/2023 19:21, J.C. Cleaver wrote:
As it currently stands, xymon is already very efficient, so it's worth pointing out that the complexity really doesn't have to come in until you start hitting things at scale. If you're on a modern core and handling 90 msg/s, xymond is going to be just fine. If you're trying to push 9000 msg/s, more needs to be taken into consideration.
We see about ~100 msgs / second and CPU load on xymond has never even crossed our radar (we run xymond on a relatively low-spec VM with a single virtual CPU)
The place where we have historically encountered performance-related issues was writing data to rrd files. We have a lot of custom tests and like being able to store and graph numerical data. My colleague thus implemented a custom xymond_channel listener which lets us take all our custom messages that come in a whole range of different formats, parse the messages to extract the numerical fields we're interested in, and then store them in a postgresql backend database rather than rrd files. This did also mean a moderate amount of custom development work for the web frontend (including some external js libs to draw graphs) to extract the data from the backend.
That wouldn't have been possible without the xymond_channel architecture along with the simple and well-defined format of the xymon messages themselves.
Agreed. The simplicity of a streaming pipe of well-defined ASCII messages combined with a bus architecture makes it incredibly easy to extend or (in larger orgs) spew data out to another team to process in whatever manner they see fit.
We had a bigdata team that wanted to do multi-dimensional analysis on "metrics" and a data/DS feed into their cluster via xymond_channel solved the problem completely. Often the only sticking point is that xymond_channel's recipient needs to be able to handle the quantity of data that's coming at it efficiently. The SysV IPC for registered channel listeners flagging their message as taken is one of the very few pinch points in the system.
-jc
participants (4)
-
alt36＠cam.ac.uk
-
cleaver＠terabithia.org
-
jeremy＠laidman.org
-
josh＠imaginenetworksllc.com