[
https://issues.apache.org/jira/browse/SOLR-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15567838#comment-15567838
]
Mikhail Khludnev commented on SOLR-9200:
----------------------------------------
https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/6175/
{code}
[junit4] 2> 1072871 ERROR (jetty-launcher-1462-thread-2)
[n:127.0.0.1:64463_solr ] o.a.h.u.Shell Failed to locate the winutils binary
in the hadoop binary path
[junit4] 2> java.io.IOException: Could not locate executable
null\bin\winutils.exe in the Hadoop binaries.
[junit4] 2> at
org.apache.hadoop.util.Shell.getQualifiedBinPath(Shell.java:356)
[junit4] 2> at
org.apache.hadoop.util.Shell.getWinUtilsPath(Shell.java:371)
[junit4] 2> at org.apache.hadoop.util.Shell.<clinit>(Shell.java:364)
[junit4] 2> at
org.apache.hadoop.util.StringUtils.<clinit>(StringUtils.java:80)
[junit4] 2> at
org.apache.hadoop.conf.Configuration.getBoolean(Configuration.java:1437)
[junit4] 2> at
org.apache.hadoop.security.token.delegation.web.DelegationTokenManager.<init>(DelegationTokenManager.java:115)
{code}
[~thetaphi], is it possible to provide -Dhadoop.home.dir=C:\hadoop where
bin\winutils.exe is located. Or just ignore it from windows run?
> Add Delegation Token Support to Solr
> ------------------------------------
>
> Key: SOLR-9200
> URL: https://issues.apache.org/jira/browse/SOLR-9200
> Project: Solr
> Issue Type: New Feature
> Components: security
> Reporter: Gregory Chanan
> Assignee: Gregory Chanan
> Fix For: 6.2, master (7.0)
>
> Attachments: SOLR-9200.patch, SOLR-9200.patch, SOLR-9200.patch,
> SOLR-9200.patch, SOLR-9200.patch, SOLR-9200_branch_6x.patch,
> SOLR-9200_branch_6x.patch, SOLR-9200_branch_6x.patch
>
>
> SOLR-7468 added support for kerberos authentication via the hadoop
> authentication filter. Hadoop also has support for an authentication filter
> that supports delegation tokens, which allow authenticated users the ability
> to grab/renew/delete a token that can be used to bypass the normal
> authentication path for a time. This is useful in a variety of use cases:
> 1) distributed clients (e.g. MapReduce) where each client may not have access
> to the user's kerberos credentials. Instead, the job runner can grab a
> delegation token and use that during task execution.
> 2) If the load on the kerberos server is too high, delegation tokens can
> avoid hitting the kerberos server after the first request
> 3) If requests/permissions need to be delegated to another user: the more
> privileged user can request a delegation token that can be passed to the less
> privileged user.
> Note to self:
> In
> https://issues.apache.org/jira/browse/SOLR-7468?focusedCommentId=14579636&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14579636
> I made the following comment which I need to investigate further, since I
> don't know if anything changed in this area:
> {quote}3) I'm a little concerned with the "NoContext" code in KerberosPlugin
> moving forward (I understand this is more a generic auth question than
> kerberos specific). For example, in the latest version of the filter we are
> using at Cloudera, we play around with the ServletContext in order to pass
> information around
> (https://github.com/cloudera/lucene-solr/blob/cdh5-4.10.3_5.4.2/solr/core/src/java/org/apache/solr/servlet/SolrHadoopAuthenticationFilter.java#L106).
> Is there any way we can get the actual ServletContext in a plugin?{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
