気がつけば長い道のりになってしまった。
PHP やCGI を適切に動作させるには、ユーザー権限で動作させることが必要だ。これはレンタル・サーバーでは至極当然として行われていて、主な理由は２つある。
１つはセキュリティー上の対策としての意味、もう１つは、FTP、Apache、PHP がそれぞれ異なる権限で動作すると、ファイルの読み書きができないからだ（これは１つめの理由にもつながっていくのだが）。
例えば上記の画面ではディレクトリを作成できない問題がそれだ。
スポンサードリンク
ディレクトリの権限を変更しても、セキュリティ関連の機能が働いてか500 エラーになるか、権限変更ができないようになっているようだった。
PHP モジュール版では、apache 権限で動作するため、アクセス権限の壁が存在しない。 suphp では、自分の uid と gid の権限で動作するため、アクセス権限の壁が構築される。 perl の suexec や fastcgi と同様の仕組み。
（「はっぴぃ・りなっくす – suphp CentOS 5 – Linux > Linux Software > PHP – SmartSection」より引用）
自 宅サーバーやVPSなど、自分でリソースを自由に使える環境下では、モジュール版を利用するのが良いと思いますが、 複数でサーバーの管理をする場合、どうしても誤って大事な他人の情報を削除したりしかねないので、共有サーバーでは、CGI版＋suEXEC で実行されているのが普通です。
（「apache で phpのモジュール版とcgi版の切り替えを行ってみる | レンタルサーバー・自宅サーバー設定・構築のヒント」より引用）
権限の確認方法
PHP としてはお馴染みのphp info を使えば調べることができる。ServerAPI が「CGI/FastCGI」になっているならCGI モードとして動作している。「Apache」の場合はApache の権限で動作している。
実行権限の設定
BlueOnyx は便利なものでPHP それ自体を利用するかどうかや、suPHP で実行するかもチェックボックス１つで変更できる。ところが、泥沼にハマることになった。
オーナーの変更
nobody、 Apache、 ユーザーが選択できる。この設定を変更すると、ファイルやディレクトリの権限がすべて変更される。この「親切」機能の影響もあって、より泥沼にハマったのだが・・。
試行錯誤
500 エラーになったり試行錯誤。
動作したかと思えば、「親切機能」によって偶然動作していただけで、実は解決していなかったなど試行錯誤。
また、サイトごとに設定できるconf ファイルに記載せよという参考情報を得ればそれも試すが効果はなかった。
※BlueOnyx の特徴的なはまりどころかもしれないところだが。システムを操作すると指定ファイル以外への書き込みができなかったり、上書きされる。
エラーログ
正常に実行された場合やされないばあいの比較など試行錯誤。
エラーからすべきことを探して対応するなど試行錯誤。
読み込めないなら直接記載してみるという試行錯誤。
open_basedir の設定
open_basedir が悪いのだという記述があればそれを変更してみるが、これが適応されない？？
ほかにもこの問題にぶち当たっている人がいたが、解決には至らなかったようだ。
PEAR を利用する場合などに一時的に「/」を追加するなどの方法も記載されていた。（サイトごとの設定と、全体設定がそれぞれあるので注意）
/ を追加しない状態ではWordPress もPEAR のアップデートも動作しなかった。しかし、追加すると無表示だったコンソールが変化し、動作している様子がわかった。（画像では中央より上が無反応で、設定変更後の下は動作している）
驚くことにこれでWordPress は動作してしまったが、おそらくセキュリティ的にはよろしくないのではないかと思い、他の手段も調査した。
中には操作手順が悪いのでは？という参考情報もあったが、とりあえず今回の作業では（セキュリティ的な評価はともかく）「/」を追加すると動作した。
ただ、すっきりしないし、試行錯誤の連続の場合、正しい手順も有耶無耶になってしまう。これでは以降に再発したとき、テスト用途とはいえ、他のサイトにまで影響するかもしれないから、再構築して手順を確認しておく（これが意外な結果になった）。
→ 続く
コメント