The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta.

Att, [cid:image001.png at 01D4D589.53709530]

De: Richard L. Hamilton <rlhamil2 at gmail.com> Enviada em: quinta-feira, 7 de março de 2019 17:54 Para: Felipe Ribeiro <felipe at redix.com.br> Cc: Ian Diddams via Xymon <xymon at xymon.com> Assunto: Re: [Xymon] Is the xymon Dead? Future

You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.

On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br<mailto:felipe at redix.com.br>> wrote:

Hello, I'm working on a company that uses xymon for almost the beggining.

We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.

But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.

So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?

Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?

Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon

Hello All,

I agree with SebA on this issue. I count on Xymon and it has proven itself many times over. But there needs to be seen a roadmap. I get comments about Xymon being so 80's but I answer back with how Xymon gets the job done. But we are in seriously changing times with so much being done in the virtual, containerized and micro-kernel areas. There is an array of "cloud" hosting options. Maybe a discussion is needed on what Xymon will do and will not do in the future.

On Fri, Mar 8, 2019 at 6:11 AM SebA <spah at syntec.co.uk> wrote:

The lack of releases (and commits - there are commits after the last release, but only 2) on the *nix side is concerning. IPv6 support may have been something that people thought would be needed, and then wasn't so much in demand, but I think that demand would be there if Xymon had good support for Docker container monitoring. With the increasing use of Docker, Xymon needs to be able monitor Docker containers or it will die a slow death (and it may already be too late).

Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. Git, specifically GitHub, has replaced SVN as the best thing to promote community contributions, and I think it would be beneficial if the official Xymon code repos are migrated to GitHub. (There is an unofficial sync project to sync a lot of SVN projects to GitHub but the project has recently closed: https://github.com/svn2github/xymon)

Kind regards,

SebA

On Fri, 8 Mar 2019 at 12:02, Felipe Ribeiro <felipe at redix.com.br> wrote:

...

The last update that I could find is the 4.3.28 dated on 2017-01-18 since them I don’t see any other update even alpha/beta.

Att,

*De:* Richard L. Hamilton <rlhamil2 at gmail.com> *Enviada em:* quinta-feira, 7 de março de 2019 17:54 *Para:* Felipe Ribeiro <felipe at redix.com.br> *Cc:* Ian Diddams via Xymon <xymon at xymon.com> *Assunto:* Re: [Xymon] Is the xymon Dead? Future

You can see updates being checked in at the sourceforge repository, so it's not dead. Someone doing the work will have to tell you what features may be added. IPv6 support has been one of those, but I don't know how much progress has been made.

On Mar 7, 2019, at 13:13, Felipe Ribeiro <felipe at redix.com.br> wrote:

Hello,

I'm working on a company that uses xymon for almost the beggining.

We enjoy the view that xymon can provid us, using html plugin, we could make some very good sensors.

But, we are afraid mainly cause the last update whore on 2017, and we don’t know for how long it will be compatible with clients.

So, my questions are, what's next? There’s something going on with the project? It'll someday gain an MYSQL historic ?

Or, even there's some monitoring system that you are looking at with the same organized visual aspect (Page -> Group -> Host -> Plugin) ?

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

--

*----------------------------------------*

• Jim Louis          \\\\||////          \ ~ ~  /          | @ @ |*

*--oOo---(_)---oOo--*

“It does me no injury for my neighbor to say there are twenty gods, or no God. It neither picks my pocket nor breaks my leg.”

~ Thomas Jefferson

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 <herzog at phys.ethz.ch> 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/

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

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

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

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

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- Dr. Christian Herzog <herzog at phys.ethz.ch> 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/

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

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- Dr. Christian Herzog <herzog at phys.ethz.ch> 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/

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon 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.

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

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 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.

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

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.

• 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).

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:

-d

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 messaging

...

...

meaning 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.ba...

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/t... https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...

Hopefully, one day, it will happen though.

Regards, Adam

-- Adam Goryachev Website Managers P: +61 2 8304 0000 adam at websitemanagers.com.au F: +61 2 8304 0001 www.websitemanagers.com.au

Sorry, the "backfeed queue" :)

See README.backfeed: https://sourceforge.net/p/xymon/code/HEAD/tree/branches/4.x-master/README.ba...

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

Hi,

On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:

On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:

...

Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.

I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.

...

Git, specifically GitHub, has replaced SVN as the best thing to promote community contributions, and I think it would be beneficial if the official Xymon code repos are migrated to GitHub.

Definitely, but it's also not the only thing which is needed for getting contributions from external contributors. It's also a social thing.

Reviewing and accepting contributions — or maybe even giving trustworthy contributors commit access is also necessary for a FLOSS project. But as far as I can tell, this happens in the Xymon project, although not on a daily base.

but github would allow the community to report issues,

SF does allow that, too, it's just not enabled for the Xymon project on SF. Example of an SF project where it is enabled: https://sourceforge.net/p/nfsen/bugs/

provide updates/patches via pull requests,

Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/

and download either released versions via the tags

Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27

if necessary or the latest code via the 'develop' (or whatever) branch.

https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk

Don't get me wrong: I think SF degraded from once the best place to host FLOSS to a website with tons of outdated trash and the most horrible UI I ever saw from a code hosting site. Not to mention that it is far too overladen with ads and popup.

My personal preference in VCS hosters is also GitHub as — from my point of view — they currently provide the best user experience. OTOH there might be some qualms about Github being not completely open source and being owned by Microsoft.

And with regards to being dead or not: Development greatly sped up when J.C. Cleaver took over release management, but it indeed seems to have stalled a little bit again. Then again, IIRC J.C. mostly took over release management so that Henrik can focus on long-time development. And if there is not much to fix in the current stable releases, not having a stable release every few months is not necessarily "dead", but might also be "stable, no relevant open issues".

