Rapid’CGI PHP, nginx et NetBSD

Tags: , , ,
3 Comments »

Il y a une foultitude de documentations sur la façon de faire tourner PHP via fastCGI sur un nginx, et à chaque fois, j’ai l’impression de lire des tambouilles copiées/collées de ci et de là. Ça cause de scripts (non portables la plupart du temps), de wrappers, et autres solutions capillotractées, et ça me plaît pas. En dépilant un peu, j’ai abouti à une solution que je trouve élégante… sous NetBSD evidemment :)

Tout d’abord, il s’agit de compiler PHP avec le support fastCGI, sans pollution avec le module CGI. Ceci est réalisé grâce au fichier /etc/mk.conf et la directive suivante:

PKG_OPTIONS.php=        -cgi fastcgi

Un make install clean plus loin, on peut s’assurer du support fastCGI d’un des binaires générés de cette façon:

$ /usr/pkg/libexec/cgi-bin/php -h|grep -i bind
  -b
|
 Bind Path for external FASTCGI Server mode

Il existe dans pkgsrc un outil spécialement dédié à gérer ce type d’implémentation, il s’agit de www/spawn-fcgi, que nous installons donc sans hésiter. spawn-fcgi a le bon goût d’être controlé par le fichier /etc/rc.conf, ainsi, après avoir copié /usr/pkg/share/examples/rc.d/spawnfcgi dans le repertoire /etc/rc.d, on configure le logiciel de cette façon:

$ grep spawn /etc/rc.conf
spawnfcgi=YES
spawnfcgi_jobs="php"
spawnfcgi_php_command="/usr/pkg/libexec/cgi-bin/php"
spawnfcgi_php_args=""
spawnfcgi_php_user="nginx"
spawnfcgi_php_address="127.0.0.1"
spawnfcgi_php_port="9000"
spawnfcgi_php_children="3"

Attention toutefois, il existe un minuscule bug dans rc.d/spawnfcgi que j’ai signalé au mainteneur, voici le patch trivial à appliquer:

--- /usr/pkg/share/examples/rc.d/spawnfcgi      2011-07-24
12:57:38.000000000 +0200
+++ /etc/rc.d/spawnfcgi 2011-07-24 17:16:49.000000000 +0200
@@ -38,6 +38,7 @@
                job_user=$(eval echo \$${name}_${job}_user)
                job_cwd=$(eval echo \$${name}_${job}_cwd)                                       job_socket=$(eval echo \$${name}_${job}_socket)
+               job_port=$(eval echo \$${name}_${job}_port)
                job_socket_mode=$(eval echo \$${name}_${job}_socket_mode)
                job_address=$(eval echo \$${name}_${job}_address)
                job_children=$(eval echo \$${name}_${job}_children)

Update bon, on est jamais mieux servi que par soi-même toussa, j’ai donc corrigé le package dans pkgsrc current. Un ptit cvs up -dP -rHEAD et tout devrait rouler.
Nous pouvons alors démarrer spawnfcgi comme n’importe quel autre service:

$ sudo /etc/rc.d/spawnfcgi start

Et de constater:

$ ps axuww|grep php
nginx     795  0.0  0.8  26412  8012 ?       Is    5:16PM  0:00.17 /usr/pkg/libexec/cgi-bin/php
nginx   18322  0.0  0.7  26412  7816 ?       Is    5:16PM  0:00.14 /usr/pkg/libexec/cgi-bin/php
nginx   22540  0.0  0.8  26412  8012 ?       Is    5:16PM  0:00.18 /usr/pkg/libexec/cgi-bin/php

Eeeeeexcellent Smithers.

Il ne reste alors plus qu’à configurer nginx pour qu’il passe à PHP en mode fastCGI les pages de script à interpréter:

        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /home/user/www$fastcgi_script_name;
            include        /usr/pkg/etc/nginx/fastcgi_params;
        }

Il faudra evidemment prendre soin de remplacer /home/user/www par le chemin de votre documentroot. Il doit d’ailleurs certainement y avoir une variable pour s’épargner cela…

On oublie pas le petit phpinfo() qui va bien:

Notice iconv() [function.iconv] Wrong charset

Tags: , ,
2 Comments »

Aaaah les charsets, décidemment, c’est ce que je préfère. Alors que j’étais en train de mettre en place une usine à gaz en PHP (remarquez l’effet de style), je ne fus que très peu surpris d’être confronté à l’erreur suivante :

Notice: iconv() [function.iconv]: Wrong charset, conversion from `UTF-8' to `UTF-8//IGNORE' is not allowed

blaaaaa bla bla bla.

La plateforme est NetBSD 5.0.1, et les packages PHP issus des builds binaires, installés avec vous savez quoi. Et c’est là où le bât blesse. En effet, php5-iconv, dans sa version binaire, est compilé avec la version builtin de la libiconv, et pour une raison que je n’ai absolument pas envie de creuser, cette version là produit l’erreur sus-citée. La solution est assez simple, il suffit d’ajouter à son /etc/mk.conf la directive suivante :

USE_BUILTIN.iconv=      no

Et de se fendre d’un make package clean dans pkgsrc/converters/php-iconv.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Performance Optimization WordPress Plugins by W3 EDGE