クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する
Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。
Zimbra Web Clientで「アカウントがロックされています」というメッセージが表示された場合は、パスワードの再入力を中止してください。繰り返し試行するとアカウントがロックされたままになる可能性があり、古い電話アプリやメールアプリがバックグラウンドで古いパスワードを送信している場合もあります。適切な対処法は、一時的なパスワードロックアウトなのか、管理者によるアカウントロックなのか、あるいは別のアカウント状態なのかによって異なります。
ユーザーは設定されたロックアウト期間が経過するまで待ってから、正しいパスワードを一度試すことができます。Zimbra 管理者は、アカウントの状態を確認し、検証済みのユーザーのロックを解除できますzmprov。まず、ログイン失敗の原因を確認し、同じデバイスまたはスクリプトがアカウントを再度ロックしないようにしてください。
Zimbra は、設定された回数の連続パスワード入力失敗後に、一時的にサインインをブロックできます。管理者は、アカウントのステータスを に設定して、locked意図的にサインインをブロックすることもできます。これらの条件は関連していますが、同一ではありません。認証ロックアウトは通常、アカウントのステータス で表されますlockoutが、管理者が設定したステータスは と表示される場合がありますlocked。ユーザーに表示される正確な文言は、Zimbra のバージョンとログインパスによって異なる場合があるため、アカウントのステータスを変更する前に確認してください。
ログインがブロックされている間も、メールの配信は継続される場合があります。アカウントがロックされたこと自体は、アカウントが侵害されたことを証明するものではありませんが、未知のデバイスまたはIPアドレスからのアクセス試行が繰り返される場合は、アクセスを復元する前に調査する必要があります。
Zimbra のテクニカル センターのトラブルシューティング ノートによると、ロックアウト期間が経過した後、正しいログインを行うことで、ロック状態が表示されているアカウントを再アクティブ化できるとのことです。また、ログイン前にステータスが自動的に変更されない場合があることも記載されています。このノートは作業中であるため、すべての展開で保証されるものではなく、インストールされている Zimbra リリースとローカル認証設定に対して検証するためのドキュメント化された動作として扱ってください。Zimbraのロックアウト期間に関するトラブルシューティング ノートを参照してください。
特権アカウントを使用して、Zimbraサーバー上で管理コマンドを実行してください。多くのインストール環境では、管理者はまずZimbraシステムユーザーに切り替えます。以下のサンプルアドレスを完全なメールボックスアドレスに置き換えてください。また、パスワードや機密性の高い出力を公開サポートスレッドに貼り付けないでください。
su - zimbra
zmprov ga user@example.com zimbraAccountStatus

処理を実行する前に、返された値を解釈してください。
lockoutログインロックアウトが発生していることを示します。解除する前に、ユーザー名、待機時間、および最近のログイン失敗の原因を確認してください。locked管理者が意図的にサインインをブロックした可能性があります。まずはアカウント所有者とロックの理由を確認してください。closed、、maintenanceまたは別の値は、異なる管理状態を示しています。activeなぜその値が設定されたのかを理解せずに、に変更しないでください。Zimbraではzmprov ga、アカウント情報を取得するためのコマンドとzmprov maアカウントを変更するためのコマンドとして、zmprovコマンドがドキュメントに記載されています。Zimbraのzmprovコマンドリファレンスを参照してください。
アカウントが認証済みで、ユーザーが承認されており、ロックがセキュリティ対策として設定されたものでない場合は、アカウントの状態をアクティブに戻します。
zmprov ma user@example.com zimbraAccountStatus active
zmprov ga user@example.com zimbraAccountStatus

1つのアカウントのアドレスのみを使用してください。個々のログイン失敗を解決するために、すべてのメールボックスに対して一括ロック解除を実行しないでください。アカウントをアクティブに設定するとサインイン資格は回復しますが、依然として間違っているパスワードを修正したり、クライアントが古い認証情報を送信するのを阻止したりするものではありません。
ロック解除後にユーザーがサインインできない場合は、組織で承認されたIDプロセスを通じてパスワードを確認してください。Zimbra管理者は、新しいパスワードを設定できますzmprov sp user@example.com <new-password>が、これはZimbraパスワードストアに適用されます。LDAP、Active Directory、またはシングルサインオンプロバイダーを介して認証を行うデプロイメントでは、代わりにその外部IDシステムでパスワードのリセットまたはロック解除が必要になる場合があります。Zimbraは、zmprov sp管理者向けガイダンスでパスワードリセットコマンドについて説明しています。Zimbraのパスワードリセット手順を確認してください。
アクセスを復元した後、不正な認証情報を送信し続けているソースがないか確認してください。一般的な原因としては、古いパスワードが保存されているスマートフォン、デスクトップメールクライアント、タブレット、認証付きSMTPを使用するプリンターまたはスキャナー、スケジュールされたスクリプト、または更新されていないアプリケーションなどが挙げられます。ユーザーに、メールボックス用に設定されているデバイスとアプリを確認し、再度サインインテストを行う前に、それらを更新するか一時的に切断してください。
ロックアウトが発生した時間帯のメールボックスログを確認してください。Zimbra はログイン失敗時の保護メッセージを に記録します/opt/zimbra/log/mailbox.log。ログの形式と詳細は、リリースや展開によって異なる場合があります。
grep -Ei 'failed login|invalid credentials|suspended' /opt/zimbra/log/mailbox.log | tail -n 50