(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)

	Kind regards, Axel

-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/

I believe this one is in the pipe for version 4.4 but could be wrong.

JP Pitout

From: Xymon <xymon-bounces at xymon.com> on behalf of Ralph Mitchell <ralphmitchell at gmail.com> Sent: 08 March 2019 17:40 To: Axel Beckert Cc: xymon at xymon.com Subject: Re: [Xymon] RES: Is the xymon Dead? Future

I'd still like to see encrypted connections for Xymon client messages going to the server.

Ralph Mitchell

On Fri, Mar 8, 2019, 10:09 AM Axel Beckert <abe at deuxchevaux.org<mailto:abe at deuxchevaux.org>> wrote: Hi,

On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:

On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:

...

Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions.

I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.

...

Git, specifically GitHub, has replaced SVN as the best thing to promote community contributions, and I think it would be beneficial if the official Xymon code repos are migrated to GitHub.

Definitely, but it's also not the only thing which is needed for getting contributions from external contributors. It's also a social thing.

Reviewing and accepting contributions - or maybe even giving trustworthy contributors commit access is also necessary for a FLOSS project. But as far as I can tell, this happens in the Xymon project, although not on a daily base.

but github would allow the community to report issues,

SF does allow that, too, it's just not enabled for the Xymon project on SF. Example of an SF project where it is enabled: https://sourceforge.net/p/nfsen/bugs/

provide updates/patches via pull requests,

Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/

and download either released versions via the tags

Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27

if necessary or the latest code via the 'develop' (or whatever) branch.

https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk

Don't get me wrong: I think SF degraded from once the best place to host FLOSS to a website with tons of outdated trash and the most horrible UI I ever saw from a code hosting site. Not to mention that it is far too overladen with ads and popup.

My personal preference in VCS hosters is also GitHub as - from my point of view - they currently provide the best user experience. OTOH there might be some qualms about Github being not completely open source and being owned by Microsoft.

And with regards to being dead or not: Development greatly sped up when J.C. Cleaver took over release management, but it indeed seems to have stalled a little bit again. Then again, IIRC J.C. mostly took over release management so that Henrik can focus on long-time development. And if there is not much to fix in the current stable releases, not having a stable release every few months is not necessarily "dead", but might also be "stable, no relevant open issues".

(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)

            Kind regards, Axel

-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org<mailto:abe at deuxchevaux.org> \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org<mailto:abe at noone.org> X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/

Xymon mailing list Xymon at xymon.com<mailto:Xymon at xymon.com> http://lists.xymon.com/mailman/listinfo/xymon

"This email is confidential. If you have received it in error, you are on notice of its status. Please notify us immediately by reply email and then delete this message from your system. Please do not copy it or use it for any purpose, or disclose its contents to any other person as to do so could be a breach of confidentiality. Thank you for your co-operation. "

"The information contained in this message is intended solely for the individual to whom it is specifically and originally addressed. This message and its contents may contain confidential or privileged information from MTN Group. If you are not the intended recipient, you are hereby notified that any disclosure or distribution, is strictly prohibited. If you receive this email in error, please notify MTN Group immediately and delete it. MTN Group does not accept any liability or responsibility if action is taken in reliance on the contents of this information . Note that all personal emails are not authorized by MTN Group. "

In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.

On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:

Hi Ralph,

On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:

...

I'd still like to see encrypted connections for Xymon client messages going to the server.

Yeah, this definitely is a feature which would be very nice to available out of the box.

Nevertheless you can do that already now with stunnel as I mentioned:

...

...

(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)

Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.

The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.

It also refers to this more detailed documentation: https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...

HTH!

  Kind regards, Axel

-- PGP: 2FF9CD59612616B5 /~\ Plain Text Ribbon Campaign, http://arc.pasp.de/ Mail: abe at deuxchevaux.org \ / Say No to HTML in E-Mail and Usenet Mail+Jabber: abe at noone.org X https://axel.beckert.ch/ / \ I love long mails: https://email.is-not-s.ms/

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

I just make sure I have a VPN or a private LAN between whatever machine runs the xymon client and the xymon server.

On Fri, 8 Mar 2019, Bruce Ferrell wrote:

Date: Fri, 8 Mar 2019 18:10:15 -0800 From: Bruce Ferrell <bferrell at baywinds.org> To: xymon at xymon.com Subject: Re: [Xymon] Encrypted Xymon reporting over SSL using stunnel

I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me.

People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK!

For real hilarity, make them expire ten years out.  By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry said right before the big crash, IBG, UBG (I be gone, you be gone).

From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.

"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really?   If we do care then we deny communication/ignore messages. Now we've lost reporting links and visibility.

Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we get the issue of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT?

On 3/8/19 11:28 AM, Richard L. Hamilton wrote:

...

In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from elsewhere isn't being provided.

...

On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org> wrote:

Hi Ralph,

On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:

...

I'd still like to see encrypted connections for Xymon client messages going to the server. Yeah, this definitely is a feature which would be very nice to available out of the box.

Nevertheless you can do that already now with stunnel as I mentioned:

...

...

(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.) Debian's xymon package ships /usr/share/doc/xymon/README.encryption with hints how to implement encrypted reporting with Xymon.

The current version can be found in our packaging git repository at https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption although I'm thinking about renaming it to README.encryption.md as I wrote it in Markdown syntax.

It also refers to this more detailed documentation:

https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu...

...

HTH!

  Kind regards, Axel

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

SebA,

