如何进行多次修改CDH集群关联的Kerberos域后Spark无法正常获得短名称映射的问题排查，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

成都创新互联公司是一家专注于网站建设、网站制作与策划设计,克东网站建设哪家好?成都创新互联公司做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:克东等地区。克东做网站价格咨询:18982081108

环境：

CDH 6.3.1

Oracle JDK 1.8.0_181

已开启Kerberos

症状表现：

该集群曾经更换了关联的Kerberos域名称，由XY.COM.CN改为了XY.COM。

现在又重新进行了更换，由XY.COM重新改为了XY.COM.CN。

修改完成后，集群重启，Cloudera Manager（以下简称CM）显示一切正常。

但是在使用Spark的过程中，发现在非Kerberos服务端的节点，执行spark的命令行工具（包括spark-shell、spark-submit等），就直接报错。提示获取短名称的规则不存在：

[main] util.KerberosName(KerberosName.java:getShortName(401)) - No auth_to_local rules applied to cloudera-scm/admin@XY.COM does not exist

解决过程：

从报错信息来看，spark-shell仍然尝试用之前的Kerberos域名来进行短名称映射。

可以看到报错信息中，getShortName方法还是会去找Kerberos域“XY.COM”对应的解析规则；然而现在这个Kerberos域XY.COM实际已经不存在，现在的规则是对应XY.COM.CN的，所以自然无法对cloudera-scm/admin@XY.COM应用有效的短名称规则。

CDH中，spark的命令行工具都是默认读取CM下发的配置文件，那么首先推测的情况，就有可能是集群关联的Kerberos域修改后，CM没有成功下发新的客户端配置。

尝试在CM界面刷新和重新部署各个服务的客户端。但是没有效果。还是会报同样的错误。

此时推断是CM本身在应对已经实施Kerberos安全的集群的Kerberos域修改时，下发客户端配置的部分存在一些问题，导致没有成功分发正确的配置文件。

那么我们必须找到一个能触发涉及Kerberos主体映射相关配置文件下发的选项，修改后重新进行下发，让正确的配置覆盖目前节点上的客户端配置文件。

打开CM，找到HDFS服务，找到配置项中的“将 Kerberos 主体映射到短名称的其他规则”。

该选项本来是留给不符合标准Kerberos命名方式的主体自定义短名称映射用的。正常情况下，只要是标准的Kerberos主体名称形式（例如hive/manager1@XY.COM.CN，或者hive@XY.COM.CN），这个选项的默认值“DEFAULT”就能正确拿到用户名（例如hive/manager1@XY.COM.CN会被最终映射为短名称hive），不需要我们手工再指定。

因为HDFS是所有其他服务组件都要依赖的核心组件，我们通过这个选项的修改，肯定会触发所有涉及认证的服务的客户端部署。

填入自定义映射规则的内容，进行保存，这个自定义映射规则实际等同于“DEFAULT”的效果：

RULE:[1:$1@$0](.*@\XY.COM.CN)s/@\XY.COM.CN//RULE:[2:$1@$0](.*@\XY.COM.CN)s/@\XY.COM.CN//

点击保存。提示重启服务，这时勾选上重新部署客户端。

重启完成后，重新运行spark-shell，一切正常！问题解决。

看完上述内容，你们掌握如何进行多次修改CDH集群关联的Kerberos域后Spark无法正常获得短名称映射的问题排查的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！