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，但是鏈接字符串還是采用普通連接方式，所以報錯。