You're right, saltstack is doing the same as using ssh keys.... For all intents and purposes an ssh connection/tunnel or an stunnel.

No need to build that into xymon.  Just do it externally and call it a day. And it still has the key distribution/management issue.

That said, if/when tunnels go down... And they do, then reporting is lost and intervention is often required.

The itch to "build in" what can be done outside, in my experience, should almost never be scratched.

It's too easy to make things over complicated for little to no pay off.

On 3/12/19 6:50 AM, SebA wrote:

The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well.  I don't believe they expire.  It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.

Kind regards,

SebA

On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:

I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me.


People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK!

For real hilarity, make them expire ten years out.  By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry said right
before the big crash, IBG, UBG (I be gone, you be gone).

 From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.

"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really?   If
we do
care then we deny communication/ignore messages. Now we've lost reporting links and visibility.

Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we get the
issue
of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT?




On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
> In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the
client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that
assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from
elsewhere isn't being provided.
>
>> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote:
>>
>> Hi Ralph,
>>
>> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
>>> I'd still like to see encrypted connections for Xymon client messages going
>>> to the server.
>> Yeah, this definitely is a feature which would be very nice to
>> available out of the box.
>>
>> Nevertheless you can do that already now with stunnel as I mentioned:
>>
>>>> (And yes, I'm still hoping and waiting for IPv6 support, too,
>>>> especially in xymonnet-based checks. Reporting to IPv6-only servers is
>>>> no issue though, if you anyways use stunnel to encrypt the
>>>> client-reporting traffic.)
>> Debian's xymon package ships /usr/share/doc/xymon/README.encryption
>> with hints how to implement encrypted reporting with Xymon.
>>
>> The current version can be found in our packaging git repository at
>> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
>> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> as I
>> wrote it in Markdown syntax.
>>
>> It also refers to this more detailed documentation:
>> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
>>
>> HTH!
>>
>>              Kind regards, Axel

_______________________________________________
Xymon mailing list
Xymon at xymon.com <mailto:Xymon at xymon.com>
http://lists.xymon.com/mailman/listinfo/xymon

...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours!  cross our palms with MUCH silver" (probably based on OSS, but thats' never stopped anyone).

Taking me back to "do it outside of xymon" for cleanliness sake.

On 3/12/19 6:50 AM, SebA wrote:

The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well.  I don't believe they expire.  It's been a while since I looked at it, so I couldn't tell you exactly how it works, but there's some information here: https://docs.saltstack.com/en/getstarted/system/communication.html Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.

Kind regards,

SebA

On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:

I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me.


People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK!

For real hilarity, make them expire ten years out.  By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry said right
before the big crash, IBG, UBG (I be gone, you be gone).

 From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.

"But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed really?   If
we do
care then we deny communication/ignore messages. Now we've lost reporting links and visibility.

Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we get the
issue
of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT?




On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
> In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good if the
client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that
assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from
elsewhere isn't being provided.
>
>> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote:
>>
>> Hi Ralph,
>>
>> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
>>> I'd still like to see encrypted connections for Xymon client messages going
>>> to the server.
>> Yeah, this definitely is a feature which would be very nice to
>> available out of the box.
>>
>> Nevertheless you can do that already now with stunnel as I mentioned:
>>
>>>> (And yes, I'm still hoping and waiting for IPv6 support, too,
>>>> especially in xymonnet-based checks. Reporting to IPv6-only servers is
>>>> no issue though, if you anyways use stunnel to encrypt the
>>>> client-reporting traffic.)
>> Debian's xymon package ships /usr/share/doc/xymon/README.encryption
>> with hints how to implement encrypted reporting with Xymon.
>>
>> The current version can be found in our packaging git repository at
>> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
>> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> as I
>> wrote it in Markdown syntax.
>>
>> It also refers to this more detailed documentation:
>> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
>>
>> HTH!
>>
>>              Kind regards, Axel

_______________________________________________
Xymon mailing list
Xymon at xymon.com <mailto:Xymon at xymon.com>
http://lists.xymon.com/mailman/listinfo/xymon

SebA

I think mentioned this in another thread.  I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.

I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.

Using code from a commercial entity (even with an apache license)  raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.

Integrating functionality that already exists through well understood, more general  mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that).  The difference in the codebase alone should cause someone to think very hard about that kind of merge.

Looking more closely at SaltStack, I see it would add  addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!).  MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!

Maybe better documentation of secure message distribution?  There used to be one on how to pull client updates via ssh.  That's secure AND simple.  It doesn't sign the updates but that could be a reasonable add-on to the documentation.

For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.

On 3/12/19 8:55 AM, SebA wrote:

There is a commercial version, but this code is open source: https://github.com/saltstack/salt I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering.  It looks  like it's using the Apache licence.

Kind regards,

SebA

On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:

...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours!  cross our palms with MUCH silver" (probably based on OSS, but
thats' never stopped anyone).

Taking me back to "do it outside of xymon" for cleanliness sake.


