ownCloud Apache AllowOverride All 警告を安全に修正する

ownCloudがApacheのAllowOverride All設定が不足していると報告した場合は、ownCloudのインストールパスに一致するApache<Directory>ブロックにその設定を追加し、構成をテストしてからApacheを再起動してください。一般的なDebianまたはUbuntuのインストールでは、この設定はアクティブなownCloud仮想ホスト、またはApache構成内の対応するディレクトリブロックに記述する必要があります。1つの警告を解消するためだけに、サーバー全体でオーバーライドを有効にしないでください。

ownCloud Server (Classic) では、Apache がインストール環境のルールを読み取れるように設定する必要があります.htaccess。これらのルールは URL の書き換えをサポートし、機密性の高いパスを保護するのに役立ちます。ルールが欠落していたり、有効になっていない場合、クリーン URL とデータディレクトリのセキュリティチェックの両方に影響が出る可能性があります。このガイドは、Apache HTTP Server を使用する ownCloud Server に適用されます。Nginx、ownCloud Infinite Scale、または Apache の設定がプロバイダによって管理されているホスティング環境には適用されません。

クイックリファレンス

目標	チェックまたは設定
ownCloudのディレクトリごとのルールを許可する	`AllowOverride All<Directory>`一致するブロック内
Apacheが変更を解析できることを確認する	`sudo apachectl -t`報告する必要があります`Syntax OK`
設定を有効にする	`sudo systemctl reload apache2`DebianまたはUbuntu上で
クリーンURLをチェックする	`mod_rewrite`設定で必要な場合は有効にしてください
警告が消えたことを確認してください	影響を受けるURLをテストした後、ownCloudの管理概要を再読み込みしてください。

警告の意味

Apacheのディレクティブは、ファイルAllowOverride内のディレクティブがリクエストに影響を与えることを許可するかどうかを決定します。Apacheはセクション内のみでディレクティブを尊重します。仮想ホストの最上位レベルや無関係なブロックにこの行を配置しても、ownCloudファイルに対しては有効になりません。より広範なルール、より具体的なルール、または別の有効な仮想ホストが存在する場合、編集した設定がリクエストの処理に使用されない可能性もあります。.htaccessAllowOverride<Directory><Directory>

ownCloudの現在のServer 10.16インストールガイドでは、AllowOverride AllownCloudドキュメントルートのディレクトリブロックに「All」と記載されています。「All」は、そのスコープ内のApacheモジュールがサポートするオーバーライドクラスを許可します。Apacheのグローバルファイルシステムポリシーを変更するのではなく、この権限をownCloudディレクトリに限定してください。Apacheマニュアルには、AllowOverrideList特定のディレクティブのみを許可したい管理者向けの説明もありますが、リストを絞り込むには、ownCloudのバージョンと同梱されている.htaccessルールとの互換性を慎重にテストする必要があります。

ownCloudディレクトリブロック内にAllowOverride Allを設定したApache仮想ホストの例 — 仮想ホストの例は、`AllowOverride All`ディレクトリブロック内に配置します`/var/www/owncloud`。

Apacheを変更する前に

製品がownCloud Server（Classic）であることを確認し、Webルートの正確なファイルシステムパスを特定してください。のようなURLは、/cloudApacheを介してAliasディスク上の別のディレクトリにマッピングされる場合があります。
アクティブな仮想ホストと設定ファイルを見つけてください。DebianまたはUbuntuでは、一般的な場所としてとがあります/etc/apache2/sites-available/。RHEL/etc/apache2/apache2.conf系システムでは、Apacheの設定は通常の下にあります/etc/httpd/。ホスティングパネルやコンテナは、別のパスを使用する場合があります。
編集する前にファイルをバックアップし、既存のTLS、プロキシ、アクセス制御、およびownCloudディレクティブを保持してください。
AllowOverride None同じパスに別のルールまたはディレクトリルールが適用されていないか確認してください。ownCloudホスト名で有効になっていないデフォルトサイトファイルは編集しないでください。

自己管理型Apacheサーバーを修正する

1. アクティブな設定を編集する

DebianまたはUbuntuでは、ownCloudホスト名を提供する仮想ホストを開きます。例：

sudo nano /etc/apache2/sites-available/owncloud.conf

そのファイル内で、<Directory>ownCloudのインストールディレクトリを指定するセクションを見つけるか、追加してください。この最小限の例は、関連する配置を示しています。サーバーで既に必要とされている追加の指示はそのままにしておいてください。

<Directory /var/www/owncloud/>
    Options +FollowSymlinks
    AllowOverride All
    Require all granted
</Directory>

実際のパスに置き換えてください/var/www/owncloud/。ApacheがURLをマッピングする場合はAlias、URLパスだけでなく、ownCloudファイルを含むファイルシステムディレクトリを設定してください。ownCloudのApacheインストールガイドには、追加の設定に関する注意事項が記載されています。ご使用のownCloudリリースとPHPの設定に合った例を使用してください。

2. モジュールと構文をチェックする

クリーンな URL を実現するにはindex.php、ownCloud ドキュメントmod_rewriteとmod_envを前提条件とします。Debian または Ubuntu では、リライトモジュールが有効になっていない場合は有効にしてください。

sudo a2enmod rewrite
sudo apachectl -t

