diary/Kojima

・rpc.gssd

Plamoのカーネルを3.11系にあげると、NFSマウントで30秒くらい時間待ちが生じる。 dmesgのログを見てみると、

[   50.547782] Key type id_resolver registered
[   50.547803] Key type id_legacy registered
[   65.538043] RPC: AUTH_GSS upcall timed out.
Please check user daemon is running.

なんてメッセージが残っていた。

このメッセージを手掛りにざっと調べてみたところ、 どうやらNFSv4が暗号化機能を持ったRPC(RPCSEC_GSS)を利用しようとしているのだけど、 そのために必要な rpc.gssd が存在しないことが原因らしい。

このrpc.gssdはnfs-utilsパッケージに含まれていて、 Kerberosが提供するGSS_APIを利用するようになっているのだけれど、 Plamoが採用しているHeimdal(スウェーデンで開発されたKerberos互換システム)だと うまくビルドできなかったので、nfs-utilsでは configure 時に --disable-gss していたので、Plamo nfs_utilsパッケージには含まれていない。

NFSv4のセキュアマウント機能は、意識して使ったことが無かったので、 rpc.gssdが無くても特に気にはならなっかたのだけど、 最近のカーネルではNFSv4のデフォルト動作がRPCSEC_GSSを使うようになっている気配。

どこから変ったのかは確認していないけど、以前使っていた3.8/3.9系のカーネルで 
はロードされていなかった rpcsec_gss_krb5.ko が、3.11系カーネルだとNFSマウント時
にロードされている模様。

仕方ないのでrpc.gssdを作ろうと調べたら、まずはlibtirpcレベルでGSSに対応する必要があり、 nfs-utilsがHeimdalのGSSを使わない問題はSuSE方面で対応パッチが公開されていたので、 それを適用することで、rpc.gssdもビルドすることができた。

ただし、カーネルモジュール rpcsec_gss_krb5.ko は自動的にロードされるものの、 rpc.gssd は自動起動はされないので、使うためには/etc/rc.d/rc.inet2 のNFS関係のデーモンを起動しているところで追加して起動してやらないといけない模様。

ちなみに rpc.gssdはクライアント側のデーモンで、サーバ側ではrpc.svcgssdというデーモンが必要になるようだけど、両者を組み合わせるとRPCSEC_GSSが実現できるのかまでは確認できていない。



トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2021-12-17 (金) 16:35:42