On 3/12/19 6:50 AM, SebA wrote:
> The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well.  I don't believe they expire.  It's been a while since I looked
at it,
> so I couldn't tell you exactly how it works, but there's some information here:
> https://docs.saltstack.com/en/getstarted/system/communication.html
> Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
>
> Kind regards,
>
> SebA
>
>
>
> On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote:
>
>
>     I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me.
>
>
>     People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK!
>
>     For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry
said right
>     before the big crash, IBG, UBG (I be gone, you be gone).
>
>      From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.
>
>     "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed
really?   If
>     we do
>     care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
>
>     Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we
get the
>     issue
>     of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT?
>
>
>
>
>     On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
>     > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good
if the
>     client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that
>     assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from
>     elsewhere isn't being provided.
>     >
>     >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>> wrote:
>     >>
>     >> Hi Ralph,
>     >>
>     >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
>     >>> I'd still like to see encrypted connections for Xymon client messages going
>     >>> to the server.
>     >> Yeah, this definitely is a feature which would be very nice to
>     >> available out of the box.
>     >>
>     >> Nevertheless you can do that already now with stunnel as I mentioned:
>     >>
>     >>>> (And yes, I'm still hoping and waiting for IPv6 support, too,
>     >>>> especially in xymonnet-based checks. Reporting to IPv6-only servers is
>     >>>> no issue though, if you anyways use stunnel to encrypt the
>     >>>> client-reporting traffic.)
>     >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption
>     >> with hints how to implement encrypted reporting with Xymon.
>     >>
>     >> The current version can be found in our packaging git repository at
>     >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
>     >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> as I
>     >> wrote it in Markdown syntax.
>     >>
>     >> It also refers to this more detailed documentation:
>     >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
>     >>
>     >> HTH!
>     >>
>     >>              Kind regards, Axel
>
>     _______________________________________________
>     Xymon mailing list
> Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>>
> http://lists.xymon.com/mailman/listinfo/xymon
>

SebA,

We agree on a lot, including the licenses.  We do NOT agree on taking risks.  Again, the concepts for secure transport ARE actually served in the good old, "pull from the client via ssh using keys" method, rather than the client push to the server. Yes, you DO actually have to do SOME setup for that to work.  The fact that it's NOT well known isn't a good reason to add a LOT of additional code to xymon.

I've had to cope with WAY too many issues around Python to have ANY trust of it.

I've had to deal far too often with Python code that "works on your machine, but not on mine" WAY too may times then had experts look and say "I'll have dig into it for a day to figure out why it does that... It's not supposed to do that".  It's not inherent in the language, but in practices around the language.

I can, and do code in it if I absolutely must, but avoid it when I can.  Yes, many, many other people like that complicated things can be built with it quickly and I didn't mean this to become bike shed discussion around language.

The kinds of issues I spoke of give ME the heebie jeebies when it comes to tools I use regularly.

On 3/12/19 10:16 AM, SebA wrote:

Hi Bruce,

Yes, I've been using the same since 2002 as well, but I disagree on the legal issue.  The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it.  Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!

Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well.  I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open.  Anyway, the key generation and encryption stuff is separate to the communication - Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.

Kind regards,

SebA

On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:

SebA

I think mentioned this in another thread.  I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.

I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.

Using code from a commercial entity (even with an apache license)  raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find
useful
at risk.

Integrating functionality that already exists through well understood, more general  mechanisms makes it special purpose functionality and THAT makes it less reliable...
Especially
in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this
discussion about that).  The difference in the codebase alone should cause someone to think very hard about that kind of merge.

Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase
security/reliability?!).  MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!

Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple.  It doesn't sign the updates but
that could be a reasonable add-on to the documentation.

For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.


On 3/12/19 8:55 AM, SebA wrote:
> There is a commercial version, but this code is open source: https://github.com/saltstack/salt
> I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering.  It looks  like it's using the
Apache
> licence.
>
> Kind regards,
>
> SebA
>
>
>
> On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote:
>
>     ...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours!  cross our palms with MUCH silver" (probably based on
OSS, but
>     thats' never stopped anyone).
>
>     Taking me back to "do it outside of xymon" for cleanliness sake.
>
>
>     On 3/12/19 6:50 AM, SebA wrote:
>     > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well.  I don't believe they expire.  It's been a while since I looked
>     at it,
>     > so I couldn't tell you exactly how it works, but there's some information here:
>     > https://docs.saltstack.com/en/getstarted/system/communication.html
>     > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral.
>     >
>     > Kind regards,
>     >
>     > SebA
>     >
>     >
>     >
>     > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>
<mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>>> wrote:
>     >
>     >
>     >     I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me.
>     >
>     >
>     >     People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK!
>     >
>     >     For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry
>     said right
>     >     before the big crash, IBG, UBG (I be gone, you be gone).
>     >
>     >      From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix.
>     >
>     >     "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed
>     really?   If
>     >     we do
>     >     care then we deny communication/ignore messages. Now we've lost reporting links and visibility.
>     >
>     >     Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we
>     get the
>     >     issue
>     >     of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT?
>     >
>     >
>     >
>     >
>     >     On 3/8/19 11:28 AM, Richard L. Hamilton wrote:
>     >     > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good
>     if the
>     >     client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not
that that
>     >     assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted)
data from
>     >     elsewhere isn't being provided.
>     >     >
>     >     >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>
<mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>>> wrote:
>     >     >>
>     >     >> Hi Ralph,
>     >     >>
>     >     >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote:
>     >     >>> I'd still like to see encrypted connections for Xymon client messages going
>     >     >>> to the server.
>     >     >> Yeah, this definitely is a feature which would be very nice to
>     >     >> available out of the box.
>     >     >>
>     >     >> Nevertheless you can do that already now with stunnel as I mentioned:
>     >     >>
>     >     >>>> (And yes, I'm still hoping and waiting for IPv6 support, too,
>     >     >>>> especially in xymonnet-based checks. Reporting to IPv6-only servers is
>     >     >>>> no issue though, if you anyways use stunnel to encrypt the
>     >     >>>> client-reporting traffic.)
>     >     >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption
>     >     >> with hints how to implement encrypted reporting with Xymon.
>     >     >>
>     >     >> The current version can be found in our packaging git repository at
>     >     >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
>     >     >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> <http://README.encryption.md> as I
>     >     >> wrote it in Markdown syntax.
>     >     >>
>     >     >> It also refers to this more detailed documentation:
>     >     >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
>     >     >>
>     >     >> HTH!
>     >     >>
>     >     >>              Kind regards, Axel
>     >
>     >  _______________________________________________
>     >     Xymon mailing list
>     > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com
<mailto:Xymon at xymon.com>>>
>     > http://lists.xymon.com/mailman/listinfo/xymon
>     >
>

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_D...) still don't support IPv6 either, so it still doesn't seem to be as important as claimed by everyone 10+ years ago when they said we would run out of IPv4 addresses.... It's hard to "change the world", I mean, we still have SMTP and DNS ;)

