[hobbit] Alternate to msgcache/hobbitfetch?
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
A slightly different way would be if hobbit client did "sending validation"...
Client sends it's data as usual to the server but if the connection fails it stores information locally until it can. Could be used if your WAN link goes down. Or in your case, intentionally use it like hobbitfetch without using msgcache (and make hobbitfetch use ssh to get the logs).
Craig Cook
Systems Monitoring Consulting and Support Services http://www.cookitservices.com
On Mon, June 4, 2007 23:18, Craig Cook wrote:
I guess what I'm looking for is a hobbitfetch variant that uses ssh/scp rather than connecting to a msgcache listener. And along with that, a way to configure the client to collect data normally, but skip starting a listening service.
A slightly different way would be if hobbit client did "sending validation"...
Client sends it's data as usual to the server but if the connection fails it stores information locally until it can. Could be used if your WAN link goes down. Or in your case, intentionally use it like hobbitfetch without using msgcache (and make hobbitfetch use ssh to get the logs).
This would be a wonderful feature to have, especially since hobbitfetch appears to be seriously broken as to reliability. Came in this morning to find my prototype farm all purple on msgcache columns, all apparently having ceased to get hobbitfetch-ed between 6:15 and 6:20 last evening. All processes still running, but nought going on.
Random thoughts on msgcache and alternatives:
SSH tunnels are nice, as they encrypt the data transfers*
SSH tunnels are a pain in some ways, imagine managing 1000+ tunnels. Even if you have autossh to help keep them up, it's fairly resource-intensive to have thousands of ssh tunnels constantly established from your server to remote hosts.
I would imagine it's not a simple thing to modify hobbit to do everything over an "on-demand" ssh tunnel, because Hobbit does more than just ssh to a host, running the client script, and parsing the output.
There is also all the other hobbit protocol stuff like pushing out new clients, logfile monitoring, etc.If Hobbit could do things via ssh, it would be much easier to deal with firewalls, as there are usually already rules in place for ssh, and if not it usually doesn't raise any serious flags with infosec if you request ssh access.
*5. Regardless, I would like to see some sort of encryption of the hobbit protocol. Nothing extreme, just not plaintext. Even a simple XOR of the data, or, even better, the server and clients could have a hobbit-security.conf where a key was defined, and all data would be XOR'd with this key. XORing data is easy to do in C and not resource intensive. This should satisfy the folks who worry about sending the contents of their logfiles and other sensitive information over the network.
That's my ramblings for the day :) -Charles
First - yes, there are bugs in msgcache/hobbitfetch, and I'll try to get those sorted out.
*5. Regardless, I would like to see some sort of encryption of the hobbit protocol. Nothing extreme, just not plaintext. Even a simple XOR
I must disagree here.
Poorly implemented cryptography is much worse than no cryptography. It gives people the impression that confidentiality "has been taken care of with encryption", when in fact it hasn't. And then people tend to forget about the *other* things they need to do to get a secure environment.
Inventing your own crypto protocol is usually the *worst* way to begin doing any kind of encryption. History is full of examples. I do not want to become part of it.
If Hobbit is going to have an encrypted link between clients and the Hobbit server, it will be using TLS (SSL). It's a well-tested protocol, it has support for not only encryption but also authentication (both server and client), and there are standard libraries available implementing it - which Hobbit already uses for network tests.
But I'm still un-convinced that it's such a great idea. There are lots of ways that you can attack Hobbit if you want to get at the information it stores - if I were to attack such a system, my first attempt would be to get access to the server and steal the hobbitd.chk file, which holds all of the information Hobbit stores about a host.
Regards, Henrik
On Tue, June 5, 2007 16:32, Henrik Stoerner wrote:
First - yes, there are bugs in msgcache/hobbitfetch, and I'll try to get those sorted out.
It's good to know that. Considering how well most of it works, I'm sure that a reliable solution to the msgcache/hobbitfetch issues will be forthcoming. There are also some troublesome things about the initialization scripts. I see environment files being sourced, then paths being hard-coded that could have been constructed from the sourced values. There are also stop functions that don't shut down everything that the start function starts. I know there's a lot of work in preparing these for the different environments. Is the right way to help to contribute "upgraded" scripts back to you, Henrik? Or would you prefer to have them posted here or to the Shire?
*5. Regardless, I would like to see some sort of encryption of the hobbit protocol. Nothing extreme, just not plaintext. Even a simple XOR
I must disagree here.
Poorly implemented cryptography is much worse than no cryptography. It gives people the impression that confidentiality "has been taken care of with encryption", when in fact it hasn't. And then people tend to forget about the *other* things they need to do to get a secure environment.
Absolutely the right thinking. Trivial encryption not only gives a false sense of security, it adds unnecessary overhead given the ease of cracking it.
Inventing your own crypto protocol is usually the *worst* way to begin doing any kind of encryption. History is full of examples. I do not want to become part of it.
If Hobbit is going to have an encrypted link between clients and the Hobbit server, it will be using TLS (SSL). It's a well-tested protocol, it has support for not only encryption but also authentication (both server and client), and there are standard libraries available implementing it - which Hobbit already uses for network tests.
That could be useful, but I find that ssh lends itself to tunneling hobbitfetch and the network-based tests if you want to do that, is ubiquitous, and it's simpler to set up the PKI authentication than doing full-blown TLS. It's worth considering how to ride on that as an alternative in the way Hobbit works. Of course, I'm biased because I already set up that relationship on all the monitored machines for general systems management purposes.
Thanks, Henrik, for the enormous amount of time you must put into this. And thanks to everyone for this active support community.
regards, j.
participants (5)
-
craig＠cookitservices.com
-
epperson＠alumni.unc.edu
-
henrik＠hswn.dk
-
hobbit＠epperson.homelinux.net
-
jonescr＠cisco.com