Hello, I had started implementing Xymon on a few machines to see if I could get it to work (I haven't touched Linux in almost 5 years). Now upper management is expressing concerns that Xymon is dead because the newest version is from 2019, and the documentation is even older.
Does this project still have a team behind it? Or has it been left "as is"?
Best Regards Daniel
CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.
Xymon is very much alive and works so well it needs few updates... Although It needs a little known subsystem, SNMP, to be better documented.
On 6/8/21 6:30 AM, Daniel-- Ciesielski wrote:
Hello,
I had started implementing Xymon on a few machines to see if I could get it to work (I haven?t touched Linux in almost 5 years).
Now upper management is expressing concerns that Xymon is dead because the newest version is from 2019, and the documentation is even older.
Does this project still have a team behind it? Or has it been left ?as is??
Best Regards
Daniel
CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
An HTML attachment was scrubbed... URL: <http://lists.xymon.com/pipermail/xymon/attachments/20210608/b1dd6999/attachment.htm>
Zabbix has it's own set of technical setup/operations hurdles and gotchas. While the possibility of outsourcing support for Zabbix is there...
I'd point out the lesson of Solarwinds... Having someone else to blame MAY leave you blind and open to catastrophe while feeling safe and secure until you've fallen off the cliff.
Xymon since it's earliest days, has followed a KISS (keep it simple stupid) principal.? Less to break that way.
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available.? The second "worst" thing is editing text files to configure it.? There have been configuration tools attempted, but to my knowledge, really gone nowhere.
On 6/8/21 10:26 AM, Malcolm Hunter wrote:
It does the job, but administration is quite technical. It?s saved our bacon many a time with various ?enterprise? monitoring solutions coming and going. Our upper management has been asking our team to look into using Zabbix instead, which ticks the zero cost of entry box but with the possibility of adding paid support.
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
*From: *Bruce Ferrell <mailto:bferrell at baywinds.org> *Sent: *08 June 2021 18:15 *To: *xymon at xymon.com <mailto:xymon at xymon.com> *Subject: *Re: [Xymon] Is Xymon Alive?
Xymon is very much alive and works so well it needs few updates... Although It needs a little known subsystem, SNMP, to be better documented.
On 6/8/21 6:30 AM, Daniel-- Ciesielski wrote:
Hello, I had started implementing Xymon on a few machines to see if I could get it to work (I haven?t touched Linux in almost 5 years). Now upper management is expressing concerns that Xymon is dead because the newest version is from 2019, and the documentation is even older. Does this project still have a team behind it? Or has it been left ?as is?? Best Regards Daniel CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com>http://lists.xymon.com/mailman/listinfo/xymon <http://lists.xymon.com/mailman/listinfo/xymon>
It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available.? The second "worst" thing is editing text files to configure it.? There have been configuration tools attempted, but to my knowledge, really gone nowhere.
I've been hoping for a fix for point A, encrypted communications, for some time. At one time it was going to be rolled into the next release.
Ralph Mitchell
On Tue, Jun 8, 2021 at 3:17 PM John Thurston <john.thurston at alaska.gov> wrote:
It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available. The second "worst" thing is editing text files to configure it. There have been configuration tools attempted, but to my knowledge, really gone nowhere.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Hi,
Point A can be fixed if you configure xymoncgimsg.cgi on the server. We have this in a password protected cgi-bin https location. We have curl and wget based drop-in replacement scripts for the native Xymon binary. The powershell windows clients also can use this to send data to the Xymon server.
So all data is encrypted and you need a username / password combo.
Stef
On 2021-06-08 21:28, Ralph M wrote:
I've been hoping for a fix for point A, encrypted communications, for some time.? At one time it was going to be rolled into the next release.
Ralph Mitchell
On Tue, Jun 8, 2021 at 3:17 PM John Thurston <john.thurston at alaska.gov <mailto:john.thurston at alaska.gov>> wrote:
It is worth noting that out of the box: A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution -- Do things because you should, not just because you can. John Thurston? ? 907-465-8591 John.Thurston at alaska.gov <mailto:John.Thurston at alaska.gov> Department of Administration State of Alaska On 6/8/2021 9:54 AM, Bruce Ferrell wrote: > The "worst", most technical thing I know about installing Xymon is > building from source (my preferred method), but just about any modern > Linux distro has binaries available.? The second "worst" thing is > editing text files to configure it.? There have been configuration tools > attempted, but to my knowledge, really gone nowhere. _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon <http://lists.xymon.com/mailman/listinfo/xymon>
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I am yet to investigate this? using stunnel System Monitoring with Xymon/Administration Guide - Wikibooks, open books for an open world<https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Hobbit(bb)/XyMon_port_1984_encryption_Using_Stunnel>
Alan Ford
From: Xymon <xymon-bounces at xymon.com> On Behalf Of Ralph M Sent: Wednesday, 9 June 2021 5:29 AM To: John Thurston <john.thurston at alaska.gov> Cc: xymon at xymon.com Subject: [EXT] Re: [Xymon] Is Xymon Alive?
I've been hoping for a fix for point A, encrypted communications, for some time. At one time it was going to be rolled into the next release.
Ralph Mitchell
On Tue, Jun 8, 2021 at 3:17 PM John Thurston <john.thurston at alaska.gov<mailto:john.thurston at alaska.gov>> wrote: It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov<mailto:John.Thurston at alaska.gov> Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available. The second "worst" thing is editing text files to configure it. There have been configuration tools attempted, but to my knowledge, really gone nowhere.
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
Note: This email, including any attachments, has been sent by AWP Australia Pty Ltd (ABN 52 097 227 177) trading as Allianz Global Assistance and is intended solely for the addressee. It is confidential, may contain personal information and may be subject to legal professional privilege. If you have received this by mistake, confidentiality and any legal privilege are not waived or lost and we ask that you contact the sender and delete and destroy this and any other copies. In relation to any lawful use you may make of the contents of this email, you must ensure that you comply with the Privacy Act (C'th) 1988 and you should note that the contents may be subject to copyright and therefore may not be reproduced, communicated or adapted without the express consent of the owner of the copyright. Allianz Global Assistance will not be liable in connection with any data corruption, delay, computer virus or unauthorised access, interception, or amendment to the contents of this email. If you no longer want to receive messages from us, please contact us at Allianz Global Assistance, PO Box 162 Toowong, Qld, 4066, ph +61 7 3305 7000.
Some of those are true... The Xymon server can tell the client to run something IF the client has been pre-configured for it. I've never seen a config that allowed sending code to the client (upgrades?) and I've been using Xymon and it's predecessor, Big Brother, since 2000.? Are you maybe referring to remote logfetch via ssh?
Out of the box, all of those "objections" for Xymon are true for Zabbix as well.
Zabbix needs a MySQL instance set up to make it run too.
Nagios is just plain "fussy" with the same objections to encryption and triple A.
I think we all know what happened when the "secure" labyrinth called Solarwinds was breached.
My point is that simple is good.? Simple is in your control.
Your point John?
On 6/8/21 12:17 PM, John Thurston wrote:
It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston??? 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available.? The second "worst" thing is editing text files to configure it.? There have been configuration tools attempted, but to my knowledge, really gone nowhere.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
There's a clientupdate option:
https://xymon.com/help/manpages/man1/clientupdate.1.html
I've never used it, but it would allow the server to send code updates.
Ralph Mitchell
On Tue, Jun 8, 2021 at 3:49 PM Bruce Ferrell <bferrell at baywinds.org> wrote:
Some of those are true... The Xymon server can tell the client to run something IF the client has been pre-configured for it. I've never seen a config that allowed sending code to the client (upgrades?) and I've been using Xymon and it's predecessor, Big Brother, since 2000. Are you maybe referring to remote logfetch via ssh?
Out of the box, all of those "objections" for Xymon are true for Zabbix as well.
Zabbix needs a MySQL instance set up to make it run too.
Nagios is just plain "fussy" with the same objections to encryption and triple A.
I think we all know what happened when the "secure" labyrinth called Solarwinds was breached.
My point is that simple is good. Simple is in your control.
Your point John?
On 6/8/21 12:17 PM, John Thurston wrote:
It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available. The second "worst" thing is editing text files to configure it. There have been configuration tools attempted, but to my knowledge, really gone nowhere.
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 6/8/2021 11:49 AM, Bruce Ferrell wrote:
? Are you maybe referring to remote logfetch via ssh?
I am referring to logfetch, which is part of the standard client package, and which does not default to -noexec (and which does not use ssh).
Per the man page: Logfetch can be requested to execute arbitrary commands to generate a list of log files to examine dynamically, but this can present a security risk in some environments. Set this option to prevent logfetch from executing requested commands
Let's pass arbitrary code, unencrypted across the network, for it to be run by a daemon on a remote machine. What could possibly go wrong? Why would anyone want to permit this? Do you still use 'telnet' for production job control?
My point is that simple is good.? Simple is in your control.
Your point John?
My point is that a 'simple solution' may not include some things which have become standard and expected between 1998 and 2021.
I still run Xymon, and have been running its predecessors since the late 90s. But this _is_ 2021. Encrypted network communication, or at least the _capability_ to encrypt network communication is pretty much normal. When my users come to me asking me to make Xymon do things for them, I must continually remind them of its 1990's roots, and clarify which of their base assumptions may not be valid.
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
Yes, john, you're right... Things have changed on 20 years. But even 20 years ago capable admins only exposed what needed to be exposed. Some exposed everything to the raw internet.? Did you do that then? ? I know I don't now and never did.? I knew better but some call me a control freak too.
Moving on, let's ACTUALLY LOOK at the logfetch man page, shall we?
*logfetch* is part of the Xymon client. It is responsible for collecting data from logfiles, and other file-related data, which is then sent to the Xymon server for analysis.
logfetch uses a configuration file, which is automatically retrieved from the Xymon server. There is no configuration done locally.
??? So... It has to be configured... FROM the server and it comes with this warning:
Do *NOT* install logfetch as suid-root.
There is no way that logfetch can check whether the configuration file it uses has been tampered with, so installing logfetch with suid-root privileges could allow an attacker to read any file on the system by using a hand-crafted configuration file.
In fact, logfetch will attempt to remove its own suid-root setup if it detects that it has been installed suid-root.
While you point out that out of the box it's not configured --noexec... Out of the box, it's not configured at all!
So it's kind of up to the admin to:
a.) Actually turn it on
and
b.) Assure it's been secured for noexec... It already makes an attempt to protect itself from suid stuff if it can and thereby protect against arbitrary commands.
But that kind of applies to any installation doesn't it?? And I know I get kind of testy when someone who doesn't know my system attempts to override my management.
On 6/8/21 1:12 PM, John Thurston wrote:
On 6/8/2021 11:49 AM, Bruce Ferrell wrote:
? Are you maybe referring to remote logfetch via ssh?
I am referring to logfetch, which is part of the standard client package, and which does not default to -noexec (and which does not use ssh).
Per the man page: Logfetch can be requested to execute arbitrary commands to generate a list of log files to examine dynamically, but this can present a security risk in some environments. Set this option to prevent logfetch from executing requested commands
Let's pass arbitrary code, unencrypted across the network, for it to be run by a daemon on a remote machine. What could possibly go wrong? Why would anyone want to permit this? Do you still use 'telnet' for production job control?
My point is that simple is good.? Simple is in your control.
Your point John?
My point is that a 'simple solution' may not include some things which have become standard and expected between 1998 and 2021.
I still run Xymon, and have been running its predecessors since the late 90s. But this _is_ 2021. Encrypted network communication, or at least the _capability_ to encrypt network communication is pretty much normal. When my users come to me asking me to make Xymon do things for them, I must continually remind them of its 1990's roots, and clarify which of their base assumptions may not be valid.
-- Do things because you should, not just because you can.
John Thurston??? 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I am using git and a task on the xymon client to do a git pull.. It has a tasks.cfg file and the folder for the scripts
-----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of Bruce Ferrell Sent: Wednesday, 9 June 2021 5:49 AM To: xymon at xymon.com Subject: [EXT] Re: [Xymon] Is Xymon Alive?
Some of those are true... The Xymon server can tell the client to run something IF the client has been pre-configured for it. I've never seen a config that allowed sending code to the client (upgrades?) and I've been using Xymon and it's predecessor, Big Brother, since 2000. Are you maybe referring to remote logfetch via ssh?
Out of the box, all of those "objections" for Xymon are true for Zabbix as well.
Zabbix needs a MySQL instance set up to make it run too.
Nagios is just plain "fussy" with the same objections to encryption and triple A.
I think we all know what happened when the "secure" labyrinth called Solarwinds was breached.
My point is that simple is good. Simple is in your control.
Your point John?
On 6/8/21 12:17 PM, John Thurston wrote:
It is worth noting that out of the box:
A) the Xymon client <> server communication channel is unencrypted TCP B) there is neither authentication or authorization of that channel C) any client may send valid messages for any hostname D) the Xymon server may send arbitrary code to the client for execution
-- Do things because you should, not just because you can.
John Thurston 907-465-8591 John.Thurston at alaska.gov Department of Administration State of Alaska
On 6/8/2021 9:54 AM, Bruce Ferrell wrote:
The "worst", most technical thing I know about installing Xymon is building from source (my preferred method), but just about any modern Linux distro has binaries available. The second "worst" thing is editing text files to configure it. There have been configuration tools attempted, but to my knowledge, really gone nowhere.
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
Note: This email, including any attachments, has been sent by AWP Australia Pty Ltd (ABN 52 097 227 177) trading as Allianz Global Assistance and is intended solely for the addressee. It is confidential, may contain personal information and may be subject to legal professional privilege. If you have received this by mistake, confidentiality and any legal privilege are not waived or lost and we ask that you contact the sender and delete and destroy this and any other copies. In relation to any lawful use you may make of the contents of this email, you must ensure that you comply with the Privacy Act (C'th) 1988 and you should note that the contents may be subject to copyright and therefore may not be reproduced, communicated or adapted without the express consent of the owner of the copyright. Allianz Global Assistance will not be liable in connection with any data corruption, delay, computer virus or unauthorised access, interception, or amendment to the contents of this email. If you no longer want to receive messages from us, please contact us at Allianz Global Assistance, PO Box 162 Toowong, Qld, 4066, ph +61 7 3305 7000.
participants (7)
-
aford＠allianz-assistance.com.au
-
bferrell＠baywinds.org
-
Daniel.Ciesielski＠airboss.com
-
john.thurston＠alaska.gov
-
malcolm.r.hunter＠gmail.com
-
ralphmitchell＠gmail.com
-
stef.coene＠docum.org