[
https://issues.apache.org/jira/browse/HDFS-7359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198839#comment-14198839
]
Chris Nauroth commented on HDFS-7359:
-------------------------------------
That's a good question. I believe we'll still have debugging information in
that case thanks to this code in {{ImageServlet}}:
{code}
LOG.info("ImageServlet rejecting: " + remoteUser);
{code}
{code}
if (UserGroupInformation.isSecurityEnabled()
&& !isValidRequestor(context, request.getUserPrincipal().getName(),
conf)) {
String errorMsg = "Only Namenode, Secondary Namenode, and administrators
may access "
+ "this servlet";
response.sendError(HttpServletResponse.SC_FORBIDDEN, errorMsg);
LOG.warn("Received non-NN/SNN/administrator request for image or edits
from "
+ request.getUserPrincipal().getName()
+ " at "
+ request.getRemoteHost());
throw new IOException(errorMsg);
}
{code}
I guess another possibility would be to change the new debug log message in the
catch block to warn level and include the values of
{{DFS_SECONDARY_NAMENODE_KERBEROS_PRINCIPAL_KEY}} and
{{DFS_NAMENODE_SECONDARY_HTTP_ADDRESS_KEY}}.
Let me know your thoughts, and if necessary, I can upload a v3. Thanks again!
> NameNode in secured HA cluster fails to start if
> dfs.namenode.secondary.http-address cannot be interpreted as a network
> address.
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-7359
> URL: https://issues.apache.org/jira/browse/HDFS-7359
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: journal-node
> Reporter: Chris Nauroth
> Assignee: Chris Nauroth
> Attachments: HDFS-7359.1.patch, HDFS-7359.2.patch
>
>
> In a secured cluster, the JournalNode validates that the caller is one of a
> valid set of principals. One of the principals considered is that of the
> SecondaryNameNode. This involves checking
> {{dfs.namenode.secondary.http-address}} and trying to interpret it as a
> network address. If a user has specified a value for this property that
> cannot be interpeted as a network address, such as "null", then this causes
> the JournalNode operation to fail, and ultimately the NameNode cannot start.
> The JournalNode should not have a hard dependency on
> {{dfs.namenode.secondary.http-address}} like this. It is not typical to run
> a SecondaryNameNode in combination with JournalNodes. There is even a check
> in SecondaryNameNode that aborts if HA is enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