Regards, Adam

On 13/3/19 4:41 am, Bruce Ferrell wrote:

SebA,

We agree on a lot, including the licenses.  We do NOT agree on taking risks.  Again, the concepts for secure transport ARE actually served in the good old, "pull from the client via ssh using keys" method, rather than the client push to the server. Yes, you DO actually have to do SOME setup for that to work.  The fact that it's NOT well known isn't a good reason to add a LOT of additional code to xymon.

I've had to cope with WAY too many issues around Python to have ANY trust of it.

I've had to deal far too often with Python code that "works on your machine, but not on mine" WAY too may times then had experts look and say "I'll have dig into it for a day to figure out why it does that... It's not supposed to do that".  It's not inherent in the language, but in practices around the language.

I can, and do code in it if I absolutely must, but avoid it when I can.  Yes, many, many other people like that complicated things can be built with it quickly and I didn't mean this to become bike shed discussion around language.

The kinds of issues I spoke of give ME the heebie jeebies when it comes to tools I use regularly.

On 3/12/19 10:16 AM, SebA wrote:

...

Hi Bruce,

Yes, I've been using the same since 2002 as well, but I disagree on the legal issue.  The Apache licence is very free and so long as it is complied with (which is mainly to do with trademarks) there are no problems with it.  Many commercial products integrate OS software that uses the Apache OS licence, and Xymon is not commercial, it's open source too!

Look, I don't know if it's worth using their code or not - I happen to like Python and can program in it (when I can't in C), but as you said, it's a different language, it might not integrate well.  I have seen some communication issues with the Salt Stack, but they're mostly due to not having the right firewall ports open.  Anyway, the key generation and encryption stuff is separate to the communication

• Xymon communication could still use the normal Xymon channel, but use key generation and encryption ideas or code or libraries from somewhere else.

Kind regards,

SebA

On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org>> wrote:

    SebA

    I think mentioned this in another thread.  I've been using BB/xymon/"that thing we can't say because an estate disliked it" since 2002.

    I think many of us went through the demise of BB when Quest/Dell/EMC absorbed/smothered it.

    Using code from a commercial entity (even with an apache license)  raises the spector/risk of past debacles and in my opinion potentially puts a tool I really like and find useful at risk.

    Integrating functionality that already exists through well understood, more general  mechanisms makes it special purpose functionality and THAT makes it less reliable... Especially in that SaltStack is really "just" an orchestrator written in Python (Py, in and of itself is enough for me to give it a pass... Very long story and ask me outside of this discussion about that).  The difference in the codebase alone should cause someone to think very hard about that kind of merge.

    Looking more closely at SaltStack, I see it would add addition transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable transport to increase security/reliability?!).  MQ per the docs, uses HTTP/SSL and now we're back to certs and even further integration of some form HTTP server to do that!

    Maybe better documentation of secure message distribution? There used to be one on how to pull client updates via ssh. That's secure AND simple.  It doesn't sign the updates but that could be a reasonable add-on to the documentation.

    For this purpose, SaltStack looks to me like that old Milton Bradley board game Mouse Trap.

    On 3/12/19 8:55 AM, SebA wrote: > There is a commercial version, but this code is open source: https://github.com/saltstack/salt > I wasn't saying we use their code - although if the licence says that other open source projects can use it, then it is worth considering.  It looks  like it's using the Apache > licence. > > Kind regards, > > SebA > > > > On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>> wrote: > >     ...And looking even closer at saltstack, it's a commercial product, leading to a possible trigger of "that's ours!  cross our palms with MUCH silver" (probably based on OSS, but >     thats' never stopped anyone). > >     Taking me back to "do it outside of xymon" for cleanliness sake. > > >     On 3/12/19 6:50 AM, SebA wrote: >     > The way Salt Minions authenticate and their keys have to be accepted on the Salt Master works pretty well. I don't believe they expire.  It's been a while since I looked >     at it, >     > so I couldn't tell you exactly how it works, but there's some information here: >     > https://docs.saltstack.com/en/getstarted/system/communication.html >     > Anyway, that model would probably work pretty well for Xymon, so long as the reporting client is not ephemeral. >     > >     > Kind regards, >     > >     > SebA >     > >     > >     > >     > On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org> <mailto:bferrell at baywinds.org <mailto:bferrell at baywinds.org>>>> wrote: >     > >     > >     >     I'm not sure which standard is in use here, so I'll just top post like Richard did.  Please don't shoot me. >     > >     > >     >     People always go for certs... And then they expire and stuff starts breaking or alerting right and left all at once.  GACK! >     > >     >     For real hilarity, make them expire ten years out. By that time, no one even remembers that certs were even installed or what they're for.  As the home loan industry >     said right >     >     before the big crash, IBG, UBG (I be gone, you be gone). >     > >     >      From one who has had to deal with such mass silliness, take it from me, it's NO FUN and REALLY tedious to fix. >     > >     >     "But I'll just use the cert for tunnel authentication" I hear you say... If in-authentic communication (even self signed) isn't denied, do we care if it's signed >     really?   If >     >     we do >     >     care then we deny communication/ignore messages. Now we've lost reporting links and visibility. >     > >     >     Some form of message authentication is probably a good idea though.  Just something that doesn't expire and can be revoked as needed.  gpg/pgp keys maybe, but then we >     get the >     >     issue >     >     of gpg/pgp key distribution/signing.  Key per monitored system... Anyone want to manage THAT? >     > >     > >     > >     > >     >     On 3/8/19 11:28 AM, Richard L. Hamilton wrote: >     >     > In the ideal, esp. when the client may have a dynamic IP address (DHCP without reserved addresses, or mobile clients, for example), it would IMO also be really good >     if the >     >     client reports could optionally be signed, with a certificate the server could verify, to give some confidence as to their actually coming from the client...not that that >     >     assures that the actual client wasn't compromised, but it's better than nothing insofar as it at least gives good odds that misleading (or maliciously crafted) data from >     >     elsewhere isn't being provided. >     >     > >     >     >> On Mar 8, 2019, at 11:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org> <mailto:abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>>>> wrote: >     >     >> >     >     >> Hi Ralph, >     >     >> >     >     >> On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph Mitchell wrote: >     >     >>> I'd still like to see encrypted connections for Xymon client messages going >     >     >>> to the server. >     >     >> Yeah, this definitely is a feature which would be very nice to >     >     >> available out of the box. >     >     >> >     >     >> Nevertheless you can do that already now with stunnel as I mentioned: >     >     >> >     >     >>>> (And yes, I'm still hoping and waiting for IPv6 support, too, >     >     >>>> especially in xymonnet-based checks. Reporting to IPv6-only servers is >     >     >>>> no issue though, if you anyways use stunnel to encrypt the >     >     >>>> client-reporting traffic.) >     >     >> Debian's xymon package ships /usr/share/doc/xymon/README.encryption >     >     >> with hints how to implement encrypted reporting with Xymon. >     >     >> >     >     >> The current version can be found in our packaging git repository at >     >     >> https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption >     >     >> although I'm thinking about renaming it to README.encryption.md <http://README.encryption.md> <http://README.encryption.md> <http://README.encryption.md> as I >     >     >> wrote it in Markdown syntax. >     >     >> >     >     >> It also refers to this more detailed documentation: >     >     >> https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Gu... >     >     >> >     >     >> HTH! >     >     >> >     >     >>              Kind regards, Axel >     > >     >  _______________________________________________ >     >     Xymon mailing list >     > Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com> <mailto:Xymon at xymon.com <mailto:Xymon at xymon.com>>> >     > http://lists.xymon.com/mailman/listinfo/xymon >     > >

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- Adam Goryachev Website Managers www.websitemanagers.com.au

