[
https://issues.apache.org/jira/browse/SOLR-6915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293247#comment-14293247
]
Emmanuel Lecharny commented on SOLR-6915:
-----------------------------------------
I would suggest you switch to ApacheDS M19. M15 is quite ancient, and depends
on LDAP API 1.0.0-M20, which is 9 version behind already.
Although the GenerilizedTimeSyntaxChecker has not changed for years... FTR, the
date "270126230030Z" is perfectly valid, and I don't see how possibly it can
fail. Here is the code :
http://svn.apache.org/viewvc/directory/shared/trunk/ldap/model/src/main/java/org/apache/directory/api/ldap/model/schema/syntaxCheckers/GeneralizedTimeSyntaxChecker.java?revision=1002871&view=markup
> 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.0, 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]
