先日、AWSからOCIへWordPressを移行しました。
しかしそれ以降でStaticPress等のプラグインが正常に動作しない現象が発生していました。
今回はそれらの原因と解消について報告します。
症状1
StaticPressを実行すると、1分後に「初期化中 … エラー!」が返ってきます。
ブラウザから確認をするとadmin-ajax.phpが403エラーになっていることが原因のようでした。
しかし、実行ユーザーが正しく設定されていることも確認できており、WAFなどのセキュリティツールは導入していませんでした。
症状1の結論
先に結論を述べてしまうと、実際のエラーは403ではなく504でした。
本ブログの構成としてはOracle Cloud上のコンピュートインスタンスにWordPressが乗っているのですが、ブラウザからアクセスする際はAWS上のCloudFrontを経由しています。
CloudFrontはオリジンからのタイムアウトの閾値が最長で1分なので、オリジンサーバーから1分間のレスポンスがないとタイムアウトを返してしまいます。
Apache側のタイムアウト設定を300秒などにしてもCloudFront側のタイムアウト制限に引っかかってしまうので、正常に動作しませんでした。
こちらに関しては以下のURLからクォータ緩和の制限を行うことで、タイムアウトの上限時間を任意に増やすことができます。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html
症状2
StaticPressを実行すると「フェッチ開始」から進まなくなりました。
php-fpmのエラーログを確認すると、どうやら403エラーになっておりファイルの作成ができないようです。
◆エラーログ
mkdir(): Permission denied in … class-static_press.php on line 360
後半はやけくそになっていたのですが、全てのファイルを777権限に変更してもパーミッションエラーで失敗してしまいました。
症状2の結論
この403エラーは厄介なことにパーミッション設定が原因ではありませんでした。
確認したところ、AmazonLinuxとは異なりOracleLinuxではデフォルトでSELinuxが起動しているため、勝手にファイル作成ができないようにアクセス制御されてしまっていたようです。
# 確認コマンド Enforcingだと有効 $ getenforce > Enforcing
そのため、まずはSELinuxを無効にして確認しました。
# 無効コマンド $ setenforce 0
結果
その他にもWordPressのメディアファイルを編集するプラグインが動作しなくなっていたのですが、SELinuxを無効化することで正常な動作になりました。
しかしこのままではSELinuxを使わないため、セキュリティの脆弱性を残すことになります。
SELinuxの設定
今回はSELinuxでhttpdの特定ディレクトリ操作が許可されていなかっただけなので、SELinuxを再度有効にしてきちんと制御することにしました。
# スーパーユーザーに切り替えておく $ sudo su - # SELinuxを再び有効に $ setenforce 1 # wordpressディレクトリのパスに対してアクセスと書き込み許可を与える $ semanage fcontext -a -t httpd_sys_rw_content_t "/var/www/wordpress(/.*)?" # ラベルの設定 $ restorecon -R /var/www/wordpress
上記を実行後、念の為Apacheを再起動してStaticPressを実行したところ問題なく動作することを確認できました。
今回はサーバー移管の際にOSも変更になったため、OracleLinuxのデフォルト設定に惑わされて一部の機能が正常に動作しなくなっていたことが原因でした。
私と同様のケースが発生することはあまりないかもしれませんが、誰かの参考になれば幸いです。
コメントを残す