Nginx

ne gère pas les processus php comme le fait Apache et ne peut donc pas modifier leur environnement. De fait, il est impossible cialis online de passer directement une variable d’environnement comme on le fait dans Apache avec la directive « SetEnv ».
On serait tenté de le faire avec la directive « env » de Nginx, mais elle ne fonctionne pas de cette manière.

Alors comment faire?

Il faut utiliser les directives fastcgi_params que l’on utilise pour interpréter les fichiers PHP entre autres.

server {
listen 80;
server_name my.domain.com;
root /home/web/my.domain.com/public;
index index.html index.htm index.php;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
fastcgi_param APPLICATION_ENV "development";
}
}

Nginx permet tout un tas de choses compliquées, et notamment utiliser des server_name dynamiques contenant des variables
Voici un exemple pour

rediriger vers un sous-répertoire un sous-domaine:

server {
listen 80 default_server;

server_name ~^(?.+)\.mondomaine\.com$;
root /home/web/www/$subdomain;
index index.html index.htm index.php;
}

Grâce à cela, si votre root est /home/web/www et que vous vous rendez à l’url toto.mondomaine.com, alors le root sera automatiquement /home/web/www/toto

Magique!

On ne maîtrise pas toujours l’ensemble de son architecture, et il arrive qu’une machine serve à la fois pour le développement et la production.
Dans ces cas là, et dans la mesure ou le serveur est en production, on désactive l’affichage des erreurs

PHP dans le fichier php.ini.

Mais il existe un moyen d’activer les

logs d’erreur PHP pour un VirtualHost spécifique directement depuis la configuration du VirtualHost.
Il suffit de rajouter la ligne

php_flag display_errors On

dans la balise

On obtient une config du genre:

...
DocumentRoot....
ErrorLog...
...
php_flag display_errors On
...

Après redémarrage, les erreurs PHP s’afficheront comme par magie!

Suite à la mise à jour d'un serveur, quelle ne fut pas ma surprise de voir que les VirtualHost n'étaient plus pris en compte par Apache!!

Peur panique à 17h, j'envisage déjà la nuit blanche, les cris, les gens qui vous montrent du doigt au bureau,

le licenciement, la rue…

Et on se met à tout essayer, quitte à tout changer sur le serveur et foirer toutes les configurations. Mais au final, est-ce que ça peut vraiment être pire. On cherche, on découvre qu'on est capable de lire (survoler serait plus juste) des articles qui parlent de Apache en allemand, en japonais, en russe.

Bref, vient le moment ou l'on redémarre Apache, et ouf, le problème est réglé. Votre vision des choses change immédiatement. Ce soir, sortie entre amis, apéro, bon dîner, et plus si affinités… et plus jamais je ferai une modification de ce genre à 17h, plus jamais…. sauf qu'en fait, on fait ça tout le temps. Ca pimente les journées j'imagine, mais c'est pas volontaire

Qu'est ce qu'on peut raconter comme conneries à 18h00, mais c'est soulagé que je peux vous expliquer comment faire.

Tout d'abord le constat:

Après

mise à jour du serveur

apt-get update
apt-get dist-upgrade

et redémarrage d'Apache,

/etc/init.d/apache2 restart

et sachant bien sûr que l'on n'a absolument rien modifié entre temps,

domain.mydomain.com ne fonctionne plus. Enfin Apache tourne, puisqu'à cette URL, j'obtiens un charmant « It Works! ». Oui mais en fait, it works pas vraiment

La solution est très simple, il y a deux possibilités:

- dans

/etc/apache2/sites-available/default

Remplacer

par

Préciser le port, ça ne se fait plus dans les nouvelles versions.

Autre possibilité:

- créer et éditer le fichier

/etc/apache2/conf.d/virtual.conf

insérer dans le fichier:

 NameVirtualHost *

Redémarrer Apache

/etc/init.d/apache2 restart

Le tour est joué. ouf.