皆さんが目にしていることに基づいて、サーバーシステムでの/ tmpの推奨構成とその理由を説明します。私はこれらの点について何年にもわたって基本的な意見の不一致について話し合ってきました。
以下は基本的に私が見る質問です。これらの質問にはいくつかの質問をすることを提案する人もいるかもしれませんが、この情報が1つの見出しの下にあると、管理者にとっては簡単になると思います。これは参考になると確信しています。
特に/ tmpの場合:
Ln -s/var/tmp/tmpにする必要がありますか?
/ tmpは再起動間で保持する必要がありますか?
/ tmpは実際のディスク領域にあるべきですか、それとも基本的にSWAP領域(またはtmpfs)に実装できるようにするべきですか?
/ tmpは/(ルート)ディスクとは別のディスクに配置する必要がありますか?
/ tmpを/(ルート)ディスクとは別のディスクコントローラーに配置しますか?
/ tmpのサイズに関する経験則はありますか?
システムが稼働している間、/ tmpスペースをどのように管理しますか? >特定の年齢のすべてのファイルを削除しますか?最大の%ageに達するまで領域をそのままにしますか?
この地域を統治するための手続き上の項目を実施する必要がありますか?
特に/ tmpの場合:
完全なメモリ内ディスクイメージ(「ライブブートCD」と考えてください)の場合、RAMのすべてのバイトを圧縮する必要があるため、これは許容できる場合があります。それ以外の場合は、ディスク容量を強く求められない限り、いいえ。/varには独自の特性があり、/ tmpを/ var/tmpと混合すると、システムのメンテナンスを実行するときに意図しない結果が生じる可能性があります。また、/ var/tmpが正しく機能するためには/ tmpをマウントする必要があるという点で、追加の依存関係が追加されます。すべてが/ tmpを必要とするわけではなく、別のパーティションまたはドライブに移行したいが、/ varをアンマウントしたくないため、移行できない場合があります。
いいえ。一貫した動作としてこれに依存している場合は、遅かれ早かれ問題が発生します。
頻繁に使用する場合、これは誘惑です。「/ tmpをRAMディスクに挿入すると、アクセスが高速化され、システムが再起動/シャットダウンしても、クリーンアップするものは何もありません」 。ただし、一時スペースをスワップされるRAMディスクとして実装することを検討している場合は、他のプログラムによるシステムのスワップスペース使用量の影響を検討します。システムが悲惨な状況にあり、それを必要とする場合の「緊急オーバーフロー」の形式としてスワップが存在する場合、最後に必要なのは、/ tmpを埋める暴走プロセスによってスワップスペースが消費され、メモリが消費され、 VMサブシステムをディスクにスワップします。スワップアクティビティと、RAMディスクへの追加のI/Oストリーミング(これにより、追加のページインがseek()を満たす可能性があります)の間に、システムはすぐにI/Oバウンドになります。
できればそうですが、必須ではありません。それを多用する場合、またはそれを必要とする一定のワークロードがある場合は、間違いなくそうです。架空の例:一時ファイルを/ tmpにダンプするデータベースは、/ tmpを別のスピンドル(つまりドライブ)に導入することでわずかに高速化されます。
回復可能性または速度の要件がある場合は、それを検討する必要があります。
予想されるワークロードの2倍に対応する必要があります。これは、ローカルユーザーがこのスペースを定期的に使用している場合、遅かれ早かれ誰かが愚かなことをしてそれを埋めようとすることを意味します。わずかな超過があると、一時ファイルが残りのスペースを埋めたために停止するプログラムの奇妙な「問題」を回避できます。
これが「共通サービス」インストールであり、サーバーが1つ以上のネットワークサービスを提供しているが、ユーザーをホストしていない場合、これはおそらくローサイドになります。これがマルチユーザーインストールの場合、これはハイサイドになります(はい、 実際のユーザーをホストする場所はまだあります ネットワークサービスだけではありません)。
tmpwatch コマンドを調べてください。これは、質問のこの部分にうまく適合していることがわかると思います。このコマンドは、特定の経過時間(時間単位)を過ぎたファイルを削除するだけです。いっぱいになる速さに応じて、30日、45日、90日などを行うことができます。
私は次のことをお勧めします:
残りはあなたの特定のニーズの問題です。
非常に多くのことは、使用している特定のアプリケーションの負荷によって異なります。一部のアプリケーションサーバー(SunONE、古いnetscapeのもの)は、数百から数千のファイルを/ tmpに書き込みます。そのような状況では、マウントされたRAMディスクにしたくないので、再起動の間に保持する理由はありません。
サーバーは一般的ではなくなり、より特別な目的になりつつあります。このタイプの質問(および同様の「システムをパーティション分割する方法」の質問)は、実際にはロードアウトによって異なります。
私は最近、4年かそこら後に初めて再起動された1台のサーバーを持っていました-それは/ tmp内のすべてのファイルを削除するブートの途中で立ち往生しました-そこには非常に多くのがらくたがあり、それをクリーンアップするのにかなりの時間がかかりました。ボックスが頻繁に再起動しない場合は、定期的にクリーニングすることをお勧めします。
経験から、/ var/tmpディレクトリと/ tmpディレクトリを混在させないことをお勧めします。
/ varである理由は、(うまくいけば)すべてのログ、キャッシュ、およびサービスデータ(データベースなど)が存在する場所です。通常、/ varを別のパーティションに配置することをお勧めします。これにより、重要なデータイベント(大量のログ記録やデータベース書き込みなど)が発生した場合でも、ルートパーティションと/ tmpパーティションには確実に動作するための空き領域があります。
たとえば、私は文字通り、この慣行に従わなかった(つまり、すべてが1つのパーティションにあった)サイトから戻ってきたところです。ログが蓄積された結果、システム全体がひざまずきました。正常なパーティションレイアウトに従っている場合、/ varパーティションのスペースが不足していましたが、サーバーは応答性を維持していました。
私が検討する1つの項目は、最後の質問を参照して、/ tmp noexec、nosuidを作成することです。つまり、実行可能ファイルを/ tmpから実行することはできず、suidバイナリはユーザーIDを切り替えることができません。ただし、これは一部のプログラムに影響を与える可能性があるため、完全に信頼する前にテストしてください。sshもその1つだったと思いますが、忘れています。
これは、/ tmpに関するセキュリティを向上させるセキュリティ対策です。
もう1つのこと:多くのユーザーは/ tmpを永続的な一時ストレージとして使用しようとします。/tmpの強制的なクリーンアップはユーザーの教育と一緒に行う必要があります。/tmpは一時であり、そこに置かれたものはいつでも消えることがあります。
/ tmpは実際のディスク領域にあるべきですか、それとも基本的にSWAP領域(またはtmpfs)に実装できるようにするべきですか?
この状況で/ tmpがいっぱいになるとどうなるか考えましたか?それはあなたが二度するようなことではありません。私は一度それをしました(Solarisでは/ tmpは利用可能なすべてのRAMとスワップを使い果たします)、そしてそれはサーバーをひざまずかせました。
いくつかの点に答えるだけです...
通常の操作中に/ roをマウントできるように、/ tmpを/とは異なるパーティションに配置します。別のディスク?これは、/ tmpと/ getの使用量と、それらがお互いの邪魔になるかどうかによって異なります。
パート1と2に関しては、私のボックス(Mac OS X)では/ var/tmpは毎日クリーンアップされませんが、/ tmpはクリーンアップされるため、ポリシーが異なるため、一緒にシンボリックリンクしないでください。/var/tmpを毎日クリーニングしても何も壊れないかどうかはわかりませんが、声が大きくなる前に調査したいと思います。現時点では172kしかありません。