SebA,
We agree on a lot, including the licenses. We do NOT agree on taking
risks. Again, the concepts for secure transport ARE actually served in the
good old, "pull from the client
via ssh using keys" method, rather than the client push to the server.
Yes, you DO actually have to do SOME setup for that to work. The fact that
it's NOT well known isn't a good
reason to add a LOT of additional code to xymon.
I've had to cope with WAY too many issues around Python to have ANY trust
of it.
I've had to deal far too often with Python code that "works on your
machine, but not on mine" WAY too may times then had experts look and say
"I'll have dig into it for a day to
figure out why it does that... It's not supposed to do that". It's not
inherent in the language, but in practices around the language.
I can, and do code in it if I absolutely must, but avoid it when I can.
Yes, many, many other people like that complicated things can be built with
it quickly and I didn't mean
this to become bike shed discussion around language.
The kinds of issues I spoke of give ME the heebie jeebies when it comes to
tools I use regularly.
On 3/12/19 10:16 AM, SebA wrote:
Hi Bruce,
Yes, I've been using the same since 2002 as well, but I disagree on the
legal issue. The Apache licence is very free and so long as it is complied
with (which is mainly to do
with trademarks) there are no problems with it. Many commercial
products integrate OS software that uses the Apache OS licence, and Xymon
is not commercial, it's open source too!
Look, I don't know if it's worth using their code or not - I happen to
like Python and can program in it (when I can't in C), but as you said,
it's a different language, it might
not integrate well. I have seen some communication issues with the Salt
Stack, but they're mostly due to not having the right firewall ports open.
Anyway, the key generation
and encryption stuff is separate to the communication - Xymon
communication could still use the normal Xymon channel, but use key
generation and encryption ideas or code or
libraries from somewhere else.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 17:04, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid
<mailto:user-24fbf1912cfe@xymon.invalid>> wrote:
SebA
I think mentioned this in another thread. I've been using
BB/xymon/"that thing we can't say because an estate disliked it" since 2002.
I think many of us went through the demise of BB when Quest/Dell/EMC
absorbed/smothered it.
Using code from a commercial entity (even with an apache license)
raises the spector/risk of past debacles and in my opinion potentially puts
a tool I really like and find
useful
at risk.
Integrating functionality that already exists through well
understood, more general mechanisms makes it special purpose functionality
and THAT makes it less reliable...
Especially
in that SaltStack is really "just" an orchestrator written in Python
(Py, in and of itself is enough for me to give it a pass... Very long story
and ask me outside of this
discussion about that). The difference in the codebase alone should
cause someone to think very hard about that kind of merge.
Looking more closely at SaltStack, I see it would add addition
transports; MQ or RAET (yet another UDP based protocol... UDP, unreliable
transport to increase
security/reliability?!). MQ per the docs, uses HTTP/SSL and now
we're back to certs and even further integration of some form HTTP server
to do that!
Maybe better documentation of secure message distribution? There
used to be one on how to pull client updates via ssh. That's secure AND
simple. It doesn't sign the updates but
that could be a reasonable add-on to the documentation.
For this purpose, SaltStack looks to me like that old Milton Bradley
board game Mouse Trap.
On 3/12/19 8:55 AM, SebA wrote:There is a commercial version, but this code is open source:
https://github.com/saltstack/salt
I wasn't saying we use their code - although if the licence says
that other open source projects can use it, then it is worth considering.
It looks like it's using the
Apache
licence.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:10, Bruce Ferrell <user-24fbf1912cfe@xymon.invalid
user-24fbf1912cfe@xymon.invalid>>> wrote:
...And looking even closer at saltstack, it's a commercial
product, leading to a possible trigger of "that's ours! cross our palms
with MUCH silver" (probably based on
OSS, but
thats' never stopped anyone).
Taking me back to "do it outside of xymon" for cleanliness
sake.
On 3/12/19 6:50 AM, SebA wrote:The way Salt Minions authenticate and their keys have to be
accepted on the Salt Master works pretty well. I don't believe they
expire. It's been a while since I looked
at it,
so I couldn't tell you exactly how it works, but there's
some information here:
https://docs.saltstack.com/en/getstarted/system/communication.html
Anyway, that model would probably work pretty well for
Xymon, so long as the reporting client is not ephemeral.
Kind regards,
SebA
On Sat, 9 Mar 2019 at 02:10, Bruce Ferrell <
user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid> <mailto:
user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>
<mailto:user-24fbf1912cfe@xymon.invalid <mailto:user-24fbf1912cfe@xymon.invalid>>>> wrote:
I'm not sure which standard is in use here, so I'll just
top post like Richard did. Please don't shoot me.
People always go for certs... And then they expire and
stuff starts breaking or alerting right and left all at once. GACK!
For real hilarity, make them expire ten years out. By
that time, no one even remembers that certs were even installed or what
they're for. As the home loan industry
said right
before the big crash, IBG, UBG (I be gone, you be gone).
From one who has had to deal with such mass silliness,
take it from me, it's NO FUN and REALLY tedious to fix.
"But I'll just use the cert for tunnel authentication" I
hear you say... If in-authentic communication (even self signed) isn't
denied, do we care if it's signed
really? If
we do
care then we deny communication/ignore messages. Now
we've lost reporting links and visibility.
Some form of message authentication is probably a good
idea though. Just something that doesn't expire and can be revoked as
needed. gpg/pgp keys maybe, but then we
get the
issue
of gpg/pgp key distribution/signing. Key per monitored
system... Anyone want to manage THAT?
On 3/8/19 11:28 AM, Richard L. Hamilton wrote:In the ideal, esp. when the client may have a dynamic
IP address (DHCP without reserved addresses, or mobile clients, for
example), it would IMO also be really good
if the
client reports could optionally be signed, with a
certificate the server could verify, to give some confidence as to their
actually coming from the client...not
that that
assures that the actual client wasn't compromised, but
it's better than nothing insofar as it at least gives good odds that
misleading (or maliciously crafted)
data from
elsewhere isn't being provided.On Mar 8, 2019, at 11:09, Axel Beckert <
user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid> <mailto:
user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>
user-bc188e45dae4@xymon.invalid <mailto:user-bc188e45dae4@xymon.invalid>>>> wrote:
Hi Ralph,
On Fri, Mar 08, 2019 at 10:40:55AM -0500, Ralph
Mitchell wrote:
I'd still like to see encrypted connections for
Xymon client messages going
to the server.
Yeah, this definitely is a feature which would be
very nice to
available out of the box.
Nevertheless you can do that already now with stunnel
as I mentioned:
(And yes, I'm still hoping and waiting for IPv6
support, too,
especially in xymonnet-based checks. Reporting to
IPv6-only servers is
no issue though, if you anyways use stunnel to
encrypt the
client-reporting traffic.)
Debian's xymon package ships
/usr/share/doc/xymon/README.encryption
with hints how to implement encrypted reporting with
Xymon.
The current version can be found in our packaging git
repository at
https://salsa.debian.org/debian/xymon/blob/master/debian/README.encryption
although I'm thinking about renaming it to
README.encryption.md <http://README.encryption.md>; <
http://README.encryption.md>; <http://README.encryption.md>; as I
wrote it in Markdown syntax.
It also refers to this more detailed documentation:
https://en.wikibooks.org/wiki/System_Monitoring_with_Xymon/Administration_Guide#Encryption_and_Tunnelling
HTH!
Kind regards, Axel
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: