在 kerberized CDH 集群中运行 kudu fsck答案

【问题标题】：Run kudu fsck in a kerberised CDH cluster在 kerberized CDH 集群中运行 kudu fsck
【发布时间】：2020-04-03 15:09:44
【问题描述】：

我正在尝试让 cloudera 管理器在 kudu 集群上运行检查，最终将是以下命令，以 kudu 用户身份运行：：

kudu cluster ksck master_host

这个命令的输出是：

未授权：leader master liveness check error：无法连接到集群：客户端连接协商失败：客户端连接到 10.x.y.z:7051：服务器需要身份验证，但客户端没有可用的 Kerberos 凭据

如果我从命令行手动运行这个命令，作为 kudu，我有同样的错误。如果我尝试运行kinit，则会要求 kudu 用户输入密码，但据我了解，所有“后端”用户都是无密码的。

如果我更新 $HOME/.klogin 以允许我的用户使用 ksu 我确实有一张 krb 票（klist 显示它）但它仍然不是 kudu 用户的票，我最终拥有同样的错误信息。

我的 kerberos-fu 很弱，但据我所知，集群配置良好，spark/impala/kudu 可以很好地协同工作，没有授权问题。检查器全是绿色的，集群的所有主机都有 kudu 凭据。

我怎样才能让这个命令从 cloudera 管理器中正常运行？

【问题讨论】：

“所有‘后端’用户都没有密码” > 错误。服务帐户将其密码存储在密钥表文件中。要将命令作为 svc 帐户运行，您必须 kinit -kt keytab_file SPN （通常在运行服务的节点上，以便 keytab 已经存在）跨度>
当然，同时处理多个 kerberos 凭据非常危险，尤其是作为 root 用户，因此将临时 env var KRB5CCNAME 设置为“私有”缓存文件是一种很好的做法。
我的立场是正确的，谢谢。我仍然无法从 cloudera manager 运行 ksck，但我确实找到了 keytab 文件。

【解决方案1】：

半答案：

要在命令行中运行命令，您可以从 kudu 的 superuser_acl 设置中的用户帐户运行它。然后作为该用户运行kinit，然后您可以运行kudu cluster ksck 命令。

这并不能解释为什么来自 cloudera manger 的同一用户仍然无法运行重新平衡，但至少我有一个变通办法。

【讨论】：