Czy php.cgi korzysta z php-cgi.ini?

[Jacek Osiecki]

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 joshua w ceti.pl GG:3828944
I don't want something I need. I want something I want.