PHP jako moduł apache czy CGI?

[jamesisko]

Witam,

stawiam nowy serwer i dotałem pytanie od admina .. PHP ma być jako moduł apache czy jako CGI?

Weim czym to się różni tak plus minus.. co wy polecacie do takiej konfiguracji serwa:

1 proc. Intel Xeon X3320 2.5 GHz Quad Core, 1333MHz FSB

łącze 100Mbit

8 GB RAM ECC

2x300GB SAS Sprzętowy RAID

[NieW]

Witam,

stawiam nowy serwer i dotałem pytanie od admina .. PHP ma być jako moduł apache czy jako CGI?

Stawiam na Cgi - większe możliwości namierzenia ewentualnych problemów ze skryptami php oraz konfiguracji pod swoje środowisko

[jamesisko]

nie bedzie problemow np z..

mam taki swój systemik linkowania.. gdzie strony maja include(/home/link/public_html/get_links.php)

czy nie bedzie problemu by strony na róznych kontach pobieraly taki skrypt?

podobnie z zapisywaniem cache z rożnych kont w jednym miejscu.. na innym koncie?

[sorrow]

Jako moduł PHP, Apacha strasznie żre dużo ramu w przypadku awarii modułu cały demon siada. Dlatego zalecane jest FastCgi odnośnie zapisu to kwestia ustawień oraz testów

[jamesisko]

um, potestuje cgi.. narazie mam php4 jako modul php5 jako cgi. stare ustawienia. na nowej maszynie chce miec tylko php5 i zobaczymy jak to bedzie chodzilo jako cgi.. bo im wiecej czytam tym bardziej za cgi jestem.

[Maximus Marius]

Jako moduł PHP, Apacha strasznie żre dużo ramu w przypadku awarii modułu cały demon siada. Dlatego zalecane jest FastCgi odnośnie zapisu to kwestia ustawień oraz testów

Ja to bym wolał jakieś konkrety , wyniki testów itp.

W przypadku awarii modułu PHP należy zgłosić bug-a, developerzy beda bardzo wdzięczni.

Za cgi/fastCgi przemawia elastycznośc rozwiązania, moduł PHP można mieć tylko jeden , skompilowanych php.cgi ile dusza zapragnie.

[sorrow]

Mówisz masz

https://www.alexatnet.com/node/144

https://www.apachelounge.com/forum/viewtopic.php?p=10991

https://blog.zabiello.com/articles/2006/04/..._php-mod_python

https://wss.pl/Articles/9683.aspx

https://blog.dreamhosters.com/2006/04/11/en...-apache-module/

"We actually removed the Apache module feature as it turned out to be causing higher loads than the former. Go figure, huh?"

[Maximus Marius]

Dziękuję!

[slawek22]

Jako moduł PHP, Apacha strasznie żre dużo ramu w przypadku awarii modułu cały demon siada.

W wypadku awarii modułu PHP siada dany proces i jedno bieżące połączenie a cały serwer jak i reszta połączeń działa bez problemu. Proces który siadł jest uruchamiany od nowa i na tym się kończy awaria mod_php/prefork który z resztą jest chyba najpopularniejszym i najlepszym sposobem na uruchomienie PHP pod apache na serwerze dedykowanym.

Dlaczego mod_php jest najlepsze na dedyka? Bo jest najszybsze, dlatego, że interpreter znajduje się w obszarze pamięci apache a komunikacja między modułem - apache to prosta instrukcja kopiowania pamięci a nie na przykład wolne sockety. W CGI przy każdym wywołaniu skryptu do pamięci jest ładowany interpreter PHP! fCGI jest szybsze niż CGI ale dalej w oddzielnym obszarze pamięci.

PHP jest nieprzystosowane do uruchamiania w trybie worker, szczególnie moduły. Używanie czegoś niezgodnie z przeznaczeniem to proszenie się o problemy. Jeżeli uruchomisz mod_php tak jak to nie jest zalecane to nic dziwnego, że to nie będzie dobrze działać.

Jeden mądry link z tego wszystkiego (tylko, że on dotyczy czegoś innego): https://blog.zabiello.com/articles/2006/04/..._php-mod_python

Korzystanie z mod_apache nie wpływa niekorzystnie na serwer jeśli jest skonfigurowany w trybie prefork. Ludzie którzy to testują pod windowsem/IIS i nie umieją konfigurować serwerów mogą sobie pisać, że cieknie pamięć, wolno działa i jest złe, ale to kompletna bzdura. Ja sobie mogę uruchomić dotneta na linuxie i potem pisać że to szajs i się ośmieszyć równie dobrze. Albo wlać olej rzepakowy do samochodu i marudzić że nie chce jechać.

