PDA

Bekijk Volledige Versie : suPHP installeren



SebastiaanStok
14/06/05, 15:27
Na lang zoeken had ik dan eindelijk de op lossing voor mijn chmod rechten probleem.

Standaart draait alles onder www, maar dat moest per gebruiker worden :)

Nu ben ik dan achter suPHP gekomen :cool:
En zo als gewoonlijk...

Gaat het weer helemaal fout :mad:
Ik heb hem ginstalleerd, geprobeerd.

En dan werk php conpleet niet meer, ik kwam er achter dat php verkeerd stond opgegeven.
Dus verandert, opnieuw ge installeerd.

Apache gerestart, nog niets :huh:

Kan iemand mij als je blieft uit de brand helpen, ik heb apache2 met monteel mod_php5 op RedHat Linux.

Ik heb de laaste versie van suphp gebruikt.

bij httpd.conf staat dit:


#LoadModule php5_module modules/libphp5.so
LoadModule suphp_module modules/mod_suphp.so

AddHandler x-httpd-php .php

#AddType application/x-httpd-php .php
#AddType application/x-httpd-php .php4
#AddType application/x-httpd-php .php3
#AddType application/x-httpd-php-source .phps
#AddType application/x-httpd-php .phtml

#suPHP_Engine on

#


En in de test virtualhost staat dit.



<VirtualHost *:80>

# suPHPP-settings
suPHP_Engine on
suPHP_UserGroup rollerscapes www

DocumentRoot /data/htdocs/rollerscapes/public_html/rollerscapes
ServerName www.rollerscapes.net
<Directory "/data/htdocs/rollerscapes/public_html/rollerscapes">
allow from all
Options all
</Directory>


In dit staat er in /e t c/suphp.conf
[code]
[global]
;Path to logfile
logfile=/var/log/suphp.log

;Loglevel
loglevel=info

;User Apache is running as
webserver_user=www

;Path all scripts have to be in
docroot=/htdocs

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=false

;Send minor error messages to browser
errors_to_browser=true

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0077

; Minimum UID
min_uid=100

; Minimum GID
min_gid=100


[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/local/bin/php

;Handler for CGI-scripts
x-suphp-cgi=execute:!self
[code]

Als ik het zo als ik boven heb aan gegeven draait, werk php conpleet niet meer :X


Als iemand weet wat ik fout doet, hoor ik het graag.

XBL
14/06/05, 15:49
Krijg je errors in je suphp.log? Parsed PHP totaal niet (en krijg je het bestand te downloaden aangeboden, bijv)?

Wat krijg je als je /usr/local/bin/php -v uitvoerd? Heb je de CLI of de CGI versie geïnstalleerd? Het moet namelijk de CGI versie zijn.

Hierdoor een beschrijving (in het Engels) zoals ik het ooit heb uitgelegd aan iemand anders op het DirectAdmin forum. Bij hem werkte het, maar ik weet niet of bij jou de installatie fout is gegaan. Het gedeelte waarin de CLI vesie terug wordt gekopieerd hoef je mogelijk niet te doen, tenzij er programma's de CLI versie nodig hebben.


I can't give you a very detailed explanation, but this will probably point you in the right direction.

First, copy the php bin to php.cli. Next compile a new version of php (get the source from php.net/downloads.php) and compile it with the following option: "--enable-force-cgi-redirect" and remove the following option: "--with-apxs".

You can test if the version is cgi, by running /usr/local/bin/php -v (it will output something like:
PHP 5.0.4 (cgi) (built: May 7 2005 10:27:01)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v2.0.4-dev, Copyright (c) 1998-2004 Zend Technologies
)

The version seems to be compiled correct as cgi, so move it to '/usr/local/bin/php.cgi' and move '/usr/local/bin/php.cli' back to '/usr/local/bin/php' so DirectAdmin (which needs a CLI version) has the correct version.

Now we can compile suPHP with the new php binary, use any of the options specified here: http://suphp.org/Documentation-Installation.en.html. And use --with-php=/usr/local/bin/php.cgi, instead of the default one (which will default to /usr/bin/php). Don't use the cli version (/usr/local/bin/php), which won't work (suPHP requires a cgi version).

Everything should be working now (at least suPHP should compile), if you have problems, check the suPHP error log (you can specify where to save it with '--with-logfile'. I set it to /etc/httpd/logs
/suphp.log).

Good luck!

Jochem

Hopelijk werkt het hiermee, anders zit de fout waarschijnlijk niet in de installatie.

Jochem

SebastiaanStok
14/06/05, 15:54
Hij parsed niet en hij word te download aan geboden, soms dan.

Soms krijg ik ook alleen de text, zonder download.

Ik heb inderdaat de CLI versie, dat zal mijn probleem wel zijn.

Ik maak ook gebruik van php op command-line, moet ik hier voor CLI versie houden of kan ik daar ook de CGI versie voor gebruiken ?

SebastiaanStok
14/06/05, 16:17
Nu word ik gek :mad:

PHP opnieuw geinstalleerd (CGI).
suPHP opnieuw geinstalleerd, en nog niets :huh:

Ps: ik heb hem zo geconfiguereerd:

./configure --with-php=/usr/local/bin/php --with-apache-user=www --with-apxs=/data/apache2/bin/apxs --with-setid-mode=paranoid --with-logfile=/var/log/suphp.log

Triloxigen
14/06/05, 16:29
Ik las niet zo gek lang gelden in een topic dat suPHP de load van de server dramatisch verhoogt.

SebastiaanStok
14/06/05, 16:38
En wat moet ik dan in plaat daar van gebruiken :)

