Onderwerp: SuPHP

SCRIPTS / WERKENDE OPTIES
- uploaden werkt en wordt onder de user van de script geplaatst.
- phpinfo zie http://beta.starxs.nl/test.php
- phpmyadmin werkt goed
- normale scripts hierzo werken perfect
- zend encoded scripts werken perfect
-- http://beta.starxs.nl/info.php
- php errors worden in de browser gezet ipv error_log (voordeel)!

BEVEILIGING
- controleert gebruiker (GID onder de 100? geen toegang!)
- start script vanaf de eigenaar
- kan scripts buiten document_root niet openen
- upload de bestanden op de naam van eigenaar

OPTIES
- per virtualhost suphp aan en uit zetten
- per virtualhost suphp een aparte php.ini file geven.

Wat ik me nu afvraag, op het moment dat ik cpanel de boel laat updaten, is dat dan niet allemaal weg en kan ik dus alles opnieuw instellen?

Of vraag ik nu iets heel doms :x

Origineel geplaatst door eXite
Wat ik me nu afvraag, op het moment dat ik cpanel de boel laat updaten, is dat dan niet allemaal weg en kan ik dus alles opnieuw instellen?

Of vraag ik nu iets heel doms :x

legt er aan hoe de update werkt.
Schrijft hij de httpd.conf opnieuw dan heb je een probleem =)
Trouwens het activeren van .php heeft een andere commando.
Dus zou meschien niet werken onder cPanel.
Ik heb zelf geen cPanel dus zou het niet weten.

Wat ik vaker heb gezien bij wrapped PHP is dat de apache-specifieke functies niet meer werken.

Bijvoorbeeld een virtual - werkt die nog?

Dus bijv: <?php virtual("/test.html"); ?>

Fatal error: Call to undefined function: virtual() in /home/sites/site3/web/test.php on line 1

maar is niet erg handige functie.
Beter include() gebruiken

Hmm nadeel is wel dat die CGI versie rete sloom is ten opzichte van de CLI versie.. ding wordt elke keer het geheugen in geladen terwijl de CLI maar een keertje wordt geladen. Als je dus een druk bezocht doosje hebt gaat je dit aardig wat prestatie kosten ben ik bang..

Ik heb idd ook rumoeren gehoord over het oplossen van dit probleem in PHP5 en ben benieuwd hoe dit gaat uitpakken..

Origineel geplaatst door trancer
Hmm nadeel is wel dat die CGI versie rete sloom is ten opzichte van de CLI versie.. ding wordt elke keer het geheugen in geladen terwijl de CLI maar een keertje wordt geladen. Als je dus een druk bezocht doosje hebt gaat je dit aardig wat prestatie kosten ben ik bang..

Waarom vergelijk je het met de CLI versie en niet met de module ? Dat lijkt mij een stuk interessanter. Verder kan je mij inziens beter wat performance verlies hebben dan een minder secured systeem.

Ik heb idd ook rumoeren gehoord over het oplossen van dit probleem in PHP5 en ben benieuwd hoe dit gaat uitpakken..

Dit zou mooi zijn, echter duurt het (denk ik) nog wel een tijdje voor 5.x zal worden gereleased. Tevens vraag ik mij af hoe ze dit denken te kunnen oplossen zonder de module als aparta user te draaien wat niet mogelijk is met Apache 1.3.x. OF zouden ze PHP5 dusdanig goed werkend maken dat iedereen oook direct overgaat op Apache 2?? Dan zouden de problemen inderdaad zijn verholpen.