第27章 ファイルシステム
再試行タイムアウトを設定すると、SSSD からのマウントなしで autofs が起動しないようになりました。
autofs ユーティリティーを起動すると、sss マップソースがマップ情報を提供する準備ができていませんでしたが、sss は、マップが 存在 しない状態と 利用できない状態を区別するための適切なエラーを返しません でした。その結果、自動マウントが正しく機能せず、SSSD からのマウントなしで autofs が起動しました。このバグを修正するために、map does not exist エラーが発生すると、autofs は、設定可能な期間にわたって SSSD にマスターマップを要求することを再試行します。これで、再試行タイムアウトを適切な値に設定し、マスターマップが読み込まれ、autofs が期待どおりに開始するようになりました。(BZ#1101782)
autofs パッケージに README.autofs-schema ファイルと更新されたスキーマが含まれる
samples/autofs.schema ディストリビューションファイルが古く、正しくありませんでした。結果として、誰かが誤った LDAP スキーマを使用している可能性があります。ただし、使用中のスキーマの変更は強制できません。今回の更新により、以下が可能になります。
- 問題を記述し、可能な場合はどのスキーマを使用するかを推奨するために、
README.autofs-schemaファイルが追加されました。
NIS サーバーに保存されているマップにアクセスするために automount を再起動する必要がなくなりました。
以前は、
autofs ユーティリティーは、起動時に NIS クライアントサービスを待ちませんでした。そのため、プログラムの起動時にネットワークマップソースが利用できなかった場合、マスターマップを読み取ることができませんでした。また、NIS サーバーに保存されているマップにアクセスするには、自動マウント サービスを再起動する必要がありました。今回の更新で、autofs は、マスターマップが利用可能になり、起動マップを取得するまで待機します。その結果、automount は NIS ドメインからマップにアクセスできるようになり、起動ごとに autofs を再起動する必要がなくなりました。
設定された待機時間後も NIS マップが利用できない場合は、
autofs 設定の master_wait オプションを増やす必要がある場合があります。ほとんどの場合、パッケージで使用される待機時間は十分です。(BZ#1383194)
autofs でローカルマウントの可用性をチェックすると、失敗する前に長いタイムアウトが発生しなくなりました。
以前は、ローカルマシンのバインドマウントが利用可能であることが予想されるため、
autofs がローカルと見なされるマウント要求に対してサーバー可用性プローブは実行されませんでした。バインドマウントが失敗した場合は、ローカルマシンへの NFS マウントが試行されました。ただし、NFS サーバーがローカルマシンで実行していないと、マウントの試行に失敗する前にタイムアウトが長くなる場合がありました。
バインドマウントが最初に試行されたにも関わらず失敗するケースに可用性プローブが追加され、
autofs はローカルマシンで NFS サーバーを使用しようとするようにフォールバックするようになりました。その結果、ローカルマシンのバインドマウントに失敗すると、ローカルの NFS サーバーが実行していない場合に、ローカルマシンで NFS マウントを試行するフォールバックがすぐに失敗します。(BZ#1420574)
GFS2 ファイルシステムを読み取り専用としてマウントすると、ジャーナルはアイドルとマークされる
GFS2 ファイルシステムを読み取り専用としてマウントする場合、カーネルはファイルシステムジャーナルをアイドルとマークしませんでした。その結果、
gfs2_log_flush （） 関数が誤ってヘッダーブロックをジャーナルに書き込もうとし、シーケンス順不同のエラーがログに記録されました。GFS2 ファイルシステムを読み取り専用としてマウントするときに、ジャーナルをアイドル状態とマークするパッチが適用されました。その結果、上記のエラーは上記のシナリオでは発生しなくなりました。(BZ#1213119)
id コマンドで誤った UID および GID が表示されなくなる
NFSv4 サーバーに接続されている NFSv4 クライアントで Red Hat Enterprise Linux を実行すると、NFS id mapper キーリングからキーが期限切れになった後、id コマンドで誤った UID および GID が表示されました。この問題は、期限切れの鍵がガベージコレクションされるまで 5 分間持続します。その後、新しいキーがキーリングに作成され、id コマンドで正しい出力が提供されました。今回の更新で、キーリング機能が修正され、上記の状況で id コマンドが誤った出力を表示しなくなりました。(BZ#1408330)
ラベル付けされた NFS がデフォルトでオフになる
Red Hat Enterprise Linux NFS サーバー上の SELinux ラベルは、通常、NFS クライアントには表示されません。代わりに、NFS クライアントは、サーバー上のファイルのラベルに関係なく、タイプ
nfs_t としてラベル付けされたすべてのファイルを認識します。
Red Hat Enterprise Linux 7.3 以降、NFS サーバーは、各ファイルラベルをクライアントと通信できるようになりました。最近の Fedora クライアントなど、最近のクライアントは、それらのファイルがサーバー上に持っているものと同じラベルでラベル付けされた NFS ファイルを参照します。これは特定のケースで役立ちますが、サーバーを Red Hat Enterprise Linux 7.3 以降にアップグレードした後に、最近のクライアントで予期せぬアクセスパーミッションの問題が発生する可能性もあります。
ラベル付き NFS サポートは、NFS サーバーではデフォルトでオフになっていることに注意してください。
security_label エクスポートオプションを使用して、ラベル付き NFS サポートを再度有効にできます。(BZ#1406885)
autofs マウントがシャットダウン状態に達した後に無限ループにならなくなる
autofs マウントがシャットダウン状態に達し、マウント処理スレッドがシャットダウン通知を読み取る前にマウント要求が到着して処理された場合、マウント処理スレッドは以前は autofs マウントをクリーンアップせずに終了していました。その結果、autofs-managed マウントがマウントされたままになると、メインプログラムは終了条件に到達せず、無限ループに入りました。このバグを修正するために、リクエストを処理するたびに終了条件の確認が行われるようになり、autofs マウントがシャットダウン状態に達した場合にクリーンアップ操作が実行されるようになりました。その結果、autofs デーモンは、シャットダウン時に想定どおりに終了するようになりました。(BZ#1420584)
名前空間の処理時に autofs の信頼性が向上しました。
以前は、
autofs カーネルモジュールは、パスの最後のコンポーネントが現在の名前空間のマウントポイントであるかどうかを確認できず、どの名前空間でもマウントポイントであるかどうかしか確認できませんでした。このバグにより、autofs は、伝播プライベート名前空間にクローンされたマウントポイントがすでに存在しているかどうかを誤って判断することがありました。
その結果、自動マウントポイントのマウントに失敗し、エラーメッセージ
Too many levels of symbolic links が返されました。これは、たとえば、autofs マウントがアクティブなときに PrivateTmp オプションを使用する systemd サービスが再起動した場合などに発生しました。
今回の更新で、名前空間を認識したマウントチェックがカーネルに追加されました。その結果、
autofs は、autofs マウントを含むマウント名前空間が伝播プライベート名前空間にクローンされている場合に、より回復力があります。
詳細は、KBase の記事 https://access.redhat.com/articles/3104671 を参照してください。(BZ#1320588)