設定テストはで終了するはずですSyntax OK。エラーが報告された場合は、再読み込みする前にそのエラーを修正してください。構文チェックが成功したということは、Apache が設定を解析できることを証明しますが、正しい仮想ホストがアクティブであることや、実行中のプロセスが編集したファイルを読み込んだことを証明するものではありません。

Apacheの設定テストでターミナルに「構文OK」と表示される — Apacheの設定テストは、`Syntax OK`サービスを再起動する前に完了している必要があります。

3. Apacheを再起動し、ownCloudをテストします。

DebianまたはUbuntuでは、構文チェックが成功した後にApacheを再起動してください。

sudo systemctl reload apache2

RHEL系システムでは、サービス名は一般的にとなっているhttpdため、対応するサービス名とディストリビューションのconfiguration-testコマンドを使用してください。Debian固有のコマンドを、サービス構成を確認せずに他のシステムにコピーしないでください。

ブラウザでownCloudのホスト名を開き、以前に書き換えが必要だったページをテストしてください。サーバーがパスプレフィックス（例：）を使用している場合は/cloud、プレフィックス付きのURLもテストしてください。リダイレクトループ、403応答、またはApache 500エラーが発生した場合は、設定の調査が必要です。無関係なディレクティブを繰り返し変更するのではなく、ApacheのエラーログとownCloudのログを確認してください。

ターミナルに、書き換えモジュールが有効になり、Apacheサービスが再読み込みされたことが表示されます。 — 必要な場合にのみ有効化し`mod_rewrite`、構文チェックが成功したらApacheサービスを再起動してください。

警告が続く場合

症状	次のチェック
再読み込み後も警告が残る	編集した仮想ホストが有効になっており、ホスト名を提供していることを確認します。さらに、`apachectl -S`下位レベルまたはより具体的なディレクトリルールがないか確認します。
クリーンな URL には、`index.php`	`mod_rewrite`有効になっていること、ownCloud ディレクトリに意図した上書き権限が付与されていること、ownCloud の書き換えベースがその URL パスと一致していることを確認してください。
管理ページには、データディレクトリは一般公開される可能性があると記載されている。	可能であれば、データディレクトリがウェブルートの外にあることを確認してください。そうでない場合は、出荷時のデータディレクトリが`.htaccess`存在し、読み取り可能であり、Apacheによって正しく認識されることを確認してください。警告を解消したからといって、ディレクトリを保護する代わりにはなりません。
Apacheが500エラーを返すか、「ここでは許可されていません」と報告する	Apacheのエラーログを確認してください。ディレクティブが`.htaccess`アクティブなオーバーライドクラスによって許可されていないか、必要なモジュールが利用できない可能性があります。
コンテナまたは管理対象ホストで実行	イメージに記載されているApacheの設定、またはプロバイダのコントロールパネルを確認してください。ホストレベルのApacheファイルが、リクエストを処理するサーバーであるとは限りません。

ownCloud が.htaccessファイルの更新ができないと報告する場合は、所有権と書き込み権限を変更する前に、ownCloud のアップグレードおよびセキュリティ強化に関するガイダンスと照らし合わせて確認してください。Web サーバーがインストール全体をショートカットとして書き込み可能にすることは避けてください。ownCloud のドキュメントには、構成の詳細はインストールによって異なり、PHP-FPM はの PHP 設定を使用しないと記載されています.htaccess。この場合の設定はにあります.user.ini。この PHP の区別自体は、Apache が ownCloud の書き換えルールとアクセスルールを処理する必要性を置き換えるものではありません。

検証チェックリスト

パス<Directory>は、ディスク上のownCloudファイルと完全に一致します。
一致するブロックにはが含まれておりAllowOverride All、アクティブな競合ルールが優先されません。
sudo apachectl -t返しますSyntax OK。
Apacheは正しいサービス名を使用して再起動されました。
ownCloudのログインページと、以前影響を受けたURLは、想定どおりHTTPS経由で読み込まれます。
更新後、管理概要には同じ警告が表示されなくなりましたが、データディレクトリは引き続きパブリックWebからはアクセスできません。

ターミナルで信頼済みドメインを確認する設定済みホスト名でのownCloudサインインページの例 — 設定済みのホスト名におけるownCloudのサインインページの例です。実際の警告ステータスは、ご自身の管理画面の概要でご確認ください。

公式資料

コメントを残す

クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する

Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。

PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

Jitsi Videobridgeに内蔵されたPrometheusエンドポイントを使用して、Jitsi Videobridgeの状態、会議の負荷、トラフィックを追跡し、Grafanaでデータを探索およびグラフ化できます。

Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker 用のカスタムドメインを、DNS、PUBLIC_URL、HTTPS、Let's Encrypt、ファイアウォールポート、NAT 設定、エンドツーエンド検証とともに構成します。

SSL更新後にZimbra管理コンソールで発生する404 Not Foundエラーを修正する

SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。

Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を修正する

アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。

MySQLバージョンアップグレード後のKopanoデータベース移行エラーを修正する

MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。

NextcloudでLDAPとActive Directory認証を設定する方法

セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。

GoogleサービスなしでElement Android通知を修正する方法：UnifiedPushガイド

UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。

Nextcloudの「データベースに一部のインデックスが欠落しています」という警告を修正する

Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。

Element WebでKeycloakを使用してシングルサインオン（SSO）を設定する方法

Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザークレームをマッピングし、ログアウトをテストします。