Przeczytałem wiele postów na ten temat i żadnychz nich dokładnie pasuje do mojego problemu. Mam witrynę WordPress (obecnie 3.5) na wirtualnym hoście GoDaddy. W listopadzie zdecydowałem się na uaktualnienie O / S z CentOS 5 do CentOS 6.3, co wymagało pełnej ponownej instalacji O / S, nad którą nie miałem kontroli i o której nie miałem informacji. Po ponownej instalacji systemu operacyjnego przebudowałem witrynę z kopii zapasowej wykonanej tuż przed rozpoczęciem.
Po przebudowie byliśmy już wtyczką WordPressprzez lata WP-DBManager nagle przestał tworzyć kopie zapasowe naszej bazy danych mysql. Tworzenie kopii zapasowej kończy się niepowodzeniem, ponieważ panel kopii zapasowej twierdzi, że „ścieżka MYSQL NIE istnieje”. Irytujące jest to, że gdy idziesz do strony Opcje DB i każesz jej automatycznie wykryć ścieżkę mysql, na stronie opcji pojawia się / usr / bin / mysql, co jest poprawne. Mogę zalogować się na stronie za pomocą SSH i gotowe. Uprawnienia są następujące:
-rwxr-xr-x 1 root root 338184 Jun 22 05:58 /usr/bin/mysql
Powinno to działać. COŚ w moich uprawnieniach do strony zmieniło się po tej przebudowie i nie wiem, co do tej pory dokumentowałem tylko konfiguracje WordPress. Z przeprowadzonych przeze mnie badań wynika, że może to mieć związek z trybem bezpiecznym PHP. Uruchamiamy PHP 5.3.3, a lista konfiguracji z phpinfo () nie pokazuje
--enable-safe-mode
co oznacza, że tryb awaryjny powinien być WYŁĄCZONY. Ustawienia trybu bezpiecznego w php.ini po uruchomieniu:
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
Od tego czasu zmieniłem Safe_mode_gid na ON, bezefekt. Mam witrynę testową zbudowaną z witryny produkcyjnej, gdzie safe_mode_include_dir = ~, więc wypróbowałem to bez żadnego efektu. Na stronie testowej działa PHP 5.3.14, a powyższe ustawienia trybu bezpiecznego były identyczne, z wyjątkiem parametru safe_mode_include_dir. Sprawdziłem zmienną ENV i / USR / bin znajduje się w PATH:
ŚCIEŻKA = / usr / local / bin: / bin: / usr / bin: / usr / local / sbin: / usr / sbin: / sbin: / home / lrservice / bin
Nie wiem, czy jest to problem ze zmienną środowiskową, oto wpisy trybu awaryjnego:
safe_mode_allowed_env_vars = PHP_
safe_mode_protected_env_vars = LD_LIBRARY_PATH
Te ustawienia nie są takie same w działającej witrynie testowej, czytamy:
safe_mode_allowed_env_vars = PHP_ LANG LANG_
Ponieważ strona jest w pełni funkcjonalna, z wyjątkiemto, wiem, że uprawnienia mysql są ogólnie poprawne. Czy to dzwoni jakimś dzwonkiem dla kogoś? Dlaczego dostaję to wszystko, jeśli tryb awaryjny jest oficjalnie wyłączony? Mam wrażenie, że jest coś oczywistego i głupiego, że ja " brakuje mi.
Odpowiedzi:
2 dla odpowiedzi № 1Masz dostęp do mysql binarny z ssh sesja w /usr/bin katalog, ale php nie może go znaleźć w tym samym miejscu. Zakładam, że twój system używa apache2 serwer internetowy.
Jest ChrootDir dyrektywa obecna w pliku konfiguracyjnym apache (zwykle znajduje się w /etc/httpd/conf/httpd.conf)?
W takim przypadku możesz sprawdzić wkatalog wskazany przez tę dyrektywę, jeśli istnieje link do pliku binarnego mysql. Jeśli nie, po prostu dodaj go, wykonując następujące polecenie (zakładając, że masz do tego uprawnienia) w sesji ssh:
$ ln /usr/bin/mysql /chroot/path/usr/bin/mysql
z /chroot/path zastąpiony przez ChrootDir ścieżka dyrektywy.
Jeden z komentarzy wspomina o open_basedir Ustawienie PHP, które można skonfigurować w php.ini, httpd.conf, lub .htaccess akta.
To ustawienie ogranicza dostęp do określonego katalogusystemu plików dostępnego dla PHP. Możliwą poprawką jest usunięcie tego ograniczenia dla skryptów wykonywanych przez używaną wtyczkę, jeśli to ustawienie nie jest chronione:
- zlokalizuj skrypty zainstalowane przez wtyczkę w katalogu wordpress,
utwórz plik .htaccess znoszący ograniczenie w katalogu zawierającym skrypty za pomocą następujących poleceń:
$ echo "php_value open_basedir none" >> .htaccess
Powyżej doda tekst między prostym cytatemna końcu pliku .htaccess, tworząc go w razie potrzeby. To rozwiązanie jest prawdopodobnie najbezpieczniejsze, ponieważ ogranicza relaksację bezpieczeństwa tylko do tych skryptów. Powinieneś uważać, aby te skrypty potencjalnie miały dostęp do znacznie więcej, niż naprawdę muszą działać.
Jeśli powyższe nie działa, oznacza to, że ustawienie jest chronione i należy je zmienić w dowolnym z nich httpd.conf lub php.ini które powinny znajdować się w obrębie /etc informator. Zobacz WIĘC pytanie dla szczegółów.