長い間、共有ホスティングユーザーは自分のアカウントで何が起こっているのかを常に把握していないという問題を心配していました-誰もがftp経由でログインしたり、 cronジョブを完了したり、 sshを介したアクセスがあったり、メッセージが送信されたり、送信されたりしていました。 ほとんどのホスティング事業者（当社を含む）の場合、ユーザーはテクニカルサポートサービスに質問し、適切な権限と資格を持つ専門家が必要なログを選択するのを待つことができます。 ボーナスの問題-1つのコマンドを実行して、ユーザーに関連するログエントリを確認することはできません。 これにより、システム管理者にとって困難が生じます。
驚きをもたらすことは、最初から単純な作業のように思えます。
まず、すべてのプログラムがsyslogシステムで動作できるわけではないことが判明しました。 たとえば、 proftpdはメインログをsyslogに書き込むことができますが、そこでファイルを操作するログを書き込むことはできません。 ドキュメントには、この状況に対する「松葉杖」があります（ちなみに、動作していません）。これは、FIFOファイル（ proftpdが突然ジャーナルを書き込むことができる）をリッスンする別の「デーモン」を意味します。 しかし、結果として、ログエントリは奇妙であり、バックアップの量によって、 syslogdから実行されるフィルターを作成するという考えを放棄することにしました。
第二に、一部のプログラムでは、ログ行の非自明な分析で「追跡」システム（行を保存し、ユーザーが識別できる行が表示された場合にのみログに書き込む）を導入する必要があることが判明しました。 最も貧弱なロギングサーバーはOpenSSHです。 ユーザーがどのキーでログインしているかを理解するには、デバッグモードをオンにする必要があります。端末への接続は最も強力なデバッグモードでのみ書き込まれ（そして私は拒否しました）、トンネルは特別な方法で割り当てられません。 キーはジャーナル自体には書き込まれませんが、フィンガープリント（すぐに読んだ人のうち何人がsshキーのフィンガープリントを見ることができますか？）、バックアップを作成し、 authorized_keysからジャーナルにキーの開始と終了を書き込み、それを明確にしなければなりませんでした。 確立された接続には識別子がなく、プロセスのpidでそれらを覚えておく必要があります。ログインが成功した後、ログにはユーザー名がマークされず、どのpidがどのユーザーにサービスを提供するかを覚えておく必要があります。 「リーク」や誤った解釈を避けるために、プロセスを完了するためのすべての可能なオプションを注意深く監視する必要があります。 特に、ログのいくつかの行を誤って「失う」可能性があるため、「ガベージコレクター」を作成しました。 proftpdログには、接続の問題を追跡することも困難です。 一番奇妙なのはsendmailでした。 彼はすべての手紙にキューの番号を書き留め、ジャーナルに書き込みます。 必要に応じて、彼はどのシステムユーザーを扱っていたかを報告します。 同時に、 sendmailのジャーナル形式自体は少し頭を悩ます。
機能を明確にし、ログの読み取り方法を選択した後、「折りたたみベッド」を実装するプロセスも楽しかったです。
UNIXのイデオロギーに従って、既存のツールを使用することにしました。 私は伝統的に「折り畳み」自体をperlで書きました。タスクは雑誌を追跡することでした。 関心のある雑誌ごとに-fスイッチを使用してテールユーティリティを選択し、続いて読み取ったものを分析しました。 しかし、読み取ったログのローテーションをどうすればよいでしょうか？ そして、老後、私はキー-Fに目を開けました。 簡単にするために、ジャーナルごとにプロセスを実行することにしました...そしてプロセスのスケジューリングで「死亡」しました。 外部信号が到着すると、全員に信号を送信する必要があります。独自のハンドラーが必要であり、システムクラッシュを解決して再起動する必要があります。 そして、 tailが複数のファイルを一度に監視できることを思い出しました。 どのファイルがどの行に属しているかを判断するためのアルゴリズムを作成することは、取るに足らないことでした。 'tail'は、現在どのファイルから行を出力しているのかを書き込みますが、彼が書いた内容を記憶する追跡システムを作成する必要があります。 正午の後、FreeBSDのtailのシステム実装にエラーがあったことが判明しました;端末を操作しないときは、端末の前ではなく、そこから行を出力した後にファイル名を書き込みます。 最後に、Perlでファイルの継続的な読み取りを独自に実装し、ファイル名の変更を追跡しました。 自転車と標準ソリューションの問題について。 時にはあらゆる面で自転車がより有益です。
ユーザーログをローテーションする方法 残りの回転と同様に、システムユーティリティはこれを扱います。 ユーザーのログの行を受信すると、「折りたたみ」スクリプトは開いているファイルに含まれているかどうかを確認し、ない場合は開いて記憶します。 ユーザーログの名前を変更してローテーションした後、ログローテーションのシステムサービスは、従来のSIGHUPを「レイアウト」に送信します。 「折りたたみ」のこのシグナルのハンドラーは、開いている記述子のリストを単純に消去し、同時にそれらを閉じます。 したがって、データが到着すると、ファイルが再度開かれます。
結果は印象的でした。 ユーザーの行動には多くの興味深いことが判明しました。 ところで、良いユーティリティを飾る素敵なアドオンについて。 ログをユーザーのホームディレクトリに置くことに加えて、システム管理者向けに1か所でレコードのコピーを個別に作成しました。 関心のあるサービスについて、各ユーザーの現在の状況を一目で評価できます。 現在の評価ではアーカイブが必要ないため、ローテーション中に追加の場所にあるログは単に削除されます。
まとめ プログラムを書くとき、このプログラムのログを誰に書くかを考えてください。 ツールを選択するとき、それについて考えてください-しかし、これは間違いなくイデオロギーの選択ではありませんか？
PSシステムの開発に協力してくれたJuickの読者に深く感謝します。 あなたなしでは、タスクに対処しないすべてのチャンスがありました。
更新： github.com/schors/peruserlog