This is an automated email from the ASF dual-hosted git repository.
tarmstrong pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/impala.git
commit 71db6db378d638ab5d4cab41e7b8fc343620f753
Author: Alex Rodoni <arod...@cloudera.com>
AuthorDate: Mon Jan 28 18:18:38 2019 -0800
IMPALA-8111: [DOCS] Added KRPC-related known issues
Change-Id: I806bedcb9d16140413bb6a1f42798be9d1b6371c
Reviewed-on: http://gerrit.cloudera.org:8080/12291
Reviewed-by: Michael Ho <k...@cloudera.com>
Tested-by: Alex Rodoni <arod...@cloudera.com>
---
docs/topics/impala_known_issues.xml | 90 +++++++++++++++++++++++++++++++++----
1 file changed, 82 insertions(+), 8 deletions(-)
diff --git a/docs/topics/impala_known_issues.xml
b/docs/topics/impala_known_issues.xml
index b498197..0353e28 100644
--- a/docs/topics/impala_known_issues.xml
+++ b/docs/topics/impala_known_issues.xml
@@ -91,17 +91,16 @@ under the License.
<concept id="IMPALA-4978">
- <title>Impala requires FQDN from hostname command on kerberized
clusters</title>
+ <title>Impala requires FQDN from hostname command on Kerberized
+ clusters</title>
<conbody>
- <p>
- The method Impala uses to retrieve the host name while constructing
the Kerberos
- principal is the <codeph>gethostname()</codeph> system call. This
function might not
- always return the fully qualified domain name, depending on the
network configuration.
- If the daemons cannot determine the FQDN, Impala does not start on a
kerberized
- cluster.
- </p>
+ <p> The method Impala uses to retrieve the host name while constructing
+ the Kerberos principal is the <codeph>gethostname()</codeph> system
+ call. This function might not always return the fully qualified
domain
+ name, depending on the network configuration. If the daemons cannot
+ determine the FQDN, Impala does not start on a Kerberized cluster.
</p>
<p>
<b>Workaround:</b> Test if a host is affected by checking whether
the output of the
@@ -241,6 +240,81 @@ under the License.
</p>
</conbody>
</concept>
+ <concept id="IMPALA-7585">
+ <title>Impala user not added to /etc/passwd when LDAP is enabled</title>
+ <conbody>
+ <p>When using Impala with LDAP enabled, a user may hit the
+ following:</p>
+ <pre>Not authorized: Client connection negotiation failed: client
connection to 127.0.0.1:27000: SASL(-1): generic failure: All-whitespace
username.</pre>
+ <p>The following sequence can lead to the <codeph>impala</codeph> user
+ not being created in <codeph>/etc/passwd</codeph> on some machines on
+ the cluster.<ul>
+ <li>Time 1: The <codeph>impala</codeph> user is not in LDAP. Impala
+ was installed on machine 1, and the user <codeph>impala</codeph>
+ is created in <codeph>/etc/passwd</codeph>. </li>
+ <li>Time 2: The <codeph>impala</codeph> user is added to LDAP.</li>
+ <li>Time 3: A new machine is added to the cluster. When adding
+ Impala service to this new machine, adding the
+ <codeph>impala</codeph> user will fail as it already exists in
+ LDAP.</li>
+ </ul></p>
+ <p>The consequence is that the <codeph>impala</codeph> user doesn't
+ exist in <codeph>/etc/passwd</codeph> on the new machine, leading to
+ the error above.</p>
+ <p><b>Workaround</b>: Manually edit <codeph>/etc/passwd</codeph> to add
+ the <codeph>impala</codeph> user</p>
+ <p><b>Bug:</b>
+ <xref keyref="IMPALA-7585">IMPALA-7585</xref></p>
+ <p><b>Affected Versions:</b> Impala 2.12, Impala 3.0</p>
+ <p><b>Fixed Version:</b> Impala 3.1</p>
+ </conbody>
+ </concept>
+ <concept id="IMPALA-7298">
+ <title>Kerberos authentication fails with the reverse DNS lookup
+ disabled</title>
+ <conbody>
+ <p> Kerberos authentication does not function correctly if <codeph>rdns
+ = false</codeph> is configured in <codeph>krb5.conf</codeph>. If
the
+ flag <codeph>rdns = false</codeph>, when Impala tries to match
+ principals, it will fail because Kerberos receives a SPN (Service
+ Principal Name) with an IP address in it, but Impala expects a
+ principal with a FQDN in it. </p>
+ <p>You may hit the following error:</p>
+ <pre>WARNINGS: TransmitData() to X.X.X.X:27000 failed: Not authorized:
Client connection negotiation failed: client connection to X.X.X.X:27000:
Server impala/x.x....@vpc.cloudera.com not found in Kerberos database
+</pre>
+ <p>
+ <b>Bug:</b>
+ <xref keyref="IMPALA-7298">IMPALA-7298</xref></p>
+ <p><b>Affected Versions:</b> Impala 2.12.0 and 3.0</p>
+ <p>
+ <b>Workaround:</b> Set the following flags in
+ <codeph>krb5.conf</codeph>: <ul>
+ <li><codeph>dns_canonicalize_hostname = true</codeph></li>
+ <li><codeph>rdns = true</codeph></li>
+ </ul></p>
+ <p><b>Fixed Versions:</b> Impala 3.1</p>
+ </conbody>
+ </concept>
+ <concept id="KUDU-2198">
+ <title>System-wide auth-to-local mapping not applied correctly to Kudu
+ service account</title>
+ <conbody>
+ <p>Due to system "auth_to_local" mapping, the principal may be mapped
to
+ some local name.</p>
+ <p>When running with Kerberos enabled, you may hit the following error
+ message where <varname><random-string></varname> is some random
+ string which doesn't match the primary in the Kerberos principal.</p>
+ <pre>WARNINGS: TransmitData() to X.X.X.X:27000 failed: Remote error:
Not authorized: {username='<random-string>', principal='impala/redacted'} is
not allowed to access DataStreamService
+</pre>
+ <p><b>Workaround</b>: Start Impala with the
+ <codeph>--use_system_auth_to_local=false</codeph> flag to ignore
the
+ system-wide <codeph>auth_to_local</codeph> mappings configured in
+ <codeph>/etc/krb5.conf</codeph>.</p>
+ <p><b>Bug:</b> KUDU-2198</p>
+ <p><b>Affected Versions:</b> Kudu 1.6</p>
+ <p><b>Fixed Version:</b> Kudu 1.6</p>
+ </conbody>
+ </concept>
</concept>
<concept id="known_issues_resources">
