アップグレード後にownCloudの整合性警告をクリアする

ownCloud のアップグレード後に「整合性チェックに失敗しました」と表示された場合は、まず管理者警告を開き、無効なファイル レポートを確認してください。ファイルを編集したりsignature.json、チェックを無効にしたり、アップグレードを無作為に再実行したりしないでください。レポートには、問題の原因がコア ファイルの不一致、ファイルの欠落または過剰、あるいはアプリの署名の問題のいずれであるかが示されています。影響を受けるコードのみを正確な公式リリースから復元するか、互換性のある署名済みアプリをインストールしてから、再スキャンしてください。この方法は ownCloud Server (Classic) に適用されます。Infinite Scale は異なるアーキテクチャを使用しており、この PHPocc整合性ワークフローは使用しません。

例えば、10.x のポイントリリース間でアップグレードを行った際に、特定のファイルが削除されindex.php、エラーversion.phpとしてフラグが立てられた場合INVALID_HASH、原因としては、コアファイルの一部が別のリリースに属しているか、変更されていることが考えられます。手動でインストールしたアプリのみが署名データの欠落でフラグが立てられた場合、コアファイルを置き換えても解決しません。どの修正方法が適切かは、エラーの詳細によって判断されます。

ファイルを変更する前にレポートを読んでください

管理者としてサインインし、黄色のコード整合性警告を開いて、無効なファイルの一覧を表示するリンクを選択します。ownCloud 10.16 のドキュメントには、このレポートと管理ページの再スキャンオプションについて記載されています。Web ページにアクセスできない場合は、ownCloud インストールディレクトリから Web サーバーユーザーとしてチェックを実行してください。

sudo -u www-data ./occ integrity:check-core
sudo -u www-data ./occ integrity:check-app <appid>

www-dataウェブサーバーで使用しているアカウントに置き換え、<appid>レポートに表示されているアプリIDに置き換えてください。Dockerでは、occデプロイメントの通常の方法を使用してownCloudコンテナ内で同じコマンドを実行します。これらのコマンドはコアファイルと指定されたアプリを検査します。ownCloudのマニュアルには、すべてのアプリをスキャンする単一の手動コマンドはないと記載されています。

エラーの種類に応じて、次のアクションを選択してください。

  • INVALID_HASHファイルの署名がハッシュ値と異なっています。これは、部分的なバージョンアップグレード、混合バージョンのアップグレード、ローカルでの編集、または予期しない変更が原因である可能性があります。ファイルを置き換える前に、公式リリース版と完全に比較してください。
  • FILE_MISSING署名付きファイルが存在しません。対応するリリースパッケージから復元してください。まず、デプロイメント、パッケージング、または権限によってファイルが省略されていないことを確認してください。
  • EXTRA_FILE署名済みディレクトリ内にファイルが存在するが、その署名に含まれていない。これは古いバージョンの残骸か、ローカルで追加されたファイルである可能性がある。削除する前に、ファイルの所有者と目的を確認してください。
  • EXCEPTION署名データが存在しない、無効である、範囲外である、または失効した証明書に関連付けられている可能性があります。アプリの場合は、ソースコードとリリース状況を確認し、互換性のある署名済みビルドをメンテナーに問い合わせてください。

手動でインストールしたサードパーティ製アプリが署名されていない場合、警告が表示されるのは当然です。ownCloudのドキュメントにも、マーケットプレイス以外でインストールされた署名なしアプリは警告が表示される可能性があると記載されています。しかし、これは無効なコアハッシュの原因を説明するものではありません。診断中は、アプリとコアの結果を分けて保管してください。

対応するリリースからのコアの不一致を修復します

  1. 復旧可能なバックアップを作成してください。サーバーファイルを置き換える前に、展開環境のバックアップ手順に従って、データベース、構成、およびデータを保存してください。アップグレードが完了していない場合、またはサービスが不安定な場合は、メンテナンスモードを有効にして、修復前にWebトラフィックを停止してください。ファイルコピーをデータベースバックアップの代わりとして使用しないでください。
  2. ownCloudが実際に実行されているバージョンを確認してください。管理画面の概要とディスク上のバージョン情報を確認してください。アップグレードプロセスが完了し、すべてのクラスタノードまたはコンテナが同じターゲットリリースを実行していることを確認してください。アップグレードログを確認し、抽出の中断、権限エラー、または途中で停止したコマンドがないか確認してください。
  3. 該当バージョンの公式アーカイブを入手してください。インスタンスが以前のポイントリリースを使用している場合は、「最新」アーカイブを使用しないでください。アーカイブを別の一時ディレクトリに展開し、フラグが付けられたパスのみを比較してください。ディストリビューションまたはデプロイメントツールによってファイルがカスタマイズされている場合は、置き換える前にそのカスタマイズ内容を理解してください。
  4. 影響を受けるコアファイルは慎重に置き換えてください。確認済みのコアファイルについては、インスタンスの設定、データ、および互換性のあるアプリケーションディレクトリを保持したまま、対応するアーカイブから公式バージョンをコピーしてください。アップグレード手順に従わずに、新しいサーバーアーカイブを古いツリーに上書きすることは避けてください。以前のリリースからの残存ファイル自体がEXTRA_FILE問題を引き起こす可能性があります。インストールに関するドキュメントに記載されている方法を使用して、通常の所有権と権限を復元してください。
  5. 該当するチェックを再度実行してください。integrity:check-core主要な検出結果や特定のアプリに対して使用できますintegrity:check-app <appid>。管理ページの再スキャン機能も利用できます。手動で編集したり削除したりしないでくださいsignature.json。これは検証者が必要とする署名データです。