-- The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Viruses - Any loss/damage incurred by receiving this email is not the sender's responsibility.

On 14/3/19 16:00, Jeremy Laidman wrote:

On Wed, 13 Mar 2019 at 10:57, Adam Goryachev <mailinglists at websitemanagers.com.au <mailto:mailinglists at websitemanagers.com.au>> wrote:

IMHO, when using "security" tools, we really need to make sure we
rely
on a third party "library" to do this, security/encryption is a fast
moving area, and we really don't want to be using something 5
years old
because nobody understood how to update it from TLS1.1 to TLS1.2
or from
using 3DES to using AES or whatever the issue becomes.

I'm not sure I agree that encryption is fast-moving in all areas, or even most of them. Yes, there are bugs found in encryption software, short-cuts found in brute-forcing hashes, new algorithms every now and then, and the occasional implementation problem (wep, wpa, ssl); all of these scenarios require some kind of upgrade. However, the math(s) behind the basic crypto primitives is fundamentally sound (well-vetted and in some cases proven), particularly around simple use cases. Even with deprecated hashes (MD5, SHA1) they're not considered insecure, just that a well-resourced, and highly motivated and patient actor can brute-force them in time. With careful selection of hashing, encipherment and session key management algorithms, a good, strong solution can be implemented using >20-year-old crypto.

However, there's other value in being able to use a separate library, and allow upgrades to the library to improve security or squash bugs, without having to recompile Xymon.

Also, xymon may
not be updated as easily/quickly as what other system libraries
might,
so again, better to let the OS (system) provide the relevant tools
to do
this, and we just become another consumer.

Agreed.

As such, an obvious choice would be openssl, or something similar,
where
it is widely supported across many platforms, well maintained, and
likely to be well maintained in the future.

Not to mention, OpenSSL is already used by Xymon for things like https checks.

I think there are two separate requirements when referring to
encryption:
1) Encrypt the content so anyone listening can't see your log 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 my routers (Cisco Meraki: www.meraki.com <http://www.meraki.com> details at https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_D...)

  still don't support IPv6 either, so it still doesn't seem to be as important as claimed by everyone 10+ years ago when they said we would run out of IPv4 addresses.... It's hard to "change the world", I mean, we still have SMTP and DNS ;)

Yep, this is true, overall IPv6 take-up continues to be slow. However, the thing about Xymon is, it needs to be able to monitor a wide range of devices and services. So if you have 1000 nodes to monitor, and just one of them runs IPv6, your Xymon has to support IPv6 in order to detect a service outage. This is the situation I'm in. My work-around is to disable "conn" checks for such hosts, and run a script that does a ping6 and creates the "conn" status messages. Also, certain sectors of the industry are likely to have a relatively large IPv6 footprint, such as telcos, and IoT network providers.

True, there are many Meraki customers requesting IPv6, I'm just acknowledging that it is a much slower process than it seemed to be advertised. It originally seemed like we would all be forced to IPv6 within a couple of years.

