Compilation des sources PHP : extensions, threads MPM

Bonjour,

Juste quelques questions simples à ce stade, j'en aurai probablement plus un peu plus tard.

Avant je faisais du php sous windows, là je suis passé sous Linux. Pour installer je vais donc compiler les sources

1) Si je compile php sans activer aucune extension lors de l'appel de ./configure, est-ce que je pourrai tout simplement les activer après la compilation en allant décommenter les lignes du php.ini et en pointant dessus avec la variable PHPRC?

Ou bien, est-ce que toute option qui n'a pas été configurée lors de la compilation devient par la suite inaccessible (à moins de recompiler bien sûr)? Dans ce cas de figure, y a t'il un avantage significatif (en termes de performances) à ne pas activer tout ce qu'on peut activer avant la compilation?

Le truc c'est qu'il y a des tas de choses dont je ne soupçonnais pas l'existence lors de ma première prise en main de php sous windows et que j'ai découvertes (et activées) plus tard en me baladant dans la documentation.

(sous windows je ne compilais pas les sources, tout simplement je décompressais le programme, ses librairies et autres fichiers annexes dans les répertoires de mon choix. Mais sous Linux à première vue seule la compilation des sources est détaillée par le manuel. Bon de toutes façons ça me tente bien de le faire comme ça, même si je pense qu'une installation "manuelle" comme sous windows ou à partir d'aptitude serait possible.)

Pour ce qui est de cette question, je pourrai au pire faire des tests moi-même, mais il y a un autre point plus important que j'aurais besoin qu'on m'éclaircisse:

2) J'ai lu le message d'avertissement en haut sur cette page:

http://fr.php.net/manual/fr/install.unix.apache2.php

A un autre endroit ils disent même que ce genre de situation est moins bien géré sous Linux que sous Windows.

Ma question: si je suis sous Debian etch avec un processeur Intel Core duo et un serveur Apache2, est-ce que je suis concerné par cette histoire de threads MPM?

Et puis au fait, c'est quoi un thread MPM?

Si tu es sous debian etch.. ne compile pas a partir des sources, installe avec apt-get ou aptitude !

J'install toute ma machine avec aptitude sauf le trio apache/php/mysql (et peut-être me kernel si un jour je m'amuse à le recompiler).

Plusieurs raisons à cela:

1) j'aime bidouiller ces 3 programmes, c'est mon petit plaisir.
2) je veux contrôler les répertoires d'installation, en particulier pour que tous les fichiers de mon serveur et de mon site se trouvent dans la partition /home, ce qui me permet de ne pas y toucher lorsque j'effectue la réinstallation de l'OS, du noyau et/ou de toutes mes autres applis.
3) je veux qu'Apache et MySQL ne tournent pas en root (bon, sur ce point, probable que j'y arriverais aussi avec des paquets aptitude).
4) je souhaite garder la liberté de choisir la version que je veux pour ces trois programmes, donc:
4a) y compris installer des versions pas encore packagées par l'équipe Debian, voire encore des sources non-encore disponibles en version précompilée.
4b) pour tous mes autres paquets, je continuerai à me servir d'aptitude upgrade sans m'ennuyer à définir des cas particuliers d'une quelconque sorte dans les commandes de la famille apt (au cas où je souhaite rester sur une version plus ancienne d'apache, php ou MySQL).
5) je veux un serveur/site de prod et un serveur/site de développement entièrement séparés.

Bref pour moi le choix serait plutôt à faire entre des sources précompilées ou des sources brutes. Aptitude ne me donnera de toutes façons pas la flexibilité que je souhaite.

Moi ce que j'en dis..
Mais alors sous debian, tu risques d'avoir des conflits en faisant ca..
Oriente toi plutot vers une distrib orientée source.. slackware.. ?

ton 1/.. ca je ne peux rien y dire
2/ Tu peux bidouiller tous les fichiers de conf, repertoires et autres meme en ayant installé par apt-get ou aptitude.. Donc par exemple definir que tes sites soient dans /home/
3/ Apache tourne sous l'utilisateur www-data et mysql sous l'utilisateur mysql
4/ pour un serveur de prod, vaut mieux rester avec des versions approuvées comme etant stables..
5/ quel que soit la distrib et la methode d'installation, tu as cette fonctionnalité