Skąd wiem że PHP jako moduł jest OK? Bo sam mam w PHP w trybie modułu apache, zużycie pamięci nie przekracza 500mb a apache robi kilkaset tysięcy requestów dziennie, nic się nie wiesza, serwer ma uptime ponad 100 dni i działa szybko. Jest munin i dokładne statystyki. Tylko z tą różnicą że to stoi na linuxie a nie na windowsie i (OMG) IIS.

Tutaj jest porządny artykuł o tym a nie wypociny pokemonów które testują wydajność apache w windowsie:

https://hostingfu.com/article/running-php-on-shared-hosting

Tam jest dość dobra tabela obrazująca wady / zalety mod/cgi/fcgi pod linuxem i apache

Wady mod_php są związane głównie z uruchamianiem tego na dzielonych serwerach a nie na dedyku. Maximus wynikami tych "testów" (bo to kompletne bzdury) bym w żadnym wypadku się nie sugerował bo ludzie którzy je przeprowadzali nie wiedzieli nawet jakiego oprogramowania mają użyć.

Well. Simply put, the reason most webhosts don't run PHPsuexec is primarily because of the significant performance disadvantage of running PHP as a CGI and the associated overhead of loading the PHP interpreter into memory for each executed script.

mod_php offers a significant performance advantage over running PHP as a CGI, and this increase in performance is critical for a webhost, especially on a machine with hundreds or thousands of virtual domains.

mod_php runs as the same unprivileged user that Apache runs as, typically "nobody". In this configuration Apache remains unprivileged and for the most part, reliably secure. Running something like PHPsuexec would not only introduce an additional setuid binary, but could also potentially open up a very serious security hole if there were a vulnerability found in PHPsuexec.

Alot of webhosts are migrating to PHP/FastCGI which offers somewhat similar performance to mod_php, and allows user privileges to be set via the same suexec mechanism as normal CGIs.

