ドメイン上でカスタムマトリックスルームエイリアスを設定する方法
Matrixルームエイリアスの仕組み、ドメインとSynapseホームサーバーの準備、フェデレーション委任の設定、カスタムエイリアスの作成、そして安全な検証方法について学びましょう。
Zimbraサーバーの動作が急に遅くなった場合、管理者はCPU使用率の上位に「 ClamAVがCPUを使いすぎている」clamdという表示を見て、アンチウイルスサービスが停止していると考えることがよくあります。確かにそのようなことは起こり得ますが、この2つのプロセスは異なる処理を実行します。「ClamAVがCPUを使いすぎている」という表示は、実際には「ClamAVがCPUを使いすぎている」という表示に似ています。再起動やアンチウイルス設定を変更する前に、どのプロセスがCPUを消費しているかを特定してください。freshclamtopfreshclamclamd
このガイドでは、低リスクのチェックからサービス復旧までを順を追って説明します。以下のコマンドとパスは、一般的な Zimbra のインストール環境に基づいています。バンドルされている ClamAV の正確なパスとサポートされている復旧手順は、Zimbra Collaboration のバージョンによって異なります。変更を加える前に、インストールされているリリースに合わせて確認してください。
まず、プロセス名、CPU使用率、経過時間、コマンドパスを記録します。root権限、またはシステムプロセスを検査する権限を持つアカウントでこれを実行してください。
ps -eo pid,pcpu,pmem,etime,args | grep -E 'clamd|freshclam'
次に、疑わしいプロセスを少なくとも短時間監視します。 を最初のコマンドの数値にtop -p PID置き換えてください。 を一度の読み取りでは、持続的な問題を診断するには不十分です。はスナップショットを報告しますが、 はスキャンまたは更新が完了した後に CPU 使用率が高いままか低下するかを確認するのに役立ちます。また、 パスが Zimbra (通常は の下) に属するものか、別のオペレーティングシステム パッケージに属するものかにも注意してください。PIDpstop/opt/zimbra

freshclam更新が正常に完了した後、一時的に処理が急増して終了するかアイドル状態に戻る場合、それは処理が継続してビジー状態になるプロセスとは異なります。処理clamdが継続的に消費されている場合は、メッセージのスキャンやデータベースの読み込みが原因となっている可能性が高いです。サンプル値が高いという理由だけでどちらのプロセスも強制終了しないでください。まずログを確認し、メールがまだ流れているかどうかを確認してください。
Zimbraのログリファレンスには、アンチウイルスログがログディレクトリに一覧表示されます。多くのインストール環境では、以下のコマンドで最近のエントリを確認できます。
tail -n 80 /opt/zimbra/log/clamd.logtail -n 80 /opt/zimbra/log/freshclam.log
CPU スパイクと並行してタイムスタンプを確認してください。 の場合clamd.log、スキャン要求やデータベース読み込みメッセージが繰り返されると、CPU 使用率がメールアクティビティや署名の再読み込みと関連付けられる可能性があります。 の場合freshclam.log、更新が完了し、その後しばらく静かな状態が続くと、定期的な更新作業が示唆されます。接続失敗、再試行、チェックサムエラー、または更新が完了しない場合は、さらに詳しく調査する必要があります。受信メッセージや添付ファイルのトラフィックが急増するとスキャンが増加する可能性があるため、同時期に Zimbra メールログも確認してください。

