Solr
  1. Solr
  2. SOLR-3854

SolrCloud does not work with https

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.7, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      There are a few places in current codebase that assume http is used. This prevents using https when running solr in cloud mode.

      1. SOLR-3854.patch
        48 kB
        Steve Davids
      2. SOLR-3854.patch
        42 kB
        Steve Davids
      3. SOLR-3854.patch
        51 kB
        Mark Miller
      4. SOLR-3854.patch
        43 kB
        Steve Davids
      5. SOLR-3854.patch
        51 kB
        Steve Davids
      6. SOLR-3854.patch
        39 kB
        Steve Davids
      7. SOLR-3854.patch
        32 kB
        Steve Davids
      8. SOLR-3854.patch
        16 kB
        Mark Miller
      9. SOLR-3854.patch
        2 kB
        Alexey Serba
      10. SOLR-3854.patch
        21 kB
        Hoss Man
      11. SOLR-3854.patch
        21 kB
        Sami Siren
      12. SOLR-3854v2.patch
        22 kB
        Steve Davids
      13. SOLR-3854v3.patch
        18 kB
        Steve Davids
      14. SOLR-3854v4.patch
        3 kB
        Steve Davids

        Issue Links

          Activity

          Hide
          Sami Siren added a comment -

          Here's a patch against trunk that allows one to use https too.

          Show
          Sami Siren added a comment - Here's a patch against trunk that allows one to use https too.
          Hide
          Mark Miller added a comment -

          this one ready Sami?

          Show
          Mark Miller added a comment - this one ready Sami?
          Hide
          Sami Siren added a comment -

          I was planning to add some tests too, but got distracted with something else. I'll try to get to this again in near future.

          Show
          Sami Siren added a comment - I was planning to add some tests too, but got distracted with something else. I'll try to get to this again in near future.
          Hide
          Steve Davids added a comment -

          +1 We are running into this problem right now. Glad to see Sami's patch is adding the option to the solr.xml.

          Show
          Steve Davids added a comment - +1 We are running into this problem right now. Glad to see Sami's patch is adding the option to the solr.xml.
          Hide
          Hoss Man added a comment -

          Updated Sami's patch to trunk to account for recent changes.

          Existing tests pass, but still no new tests using https.

          Show
          Hoss Man added a comment - Updated Sami's patch to trunk to account for recent changes. Existing tests pass, but still no new tests using https.
          Hide
          Mark Miller added a comment -

          Sami, Hossman, will you get this in shortly for 4.1 or should I push it to 4.2?

          Show
          Mark Miller added a comment - Sami, Hossman, will you get this in shortly for 4.1 or should I push it to 4.2?
          Hide
          Alexey Serba added a comment -

          I've uploaded another patch that I believe is less intrusive.

          It touches only two places:

          1. host property parsing in ZkController
            host property supports passing a scheme/protocol already, it just has a tiny bug in the parsing code
            "ZkController"
                   Matcher m = URL_PREFIX.matcher(host);
            -      if (m.matches()) {
            -        String prefix = m.group(1);
            -        host = prefix + host;
            -      } else {
            +      if (!m.matches()) {
                     host = "http://" + host;
                   }
            
          2. I think Solr's distributed shard paramater should support handling scheme/protocol as part of a shard address
            "HttpShardHandler"
                   for (int i=0; i<urls.size(); i++) {
            -        urls.set(i, httpShardHandlerFactory.scheme + urls.get(i));
            +        String url = urls.get(i);
            +        if (!URL_PREFIX.matcher(url).matches()) {
            +          url = httpShardHandlerFactory.scheme + url;
            +        }
            +        urls.set(i, url);
                   }
            

          With these two tiny fixes I've been able to run SolrCloud in SSL mode. When you start a node you should pass "-Dhost=https://localhost" parameter. Correct https addresses are saved in the Zk's cluster state, used in indexing in SolrCmdDistributor and passed to search handlers as a shard parameter. Am I missing something?

          Show
          Alexey Serba added a comment - I've uploaded another patch that I believe is less intrusive. It touches only two places: host property parsing in ZkController host property supports passing a scheme/protocol already, it just has a tiny bug in the parsing code "ZkController" Matcher m = URL_PREFIX.matcher(host); - if (m.matches()) { - String prefix = m.group(1); - host = prefix + host; - } else { + if (!m.matches()) { host = "http: //" + host; } I think Solr's distributed shard paramater should support handling scheme/protocol as part of a shard address "HttpShardHandler" for ( int i=0; i<urls.size(); i++) { - urls.set(i, httpShardHandlerFactory.scheme + urls.get(i)); + String url = urls.get(i); + if (!URL_PREFIX.matcher(url).matches()) { + url = httpShardHandlerFactory.scheme + url; + } + urls.set(i, url); } With these two tiny fixes I've been able to run SolrCloud in SSL mode. When you start a node you should pass "-Dhost= https://localhost " parameter. Correct https addresses are saved in the Zk's cluster state, used in indexing in SolrCmdDistributor and passed to search handlers as a shard parameter. Am I missing something?
          Hide
          Mark Miller added a comment -

          One comment:
          It might be nice to add an option that create https addresses even when auto detecting the host.

          Otherwise, I have not looked closely enough to see how the two approaches differ. Sami, hossman?

          Show
          Mark Miller added a comment - One comment: It might be nice to add an option that create https addresses even when auto detecting the host. Otherwise, I have not looked closely enough to see how the two approaches differ. Sami, hossman?
          Hide
          Jan Høydahl added a comment -

          Have not reviewed in detail. Some use SSL + Basic Authentication. Can you comment on whether these two patches will allow BasicAuth, e.g. by passing -Dhost=https://user:pass@localhost ? What about certificate based auth?

          Show
          Jan Høydahl added a comment - Have not reviewed in detail. Some use SSL + Basic Authentication. Can you comment on whether these two patches will allow BasicAuth, e.g. by passing -Dhost= https://user:pass@localhost ? What about certificate based auth?
          Hide
          Hoss Man added a comment -

          I like that alexey's patch is a lot shorter, but i haven't had a chance to compare them closely enough to understand the pros/cons in terms of configurability.

          It might be nice to add an option that create https addresses even when auto detecting the host.

          maybe i'm missing something, but instead of hardcoding a default of "http" in zkcontroller like alexey mentioned, couldn't that be done by using cc.getHttpShardHandlerFactory().schema as the default?

          In any case .. i'm not sure that we can reliably make much progress until we can write test for this stuff – and as a first step i put up a patch in SOLR-4394 to get to the point where we have some simple client<-ssl->solr tests ... if we move forward on that, then we can take the next step of client<-ssl->solrcloud<-ssl->solrcloud tests

          Show
          Hoss Man added a comment - I like that alexey's patch is a lot shorter, but i haven't had a chance to compare them closely enough to understand the pros/cons in terms of configurability. It might be nice to add an option that create https addresses even when auto detecting the host. maybe i'm missing something, but instead of hardcoding a default of "http" in zkcontroller like alexey mentioned, couldn't that be done by using cc.getHttpShardHandlerFactory().schema as the default? In any case .. i'm not sure that we can reliably make much progress until we can write test for this stuff – and as a first step i put up a patch in SOLR-4394 to get to the point where we have some simple client<-ssl->solr tests ... if we move forward on that, then we can take the next step of client<-ssl->solrcloud<-ssl->solrcloud tests
          Hide
          Sam Kass added a comment -

          While Alexey's patch is admirably succinct, Sami's patch allows setting the protocol via the solr.xml file where all the other settings are stored, as well as getting rid of a bunch of arbitrary comparisons to the explicit "http" string, so seems preferable to me.

          Show
          Sam Kass added a comment - While Alexey's patch is admirably succinct, Sami's patch allows setting the protocol via the solr.xml file where all the other settings are stored, as well as getting rid of a bunch of arbitrary comparisons to the explicit "http" string, so seems preferable to me.
          Hide
          Steve Rowe added a comment -

          Bulk move 4.4 issues to 4.5 and 5.0

          Show
          Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
          Hide
          Mark Miller added a comment -

          1 from Alexey's approach has been committed. I'm also going to commit 2 - I think this approach should work fine. That will fix the support that I kind of assumed would work way back win.

          Sami's first class support can then be finished or not at a later time.

          Show
          Mark Miller added a comment - 1 from Alexey's approach has been committed. I'm also going to commit 2 - I think this approach should work fine. That will fix the support that I kind of assumed would work way back win. Sami's first class support can then be finished or not at a later time.
          Hide
          Mark Miller added a comment -

          Hmm...looking a little deeper, it's not too much more work to finish Sami's patch, and I think it's the right long term approach. We already have a spot to set the url scheme for http search requests - I think other http requests should respect that same scheme config.

          Show
          Mark Miller added a comment - Hmm...looking a little deeper, it's not too much more work to finish Sami's patch, and I think it's the right long term approach. We already have a spot to set the url scheme for http search requests - I think other http requests should respect that same scheme config.
          Hide
          Mark Miller added a comment -

          First pass. I took Sami's URLUtils and went through and setup the rest as I thought made the most sense. Pretty similar to what Sami did but with trunk in mind.

          I'd like to also stop storing the scheme as part of urls - but that doesn't have to be done in this issue I think. This just ignores the scheme for any address and uses the configured scheme. Better to also ignore the scheme when we first generate or accept the url.

          Show
          Mark Miller added a comment - First pass. I took Sami's URLUtils and went through and setup the rest as I thought made the most sense. Pretty similar to what Sami did but with trunk in mind. I'd like to also stop storing the scheme as part of urls - but that doesn't have to be done in this issue I think. This just ignores the scheme for any address and uses the configured scheme. Better to also ignore the scheme when we first generate or accept the url.
          Hide
          Steve Davids added a comment -

          Created a patch that includes a test that runs the "BasicDistributedZkTest" in SSL mode. While creating the test there were a couple of places that were causing issues if the wrong scheme was in zookeeper, so I added Sami's "hostProtocol" back in to get the test to pass.

          Show
          Steve Davids added a comment - Created a patch that includes a test that runs the "BasicDistributedZkTest" in SSL mode. While creating the test there were a couple of places that were causing issues if the wrong scheme was in zookeeper, so I added Sami's "hostProtocol" back in to get the test to pass.
          Hide
          Mark Miller added a comment -

          Thanks! I'll review this soon.

          While creating the test there were a couple of places that were causing issues if the wrong scheme was in zookeeper, so I added Sami's "hostProtocol" back

          I think we may just want to track that down. Personally, I don't really like the idea of having to set SSL twice - once for updates and once for searches. I don't really see the use case, and it seems more complicated than necessary. I think it makes sense to simply have one place to set the url scheme for distributed requests.

          It also would have been nice to leave the scheme out of ZooKeeper from the beginning, but I think that can be a later improvement.

          Show
          Mark Miller added a comment - Thanks! I'll review this soon. While creating the test there were a couple of places that were causing issues if the wrong scheme was in zookeeper, so I added Sami's "hostProtocol" back I think we may just want to track that down. Personally, I don't really like the idea of having to set SSL twice - once for updates and once for searches. I don't really see the use case, and it seems more complicated than necessary. I think it makes sense to simply have one place to set the url scheme for distributed requests. It also would have been nice to leave the scheme out of ZooKeeper from the beginning, but I think that can be a later improvement.
          Hide
          Steve Davids added a comment -

          I believe the RecoveryStrategy was complaining (among others) as it reads the URL directly from ZooKeeper:

          String leaderBaseUrl = leaderprops.getStr(ZkStateReader.BASE_URL_PROP);
          String leaderCoreName = leaderprops.getStr(ZkStateReader.CORE_NAME_PROP);
          
          String leaderUrl = ZkCoreNodeProps.getCoreUrl(leaderBaseUrl, leaderCoreName);
          

          This same concept is in CloudSolrServer:

          ZkCoreNodeProps zkProps = new ZkCoreNodeProps(leader);
          String url = zkProps.getBaseUrl() + "/" + col.getName();
          

          CloudSolrServer would need to be updated as well to allow a configurable URL scheme as there isn't a configured HttpShardHandler to grab the value.

          I believe it is somewhat reasonable to have each node report the scheme that is able to be used to connect to that specific server, more so for external clients that would like to use the base_url value as reported in zookeeper. Though I do see why needing to configure the url scheme in two different locations isn't optimal, I think it is a little strange that HttpShardHandler throws away the scheme of all passed URLs and inserts it's scheme. How about the HttpShardHandler not strip the schemes off unless a scheme was specifically configured, if that was the case then only the "hostProtocol" would need to be configured.

          Show
          Steve Davids added a comment - I believe the RecoveryStrategy was complaining (among others) as it reads the URL directly from ZooKeeper: String leaderBaseUrl = leaderprops.getStr(ZkStateReader.BASE_URL_PROP); String leaderCoreName = leaderprops.getStr(ZkStateReader.CORE_NAME_PROP); String leaderUrl = ZkCoreNodeProps.getCoreUrl(leaderBaseUrl, leaderCoreName); This same concept is in CloudSolrServer: ZkCoreNodeProps zkProps = new ZkCoreNodeProps(leader); String url = zkProps.getBaseUrl() + "/" + col.getName(); CloudSolrServer would need to be updated as well to allow a configurable URL scheme as there isn't a configured HttpShardHandler to grab the value. I believe it is somewhat reasonable to have each node report the scheme that is able to be used to connect to that specific server, more so for external clients that would like to use the base_url value as reported in zookeeper. Though I do see why needing to configure the url scheme in two different locations isn't optimal, I think it is a little strange that HttpShardHandler throws away the scheme of all passed URLs and inserts it's scheme. How about the HttpShardHandler not strip the schemes off unless a scheme was specifically configured, if that was the case then only the "hostProtocol" would need to be configured.
          Hide
          Mark Miller added a comment -

          That sounds reasonable.

          I think hostProtocol is the wrong name though? http://en.wikipedia.org/wiki/URI_scheme

          Show
          Mark Miller added a comment - That sounds reasonable. I think hostProtocol is the wrong name though? http://en.wikipedia.org/wiki/URI_scheme
          Hide
          Steve Davids added a comment -

          Update the patch with the following changes:

          1. hostProtocol has been changed to hostUrlScheme
          2. No longer need to specify the "urlScheme" on the HttpShardHandlerFactory. The scheme is only stripped/replaced if that value is specifically configured and SolrCloud passes the configured base_url value with the proper http/https scheme.
          3. Added a test that runs the CloudSolrServerTest in SSL mode

          There appears to be a few other places that is still hard-coding a scheme:

          SolrZkClient.getBaseUrlForNodeName(nodeName)
          ...
          return "http://" + hostAndPort + (path.isEmpty() ? "" : ("/" + path));
          

          getBaseUrlForNodeName is exclusively used by the OverseerCollectionProcessor.

          CloudSolrServer.request(request)
          ...
          if (request.getPath().equals("/admin/collections")
                  || request.getPath().equals("/admin/cores")) {
                Set<String> liveNodes = clusterState.getLiveNodes();
                for (String liveNode : liveNodes) {
                  int splitPointBetweenHostPortAndContext = liveNode.indexOf("_");
                  theUrlList.add("http://"
                      + liveNode.substring(0, splitPointBetweenHostPortAndContext)
                      + "/"
                      + URLDecoder.decode(liveNode, "UTF-8").substring(
                          splitPointBetweenHostPortAndContext + 1));
                }
              }
          ...
          

          Not positive how those two instances should be handled as it isn't dealing with a specific core, but the server in general.

          Show
          Steve Davids added a comment - Update the patch with the following changes: hostProtocol has been changed to hostUrlScheme No longer need to specify the "urlScheme" on the HttpShardHandlerFactory. The scheme is only stripped/replaced if that value is specifically configured and SolrCloud passes the configured base_url value with the proper http/https scheme. Added a test that runs the CloudSolrServerTest in SSL mode There appears to be a few other places that is still hard-coding a scheme: SolrZkClient.getBaseUrlForNodeName(nodeName) ... return "http: //" + hostAndPort + (path.isEmpty() ? "" : (" /" + path)); getBaseUrlForNodeName is exclusively used by the OverseerCollectionProcessor. CloudSolrServer.request(request) ... if (request.getPath().equals( "/admin/collections" ) || request.getPath().equals( "/admin/cores" )) { Set< String > liveNodes = clusterState.getLiveNodes(); for ( String liveNode : liveNodes) { int splitPointBetweenHostPortAndContext = liveNode.indexOf( "_" ); theUrlList.add( "http: //" + liveNode.substring(0, splitPointBetweenHostPortAndContext) + "/" + URLDecoder.decode(liveNode, "UTF-8" ).substring( splitPointBetweenHostPortAndContext + 1)); } } ... Not positive how those two instances should be handled as it isn't dealing with a specific core, but the server in general.
          Hide
          Erik Hatcher added a comment -

          Steve - is your latest patch for trunk or branch_4x or does it matter?

          Seems to apply ok on trunks, but with offsets:

          $ patch -p0 < SOLR-3854.patch 
          patching file solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java
          patching file solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
          patching file solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java
          Hunk #1 succeeded at 511 (offset 24 lines).
          Hunk #2 succeeded at 766 (offset 24 lines).
          Hunk #3 succeeded at 1511 (offset 24 lines).
          Hunk #4 succeeded at 1646 (offset 24 lines).
          Hunk #5 succeeded at 1743 (offset 24 lines).
          patching file solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
          patching file solr/core/src/java/org/apache/solr/cloud/ZkController.java
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolr.java
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXmlOld.java
          patching file solr/core/src/java/org/apache/solr/core/ZkContainer.java
          patching file solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java
          patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
          patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java
          patching file solr/core/src/java/org/apache/solr/update/PeerSync.java
          patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedSSLZkTest.java
          patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java
          patching file solr/core/src/test/org/apache/solr/cloud/ZkControllerTest.java
          patching file solr/core/src/test/org/apache/solr/core/TestSolrXml.java
          patching file solr/core/src/test-files/solr/solr-50-all.xml
          patching file solr/core/src/test-files/solr/solr.xml
          patching file solr/solrj/src/java/org/apache/solr/common/util/URLUtil.java
          patching file solr/solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrServerSSLTest.java
          patching file solr/solrj/src/test/org/apache/solr/common/util/URLUtilTest.java
          patching file solr/solrj/src/test-files/solrj/solr/solr.xml
          patching file solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java
          patching file solr/test-framework/src/java/org/apache/solr/cloud/AbstractFullDistribZkTestBase.java
          

          but reports some failures on branch_4x:

          $ patch -p0 < SOLR-3854.patch 
          patching file solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java
          patching file solr/core/src/java/org/apache/solr/cloud/ElectionContext.java
          patching file solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java
          Hunk #1 succeeded at 511 (offset 24 lines).
          Hunk #2 succeeded at 766 (offset 24 lines).
          Hunk #3 succeeded at 1511 (offset 24 lines).
          Hunk #4 succeeded at 1646 (offset 24 lines).
          Hunk #5 succeeded at 1743 (offset 24 lines).
          patching file solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java
          patching file solr/core/src/java/org/apache/solr/cloud/ZkController.java
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolr.java
          Hunk #1 succeeded at 135 (offset 4 lines).
          Hunk #2 succeeded at 239 (offset 4 lines).
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java
          patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXmlOld.java
          Hunk #1 succeeded at 149 (offset -2 lines).
          patching file solr/core/src/java/org/apache/solr/core/ZkContainer.java
          Hunk #1 FAILED at 65.
          Hunk #2 succeeded at 155 (offset 21 lines).
          1 out of 2 hunks FAILED -- saving rejects to file solr/core/src/java/org/apache/solr/core/ZkContainer.java.rej
          patching file solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java
          patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
          patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java
          patching file solr/core/src/java/org/apache/solr/update/PeerSync.java
          patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedSSLZkTest.java
          patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java
          patching file solr/core/src/test/org/apache/solr/cloud/ZkControllerTest.java
          patching file solr/core/src/test/org/apache/solr/core/TestSolrXml.java
          patching file solr/core/src/test-files/solr/solr-50-all.xml
          patching file solr/core/src/test-files/solr/solr.xml
          patching file solr/solrj/src/java/org/apache/solr/common/util/URLUtil.java
          patching file solr/solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrServerSSLTest.java
          patching file solr/solrj/src/test/org/apache/solr/common/util/URLUtilTest.java
          patching file solr/solrj/src/test-files/solrj/solr/solr.xml
          patching file solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java
          patching file solr/test-framework/src/java/org/apache/solr/cloud/AbstractFullDistribZkTestBase.java
          

          Am I doing something wrong or in the wrong place? I'm admittedly little rusty/unfamiliar with this fast moving (SolrCloud distrib testing) area lately.

          Show
          Erik Hatcher added a comment - Steve - is your latest patch for trunk or branch_4x or does it matter? Seems to apply ok on trunks, but with offsets: $ patch -p0 < SOLR-3854.patch patching file solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java patching file solr/core/src/java/org/apache/solr/cloud/ElectionContext.java patching file solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java Hunk #1 succeeded at 511 (offset 24 lines). Hunk #2 succeeded at 766 (offset 24 lines). Hunk #3 succeeded at 1511 (offset 24 lines). Hunk #4 succeeded at 1646 (offset 24 lines). Hunk #5 succeeded at 1743 (offset 24 lines). patching file solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java patching file solr/core/src/java/org/apache/solr/cloud/ZkController.java patching file solr/core/src/java/org/apache/solr/core/ConfigSolr.java patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXmlOld.java patching file solr/core/src/java/org/apache/solr/core/ZkContainer.java patching file solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java patching file solr/core/src/java/org/apache/solr/update/PeerSync.java patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedSSLZkTest.java patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java patching file solr/core/src/test/org/apache/solr/cloud/ZkControllerTest.java patching file solr/core/src/test/org/apache/solr/core/TestSolrXml.java patching file solr/core/src/test-files/solr/solr-50-all.xml patching file solr/core/src/test-files/solr/solr.xml patching file solr/solrj/src/java/org/apache/solr/common/util/URLUtil.java patching file solr/solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrServerSSLTest.java patching file solr/solrj/src/test/org/apache/solr/common/util/URLUtilTest.java patching file solr/solrj/src/test-files/solrj/solr/solr.xml patching file solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java patching file solr/test-framework/src/java/org/apache/solr/cloud/AbstractFullDistribZkTestBase.java but reports some failures on branch_4x: $ patch -p0 < SOLR-3854.patch patching file solr/core/src/java/org/apache/solr/client/solrj/embedded/JettySolrRunner.java patching file solr/core/src/java/org/apache/solr/cloud/ElectionContext.java patching file solr/core/src/java/org/apache/solr/cloud/OverseerCollectionProcessor.java Hunk #1 succeeded at 511 (offset 24 lines). Hunk #2 succeeded at 766 (offset 24 lines). Hunk #3 succeeded at 1511 (offset 24 lines). Hunk #4 succeeded at 1646 (offset 24 lines). Hunk #5 succeeded at 1743 (offset 24 lines). patching file solr/core/src/java/org/apache/solr/cloud/SyncStrategy.java patching file solr/core/src/java/org/apache/solr/cloud/ZkController.java patching file solr/core/src/java/org/apache/solr/core/ConfigSolr.java Hunk #1 succeeded at 135 (offset 4 lines). Hunk #2 succeeded at 239 (offset 4 lines). patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXml.java patching file solr/core/src/java/org/apache/solr/core/ConfigSolrXmlOld.java Hunk #1 succeeded at 149 (offset -2 lines). patching file solr/core/src/java/org/apache/solr/core/ZkContainer.java Hunk #1 FAILED at 65. Hunk #2 succeeded at 155 (offset 21 lines). 1 out of 2 hunks FAILED -- saving rejects to file solr/core/src/java/org/apache/solr/core/ZkContainer.java.rej patching file solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java patching file solr/core/src/java/org/apache/solr/handler/component/HttpShardHandlerFactory.java patching file solr/core/src/java/org/apache/solr/update/PeerSync.java patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedSSLZkTest.java patching file solr/core/src/test/org/apache/solr/cloud/BasicDistributedZkTest.java patching file solr/core/src/test/org/apache/solr/cloud/ZkControllerTest.java patching file solr/core/src/test/org/apache/solr/core/TestSolrXml.java patching file solr/core/src/test-files/solr/solr-50-all.xml patching file solr/core/src/test-files/solr/solr.xml patching file solr/solrj/src/java/org/apache/solr/common/util/URLUtil.java patching file solr/solrj/src/test/org/apache/solr/client/solrj/impl/CloudSolrServerSSLTest.java patching file solr/solrj/src/test/org/apache/solr/common/util/URLUtilTest.java patching file solr/solrj/src/test-files/solrj/solr/solr.xml patching file solr/test-framework/src/java/org/apache/solr/BaseDistributedSearchTestCase.java patching file solr/test-framework/src/java/org/apache/solr/cloud/AbstractFullDistribZkTestBase.java Am I doing something wrong or in the wrong place? I'm admittedly little rusty/unfamiliar with this fast moving (SolrCloud distrib testing) area lately.
          Hide
          Steve Davids added a comment -

          The latest patch was for the trunk.

          Show
          Steve Davids added a comment - The latest patch was for the trunk.
          Hide
          Erik Hatcher added a comment -

          Applying that patch to a clean trunk checkout, I'm getting test failures ("ant test" from the solr/ subdirectory):

             [junit4] Tests with failures (first 10 out of 48):
             [junit4]   - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.test404ViaHttp
             [junit4]   - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.testGetRawFile
             [junit4]   - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.testDirList
             [junit4]   - org.apache.solr.cloud.OverseerTest.testOverseerFailure
             [junit4]   - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch
             [junit4]   - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleField
             [junit4]   - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleFieldRoundTrip
             [junit4]   - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleFieldDefaultFieldTypeRoundTrip
             [junit4]   - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testMultipleFieldsRoundTrip
             [junit4]   - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testParseAndAddMultipleFieldsRoundTrip
          

          I can get the, hopefully relevant details in case that's worthwhile. All runs clean for others?

          Show
          Erik Hatcher added a comment - Applying that patch to a clean trunk checkout, I'm getting test failures ("ant test" from the solr/ subdirectory): [junit4] Tests with failures (first 10 out of 48): [junit4] - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.test404ViaHttp [junit4] - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.testGetRawFile [junit4] - org.apache.solr.handler.admin.ShowFileRequestHandlerTest.testDirList [junit4] - org.apache.solr.cloud.OverseerTest.testOverseerFailure [junit4] - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch [junit4] - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleField [junit4] - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleFieldRoundTrip [junit4] - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testSingleFieldDefaultFieldTypeRoundTrip [junit4] - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testMultipleFieldsRoundTrip [junit4] - org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactoryTest.testParseAndAddMultipleFieldsRoundTrip I can get the, hopefully relevant details in case that's worthwhile. All runs clean for others?
          Hide
          Steve Davids added a comment -

          I was running the tests from within Eclipse without problems, will try to run from ant later this evening. Happen to know if there are any gotchas that you need to take into account between the two?

          Show
          Steve Davids added a comment - I was running the tests from within Eclipse without problems, will try to run from ant later this evening. Happen to know if there are any gotchas that you need to take into account between the two?
          Hide
          Steve Davids added a comment -

          After running the test suite there appears to be some inconsistencies between test runs.

          The first run resulted in 7 failed tests...

          ant -Dtests.jvms=8 test
             [junit4] Tests with failures:
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.powerTest
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.absoluteValueTest
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.divideTest
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.multiplyTest
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.negateTest
             [junit4]   - org.apache.solr.analytics.expression.ExpressionTest.addTest
             [junit4]   - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch
             [junit4] 
             [junit4] 
             [junit4] JVM J0:     2.60 ..   692.15 =   689.55s
             [junit4] JVM J1:     2.12 ..   704.03 =   701.91s
             [junit4] JVM J2:     2.60 ..   692.29 =   689.69s
             [junit4] JVM J3:     2.35 ..   692.78 =   690.43s
             [junit4] JVM J4:     2.12 ..   693.73 =   691.62s
             [junit4] JVM J5:     2.35 ..   693.26 =   690.92s
             [junit4] JVM J6:     2.60 ..   696.68 =   694.08s
             [junit4] JVM J7:     2.35 ..   691.85 =   689.50s
             [junit4] Execution time total: 11 minutes 44 seconds
             [junit4] Tests summary: 366 suites, 1591 tests, 7 failures, 27 ignored (14 assumptions)
          

          Tried it again and 3 tests failed...

          ant -Dtests.jvms=8 test
             [junit4] Tests with failures:
             [junit4]   - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds
             [junit4]   - org.apache.solr.cloud.OverseerRolesTest.testDistribSearch
             [junit4]   - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch
             [junit4] 
             [junit4] 
             [junit4] JVM J0:     2.35 ..   704.78 =   702.43s
             [junit4] JVM J1:     2.35 ..   704.96 =   702.61s
             [junit4] JVM J2:     2.37 ..   704.79 =   702.42s
             [junit4] JVM J3:     2.35 ..   705.01 =   702.66s
             [junit4] JVM J4:     2.35 ..   704.87 =   702.52s
             [junit4] JVM J5:     2.35 ..   766.99 =   764.65s
             [junit4] JVM J6:     2.37 ..   705.05 =   702.68s
             [junit4] JVM J7:     2.59 ..   704.88 =   702.28s
             [junit4] Execution time total: 12 minutes 47 seconds
             [junit4] Tests summary: 366 suites, 1591 tests, 1 error, 2 failures, 26 ignored (13 assumptions)
          

          Decided to isolate just running the SolrCloud test package and all tests passed...

          ant -Dtests.jvms=8 -Dtests.class=org.apache.solr.cloud.* test
             [junit4] JVM J0:     2.22 ..   352.21 =   349.99s
             [junit4] JVM J1:     2.23 ..   371.36 =   369.13s
             [junit4] JVM J2:     2.22 ..   351.94 =   349.72s
             [junit4] JVM J3:     2.22 ..   351.69 =   349.47s
             [junit4] JVM J4:     2.48 ..   356.82 =   354.34s
             [junit4] JVM J5:     2.22 ..   352.47 =   350.25s
             [junit4] JVM J6:     2.22 ..   353.56 =   351.34s
             [junit4] JVM J7:     2.22 ..   384.37 =   382.15s
             [junit4] Execution time total: 6 minutes 24 seconds
             [junit4] Tests summary: 52 suites, 102 tests, 8 ignored (7 assumptions)
               [echo] 5 slowest tests:
          [junit4:tophints] 237.14s | org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest
          [junit4:tophints] 192.24s | org.apache.solr.cloud.BasicDistributedSSLZkTest
          [junit4:tophints] 179.70s | org.apache.solr.cloud.DistribCursorPagingTest
          [junit4:tophints] 179.07s | org.apache.solr.cloud.BasicDistributedZkTest
          [junit4:tophints] 161.44s | org.apache.solr.TestRandomFaceting
          

          Anyone have ideas why there are inconsistencies between test runs?

          Show
          Steve Davids added a comment - After running the test suite there appears to be some inconsistencies between test runs. The first run resulted in 7 failed tests... ant -Dtests.jvms=8 test [junit4] Tests with failures: [junit4] - org.apache.solr.analytics.expression.ExpressionTest.powerTest [junit4] - org.apache.solr.analytics.expression.ExpressionTest.absoluteValueTest [junit4] - org.apache.solr.analytics.expression.ExpressionTest.divideTest [junit4] - org.apache.solr.analytics.expression.ExpressionTest.multiplyTest [junit4] - org.apache.solr.analytics.expression.ExpressionTest.negateTest [junit4] - org.apache.solr.analytics.expression.ExpressionTest.addTest [junit4] - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch [junit4] [junit4] [junit4] JVM J0: 2.60 .. 692.15 = 689.55s [junit4] JVM J1: 2.12 .. 704.03 = 701.91s [junit4] JVM J2: 2.60 .. 692.29 = 689.69s [junit4] JVM J3: 2.35 .. 692.78 = 690.43s [junit4] JVM J4: 2.12 .. 693.73 = 691.62s [junit4] JVM J5: 2.35 .. 693.26 = 690.92s [junit4] JVM J6: 2.60 .. 696.68 = 694.08s [junit4] JVM J7: 2.35 .. 691.85 = 689.50s [junit4] Execution time total: 11 minutes 44 seconds [junit4] Tests summary: 366 suites, 1591 tests, 7 failures, 27 ignored (14 assumptions) Tried it again and 3 tests failed... ant -Dtests.jvms=8 test [junit4] Tests with failures: [junit4] - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds [junit4] - org.apache.solr.cloud.OverseerRolesTest.testDistribSearch [junit4] - org.apache.solr.cloud.BasicDistributedSSLZkTest.testDistribSearch [junit4] [junit4] [junit4] JVM J0: 2.35 .. 704.78 = 702.43s [junit4] JVM J1: 2.35 .. 704.96 = 702.61s [junit4] JVM J2: 2.37 .. 704.79 = 702.42s [junit4] JVM J3: 2.35 .. 705.01 = 702.66s [junit4] JVM J4: 2.35 .. 704.87 = 702.52s [junit4] JVM J5: 2.35 .. 766.99 = 764.65s [junit4] JVM J6: 2.37 .. 705.05 = 702.68s [junit4] JVM J7: 2.59 .. 704.88 = 702.28s [junit4] Execution time total: 12 minutes 47 seconds [junit4] Tests summary: 366 suites, 1591 tests, 1 error, 2 failures, 26 ignored (13 assumptions) Decided to isolate just running the SolrCloud test package and all tests passed... ant -Dtests.jvms=8 -Dtests.class=org.apache.solr.cloud.* test [junit4] JVM J0: 2.22 .. 352.21 = 349.99s [junit4] JVM J1: 2.23 .. 371.36 = 369.13s [junit4] JVM J2: 2.22 .. 351.94 = 349.72s [junit4] JVM J3: 2.22 .. 351.69 = 349.47s [junit4] JVM J4: 2.48 .. 356.82 = 354.34s [junit4] JVM J5: 2.22 .. 352.47 = 350.25s [junit4] JVM J6: 2.22 .. 353.56 = 351.34s [junit4] JVM J7: 2.22 .. 384.37 = 382.15s [junit4] Execution time total: 6 minutes 24 seconds [junit4] Tests summary: 52 suites, 102 tests, 8 ignored (7 assumptions) [echo] 5 slowest tests: [junit4:tophints] 237.14s | org.apache.solr.cloud.ChaosMonkeyNothingIsSafeTest [junit4:tophints] 192.24s | org.apache.solr.cloud.BasicDistributedSSLZkTest [junit4:tophints] 179.70s | org.apache.solr.cloud.DistribCursorPagingTest [junit4:tophints] 179.07s | org.apache.solr.cloud.BasicDistributedZkTest [junit4:tophints] 161.44s | org.apache.solr.TestRandomFaceting Anyone have ideas why there are inconsistencies between test runs?
          Hide
          Mark Miller added a comment -

          Most of those are known flakey tests

          Show
          Mark Miller added a comment - Most of those are known flakey tests
          Hide
          Steve Davids added a comment -

          New patch for the trunk which allows clients to set a "urlScheme" in the recently created "/clusterprops.json" file (SOLR-5610). This allows the OverseerCollectionProcessor & CloudSolrServer to build the proper schemed url given a plain node name outside of the knowledge of each individual core's urlScheme configuration. The functionality enables admin functionality to manipulate the cluster: create/delete/split/etc. Those were the last holdouts that were hard coding a url scheme.

          Show
          Steve Davids added a comment - New patch for the trunk which allows clients to set a "urlScheme" in the recently created "/clusterprops.json" file ( SOLR-5610 ). This allows the OverseerCollectionProcessor & CloudSolrServer to build the proper schemed url given a plain node name outside of the knowledge of each individual core's urlScheme configuration. The functionality enables admin functionality to manipulate the cluster: create/delete/split/etc. Those were the last holdouts that were hard coding a url scheme.
          Hide
          Steve Davids added a comment -

          Just thinking about this a little bit more, if the "urlScheme" is defined in the clusterprops.json file then we can drop the "urlScheme" configuration in the solr.xml - whatever is defined in the clusterprops is applied to all cores on all servers within the cluster. This may make configuration a bit easier but at the potential loss of flexibility, is there a use case where someone only wants to run https in a certain core or certain machines within the cluster (not all). Alternatively, we can use the value defined in the cluster props as the default value if no urlScheme is defined specifically on that core (if not specified anywhere default to http). Just a few thoughts...

          Show
          Steve Davids added a comment - Just thinking about this a little bit more, if the "urlScheme" is defined in the clusterprops.json file then we can drop the "urlScheme" configuration in the solr.xml - whatever is defined in the clusterprops is applied to all cores on all servers within the cluster. This may make configuration a bit easier but at the potential loss of flexibility, is there a use case where someone only wants to run https in a certain core or certain machines within the cluster (not all). Alternatively, we can use the value defined in the cluster props as the default value if no urlScheme is defined specifically on that core (if not specified anywhere default to http). Just a few thoughts...
          Hide
          Mark Miller added a comment -

          That all sounds reasonable to me...

          Show
          Mark Miller added a comment - That all sounds reasonable to me...
          Hide
          Steve Davids added a comment -

          Updated patch from trunk. Chatted with Mark and decided to remove the "hostUrlScheme" from the solr.xml in favor of just setting the "urlScheme" property in the clusterprops.json file.

          Show
          Steve Davids added a comment - Updated patch from trunk. Chatted with Mark and decided to remove the "hostUrlScheme" from the solr.xml in favor of just setting the "urlScheme" property in the clusterprops.json file.
          Hide
          Mark Miller added a comment -

          Thanks Steve - I started looking at this last night and have done a bit more work early this morning. I'm tweaking the tests a little to get some more coverage, but I think things look good overall.

          Show
          Mark Miller added a comment - Thanks Steve - I started looking at this last night and have done a bit more work early this morning. I'm tweaking the tests a little to get some more coverage, but I think things look good overall.
          Hide
          Steve Davids added a comment -

          Thanks, let me know if you need a hand. I was also thinking that the following test should be added to verify the scheme:

            private void testBaseUrlHttpsScheme() {
              List<Replica> replicas = getZkReplicas();
              assertFalse("No replicas found in ZooKeeper", replicas.isEmpty());
              
              for(Replica replica : replicas) {
                String baseUrl = (String) replica.get(ZkStateReader.BASE_URL_PROP);
                assertTrue(baseUrl + " didn't begin with a https url scheme", StringUtils.startsWith(baseUrl, "https://"));
                try {
                  URL url = new URL(baseUrl);
                  assertNotNull("No path can be found for " + replica.getNodeName(), url.getPath());
                } catch (Exception ex) {
                  fail(replica.getNodeName() + " failed to build a proper URL [" + baseUrl + "]");
                }
              }
            }
            
            protected List<Replica> getZkReplicas() {
              List<Replica> replicas = new ArrayList<Replica>();
              ClusterState clusterState = cloudClient.getZkStateReader().getClusterState();
              for(String collection : clusterState.getCollections()) {
                for(Slice slice : clusterState.getSlicesMap(collection).values()) {
                  replicas.addAll(slice.getReplicas());
                }
              }
              
              return replicas;
            }
          
          Show
          Steve Davids added a comment - Thanks, let me know if you need a hand. I was also thinking that the following test should be added to verify the scheme: private void testBaseUrlHttpsScheme() { List<Replica> replicas = getZkReplicas(); assertFalse( "No replicas found in ZooKeeper" , replicas.isEmpty()); for (Replica replica : replicas) { String baseUrl = ( String ) replica.get(ZkStateReader.BASE_URL_PROP); assertTrue(baseUrl + " didn't begin with a https url scheme" , StringUtils.startsWith(baseUrl, "https: //" )); try { URL url = new URL(baseUrl); assertNotNull( "No path can be found for " + replica.getNodeName(), url.getPath()); } catch (Exception ex) { fail(replica.getNodeName() + " failed to build a proper URL [" + baseUrl + "]" ); } } } protected List<Replica> getZkReplicas() { List<Replica> replicas = new ArrayList<Replica>(); ClusterState clusterState = cloudClient.getZkStateReader().getClusterState(); for ( String collection : clusterState.getCollections()) { for (Slice slice : clusterState.getSlicesMap(collection).values()) { replicas.addAll(slice.getReplicas()); } } return replicas; }
          Hide
          Mark Miller added a comment -

          Hmm...it seems like we really don't want to put the scheme in zk as part of the base url - if you want to turn things on and off, it won't respect that anyway.

          Show
          Mark Miller added a comment - Hmm...it seems like we really don't want to put the scheme in zk as part of the base url - if you want to turn things on and off, it won't respect that anyway.
          Hide
          Steve Davids added a comment -

          True, it will only be respected on a server restart. So if you wanted to go from http -> https you would need to update the clusterprops.json then restart all of your nodes to pick up the new configuration. Although, if the scheme was stored as apart of either the HttpShardHandler or in the solr.xml a restart would be required as well. I don't think people will be flipping SSL on/off, more of a global set it and forget it property.

          Show
          Steve Davids added a comment - True, it will only be respected on a server restart. So if you wanted to go from http -> https you would need to update the clusterprops.json then restart all of your nodes to pick up the new configuration. Although, if the scheme was stored as apart of either the HttpShardHandler or in the solr.xml a restart would be required as well. I don't think people will be flipping SSL on/off, more of a global set it and forget it property.
          Hide
          Mark Miller added a comment -

          Server restart is fine - I had it in my head we didn't regenerate the url in zk on every startup - but its only coreNodeName that is not generated. Nevermind.

          Show
          Mark Miller added a comment - Server restart is fine - I had it in my head we didn't regenerate the url in zk on every startup - but its only coreNodeName that is not generated. Nevermind.
          Hide
          Mark Miller added a comment - - edited

          So I looked at pulling the new ssl test code into AbstractFullDistribZkTestBase. Most tests should just work with this, and a couple that explicitly use http or something just need a little getter. Then, rather than run this one test and add the extra test time, like a dozen tests can randomly run with ssl or not.

          The problem is that it seems to all work fine running tests one at a time in eclipse, but running them with ant test has all kinds of fails. I have not figured out why yet. I've tried a few things, but everything looks like it should clean up properly (the latest patch was missing clearing the system properties it set in teardown or afterclass). Somehow the tests are interacting with each other, or they don't work when run by ant (there are some differences unless you pass security managers and what not via your ide).

          Show
          Mark Miller added a comment - - edited So I looked at pulling the new ssl test code into AbstractFullDistribZkTestBase. Most tests should just work with this, and a couple that explicitly use http or something just need a little getter. Then, rather than run this one test and add the extra test time, like a dozen tests can randomly run with ssl or not. The problem is that it seems to all work fine running tests one at a time in eclipse, but running them with ant test has all kinds of fails. I have not figured out why yet. I've tried a few things, but everything looks like it should clean up properly (the latest patch was missing clearing the system properties it set in teardown or afterclass). Somehow the tests are interacting with each other, or they don't work when run by ant (there are some differences unless you pass security managers and what not via your ide).
          Hide
          Mark Miller added a comment -

          The error I see is: Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

          Show
          Mark Miller added a comment - The error I see is: Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
          Hide
          Steve Davids added a comment -

          Fixed the majority of the SSLExceptions by configuring our own HttpClientConfigurer that doesn't complain when it encounters a self-signed cert via the TrustSelfSignedStrategy. There is one more place that complains in the SolrDispatchFilter.remoteQuery(...) method that doesn't use HttpClient (uses standard java.net to establish a connection). We should update that code to go ahead and create an HttpClient instance via HttpClientUtil.createClient(...) which will take care of the last remaining SSLExceptions.

          Show
          Steve Davids added a comment - Fixed the majority of the SSLExceptions by configuring our own HttpClientConfigurer that doesn't complain when it encounters a self-signed cert via the TrustSelfSignedStrategy. There is one more place that complains in the SolrDispatchFilter.remoteQuery(...) method that doesn't use HttpClient (uses standard java.net to establish a connection). We should update that code to go ahead and create an HttpClient instance via HttpClientUtil.createClient(...) which will take care of the last remaining SSLExceptions.
          Hide
          Mark Miller added a comment -

          Oh sweet, thanks!

          Show
          Mark Miller added a comment - Oh sweet, thanks!
          Hide
          Mark Miller added a comment -

          We should update that code to go ahead and create an HttpClient instance via HttpClientUtil.createClient(...) which will take care of the last remaining SSLExceptions.

          See SOLR-5700: Improve error handling of remote queries (proxied requests)

          Show
          Mark Miller added a comment - We should update that code to go ahead and create an HttpClient instance via HttpClientUtil.createClient(...) which will take care of the last remaining SSLExceptions. See SOLR-5700 : Improve error handling of remote queries (proxied requests)
          Hide
          Steve Davids added a comment -

          Attached a new patch that fixes the BasicDistributedZk2Test (was using java.net instead of using HttpClient). Also, with the SOLR-5700 patch applied (left separate) it fixed the other broken test with SSLExceptions.

          Show
          Steve Davids added a comment - Attached a new patch that fixes the BasicDistributedZk2Test (was using java.net instead of using HttpClient). Also, with the SOLR-5700 patch applied (left separate) it fixed the other broken test with SSLExceptions.
          Hide
          Mark Miller added a comment -

          Thanks Steve! I'm seeing a similar fail as before in an unrelated CacheHeaderTest - I've stopped there. Perhaps a test clean up issue? I'm headed out for a bit, but I'll take a look tomorrow.

          Show
          Mark Miller added a comment - Thanks Steve! I'm seeing a similar fail as before in an unrelated CacheHeaderTest - I've stopped there. Perhaps a test clean up issue? I'm headed out for a bit, but I'll take a look tomorrow.
          Hide
          Mark Miller added a comment -

          Do we clean up the HttpClientConfigurer after each test so that the next test in that jvm gets as clean env? Or is there something else to clean up?

          Show
          Mark Miller added a comment - Do we clean up the HttpClientConfigurer after each test so that the next test in that jvm gets as clean env? Or is there something else to clean up?
          Hide
          Mark Miller added a comment -

          I see the configurer clean up in teardown. I'm not sure what I'm seeing. My guess is that you don't see it because of test ordering (I run 8 test jvms in parallel and the default is much lower). I'll dig in tomorrow if you don't get to it first.

          Show
          Mark Miller added a comment - I see the configurer clean up in teardown. I'm not sure what I'm seeing. My guess is that you don't see it because of test ordering (I run 8 test jvms in parallel and the default is much lower). I'll dig in tomorrow if you don't get to it first.
          Hide
          Steve Davids added a comment -

          Did you apply the SolrDispatchFilter changes from the patch in SOLR-5700?

          Show
          Steve Davids added a comment - Did you apply the SolrDispatchFilter changes from the patch in SOLR-5700 ?
          Hide
          Mark Miller added a comment -

          Yeah, SOLR-5700 has been committed and is part of what I'm testing. Still seeing a lot of fails. Taking a look.

          Show
          Mark Miller added a comment - Yeah, SOLR-5700 has been committed and is part of what I'm testing. Still seeing a lot of fails. Taking a look.
          Hide
          Steve Davids added a comment -

          Oh, it could be because the extra call to

          initSSLConfig(sslConfig, keystorePath);

          has been removed in SolrJettyTestBase.getSSLConfig() which has now turned on SSL for tests that previously weren't configured to run SSL since the initSSL method sets

          sslConfig.useSsl = false;
          sslConfig.clientAuth = false;
          
          Show
          Steve Davids added a comment - Oh, it could be because the extra call to initSSLConfig(sslConfig, keystorePath); has been removed in SolrJettyTestBase.getSSLConfig() which has now turned on SSL for tests that previously weren't configured to run SSL since the initSSL method sets sslConfig.useSsl = false ; sslConfig.clientAuth = false ;
          Hide
          Mark Miller added a comment -

          Yeah, I had pulled that out in the last patch I put up because it looked like a test bug, tossing out the randomized settings.

          Show
          Mark Miller added a comment - Yeah, I had pulled that out in the last patch I put up because it looked like a test bug, tossing out the randomized settings.
          Hide
          Mark Miller added a comment -

          I'm working through each of them. I'll be done shortly I think.

          Show
          Mark Miller added a comment - I'm working through each of them. I'll be done shortly I think.
          Hide
          ASF subversion and git services added a comment -

          Commit 1566456 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1566456 ]

          SOLR-3854: SSL support for SolrCloud

          Show
          ASF subversion and git services added a comment - Commit 1566456 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1566456 ] SOLR-3854 : SSL support for SolrCloud
          Hide
          Mark Miller added a comment -

          I just committed an initial pass to trunk. Since we are just working out tests here, it will be easier to collaborate this way - patch is getting unwieldy.

          The latest has SSL working for almost all tests randomly, if possible. Some tests are excluded for various reasons. It's a huge expansion in our coverage though.

          Currently, we don't use the client auth setting. Perhaps that can be improved by someone that understands it better than I. I'd have to dig first.

          Steve Davids, I'll leave this open in the case you have any further patches in you. Likewise, let me know if everything looks okay to you.

          Show
          Mark Miller added a comment - I just committed an initial pass to trunk. Since we are just working out tests here, it will be easier to collaborate this way - patch is getting unwieldy. The latest has SSL working for almost all tests randomly, if possible. Some tests are excluded for various reasons. It's a huge expansion in our coverage though. Currently, we don't use the client auth setting. Perhaps that can be improved by someone that understands it better than I. I'd have to dig first. Steve Davids , I'll leave this open in the case you have any further patches in you. Likewise, let me know if everything looks okay to you.
          Show
          Mark Miller added a comment - https://github.com/apache/lucene-solr/commit/e400b48a7e778d17678311b1d48f9fcb7e741b0d
          Hide
          Steve Davids added a comment -

          Awesome, will take a little bit more of a deep-dive. One thing I noticed right away though, what's the reason for adding

          <str name="urlScheme">${urlScheme:}</str>

          throughout the various solr.xml files? That shouldn't be necessary with the patch.

          Show
          Steve Davids added a comment - Awesome, will take a little bit more of a deep-dive. One thing I noticed right away though, what's the reason for adding <str name= "urlScheme" >${urlScheme:}</str> throughout the various solr.xml files? That shouldn't be necessary with the patch.
          Hide
          Mark Miller added a comment -

          Yeah, it's needed - not all tests are solrcloud tests or have zookeeper involved. Those tests now also use SSL randomly and do distrib searches and need to turn on the https scheme.

          One of the base SolrCloud tests will clear that system property. Probably better if that was cleared randomly for better coverage.

          Show
          Mark Miller added a comment - Yeah, it's needed - not all tests are solrcloud tests or have zookeeper involved. Those tests now also use SSL randomly and do distrib searches and need to turn on the https scheme. One of the base SolrCloud tests will clear that system property. Probably better if that was cleared randomly for better coverage.
          Hide
          ASF subversion and git services added a comment -

          Commit 1566483 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1566483 ]

          SOLR-3854: Boost test timeouts - SSL can be slower.

          Show
          ASF subversion and git services added a comment - Commit 1566483 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1566483 ] SOLR-3854 : Boost test timeouts - SSL can be slower.
          Hide
          Steve Davids added a comment -

          Attached a new patch from trunk that allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class.

          Show
          Steve Davids added a comment - Attached a new patch from trunk that allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class.
          Hide
          ASF subversion and git services added a comment -

          Commit 1566515 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1566515 ]

          SOLR-3854: Allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. Also try and address failing the statics retained check.

          Show
          ASF subversion and git services added a comment - Commit 1566515 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1566515 ] SOLR-3854 : Allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. Also try and address failing the statics retained check.
          Hide
          Mark Miller added a comment -

          Thanks Steve! Great stuff.

          Show
          Mark Miller added a comment - Thanks Steve! Great stuff.
          Hide
          Steve Davids added a comment -

          Looks like the ALLOW_SSL property doesn't get reset to true in the afterClass method (should replace sslConfig = null; in SolrTestCaseJ4). Other than that, I don't see any glaring issues - have a timeline for pushing this to the 4.x branch? If there are any outstanding issues you would like me to look at just let me know.

          Show
          Steve Davids added a comment - Looks like the ALLOW_SSL property doesn't get reset to true in the afterClass method (should replace sslConfig = null; in SolrTestCaseJ4). Other than that, I don't see any glaring issues - have a timeline for pushing this to the 4.x branch? If there are any outstanding issues you would like me to look at just let me know.
          Hide
          ASF subversion and git services added a comment -

          Commit 1566883 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1566883 ]

          SOLR-3854 : Reset ALLOW_SSL in afterClass.

          Show
          ASF subversion and git services added a comment - Commit 1566883 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1566883 ] SOLR-3854 : Reset ALLOW_SSL in afterClass.
          Hide
          Mark Miller added a comment -

          Thanks Steve - I'll merge back to 4x fairly soon.

          Show
          Mark Miller added a comment - Thanks Steve - I'll merge back to 4x fairly soon.
          Hide
          ASF subversion and git services added a comment -

          Commit 1567203 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1567203 ]

          SOLR-3854 : Disable SSL on OSX for this test for now.

          Show
          ASF subversion and git services added a comment - Commit 1567203 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1567203 ] SOLR-3854 : Disable SSL on OSX for this test for now.
          Hide
          Mark Miller added a comment -

          As reported on the email list, using SSL with "BasicDistributedZk2Test" on OSX causes the following exception:

          	Caused by: java.net.SocketException: Invalid argument
          		at java.net.SocketInputStream.socketRead0(Native Method)
          		at java.net.SocketInputStream.read(SocketInputStream.java:152)
          		at java.net.SocketInputStream.read(SocketInputStream.java:122)
          		at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
          		at sun.security.ssl.InputRecord.read(InputRecord.java:480)
          		at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927)
          		at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884)
          		at sun.security.ssl.AppInputStream.read(AppInputStream.java:102)
          		at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160)
          		at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84)
          		at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273)
          		at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
          		at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
          		at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260)
          		at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283)
          		at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251)
          		at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197)
          		at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271)
          		at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123)
          		at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682)
          		at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486)
          		at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863)
          		at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
          		at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
          		at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
          		at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:395)
          		... 11 more
          
          Show
          Mark Miller added a comment - As reported on the email list, using SSL with "BasicDistributedZk2Test" on OSX causes the following exception: Caused by: java.net.SocketException: Invalid argument at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:152) at java.net.SocketInputStream.read(SocketInputStream.java:122) at sun.security.ssl.InputRecord.readFully(InputRecord.java:442) at sun.security.ssl.InputRecord.read(InputRecord.java:480) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:927) at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:884) at sun.security.ssl.AppInputStream.read(AppInputStream.java:102) at org.apache.http.impl.io.AbstractSessionInputBuffer.fillBuffer(AbstractSessionInputBuffer.java:160) at org.apache.http.impl.io.SocketInputBuffer.fillBuffer(SocketInputBuffer.java:84) at org.apache.http.impl.io.AbstractSessionInputBuffer.readLine(AbstractSessionInputBuffer.java:273) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:260) at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) at org.apache.http.impl.conn.ManagedClientConnectionImpl.receiveResponseHeader(ManagedClientConnectionImpl.java:197) at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:271) at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:123) at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:682) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:486) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:863) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:395) ... 11 more
          Hide
          Steve Davids added a comment -

          I was able to reproduce this problem in OSX in both BasicDistributedZk2Test and BasicDistributedZkTest when using two-way SSL by configuring "useSsl = true" and "useClientAuth = true". Once the useClientAuth was turned off it seems to consistently provide good test runs.

          Here is the full test suite results:

          trySsl = true, trySslClientAuth = true
             [junit4] Tests with failures:
             [junit4]   - org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch
             [junit4]   - org.apache.solr.TestDistributedSearch.testDistribSearch
             [junit4]   - org.apache.solr.cloud.DistribCursorPagingTest.testDistribSearch
             [junit4]   - org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch
             [junit4]   - org.apache.solr.TestDistributedGrouping.testDistribSearch
             [junit4]   - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds
             [junit4] 
             [junit4] 
             [junit4] JVM J0:     2.58 ..   899.26 =   896.67s
             [junit4] JVM J1:     2.81 ..   899.14 =   896.33s
             [junit4] JVM J2:     2.58 ..   899.03 =   896.45s
             [junit4] JVM J3:     2.59 ..   899.27 =   896.69s
             [junit4] JVM J4:     2.58 ..   899.27 =   896.69s
             [junit4] JVM J5:     2.84 ..   899.09 =   896.25s
             [junit4] JVM J6:     2.80 ..   899.13 =   896.33s
             [junit4] JVM J7:     2.58 ..   899.07 =   896.49s
             [junit4] Execution time total: 14 minutes 59 seconds
             [junit4] Tests summary: 372 suites, 1603 tests, 5 errors, 1 failure, 26 ignored (13 assumptions)
          
          trySsl = true, trySslClientAuth = false
             [junit4] Tests with failures:
             [junit4]   - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds
             [junit4] 
             [junit4] 
             [junit4] JVM J0:     2.27 ..   716.97 =   714.69s
             [junit4] JVM J1:     2.28 ..   716.79 =   714.51s
             [junit4] JVM J2:     2.27 ..   716.99 =   714.72s
             [junit4] JVM J3:     2.52 ..   716.78 =   714.26s
             [junit4] JVM J4:     2.28 ..   716.82 =   714.54s
             [junit4] JVM J5:     2.52 ..   717.00 =   714.48s
             [junit4] JVM J6:     2.28 ..   716.80 =   714.52s
             [junit4] JVM J7:     2.27 ..   716.95 =   714.67s
             [junit4] Execution time total: 11 minutes 57 seconds
             [junit4] Tests summary: 372 suites, 1603 tests, 1 failure, 26 ignored (13 assumptions)
          

          I attached a patch which cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients. Shawn Heisey was kind enough to perform a few test runs (BasicDistributedZkTest & BasicDistributedZk2Test) on both windows and linux with both SSL params set to true with clean test runs.

          Show
          Steve Davids added a comment - I was able to reproduce this problem in OSX in both BasicDistributedZk2Test and BasicDistributedZkTest when using two-way SSL by configuring "useSsl = true" and "useClientAuth = true". Once the useClientAuth was turned off it seems to consistently provide good test runs. Here is the full test suite results: trySsl = true, trySslClientAuth = true [junit4] Tests with failures: [junit4] - org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch [junit4] - org.apache.solr.TestDistributedSearch.testDistribSearch [junit4] - org.apache.solr.cloud.DistribCursorPagingTest.testDistribSearch [junit4] - org.apache.solr.cloud.BasicDistributedZkTest.testDistribSearch [junit4] - org.apache.solr.TestDistributedGrouping.testDistribSearch [junit4] - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds [junit4] [junit4] [junit4] JVM J0: 2.58 .. 899.26 = 896.67s [junit4] JVM J1: 2.81 .. 899.14 = 896.33s [junit4] JVM J2: 2.58 .. 899.03 = 896.45s [junit4] JVM J3: 2.59 .. 899.27 = 896.69s [junit4] JVM J4: 2.58 .. 899.27 = 896.69s [junit4] JVM J5: 2.84 .. 899.09 = 896.25s [junit4] JVM J6: 2.80 .. 899.13 = 896.33s [junit4] JVM J7: 2.58 .. 899.07 = 896.49s [junit4] Execution time total: 14 minutes 59 seconds [junit4] Tests summary: 372 suites, 1603 tests, 5 errors, 1 failure, 26 ignored (13 assumptions) trySsl = true, trySslClientAuth = false [junit4] Tests with failures: [junit4] - org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeMixedAdds [junit4] [junit4] [junit4] JVM J0: 2.27 .. 716.97 = 714.69s [junit4] JVM J1: 2.28 .. 716.79 = 714.51s [junit4] JVM J2: 2.27 .. 716.99 = 714.72s [junit4] JVM J3: 2.52 .. 716.78 = 714.26s [junit4] JVM J4: 2.28 .. 716.82 = 714.54s [junit4] JVM J5: 2.52 .. 717.00 = 714.48s [junit4] JVM J6: 2.28 .. 716.80 = 714.52s [junit4] JVM J7: 2.27 .. 716.95 = 714.67s [junit4] Execution time total: 11 minutes 57 seconds [junit4] Tests summary: 372 suites, 1603 tests, 1 failure, 26 ignored (13 assumptions) I attached a patch which cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients. Shawn Heisey was kind enough to perform a few test runs (BasicDistributedZkTest & BasicDistributedZk2Test) on both windows and linux with both SSL params set to true with clean test runs.
          Hide
          ASF subversion and git services added a comment -

          Commit 1567643 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1567643 ]

          SOLR-3854: Cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients.

          Show
          ASF subversion and git services added a comment - Commit 1567643 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1567643 ] SOLR-3854 : Cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients.
          Hide
          ASF subversion and git services added a comment -

          Commit 1567700 from Mark Miller in branch 'dev/trunk'
          [ https://svn.apache.org/r1567700 ]

          SOLR-3854: Update MorphlineGoLiveMiniMRTest for SSL. Disable SSL for now .

          Show
          ASF subversion and git services added a comment - Commit 1567700 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1567700 ] SOLR-3854 : Update MorphlineGoLiveMiniMRTest for SSL. Disable SSL for now .
          Hide
          ASF subversion and git services added a comment -

          Commit 1567701 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1567701 ]

          SOLR-3854: Update MorphlineGoLiveMiniMRTest for SSL. Disable SSL for now .

          Show
          ASF subversion and git services added a comment - Commit 1567701 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1567701 ] SOLR-3854 : Update MorphlineGoLiveMiniMRTest for SSL. Disable SSL for now .
          Hide
          ASF subversion and git services added a comment -

          Commit 1567703 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1567703 ]

          SOLR-3854: Revert last commit - SSL not on 4x yet.

          Show
          ASF subversion and git services added a comment - Commit 1567703 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1567703 ] SOLR-3854 : Revert last commit - SSL not on 4x yet.
          Hide
          Hoss Man added a comment -

          I think there's a maven config problem here that still needs resolved...

          https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1103/

          Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1103: POMs out of sync
          
          Hmmm...  lots of compilation failures from Maven build regarding 
          http-client classess not found?
          
          This seems to have been a problem with the maven build since Feb 10...
          
          https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1101/
          
          ...looking at the commits, i think this looks like the suspicious one...
          
          https://svn.apache.org/viewvc?view=revision&revision=1566456
          
          It's the only commit arround that day that changes an ivy.xml file, and 
          that change relates to httpcomponents...
          
          https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/ivy.xml?r1=1566456&r2=1566455&pathrev=1566456
          
          
          ...so it looks like something else needs to change in the maven configs as 
          well?
          
          Show
          Hoss Man added a comment - I think there's a maven config problem here that still needs resolved... https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1103/ Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1103: POMs out of sync Hmmm... lots of compilation failures from Maven build regarding http-client classess not found? This seems to have been a problem with the maven build since Feb 10... https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1101/ ...looking at the commits, i think this looks like the suspicious one... https://svn.apache.org/viewvc?view=revision&revision=1566456 It's the only commit arround that day that changes an ivy.xml file, and that change relates to httpcomponents... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/ivy.xml?r1=1566456&r2=1566455&pathrev=1566456 ...so it looks like something else needs to change in the maven configs as well?
          Hide
          Steve Davids added a comment -

          Seems like adding HttpClient wasn't necessary - was able to compile and run tests without it. Quick patch to revert:

          Index: solr/core/ivy.xml
          ===================================================================
          --- solr/core/ivy.xml	(revision 1566863)
          +++ solr/core/ivy.xml	(working copy)
          @@ -48,7 +48,6 @@
               <dependency org="org.easymock" name="easymock" rev="${/org.easymock/easymock}" conf="test->*"/>
               <dependency org="cglib" name="cglib-nodep" rev="${/cglib/cglib-nodep}" conf="test->*"/>
               <dependency org="org.objenesis" name="objenesis" rev="${/org.objenesis/objenesis}" conf="test->*"/>
          -    <dependency org="org.apache.httpcomponents" name="httpclient" rev="${/org.apache.httpcomponents/httpclient}" conf="test->*"/>
           
               <dependency org="org.apache.hadoop" name="hadoop-common" rev="${/org.apache.hadoop/hadoop-common}" conf="compile.hadoop->*"/>
               <!--
          
          Show
          Steve Davids added a comment - Seems like adding HttpClient wasn't necessary - was able to compile and run tests without it. Quick patch to revert: Index: solr/core/ivy.xml =================================================================== --- solr/core/ivy.xml (revision 1566863) +++ solr/core/ivy.xml (working copy) @@ -48,7 +48,6 @@ <dependency org="org.easymock" name="easymock" rev="${/org.easymock/easymock}" conf="test->*"/> <dependency org="cglib" name="cglib-nodep" rev="${/cglib/cglib-nodep}" conf="test->*"/> <dependency org="org.objenesis" name="objenesis" rev="${/org.objenesis/objenesis}" conf="test->*"/> - <dependency org="org.apache.httpcomponents" name="httpclient" rev="${/org.apache.httpcomponents/httpclient}" conf="test->*"/> <dependency org="org.apache.hadoop" name="hadoop-common" rev="${/org.apache.hadoop/hadoop-common}" conf="compile.hadoop->*"/> <!--
          Hide
          Steve Rowe added a comment -

          Seems like adding HttpClient wasn't necessary - was able to compile and run tests without it. Quick patch to revert:

          Thanks Steve, I came to the same conclusion and also successfully ran all core tests without this redundant dependency (since solrj/lib/*.jar is included in Solr core's compile classpath, and so also its test classpath).

          I'll commit shortly.

          Show
          Steve Rowe added a comment - Seems like adding HttpClient wasn't necessary - was able to compile and run tests without it. Quick patch to revert: Thanks Steve, I came to the same conclusion and also successfully ran all core tests without this redundant dependency (since solrj/lib/*.jar is included in Solr core's compile classpath, and so also its test classpath). I'll commit shortly.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568184 from Steve Rowe in branch 'dev/trunk'
          [ https://svn.apache.org/r1568184 ]

          SOLR-3854: remove redundant solr-core test dependency on httpclient

          Show
          ASF subversion and git services added a comment - Commit 1568184 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1568184 ] SOLR-3854 : remove redundant solr-core test dependency on httpclient
          Hide
          ASF subversion and git services added a comment -

          Commit 1568340 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568340 ]

          SOLR-3854: SSL support for SolrCloud.

          Show
          ASF subversion and git services added a comment - Commit 1568340 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568340 ] SOLR-3854 : SSL support for SolrCloud.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568341 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568341 ]

          SOLR-3854: Boost test timeouts - SSL can be slower.

          Show
          ASF subversion and git services added a comment - Commit 1568341 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568341 ] SOLR-3854 : Boost test timeouts - SSL can be slower.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568347 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568347 ]

          SOLR-3854: Allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. Also try and address failing the statics retained check.

          Show
          ASF subversion and git services added a comment - Commit 1568347 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568347 ] SOLR-3854 : Allows the test harness to perform two-way SSL handshakes, the two-way SSL will now be randomly selected during test runs. Also, cleaned up some of the code by breaking out the SSLConfig into a separate class. Also try and address failing the statics retained check.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568351 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568351 ]

          SOLR-3854 : Reset ALLOW_SSL in afterClass.

          Show
          ASF subversion and git services added a comment - Commit 1568351 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568351 ] SOLR-3854 : Reset ALLOW_SSL in afterClass.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568356 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568356 ]

          SOLR-3854 : Disable SSL on OSX for this test for now.

          Show
          ASF subversion and git services added a comment - Commit 1568356 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568356 ] SOLR-3854 : Disable SSL on OSX for this test for now.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568357 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568357 ]

          SOLR-3854: Cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients.

          Show
          ASF subversion and git services added a comment - Commit 1568357 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568357 ] SOLR-3854 : Cleans up a lot of the tests by using a common function to build a consistent schemed URL (fixes SSL for SolrCmdDistributorTest) + disabled the "useClientAuth" property for OSX clients.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568363 from Mark Miller in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568363 ]

          SOLR-3854: remove redundant solr-core test dependency on httpclient.

          Show
          ASF subversion and git services added a comment - Commit 1568363 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568363 ] SOLR-3854 : remove redundant solr-core test dependency on httpclient.
          Hide
          Mark Miller added a comment -

          Thanks to everyone that contributed to getting this done! And an extral thanks to Steve for driving it home.

          Show
          Mark Miller added a comment - Thanks to everyone that contributed to getting this done! And an extral thanks to Steve for driving it home.
          Hide
          ASF subversion and git services added a comment -

          Commit 1568689 from hossman@apache.org in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1568689 ]

          re-apply r1567231, which seems to have been inadvertantly reverted in r1568340 as part of SOLR-3854

          Show
          ASF subversion and git services added a comment - Commit 1568689 from hossman@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1568689 ] re-apply r1567231, which seems to have been inadvertantly reverted in r1568340 as part of SOLR-3854
          Hide
          Mark Miller added a comment -

          As Noble brought up in 4.7 vote thread:

          The new scheme property has to be white listed to work with the cluster properties api.

          Currently, a user will have to manually add the entry to ZooKeeper. We should open a new issue depending on whether or not the fix makes it into a respin.

          Show
          Mark Miller added a comment - As Noble brought up in 4.7 vote thread: The new scheme property has to be white listed to work with the cluster properties api. Currently, a user will have to manually add the entry to ZooKeeper. We should open a new issue depending on whether or not the fix makes it into a respin.
          Hide
          Steve Davids added a comment -

          Came across an issue with the release candidate... Unfortunately when switching from http -> https it causes the same node to become a replica for that shard group. That is because the base url is being compared in the clusterstate to grab the previously assigned core node name / shard id. I attached a patch that uses the nodeName instead (essentially the same as baseUrl just without the scheme). It is important to note that the port is actually embedded in the node name, so if the port changes the machine will be added as a new replica. Thus, if clients would like to update their port from 8080 -> 8443 they would need to update the node_name value in the clusterstate.json file in zookeeper.

          Here is how to get the clusterprops.json initially populated in the example:

          steves-mbp:cloud-scripts sdavids$ pwd
          /Users/sdavids/Downloads/solr-4.7.0/example/scripts/cloud-scripts
          steves-mbp:cloud-scripts sdavids$ ./zkcli.sh -zkhost localhost:9983 -cmd put /clusterprops.json '{"urlScheme":"https"}'
          
          Show
          Steve Davids added a comment - Came across an issue with the release candidate... Unfortunately when switching from http -> https it causes the same node to become a replica for that shard group. That is because the base url is being compared in the clusterstate to grab the previously assigned core node name / shard id. I attached a patch that uses the nodeName instead (essentially the same as baseUrl just without the scheme). It is important to note that the port is actually embedded in the node name, so if the port changes the machine will be added as a new replica. Thus, if clients would like to update their port from 8080 -> 8443 they would need to update the node_name value in the clusterstate.json file in zookeeper. Here is how to get the clusterprops.json initially populated in the example: steves-mbp:cloud-scripts sdavids$ pwd /Users/sdavids/Downloads/solr-4.7.0/example/scripts/cloud-scripts steves-mbp:cloud-scripts sdavids$ ./zkcli.sh -zkhost localhost:9983 -cmd put /clusterprops.json '{ "urlScheme" : "https" }'
          Hide
          ASF subversion and git services added a comment -

          Commit 1570797 from Noble Paul in branch 'dev/trunk'
          [ https://svn.apache.org/r1570797 ]

          SOLR-3854 urlScheme property should be whitelisted

          Show
          ASF subversion and git services added a comment - Commit 1570797 from Noble Paul in branch 'dev/trunk' [ https://svn.apache.org/r1570797 ] SOLR-3854 urlScheme property should be whitelisted
          Hide
          ASF subversion and git services added a comment -

          Commit 1570798 from Noble Paul in branch 'dev/branches/lucene_solr_4_7'
          [ https://svn.apache.org/r1570798 ]

          SOLR-3854 urlScheme property should be whitelisted

          Show
          ASF subversion and git services added a comment - Commit 1570798 from Noble Paul in branch 'dev/branches/lucene_solr_4_7' [ https://svn.apache.org/r1570798 ] SOLR-3854 urlScheme property should be whitelisted
          Hide
          ASF subversion and git services added a comment -

          Commit 1570799 from Noble Paul in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1570799 ]

          SOLR-3854 urlScheme property should be whitelisted

          Show
          ASF subversion and git services added a comment - Commit 1570799 from Noble Paul in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1570799 ] SOLR-3854 urlScheme property should be whitelisted
          Hide
          Mark Miller added a comment -

          Thanks Steve Davids. Sorry for the delayed response, have not been feeling well. Unless there is another RC we can discuss getting this into, which seems unlikely at this point, we will have to address it in a 4.7.1 or 4.8 release.

          That is because the base url is being compared in the clusterstate to grab the previously assigned core node name / shard id.

          That sounds like an ugly bug, though I have not looked at the code or patch yet.

          Show
          Mark Miller added a comment - Thanks Steve Davids . Sorry for the delayed response, have not been feeling well. Unless there is another RC we can discuss getting this into, which seems unlikely at this point, we will have to address it in a 4.7.1 or 4.8 release. That is because the base url is being compared in the clusterstate to grab the previously assigned core node name / shard id. That sounds like an ugly bug, though I have not looked at the code or patch yet.
          Hide
          Mark Miller added a comment -

          The previous issue has been moved to: SOLR-5770

          There is an issue with opting out of SSL for a unit tests here: SOLR-5771

          Show
          Mark Miller added a comment - The previous issue has been moved to: SOLR-5770 There is an issue with opting out of SSL for a unit tests here: SOLR-5771
          Hide
          ASF subversion and git services added a comment -

          Commit 1574951 from Steve Rowe in branch 'dev/trunk'
          [ https://svn.apache.org/r1574951 ]

          SOLR-3854: IntelliJ config: add solr example lib test dependency to map-reduce and dataimporthandler contribs

          Show
          ASF subversion and git services added a comment - Commit 1574951 from Steve Rowe in branch 'dev/trunk' [ https://svn.apache.org/r1574951 ] SOLR-3854 : IntelliJ config: add solr example lib test dependency to map-reduce and dataimporthandler contribs
          Hide
          ASF subversion and git services added a comment -

          Commit 1574953 from Steve Rowe in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1574953 ]

          SOLR-3854: IntelliJ config: add solr example lib test dependency to map-reduce and dataimporthandler contribs (merged trunk r1574951)

          Show
          ASF subversion and git services added a comment - Commit 1574953 from Steve Rowe in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1574953 ] SOLR-3854 : IntelliJ config: add solr example lib test dependency to map-reduce and dataimporthandler contribs (merged trunk r1574951)

            People

            • Assignee:
              Mark Miller
              Reporter:
              Sami Siren
            • Votes:
              7 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development