hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kihwal Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-5628) Some namenode servlets should not be internal.
Date Thu, 05 Dec 2013 23:10:35 GMT

    [ https://issues.apache.org/jira/browse/HDFS-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840676#comment-13840676
] 

Kihwal Lee commented on HDFS-5628:
----------------------------------

The main thing is FsckServlet and the token sevlets. I do not care much about others, but
was going to do them for the completeness.  We are experimenting with a change in kerberos
auth handler, which will require no change in HDFS.  I think we will move this jira to the
common project and update the tile eventually.

> Some namenode servlets should not be internal.
> ----------------------------------------------
>
>                 Key: HDFS-5628
>                 URL: https://issues.apache.org/jira/browse/HDFS-5628
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.2.0
>            Reporter: Kihwal Lee
>
> This is the list of internal servlets added by namenode.
> | Name | Auth | Need to be accessible by end users |
> | StartupProgressServlet | none | no |
> | GetDelegationTokenServlet | internal SPNEGO | yes |
> | RenewDelegationTokenServlet | internal SPNEGO | yes |
> |  CancelDelegationTokenServlet | internal SPNEGO | yes |
> |  FsckServlet | internal SPNEGO | yes |
> |  GetImageServlet | internal SPNEGO | no |
> |  ListPathsServlet | token in query | yes |
> |  FileDataServlet | token in query | yes |
> |  FileChecksumServlets | token in query | yes |
> | ContentSummaryServlet | token in query | yes |
> GetDelegationTokenServlet, RenewDelegationTokenServlet, CancelDelegationTokenServlet
and FsckServlet are accessed by end users, but hard-coded to use the internal SPNEGO filter.
> If a name node HTTP server binds to multiple external IP addresses, the internal SPNEGO
service principal name may not work with an address to which end users are connecting.  The
current SPNEGO implementation in Hadoop is limited to use a single service principal per filter.
> If the underlying hadoop kerberos authentication handler cannot easily be modified, we
can at least create a separate auth filter for the end-user facing servlets so that their
service principals can be independently configured. If not defined, it should fall back to
the current behavior.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message