Dat het wel onder aparte gebruikers vald ?

Ps: load is monteel geen probleem, procesor komt niet eens tot 01.00.00.00 :D


Edit: kennelijk gebruikt plesk zelf, suexec

The MAzTER
14/06/05, 17:14
Origineel geplaatst door Triloxigen
Ik las niet zo gek lang gelden in een topic dat suPHP de load van de server dramatisch verhoogt.

0.6 is helemaal herschreven en zou een stuk minder load moeten veroorzaken.

al moet ik wel toegeven dat ik van 0.5.2 nooit last ondervonden heb.

@Rollerscapes gebruik de search eens.

wdv
14/06/05, 17:20
Het zal nog steeds zo zijn dat suPHP steeds nieuwe PHP processen moet forken wat nu eenmaal de load een stuk omhoog gooit.

SebastiaanStok
14/06/05, 17:37
Ik heb de search gebruikt, maar dit probleem komt zeer wijnig voor :(

SebastiaanStok
14/06/05, 17:45
Kan het zijn dat mijn apache niet goed is ingesteld ?

./configure --enable-so --enable-ssl --enable-shared=max --prefix=/data/apache2

wv-
14/06/05, 18:59
fast-cgi in combinatie gebruiken als je last hebt van teveel forks (dus resources).

SebastiaanStok
14/06/05, 19:44
Dat is niet de oplossing voor mijn probleem :)

SebastiaanStok
14/06/05, 20:03
Volgens mij heb ik de oplossign :)

Moet ik nog wel proberen, morgen :p

XBL
14/06/05, 21:55
Wel vertellen wat je gedaan hebt, hè!

@ Trixoligen: Niet dramatisch. Hij moet nu voor elke keer dat een script uitgevoerd moet worden een apart proces beginnen, dit zou je moeten merken op de load. Wij hebben er nauwelijks iets van gemerkt en de load stijging die we in de loop van de tijd ondervinden kan ook liggen aan het groeiende aantal gebruikers.

Daarnaast denk ik dat dat kleine nadeel (want het is niet zo dramatisch) niet opweegt tegen de voordelen: Je weet wat er gebeurd op je server en je klanten hebben er nooit last van dat een bestand of map door apache bezeten wordt (wat soms het geval is en dan komen ze weer klagen bij ons dat een bestand niet verwijderd wilt worden).

Jochem

SebastiaanStok
15/06/05, 14:45
Ik heb geprobeerd