繰り返し発生するエラーに関連するタイムスタンプと送信元アドレスを探してください。それらをユーザーのデバイスとネットワーク記録と照合してください。見慣れたIPアドレスでも、古いメールクライアントが原因である可能性があります。見慣れない送信元や、ユーザーがログインを停止した後も試行が続く場合は、セキュリティレビューを実施する必要があります。組織の保持ポリシーに従って、関連するログエントリを保存してください。
Zimbraのトラブルシューティング資料には、ログイン失敗が繰り返されたためにIPアドレスが停止されたことを示すメールボックスログメッセージの例が記載されています。ログイン失敗が繰り返された場合のZimbraのログ例を参照してください。
しきい値を変更する前に、有効なアカウントまたはサービスレベルの設定を確認してください。Zimbraのロックアウト属性には、ロックアウトが有効になっているかどうか、ロックアウト期間、連続失敗の最大回数、および失敗がカウントされる期間が含まれます。適用可能な値はアカウントとそのサービスレベルによって異なり、Zimbraのリリースによっても異なる場合があります。サンプル値が普遍的なデフォルト値であると想定するのではなく、インストールされているバージョンに合ったドキュメントを参照してください。
zmprov ga user@example.com zimbraPasswordLockoutEnabled zimbraPasswordLockoutDuration zimbraPasswordLockoutMaxFailures zimbraPasswordLockoutFailureLifetime

設定がサービスクラス(COS)から継承されている場合は、そのCOSも確認してください。たとえば、zmprov gc defaultアカウントが実際にそのdefaultCOSに属している場合にのみ使用してください。メッセージを消すためだけに、ロックアウトを無効にしたり、失敗しきい値を上げたりしないでください。まず、古い認証情報を解決し、次に、ユーザーアクセスとパスワード推測に対する保護のバランスが取れたポリシー値を選択してください。ポリシーの変更は、承認された小規模な範囲でテストし、ロールバックのために以前の値を文書化してください。
影響を受けたアカウントが管理者である場合は、最初の対応として手動でディレクトリを編集することは避けてください。アカウントが Zimbra で管理されている管理者アカウントか、外部ディレクトリ経由で認証されているアカウントかを確認してください。別の承認済み管理者アカウントを使用するか、組織の文書化された復旧手順に従ってください。Zimbra は管理者パスワードの復旧に関する別のガイダンスを提供しており、外部 LDAP または Active Directory 認証によって復旧パスが変わることを指摘しています。Zimbraの管理者アカウント復旧ガイダンスを確認してください。
有効な管理者アカウントが利用できない場合は、ZimbraサービスプロバイダーまたはLDAPディレクトリを担当するチームに連絡してください。フォーラムから検証されていないLDAP変更手順をコピーすることは避けてください。誤ったバインドIDやディレクトリの変更は、単一のメールボックスだけでなく、他のメールボックスにも影響を与える可能性があります。
アカウントの状態と認証情報の誤りの原因を修正した後、アカウントの状態を再度確認し、ユーザーに通常のWebクライアントから一度サインインしてもらい、その時点で新たなログイン失敗イベントが発生しないことを確認します。メールアプリに保存されているパスワードは、パスワードが確認された後にのみ更新してください。状態が に戻った場合はlockout、次の失敗タイムスタンプをログと照合し、残りのクライアントを特定してから再度ロックを解除してください。
修正が有効な状態とは、ユーザーがサインインでき、アカウントがアクティブなままで、認証失敗が繰り返されなくなった状態を指します。アカウントがアクティブな状態でも認証できない場合は、パスワード、外部IDプロバイダー、アカウントポリシー、およびサービスの状態をそれぞれ原因として調査してください。メールボックスのロックを繰り返し解除しても、これらの問題は解決しません。
Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。
Jitsi Videobridgeに内蔵されたPrometheusエンドポイントを使用して、Jitsi Videobridgeの状態、会議の負荷、トラフィックを追跡し、Grafanaでデータを探索およびグラフ化できます。
Jitsi Meet Docker 用のカスタムドメインを、DNS、PUBLIC_URL、HTTPS、Let's Encrypt、ファイアウォールポート、NAT 設定、エンドツーエンド検証とともに構成します。
SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。
アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。
MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。
セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。
UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。
Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。
Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザー クレームをマッピングし、ログアウトをテストします。