You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Jan Høydahl (Jira)" <ji...@apache.org> on 2020/11/03 11:45:00 UTC

[jira] [Commented] (SOLR-10202) Auto resolve urlScheme, remove cluster property

    [ https://issues.apache.org/jira/browse/SOLR-10202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17225318#comment-17225318 ] 

Jan Høydahl commented on SOLR-10202:
------------------------------------

In SOLR-12182 the scheme is parameterized in state.json which takes us one step closer to a smoother switch between schemes. Tim mentioned this issue and rightly pointed out that a {{CloudSolrClient}} external from the cluster also needs to know urlScheme, which it gets from ZK today.

This made me thinking. Can we simply add a new {{.withUrlScheme()}} method to {{CloudSolrClient.Builder}}? It won't be back compat, but it will give clients a way to provide the scheme. Could alternatively provide a {{UrlSchemeResolver}} interface. Implementations could be {{StaticUrlSchemeResolver, ZkUrlSchemeResolver, SysPropUrlSchemeResolver or SniffUrlSchemeResolver}}, where the OOTB could be the sysprop one, and the Sniff* one would attempt both and use the one that returns a valid response :)

> Auto resolve urlScheme, remove cluster property
> -----------------------------------------------
>
>                 Key: SOLR-10202
>                 URL: https://issues.apache.org/jira/browse/SOLR-10202
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrCloud
>            Reporter: Jan Høydahl
>            Assignee: Timothy Potter
>            Priority: Major
>
> Spinoff from SOLR-9640.
> Today we need to explicitly set {{urlScheme}} cluster property to enable SSL, at the same time as we need to set all the SSL env variables on each node. As discussed in SOLR-9640, we could be smarter about this so an admin only need to setup {{solr.in.sh}} with keystore to enable SSL.
> h3. How
> Perhaps simplified a bit, but in principle, at node start, if {{solr.jetty.keystore}} (one out of several possiilities) is defined then use https, else http :-) Then, if the administrator has mixed it up and failed to configure {{solr.jetty.keystore}} on one of the nodes, then that node will not be able to communicate with the others over {{http}}, it will get {{curl: (52) Empty reply from server}}. Opposite, an SSL enabled node trying to talk to a Solr node that is not SSL enabled over {{https}}, will get {{curl: (35) Unknown SSL protocol error in connection to localhost:-9847}} (not the curl error of course, but similar).
> I don't think the nodes need to tell ZK about SSL at all?
> So my claim is that this will not give bigger risk of misconfiguration, cause if you add a new node to the cluster without SSL, it will generate a lot of BUZZ in the logs and it will never receive any unencrypted data from the other nodes since connections will fail. Agree?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org