javax.security.auth.login.LoginException: Checksum failed
之前碰到过类似的问题，都是因为服务器端的keytab问题；多半是因为重新生成了keytab后，客户端需要重新声场keytab；但是这次不是，即使我重新生成了客户端的keytab仍然无法好用。
难道这个异常不是因为客户端的秘钥和服务器端秘钥不相符造成的吗？
确实是，但是这次比之前的情况要负责的多。所有的这一切都是因为在客户端使用了一个指令：ktadd，无论是在kadmin的shell下还是在kutil的工具中使用，ktadd我之前的理解是把秘钥导出来而已；但是其实不是，他其实是重新生成了秘钥（和之前是否一致不确定），生成的keytab中至少version是不一致（想到这一点是因为sha1sum指令下两次生成的keytab的散列值是不一样的）。这个生成会影响到KDC的结果；因为client和server都是依赖于keytab文件，所以这个时候就出现了客户端和服务器端文件不一致；
我之前碰到这种情况通常都是将通过cloudera manager来重新生成秘钥，推测应该也是使用ktadd来重新生成秘钥；这继续导致了问题：client的keytab过期了；于是客户端再次向服务器端发出请求，服务器端发现有问题，告知checksum error；这就进入了一种恶性循环。客户端再次重新生成keytab，服务器端自身验证又失败。
直到我认识到了看到的checksum failed 并不是client的验证失败，而是服务器自己定时周期验证失败之后，问题的症结才找到：ktadd将会导致秘钥文件发生变化；而作为keytab模式的常见的解决方案就是在某一端生成了秘钥文件之后，拷贝到各个集群中；一定要保证keytab文件的一致性。
如此，问题解决。
详细说明如下：
之前我一直以为是因为我提交了beeline -u "jdbc:hive2://10.1.108.65:10000/default;principal=hive/slave1@BD.COM;auth=kerberos"才导致的后台checksum；但是其实不是，本质原因是因为ktadd其实是一个重新生成keytab过程，而且是修改了KDC的密码的过程；
import kerber可以指定修改的密码；但是注意修改之后，需要在“gengerate missing keytab”中生成一次；貌似修改会导致keytab的丢失。
开启了kerberos之后，再来安装impala就需要手动在KDC中添加impala用户，然后再cloudera中“generate missing credentials”
研究Kerberos的hive链接字符串问题；终于研究明白了；原来之前的ktadd并不是导出keytab，而是改变了认证了信息；每次ktadd都会导致这个用户的验证信息（加密信息）发生变化；所以我在客户端调用ktadd，导致hive服务端验证失败，除非它在重新生成才能够正常运行；但是它已重新生成，本质也是ktadd一下，这样client的keytab也就过期了；于是就形成了一个死循环。昨晚解决的方式就是手动的设置一下hive/slave1@BD.COM的密码，然后在cloudera中重新import一下主体信息（也是输入密码方式）；然后重启hive服务，搞定了。
后续还要研究一下到底怎么来玩；其实还是应该生成的keytab在这个集群中复制一份；比如我在65的cloudera中生成了keytab（启动kerberos的时候，其实都会为各个主体创建keytab文件，只要在cm的目录下面搜索*.keytab即可，然后把这份keytab拷贝到各个集群下属的服务器，之后采用kinit -kt进行登录即可。
Keytab里面装了不少东西，版本号，实体名称，实体key（long-term key，根据密码计算出来的）；根据实测，每次ktadd出来的东西都不一样，后来想想也是，至少版本号是不一致的。
import kerber可以指定修改的密码；但是注意修改之后，需要在“gengerate missing keytab”中生成一次；貌似修改会导致keytab的丢失。
开启了kerberos之后，再来安装impala就需要手动在KDC中添加impala用户，然后再cloudera中“generate missing credentials”
研究Kerberos的hive链接字符串问题；终于研究明白了；原来之前的ktadd并不是导出keytab，而是改变了认证了信息；每次ktadd都会导致这个用户的验证信息（加密信息）发生变化；所以我在客户端调用ktadd，导致hive服务端验证失败，除非它在重新生成才能够正常运行；但是它已重新生成，本质也是ktadd一下，这样client的keytab也就过期了；于是就形成了一个死循环。昨晚解决的方式就是手动的设置一下hive/slave1@BD.COM的密码，然后在cloudera中重新import一下主体信息（也是输入密码方式）；然后重启hive服务，搞定了。
后续还要研究一下到底怎么来玩；其实还是应该生成的keytab在这个集群中复制一份；比如我在65的cloudera中生成了keytab（启动kerberos的时候，其实都会为各个主体创建keytab文件，只要在cm的目录下面搜索*.keytab即可，然后把这份keytab拷贝到各个集群下属的服务器，之后采用kinit -kt进行登录即可。
Keytab里面装了不少东西，版本号，实体名称，实体key（long-term key，根据密码计算出来的）；根据实测，每次ktadd出来的东西都不一样，后来想想也是，至少版本号是不一致的。
Peer indicated failure: Unsupported mechanism type GSSAPI
这是因为hive所在集群已经关闭了kerberos，但是连接字符串还是采用kerberos方式就会爆此错误；
与之对应的是“Unsupported mechanism type PLAIN”，代表服务器已经开启了kerberos，但是链接字符串还是采用普通连接方式，所以报错。
这是因为hive所在集群已经关闭了kerberos，但是连接字符串还是采用kerberos方式就会爆此错误；
与之对应的是“Unsupported mechanism type PLAIN”，代表服务器已经开启了kerberos，但是链接字符串还是采用普通连接方式，所以报错。