AddHandler x-httpd-php .php

te veranderen naar

AddHandler x-httpd-php-cgi .php

Helaas werk dit nog steeds niet :(

Kan het zijn dat de config-file van op de verkeerde gebruiker staat(root) ?

Als dit niet werk ga ik aan de slach met suExec :(

Dillard
15/06/05, 15:11
Hoe staat het met je rechten op de PHP bestanden ?

a) Wie is nu de eigenaar ?
b) Hebben group en world niet teveel rechten (zie kopje security options in /etc/suphp.conf en vergelijk deze met je files)

SebastiaanStok
15/06/05, 15:15
De bestanden staan onder rollerscaps:www

En zijn zo ingesteld:
Bestanden: 644
Dirs: 755

De /etc/suphp.conf kan je hier boven terug vinden :)

Ps: die heb ik nu op de gebruiker www:www gezet met 644

Dillard
15/06/05, 15:23
En wat zijn de UID en GID van rollerscaps en www ?

SebastiaanStok
15/06/05, 15:35
uid=500(rollerscapes) gid=500(rollerscapes) groepen=500(rollerscapes),506(www)

uid=504(www) gid=506(www) groepen=506(www),500(rollerscapes)

Met deze configure:

./configure
--with-php=/usr/local/bin/php --with-apache-user=www --with-apxs=/data/apache2/bin/apxs --with-setid-mode=paranoid --with-logfile=/var/log/suphp.log

De php locatie is goed :)
Nog sugestich ?

Zelfs zonder de gebruiker een group werkt het nog steeds niet...

SebastiaanStok
15/06/05, 15:44
Volgens mij staat het config file verkeerd

Dit zag ik tijden het conpileren: clean-DOPT_CONFIGFILE=\"/usr/local/etc/suphp.conf\"

Edit: nope nog steeds niet :(

SebastiaanStok
15/06/05, 16:00
Het is het eigenlijk zo dat je met suphp niet de php script moet draaien in cgi-bin of zo iets :huh:


Edit: ik heb nu deze geprobeerd, nog niets :mad:

http://www.pookey.co.uk/wiki/php/suphp_mod_php

XBL
15/06/05, 16:20
Het script zou een Internal Server Error moeten geven indien de rechten niet correct waren. Op dit moment lijkt het er op dat handler/mime type gewoon niet gepakt wordt.

Plaats deze eens binnen de virtualhost, wij doen dit ook, omdat ik (meen) het niet werkte als je dit plaatst in de httpd.conf zelf.

Jochem

SebastiaanStok
15/06/05, 16:24
Nee werk nog niet :(

Ik zelf het gehele system in de virtuelhost gezet, en nog werkt het niet :eek:



LoadModule suphp_module modules/mod_suphp.so
LoadModule php5_module modules/libphp5.so
AddType application/x-httpd-php .php
AddType application/x-httpd-php-source .phps
AddHandler x-httpd-php .php
suPHP_Engine on
php_admin_flag engine off

SebastiaanStok
15/06/05, 19:39
Nou als iemand iets kan geven wat ZEKERWETEN werkt ben ik heel blij wand ik geef het op :(

Morgen maar apache2 updaten en dan gelijk kijken of SuExec wel aan me ijsen voldoet.

wv-
15/06/05, 19:53
laat iemand er naar kijken? huur desnoods iemand :)

SebastiaanStok
15/06/05, 20:55
Huuren lijkt mij te duur :(

Heb jij mischien tijd om dit te doen via de msn ?


Maar wat ik me af vraag, het zou zo simpel moeten zijn en het werkt niet :huh:

Ik ga morgen even een conpleet nieuwe versie van apache2 installeren en hier dan mee testen.

Wat monteel gebreurd dit real-life :X

mind
16/06/05, 01:27
Ik denk dat ik de oplossing heb voor jou probleem :D
PHP is standaard niet aan een handler gekoppeld vanaf versie 0.6.0 Je MOET in je VirtualHost sectie dus een suPHP_Addhandeler opnemen. Dit is reuze handig omdat je nu per extensie, per dir en per host kan bepalen welke php versie er gebruikt wordt.

Een voorbeeldje van mijn config:

<VirtualHost *:80>
SuexecUserGroup bla bla
AddType x-httpd-php .php
suPHP_Engine on
suPHP_UserGroup bla bla
ServerAdmin root@localhost
DocumentRoot /home/bla
<Directory "/home/bla">
suPHP_Addhandler x-httpd-php
</Directory>
ServerName test.monshouwer.com
ErrorLog /home/bla/test.internal.lan-error_log
CustomLog /home/bla/test.internal.lan-access_log common
</VirtualHost>

Ps. Door een bug in apache moet de dir van het php script leesbaar zijn voor de webserver. De laadste apr versie (CVS) fixt dit...

Mvgr,

Kees

Drunk
16/06/05, 02:09
Je kunt (als je nog Apache 1.3.x gebruikt) ook eens naar de mogelijkheden van mod_suid i.c.m RSBAC kernels kijken, dit werkt bij ons als een zonnetje terwijl suPHP niet wilde wat ik wil :p.
RSBAC is een kernel module met authenticatie zoals dit in openBSD is geregeld dus dit maakt het gebruik van mod_suid wel veilig (moet je wel de posix funcites van PHP weg laten (--disable-posix -> maar dat is al algemeen bekend ...)). Helaas heb ik nog geen goed/stabiel alternatief gevonden voor mod_suid en Apache2, de oplossing is nog niet gevonden maar er wordt aan gewerkt.

SebastiaanStok
16/06/05, 10:46
Omg :eek: Het werkt :D

Einelijk :W:


Zoon ongelovelijk hartelijk bedankt :cool:

Wel vreemd dat dit in de documetie staat :rolleyes:

suPHP_Addhandler had ik al gezien in de C++ source van mod_suphp.c maar ik snapte het niet :)


Ik krijg nu alleen een 500 error, dat komt omtdat het buiten de document-root staat :)
Maar dat zo weer gefixt.

Edit: het wat jammer dat ik niet zo smylies mag gebruiken.

SebastiaanStok
16/06/05, 10:59
Oke ben verder gekomen :)