Zimbraのログファイルリファレンスを使用して、ご使用のリリースにおけるログファイルの場所を確認してください。ClamAVのFreshClamトラブルシューティングガイドでは、DNS、ダウンロード、レート制限の問題など、一般的なアップデーターのエラーについて説明しています。エンジンがClamAVの最新のアップストリームリリースよりも古いという警告が表示されたとしても、それだけでデータベースが破損しているとは限りません。Zimbraは、テスト済みのエンジンをZCSリリースに同梱しています。
何かを調整する前に、サービスが混雑する一般的な原因を排除してください。
clamdか確認してくださいfreshclam。別途インストールされたOSレベルのClamAVサービス、またはカスタムcronジョブが、Zimbraの管理対象サービスと並行して2つ目のプロセスを起動している可能性があります。どの製品がサービスを所有し、何がそのサービスを起動しているかを確認するまでは、サービスを無効にしないでください。df -h /opt/zimbraとを使用して、空き容量と inode を確認してくださいdf -i /opt/zimbra。ファイルシステムがいっぱいになると、一時的な更新やログの書き込みが妨げられ、再試行が発生する可能性があります。空き容量を確保するために、署名ファイルを手動で削除しないでください。clamdサービスが正常に動作している場合でもCPU使用率が上昇する可能性があります。freshclam、ホストのDNS解決、時計、送信接続、および必要なプロキシ設定を確認してください。手動で更新ジョブを繰り返し実行するのではなく、根本的なネットワークまたはプロキシの問題を修正してください。
ClamAV は、設定マニュアルで FreshClam の設定がアップデートの動作とログ記録をどのように制御するかを説明しています。Zimbra もウイルス定義の更新頻度属性を説明していますが、その値と設定はご使用の ZCS バージョンに合わせて確認してください。CPU 負荷を一時的に軽減するために更新頻度を下げないでください。古いシグネチャは保護機能を弱め、DNS やプロキシのパスに問題がある場合は、スケジュールに関係なく引き続きエラーが発生します。
現在の処理に負荷をかけながら、CPUとメール配信状況を監視してください。同じパターンが繰り返される場合は、メッセージサイズ、圧縮添付ファイル、受信メール量との関連性を確認し、サーバー容量と組織の添付ファイルスキャンポリシーを見直してください。セキュリティへの影響を評価し、インストールされているリリースでZimbraがサポートする制御を確認することなく、ClamAVの制限を文書化せずに追加したり、ファイルの種類を除外したりすることは避けてください。
ログに示されているDNS、プロキシ、ファイアウォール、時計、またはアウトバウンドネットワークアクセスを修正してください。Zimbraが意図したアップデーターのみが実行されていることを確認してください。頻繁な手動呼び出しやアドホックスクリプトによる署名データベースのダウンロードはスケジュールしないでください。ClamAVはFreshClamまたはcvdupdateをサポート対象の更新方法として認識しており、Zimbraサーバーの更新元としてはZimbraのパッケージ化された統合機能を使用するべきです。
不正なデータベース、チェックサムエラー、データベースロードの失敗などのエラーが発生した場合は、バージョンを考慮した復旧が必要です。ZimbraのClamAV定義リセット手順は、 FreshClamバイナリパスの違いを含め、ZCSの世代ごとに異なる手順になっています。データベースファイルを移動または再構築する前に、使用するバージョンの手順全体を必ずお読みください。復旧が確認されるまで既存のデータベースのコピーを保持し、古いリリースガイドのコマンドを安易に適用しないでください。
パフォーマンス改善の第一手段として、ZimbraのClamAVバイナリをスタンドアロンのアップストリームビルドに置き換えないでください。Zimbraのドキュメントには、サイクル外のエンジン変更はサポートされない可能性があると警告されています。バンドルされているエンジン自体を更新する必要がある場合は、適切なZCSパッチまたはアップグレードパスを使用してください。
根本的な問題が解決した後もサービスが停止したままの場合は、制御されたウイルス対策再起動によって古いプロセスがクリアされたり、修復されたデータベースが再読み込みされたりする可能性があります。スキャンが一時的に中断しても問題ないタイミングで再起動をスケジュールし、ZCS リリースに応じたコマンドシーケンスに従ってください。Zimbra の手順書と を参照しzmantivirusctl stop、ユーザーzmantivirusctl startとして実行してくださいzimbra。
su - zimbrazmantivirusctl stopzmantivirusctl startzmcontrol status
メンテナンスプランで必須とされていない限り、ClamAVのみの問題に対してフルバックアップを使用しないでくださいzmcontrol stop。アンチウイルスサービスが復旧しない場合は、関連するログを保存し、再起動を繰り返すのではなく、Zimbraのリリース固有のトラブルシューティングまたはサポートチャネルを使用してください。

