[INFO] 2022-12-29 16:24:26.021 ?- [taskAppId=TASK-678-305576-2357578]:[127] - ?-> workspace /data/DATA_DIR/share/dw_ia_portraitsearch
?? ?kinit -kt /data/DATA_DIR/share/keytab/hive.keytab hive@CDP.COM
?? ?kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1006) while getting initial credentials

腳本在執(zhí)行kinit的過程中 報錯，注意 這個錯是隨即錯，也就是有時候會出現(xiàn)，有時候不會出現(xiàn)。

出現(xiàn)原因也很簡單，就是多個任務(wù)同時執(zhí)行kinit。。。

網(wǎng)上看到的大多文章都是起源這篇

Parallel kinit calls lead to a corrupted Kerberos cache - Stack Overflow

當(dāng)時出了這個問題后，我看小組里的用到了這個辦法

export KRB5CCNAME=tmp/krb5cc_`date +%m%d%H%M%S%N`

指定了一個環(huán)境變量有什么用嗎？ 我暫時是感覺不到，但是別人說有用，也許有點，開始研究下，見到了這篇文章。

Kerberos kinit crontab定時任務(wù)不生效的問題解決 - 一杯半盞 - 博客園

我們linux常規(guī)認(rèn)證kerberos 一般都是

kinit -kt /data/DATA_DIR/share/keytab/hive.keytab hive@CDH.COM

kinit -kt /data/DATA_DIR/share/keytab/hive.keytab hive-- 可以省略后面的realm

那么我們認(rèn)證了這個會發(fā)生那些物理變化？

?通過klist可以看到生成了一個cache? /tmp/krb5cc_1000，其中后綴1000也就是devuser的uid ，我們在tmp目錄下就看到了這個。

先不討論上面的問題。我們來測試一下。

同時開兩個窗口a b 登錄用戶都是devuser

然后窗口a，kinit 認(rèn)證，b能否直接hdfs dfs -ls /

kinit -kt /data/DATA_DIR/share/keytab/hive.keytab hive?

可以看到左邊顯示kdestroy了，右邊klist 確實沒了，然后左邊認(rèn)證，右邊可以hdfs dfs -ls/ 成功。

這個說明什么問題？ 當(dāng)我們devuser認(rèn)證了，那么其他用戶在使用devuser的時候都是有權(quán)限的，即使我現(xiàn)在再重新開一個窗口。

這樣好嗎？不好?。?！但是無所謂，沒人會在意這細節(jié)，能夠認(rèn)證已經(jīng)花費我們的大部分精力了，還想要我咋樣？？？但是今天沒事就研究下。

比如現(xiàn)在有這種要求，生產(chǎn)環(huán)境只給大家一個devuser的用戶去登錄，并且按照良好習(xí)慣要求大家kinit認(rèn)證使用完了之后即使kdestroy。

那么會出現(xiàn) a 登錄后 kinit? 開始做xxxxxx ，

這時b也登錄devuser ，但是b發(fā)現(xiàn)klist有人已經(jīng)認(rèn)證了，那b怎么辦，(b現(xiàn)在也可以hdfs dfs -ls )

但是呢 萬一我工作了一半，此時a工作完了kdestroy了 我怎么辦？

?

?上一秒我還可以好好干活 下一秒我就不能干活了。 有人又說了你重新認(rèn)證下步就好了嗎？

確實是，但是我重新認(rèn)證的過程中，萬一又來了個c，和我同樣的遭遇呢？

又有人說不destroy不就好了？一般認(rèn)證可以管一天 續(xù)期7天，七天認(rèn)證下，不也可以么？問題的關(guān)鍵是 你這樣一直認(rèn)證確實可以解決，但是我們使用kerberos的目的就是安全，你這樣一直認(rèn)證，等于說別人只要知道了你devuser的密碼就可以(等你認(rèn)證或有效期內(nèi))在hdfs上為所欲為?，而之前他需要kinit，他需要知道keytab的位置和principal。

所以其實最好的辦法是一人一個賬號 一個keytab

或者就是 每個人使用不同的緩存去認(rèn)證，你destroy是去掉自己的緩存而我不受影響。

左邊還是認(rèn)證的krb5cc_1000， 右邊認(rèn)證的krb5cc_devuser 我們自己搞得一個cache。兩者互不干擾，左邊destroy了右邊還是可以的。

所以同事的那種export KRB5CCNAME=tmp/krb5cc_`date +%m%d%H%M%S%N` 是可行的。

但是真的需要這個么？

我們的腳本都是通過dolphin去調(diào)用shell，dolphin的用戶對應(yīng)的租戶都是producer，就是說只有一個用戶，但是有成千上萬個任務(wù)，真的需要全部都kinit一遍嗎？

?文章來源地址http://www.zghlxwxcb.cn/news/detail-539848.html

?

到了這里，關(guān)于kinit: Failed to store credentials: Internal credentials cache error (filename: /tmp/krb5cc_1006)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！