Another key component to keep on the watch list is the very experimental, but upcoming "perchild" MPM (https://httpd.apache.org/docs/2.0/mod/perchild.html...) which is a hybrid forking+threading model MPM which has the ability to set per virtualhost user/group privileges.

https://www.alexatnet.com/node/144

Mądre komentarze pod dołem dyskredytujące ten test. Kto w ogóle wpadł na pomysł, żeby PHP testować pod windowsem! Powinni go od razu zamknąć w pokoju bez klamek. Test jest do niczego, odsyłam do komentarzy.

https://blog.dreamhosters.com/2006/04/11/en...-apache-module/

we disabled the use of turning off PHP as CGI as this was becoming an issue since when you turn it off, your applications run under Apache’s memory space, which then makes it hard for us to determine who is using resources.

Oni wyłączyli żeby sprawdzać kto ile zasobów używa, a właściwie sami nie wiedzą dla czego, sytuacja wyjaśniona tam -->>

https://blog.dreamhosters.com/2006/04/11/en...odule/#comments

PHP as CGI runs under a somewhat strict suEXEC environment, which is why a lot of php-related .htaccess directives get ignored. mod_rewrite directives are definitely okay under CGI (I use them myself.) Sadly, that’s just the breaks on a shared server, where security and usability must be balanced.

Lastly, it would appear the “hip new thing” is to sign up for a DreamHost account, create 50 different subdomains, host a lot of crazy CPU-intensive scripts (discuz forums, anyone?) and hide it all under mod_php so linux’s accounting system thinks dhapache is hogging everything and we have no way to track down who’s really doing it

Mają problemy z śledzeniem zamulaczy serwera.

https://www.apachelounge.com/forum/viewtopic.php?p=10991

Kolejna bzdura, tak to jest jak się uruchamia apache pod windowsem i dodatkowo nie umie go skonfigurować jak trzeba.

PHP configuration: only with the extension php_mysql.dll and eaccelerator.dll

Light blue: httpd.exe processes Memory Usage

Dark blue: all processes Memory Usage total

exe... dll... OMG!

https://wss.pl/Articles/9683.aspx

Kolejny raz PHP w IIS pod windowsem Nie rób sobie jaj to tak jakby nie wiem... uruchamiać worda pod linuxowym emulatorem windowsa i na podstawie tego robić testy wydajności zestawów komputerowych dla sekretarek.

[jamesisko]

czyli jednak jako modul. Poczytalem te wszystkie linki i bedzie to modul apache. OK, dzieki wielkie za pomoc w podjeciu decyzji. serwer della zamówiony, pod koniec czerwca powinien być juz na chodzie (lacznie przeniesienim wszystkiego).

aha, bedzie to chodzlo prawdopodobnie na CentOS 4.4

[Prohost]

Na dedyka gdzie tylko ty masz www najlepiej mod_php. Jednak jeśli ktoś haknie ci jedną www to ma dostęp do wszystkich.

Cgi najlepiej się nadaje tam gdzie trzeba oddzielać strony/użytkowników.

Przy Cgi tez łatwiej znajdziesz problem co ci zamula serwer.

Oczywiście są inne rozwiązania jak https://www.litespeedtech.com/products/webserver/overview/

Tu php działa bezpiecznie podobnie do fastcgi ale duzo szybciej używając ich sapi - tylko nie można na tym serwerze mieć materiałów dla dorosłych i w wersji enterprise jest płatny.

[slawek22]

Na dedyka gdzie tylko ty masz www najlepiej mod_php. Jednak jeśli ktoś haknie ci jedną www to ma dostęp do wszystkich.

Prawda, jednak jeśli masz "sam dla siebie" mod_php to jeśli ci ktoś haknie serwer to ma dostęp jedynie do plików do których ma dostęp serwer (użytkownik nobody dajmy na to). Może nadpisać tylko to do czego apache ma prawo pisać tzn to co ma ustawione prawa zapisu "dla wszystkich użytkowników serwera".

Jak masz cgi i pliki są własnością konkretnego użytkownika to jeden włam i leci cała zawartość konta użytkownika, w przypadku kiedy jesteś sam na serwerze leci dosłownie WSZYSTKO czyli cała zawartość serwera WWW.

bezpieczeństwo mod_php jest wyższe jeśli jesteś sam na serwerze. cgi jest lepsze kiedy prowadzisz hosting.

No chyba, że sobie byś ustawił innego użytkownika dla każdej witryny, ale tutaj znowu w cgi może włamywacz wyciąć wszystko a w mod_php tylko pliki które pozwalasz modyfikować skryptom php.

[jamesisko]

Wiecie co.. to ja juz nie wiem.. teraz mi admin pisze ze php5 nie chodzi jako moduł apache.

gosc jest b. konkretny jesli chodzi o ustawianei.. ale cholernie oszczędny w słowach.

Zrobie tak jak mam teraz: php4 jako modul apache, php5 jako cgi.

i tak bedzie najlepiej.

[Prohost]

Na dedyka gdzie tylko ty masz www najlepiej mod_php. Jednak jeśli ktoś haknie ci jedną www to ma dostęp do wszystkich.

Prawda, jednak jeśli masz "sam dla siebie" mod_php to jeśli ci ktoś haknie serwer to ma dostęp jedynie do plików do których ma dostęp serwer (użytkownik nobody dajmy na to). Może nadpisać tylko to do czego apache ma prawo pisać tzn to co ma ustawione prawa zapisu "dla wszystkich użytkowników serwera".

Jak masz cgi i pliki są własnością konkretnego użytkownika to jeden włam i leci cała zawartość konta użytkownika, w przypadku kiedy jesteś sam na serwerze leci dosłownie WSZYSTKO czyli cała zawartość serwera WWW.

bezpieczeństwo mod_php jest wyższe jeśli jesteś sam na serwerze. cgi jest lepsze kiedy prowadzisz hosting.

No chyba, że sobie byś ustawił innego użytkownika dla każdej witryny, ale tutaj znowu w cgi może włamywacz wyciąć wszystko a w mod_php tylko pliki które pozwalasz modyfikować skryptom php.

Przecie pod cgi też można dać chmod tylko do odczytu plikom - nie widzę problemu.

Ale i tak są sposoby. Najlepiej minimalizować straty oddzielając strony/userów. No i nie mieć dziur w skryptach. Robić backupy itp.

[slawek22]

php4 jako modul apache, php5 jako cgi.

To standardowe rozwiązanie, może się da ustawić oba jako moduły ale tego nie jestem pewien.

Przecie pod cgi też można dać chmod tylko do odczytu plikom - nie widzę problemu.

Tak, racja. Da się ustawić chomd, jednak korzystając z modułu jest o tyle lepiej że bez zabawy masz prawa modyfikacji tylko tych plików które zostały utworzone przez proces apache (tzn. pliki które ty umieściłeś na serwerze nie mogą być zmienione korzystając z luki).

Ale i tak są sposoby. Najlepiej minimalizować straty oddzielając strony/userów.

To zależy, dla mnie najlepszym rozwiązaniem byłoby połączenie obu metod. Tzn. oddzielenie strony/userów i prawa zapisu tylko do plików / katalogów z ręcznie nadanym takim prawem.

Co do hostingu to ja myślałem o rozwiązaniu które uniemożliwi wykonywanie jakichkolwiek plików przez serwer www jeśli katalog lub plik ma prawa zapisu, jest coś takiego?

Jeszcze co do mod_php to na przykład umieszczenie katalogów użytkowników tak: home/40_losowych_znaków/public_html ustawienie katalogu FTP na /public_html oraz wyłączenie praw listowania zawartości katalogu home dla użytkownika nobody nie rozwiązałoby problemu z dostępem do nie swoich plików na dzielonym hostingu?