Is the xymon Dead? Future
list Felipe Ribeiro
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) ?
list Richard L. Hamilton
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 <user-675193762e07@xymon.invalid> 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 at xymon.com <list Felipe Ribeiro
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 <user-af55987f6d56@xymon.invalid> Enviada em: quinta-feira, 7 de março de 2019 17:54 Para: Felipe Ribeiro <user-675193762e07@xymon.invalid> 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 <user-675193762e07@xymon.invalid<mailto:user-675193762e07@xymon.invalid>> 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) ?
Attachments (1)
attachment.pnglist Sebastian Auriol
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 <user-675193762e07@xymon.invalid> 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 <user-af55987f6d56@xymon.invalid> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <user-675193762e07@xymon.invalid> *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 <user-675193762e07@xymon.invalid> 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) ?
list James Louis
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 <user-4631430d620a@xymon.invalid> 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 <user-675193762e07@xymon.invalid> 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 <user-af55987f6d56@xymon.invalid> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <user-675193762e07@xymon.invalid> *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 <user-675193762e07@xymon.invalid> 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) ?
-- *----------------------------------------*
* 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
list John Horne
▸
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.
![http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>](http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>){kind=link}
list Japheth Cleaver
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 <user-4631430d620a@xymon.invalid <mailto:user-4631430d620a@xymon.invalid>> 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 <user-675193762e07@xymon.invalid
<mailto:user-675193762e07@xymon.invalid>> 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 <user-af55987f6d56@xymon.invalid
*Enviada em:* quinta-feira, 7 de março de 2019 17:54
*Para:* Felipe Ribeiro <user-675193762e07@xymon.invalid
*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
<user-675193762e07@xymon.invalid <mailto:user-675193762e07@xymon.invalid>> 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) ?
list Axel Beckert
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: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Ralph Mitchell
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 <user-bc188e45dae4@xymon.invalid> 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 tagsPossible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27if 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: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Jean-Pierre Pitout [ Mtn South Africa ]
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 <user-00a5e44c48c0@xymon.invalid>
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 <user-bc188e45dae4@xymon.invalid<mailto:user-bc188e45dae4@xymon.invalid>> 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: user-bc188e45dae4@xymon.invalid<mailto:user-bc188e45dae4@xymon.invalid> \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid<mailto:user-0064bde8d49d@xymon.invalid> X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/ "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. "
list Axel Beckert
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_Guide#Encryption_and_Tunnelling HTH!
▸
Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Bruce Ferrell
▸
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 tagsPossible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27if 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
I'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.
list Richard L. Hamilton
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 <user-bc188e45dae4@xymon.invalid> 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_Guide#Encryption_and_Tunnelling HTH! Kind regards, Axel -- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Richard L. Hamilton
▸
On Mar 8, 2019, at 11:14, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid> 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 tagsPossible, 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.
list Bruce Ferrell
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 <user-bc188e45dae4@xymon.invalid> 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_Guide#Encryption_and_Tunnelling HTH! Kind regards, Axel
list Stephane Bakhos
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 <user-24fbf1912cfe@xymon.invalid> 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 <user-bc188e45dae4@xymon.invalid> 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_Guide#Encryption_and_TunnellingHTH! Kind regards, Axel
list Sebastian Auriol
▸
On Fri, 8 Mar 2019 at 15:09, Axel Beckert <user-bc188e45dae4@xymon.invalid> 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 tagsPossible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27if 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, Axel
And I'm still hoping for TLS support in the client. I did try https URL
as the recipient (which should work - r7797) but I couldn't get it to work
in the RPM version.Kind regards, SebA
list Japheth Cleaver
▸
On 3/11/2019 6:59 AM, SebA wrote:
On Fri, 8 Mar 2019 at 15:09, Axel Beckert <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>> wrote:
Well another option is just to convert the repo on SF from SVN to Git, but keep it hosted on SF. And then also to enable the bugs and patches area - if someone is going to monitor and maintain those areas. I have seen SF projects where no-one does. But most active FLOSS projects are on GitHub these days.
And with regards to being dead or not: Development greatly sped up
when J.C. Cleaver took over release management, but it indeed seems to
have stalled a little bit again. Then again, IIRC J.C. mostly took
over release management so that Henrik can focus on long-time
development. And if there is not much to fix in the current stable
releases, not having a stable release every few months is not
necessarily "dead", but might also be "stable, no relevant open
issues".
Yes, development did greatly speed up, but it practically ceased when J.C., I think, found difficulty merging the patches he had been using in his RPMs with Henrik's new 4.4 code. Or over 2 years ago (Jan 2016) when he released 4.3.28. I know the idea was that Henrik could focus on long-time development, but I think that ceased over 3 years ago - his last commit was in Jan 2016, with the last development type commit being Dec 2015. Both of them changed jobs (Henrik in Aug 2013 and J.C. in Sep 2015) and I'm guessing no longer used, or needed to develop, Xymon in their new roles and then their desire or capacity to keep putting time into the project dwindled.This is a fair criticism, unfortunately. The primary issue for me since then has been having access to sufficiently high-throughput performance and load testing, which had been a significant aspect of the feature and dev cycle. I'd been hesitant to release further absent a true shakedown of the new code, however that was /never/ intended to be an indication of lack of interest in the project. It had seemed to have gotten to a point where a lot of the low-hanging fruit had been hit and there was -- once again -- a large delta in the jump to the prospective next release -- in fact, which I feel was similar to the previous stall.
▸
(And yes, I'm still hoping and waiting for IPv6 support, too,
especially in xymonnet-based checks. Reporting to IPv6-only
servers is
no issue though, if you anyways use stunnel to encrypt the
client-reporting traffic.)
Kind regards, Axel
And I'm still hoping for TLS support in the client. I did try https
URL as the recipient (which should work - r7797) but I couldn't get
it to work in the RPM version
Knowing that there is still actually a demand for IPv6 is helpful. Simply put, what's most needed right now is a potentially large testbed for testing and validation of the code we have.
Regards,
-jc
list Richard L. Hamilton
I don't have "large" at home, of course - not hundreds, but very low two digits, slightly less low if VM's that are only up intermittently are counted. It is eclectic: three different Solaris versions (on SPARC and x86), two different macOS versions, one Windows physical, one SPARC Linux LDOM, and a couple of the latest of CentOS and Ubuntu on the intermittent VMs. And I'm retired, so I don't have access to anything else to test on (and might have found it problematic to run test software at work when I wasn't retired). I do have something for you to think about, though. While IPv4 certainly isn't going to go away until everyone gives up on it, the use of IPv4 and IPv6 can only increase. And physical connectivity doesn't mean both will work - my home router sometimes loses external IPv6 connectivity until I log into it and drop and renew the DHCPv6 lease. (thank the network deities that there is some attempt to keep the /64 prefixes from changing too much, since I don't have DNS updates automated for IPv6) So since I already have a server-side Xymon script that probes the router (using upnpc command, as home routers don't necessarily provide other non-web ways of finding out connectivity status and external IP), I also have it do an IPv6 ping of a public server, and turn yellow for router internet status if IPv4 is up but IPv6 is down. (modem internet status is just a web scrape and inspection of the result, since my modem only provides status and not configuration to the user, and does not require a login for that) But a more generic solution might be able to offer an enhanced version of conn= tag, and even an additional conn6= tag, allowing either consolidated address testing, or one column each for IPv4 and IPv6; that would let one better spot connectivity issues in a mixed IPv4/IPv6 environment!
▸
On Mar 12, 2019, at 01:09, Japheth Cleaver <user-87556346d4af@xymon.invalid> wrote: On 3/11/2019 6:59 AM, SebA wrote:On Fri, 8 Mar 2019 at 15:09, Axel Beckert <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>> wrote: Well another option is just to convert the repo on SF from SVN to Git, but keep it hosted on SF. And then also to enable the bugs and patches area - if someone is going to monitor and maintain those areas. I have seen SF projects where no-one does. But most active FLOSS projects are on GitHub these days. And with regards to being dead or not: Development greatly sped up when J.C. Cleaver took over release management, but it indeed seems to have stalled a little bit again. Then again, IIRC J.C. mostly took over release management so that Henrik can focus on long-time development. And if there is not much to fix in the current stable releases, not having a stable release every few months is not necessarily "dead", but might also be "stable, no relevant open issues". Yes, development did greatly speed up, but it practically ceased when J.C., I think, found difficulty merging the patches he had been using in his RPMs with Henrik's new 4.4 code. Or over 2 years ago (Jan 2016) when he released 4.3.28. I know the idea was that Henrik could focus on long-time development, but I think that ceased over 3 years ago - his last commit was in Jan 2016, with the last development type commit being Dec 2015. Both of them changed jobs (Henrik in Aug 2013 and J.C. in Sep 2015) and I'm guessing no longer used, or needed to develop, Xymon in their new roles and then their desire or capacity to keep putting time into the project dwindled.This is a fair criticism, unfortunately. The primary issue for me since then has been having access to sufficiently high-throughput performance and load testing, which had been a significant aspect of the feature and dev cycle. I'd been hesitant to release further absent a true shakedown of the new code, however that was /never/ intended to be an indication of lack of interest in the project. It had seemed to have gotten to a point where a lot of the low-hanging fruit had been hit and there was -- once again -- a large delta in the jump to the prospective next release -- in fact, which I feel was similar to the previous stall. (And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.) Kind regards, Axel And I'm still hoping for TLS support in the client. I did try https URL as the recipient (which should work - r7797) but I couldn't get it to work in the RPM version Knowing that there is still actually a demand for IPv6 is helpful. Simply put, what's most needed right now is a potentially large testbed for testing and validation of the code we have. Regards, -jc
list Sebastian Auriol
On Tue, 12 Mar 2019 at 05:09, Japheth Cleaver <user-87556346d4af@xymon.invalid>
▸
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
list Axel Beckert
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: user-bc188e45dae4@xymon.invalid \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: user-0064bde8d49d@xymon.invalid X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/
list Sebastian Auriol
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 <user-24fbf1912cfe@xymon.invalid> 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 <user-bc188e45dae4@xymon.invalid> 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 athttps://salsa.debian.org/debian/xymon/blob/master/debian/README.encryptionalthough 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_Guide#Encryption_and_TunnellingHTH! Kind regards, Axel
list Bruce Ferrell
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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> 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 <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>> 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
list Bruce Ferrell
...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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> 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 <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>> 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
list Sebastian Auriol
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 <user-24fbf1912cfe@xymon.invalid> 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 <user-24fbf1912cfe@xymon.invalid<mailto:user-24fbf1912cfe@xymon.invalid>> 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 theissue 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 theclient 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 <user-bc188e45dae4@xymon.invalid<mailto:user-bc188e45dae4@xymon.invalid>> 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.encryptionwith hints how to implement encrypted reporting with Xymon. The current version can be found in our packaging git repository athttps://salsa.debian.org/debian/xymon/blob/master/debian/README.encryptionalthough 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_TunnellingHTH! Kind regards, Axel
list Sebastian Auriol
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 <user-24fbf1912cfe@xymon.invalid> 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 <user-24fbf1912cfe@xymon.invalid<mailto:user-24fbf1912cfe@xymon.invalid>> 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 theissue 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 theclient 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 <user-bc188e45dae4@xymon.invalid<mailto:user-bc188e45dae4@xymon.invalid>> 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.encryptionwith hints how to implement encrypted reporting with Xymon. The current version can be found in our packaging git repository athttps://salsa.debian.org/debian/xymon/blob/master/debian/README.encryptionalthough 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_TunnellingHTH! Kind regards, Axel
list Bruce Ferrell
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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> 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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>> 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 <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>> 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
list Sebastian Auriol
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 <user-24fbf1912cfe@xymon.invalid> 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/saltI 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 <user-24fbf1912cfe@xymon.invalid<mailto:user-24fbf1912cfe@xymon.invalid>> 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 <user-24fbf1912cfe@xymon.invaliduser-24fbf1912cfe@xymon.invalid>>> 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 weget theissue 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 fromelsewhere isn't being provided.On Mar 8, 2019, at 11:09, Axel Beckert <user-bc188e45dae4@xymon.invaliduser-bc188e45dae4@xymon.invalid>>> 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 toIPv6-only servers isno issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)Debian's xymon package ships/usr/share/doc/xymon/README.encryptionwith hints how to implement encrypted reporting with Xymon. The current version can be found in our packaging git repository athttps://salsa.debian.org/debian/xymon/blob/master/debian/README.encryptionalthough I'm thinking about renaming it toREADME.encryption.md <http://README.encryption.md>; < http://README.encryption.md>; as Iwrote 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_TunnellingHTH! Kind regards, Axel
list Bruce Ferrell
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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> 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 theApachelicence. Kind regards, SebA On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>> 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 onOSS, butthats' 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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>><mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>>> 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 <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>><mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>>> 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 > > >
list Sebastian Auriol
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 <user-24fbf1912cfe@xymon.invalid> 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 SaltStack, but they're mostly due to not having the right firewall ports open. Anyway, the key generationand 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 <user-24fbf1912cfe@xymon.invalid<mailto:user-24fbf1912cfe@xymon.invalid>> 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/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 thisdiscussion 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/saltI 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 theApachelicence. Kind regards, SebA On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <user-24fbf1912cfe@xymon.invaliduser-24fbf1912cfe@xymon.invalid>>> 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 onOSS, butthats' 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.htmlAnyway, that model would probably work pretty well forXymon, so long as the reporting client is not ephemeral.Kind regards, SebA On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <
user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:
▸
user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>>> 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 dynamicIP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really goodif theclient 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 <
user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>
▸
user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>>> wrote:Hi Ralph, On Fri, Mar 08, 2019 at 10:40:55AM -0500, RalphMitchell wrote:I'd still like to see encrypted connections forXymon client messages goingto 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 toIPv6-only servers isno issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)Debian's xymon package ships/usr/share/doc/xymon/README.encryptionwith hints how to implement encrypted reporting withXymon.The current version can be found in our packaging git repository athttps://salsa.debian.org/debian/xymon/blob/master/debian/README.encryptionalthough I'm thinking about renaming it toREADME.encryption.md <http://README.encryption.md>; < http://README.encryption.md>; <http://README.encryption.md>; as Iwrote 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_TunnellingHTH! Kind regards, Axel
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:
list Adam Goryachev
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: 1) 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". 2) 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_Device_Compatibility) 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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> 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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>> 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 <user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>>> 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 <user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>>> 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 > > > > > > >
--
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.
list Jeremy Laidman
On Wed, 13 Mar 2019 at 10:57, Adam Goryachev <
▸
user-92fd6827f6ae@xymon.invalid> 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 file
Yep.
▸
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 caneasily 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_Device_Compatibility) 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
list Adam Goryachev
▸
On 14/3/19 16:00, Jeremy Laidman wrote:
On Wed, 13 Mar 2019 at 10:57, Adam Goryachev <user-92fd6827f6ae@xymon.invalid <mailto:user-92fd6827f6ae@xymon.invalid>> 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 file
Yep.
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 myrouters (Cisco Meraki: www.meraki.com <http://www.meraki.com>;
▸
details at https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility) 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.
list Jeremy Laidman
▸
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
list Sebastian Auriol
On Thu, 14 Mar 2019 at 07:09, Adam Goryachev <
▸
user-92fd6827f6ae@xymon.invalid> 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
list Christian Herzog
hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support
▸
On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
--
Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
list Japheth Cleaver
Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc
▸
On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
list Christian Herzog
Hi JC,
▸
That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/
ok I'll try to get this compiled (+1 for moving to git :)▸
I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful.
I'll be back when I have results. best, -Christian
list Christian Herzog
Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian
▸
On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
-- Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
list Japheth Cleaver
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way. Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything. Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system? -jc
▸
On 4/9/2019 12:12 AM, Christian Herzog wrote:Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
list Japheth Cleaver
Actually, this ended up being pretty broken as-is -- possibly a commit was lost. r8048 has the fix, or the attached patch should work too. Regular ping checks should work again. https://sourceforge.net/p/xymon/code/8048/tree//branches/4.x-master/xymonnet/xymonnet.c?diff=516c17fd34309d2eb14bcb64:8047 HTH, -jc
▸
On 4/9/2019 9:33 AM, Japheth Cleaver wrote:The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way. Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything. Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system? -jc On 4/9/2019 12:12 AM, Christian Herzog wrote:Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
-------------- next part --------------
--- a/branches/4.x-master/xymonnet/xymonnet.c
+++ b/branches/4.x-master/xymonnet/xymonnet.c
@@ -8,7 +8,7 @@
/* */
/*----------------------------------------------------------------------------*/
-static char rcsid[] = "$Id: xymonnet.c 8044 2019-04-08 22:51:46Z jccleaver $";
+static char rcsid[] = "$Id: xymonnet.c 8048 2019-04-09 21:08:10Z jccleaver $";
#include <limits.h>
#include <stdio.h>
@@ -1264,7 +1264,7 @@
char *p;
char l[MAX_LINE_LEN];
char pingip[MAX_LINE_LEN];
- int ip1, ip2, ip3, ip4;
+ char *eoip, eoipchar;
int pingstatus, failed = 0, i;
char fn[PATH_MAX];
@@ -1337,29 +1337,31 @@
/* The test did run, and we have a result-file. Look at it. */
while (fgets(l, sizeof(l), logfd)) {
p = strchr(l, '\n'); if (p) *p = '\0';
- if (sscanf(l, "%d.%d.%d.%d ", &ip1, &ip2, &ip3, &ip4) == 4) {
• - sprintf(pingip, "%d.%d.%d.%d", ip1, ip2, ip3, ip4);
• - /*
- * Need to loop through all testitems - there may be multiple entries for
- * the same IP-address.
- */
- for (t=service->items; (t); t = t->next) {
- if (strcmp(t->host->ip, pingip) == 0) {
- if (t->open) dbgprintf("More than one ping result for %s\n", pingip);
- t->open = (strstr(l, "is alive") != NULL);
- t->banner = dupstrbuffer(l);
- }
• - if (t->host->extrapings) {
- ipping_t *walk;
- for (walk = t->host->extrapings->iplist; (walk); walk = walk->next) {
- if (strcmp(walk->ip, pingip) == 0) {
- if (t->open) dbgprintf("More than one ping result for %s\n", pingip);
- walk->open = (strstr(l, "is alive") != NULL);
- walk->banner = dupstrbuffer(l);
- }
+ eoip = l + strcspn(l, " \t");
+ eoipchar = *eoip;
+ *eoip = '\0';
• + if (conn_is_ip(l) == 0) continue;
+ sprintf(pingip, "%s", l);
+ *eoip = eoipchar;
• + /*
+ * Need to loop through all testitems - there may be multiple entries for
+ * the same IP-address.
+ */
+ for (t=service->items; (t); t = t->next) {
+ if (strcmp(t->host->ip, pingip) == 0) {
+ if (t->open) dbgprintf("More than one ping result for %s\n", pingip);
+ t->open = (strstr(l, "is alive") != NULL);
+ t->banner = dupstrbuffer(l);
+ }
+ if (t->host->extrapings) {
+ ipping_t *walk;
+ for (walk = t->host->extrapings->iplist; (walk); walk = walk->next) {
+ if (strcmp(walk->ip, pingip) == 0) {
+ if (t->open) dbgprintf("More than one ping result for %s\n", pingip);
+ walk->open = (strstr(l, "is alive") != NULL);
+ walk->banner = dupstrbuffer(l);
}
}
}
list Christian Herzog
ok I'll answer in reverse order... - compiled and tested r8048 - same issue: conn is red for IPv6-only hosts - fping: there wasn't any :) I now installed fping 4.2 (buster). no change. - in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default - xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log - most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113 thanks, -Christian
▸
On 4/9/19 6:33 PM, Japheth Cleaver wrote:The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way. Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything. Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system? -jc On 4/9/2019 12:12 AM, Christian Herzog wrote:Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
-- Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
list Christian Herzog
by setting
FPING="/usr/bin/fping"
I can make conn green for IPv6 only hosts at least most of the time, but http
and ssh stay red ("https://ipv6.daduke.org/ - DNS error").
thanks,
-Christian
list Paul Root
FPING should be the path to fping (/usr/sibn/fping?) not xymonping.
▸
-----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of Christian Herzog Sent: Thursday, April 11, 2019 3:46 AM To: xymon at xymon.com Subject: Re: [Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6) ok I'll answer in reverse order... - compiled and tested r8048 - same issue: conn is red for IPv6-only hosts - fping: there wasn't any :) I now installed fping 4.2 (buster). no change. - in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default - xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log - most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113 thanks, -Christian On 4/9/19 6:33 PM, Japheth Cleaver wrote:
The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way. Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything. Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system? -jc On 4/9/2019 12:12 AM, Christian Herzog wrote:Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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
-- Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
list Christian Herzog
FPING should be the path to fping (/usr/sibn/fping?) not xymonping.
you're right. The frankensteined Debian package I built for 4.4 alpha didn't set that correctly. I now compared all config values to our production setup, but FPING was the only notable difference. Anyway, the status is the same as yesterday: for a v6 only host, conn is now green, but http and ssh stay red (DNS error) current xymonnet debug log: https://people.phys.ethz.ch/~daduke/xymonnet-log @JC: how can I debug this further? What other (IPv6 related) test would be interesting for you? thanks, -Christian
▸
-----Original Message----- From: Xymon <xymon-bounces at xymon.com> On Behalf Of Christian Herzog Sent: Thursday, April 11, 2019 3:46 AM To: xymon at xymon.com Subject: Re: [Xymon] IPv6 debugging on xymon 4.4 (was Re: Roadmap/GitHub?/IPv6) ok I'll answer in reverse order... - compiled and tested r8048 - same issue: conn is red for IPv6-only hosts - fping: there wasn't any :) I now installed fping 4.2 (buster). no change. - in xymonserver.cfg I have FPING="xymonping" - is that correct? seems to be the default - xymonnet --debug log is here: https://people.phys.ethz.ch/~daduke/xymonnet-log - most interesting line might be DNS lookup failed for ipv6.daduke.org - status DNS server returned answer with no data (1), but 'host ipv6.daduke.org' works and 3 lines later xymonnet says Adding tcp test IP=2a01:4f8:162:464::113 thanks, -Christian On 4/9/19 6:33 PM, Japheth Cleaver wrote:The first is the correct way of writing it, however the second really should be accepted as well IMO since it's not uncommon for things to be written that way. Most of the response in https://lists.xymon.com/archive/2016-October/043993.html is about using both a 4.3.# and a 4.4-x xymon server as the destination points simultaneously. The 4.3 branch won't recognize or record the IPv6 IPs properly. So long as you're running 4.4-alpha in a normal fashion (talking to itself) it should work fine -- no separate hosts file needed or anything. Can you send the relevant sections of xymmonet.log when running it in --debug mode? Also, what version of fping are you running on the system? -jc On 4/9/2019 12:12 AM, Christian Herzog wrote:Hi JC, I now compiled 4.4 alpha and set up a test server. IPv4 monitoring is working as expected. Can you remind me how to specify IPv6 tests? I found https://lists.xymon.com/archive/2016-October/043993.html but can't make much sense of it. in particular: - do I need any compile switches to enable IPv6 support? - how to specify a v6 host? I tried 2a01:4f8:162:464::113 testhost and [2a01:4f8:162:464::113] testhost the first yields conn red and the second doesn't work at all - separate v6 hosts file ok, how to make it known then? thanks, -Christian On Fri, Apr 05, 2019 at 08:53:39AM -0700, Japheth Cleaver wrote:Hi Christian, That's actually really great to hear. The current 4.4 alpha would be https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/ I'll probably branch that after forward porting these patches coming in to 4.3.29, and trying to reduce some of the warnings I'm seeing in compiles. In the meantime, any validation from snapshots off that branch would be helpful. Regards, -jc On 4/5/2019 4:47 AM, Christian Herzog wrote:hey JC, thanks for the status update. I've done some pretty extensive IPv6 xymon testing 6 years ago ([1] and later private emails with Henrik) and found IPv6 support to be in pretty good shape in then 4.3.99.tgz. However, none of this seems to be in 4.3.28. Since we're now once again (and for reals this time!) on the verge of introducing IPv6 into our networks, I'll have to come back to working on xymon IPv6. I'd be happy to do all sorts of testing, but where to start? I can't even find any 4.4 (alpha) tree out there. Can you advise? thanks and best regards, -Christian [1] https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support On Fri, Mar 08, 2019 at 06:46:52AM -0800, Japheth Cleaver wrote: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-- Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/ This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-- Dr. Christian Herzog <user-5bd58cd9da64@xymon.invalid> support: +41 44 633 26 68 IT Services Group, HPT H 8 voice: +41 44 633 39 50 Department of Physics, ETH Zurich 8093 Zurich, Switzerland http://nic.phys.ethz.ch/
list Japheth Cleaver
▸
On 4/11/2019 11:07 PM, Christian Herzog wrote:
FPING should be the path to fping (/usr/sibn/fping?) not xymonping.you're right. The frankensteined Debian package I built for 4.4 alpha didn't set that correctly. I now compared all config values to our production setup, but FPING was the only notable difference.
I think it might be worth it to officially retire xymonping in the 4.x branch, as it'll need to be updated for IPv6 as well and fping development seems to be healthy and reliable on platforms. Or at the very least, gate it for IPv6 building in the short term.
▸
Anyway, the status is the same as yesterday: for a v6 only host, conn is now green, but http and ssh stay red (DNS error) current xymonnet debug log: https://people.phys.ethz.ch/~daduke/xymonnet-log @JC: how can I debug this further? What other (IPv6 related) test would be interesting for you?
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity routines in lib/tcplib.c are being used for IPv6 connectivity in sending *messages* back and forth between xymon servers and clients, but not for network testing. For the short term, testing xymonclient messaging and xymond record management (using conn tests as sources) might be the most useful. xymonnet/TCP polling will take some additional patching. Regards, -jc
list Christian Herzog
▸
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivity
I guess it was. Rereading my correspondence with Henrik from 6 years ago, it seems we had it pretty much working using xymonnet2 at that time: https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support (see my last message in that thread). I have no idea what has happened in the xymon source tree during those 6 years, and of course I don't have that config any more, but if we could reproduce those results we might be one step closer.
For the short term, testing xymonclient messaging meaning client reports to IPv6 XYMONSERVERS?
▸
and xymond record management (using conn tests as sources) might be the most useful.
meaning what exactly? I'll go right ahead with those tests and stand by for any xymonnet2 trials you might come up with. cheers, -Christian
list Japheth Cleaver
▸
On 4/14/2019 11:53 PM, Christian Herzog wrote:
Looking at xymonnet.c and contest.c, I'm actually suspecting here that we're not building NET6 connections at all in xymonnet tests, which means there's more connecting work left to do than expected. I'm not sure if the original plan was to migrate to xymonnet2 before IPv6. The factored-out connectivityI guess it was. Rereading my correspondence with Henrik from 6 years ago, it seems we had it pretty much working using xymonnet2 at that time: https://xymon.xymon.narkive.com/BbXHR8kH/status-of-ipv6-support (see my last message in that thread). I have no idea what has happened in the xymon source tree during those 6 years, and of course I don't have that config any more, but if we could reproduce those results we might be one step closer.
Agreed. I'm a bit torn at the xymonnet v xymonnet2 split here, simply due to how some of the code diverges at this point. I suspect adding IPv6 branching into xymonnet will be easier (or at least easier to validate).
▸
For the short term, testing xymonclient messaging meaning client reports to IPv6 XYMONSERVERS? and xymond record management (using conn tests as sources) might be the most useful.meaning what exactly?
Correct. xymonproxy is another component that will need work, but client->xymond and anything at all (xymonnet/xymongen, etc) talking to an IPv6-only xymond would be very helpful. xymongen needs to download full xymondboard copies from xymond, so it's really about catching any assumptions out there on IP size or host lookups. Would be good to disable BFQ too if it's enabled, since local components will short-circuit to using that for message submission instead of TCP in 4.x
▸
I'll go right ahead with those tests and stand by for any xymonnet2 trials you might come up with.
Thanks! I'll be focusing on 4.3.29 this week, so this will definitely help. -jc
list Christian Herzog
▸
Agreed. I'm a bit torn at the xymonnet v xymonnet2 split here, simply due to how some of the code diverges at this point. I suspect adding IPv6 branching into xymonnet will be easier (or at least easier to validate).
this decision is way above my paygrade :) But we (the xymon community) need to do something since IPv6 is coming, and fast.
▸
and xymond record management (using conn tests as sources) might be the most useful.meaning what exactly?Correct. xymonproxy is another component that will need work, but client->xymond and anything at all (xymonnet/xymongen, etc) talking to an IPv6-only xymond would be very helpful. xymongen needs to download full xymondboard copies from xymond, so it's really about catching any assumptions out there on IP size or host lookups.
can you be more specific about what you would like to have tested? what I can say already:
▸
For the short term, testing xymonclient messaging meaning client reports to IPv6 XYMONSERVERS?
specifying IPv6 XYMONSERVERS on the client doesn't work. No reports coming in. also, any hosts.cfg entry seems to get resolved to IPv4 only, even if the host entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack host, conn turns red even if IPv6 is working fine. Probably xymonnet <-> xymonnet2 again.
▸
Would be good to disable BFQ too if it's enabled, since local components will short-circuit to using that for message submission instead of TCP in 4.x
this [1] BFQ? *confused*[1] https://algo.ing.unimo.it/people/paolo/disk_sched/ I've also been thinking about how I would like xymon to behave on dual stack hosts: in my experience, IPv4 networks are still quite a bit more stable than IPv6 (I've seen sporadic PD issues, sudden IPv6 routing problems in the middle of Europe etc), so ideally we would have v4/v6 tests on supported services on dual stack hosts. I don't know if this means splitting each tests into two halves or duplicate the whole host entry or something else entirely, but we need to be able to deal with "v4 is working but v6 isn't" or vice versa.... thanks, -Christian
list Christian Herzog
for reference, I compiled xymon-4.3.99-20130812.tar.gz from https://www.xymon.com/misc/ (the source I had been testing with 6 years ago) and lo and behold, IPv6 only hosts work fine! I have no idea what the difference between this old tgz and current trunk is, but at least in terms of IPv6 there seems to be a regression. HTH, -Christian
▸
also, any hosts.cfg entry seems to get resolved to IPv4 only, even if the host entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack host, conn turns red even if IPv6 is working fine. Probably xymonnet <-> xymonnet2 again.
list Japheth Cleaver
▸
On 4/17/2019 6:24 AM, Christian Herzog wrote:
for reference, I compiled xymon-4.3.99-20130812.tar.gz from https://www.xymon.com/misc/ (the source I had been testing with 6 years ago) and lo and behold, IPv6 only hosts work fine! I have no idea what the difference between this old tgz and current trunk is, but at least in terms of IPv6 there seems to be a regression. HTH, -Christian
Thanks. That tarball does indeed use xymonnet2 rather than the existing one, which does help clear that up a bit. Do you think you might be able to test a snapshot of https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk ? That would help isolate issues against the latest in that tree. And for either of these releases, it might be helpful to test xymonnet2 as a poller speaking to a 4.x copy of xymond. In theory, they should be compatible enough to interoperate. -jc
list Japheth Cleaver
▸
On 4/15/2019 11:28 PM, Christian Herzog wrote:
For the short term, testing xymonclient messagingmeaning client reports to IPv6 XYMONSERVERS?specifying IPv6 XYMONSERVERS on the client doesn't work. No reports coming in.
Thanks.
▸
also, any hosts.cfg entry seems to get resolved to IPv4 only, even if the host entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack host, conn turns red even if IPv6 is working fine. Probably xymonnet <-> xymonnet2 again.Would be good to disable BFQ too if it's enabled, since local components will short-circuit to using that for message submission instead of TCP in 4.x this [1] BFQ? *confused*
Sorry, the "backfeed queue" :) See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.backfeed The short of it is that it provides an alternate way of submitting messages to xymond for local processes, using SysV-IPC instead of localhost TCP connections. It's much more efficient for injecting lots of messages, but sort of obviates the testing of xymond submissions over IPv6 :)
▸
I've also been thinking about how I would like xymon to behave on dual stack hosts: in my experience, IPv4 networks are still quite a bit more stable than IPv6 (I've seen sporadic PD issues, sudden IPv6 routing problems in the middle of Europe etc), so ideally we would have v4/v6 tests on supported services on dual stack hosts. I don't know if this means splitting each tests into two halves or duplicate the whole host entry or something else entirely, but we need to be able to deal with "v4 is working but v6 isn't" or vice versa....
Looking into this more, I believe we'll be able to use the existing "conn" framework for handling multiple IP addresses, but we may need a default set of flags for how to handle priority and fallbacks on DNS lookup. I'd envision something along the lines of: IPv4 Only IPv4 Mandatory/IPv6 Optional IPv4 Optional/IPv6 Mandatory IPv6 Only xymonnet can have a set of flags, but this we'd also want the ability to set flags for for each host. For non-http checks, a "testip" combined with the choice of dedicated address (of either type) in hosts.cfg should keep checks hitting only one protocol or the other. Regards, -jc
list Adam Goryachev
▸
On 18/4/19 06:45, Japheth Cleaver wrote:
On 4/15/2019 11:28 PM, Christian Herzog wrote:For the short term, testing xymonclient messagingmeaning client reports to IPv6 XYMONSERVERS?specifying IPv6 XYMONSERVERS on the client doesn't work. No reports coming in.Thanks.also, any hosts.cfg entry seems to get resolved to IPv4 only, even if the host entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack host, conn turns red even if IPv6 is working fine. Probably xymonnet <-> xymonnet2 again.Would be good to disable BFQ too if it's enabled, since local components will short-circuit to using that for message submission instead of TCP in 4.x this [1] BFQ? *confused*Sorry, the "backfeed queue" :) See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.backfeed The short of it is that it provides an alternate way of submitting messages to xymond for local processes, using SysV-IPC instead of localhost TCP connections. It's much more efficient for injecting lots of messages, but sort of obviates the testing of xymond submissions over IPv6 :)I've also been thinking about how I would like xymon to behave on dual stack hosts: in my experience, IPv4 networks are still quite a bit more stable than IPv6 (I've seen sporadic PD issues, sudden IPv6 routing problems in the middle of Europe etc), so ideally we would have v4/v6 tests on supported services on dual stack hosts. I don't know if this means splitting each tests into two halves or duplicate the whole host entry or something else entirely, but we need to be able to deal with "v4 is working but v6 isn't" or vice versa....Looking into this more, I believe we'll be able to use the existing "conn" framework for handling multiple IP addresses, but we may need a default set of flags for how to handle priority and fallbacks on DNS lookup. I'd envision something along the lines of: IPv4 Only IPv4 Mandatory/IPv6 Optional IPv4 Optional/IPv6 Mandatory IPv6 Only xymonnet can have a set of flags, but this we'd also want the ability to set flags for for each host. For non-http checks, a "testip" combined with the choice of dedicated address (of either type) in hosts.cfg should keep checks hitting only one protocol or the other.
Sorry, I'm not able to help much since my routers are still all non-IPv6 capable, but wouldn't we also want: IPv4 Mandatory/IPv6 Mandatory In the case that you are operating as a dual stack, you care if v4 only users are unable to access your host, as well as if v6 only users are unable to access? Similarly for testip hosts, we should be able to specify both v4 and v6 address, perhaps the hostname/IP field in the hosts file could be extended to allow a comma separated list of addresses ? As for testing v4 and v6 conn test (or other network tests), why not just combine them in the same way the http test can have multiple results under the same status or the ssl test gets multiple results from https + imaps + pop3s etc all in the same status? I have tried a few times to get into IPv6, but each time, it's been a no go due to some specific issues (either providers not supporting it, my not knowing enough about it, or currently, Cisco routers not supporting it: https://community.meraki.com/t5/Security-SD-WAN/WE-Need-IPV6-Support-in-MX/td-p/1095 https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility Hopefully, one day, it will happen though. Regards, Adam -- Adam Goryachev Website Managers P: +61 2 8304 0000 user-eaec2ffb4cbc@xymon.invalid F: +61 2 8304 0001 www.websitemanagers.com.au
list Adam Goryachev
On 18/4/19 06:45, Japheth Cleaver wrote:
On 4/15/2019 11:28 PM, Christian Herzog wrote:For the short term, testing xymonclient messagingmeaning client reports to IPv6 XYMONSERVERS?specifying IPv6 XYMONSERVERS on the client doesn't work. No reports coming in.Thanks.also, any hosts.cfg entry seems to get resolved to IPv4 only, even if the host entry is IPv6. As soon as I cut IPv4 connectivity on a dual stack host, conn turns red even if IPv6 is working fine. Probably xymonnet <-> xymonnet2 again.Would be good to disable BFQ too if it's enabled, since local components will short-circuit to using that for message submission instead of TCP in 4.x this [1] BFQ? *confused*Sorry, the "backfeed queue" :) See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.backfeed The short of it is that it provides an alternate way of submitting messages to xymond for local processes, using SysV-IPC instead of localhost TCP connections. It's much more efficient for injecting lots of messages, but sort of obviates the testing of xymond submissions over IPv6 :)I've also been thinking about how I would like xymon to behave on dual stack hosts: in my experience, IPv4 networks are still quite a bit more stable than IPv6 (I've seen sporadic PD issues, sudden IPv6 routing problems in the middle of Europe etc), so ideally we would have v4/v6 tests on supported services on dual stack hosts. I don't know if this means splitting each tests into two halves or duplicate the whole host entry or something else entirely, but we need to be able to deal with "v4 is working but v6 isn't" or vice versa....Looking into this more, I believe we'll be able to use the existing "conn" framework for handling multiple IP addresses, but we may need a default set of flags for how to handle priority and fallbacks on DNS lookup. I'd envision something along the lines of: IPv4 Only IPv4 Mandatory/IPv6 Optional IPv4 Optional/IPv6 Mandatory IPv6 Only xymonnet can have a set of flags, but this we'd also want the ability to set flags for for each host. For non-http checks, a "testip" combined with the choice of dedicated address (of either type) in hosts.cfg should keep checks hitting only one protocol or the other.
Sorry, I'm not able to help much since my routers are still all non-IPv6 capable, but wouldn't we also want: IPv4 Mandatory/IPv6 Mandatory In the case that you are operating as a dual stack, you care if v4 only users are unable to access your host, as well as if v6 only users are unable to access? Similarly for testip hosts, we should be able to specify both v4 and v6 address, perhaps the hostname/IP field in the hosts file could be extended to allow a comma separated list of addresses ? As for testing v4 and v6 conn test (or other network tests), why not just combine them in the same way the http test can have multiple results under the same status or the ssl test gets multiple results from https + imaps + pop3s etc all in the same status? I have tried a few times to get into IPv6, but each time, it's been a no go due to some specific issues (either providers not supporting it, my not knowing enough about it, or currently, Cisco routers not supporting it: https://community.meraki.com/t5/Security-SD-WAN/WE-Need-IPV6-Support-in-MX/td-p/1095 https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility Hopefully, one day, it will happen though. Regards, Adam
list Christian Herzog
▸
Do you think you might be able to test a snapshot of https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk ? That would help isolate issues against the latest in that tree.
I had all sorts of problems getting this compiled, and it's not running well either: conn/ping is missing, most hosts don't show any tests and I get multiple errors in the logs: - Task xymond terminated by signal 6 - Whoops ! Failed to send message (Connection failed) - Cannot load hosts.cfg from xymond, code 5 - Failed to load from xymond, reverting to file-load - Failed to get a message, terminating etc
▸
And for either of these releases, it might be helpful to test xymonnet2 as a poller speaking to a 4.x copy of xymond. In theory, they should be compatible enough to interoperate.
the point here is that only the 2013 tarball and r8050 have xymonnet2, while r8048 does not. In 2013 it seems to be working fine, in r8050 it's not (see above). -d
list Christian Herzog
▸
Sorry, the "backfeed queue" :) See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.backfeed The short of it is that it provides an alternate way of submitting messages to xymond for local processes, using SysV-IPC instead of localhost TCP connections. It's much more efficient for injecting lots of messages, but sort of obviates the testing of xymond submissions over IPv6 :)
I see.
▸
Looking into this more, I believe we'll be able to use the existing "conn" framework for handling multiple IP addresses, but we may need a default set of flags for how to handle priority and fallbacks on DNS lookup. I'd envision something along the lines of: IPv4 Only IPv4 Mandatory/IPv6 Optional IPv4 Optional/IPv6 Mandatory IPv6 Only
I agree with Adam and even think
IPv4 Mandatory/IPv6 Mandatory would be the default in our case.
I'll be ready to perform more tests after the Easter break. cheers, -d