[
https://issues.apache.org/jira/browse/SOLR-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16910929#comment-16910929
]
Jason Gerlowski commented on SOLR-13687:
----------------------------------------
Sure. My main point was less about url vs zk-conn-string (I think either is
fine...though there is prior art around the ZK_HOST setting). My point was
just that a solr.in.sh property fits well with how other similar things are
done today. Whether you add an explicit flag or not, users would probably
expect this to be set-able in solr.in.sh.
bq. Ideally, we should minimize access to ZK from hosts outside of of solr
nodes. It's a security hole.
Two things about this:
1. ZK has security mechanisms. If you don't use those, then yes, it's a
security hole. But you can say the same thing about a Solr URL if Solr hasn't
been secured.
2. I'd love for ZK to be a background detail we can hide from people, but right
now I think it's a little unrealistic to try abstracting from clients, given
how fundamental it is to Solr. ZK-conn-strings are stickier and more useful to
use in cloud environments, where individual Solr nodes might join and leave a
cluster frequently. etc
That said, I don't really have a dog in the conn-string vs url fight. Just
thinking aloud about pros/cons. I think adding a flag/solr.in.sh option for
either would be an improvement.
> Enable the bin/solr script to accept a solr url to run commands
> ----------------------------------------------------------------
>
> Key: SOLR-13687
> URL: https://issues.apache.org/jira/browse/SOLR-13687
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Priority: Major
>
> The problem we have today with our {{bin/solr}} script is that we have to run
> it from one of the nodes where Solr is running. This is a security issue b/c
> only admins are usaully be allowed to login to a machine where solr is
> running.If you have multiple cluster running in that host we don't know which
> one it's going to use. It is much easier to write a simple script that works
> over a url and the user has no ambiguity as to how it works. You can just
> unpack a solr distribution to your local machine and start using the script
> without bothering to install solr .
> The following commands can easily be executed remotely. These commands can
> accept the base url of any solr node in the cluster and perform the opertaion
> * healthcheck
> * create
> * create_core
> * create_collection
> * delete, version,
> * config
> * autoscaling
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