On Thu, 14 Mar 2019 at 07:09, Adam Goryachev < mailinglists at websitemanagers.com.au> wrote:

...

I mostly understand, and think I agree with most of the above. At the end of the day, the solution needs to be:

a) backwards compatible, so you can still accept plain, unsigned, unencrypted connections from the coffee maker in the corner

b) simple to install and maintain, and robust. If it's too hard to install or maintain, then people won't want to use it. ...

I agree with the recent comments, but I will just add: c) automatable - we have automated client deployment and adding of the appropriate config to the server via Ansible, and it would be good to be able to continue to use Ansible in the future.

Kind regards,

SebA

On Mar 8, 2019, at 11:14, Bruce Ferrell <bferrell at baywinds.org> wrote:

On 3/8/19 7:08 AM, Axel Beckert wrote:

...

Hi,

On Fri, Mar 08, 2019 at 01:31:35PM +0000, John Horne wrote:

...

On Fri, 2019-03-08 at 12:09 +0000, SebA wrote:

...

Many years ago, I pushed for Xymon to be moved from VCS to SVN to promote community contributions. I think you meant CVS instead of VCS. VCS (Version Control System) is the general term for CVS, SVN, Git, Mercurial, etc.

...

...

Git, specifically GitHub, has replaced SVN as the best thing to promote community contributions, and I think it would be beneficial if the official Xymon code repos are migrated to GitHub. Definitely, but it's also not the only thing which is needed for getting contributions from external contributors. It's also a social thing.

Reviewing and accepting contributions — or maybe even giving trustworthy contributors commit access is also necessary for a FLOSS project. But as far as I can tell, this happens in the Xymon project, although not on a daily base.

...

but github would allow the community to report issues, SF does allow that, too, it's just not enabled for the Xymon project on SF. Example of an SF project where it is enabled: https://sourceforge.net/p/nfsen/bugs/ <https://sourceforge.net/p/nfsen/bugs/>

...

provide updates/patches via pull requests, Exists on SF, too, example: https://sourceforge.net/p/nfsen/patches/ <https://sourceforge.net/p/nfsen/patches/>

...

and download either released versions via the tags Possible, too, example: https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27 <https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.3.27>

...

if necessary or the latest code via the 'develop' (or whatever) branch. https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master <https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/branches/4.x-master> https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk <https://sourceforge.net/p/xymon/code/HEAD/tarball?path=/trunk>

Don't get me wrong: I think SF degraded from once the best place to host FLOSS to a website with tons of outdated trash and the most horrible UI I ever saw from a code hosting site. Not to mention that it is far too overladen with ads and popup.

My personal preference in VCS hosters is also GitHub as — from my point of view — they currently provide the best user experience. OTOH there might be some qualms about Github being not completely open source and being owned by Microsoft.

And with regards to being dead or not: Development greatly sped up when J.C. Cleaver took over release management, but it indeed seems to have stalled a little bit again. Then again, IIRC J.C. mostly took over release management so that Henrik can focus on long-time development. And if there is not much to fix in the current stable releases, not having a stable release every few months is not necessarily "dead", but might also be "stable, no relevant open issues".

