On Tue, 26 Jan 2010, Remigiusz 'Enleth' Marcinkiewicz wrote:
On Tuesday January 26 2010 18:44:25 Jacek Osiecki wrote:
On Tue, 26 Jan 2010, Arkadiusz Rdest wrote:
Jacek Osiecki wrote:
On Tue, 26 Jan 2010, Marcin Kurzyna wrote:
Hmm, sprawdziłem php.cgi -i - i pokazało że używa
/etc/php/php-cgi-fcgi.ini Dlaczego? Owszem, fcgi mam zainstalowane (za
chwilę je usunę bo na nic się nie przyda chyba)
a powinno ci sie przydac, bo FastCGI to najbezpieczniejszy i najszybszy
model odpalania prpocesów PHP.
Teoretycznie najbezpieczniejszy, ale za to wysoce problematyczny - nigdzie
nie można znaleźć jednoznacznej informacji jak go używać... Bezpieczny to
jest dopiero po pożenieniu z suexec/suphp, a prób zestawienia działającego
zestawu fcgi+suphp miałem już serdecznie dosyć.
Po prostu odpalać procesy na koncie usera którego prawa mają mieć wykonywane
skrypty? Do tego żadnego sucrapa nie trzeba, wystarczy spawn-fcgi i skrypt
startowy przystosowany do pracy z wieloma instancjami usługi. Jako bonus
Nie wiem, próbowałem wielu różnych kombinacji i za każdym razem albo nie
działało zgłaszając (lub nie) dziwaczne błędy z których nie dało się niczego
wywnioskować, ewentualnie działało ale nie do końca (losowe "permission
denied" lub diabli-wiedzą-czemu próba dostępu do innego katalogu niż trzeba).
dostaniesz niewrażliwość serwera HTTP i procesów PHP innych userów na złamanie
zabezpieczeń, zwis lub restart pojedyńczej instancji, możliwość podania
całkowicie innej konfiguracji albo nawet wersji PHP na konkretny vhost, a
jakby pokombinować, powinno być możliwe nawet prawdziwe chrootowanie PHP np.
na ~/public_html/ usera.
Ja się po prostu poddałem :) Nawet głupiego wykonywania z prawami usera nie
mogłem wyegzekwować, a o chrootowaniu to nawet nie próbowałem marzyć :(
Swój skrypt startowy mogę udostępnić, jakby ktoś był zainteresowany. Nie
jestem pewien, czy jest w pełni "the PLD way", ale IMHO jest wygodny i działa
dobrze. Już dawno bym go podrzucił do skomentowania na -devel, ale czasu nie
mam żeby dopracować i opisać...
Udostępnij, może w końcu zrozumiem co właściwie należy ustawić w tym fcgi :)
Mnie przerosły pliki konfiguracyjne, w których wszystko trzeba było ustawiać
na czuja i najlepiej po kilka razy (w php.ini, w definicji virtualhosta,
w osobnym .conf dla apache'a itd.
Do tego nie działa z APC, który daje takiego kopa że niejeden serwer uratował...
eAccelerator i xcache działają. Ten pierwszy w moich (bardzo nienaukowych i
nieudokumentowanych) testach był pod fcgi szybszy. Jeśli nie potrzebujesz
jakiejś konkretnej funkcjonalności którą ma tylko APC, może jeden z tych się
nada?
Ja jestem prosty człek, chcę mieć działający system. Przy fcgi kilka dni
walki spełzło na niczym, a APC ma bardzo miłą zaletę: instalujesz i działa.
Jako mod_php - zać php.cgi jest potrzebne do odpalania pojedynczych rzeczy
z crona. Tak, wiem - można mu wskazać jawnie plik konfiguracyjny - ale nawet
o tym nie myślałem widząc jasny opis że php-cgi.ini jest includowane przy
php.cgi :)
Odpalanie php.cgi z crona naprawdę ci działa? CGI to nie synonim dla CLI,
programy działające jako CGI oczekują konkretnych danych od serwera HTTP w
zmiennych środowiskowych, zwracają wyjście z (częściowymi) nagłówkami HTTP i
generalnie zakładają, że odpalić je mógł tylko serwer HTTP i nic innego. Jeśli
działa, to chyba bardziej z przypadku niż zamierzeń autorów PHP...
No bez przesady - to że wyrzuci nagłówki to żaden problem. Nie widzę powodów
(poza estetycznymi), dla których php.cgi miałoby nie działać.
Pozdrawiam,
--
Jacek Osiecki [email protected] GG:3828944
I don't want something I need. I want something I want.
_______________________________________________
pld-users-pl mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-users-pl
