次の状況に直面しました。 GNU画面セッションが実行中であり、AFSにアクセスできなくなりました。トークンの有効期限が切れました。ただし、新しいシェルからアクセスできます。違いは次のとおりです。この問題問題は、Kerberosチケットがないため（ak、aklogが探している領域ではない）aklogを呼び出すことができないことです。私もそんなチケットは買えません。 AFSがどのように設定されているかはわかりませんが、機能します。
Kerberos チケットは /tmp/krb5cc* に「保存」され、KRB5CCNAME という変数で指定されます。 Kerberosとscreen / tmuxにこの問題がある場合は、kinitを実行するか、KRB5CCNAMEを設定して最新のチケットを古いシェルに移植できます。
AFS資格情報がどのように指定されているのか疑問に思いますが、同様にこれをシェル（AFSアクセス権を持つsshシェル）から内部シェル（screen -rAFSアクセス権がなくなった後に取得されるシェル）に移植できるかどうか疑問に思います。 ）））。 2つのシェル間で関連する環境変数が変更されていないようです。strace tokensアクセス専用と言いますが/proc/fs/openafs/afs_ioctl、これはプロセスに関連しており、特殊なカーネル機能を使用しているため、非常に難しいことを意味します。シェルを閉じて新しいシェルを開かずにAFSに再びアクセスできる方法についてのアイデアはありますか？
ベストアンサー1
sshを介してログインし、pam_afs_session.soが有効になると、Kerberosチケットが作成され、それを使用してAFSトークンを生成します。ログアウトすると、KerberosチケットとAFSトークンが削除されます。
ご存知のように、Kerberosチケットはファイルに保存され、AFSトークンはカーネルのPAG（Process Authentication Groups）に保存されます。 2番目のSSHセッションを介して接続すると、pam_afs_session.soライブラリは新しいファイルに新しいKerberosチケットを作成し、新しいPAGに新しいAFSトークンを生成します。
GNUスクリーンセッションでAFSトークンをアクティブに保つ最も簡単な方法は次のとおりです。
- 新しいKerberosチケットファイルを作成します。既存のものはこのように見えるかもしれません。/tmp/krb5cc_UID_RANDOM。新しいRANDOM文字列を使用して1つを作成します。
- 作成した新しいチケットファイルに既存のチケットファイルをコピーします。
- KRB5CCNAME環境変数を作成した新しい名前に変更してエクスポートします。
- 起動画面-r
- これでシェルからログアウトできます。これにより、古いチケットファイルからKerberosチケットが削除されますが、コピーは内部シェルで引き続き有効です。ただし、AFSトークンも削除されるため...
- 内部シェルに再接続したら、次を実行します。aklog。これにより、保存されたKerberosチケットが新しいAFSトークンにコピーされます。有効期限が切れるまで有効でなければなりません。内部シェルを終了する前に、以下を実行する必要があります。破壊する不要になったKerberosチケットを削除してください。