I too have been victim of the rampant recreation of scp.  It makes things very irritating to work with.  If you've used Windows as a desktop and things slow down it has a similar feel to it - nice and laggy.<br><br>I like the idea of SSL, good one Charles =)<br>
<br><div><span class="gmail_quote">On 1/25/08, <b class="gmail_sendername">Charles Jones</b> <<a href="mailto:jonescr@cisco.com">jonescr@cisco.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think Henriks stance on having the server collect data via ssh<br>connections just doesn't scale.  Sure it works fine for a few dozen<br>hosts, but let's say you have 2000 servers...now you are expecting be<br>able to make 2000 trouble-free ssh connections before the next polling<br>
cycle begins. This introduces many problems:<br><br>* How many ssh sessions can you run at the same time without spiking the<br>load on the hobbit server?<br>* What happens when an ssh session hangs (could hang the hobbit server,<br>
or make the poll cycle take too long)<br><br>You do know about the "pulldata" option?  It allows the Hobbit server to<br>do a "pull" instead of waiting for client "push". This works fairly<br>
well, and I am using it in a production environment. I can see how it<br>would not scale to well either though, for a really large number of hosts.<br><br>To picture the scalability, imagine a server that only has to receive<br>
updates from hobbit clients. All it has to do is listen on port 1984,<br>and using relatively little CPU it can probably handle a constant flow<br>of client updates.<br><br>Now imagine a server that has to go and fetch the client data itself.<br>
There is a LOT more overhead and processing involved in launching an<br>outgoing ssh connection, running a remote client data-gathering command,<br>waiting for the output, etc. Imagine 2000 of those firing off every 5<br>
minutes. How many simultaneous ssh sessions can your server handle?<br>I've seen a server brought to its knees by a script that ran amok and<br>was doing 50 simulataneous scp commands :)  Some time saving is done by<br>
using msgcache (no waiting for the data-gathering), but there is still<br>the overhead of ssh itself, and having key-based ssh ability could be<br>deemed a security risk (anyone who hacks into the hobbit server could<br>then ssh to all of your client machines without a password).<br>
<br>A good solution would be an ssl-encrypted, bi-directional protocol. This<br>would allow secure transfer of client data, either push or pull, without<br>the overhead, management, and security risks of using ssh.<br><br>
In the meantime, definitely check out the pulldata+msgcache option, as<br>it sounds like it will do what you want.<br><br>-Charles<br><br>Tim Rotunda wrote:<br>> To answer Axel's what is it question.....its a Hobbit version of BB-Central,<br>
> which runs on a central server like hobbit does.  It reaches out to the<br>> clients via ssh (or whatever) and collects data.  I did a shell script<br>> version a few years ago and it worked good until the client count topped<br>
> 25-30.  Then I migrated it to C and it would handle 60+ nodes pretty well.<br>> Then I migrated that to a multi-threaded C process and it really smoked.  I<br>> never did reach the limit with that version.  I think they are still using<br>
> it and adding nodes to the client list, which is prob over 250 or so.<br>><br>> I was going to put it out to the community but my company would not allow it<br>> (idiots) so I couldn't.  I now work only 40 hours a week so now I have some<br>
> time to myself and was thinking about rewriting it from memory and putting<br>> it out there.  I would put out the one that is threaded and it would prob<br>> just be for x86 Linux, which should build on Solaris, HP-UX, etc.<br>
><br><br><br>To unsubscribe from the hobbit list, send an e-mail to<br><a href="mailto:hobbit-unsubscribe@hswn.dk">hobbit-unsubscribe@hswn.dk</a><br><br><br></blockquote></div><br><br clear="all"><br>-- <br>Josh Luthman<br>
Office: 937-552-2340<br>Direct: 937-552-2343<br>1100 Wayne St<br>Suite 1337<br>Troy, OH 45373<br><br>Those who don't understand UNIX are condemned to reinvent it, poorly.<br>--- Henry Spencer