ownCloudのコード署名に関するガイダンスでは、リリースアーカイブから正しいファイルを復元したり、不要な余分なファイルを削除したり、公式サーバーのtarballから欠落しているファイルを復元したりといった例が示されていindex.phpますversion.php。.htaccessこれらはあくまで例であり、普遍的な置換リストではありません。ご自身のレポートに記載されている正確なパスに基づいて対応してください。

アプリの警告をマスクせずに処理する

サーバーアップグレード後にフラグが立てられたアプリについては、まずアプリが対象のownCloudリリースをサポートしていることを確認してください。サポートされている管理者またはコマンドラインの手順を使用して互換性のないアプリを無効にし、マーケットプレイスまたはアプリメンテナから公式の互換性のあるリリースをインストールしてください。以前に署名されたアプリが署名されていない、または証明書が失効していると報告された場合は、メンテナに連絡して適切に署名された代替品を入手してください。別のアプリまたはバージョンから署名データをコピーしないでください。署名はアプリのコンテンツと証明書のスコープに関連付けられています。

警告対象となったアプリが組織が管理するカスタムアプリである場合、アプリの正規の保守担当者は、適切なプロセスと信頼できる署名資格情報を使用してリリースをビルドし、署名する必要があります。管理者は、不明または変更されたコードを通過させるために代替署名を作成してはなりません。ファイルのソースと整合性を確認できない場合は、警告を抑制するのではなく、レポートを保存し、潜在的なセキュリティ問題として調査してください。

修理を確認する

関連する整合性チェックを再度実行し、管理概要を更新してください。同じパスが表示されなくなったこと、修復されたコンポーネントの警告が消えたこと、ownCloud のログに新しいアップグレードエラーや権限エラーが表示されていないことを確認してください。ログイン、ファイル一覧表示、アップロード、および影響を受けるアプリをテストしてください。マルチノード展開の場合は、すべてのノードをチェックしてください。1 つのサーバーで問題がないという結果が出ても、すべてのノードで同じコードが使用されているとは限りません。

レポートが引き続き表示される場合は、ファイルの置換を停止し、実行中のツリーをそのバージョンの正確なパッケージ、デプロイメントイメージ、またはマウントされたボリュームと比較してください。コードの2つ目のコピー、古いバインドマウント、古いファイルを復元するデプロイメントスクリプト、またはローカルパッチがないか確認してください。バージョンに合ったownCloud 10.16のコード署名と整合性に関するガイダンス、ownCloudのアップグレード手順、および復元に関するドキュメントを参照してください。このページはownCloud Server 10.16向けです。以前のバージョンでは異なる場合があるため、インストールされているリリースに合ったドキュメントを選択してください。

コメントを残す

アップグレード後にownCloudの整合性警告をクリアする

無効ファイルレポートを使用して、一致しないコアファイルまたはアプリ署名を特定し、正しいリリースファイルを復元し、整合性チェックを安全に検証します。

ownCloud Infinite ScaleをDocker Composeでインストールする

ownCloud Infinite Scaleを公式のComposeサンプルからデプロイし、ドメインと永続ストレージを設定した後、TLS、コンテナ、および初回ログインを確認します。

ownCloud Infinite Scale 用の S3 Blob Storage の設定

ownCloud Infinite Scale 用の S3 Blob Storage の設定

ownCloud Infinite Scaleがファイルコンテンツを確実に保存できるように、S3NGドライバー、バケットのアクセス許可、永続的なメタデータストレージ、およびアップロードサイズを設定します。

ownCloudのアップロードが99%で止まった場合は、これらの制限を確認してください。

ownCloudのアップロードが99%で止まった場合は、これらの制限を確認してください。

ownCloud Serverへのアップロードが完了間近で停止する原因を特定するには、ファイルの状態、クォータ、一時ディスク容量、PHPの制限、プロキシのタイムアウトなどを確認してください。

ownCloudのApache .htaccess警告を安全にクリアする

ownCloudのApache .htaccess警告を安全にクリアする

ownCloudのウェブルートに対してのみAllowOverride Allを設定し、アクティブなApache仮想ホストを検証し、安全にリロードして.htaccessルールを復元します。

ownCloud Enterprise Auditingを設定し、ログを確認する

ownCloudのエンタープライズ監査アプリを有効にし、admin_auditイベントを保護されたログファイルにルーティングして、実際のユーザー操作が記録されていることを確認します。

ownCloud Infinite ScaleをOIDCを使用してKeycloakに接続します。

ownCloud Infinite ScaleをOIDCを使用してKeycloakに接続します。

Keycloakのレルム発行者、Webクライアント、およびユーザークレームを整合させることで、ownCloud Infinite ScaleがWebクライアントとモバイルクライアント全体でユーザーを確実にサインインできるようにします。

ownCloudのファイルを共有を失うことなく新しい所有者に移動する

ownCloudのoccコマンドを使用して、所有ファイルと共有フォルダを転送し、何が残るかを把握し、古いアカウントを削除する前にアクセス権を確認してください。

ownCloud 10のクエリを安全にインデックス管理することで高速化

ownCloud 10のデータベースインデックスに注意が必要な場合、サポートされているスキーマ更新を安全に適用する方法、クエリチューニングやデータベースの変更がより適切な解決策となる場合について学びましょう。

ownCloudでLinuxマウントなしでSMB/CIFS共有をマウントする

外部ストレージを介してWindowsまたはSambaネットワーク共有をownCloudに接続し、認証情報を確認し、アクセスできないフォルダのトラブルシューティングを安全に行います。