Maar om de een of andere reden krijg ik altijd een 500 error :)

Dit staat er in /var/log/suphp.log


..


En dit is ingesteld bij /e tc/suphp.conf


..



Edit: ik had de <directory> niet goed staan :)

Dillard
16/06/05, 11:29
Vraagje: moet dit per virtual host worden ingesteld of kun je dit in de default zetten? Anders zit je met een control panel als Plesk of Cpanel mooi in de problemen omdat deze zelf de httpd.conf opbouwt.

SebastiaanStok
16/06/05, 11:30
Kan je het niet gewoon uit proberen :)

Maar zelf denk dat je het per virtual host moet instellen.

Darom maak ik altijd alles zelf :)

SebastiaanStok
16/06/05, 12:24
Oke ik zit nu nog met 1 probleem, als ik iets upload dan krijgt deze standaart chmod 0600

Maar dan kan apache er niets meer mee, ik kan het wel via chmod() op lossen, maar dit moet neem ik aan anders kunen ?

Triloxigen
16/06/05, 12:27
Nee, waarom zou dat anders moeten kunnen?
Dat is net het idee erachter :p

SebastiaanStok
16/06/05, 12:29
Omdat apache minimaal group lees rechten moet hebben anders krijg ik een 403 error :)

De andere gebruikers kunnen er niets meer mee, omdat de gebruiker niet over een komt.

Triloxigen
16/06/05, 13:51
Ja.. maar ik snap het probleem nog niet zo..

SebastiaanStok
16/06/05, 20:56
Ik ben er achter gekomen dat ik dit kan doen met umask

Apache geeft nu als ik het bestand geen group rechten heeft een 403 error.

SebastiaanStok
17/06/05, 11:13
Hij staat op parinode dus hij moet van die gebruiker een group zijn die ik heb op gegeven.

Dus apache lees rechten kan geen kwaat.