Your company's network policies seem to be a good thing. I've worked
at places with this same policy, for good reason. But it does tend to
complicate operations sometimes. Some options you might pursue:
* Set up ssh-agent on the clients and use passphrase-protected keys.
Downside to this, someone on your ops team will be inevitably awoken
at 4am to type in the password.
* Try to get an exception to the policy by running Solr under a new
user account inside a jail. Use a restricted login shell to make sure
it can do only what you intend. So when the key is compromised,
damage is contained.
Or, write a custom server/client running on a different port. In this
case you lose over-the-wire encryption, and if your server is buggy,
you get pwn3d anyway.
--Matt
On Nov 29, 2007, at 7:48 PM, Justin Knoll wrote:
Hello,
I recently set up Solr with distribution on a couple of servers. I
just learned that our network policies do not permit us to use SSH
with passphraseless keys, and the snappuller script uses SSH to
examine the master Solr instance's state before it pulls the newest
index via rsync.
We plan to attempt to rewrite the snappuller (and possibly other
distribution scripts, as required) to eliminate this dependency on
SSH. I thought I ask the list in case anyone has experience with
this same situation or any insights into the reasoning behind
requiring SSH access to the master instance.
Thanks,
Justin Knoll
--
Matt Kangas / [EMAIL PROTECTED]
