[
https://issues.apache.org/jira/browse/SOLR-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032710#comment-15032710
]
Gregory Chanan commented on SOLR-6915:
--------------------------------------
bq. This is still failing fairly frequently on Jenkins runs, particularly on
Java 9 (eg http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14737/). Maybe
the thing to do is to wrap the MiniKDC startup method in an assumeTrue(), if we
know there are certain locales that break this?
I think that's more or less what was done in SOLR-7183. I think the issue is
that just maintains a list of known bad locales instead of running checks on
the locales to programatically figure out what was wrong. And there are new
locales in JDK9. So easiest thing to do is add more to the list, medium
solution is to runs checks on the locale, best solution is to fix MiniKDC.
Just a note: http://jenkins.thetaphi.de/job/Lucene-Solr-5.x-Linux/14789/ fails
with ar_TD
> SaslZkACLProvider and Kerberos Test Using MiniKdc
> -------------------------------------------------
>
> Key: SOLR-6915
> URL: https://issues.apache.org/jira/browse/SOLR-6915
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Fix For: 5.1, Trunk
>
> Attachments: SOLR-6915.patch, SOLR-6915.patch, fail.log, fail.log,
> tests-failures.txt
>
>
> We should provide a ZkACLProvider that requires SASL authentication. This
> provider will be useful for administration in a kerberos environment. In
> such an environment, the administrator wants solr to authenticate to
> zookeeper using SASL, since this is only way to authenticate with zookeeper
> via kerberos.
> The authorization model in such a setup can vary, e.g. you can imagine a
> scenario where solr owns (is the only writer of) the non-config znodes, but
> some set of trusted users are allowed to modify the configs. It's hard to
> predict all the possibilities here, but one model that seems generally useful
> is to have a model where solr itself owns all the znodes and all actions that
> require changing the znodes are routed to Solr APIs. That seems simple and
> reasonable as a first version.
> As for testing, I noticed while working on SOLR-6625 that we don't really
> have any infrastructure for testing kerberos integration in unit tests.
> Internally, I've been testing using kerberos-enabled VM clusters, but this
> isn't great since we won't notice any breakages until someone actually spins
> up a VM. So part of this JIRA is to provide some infrastructure for testing
> kerberos at the unit test level (using Hadoop's MiniKdc, HADOOP-9848).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]