SeafileとCollaboraを正しいWOPI URLに接続します。
Seafileで安全なドキュメント編集を有効にするには、デプロイメント用にCollaboraの検出URL、HTTPS、およびWOPIアクセスを設定してください。
Collabora Online Development Edition (CODE) がスケジュールされたバージョンチェックを実行しないようにするには、fetch_update_checkを に0、allow_update_popupを に設定しますfalse。承認されていない外部サービスに接続してはならないデプロイメントの場合は、使用されていない統合を無効にし、ネットワーク境界で送信許可リストを適用してください。更新通知を非表示にするだけでは、ネットワークトラフィックはブロックされません。
2026年10月現在、Collaboraの保守coolwsd.xml.in文書には、更新チェック間隔が10時間と記載されており、更新通知用の個別の制御機能も用意されています。しかし、「テレメトリを無効にする」というラベルの付いた単一の共通スイッチは記載されていません。更新要求、オプションのクラウド支援編集、ローカル診断ログ、そして文書保存サーバーへの必須のWOPI接続は、それぞれ異なるものです。これらを単一の設定として扱うと、接続が維持されたままになったり、文書編集が中断されたりする可能性があります。
これらの手順は主にスタンドアロンのcollabora/codeDockerデプロイメントに適用されます。パッケージインストールでも同じ構成概念を使用しますが、通常はサービスを編集し/etc/coolwsd/coolwsd.xmlて再起動しますcoolwsd。別の製品によって管理される組み込みのCODEインストールでは、起動オプションが再生成される場合があります。その場合は、一時ファイルをパッチするのではなく、管理製品で設定を変更してください。
まず、CODEサービスがDocker Compose、docker runコマンド、またはネイティブパッケージのいずれによって構成されているかを確認します。Dockerの場合は、環境変数に認証情報が含まれる可能性があるため、出力を公開せずにコンテナとその現在の環境を調べます。
docker ps --format 'table {{.Names}} {{.Image}}'
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' code
実際のコンテナ名に置き換えてくださいcode。変更する前に、デプロイメントファイルまたは既存のファイルの安全なコピーを保存してくださいcoolwsd.xml。Compose の設定に TLS 終端、WOPI ホスト許可、または認証パラメータが既に含まれている場合は、それらの値を保持してください。
extra_paramsこれらのオプションを、CODEサービスのブロック内の既存の値に追加してくださいenvironment。これは断片であり、Composeファイルの完全な置き換えではありません。
services:
code:
environment:
extra_params: >-
--o:fetch_update_check=0
--o:allow_update_popup=false
2 つのフラグを既存のフラグとマージし、上書きしないでください。次に、実際の Compose サービス名を使用してextra_paramsCODE サービスのみを再作成します。デプロイメントでは、コンテナを再作成する際に、環境変数に同じオプションを含めてください。docker compose up -d --no-deps --force-recreate codedocker runextra_params
編集/etc/coolwsd/coolwsd.xml:既存の要素を見つけて、元の属性を保持したまま値を変更します。
<fetch_update_check>0</fetch_update_check>
<allow_update_popup>false</allow_update_popup>
既存の要素に属性が含まれている場合は、属性を保持し、テキスト値のみを変更します。再起動する前に、ファイルが有効な XML であることを確認してください。たとえば、がインストールされているxmllint --noout /etc/coolwsd/coolwsd.xml場合はを使用しますxmllint。 を使用して再起動しますsudo systemctl restart coolwsd。
重要: allow_update_popup=falseこの設定はエディターの更新通知を抑制するものであり、それ自体が送信制御ではありません。このfetch_update_check=0設定はスケジュールされたチェックに関するものです。組織は引き続き、通常のメンテナンスプロセスを通じてセキュリティ更新プログラムを追跡する必要があります。
リモート統合の有効な設定を確認してください。現在のアップストリーム設定では、リモートのLanguageToolまたはDuden校正はデフォルトで無効になっており、サーバー全体のAIおよびDeepLスイッチもデフォルトで無効になっていることがドキュメントに記載されています。管理者または統合によって有効になっている可能性があります。インストールされているCODEバージョンにこれらのオプションが存在する場合は、必要でない限り無効のままにしてください。
--o:languagetool.enabled=false
--o:ai.enabled=false
--o:deepl.enabled=false
インストールされているバージョンでサポートされているオプションのみを含め、競合する2つ目の値を設定するのではなく、それらを統合してください。同様の効果は、ネイティブXMLインストールの対応する、、およびセクションextra_paramsで設定できます。<languagetool><ai><deepl>
remote_config.remote_url削除する前に、必ず確認してくださいremote_font_config.url。空のリモート構成 URL は、オプションの構成取得を回避します。リモートフォント URL は、正当な理由により、ご自身の Nextcloud インストールを指している可能性があります。これを削除するとドキュメントのタイポグラフィに影響が出る可能性があるため、フォント サービスが承認され、必要な場合は残しておいてください。また、デプロイメントのニーズに応じて、設定されている監視 WebSocket アドレスや引用マネージャーなどの追加プラグインも確認してください。
ログ記録はプライバシーとは別の問題であり、外部テレメトリの証拠ではありません。診断情報におけるローカル識別子を制限したい場合はlogging.docstats、、、logging.userstatsおよびを確認logging.anonymize.anonymize_user_dataしてください。インシデントのトラブルシューティングに必要なセキュリティおよび運用ログは保持してください。ログの詳細度を変更しても、送信ソケットはブロックされません。
設定変更だけでは、予期しないアウトバウンド接続を完全にゼロにすることはできません。CODEを、デプロイメントに必要な特定の宛先とポートを許可するファイアウォールまたはエグレスプロキシの背後に配置してください。通常、これは承認済みのWOPIストレージホスト、実際に使用する内部フォントまたはIDサービス、および内部DNSなどの必要なインフラストラクチャを意味します。承認されていない更新エンドポイントを含む、その他のインターネット宛先をCODEワークロードからブロックしてください。
ネットワークをむやみに無効にしたり、Dockerネットワークを「:」に設定したりしないでくださいinternal: true。アーキテクチャによっては、CODEがWOPIサーバーに接続できなくなったり、必要な統合機能が動作しなくなる可能性があります。また、ユーザーのブラウザはエディタのリソースを読み込み、CODEサーバーとは独立してリクエストを行う場合があることに注意してください。サーバーのファイアウォールルールはブラウザには適用されません。
iptablesバックエンドを使用するDocker Engineのインストールでは、DockerはDOCKER-USER管理者転送ルールを設定する場所としてチェーンを推奨しています。nftablesバックエンドを使用する場合は、既存のチェーンがDOCKER-USER存在すると想定するのではなく、別途ベースチェーンを実装してください。実際のブリッジまたはコンテナネットワーク、IPv4およびIPv6、DNS、接続状態、正当なWOPIトラフィックに対してルールを設計してください。汎用的なルールを貼り付けると、オフラインでの編集が困難になる可能性があります。ポリシーを適用する前に、 DockerのiptablesガイダンスとnftablesガイダンスDROPを参照してください。
再起動またはコンテナの再作成後、起動ログを調べて構成エラーがないか確認し、通常のストレージ統合機能を使用してドキュメントの開き方、編集方法、保存方法をテストしてください。エディタが応答するだけでは、承認されていないリクエストがすべて停止したとは言えません。実行中の起動パラメータを確認し、起動時およびドキュメント編集時にファイアウォール、エグレスプロキシ、またはコンテナネットワークからのDNSログとアウトバウンド接続ログを確認してください。
docker logs --since 10m code
# Check configured flags without exposing unrelated environment secrets:
docker inspect --format '{{range .Config.Env}}{{println .}}{{end}}' code | grep '^extra_params='
ネイティブインストールの場合、sudo journalctl -u coolwsd --since '10 minutes ago'ローカルのXMLを使用して検査してください。ブラウザ側では、ブラウザの開発者ツールを開き、ドキュメントを開きながらネットワークタブを確認してください。CODEおよびWOPIホストへのリクエストと、サードパーティの宛先へのリクエストを区別してください。
成功基準: CODEがドキュメントを正常にロードおよび保存すること。更新チェックオプションがゼロに設定されていること。オプションのクラウド統合は、明示的に承認されない限り無効のままであること。ネットワーク監視で、監視期間中に許可された宛先のみが表示されること。トラフィックをフィルタリングした後でドキュメントのロードが失敗した場合は、TLS証明書の検証を無効にしたり、無制限の送信を許可したりするのではなく、一時的に拒否された宛先を承認済みのWOPIおよびインフラストラクチャリストと照合してください。
主な参考資料: Collaboraが管理するサーバー構成テンプレート、Nextcloud All-in-One CODEコンテナ構成、および公式CODE Dockerイメージの説明。これらは関連する設定とデプロイパターンを文書化したものであり、お客様固有のインストール環境におけるネットワーク監査に代わるものではありません。
Seafileで安全なドキュメント編集を有効にするには、デプロイメント用にCollaboraの検出URL、HTTPS、およびWOPIアクセスを設定してください。
システムクリップボードをテストし、ブラウザの権限を調整し、埋め込み型Collabora統合においてiframeポリシーの変更が必要なタイミングを特定します。
フォントファイルをDockerとCollaboraのシステムプレートにマウントすることで、カスタムフォントがエディタに表示され、ドキュメント内で正しくレンダリングされるようになります。
coolwsd.xmlとそのデプロイメントソースをバックアップし、安全に復元してから、ユーザーが編集を再開する前にCODEを検証してください。
CODE内でNextcloudまたはその他のWOPIオリジンを正確に許可し、アクティブなホスト許可リストを確認して、Nextcloudの送信元IP制限と区別します。
Collaboraのブラウザ、WOPI、およびWebSocket接続をトレースして、ドキュメントが開かない理由を特定し、Nextcloudの設定に合った修正を適用してください。
Helmを使用してCollabora CODEレプリカをデプロイし、WOPIアフィニティによって各ドキュメントを1つのポッドに保持し、イングレス、ノード配置、およびNextcloud編集を検証します。
ブラウザからcoolwsdまでのソケットハンドシェイクの失敗を追跡し、CODE 26.04 Apacheの変更を含め、リバースプロキシのルートをCollaboraのバージョンに一致させます。
Collabora WOPI 認証の失敗を、鍵の不一致、古い検出データ、クロックのずれ、プロキシ URL の変更などが原因で発生する場合でも、検証の信頼性を損なうことなく追跡できます。
ブラウザのズームをリセットし、クリーンなセッションをテストし、サイズが不正なメニューにCollaboraサーバーのアップデートが必要なタイミングを特定します。