修正または再起動後、プロセスチェックを繰り返し、単一の瞬間値に頼るのではなく、CPU の傾向を監視してください。 がclamd存在し、freshclam繰り返しリトライで停止しておらず、zmcontrol statusアンチウイルスが実行中であることを確認してください。新しいログエントリを確認し、データベースの読み込みが成功していること、および更新またはスキャンエラーが繰り返し発生していないことを確認してください。最後に、通常のテストメッセージが配信され、組織のメールセキュリティポリシーに従って処理されていることを確認してください。
正常な復旧には、次の3つの兆候が見られます。原因となっているプロセスが処理完了後にCPUを継続的に消費しなくなること、ログに同じエラーが繰り返されなくなること、そしてZimbraのメールフローとウイルス対策サービスの状態が正常であること。CPU使用率が高いままの場合は、タイムスタンプ付きのプロセススナップショット、対応するclamd.logメールfreshclam.logログエントリ、ディスク容量の結果、およびZCSのバージョンを収集してください。これらの証拠は、マルウェアスキャンを推測の域を出ないものにすることなく、実際のスキャナの不具合と大量のメール、または更新パスの破損を区別するのに役立ちます。
バージョンに関する注記:ガイダンスは2026年10月6日に確認されました。Zimbraのテクニカルセンターには、最新のリファレンスと、以前のリリース固有のトラブルシューティングページの両方が含まれています。インストールされているZCSリリースのドキュメントと照らし合わせて、コマンドとパスを確認してください。
Matrixルームエイリアスの仕組み、ドメインとSynapseホームサーバーの準備、フェデレーション委任の設定、カスタムエイリアスの作成、そして安全な検証方法について学びましょう。
ownCloud Serverの管理者が、共有、バージョン、検証を考慮しながら、occを使用して選択したフォルダまたはすべてのファイルを別のユーザーに転送する方法を学びましょう。
Nextcloudのコード整合性警告の診断方法、変更または欠落したコアファイルの復元方法、余分なファイルやアプリ署名エラーの処理方法、そして修復が安全に行われたことを確認する方法を学びましょう。
Nextcloud Desktopが「ファイルの処理中」のまま止まってしまいますか?データにリスクを与えることなく、ブロックしているファイル、同期設定、ネットワーク、ログ、および安全なリセットオプションを診断します。
occコマンドを使用して、紛失したNextcloud管理者パスワードをコマンドラインからリセットします。正しいインストールパスを見つけて、安全にリセットを実行し、アクセスを確認してください。
Jitsi Meet 用に Docker Compose を使用して Jibri をセットアップします。録画の設定、ストレージ権限の保護、サービスの起動、録画と RTMP ストリームのテストを行います。
ownCloud Serverの有効期限切れコマンドと完全削除コマンドを比較し、Infinite Scaleの個別のリビジョンワークフローと、クリーンアップを安全に検証する方法を学びましょう。
Jitsi Meet の設定で、承認された認証済みユーザーのみがルームを開始できるようにし、許可すればゲストも参加できるようにします。Docker の手順と最新の認証ガイダンスが含まれています。
ownCloudのWebDAV警告のトラブルシューティングを行うには、DAVルート、Apacheのリライト、リバースプロキシ、DNS、TLS、およびサーバー側の接続性を確認してください。
ZimbraでCPU使用率が高い原因がclamdかfreshclamのどちらであるかを特定し、適切なログを検査し、一般的な原因を安全に修正し、ウイルス対策サービスの復旧を確認します。