(And yes, I'm still hoping and waiting for IPv6 support, too, especially in xymonnet-based checks. Reporting to IPv6-only servers is no issue though, if you anyways use stunnel to encrypt the client-reporting traffic.)

  Kind regards, 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.

Certainly the price is right compared to commercial alternatives. Some places can't seem to get $$ for system monitoring. Of course, it costs regardless (you need either someone in-house or a vendor to set up a product, and someone in-house to update it and the configuration data it needs). And it definitely costs if you don't monitor, assuming it matters enough to have something working that you want to fix problems quickly.

IPv6... eh. No matter how much people scream that "we gotta have it!!!", as has been mentioned, it's really not much used in real life. And I think I can make that statement authoritatively... To pay my bills, I do enterprise level support for a major vendor. I see hundreds of customer networks annually and see almost no ipv6 and very little demand for it. That said, it's most likely I good idea long term to get that kind of support into xymon.

One can't count on remote clients having IPv6 capability, so everyone that deals with end users over the Internet still needs to support IPv4. And for private addresses, running out of them is a non-issue. Still, sooner or later, the IoT will mean billions of connected gadgets, which will sooner or later require IPv6. Quite a lot of major sites do support IPv6 outward-facing. (some examples: Apple, Facebook, Oracle, YouTube, Google, Instagram...but not Twitter) Plenty of ISPs support it, at least if the client isn't running ancient modems and/or routers. Everything that adds IPv6 support takes away another excuse for not using it. Phones may use IPv6 if available; I see both WiFi and cellular IPv6 addresses for mine, at the moment.

The politics of where to host repositories and what VCS to use... ALL public hosting sites are a pain in one way or another and that is an entirely separate issue from the VCS technology used.

GIT, CVS and SVN (to name only a few) inherently don't offer bug tracking. github does, gitlab does and so does sourceforge.

Much as a dislike what SF became, it tends to offer the most variety in the tools offered and we needn't mention the owner of github.

Container monitoring, MIGHT be a good idea... If someone can say what specific things they want to be monitored/reported.... Not just holler they want monitoring.

One aspect is info regarding relationship between host and VM or container, and the type of VM or container technology (which implies the commands used to probe it). It would be useful to be able to show e.g. all VMs/containers on a host, or the (current, since they may be able to live migrate) host running a VM/container, and the technology used (be it Docker, VMware, VirtualBox, Parallels, Solaris LDOMS or zones, etc)...since some fixes will require knowing that. It's worse when you consider that some of those can be live-migrated, so the host to VM or container relationship isn't constant. I would think that that, along with resource management, would be the main issues. Of course, large-scale virtualization solutions probably have a lot of that anyway, but at least a partial view via Xymon would IMO be very handy.

Other than that, what's really different about a container or VM, compared to a physical system? There may be an extra level of resource management, but I'm not sure it's useful for Xymon to know about and report that.

And how far do you really want to go? Xymon is a monitoring tool, not a configuration management tool (although for dubiously managed systems, I might make sure history is retained and some non obvious configuration data is captured in tests, so that it may help document what's needed to put Humpty back together again). But containers and VMs in principle have their own configuration management, or at any rate the ability to re-create them new with the latest tested combo of what they need; so maybe some extra tag that's to containers or VMs what [clientversion] is to Xymon client software tarballs distributed via Xymon, would be good enough to let one see what (local, I suppose) rev a container or VM build is at; the containers/VM's might need to be built to have that pre-stored in a file that the client script can check for.

When I can see something I need/want tracked and monitored, I do the following:

1.) Start from the assumption I'm neither the first only only one to do this -- Who else has done this before and what did they do? Is there something close to what I need? ( xymonton/deadcat anyone ) 2.) If I find I am a snowflake (not very often), then I look at what sort of test I need. At this point, it's usually a VERY simple thing to test from a shell script. Add that to $XYMONHOME/ext and the tasks file and I'm done.

What I HAVE seen done around containers looks insane to me... Something not too unlike strace on steroids and then passing the output to splunk like tools and things like graphite... Neither of which do I agree with especially for tools like Xymon.

Given recent findings around security of "off the shelf containers" that are loaded with insecure and unmaintained libraries, that LOOKS like something that might be a target... But it also makes me look with a very jaundiced eye at containers. If not the concept, then the practice and that's a whole different discussion.

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

On 3/11/2019 6:59 AM, SebA wrote:

On Fri, 8 Mar 2019 at 15:09, Axel Beckert <abe at deuxchevaux.org <mailto:abe at deuxchevaux.org>> wrote:

Well another option is just to convert the repo on SF from SVN to Git, but keep it hosted on SF.  And then also to enable the bugs and patches area - if someone is going to monitor and maintain those areas.  I have seen SF projects where no-one does.  But most active FLOSS projects are on GitHub these days.

And with regards to being dead or not: Development greatly sped up
when J.C. Cleaver took over release management, but it indeed seems to
have stalled a little bit again. Then again, IIRC J.C. mostly took
over release management so that Henrik can focus on long-time
development. And if there is not much to fix in the current stable
releases, not having a stable release every few months is not
necessarily "dead", but might also be "stable, no relevant open
issues".

Yes, development did greatly speed up, but it practically ceased when J.C., I think, found difficulty merging the patches he had been using in his RPMs with Henrik's new 4.4 code.  Or over 2 years ago (Jan 2016) when he released 4.3.28.  I know the idea was that Henrik could focus on long-time development, but I think that ceased over 3 years ago - his last commit was in Jan 2016, with the last development type commit being Dec 2015.  Both of them changed jobs (Henrik in Aug 2013 and J.C. in Sep 2015) and I'm guessing no longer used, or needed to develop, Xymon in their new roles and then their desire or capacity to keep putting time into the project dwindled.

This is a fair criticism, unfortunately. The primary issue for me since then has been having access to sufficiently high-throughput performance and load testing, which had been a significant aspect of the feature and dev cycle. I'd been hesitant to release further absent a true shakedown of the new code, however that was /never/ intended to be an indication of lack of interest in the project. It had seemed to have gotten to a point where a lot of the low-hanging fruit had been hit and there was -- once again -- a large delta in the jump to the prospective next release  -- in fact, which I feel was similar to the previous stall.

    (And yes, I'm still hoping and waiting for IPv6 support, too,
    especially in xymonnet-based checks. Reporting to IPv6-only
    servers is
    no issue though, if you anyways use stunnel to encrypt the
    client-reporting traffic.)

                     Kind regards, Axel

And I'm still hoping for TLS support in the client.  I did try https
URL as the recipient (which should work - r7797) but I couldn't get
it to work in the RPM 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

On Tue, 12 Mar 2019 at 05:09, Japheth Cleaver <cleaver at terabithia.org> wrote:

Knowing that there is still actually a demand for IPv6 is helpful. Simply put, what's most needed right now is a potentially large testbed for testing and validation of the code we have.

Regards, -jc

Hi jc,

It might be helpful if you or someone commit ToDo and TESTING files in the 4.x-master branch describing what is broken, what work is partially implemented, what the roadmap might look like (maybe in a different file), and exactly what testing needs to be done (in such a way that anyone could look at the test plan and say, 'OK, I'll try and complete that') before features are considered worthy of pushing into a stable branch, or before a 4.4 branch can be branched and considered as beta or stable.

I don't think this knowledge is widely known, and the first step towards getting it done is probably to verbalize what it is that needs doing. Then perhaps people will pick up a particular test case and run through it and that one can be ticked off. A way of tracking these, e.g. in a 'bug' tracker may be helpful, so that they can provide evidence of the test. Redmine might be larger than what's required, but it does seem quite good for progressing projects, with the ability to see what needs to be done for each release.

The thing is that, with SVN especially, not so much if Xymon was using Git, it's very easy for planned or even developed features to get stuck behind other features pending testing in the pipeline. What I mean is that even if there was no demand for IPv6, we would want to get that out of the door so that we can move on to progressing other features (without ditching all the work that has already been done), as merging branches can be tricky or time consuming.

Kind regards,

SebA