php & phpinfo / imap

[WH-Tim]

Ik heb hier een zeer raar verschijnsel. In de shell geeft php andere modules en versies aan dan de phpinfo(); ..

In de shell:

# php -v
PHP 4.3.9 (cli) (built: Dec 16 2004 12:07:01)
Copyright (c) 1997-2004 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies

#php -m
[PHP Modules]
bcmath
calendar
ctype
curl
ftp
gd
gettext
imap
mcrypt
mhash
mysql
openssl
overload
pcre
posix
session
sockets
standard
tokenizer
xml
zip
zlib

[Zend Modules]

Terwijl als ik phpinfo(); doe krijg ik dit:

PHP Version 4.3.4

'./configure' '--enable-force-cgi-redirect' '--enable-cgi' '--with-curl' '--with-curl-dir=/usr/local/lib' '--with-gd' '--with-gd-dir=/usr/local/lib' '--with-gettext' '--with-jpeg-dir=/usr/local/lib' '--with-kerberos' '--with-mcrypt' '--with-mysql' '--with-pear' '--with-png-dir=/usr/local/lib' '--with-xml' '--with-zlib' '--with-zlib-dir=/usr/local/lib' '--enable-bcmath' '--enable-calendar' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--enable-track-vars'

Imap weg.. en de versie is opeens anders. De imap applicaties draaien overigens ook niet, terwijl imap WEL draait en is meecompiled.

# netstat -an | grep 143
tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN

Iemand een idee wat hier aan de hand kan zijn?

[PeterT]

Het mag duidelijk zijn dat Apache (of je webserver) een andere PHP versie gebruikt.
Ik zie ook dat je niet --with-apxs=/usr/local/apache/bin/apxs (of evt. andere locatie van apache) hebt gebruikt bij je php compilatie.. is wel handig op zich

[WH-Tim]

Kan aan mij liggen, maar het leek mij tot vandaag nogal vrij normaal dat er maar 1 phpversie draait op de server. Indien mijn apache op 3.4.3 ingesteld staat, wat volgensmij ook zo is, kan dit dan niet veranderd worden dat deze gewoon de goede versie pakt, de standalone compiled 3.4.9?

[PeterT]

Als je de standalone goed compiled wordt deze automatisch door Apache opgepakt.

[tino]

Doe op de server eens een locate php.
Ik weet zeker dat er meerdere op staan. Misschien één die standaard bij OS geleverd wordt en ééntje van source gecompileerd?

Tino

[WH-Tim]

Klopt, dit komt doordat ik suphp aan het installeren ben geweest. Momenteel bestaan er:

php
php.CGI
php.CLI

Maar dit is een vrij normale installatie van suphp, zo met deze bestanden. Kan ik niet ergens opgeven welke hij als standaard moet pakken?

/edit:

Heb inderdaad nog een source installatie gevonden, zal even de rotzooi opruimen en opnieuw testen.

[PeterT]

Ik zou gewoon even opnieuw compilen, kan je meteen php 4.3.10 erop zetten

[WH-Tim]

suPHP kan het goed verkloten als je er nog niet eerder mee gewerkt hebt :x

Goed dat het nog een server in aanbouw is, anders waren er al veel boze mails binnengekomen vandaag

[PeterT]

suPHP is sowieso niet iets dat ik snel op een produktie server zou zetten..

[WH-Tim]

Lijkt mij wel een stuk veiliger... Het OS is dan wel goed beveiligd met rechten en groepen, open_basedir per virtualhost en nog paar andere dingen, maar als je alles onder de user zelf kunt laten draaien lijkt mij dit toch de ultieme oplossing.

[WH-Tim]

Pfieuw, apache+php draait weer (sinds vanmiddag eigenlijk al ) alleen die suphp nog goed configureren of eraf knallen. Wat zou jij als alternatief bieden PeterT als ik vragen mag, of laat jij het liever gewoon helemaal weg?

[TSG-Hans]

Origineel geplaatst door WH-Tim
Lijkt mij wel een stuk veiliger... Het OS is dan wel goed beveiligd met rechten en groepen, open_basedir per virtualhost en nog paar andere dingen, maar als je alles onder de user zelf kunt laten draaien lijkt mij dit toch de ultieme oplossing.

open_basedir en suphp gaan niet samen.

Ik raad jou af suphp op een productie server " te knallen", omdat jou vragen hierboven aantonen dat jij het verschil niet begrijpt tussen php-cli en php-cgi. Bovendien zet je met een onjuiste configuratie van php-cgi en suphp meer open dan dicht. Ga eerst eens uitgebreid "spelen" met suphp

[WH-Tim]

Klopt, is me nog steeds niet duidelijk Ik haal hem inderdaad eerst weer even eraf aangezien het op het moment geen zin heeft. Bedankt voor de tip in regel 1

[wv-]

tip voor in productie:

Je kan je huidige php, die gecompileerd is als module, in apache laten zitten. Je zet in je config dan een 2e handler voor de nieuwe php, bvb voor .phptest files. Eenmaal je uitgebreid getest hebt met .phptest files, kan je .phptest veranderen naar .php

[PeterT]

Origineel geplaatst door WH-Tim
Wat zou jij als alternatief bieden PeterT als ik vragen mag, of laat jij het liever gewoon helemaal weg?

Geen van beide eigenlijk.
Simpelweg een aantal utilities root/wheel only maken en je bent redelijk veilig.
Nooit 100%, maar er zijn gewoon scripts die niet werken met suPHP / open base dir