You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Gregory Chanan (JIRA)" <ji...@apache.org> on 2015/12/01 00:26:11 UTC
[jira] [Commented] (SOLR-6915) SaslZkACLProvider and Kerberos Test
Using MiniKdc
[ 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org