Is the xymon Dead? Future
Hello, I'm working on a company that uses xymon for almost the beggining.
We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.
But, we are afraid mainly cause the last update whore on 2017, and we don't know for how long it will be compatible with clients.
So, my questions are, what's next? There's something going on with the project? It'll someday gain an MYSQL historic ?
Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.
On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br> wrote:
Hello, I'm working on a company that uses xymon for almost the beggining.
We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.
But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.
So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?
Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
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>
The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta.
Att, [cid:image001.png at 01D4D589.53709530]
De: Richard L. Hamilton <rlhamil2 at gmail.com> Enviada em: quinta-feira, 7 de março de 2019 17:54 Para: Felipe Ribeiro <felipe at redix.com.br> Cc: Ian Diddams via Xymon <xymon at xymon.com> Assunto: Re: [Xymon] Is the xymon Dead? Future
You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.
On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br<mailto:felipe at redix.com.br>> wrote:
Hello, I'm working on a company that uses xymon for almost the beggining.
We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.
But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.
So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?
Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
The lack of releases (and commits - there are commits after the last release, but only 2) on the *nix side is concerning. IPv6 support may have been something that people thought would be needed, and then wasn't so much in demand, but I think that demand would be there if Xymon had good support for Docker container monitoring. With the increasing use of Docker, Xymon needs to be able monitor Docker containers or it will die a slow death (and it may already be too late).
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. 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. (There is an unofficial sync project to sync a lot of SVN projects to GitHub but the project has recently closed: https://github.com/svn2github/xymon)
Kind regards,
SebA
On Fri, 8 Mar 2019 at 12:02, Felipe Ribeiro <felipe at redix.com.br> wrote:
The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta.
Att,
*De:* Richard L. Hamilton <rlhamil2 at gmail.com> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <felipe at redix.com.br> *Cc:* Ian Diddams via Xymon <xymon at xymon.com> *Assunto:* Re: [Xymon] Is the xymon Dead? Future
You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.
On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br> wrote:
Hello,
I'm working on a company that uses xymon for almost the beggining.
We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.
But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.
So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?
Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
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
Hello All,
I agree with SebA on this issue. I count on Xymon and it has proven itself many times over. But there needs to be seen a roadmap. I get comments about Xymon being so 80's but I answer back with how Xymon gets the job done. But we are in seriously changing times with so much being done in the virtual, containerized and micro-kernel areas. There is an array of "cloud" hosting options. Maybe a discussion is needed on what Xymon will do and will not do in the future.
On Fri, Mar 8, 2019 at 6:11 AM SebA <spah at syntec.co.uk> wrote:
The lack of releases (and commits - there are commits after the last release, but only 2) on the *nix side is concerning. IPv6 support may have been something that people thought would be needed, and then wasn't so much in demand, but I think that demand would be there if Xymon had good support for Docker container monitoring. With the increasing use of Docker, Xymon needs to be able monitor Docker containers or it will die a slow death (and it may already be too late).
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. 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. (There is an unofficial sync project to sync a lot of SVN projects to GitHub but the project has recently closed: https://github.com/svn2github/xymon)
Kind regards,
SebA
On Fri, 8 Mar 2019 at 12:02, Felipe Ribeiro <felipe at redix.com.br> wrote:
The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta.
Att,
*De:* Richard L. Hamilton <rlhamil2 at gmail.com> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <felipe at redix.com.br> *Cc:* Ian Diddams via Xymon <xymon at xymon.com> *Assunto:* Re: [Xymon] Is the xymon Dead? Future
You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.
On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br> wrote:
Hello,
I'm working on a company that uses xymon for almost the beggining.
We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.
But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.
So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?
Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
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--*
“It does me no injury for my neighbor to say there are twenty gods, or no God. It neither picks my pocket nor breaks my leg.”
~ Thomas Jefferson
I think a larger discussion on Xymon's roadmap in terms of Docker and container analysis is definitely something warranted. A host-based approach tends to invite individualized responses to coordination among varying levels of architecture (including both host -> hypervisor, baremetal (eg, DRAC) -> host, and hypervisor "status" reporting), but containers' typically ephemeral nature could merit a distinct reference point -- or not, if it's desired to have them persistently reportable. Host-Svc may or may not make sense there.
I tend to agree that a move to Github may be helpful here at this point
- athough with the various community issues people have had with GH since MS's purchase, it seems there has been a bit of an outcry, I'm not sure there's much SF will end up being able to capitalize on. It would certainly make PR's easier to coordinate and invite more interaction.
The largest stalling point on the roadmap here was indeed the IPv6 transition. I think things are releasable in an Alpha state, and that was the intent at the last release, but it's been difficult to find any site using IPv6 at sufficient scale who could help with the testing process. That's a bit of a Catch-22 though, and perhaps it would be best to release an easy reference point for future testing and go from there
- along with the various other patches that I've received. (And this does raise the question of what the next highest priorities out there will be.)
Regards, -jc
On 3/8/2019 4:39 AM, James Louis wrote:
Hello All,
I agree with SebA on this issue. I count on Xymon and it has proven itself many times over. But there needs to be seen a roadmap. I get comments about Xymon being so 80's but I answer back with how Xymon gets the job done. But we are in seriously changing times with so much being done in the virtual, containerized and micro-kernel areas. There is an array of "cloud" hosting options. Maybe a discussion is needed on what Xymon will do and will not do in the future.
On Fri, Mar 8, 2019 at 6:11 AM SebA <spah at syntec.co.uk <mailto:spah at syntec.co.uk>> wrote:
The lack of releases (and commits - there are commits after the last release, but only 2) on the *nix side is concerning. IPv6 support may have been something that people thought would be needed, and then wasn't so much in demand, but I think that demand would be there if Xymon had good support for Docker container monitoring. With the increasing use of Docker, Xymon needs to be able monitor Docker containers or it will die a slow death (and it may already be too late). Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. 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. (There is an unofficial sync project to sync a lot of SVN projects to GitHub but the project has recently closed: https://github.com/svn2github/xymon) Kind regards, SebA On Fri, 8 Mar 2019 at 12:02, Felipe Ribeiro <felipe at redix.com.br <mailto:felipe at redix.com.br>> wrote: The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta. Att, *De:* Richard L. Hamilton <rlhamil2 at gmail.com <mailto:rlhamil2 at gmail.com>> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <felipe at redix.com.br <mailto:felipe at redix.com.br>> *Cc:* Ian Diddams via Xymon <xymon at xymon.com <mailto:xymon at xymon.com>> *Assunto:* Re: [Xymon] Is the xymon Dead? Future You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made. On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br <mailto:felipe at redix.com.br>> wrote: Hello, I'm working on a company that uses xymon for almost the beggining. We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors. But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients. So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ? Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. 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.
Personally, I would agree with this. I have not used SVN, but I found using github so much easier than CVS. The current Xymon developers should maintain control of the code, but github would allow the community to report issues, provide updates/patches via pull requests, and download either released versions via the tags if necessary or the latest code via the 'develop' (or whatever) branch.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.
I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
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.
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.
but github would allow the community to report issues,
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: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests,
Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags
Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch.
https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
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-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
I'd still like to see encrypted connections for Xymon client messages going to the server.
Ralph Mitchell
On Fri, Mar 8, 2019, 10:09 AM Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.
I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
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.
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.
but github would allow the community to report issues,
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: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests,
Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags
Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch.
https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
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-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I believe this one is in the pipe for version 4.4 but could be wrong.
JP Pitout
From: Xymon <xymon-bounces at xymon.com> on behalf of Ralph Mitchell <ralphmitchell at gmail.com> Sent: 08 March 2019 17:40 To: Axel Beckert Cc: xymon at xymon.com Subject: Re: [Xymon] RES: Is the xymon Dead? Future
I'd still like to see encrypted connections for Xymon client messages going to the server.
Ralph Mitchell
On Fri, Mar 8, 2019, 10:09 AM Axel Beckert <abe at deuxchevaux.org<mailto:abe at deuxchevaux.org>> wrote: Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.
I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
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.
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.
but github would allow the community to report issues,
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: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests,
Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags
Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch.
https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
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-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org<mailto:abe at deuxchevaux.org> \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org<mailto:abe at noone.org> X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
"This email is confidential. If you have received it in error, you are on notice of its status. Please notify us immediately by reply email and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person as to do so could be a breach of confidentiality. Thank you for your co-operation. "
"The information contained in this message is intended solely for the individual to whom it is specifically and originally addressed. This message and its contents may contain confidential or privileged information from MTN Group. If you are not the intended recipient, you are hereby notified that any disclosure or distribution, is strictly prohibited. If you receive this email in error, please notify MTN Group immediately and delete it. MTN Group does not accept any liability or responsibility if action is taken in reliance on the contents of this information . Note that all personal emails are not authorized by MTN Group. "
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client messages going to the server.
Yeah, this definitely is a feature which would be very nice to available out of the box.
Nevertheless you can do that already now with stunnel as I mentioned:
(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.)
Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.
It also refers to this more detailed documentation: https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...
HTH!
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.
On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client messages going to the server.
Yeah, this definitely is a feature which would be very nice to available out of the box.
Nevertheless you can do that already now with stunnel as I mentioned:
(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.)
Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.
It also refers to this more detailed documentation: https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...
HTH!
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.
On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client messages going to the server. Yeah, this definitely is a feature which would be very nice to available out of the box.
Nevertheless you can do that already now with stunnel as I mentioned:
(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.) Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.
It also refers to this more detailed documentation: https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...
HTH!
Kind regards, Axel
I just make sure I have a VPN or a private LAN between whatever machine runs the xymon client and the xymon server.
On Fri, 8 Mar 2019, Bruce Ferrell wrote:
Date: Fri, 8 Mar 2019 18:10:15 -0800 From: Bruce Ferrell <bferrell at baywinds.org> To: xymon at xymon.com Subject: Re: [Xymon] Encrypted Xymon reporting over SSL using stunnel
I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.
On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client messages going to the server. Yeah, this definitely is a feature which would be very nice to available out of the box.
Nevertheless you can do that already now with stunnel as I mentioned:
(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.) Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.
It also refers to this more detailed documentation:
https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...
HTH!
Kind regards, Axel
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org> wrote:
I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.
On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
I'd still like to see encrypted connections for Xymon client messages going to the server. Yeah, this definitely is a feature which would be very nice to available out of the box.
Nevertheless you can do that already now with stunnel as I mentioned:
(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.) Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.
The current version can be found in our packaging git repository at
https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.
It also refers to this more detailed documentation:
https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...
HTH!
Kind regards, Axel
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
SebA,
You're right, saltstack is doing the same as using ssh keys.... For all intents and purposes an ssh connection/tunnel or an stunnel.
No need to build that into xymon. Just do it externally and call it a day. And it still has the key distribution/management issue.
That said, if/when tunnels go down... And they do, then reporting is lost and intervention is often required.
The itch to "build in" what can be done outside, in my experience, should almost never be scratched.
It's too easy to make things over complicated for little to no pay off.
On 3/12/19 6:50 AM, SebA wrote:
The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone). From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility. Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided. > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote: >> >> Hi Ralph, >> >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: >>> I'd still like to see encrypted connections for Xymon client messages going >>> to the server. >> Yeah, this definitely is a feature which would be very nice to >> available out of the box. >> >> Nevertheless you can do that already now with stunnel as I mentioned: >> >>>> (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.) >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption >> with hints how to implement encrypted reporting with Xymon. >> >> The current version can be found in our packaging git repository at >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> as I >> wrote it in Markdown syntax. >> >> It also refers to this more detailed documentation: >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling >> >> HTH! >> >> Kind regards, Axel _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
Right, but I think it's easier and more reliable when it is integrated, and you can add it to the feature list: 'secure client-server communication'. That's a selling point and it's something people will look for in a monitoring system. If it involves other software like stunnel or a VPN, you can't put it on the feature list.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:00, Bruce Ferrell <bferrell at baywinds.org> wrote:
SebA,
You're right, saltstack is doing the same as using ssh keys.... For all intents and purposes an ssh connection/tunnel or an stunnel.
No need to build that into xymon. Just do it externally and call it a day. And it still has the key distribution/management issue.
That said, if/when tunnels go down... And they do, then reporting is lost and intervention is often required.
The itch to "build in" what can be done outside, in my experience, should almost never be scratched.
It's too easy to make things over complicated for little to no pay off.
On 3/12/19 6:50 AM, SebA wrote:
The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
I'm not sure which standard is in use here, so I'll just top postlike Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff startsbreaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, noone even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it fromme, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear yousay... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
Some form of message authentication is probably a good idea though.Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > In the ideal, esp. when the client may have a dynamic IP address(DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided. > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote: >> >> Hi Ralph, >> >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: >>> I'd still like to see encrypted connections for Xymon client messages going >>> to the server. >> Yeah, this definitely is a feature which would be very nice to >> available out of the box. >> >> Nevertheless you can do that already now with stunnel as I mentioned: >> >>>> (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.) >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption >> with hints how to implement encrypted reporting with Xymon. >> >> The current version can be found in our packaging git repository at >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption >> although I'm thinking about renaming it to README.encryption.md < http://README.encryption.md> as I >> wrote it in Markdown syntax. >> >> It also refers to this more detailed documentation: >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... >> >> HTH! >> >> Kind regards, Axel
_______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but thats' never stopped anyone).
Taking me back to "do it outside of xymon" for cleanliness sake.
On 3/12/19 6:50 AM, SebA wrote:
The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone). From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility. Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided. > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote: >> >> Hi Ralph, >> >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: >>> I'd still like to see encrypted connections for Xymon client messages going >>> to the server. >> Yeah, this definitely is a feature which would be very nice to >> available out of the box. >> >> Nevertheless you can do that already now with stunnel as I mentioned: >> >>>> (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.) >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption >> with hints how to implement encrypted reporting with Xymon. >> >> The current version can be found in our packaging git repository at >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> as I >> wrote it in Markdown syntax. >> >> It also refers to this more detailed documentation: >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling >> >> HTH! >> >> Kind regards, Axel _______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
There is a commercial version, but this code is open source: https://github.com/saltstack/salt I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache licence.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org> wrote:
...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but thats' never stopped anyone).
Taking me back to "do it outside of xymon" for cleanliness sake.
On 3/12/19 6:50 AM, SebA wrote:
The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
I'm not sure which standard is in use here, so I'll just top postlike Richard did. Please don't shoot me.
People always go for certs... And then they expire and stuff startsbreaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By that time, noone even remembers that certs were even installed or what they're for. As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness, take it fromme, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I hear yousay... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
Some form of message authentication is probably a good idea though.Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > In the ideal, esp. when the client may have a dynamic IP address(DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided. > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote: >> >> Hi Ralph, >> >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: >>> I'd still like to see encrypted connections for Xymon client messages going >>> to the server. >> Yeah, this definitely is a feature which would be very nice to >> available out of the box. >> >> Nevertheless you can do that already now with stunnel as I mentioned: >> >>>> (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.) >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption >> with hints how to implement encrypted reporting with Xymon. >> >> The current version can be found in our packaging git repository at >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption >> although I'm thinking about renaming it to README.encryption.md < http://README.encryption.md> as I >> wrote it in Markdown syntax. >> >> It also refers to this more detailed documentation: >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... >> >> HTH! >> >> Kind regards, Axel
_______________________________________________ Xymon mailing list Xymon at xymon.com <mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon
SebA
I think mentioned this in another thread. I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.
I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.
Using code from a commercial entity (even with an apache license) raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.
Integrating functionality that already exists through well understood, more general mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that). The difference in the codebase alone should cause someone to think very hard about that kind of merge.
Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!). MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!
Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple. It doesn't sign the updates but that could be a reasonable add-on to the documentation.
For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.
On 3/12/19 8:55 AM, SebA wrote:
There is a commercial version, but this code is open source: https://github.com/saltstack/salt I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache licence.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but thats' never stopped anyone). Taking me back to "do it outside of xymon" for cleanliness sake. On 3/12/19 6:50 AM, SebA wrote: > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, > so I couldn't tell you exactly how it works, but there's some information here: > https://docs.saltstack.com/en/getstarted/system/communication.html > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. > > Kind regards, > > SebA > > > > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote: > > > I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. > > > People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! > > For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right > before the big crash, IBG, UBG (I be gone, you be gone). > > From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. > > "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If > we do > care then we deny communication/ignore messages. Now we've lost reporting links and visibility. > > Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the > issue > of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? > > > > > On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the > client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that > assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from > elsewhere isn't being provided. > > > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>> wrote: > >> > >> Hi Ralph, > >> > >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: > >>> I'd still like to see encrypted connections for Xymon client messages going > >>> to the server. > >> Yeah, this definitely is a feature which would be very nice to > >> available out of the box. > >> > >> Nevertheless you can do that already now with stunnel as I mentioned: > >> > >>>> (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.) > >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption > >> with hints how to implement encrypted reporting with Xymon. > >> > >> The current version can be found in our packaging git repository at > >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption > >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> as I > >> wrote it in Markdown syntax. > >> > >> It also refers to this more detailed documentation: > >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling > >> > >> HTH! > >> > >> Kind regards, Axel > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> > http://lists.xymon.com/mailman/listinfo/xymon >
Hi Bruce,
Yes, I've been using the same since 2002 as well, but I disagree on the legal issue. The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it. Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!
Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well. I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open. Anyway, the key generation and encryption stuff is separate to the communication - Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org> wrote:
SebA
I think mentioned this in another thread. I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.
I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.
Using code from a commercial entity (even with an apache license) raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.
Integrating functionality that already exists through well understood, more general mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that). The difference in the codebase alone should cause someone to think very hard about that kind of merge.
Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!). MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!
Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple. It doesn't sign the updates but that could be a reasonable add-on to the documentation.
For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.
On 3/12/19 8:55 AM, SebA wrote:
There is a commercial version, but this code is open source: https://github.com/saltstack/salt I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache licence.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
...And looking even closer at saltstack, it's a commercial product,leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but thats' never stopped anyone).
Taking me back to "do it outside of xymon" for cleanliness sake. On 3/12/19 6:50 AM, SebA wrote: > The way Salt Minions authenticate and their keys have to beaccepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked at it, > so I couldn't tell you exactly how it works, but there's some information here: > https://docs.saltstack.com/en/getstarted/system/communication.html > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. > > Kind regards, > > SebA > > > > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto: bferrell at baywinds.org>>> wrote: > > > I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. > > > People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! > > For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry said right > before the big crash, IBG, UBG (I be gone, you be gone). > > From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. > > "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really? If > we do > care then we deny communication/ignore messages. Now we've lost reporting links and visibility. > > Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we get the > issue > of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? > > > > > On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the > client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that > assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from > elsewhere isn't being provided. > > > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto: abe at deuxchevaux.org>>> wrote: > >> > >> Hi Ralph, > >> > >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: > >>> I'd still like to see encrypted connections for Xymon client messages going > >>> to the server. > >> Yeah, this definitely is a feature which would be very nice to > >> available out of the box. > >> > >> Nevertheless you can do that already now with stunnel as I mentioned: > >> > >>>> (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.) > >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption > >> with hints how to implement encrypted reporting with Xymon. > >> > >> The current version can be found in our packaging git repository at > >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption > >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> < http://README.encryption.md> as I > >> wrote it in Markdown syntax. > >> > >> It also refers to this more detailed documentation: > >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... > >> > >> HTH! > >> > >> Kind regards, Axel > > _______________________________________________ > Xymon mailing list > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> > http://lists.xymon.com/mailman/listinfo/xymon >
SebA,
We agree on a lot, including the licenses. We do NOT agree on taking risks. Again, the concepts for secure transport ARE actually served in the good old, "pull from the client via ssh using keys" method, rather than the client push to the server. Yes, you DO actually have to do SOME setup for that to work. The fact that it's NOT well known isn't a good reason to add a LOT of additional code to xymon.
I've had to cope with WAY too many issues around Python to have ANY trust of it.
I've had to deal far too often with Python code that "works on your machine, but not on mine" WAY too may times then had experts look and say "I'll have dig into it for a day to figure out why it does that... It's not supposed to do that". It's not inherent in the language, but in practices around the language.
I can, and do code in it if I absolutely must, but avoid it when I can. Yes, many, many other people like that complicated things can be built with it quickly and I didn't mean this to become bike shed discussion around language.
The kinds of issues I spoke of give ME the heebie jeebies when it comes to tools I use regularly.
On 3/12/19 10:16 AM, SebA wrote:
Hi Bruce,
Yes, I've been using the same since 2002 as well, but I disagree on the legal issue. The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it. Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!
Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well. I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open. Anyway, the key generation and encryption stuff is separate to the communication - Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
SebA I think mentioned this in another thread. I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002. I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it. Using code from a commercial entity (even with an apache license) raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk. Integrating functionality that already exists through well understood, more general mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that). The difference in the codebase alone should cause someone to think very hard about that kind of merge. Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!). MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that! Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple. It doesn't sign the updates but that could be a reasonable add-on to the documentation. For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap. On 3/12/19 8:55 AM, SebA wrote: > There is a commercial version, but this code is open source: https://github.com/saltstack/salt > I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache > licence. > > Kind regards, > > SebA > > > > On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote: > > ...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but > thats' never stopped anyone). > > Taking me back to "do it outside of xymon" for cleanliness sake. > > > On 3/12/19 6:50 AM, SebA wrote: > > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked > at it, > > so I couldn't tell you exactly how it works, but there's some information here: > > https://docs.saltstack.com/en/getstarted/system/communication.html > > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. > > > > Kind regards, > > > > SebA > > > > > > > > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>>> wrote: > > > > > > I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. > > > > > > People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! > > > > For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry > said right > > before the big crash, IBG, UBG (I be gone, you be gone). > > > > From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. > > > > "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed > really? If > > we do > > care then we deny communication/ignore messages. Now we've lost reporting links and visibility. > > > > Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we > get the > > issue > > of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? > > > > > > > > > > On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > > > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good > if the > > client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that > > assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from > > elsewhere isn't being provided. > > > > > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>>> wrote: > > >> > > >> Hi Ralph, > > >> > > >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: > > >>> I'd still like to see encrypted connections for Xymon client messages going > > >>> to the server. > > >> Yeah, this definitely is a feature which would be very nice to > > >> available out of the box. > > >> > > >> Nevertheless you can do that already now with stunnel as I mentioned: > > >> > > >>>> (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.) > > >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption > > >> with hints how to implement encrypted reporting with Xymon. > > >> > > >> The current version can be found in our packaging git repository at > > >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption > > >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> <http://README.encryption.md> as I > > >> wrote it in Markdown syntax. > > >> > > >> It also refers to this more detailed documentation: > > >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling > > >> > > >> HTH! > > >> > > >> Kind regards, Axel > > > > _______________________________________________ > > Xymon mailing list > > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>>> > > http://lists.xymon.com/mailman/listinfo/xymon > > >
Yeah, I've come across issues to do with library package conflicts or incompatibilities with Python, just like with Perl and Ruby. Sometimes it's difficult to get all the right versions of packages. (The way SaltStack deal with this issue is to put the packages they use in their repo, but it can still mess up your system if you already had versions installed.) Let's just leave that point of discussion there.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:41, Bruce Ferrell <bferrell at baywinds.org> wrote:
SebA,
We agree on a lot, including the licenses. We do NOT agree on taking risks. Again, the concepts for secure transport ARE actually served in the good old, "pull from the client via ssh using keys" method, rather than the client push to the server. Yes, you DO actually have to do SOME setup for that to work. The fact that it's NOT well known isn't a good reason to add a LOT of additional code to xymon.
I've had to cope with WAY too many issues around Python to have ANY trust of it.
I've had to deal far too often with Python code that "works on your machine, but not on mine" WAY too may times then had experts look and say "I'll have dig into it for a day to figure out why it does that... It's not supposed to do that". It's not inherent in the language, but in practices around the language.
I can, and do code in it if I absolutely must, but avoid it when I can. Yes, many, many other people like that complicated things can be built with it quickly and I didn't mean this to become bike shed discussion around language.
The kinds of issues I spoke of give ME the heebie jeebies when it comes to tools I use regularly.
On 3/12/19 10:16 AM, SebA wrote:
Hi Bruce,
Yes, I've been using the same since 2002 as well, but I disagree on the legal issue. The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it. Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!
Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well. I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open. Anyway, the key generation and encryption stuff is separate to the communication - Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
SebA I think mentioned this in another thread. I've been usingBB/xymon/"that thing we can't say because an estate disliked it" since 2002.
I think many of us went through the demise of BB when Quest/Dell/EMCabsorbed/smothered it.
Using code from a commercial entity (even with an apache license)raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.
Integrating functionality that already exists through wellunderstood, more general mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that). The difference in the codebase alone should cause someone to think very hard about that kind of merge.
Looking more closely at SaltStack, I see it would add additiontransports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!). MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!
Maybe better documentation of secure message distribution? Thereused to be one on how to pull client updates via ssh. That's secure AND simple. It doesn't sign the updates but that could be a reasonable add-on to the documentation.
For this purpose, SaltStack looks to me like that old Milton Bradleyboard game Mouse Trap.
On 3/12/19 8:55 AM, SebA wrote: > There is a commercial version, but this code is open source:https://github.com/saltstack/salt > I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache > licence. > > Kind regards, > > SebA > > > > On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto: bferrell at baywinds.org>>> wrote: > > ...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but > thats' never stopped anyone). > > Taking me back to "do it outside of xymon" for cleanliness sake. > > > On 3/12/19 6:50 AM, SebA wrote: > > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked > at it, > > so I couldn't tell you exactly how it works, but there's some information here: > > https://docs.saltstack.com/en/getstarted/system/communication.html > > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. > > > > Kind regards, > > > > SebA > > > > > > > > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell < bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto: bferrell at baywinds.org <mailto:bferrell at baywinds.org>> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>>> wrote: > > > > > > I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. > > > > > > People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! > > > > For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry > said right > > before the big crash, IBG, UBG (I be gone, you be gone). > > > > From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. > > > > "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed > really? If > > we do > > care then we deny communication/ignore messages. Now we've lost reporting links and visibility. > > > > Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we > get the > > issue > > of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? > > > > > > > > > > On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > > > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good > if the > > client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that > > assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from > > elsewhere isn't being provided. > > > > > >> On Mar 8, 2019, at 11:09, Axel Beckert < abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto: abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto: abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>>> wrote: > > >> > > >> Hi Ralph, > > >> > > >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: > > >>> I'd still like to see encrypted connections for Xymon client messages going > > >>> to the server. > > >> Yeah, this definitely is a feature which would be very nice to > > >> available out of the box. > > >> > > >> Nevertheless you can do that already now with stunnel as I mentioned: > > >> > > >>>> (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.) > > >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption > > >> with hints how to implement encrypted reporting with Xymon. > > >> > > >> The current version can be found in our packaging git repository at > > >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption > > >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> < http://README.encryption.md> <http://README.encryption.md> as I > > >> wrote it in Markdown syntax. > > >> > > >> It also refers to this more detailed documentation: > > >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... > > >> > > >> HTH! > > >> > > >> Kind regards, Axel > > > > _______________________________________________ > > Xymon mailing list > > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto: Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto: Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>>> > > http://lists.xymon.com/mailman/listinfo/xymon > > >
I hate top-posting... but oh well, I'm too lazy to fix the below.
IMHO, when using "security" tools, we really need to make sure we rely on a third party "library" to do this, security/encryption is a fast moving area, and we really don't want to be using something 5 years old because nobody understood how to update it from TLS1.1 to TLS1.2 or from using 3DES to using AES or whatever the issue becomes. Also, xymon may not be updated as easily/quickly as what other system libraries might, so again, better to let the OS (system) provide the relevant tools to do this, and we just become another consumer.
As such, an obvious choice would be openssl, or something similar, where it is widely supported across many platforms, well maintained, and likely to be well maintained in the future.
I think there are two separate requirements when referring to encryption:
Encrypt the content so anyone listening can't see your log file contents, process list, and other info being sent back to xymon server. This could use SSH style encryption, where the server key stays the same "for life" and on each connection the server/client negotiate the encryption, this ensures the content is protected "in-transit".
Signature - ie, ensuring the message actually came from "one of my clients" or taking this further it came from "this specific client". In this case, we would need to create something specific to each server (to verify it came from any of our clients) or specific to each client (to verify it came from this specific client). Some ideas:
- Do we need full PGP security for this? At least during setup, we can easily start with a known good/clean connection, or rely on the admin to ensure that some "shared secret" is valid on both ends.
- We can already send data back to the client after the client successfully delivers data to the server. If the "current" data the client is sending is considered "clean/secure" then we can easily send back a renewed "certificate".
So... a) Start with a simple shared secret that the admin can create (or is auto-generated) on server install. b) The admin configures this secret onto each client that is added, along with adding the hostname to the server (xymon-hosts file). c) When the client connects to the server, it uses the SSH "encryption" to protect the conversation, sends the shared key plus the normal "1st set of data reports". The server responds with a client "certificate". d) When the client next connects to the server, it uses the SSH "encryption" to protect the conversation, and signs the data with the certificate it received from the server. If the certificate is due to expire in X days (configurable on server) then the server will provide an updated certificate to the client. The client can continue to use the "old" certificate until expiry, but should allow plenty of time to transition to the new one. In reality, this could be one or two days only, since most clients report every 5 mins.
Or... we could configure a shared secret in the xymon-hosts file for each client (different "password" for each client) and the client simply encrypts all data it returns with this shared secret. Advantage is "simplicity" disadvantage is much less secure.
Anyway, starting with an agreed "wish list" of functionality (signed or encrypted are two items), and then a protracted discussion on the best way to achieve it, and then we can start coding it. If we just leave it as a high level wish list, then it is always "too hard". Let's break it down into smaller steps. Also, even if we can't provide the functionality to satisfy everyone, at least we could provide functionality to satisfy some people (ie, do it the easy way first, and then it could be extended/upgraded/changed later if there really is a need as opposed to want).
Just my thoughts on this.
PS, as for IPv6, I am yet to see any decent level of support here, I tried to start using it years ago, and it just never happened. Turns my routers (Cisco Meraki: www.meraki.com details at https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...) still don't support IPv6 either, so it still doesn't seem to be as important as claimed by everyone 10+ years ago when they said we would run out of IPv4 addresses.... It's hard to "change the world", I mean, we still have SMTP and DNS ;)
Regards, Adam
On 13/3/19 4:41 am, Bruce Ferrell wrote:
SebA,
We agree on a lot, including the licenses. We do NOT agree on taking risks. Again, the concepts for secure transport ARE actually served in the good old, "pull from the client via ssh using keys" method, rather than the client push to the server. Yes, you DO actually have to do SOME setup for that to work. The fact that it's NOT well known isn't a good reason to add a LOT of additional code to xymon.
I've had to cope with WAY too many issues around Python to have ANY trust of it.
I've had to deal far too often with Python code that "works on your machine, but not on mine" WAY too may times then had experts look and say "I'll have dig into it for a day to figure out why it does that... It's not supposed to do that". It's not inherent in the language, but in practices around the language.
I can, and do code in it if I absolutely must, but avoid it when I can. Yes, many, many other people like that complicated things can be built with it quickly and I didn't mean this to become bike shed discussion around language.
The kinds of issues I spoke of give ME the heebie jeebies when it comes to tools I use regularly.
On 3/12/19 10:16 AM, SebA wrote:
Hi Bruce,
Yes, I've been using the same since 2002 as well, but I disagree on the legal issue. The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it. Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!
Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well. I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open. Anyway, the key generation and encryption stuff is separate to the communication
- Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:
SebA
I think mentioned this in another thread. I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.
I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.
Using code from a commercial entity (even with an apache license) raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.
Integrating functionality that already exists through well understood, more general mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that). The difference in the codebase alone should cause someone to think very hard about that kind of merge.
Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!). MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!
Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple. It doesn't sign the updates but that could be a reasonable add-on to the documentation.
For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.
On 3/12/19 8:55 AM, SebA wrote: > There is a commercial version, but this code is open source: https://github.com/saltstack/salt > I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering. It looks like it's using the Apache > licence. > > Kind regards, > > SebA > > > > On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote: > > ...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours! cross our palms with MUCH silver" (probably based on OSS, but > thats' never stopped anyone). > > Taking me back to "do it outside of xymon" for cleanliness sake. > > > On 3/12/19 6:50 AM, SebA wrote: > > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire. It's been a while since I looked > at it, > > so I couldn't tell you exactly how it works, but there's some information here: > > https://docs.saltstack.com/en/getstarted/system/communication.html > > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. > > > > Kind regards, > > > > SebA > > > > > > > > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>>> wrote: > > > > > > I'm not sure which standard is in use here, so I'll just top post like Richard did. Please don't shoot me. > > > > > > People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once. GACK! > > > > For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for. As the home loan industry > said right > > before the big crash, IBG, UBG (I be gone, you be gone). > > > > From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. > > > > "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed > really? If > > we do > > care then we deny communication/ignore messages. Now we've lost reporting links and visibility. > > > > Some form of message authentication is probably a good idea though. Just something that doesn't expire and can be revoked as needed. gpg/pgp keys maybe, but then we > get the > > issue > > of gpg/pgp key distribution/signing. Key per monitored system... Anyone want to manage THAT? > > > > > > > > > > On 3/8/19 11:28 AM, Richard L. Hamilton wrote: > > > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good > if the > > client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that > > assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from > > elsewhere isn't being provided. > > > > > >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>>> wrote: > > >> > > >> Hi Ralph, > > >> > > >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: > > >>> I'd still like to see encrypted connections for Xymon client messages going > > >>> to the server. > > >> Yeah, this definitely is a feature which would be very nice to > > >> available out of the box. > > >> > > >> Nevertheless you can do that already now with stunnel as I mentioned: > > >> > > >>>> (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.) > > >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption > > >> with hints how to implement encrypted reporting with Xymon. > > >> > > >> The current version can be found in our packaging git repository at > > >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption > > >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> <http://README.encryption.md> as I > > >> wrote it in Markdown syntax. > > >> > > >> It also refers to this more detailed documentation: > > >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... > > >> > > >> HTH! > > >> > > >> Kind regards, Axel > > > > _______________________________________________ > > Xymon mailing list > > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto: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
-- Adam Goryachev Website Managers www.websitemanagers.com.au
-- The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Viruses - Any loss/damage incurred by receiving this email is not the sender's responsibility.
On Wed, 13 Mar 2019 at 10:57, Adam Goryachev < mailinglists at websitemanagers.com.au> wrote:
IMHO, when using "security" tools, we really need to make sure we rely on a third party "library" to do this, security/encryption is a fast moving area, and we really don't want to be using something 5 years old because nobody understood how to update it from TLS1.1 to TLS1.2 or from using 3DES to using AES or whatever the issue becomes.
I'm not sure I agree that encryption is fast-moving in all areas, or even most of them. Yes, there are bugs found in encryption software, short-cuts found in brute-forcing hashes, new algorithms every now and then, and the occasional implementation problem (wep, wpa, ssl); all of these scenarios require some kind of upgrade. However, the math(s) behind the basic crypto primitives is fundamentally sound (well-vetted and in some cases proven), particularly around simple use cases. Even with deprecated hashes (MD5, SHA1) they're not considered insecure, just that a well-resourced, and highly motivated and patient actor can brute-force them in time. With careful selection of hashing, encipherment and session key management algorithms, a good, strong solution can be implemented using >20-year-old crypto.
However, there's other value in being able to use a separate library, and allow upgrades to the library to improve security or squash bugs, without having to recompile Xymon.
Also, xymon may not be updated as easily/quickly as what other system libraries might, so again, better to let the OS (system) provide the relevant tools to do this, and we just become another consumer.
Agreed.
As such, an obvious choice would be openssl, or something similar, where it is widely supported across many platforms, well maintained, and likely to be well maintained in the future.
Not to mention, OpenSSL is already used by Xymon for things like https checks.
I think there are two separate requirements when referring to encryption:
- Encrypt the content so anyone listening can't see your log file
Yep.
- Signature - ie, ensuring the message actually came from "one of my clients" or taking this further it came from "this specific client".
Yep.
And there are situations where only signing is required. This not only ensures no tampering, but it also ensures that a large message has not been truncated by some process. On some systems, I often get a red "procs" test because the [ps] or [netstat] sections were so long that the data message was truncated. I'd prefer to skip a truncated message entirely than to react to conclusions based on incomplete data, at least in this case. A [signature] section at the end of the message (or heck, even just an [end] section) and appropriate handling in xymond, would fix this.
Having encryption also gives us signing, and having signing also ensures no tampering. If encryption and signing aren't required, the overhead of managing keys makes it burdensome to detect truncated messages. But if we bake in encryption, we get everything. If we use x509 certificates, we get all of this, plus potentially PKI (federated trust, revocation, expiry). It's a hierarchy, and the higher up we go, the harder it is to implement (both in the code, and rolling it out to nodes), but the more features we get.
(As an aside I like the idea that an x509 certificate can be used to tie a client data message to an entry in hosts.cfg, either allowing the commonName field to override the value in the client data message, or having a "CN" tag in the hosts.cfg file to match the client message to.)
Also, key management needs to be considered. It's a different task to encrypt traffic between a xymonproxy server and xymond server, to rolling out encryption to 500 devices each running a Xymon client.
- Do we need full PGP security for this? At least during setup, we can
easily start with a known good/clean connection, or rely on the admin to ensure that some "shared secret" is valid on both ends.
So, like bootstrapping the key rollout procedure. This could leverage the existing "download" client message type. The client should know when her certificate is soon to expire, and can just ask for a new one with: "xymon download /meta/clientcert.x509" and the xymond process could sign a new cert on-the-fly and send it down the wire.
- We can already send data back to the client after the client successfully delivers data to the server. If the "current" data the client is sending is considered "clean/secure" then we can easily send back a renewed "certificate".
Yep, that's another option.
So...
a) Start with a simple shared secret that the admin can create (or is auto-generated) on server install. b) The admin configures this secret onto each client that is added, along with adding the hostname to the server (xymon-hosts file).
b1) admin configures ssh public key on client
c) When the client connects to the server, it uses the SSH "encryption"
to protect the conversation, sends the shared key plus the normal "1st set of data reports". The server responds with a client "certificate". d) When the client next connects to the server, it uses the SSH "encryption" to protect the conversation, and signs the data with the certificate it received from the server. If the certificate is due to expire in X days (configurable on server) then the server will provide an updated certificate to the client. The client can continue to use the "old" certificate until expiry, but should allow plenty of time to transition to the new one. In reality, this could be one or two days only, since most clients report every 5 mins.
e) Delete the shared secret.
I think there's too much going on here, but not sure where. It seems to me that there's already an authentication process going on using asymmetric keys via the ssh authentication mechanism. It would seem that an extra key to authenticate the client is redundant, because the client has already authenticated itself.
Also, could the shared key be a problem if it gets out? Let's say I have 50 devices all using certs, but still with the shared key still in place, just in case of certificate corruption requiring a new bootstrapping procedure. Now, let's say someone hacks into one of the devices and retrieves the shared key. That key can now be used to bootstrap any new device to trust a rogue certificate authority, or at least to sign reports that are rejected by Xymon for being signed by the wrong certificate. Perhaps this could be used as part of a man-in-the-middle attack?
I think I'd be more comfortable if the shared key was unique to each device. But ultimately, I think it shouldn't be required, because the ssh keys are per-device keys, and should be sufficient to give the same effect.
Or... we could configure a shared secret in the xymon-hosts file for each client (different "password" for each client) and the client simply encrypts all data it returns with this shared secret. Advantage is "simplicity" disadvantage is much less secure.
Why less secure? I'm not disagreeing, just want to understand why.
Another option is to do the ssh host key thing, where the first time a connection is made to a host, everyone just accepts the new host key into their known_hosts file (presumably after checking the fingerprint out-of-band, lol).
So one way to do this for the Xymon client would be to have the client fetch its unique key the first time it connects to the server, and use it to sign from then on. I think this much the same as the "a" through "e" steps you outlined above, except not necessarily using certificates - but it could be a certificate, or a private key, or both client private key and server public key, or a unique per-client shared key, or a one-for-all-clients shared key.
A few more comments to consider.
It's easy to do crypto badly. Whatever is done here (if anything), we shouldn't be rolling our own crypto, and instead we need to use standard crypto primitives provided by a well-known and highly-regarded library such as OpenSSL. Even that is not sufficient; one could choose the wrong type of cipher (eg a block cipher where a stream cipher is appropriate), or use a hash function that requires sufficient source data volume to properly initialise, to has a password that could be only 8 characters. There are standardised ways of doing crypto that are recognised as optimal, or at least sound, such as PBKDF2 for deriving robust keys, salting hashes, and so on. If it's going to be built in, it needs to be done right.
Certificates don't need to be x509. Secure shell (ssh) can support certificates for authentication, but they aren't x509 certs, and from what little I've read, their use seems to be further away from the "full-blown PKI" end of the spectrum and closer to simple asymmetric key pairs. The one thing that ssh's certs cannot do is revocation. This means if I use the same cert on all boxes I login to, and my private key is exposed, I need to change my key on each and every one of those boxes. One solution to this is suitable key management, eg storing my private key on an HSM or Yubikey; another is to use a unique key for each box I want to authenticate to (essentially giving myself multiple identities). This problem isn't necessarily relevant to the discussion about securing client data messages, but it highlights the fact that this is complex, and different requirements may benefit from having quite different solutions available.
Certs give us the *potential *to use PKI, but to get all the benefits of PKI one also needs ancillary services such as an OCSP or CRL server and proper key management. However, many organisations don't have PKI infrastructure, so the benefits of PKI such as revocation lists, don't warrant the overhead, and self-signed certs or other forms of key pair technology, should be available for those who aren't able to afford or run a complete PKI solution. Non-PKI essentially becomes mutual authentication between pairs of nodes (one always being the Xymon server). If a client key is compromised, both ends need remediation. If a server key is compromised, all clients need remediation. This is usually good enough for most smaller organisations.
I see no reason why we can't support ssh just with sufficient documentation. The same goes for or stunnel, IPSec, OpenVPN, etc. They're all useful to people in different circumstances. This just requires documenting each one. There may be cases where a script or two would benefit these different methods (an extreme case is xymon-rclient.sh, which IMHO is waaaay too big to be included as a simple "helper" script for one of these methods).
If we are to do this right, we should include support for both client-side and server-side authentication.
PS, as for IPv6, I am yet to see any decent level of support here, I tried to start using it years ago, and it just never happened. Turns my routers (Cisco Meraki: www.meraki.com details at
https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...)
still don't support IPv6 either, so it still doesn't seem to be as important as claimed by everyone 10+ years ago when they said we would run out of IPv4 addresses.... It's hard to "change the world", I mean, we still have SMTP and DNS ;)
Yep, this is true, overall IPv6 take-up continues to be slow. However, the thing about Xymon is, it needs to be able to monitor a wide range of devices and services. So if you have 1000 nodes to monitor, and just one of them runs IPv6, your Xymon has to support IPv6 in order to detect a service outage. This is the situation I'm in. My work-around is to disable "conn" checks for such hosts, and run a script that does a ping6 and creates the "conn" status messages. Also, certain sectors of the industry are likely to have a relatively large IPv6 footprint, such as telcos, and IoT network providers.
J
On 14/3/19 16:00, Jeremy Laidman wrote:
On Wed, 13 Mar 2019 at 10:57, Adam Goryachev <mailinglists at websitemanagers.com.au <mailto:mailinglists at websitemanagers.com.au>> wrote:
IMHO, when using "security" tools, we really need to make sure we rely on a third party "library" to do this, security/encryption is a fast moving area, and we really don't want to be using something 5 years old because nobody understood how to update it from TLS1.1 to TLS1.2 or from using 3DES to using AES or whatever the issue becomes.I'm not sure I agree that encryption is fast-moving in all areas, or even most of them. Yes, there are bugs found in encryption software, short-cuts found in brute-forcing hashes, new algorithms every now and then, and the occasional implementation problem (wep, wpa, ssl); all of these scenarios require some kind of upgrade. However, the math(s) behind the basic crypto primitives is fundamentally sound (well-vetted and in some cases proven), particularly around simple use cases. Even with deprecated hashes (MD5, SHA1) they're not considered insecure, just that a well-resourced, and highly motivated and patient actor can brute-force them in time. With careful selection of hashing, encipherment and session key management algorithms, a good, strong solution can be implemented using >20-year-old crypto.
However, there's other value in being able to use a separate library, and allow upgrades to the library to improve security or squash bugs, without having to recompile Xymon.
Also, xymon may not be updated as easily/quickly as what other system libraries might, so again, better to let the OS (system) provide the relevant tools to do this, and we just become another consumer.Agreed.
As such, an obvious choice would be openssl, or something similar, where it is widely supported across many platforms, well maintained, and likely to be well maintained in the future.Not to mention, OpenSSL is already used by Xymon for things like https checks.
I think there are two separate requirements when referring to encryption: 1) Encrypt the content so anyone listening can't see your log fileYep.
2) Signature - ie, ensuring the message actually came from "one of my clients" or taking this further it came from "this specific client".Yep.
And there are situations where only signing is required. This not only ensures no tampering, but it also ensures that a large message has not been truncated by some process. On some systems, I often get a red "procs" test because the [ps] or [netstat] sections were so long that the data message was truncated. I'd prefer to skip a truncated message entirely than to react to conclusions based on incomplete data, at least in this case. A [signature] section at the end of the message (or heck, even just an [end] section) and appropriate handling in xymond, would fix this.
Having encryption also gives us signing, and having signing also ensures no tampering. If encryption and signing aren't required, the overhead of managing keys makes it burdensome to detect truncated messages. But if we bake in encryption, we get everything. If we use x509 certificates, we get all of this, plus potentially PKI (federated trust, revocation, expiry). It's a hierarchy, and the higher up we go, the harder it is to implement (both in the code, and rolling it out to nodes), but the more features we get.
(As an aside I like the idea that an x509 certificate can be used to tie a client data message to an entry in hosts.cfg, either allowing the commonName field to override the value in the client data message, or having a "CN" tag in the hosts.cfg file to match the client message to.)
Also, key management needs to be considered. It's a different task to encrypt traffic between a xymonproxy server and xymond server, to rolling out encryption to 500 devices each running a Xymon client.
- Do we need full PGP security for this? At least during setup, we can easily start with a known good/clean connection, or rely on the admin to ensure that some "shared secret" is valid on both ends.So, like bootstrapping the key rollout procedure. This could leverage the existing "download" client message type. The client should know when her certificate is soon to expire, and can just ask for a new one with: "xymon download /meta/clientcert.x509" and the xymond process could sign a new cert on-the-fly and send it down the wire.
- We can already send data back to the client after the client successfully delivers data to the server. If the "current" data the client is sending is considered "clean/secure" then we can easily send back a renewed "certificate".Yep, that's another option.
So... a) Start with a simple shared secret that the admin can create (or is auto-generated) on server install. b) The admin configures this secret onto each client that is added, along with adding the hostname to the server (xymon-hosts file).b1) admin configures ssh public key on client
c) When the client connects to the server, it uses the SSH "encryption" to protect the conversation, sends the shared key plus the normal "1st set of data reports". The server responds with a client "certificate". d) When the client next connects to the server, it uses the SSH "encryption" to protect the conversation, and signs the data with the certificate it received from the server. If the certificate is due to expire in X days (configurable on server) then the server will provide an updated certificate to the client. The client can continue to use the "old" certificate until expiry, but should allow plenty of time to transition to the new one. In reality, this could be one or two days only, since most clients report every 5 mins.e) Delete the shared secret.
I think there's too much going on here, but not sure where. It seems to me that there's already an authentication process going on using asymmetric keys via the ssh authentication mechanism. It would seem that an extra key to authenticate the client is redundant, because the client has already authenticated itself.
Actually, I was suggesting the SSH style encryption which would be used for encryption only, not signing, in my mind that was a separate process which works with the contents. In my thought process, the SSH encryption is kind of like HTTPS, where any client can connect to the server (without authentication) but still ensure that the content is encrypted/protected.
Within this, there would be another signature to sign the content which is used to confirm it came from client abc and not random unknown, nor from known client xyz.
Also, could the shared key be a problem if it gets out? Let's say I have 50 devices all using certs, but still with the shared key still in place, just in case of certificate corruption requiring a new bootstrapping procedure. Now, let's say someone hacks into one of the devices and retrieves the shared key. That key can now be used to bootstrap any new device to trust a rogue certificate authority, or at least to sign reports that are rejected by Xymon for being signed by the wrong certificate. Perhaps this could be used as part of a man-in-the-middle attack?
I think the shared key is only enough to "add" a client, and only if that client is already listed in the xymon-hosts file. So, the value of this shared key is pretty low. Worst case, it could allow a rogue client to get a valid certificate for a host that is listed but doesn't use encryption/certificates, either because it is a old client that doesn't support it, or it is a platform that isn't supported, etc...
I think I'd be more comfortable if the shared key was unique to each device. But ultimately, I think it shouldn't be required, because the ssh keys are per-device keys, and should be sufficient to give the same effect.
Or... we could configure a shared secret in the xymon-hosts file for each client (different "password" for each client) and the client simply encrypts all data it returns with this shared secret. Advantage is "simplicity" disadvantage is much less secure.Why less secure? I'm not disagreeing, just want to understand why.
From my (limited) understanding, a lot of crypto attacks are based on dictionary attacks. Since pretty much 100% of our content is plain text, and a lot of that will be "recent dates, repeated a lot throughout the content", ie, log files... then it would make it easier to find out the "key" if you know (or can guess) the plain text that was encrypted. My understanding is that this is less relevant when you use some of the more modern encryption processes along with PKI. I guess everyone can know the content of the index.html that a user will get over https, so I assume that https encryption processes are able to overcome this issue.
Another option is to do the ssh host key thing, where the first time a connection is made to a host, everyone just accepts the new host key into their known_hosts file (presumably after checking the fingerprint out-of-band, lol).
So one way to do this for the Xymon client would be to have the client fetch its unique key the first time it connects to the server, and use it to sign from then on. I think this much the same as the "a" through "e" steps you outlined above, except not necessarily using certificates - but it could be a certificate, or a private key, or both client private key and server public key, or a unique per-client shared key, or a one-for-all-clients shared key.
Right, it could even be that some tool on the client connects to the server and requests the certificate, and you a second interactive tool on the server will receive/process that request, once the admin approves it, then the response is sent back to the client. I mean, who doesn't have two ssh sessions open (one client and one server) when adding a new client?
A few more comments to consider.
It's easy to do crypto badly. Whatever is done here (if anything), we shouldn't be rolling our own crypto, and instead we need to use standard crypto primitives provided by a well-known and highly-regarded library such as OpenSSL. Even that is not sufficient; one could choose the wrong type of cipher (eg a block cipher where a stream cipher is appropriate), or use a hash function that requires sufficient source data volume to properly initialise, to has a password that could be only 8 characters. There are standardised ways of doing crypto that are recognised as optimal, or at least sound, such as PBKDF2 for deriving robust keys, salting hashes, and so on. If it's going to be built in, it needs to be done right.
Certificates don't need to be x509. Secure shell (ssh) can support certificates for authentication, but they aren't x509 certs, and from what little I've read, their use seems to be further away from the "full-blown PKI" end of the spectrum and closer to simple asymmetric key pairs. The one thing that ssh's certs cannot do is revocation. This means if I use the same cert on all boxes I login to, and my private key is exposed, I need to change my key on each and every one of those boxes. One solution to this is suitable key management, eg storing my private key on an HSM or Yubikey; another is to use a unique key for each box I want to authenticate to (essentially giving myself multiple identities). This problem isn't necessarily relevant to the discussion about securing client data messages, but it highlights the fact that this is complex, and different requirements may benefit from having quite different solutions available.
Certs give us the /potential /to use PKI, but to get all the benefits of PKI one also needs ancillary services such as an OCSP or CRL server and proper key management. However, many organisations don't have PKI infrastructure, so the benefits of PKI such as revocation lists, don't warrant the overhead, and self-signed certs or other forms of key pair technology, should be available for those who aren't able to afford or run a complete PKI solution. Non-PKI essentially becomes mutual authentication between pairs of nodes (one always being the Xymon server). If a client key is compromised, both ends need remediation. If a server key is compromised, all clients need remediation. This is usually good enough for most smaller organisations.
I mostly understand, and think I agree with most of the above. At the end of the day, the solution needs to be:
a) backwards compatible, so you can still accept plain, unsigned, unencrypted connections from the coffee maker in the corner
b) simple to install and maintain, and robust. If it's too hard to install or maintain, then people won't want to use it.
- I see no reason why we can't support ssh just with sufficient documentation. The same goes for or stunnel, IPSec, OpenVPN, etc. They're all useful to people in different circumstances. This just requires documenting each one. There may be cases where a script or two would benefit these different methods (an extreme case is xymon-rclient.sh, which IMHO is waaaay too big to be included as a simple "helper" script for one of these methods).
Possibly we could run the existing 1984 listener in a wrapper which handles all the "encryption", and then within xymon itself, there are a small number of additional "types" that can be sent from client, or returned to the client to add the additional certificate/signing stuff.
So, if we can easily add a command line flag that says enable "STARTSSL" command, that in itself would be a huge step forward. IMAP and POP and I think SMTP can all do this, so it should be a pretty well defined protocol, and should be well supported in common libraries.
Again, lets not try and jump and touch the moon, one step at a time...
If we are to do this right, we should include support for both client-side and server-side authentication.
PS, as for IPv6, I am yet to see any decent level of support here, I tried to start using it years ago, and it just never happened. Turns my routers (Cisco Meraki: www.meraki.com <http://www.meraki.com> details at https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...)
still don't support IPv6 either, so it still doesn't seem to be as important as claimed by everyone 10+ years ago when they said we would run out of IPv4 addresses.... It's hard to "change the world", I mean, we still have SMTP and DNS ;)
Yep, this is true, overall IPv6 take-up continues to be slow. However, the thing about Xymon is, it needs to be able to monitor a wide range of devices and services. So if you have 1000 nodes to monitor, and just one of them runs IPv6, your Xymon has to support IPv6 in order to detect a service outage. This is the situation I'm in. My work-around is to disable "conn" checks for such hosts, and run a script that does a ping6 and creates the "conn" status messages. Also, certain sectors of the industry are likely to have a relatively large IPv6 footprint, such as telcos, and IoT network providers.
True, there are many Meraki customers requesting IPv6, I'm just acknowledging that it is a much slower process than it seemed to be advertised. It originally seemed like we would all be forced to IPv6 within a couple of years.
I think there's too much going on here, but not sure where. It seems to me that there's already an authentication process going on using asymmetric keys via the ssh authentication mechanism. It would seem that an extra key to authenticate the client is redundant, because the client has already authenticated itself.
Actually, I was suggesting the SSH style encryption which would be used for encryption only, not signing, in my mind that was a separate process which works with the contents. In my thought process, the SSH encryption is kind of like HTTPS, where any client can connect to the server (without authentication) but still ensure that the content is encrypted/protected.
Yes, that's one way to approach it. However, encryption without signing is open to MITM attacks. So this approach would be suitable for low-risk situations, such as detecting data corruption or truncation rather than detecting malicious interference, I would think.
HTTPS is a weird case. It's designed to allow mutual authentication, and does that really well. But the cost of getting a client-side authentication artefact that works along with the HTTPS system is too high, and so people eschew the client authentication and overlay a use username/password system, probably because it's the way things have always been done, and the way users are accustomed to doing it even before encryption was common for Internet protocols (telnet, rlogin, etc).
Within this, there would be another signature to sign the content which is used to confirm it came from client abc and not random unknown, nor from known client xyz.
My problem with this approach is that we already have a system that naturally handles private keys very well, but we would be discarding the client half authentication, and then jamming in a completely different authentication scheme, requiring two different types of secrets to be managed. This is fine when the key management burden is massively asymmetrical as per general purpose HTTPS, but when we control both ends of the transaction, the asymmetry is rebalanced, and so I think we should make use of HTTPS to authenticate both nodes.
Also, could the shared key be a problem if it gets out? Let's say I have 50 devices all using certs, but still with the shared key still in place, just in case of certificate corruption requiring a new bootstrapping procedure. Now, let's say someone hacks into one of the devices and retrieves the shared key. That key can now be used to bootstrap any new device to trust a rogue certificate authority, or at least to sign reports that are rejected by Xymon for being signed by the wrong certificate. Perhaps this could be used as part of a man-in-the-middle attack?
I think the shared key is only enough to "add" a client, and only if that client is already listed in the xymon-hosts file. So, the value of this shared key is pretty low. Worst case, it could allow a rogue client to get a valid certificate for a host that is listed but doesn't use encryption/certificates, either because it is a old client that doesn't support it, or it is a platform that isn't supported, etc...
I agree the value is low. Which is why I think we can do without it altogether. The window of opportunity to abuse this key is very small, and so I think the risk isn't that much worse if there's no key at all. For situations where the risk has to be mitigated, there would be no problem having an administrator copying the certificate into place out-of-band or via a trusted path such as scp.
Or... we could configure a shared secret in the xymon-hosts file for each client (different "password" for each client) and the client simply encrypts all data it returns with this shared secret. Advantage is "simplicity" disadvantage is much less secure.
Why less secure? I'm not disagreeing, just want to understand why.
From my (limited) understanding, a lot of crypto attacks are based on dictionary attacks. Since pretty much 100% of our content is plain text, and a lot of that will be "recent dates, repeated a lot throughout the content", ie, log files... then it would make it easier to find out the "key" if you know (or can guess) the plain text that was encrypted. My understanding is that this is less relevant when you use some of the more modern encryption processes along with PKI. I guess everyone can know the content of the index.html that a user will get over https, so I assume that https encryption processes are able to overcome this issue.
Yes, it very much depends on how the encryption is done. For some systems, knowing the plaintext and the ciphertext gives you back your key. But in other systems, such as when the key is as long as the plaintext, this is not the case, because you can choose a key to decrypt to any possible original plaintext you wanted. So you can brute-force this, but there are a bazillian possible keys that appear to give a valid plaintext and you don't know which is the right one.
Even with crypto that allows the cracker to know when she's found the right key, a long enough key length means that the resources and time required to crack the code is prohibitive. It's easy to choose badly, but it's not too difficult to choose a solid algorithm for this. You're wise to be cautions, but this problem has been solved.
I'm not a crypto dude, but I believe the standard PBKDF functions are intended to be robust against brute-force attacks, by key stretching as well as by imposing a computational burden (cpu-hard) on the attacker (by requiring thousands of hash iterations for each attempt). Alternatives such as bcrypt and scrypt require a chain of computations plus one at the very end (paraphrasing may be inaccurate), meaning memory can't be released until the hashing is complete. These are memory-hard functions, and they are intended to make things hard for ASICs and GPUs, which can crunch through CPU-hard functions quickly.
Software such as LastPass uses PBDKF2 with 5000 iterations (user configurable) to encrypt a user's vault, making it take a really long time for an attacker to find the matching key.
I mostly understand, and think I agree with most of the above. At the end of the day, the solution needs to be:
a) backwards compatible, so you can still accept plain, unsigned, unencrypted connections from the coffee maker in the corner
Yep. Perhaps tagged as "insecure" in Xymon, to remind the sysadmin to go do the needful for that client, and add the keys.
What keeps popping into my head is "STARTTLS" which is used by several protocols (eg SMTP) to seek opportunistic encryption but to default to no encryption because it's better than nothing.
b) simple to install and maintain, and robust. If it's too hard to install or maintain, then people won't want to use it.
Yep, and I think backwards compatibility and opportunistic encryption is probably the key to this. If a sysadmin can roll out encryption to just a single node, without breaking all of the others, then she's more likely to try it out, then phase it in. It also allows temporary disabling of the encryption layer, to help troubleshoot with a tcpdump.
Possibly we could run the existing 1984 listener in a wrapper which handles all the "encryption", and then within xymon itself, there are a small number of additional "types" that can be sent from client, or returned to the client to add the additional certificate/signing stuff.
So, if we can easily add a command line flag that says enable "STARTSSL" command, that in itself would be a huge step forward. IMAP and POP and I think SMTP can all do this, so it should be a pretty well defined protocol, and should be well supported in common libraries.
Ah, I read your mind it seems. And I was also thinking about the likelihood that we can borrow code from postfix or dovecot or whatever, which all accept STARTTLS and then hand off to an encryption layer.
Looks like modern versions of the openssl client have a "--starttls" option. Worst case, I reckon the Xymon client could do some file-handle manipulation magic on execution of the openssl binary. Server side would probably need C coding.
A separate TCP port for BB-over-TLS (ie not 1984 multiplexed with STARTTLS) is probably easier to prototype, because we can do this with stunnel.
True, there are many Meraki customers requesting IPv6, I'm just acknowledging that it is a much slower process than it seemed to be advertised. It originally seemed like we would all be forced to IPv6 within a couple of years.
Yep, that's for sure, and it really hasn't happened.
Although I do think that the crunch has come, but people are all of a sudden realising that they can turn on NAT and free up oodles of address space in the process. Or use IPv6 in their management networks and free up address space for their data path. I think it's a bit like the Y2K crisis that never happened - I think we just didn't feel it because of all the people working behind the scenes to fix the bugs before the planes fell out of the sky. Slightly off topic now.
On thinking about this, it occurs to me that perhaps the simplest course of action is to provide an alternative client data reporting path to go via https. This is already supported by the xymoncgimsg.cgi script which simply runs within the server web software. On the client side, a wget/curl command can be used to create a post message containing the client data. The implementer rolling this out can choose to do authentication with certs, either server-side or client-side or both, or neither. Or just use http rather than https. Or to use username and password. Curl and wget also supports proxying, which is a bonus.
What's missing from this is key (client cert) management. This could be handled by ssh/scp, or by Xymon's built-in file deployment system, or via the client message response, or by the client node periodically fetching its cert from a URL based on its FQDN that's restricted by client cert or username/password or ACL or whatever, and encrypted by TLS.
I've never used xymoncgimsg.cgi for accepting client messages. The man page recommends using xymonproxy instead, but doesn't say why. Could this be a performance bottleneck? I know others on this list have used it, and perhaps can comment.
J
On Thu, 14 Mar 2019 at 07:09, Adam Goryachev < mailinglists at websitemanagers.com.au> wrote:
...
I mostly understand, and think I agree with most of the above. At the end of the day, the solution needs to be:
a) backwards compatible, so you can still accept plain, unsigned, unencrypted connections from the coffee maker in the corner
b) simple to install and maintain, and robust. If it's too hard to install or maintain, then people won't want to use it. ...
I agree with the recent comments, but I will just add: c) automatable - we have automated client deployment and adding of the appropriate config to the server via Ansible, and it would be good to be able to continue to use Ansible in the future.
Kind regards,
SebA
On 3/8/19 7:08 AM, Axel Beckert wrote:
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
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. 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.
but github would allow the community to report issues, 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: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests, Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch. https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
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, AxelI've been using Xymon and it's predecessor BB, since 2002, administering *IX systems since the mid 80's and Linux since '93.
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.
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.
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.
GIT, CVS and SVN (to name only a few) inherently don't offer bug tracking. github does, gitlab does and so does sourceforge.
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.
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.
When I can see something I need/want tracked and monitored, I do the following:
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 ) 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.
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.
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.
On Mar 8, 2019, at 11:14, Bruce Ferrell <bferrell at baywinds.org> wrote:
On 3/8/19 7:08 AM, Axel Beckert wrote:
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
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. 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.
but github would allow the community to report issues, 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: https://sourceforge.net/p/nfsen/bugs/ <https://sourceforge.net/p/nfsen/bugs/>
provide updates/patches via pull requests, Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/ <https://sourceforge.net/p/nfsen/patches/>
and download either released versions via the tags Possible, too, example: 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>
if necessary or the latest code via the 'develop' (or whatever) branch. 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> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk <https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk>
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, AxelI've been using Xymon and it's predecessor BB, since 2002, administering *IX systems since the mid 80's and Linux since '93.
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.
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.
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.
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.
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.
GIT, CVS and SVN (to name only a few) inherently don't offer bug tracking. github does, gitlab does and so does sourceforge.
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.
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.
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.
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.
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.
When I can see something I need/want tracked and monitored, I do the following:
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 ) 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.
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.
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.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Fri, 8 Mar 2019 at 15:09, Axel Beckert <abe at deuxchevaux.org> wrote:
Hi,
On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:
On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:
Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.
I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.
Yes, you're quite right, I meant CVS. I must have been having a mental blank or typoed.
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.
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.
I would say it has happened, but not very consistently, especially recently. There have been patches submitted via the mailing list that got missed by the maintainers, there are probably still a bunch outstanding. GitHub might make these more obvious. Beyond this, I totally agree with your comments.
but github would allow the community to report issues,
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: https://sourceforge.net/p/nfsen/bugs/
provide updates/patches via pull requests,
Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/
and download either released versions via the tags
Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27
if necessary or the latest code via the 'develop' (or whatever) branch.
https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk
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.
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.
(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, AxelAnd 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.
Kind regards,
SebA
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 versionKnowing 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
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, AxelAnd 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
On Tue, 12 Mar 2019 at 05:09, Japheth Cleaver <cleaver at terabithia.org> wrote:
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
Hi jc,
It might be helpful if you or someone commit ToDo and TESTING files in the 4.x-master branch describing what is broken, what work is partially implemented, what the roadmap might look like (maybe in a different file), and exactly what testing needs to be done (in such a way that anyone could look at the test plan and say, 'OK, I'll try and complete that') before features are considered worthy of pushing into a stable branch, or before a 4.4 branch can be branched and considered as beta or stable.
I don't think this knowledge is widely known, and the first step towards getting it done is probably to verbalize what it is that needs doing. Then perhaps people will pick up a particular test case and run through it and that one can be ticked off. A way of tracking these, e.g. in a 'bug' tracker may be helpful, so that they can provide evidence of the test. Redmine might be larger than what's required, but it does seem quite good for progressing projects, with the ability to see what needs to be done for each release.
The thing is that, with SVN especially, not so much if Xymon was using Git, it's very easy for planned or even developed features to get stuck behind other features pending testing in the pipeline. What I mean is that even if there was no demand for IPv6, we would want to get that out of the door so that we can move on to progressing other features (without ditching all the work that has already been done), as merging branches can be tricky or time consuming.
Kind regards,
SebA
Hi J.C.,
On Mon, Mar 11, 2019 at 10:09:29PM -0700, Japheth Cleaver wrote:
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.
Thanks for that insight!
And I'm still hoping for TLS support in the client.
+1 despite my workaround works as reliable as stunnel's startup scripts — i.e. not perfect, but does the job. And gets purple if stunnel restart fails. :-)
Knowing that there is still actually a demand for IPv6 is helpful.
Definitely.
In Debian's hobbit-plugins package there is already a server-side conn6 check which uses the hostname in hosts.cfg and makes a AAAA lookup to see what it needs to ping. So I can cope with the conn check being IPv4-only.
But what is wishfully needed is the IPv6 support for the xymonnet tests.
Simply put, what's most needed right now is a potentially large testbed for testing and validation of the code we have.
Unfortunately due to a job change 2.5 years ago, the Xymon setups I maintain now are no more at the size of nearly a thousand hosts, just two setups with two or three dozens monitored hosts each.
Kind regards, Axel-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
participants (13)
-
abe＠deuxchevaux.org
-
bferrell＠baywinds.org
-
cleaver＠terabithia.org
-
felipe＠redix.com.br
-
Jean-Pierre.Pitout＠mtn.com
-
jeremy＠laidman.org
-
jglouisjr＠gmail.com
-
john.horne＠plymouth.ac.uk
-
mailinglists＠websitemanagers.com.au
-
nuitari＠nuitari.net
-
ralphmitchell＠gmail.com
-
rlhamil2＠gmail.com
-
spah＠syntec.co.uk