[
https://issues.apache.org/jira/browse/SOLR-14115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17000957#comment-17000957
]
Erick Erickson commented on SOLR-14115:
---------------------------------------
[~janhoy] :
I'm a little confused here.
{quote}The security aspect that cli tools require local access can be used to
our advantage, and restrict certain zk operations to cli (direct connection to
zk) only.
bq.uploading the first security.json file already needs to happen from cli
{quote}
So are saying remove zkCli (the bits from Solr), but require people to use the
Zookeeper-provided zkcli to uploade the security file?
I didn't restrict _anytying_ when I added the "bin/solr zk..." support_._ At
one point I recursively copied everything from the root of ZK to a local disk,
wiped ZK and then put all the data back just to see if I could use it as an
unsupported backup mechanism. Perhaps this has changed since I originally added
that support.
That said, to use this you must be able to execute an arbitrary script on a
machine running Solr _and_ have free access to ZK so restricting something like
this seems like shutting the barn door after the horses have run away.
> Deprecate zkcli and bin/solr zk support
> ---------------------------------------
>
> Key: SOLR-14115
> URL: https://issues.apache.org/jira/browse/SOLR-14115
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
> Reporter: Erick Erickson
> Priority: Major
>
> I think it's a valid argument that these have outlived their usefulness and
> we should remove them and have APIs to do what Solr requires. Especially if
> we can find and point to a third-party visual ZK tool for _changing_
> arbitrary data in ZK. Zookeeper 3.5.5 has the admin server which has a UI
> (although I don't see how to change data in ZK with it. Haven't looked very
> much).
> While we're ripping stuff out of Solr, are these candidates? It would break
> my heart to rip ZK support out from bin/solr, but all good things must come
> to an end. Why do we maintain three (zkcli, bin/solr and the APIs) ways of
> doing the same thing?
> Mark put the zkcli stuff in before we had APIs to do what Solr needs to do
> with ZK, mainly uploading configsets at the time. I put the zk support in
> bin/solr also before the APIs existed because I thought having to learn our
> custom wrapper for ZK was yet another orphan bit of code laying around. All
> before we had things like the configsets API.
> Personally, I'd prefer removing zkcli rather than bin/solr, but that's
> because I originated the bin/solr code ;)
> This occurred when reading SOLR-14109, I'm not entirely sure what I _really_
> think about it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
