10

この問題に関する多数の投稿を読みましたが、どれも私の問題と正確に一致しません。GoDaddy 仮想ホストに WordPress サイト (現在は 3.5) があります。11 月に、O/S を CentOS 5 から CentOS 6.3 にアップグレードすることを選択しました。これには、O/S の完全な再インストールが含まれていましたが、これについては制御できず、情報もありませんでした。O/S の再インストールに続いて、開始直前に取ったバックアップからサイトを再構築しました。

再構築後、何年も使用してきた WordPress プラグインである WP-DBManager が突然、mysql データベースのバックアップを停止しました。バックアップ パネルで「MYSQL パスが存在しません」と表示されるため、バックアップは失敗します。面倒なことに、DB オプション ページに移動して mysql パスを自動検出するように指示すると、オプション ページは正しい /usr/bin/mysql を生成します。SSH でサイトにログインできます。権限は次のとおりです。

-rwxr-xr-x 1 root root 338184 Jun 22 05:58 /usr/bin/mysql

これは機能する必要があります。この再構築でサイトのアクセス許可の何かが変更されましたが、何がわかりません。これまでのところ、WordPress の構成のみを文書化しました。私が行った調査によると、PHP セーフ モードが関係している可能性があります。PHP 5.3.3 を実行していますが、phpinfo() からの構成リストが表示されません。

--enable-safe-mode

つまり、セーフモードはオフにする必要があります。これが開始されたときのphp.iniのセーフモード設定は次のとおりです。

safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
safe_mode_exec_dir = 
safe_mode_include_dir = 
safe_mode = off
safe_mode_gid = off

それ以来、safe_mode_gid を ON に変更しましたが、効果はありません。safe_mode_include_dir = ~ という本番サイトからテスト サイトを構築したので、それを試してみましたが、効果はありませんでした。テスト サイトは PHP 5.3.14 を実行し、上記のセーフ モード設定は safe_mode_include_dir を除いて同じです。ENV 変数を確認したところ、/usr/bin が PATH に含まれています。

PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/lrservice/bin

これが環境変数の問題かどうかはわかりません。そのためのセーフモードのエントリは次のとおりです。

safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH

これらの設定は、実際のテスト サイトではすべて同じではありません。

safe_mode_allowed_env_vars = PHP_ LANG LANG_

サイトはこれを除いて完全に機能しているため、mysql のアクセス許可は一般的に正しいことがわかっています。これは誰にとってもベルを鳴らしますか?? セーフモードが正式にオフになっているのに、なぜこのようなことが起こるのでしょうか? 私が見逃している明らかでばかげた何かがあると感じています。

4

1 に答える 1

2

ディレクトリ内のセッションmysqlからバイナリにアクセスできますが、同じ場所で見つけることができません。システムでapache2 Web サーバーを使用していると仮定しています。ssh/usr/binphp

ディレクティブはChrootDirapache 構成ファイル (通常は にあります/etc/httpd/conf/httpd.conf) に存在しますか?

その場合、mysql バイナリへのリンクがあるかどうか、このディレクティブが指すディレクトリをチェックインできます。そうでない場合は、ssh セッションで次のコマンドを実行して (そのための権限があると仮定して) 単純に追加します。

$ ln /usr/bin/mysql /chroot/path/usr/bin/mysql

ディレクティブ パスに/chroot/path置き換えられます。ChrootDir

コメントの 1 つは、php.ini、httpd.conf、または.htaccessファイルのいずれかで構成できるopen_basedir PHP 設定について言及しています。

この設定は、PHP が使用できるファイルシステムの特定のディレクトリへのアクセスを制限します。設定が保護されていない場合、使用しているプラ​​グインによって実行されるスクリプトのこの制限を削除することで解決できる可能性があります。

  • WordPress ディレクトリにプラグインによってインストールされたスクリプトを見つけます。

  • 次のコマンドを使用して、スクリプトを含むディレクトリの制限を解除する .htaccess ファイルを作成します。

    $ echo 'php_value open_basedir none' >> .htaccess

上記は、.htaccess ファイルの末尾にある単純な引用符の間にテキストを追加し、必要に応じて作成します。このソリューションは、セキュリティをこれらのスクリプトのみに緩和するため、おそらく最も安全です。これらのスクリプトが、実際に操作する必要がある以上のものにアクセスできる可能性があることに注意する必要があります。

上記が機能しない場合は、設定が保護されていることを意味し、ディレクトリ内にあるhttpd.confまたはphp.iniで変更する必要があります。/etc詳細については、このSO の質問を参照してください。

于 2012-12-19T01:49:15.027 に答える