Enfin.. desole si mes reponses semblent hors sujet.. mais c'est vrai que la gestion de serveur sous debian.. c'est quand meme un sacré avantage par rapport aux systemes d'il ya 10 ans ou tout se faisait a partir des sources..

2) Exact, par contre il y a quelques trucs que tu ne peux définir qu'à la compilation. Sous mysql par exemple, lier statiquement ou dynamiquement les librairies, supporter uniquement certains jeux de caractères multibytes à l'exclusion de tous les autres, etc. Dans ces cas précis c'est une question de performances.

3) Sur Apache il y a la directive de configuration User. Sur mysql il y a l'option de compilation --with-mysqld-user et si on est passé à côté il y a une option --user sur le script mysql_install_db qui permet de contourner le problème si on a oublié.

Par ailleurs, aussi bien pour apache que pour le serveur de BdD, il y a aussi moyen de ne rien lancer du tout en root, y compris la partie du daemon qui est censée tourner en root. Je pense que la manipe serait possible également pour des installations dans /usr, mais ici ce n'est pas ce qui nous intéresse, parce que bon sang je viens d'avoir une idée. Je me rends compte que tout ça fait que dans des conditions normales, rien n'empèche un utilisateur non-root sur un système lambda d'installer un serveur Apache/php/MySQL dans son home. Comme il ne peut pas écouter le port 80, il n'a qu'à utiliser l'option Port 80 redirect offerte par no-ip; sur leur site ils disent que c'est pour contrer les ISPs qui font chier, mais il en ressort que la possibilité qu'ils offrent pourrait aussi bien être utilisée à l'encontre d'un sysadmin récalcitrant.

J'avais entendu effectivement ces histoires sur des types qui installent un serveur sur les machines de leur boîte à l'insu du service info, je n'y croyais pas tellement mais là je vois bien que c'est possible.

Je sais pas ce que ça donnerait une manipe équivalente pour windows (monter un serveur sur un poste dont on est pas administrateur). Peut-être bien que c'est possible aussi, mais comme l'OS est propriétaire le plan est plus dur à échafauder.

4) Oui. Mais juste à titre de remarque, Debian est connu pour attendre longtemps avant de proposer les nouvelles versions des paquets, souvent bien après que les développeurs les considèrent comme stables. A titre d'exemple: http://fr.php.net/manual/fr/install.unix.debian.php. En termes de politique globale, je suppose que leur réputation de stabilité est à ce prix. Mais si pour un logiciel en particulier on veut upgrader tout de suite vers la toute nouvelle release stable, il faut le faire manuellement.

5) C'est intéressant. Comment on fait? Je suppose que c'est un paquet spécial qui va s'installer ailleurs.

Au fait, concernant mes questions du début, j'ai trouvé la réponse à 1), mais pour ce qui est de 2) je ne sais toujours pas.

Citation:

---

Envoyé par Lancelot du Lac

Au fait, concernant mes questions du début, j'ai trouvé la réponse à 1), mais pour ce qui est de 2) je ne sais toujours pas.

---

Salut

Ce point de détail ne posera plus aucun problème à partir de PHP 5.3 (si j'ai bien tout suivi, mais parfois je rate un détail) puisque PHP a changé de parseur. PHP 5.3 n'utilise plus bison mais re2c, qui est thread-safe d'origine. Je te fais un raccourci car je n'en maîtrise pas tous les détails (je ne suis pas développeur core), mais tu peux chercher dans les archives d'internals@ pour plus d'infos ;)

J'ai rien trouvé sur le sujet dans les archives d'internal.

Merci pour le tuyau sur php5.3, c'est une bonne nouvelle.

Ceci dit je ne sais toujours pas si je suis concerné par le problème, qui apparement se pose aussi sur MySQL, puisqu'il y a une option pour compiler une version "thread safe."

C'est bien connu que les serveurs apache crèe des threads, de même c'est le mode de fonctionnement de Linux je crois (chaque processus a un processus parent, et les "fils" de processus remontent tous jusqu'à init).

Mais bon, ce serait dommage de faire régresser le fonctionnement de mon serveur avec le module MPM s'il n'y a pas nécessité.