Installation et test de NGinx sous Ubuntu

NGinx est une des alternative au serveur Web Apache (il est actuellement utilisé par plus de 6% des serveurs Web). Il se targue d'être plus rapide, plus léger et facile à configurer.

Nous allons vérifier tout cela dans ce billet en détaillant une installation de NGinx 0.8.54 (Stable) sur une machine GNU/Linux (Ubuntu Desktop 10.10) avec en bonus le support FastCGI de PHP et de Perl !

Installation de NGinx

On commence par ajouter le dépôt officiel pour la version stable:

sudo add-apt-repository ppa:nginx/stable

sudo aptitude update

Puis on installe la bête (facile non ?):

sudo aptitude install nginx

Remarque: si un serveur Web (Apache ou autre) tourne déjà sur votre machine, l'installation de NGinx se passera normalement, par contre il n'arrivera pas à se lancer car le port HTTP par défaut (TCP/80) sera déjà occupé. La solution la plus propre est de configurer NGinx pour qu'il écoute sur un autre port (TCP/81 par exemple) puis faire vos tests en forcant l'utilisation de ce port dans votre navigateur Internet (en ajoutant :81 aux URL). Une fois Nginx validé, il suffira de supprimer l'autre serveur Web de votre machine, puis de reconfigurer Nginx sur le port par défaut (TCP/80).

Premier contact avec NGinx

Un script de démarrage nommé nginx a été installé dans le répertoire /etc/init.d. On peut voir la liste des commandes accepté par ce script en saisissant la ligne de commande suivante:

sudo service nginx

Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}

On va donc activer la configuration de test:

sudo service nginx configtest

Testing nginx configuration: nginx.

Puis lancer le serveur:

sudo service nginx start

Starting nginx: nginx.

On ouvre un navigateur sur la même machine puis on entre l'UTL suivante: http://localhost/

La page suivante devrait s'afficher:

On peut ensuite arrêter le serveur:

sudo service nginx stop

Stopping nginx: nginx.

Puis passer à l'étape suivante...

Configuration du serveur NGinx

Les fichiers de configuration se trouvent dans le répertoire /etc/nginx. Les habitués d'Apache ne seront pas trop perturbés par la structure de l'arborescence de ce répertoire:

 

drwxr-xr-x 2 root root 4096 2011-01-05 08:26 conf.d/

-rw-r--r-- 1 root root 884 2011-01-05 08:04 fastcgi_params

-rw-r--r-- 1 root root 2258 2011-01-05 08:04 koi-utf

-rw-r--r-- 1 root root 1805 2011-01-05 08:04 koi-win

-rw-r--r-- 1 root root 2066 2011-01-05 08:04 mime.types

-rw-r--r-- 1 root root 1340 2011-01-05 08:04 nginx.conf

-rw-r--r-- 1 root root 465 2011-01-05 08:04 scgi_params

drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-available/

drwxr-xr-x 2 root root 4096 2011-01-05 10:36 sites-enabled/

-rw-r--r-- 1 root root 497 2011-01-05 08:04 uwsgi_params

-rw-r--r-- 1 root root 3071 2011-01-05 08:04 win-utf

On y retrouve (entre autres):

  • nginx.conf: le fichier de configuration central
  • conf.d/: un répertoire contenant des fichiers de configuration additionnels
  • sites-available/: répertoire contenant la liste des fichier de configuration des sites disponibles
  • sites-enabled/: répertoire contenant la liste des fichiers de configuration des sites actifs (liens symboliques vers le répertoire site-availables)

On commence par jeter un coups d'oeil au fichier nginx.conf.... Quel bonheur par rapport à celui d'Apache :).

On passe ensuite au fichier du site par défaut /etc/nginx/sites-available/default (que l'on a activé tout à l'heure par la commande 'sudo service nginx configtest'):

server {

listen 80

 

root /usr/share/nginx/www;

index index.html index.htm;

 

server_name localhost;

 

location / {

try_files $uri $uri/ /index.html;

}

 

location /doc {

root /usr/share;

autoindex on;

allow 127.0.0.1;

deny all;

}

 

location /images {

root /usr/share;

autoindex off;

}

 

}

On peut donc voir que l'on a un site qui écoute sur le port TCP/80 (listen   80) et sert les pages se trouvant dans le répertoire /usr/share/nginx/www (root /usr/share/nginx/www) à partir de l'URL http://localhost/ (server_name localhost).

Nous allons nous baser sur cet exemple pour construire un nouveau fichier de configuration propre à nos besoins.

On commence par créer l'arborescence qui va héberger nos pages (par exemple /home/labo/www). Si le répertoire n'existe pas il faut le créer et lui donner les bons droits:

mkdir /home/labo/www

Enfin on édite une page de test:

# vi /home/labo/www/index.html

<html><body>Ma page</body></html>

Ensuite on passe à la création du fichier de configuration du site.

sudo vi /etc/nginx/sites-available/monsite

Avec le contenu suivant (à adapter à votre configuration):

# Mon site a moi

 

server {

listen 80;

 

root /home/labo/www;

index index.html index.htm;

 

server_name localhost;

 

location / {

# First attempt to serve request as file, then

# as directory, then fall back to index.html

try_files $uri $uri/ /index.html;

}

 

}

On supprime le site par defaut et on active le notre:

cd /etc/nginx/sites-enabled

sudo rm default

sudo ln -s ../sites-available/monsite

On redémarre le serveur Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Puis  on teste la page: http://localhost/

Pour rendre le site "visible depuis l'extérieur", il faut changer la ligne:

server_name localhost;

Puis la remplacer par:

server_name www.mondomaine.com;

Il faut bien sur que le nom www.mondomaine.com pointe sur l'adresse IP de votre serveur Nginx...

Test des performances

Pour voir ce qu'il a dans le ventre, j'ai installé en Nginx et Apache sur ma machine. Nginx écoutant sur le port TCP/81 et Apache sur le port TCP/80.

J'ai ensuite utilisé le logiciel httperf (disponible dans les dépôts Ubuntu) pour simuler des requêtes sur le serveur.

Test du serveur Apache:

# httperf --client=0/1 --server=localhost --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=5000 --num-calls=10

Request rate: 4284.8 req/s (0.2 ms/req)

Puis test du serveur NGinx:

# httperf --client=0/1 --server=localhost --port=81 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=5000 --num-calls=10

Request rate: 6332.6 req/s (0.2 ms/req)

On a donc un gain d'environ 30% en terme de requêtes supportées par le serveur.

 

 

Request rate / Request number

 

Support du PHP

De nos jours, un serveur Web sans support PHP c'est un peu comme un Ferrari avec des roues de 13 pouces. Dans l'optique d'avoir un serveur performant nous allons donc utiliser le module externe PHP FPM (PHP FastCGI) qui s'occupera de l'exécution des scripts PHP dans un processus indépendant de NGinx (merci à cet article qui m'a bien aidé).

On commence par installer le module:

sudo add-apt-repository ppa:brianmercer/php

sudo aptitude update && sudo aptitude install php5-fpm

Par défaut, le processus PHP-FPM va se mettre en écoute sur le port TCP/9000 et écouté les requêtes venant seulement de la machine locale (localhost).

Il ne reste plus qu'à modifier le fichier de configuration de votre site pour prendre en compte le langage PHP (fichier /etc/nginx/sites-available/monsite):

# Mon site a moi

server {

listen 80;

server_name localhost;

root /home/labo/www;

 

location / {

index index.php index.html;

}

 

location ~ .php$ {

fastcgi_pass 127.0.0.1:9000;

include /etc/nginx/fastcgi_params;

fastcgi_index index.php;

}

}

Attention de bien avoir configurer la variable root ("root /home/labo/www" dans mon exemple), sinon vous risquez de tomber sur une erreur 404 lors du passage du script PHP vers le process PHP-FPM.

On relance ensuite Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Pour tester que le PHP fonctionne bien, le plus simple est de créer un fichier info.php (à mettre à la racine du site /home/labo/www/) contenant:

<?php

phpinfo();

?>

Puis de pointer votre navigateur Web vers l'URL: http://localhost/info.php

La page suivante devrait s'afficher:

Support de Perl

Tout comme PHP, nous allons utiliser FastCGI pour exécuter les scripts Perl depuis notre serveur NGinx. Le principe est le même. Un processus (fastcgi-wrapper.pl) va se mettre en écoute sur le port TCP/8999 puis attendre les demandes d’exécution envoyées par NGinx.

Contrairement à PHP, il n'existe pas (encore) de package Ubuntu permettant d'automatiser l'installation de ce processus. Il faut donc mettre un peu les mains dans le cambouis (merci à ce blog) !

On commence par installer le module Perl FCGI sur lequel le processus fastcgi-wrapper.pl va se baser:

sudo perl -MCPAN -e 'install FCGI'

On installe le processus fastcgi-wrapper.pl qui va s'occuper de l’exécution  des scripts Perl:

sudo wget -O /usr/bin/fastcgi-wrapper.pl http://lindev.fr/public/nginx/fastcgi-wrapper.pl

sudo chmod 755 /usr/bin/fastcgi-wrapper.pl

La plupart des tutos que j'ai trouvé sur le Net utilise ensuite un script init.d pas très beau à voir (http://lindev.fr/public/nginx/perl-fastcgi). En effet, pour arrêter le processus on a droit à un beau killall -9 perl ! Autant dire que si vous avez d'autres processus Perl en tache de fond de votre serveur cela risque de poser quelques problèmes :). J'ai donc écrit un nouveau script basée sur celui du wrapper PHP.

On automatise le lancement de ce script au démarrage du serveur:

sudo wget -O /etc/init.d/perl-fastcgi https://raw.github.com/nicolargo/ubuntupostinstall/master/perl-fastcgi

sudo chmod 755 /etc/init.d/perl-fastcgi

sudo update-rc.d perl-fastcgi defaults

Puis on le lance en tache de fond:

sudo service perl-fastcgi start

Il ne reste plus qu'à modifier le fichier de configuration Nginx de votre site pour prendre en compte les scripts Perl:

# Mon site a moi

server {

listen 80;

server_name localhost;

root /home/labo/www;

 

location / {

index index.php index.html;

}

 

location ~ .php$ {

fastcgi_pass 127.0.0.1:9000;

include /etc/nginx/fastcgi_params;

fastcgi_index index.php;

}

 

location ~ .pl$ {

fastcgi_pass 127.0.0.1:8999;

include /etc/nginx/fastcgi_params;

fastcgi_index index.pl;

}

}

On relance ensuite Nginx:

sudo service nginx restart

Restarting nginx: nginx.

Pour tester que le Perl fonctionne bien, le plus simple est de créer un fichier info.pl (à mettre à la racine du site /home/labo/www/) contenant:

#!/usr/bin/perl

print "Content-type: text/htmlnn";

print "<html><body>Hello, world.</body></html>";

Attention, contrairement au script PHP, les fichier .pl douivent avoir les droits en exécution sous peine de ce trouver devant le message suivant:

Error: No such CGI app - /home/labo/www/info.pl may not exist or is not executable by this process.

On doit donc saisir la commande:

chmod a+x /home/labo/www/info.pl

Puis de pointer votre navigateur Web vers l'URL: http://localhost/info.pl

La page suivante devrait s'afficher:

Optimisation corner !

On passe maintenant à quelques optimisations que l'on peut ajouter à la configuration de son site (merci à @T1B0).

On commence par le fait de ne pas loguer les message 404 sur le fichier favicon.ico (histoire de ne pas surcharger ses logs):

location = /favicon.ico {

access_log off;

return 204;

}

Ensuite on optimise la durée d'expiration des en-tête des fichiers statiques (pour les caches):

location ~* ^.+.(jpg|jpeg|gif|css|png|js|xml)$ {

expires 30d;

}

Pour aller plus loin, vous pouvez également lire ce billet chez K-Tux. (notamment l'utilisation de memcache qui est intégré à NGinx !).

Conclusion

Vous avez donc à votre disposition un beau serveur Web NGinx avec le support FastCGI PHP & Perl !

Elle est pas belle la vie ?

  • bartux

    *il se targue (pas il se tarde).

    Merci pour l’article en tout cas.

  • anonymous

    il se targue* :p

  • http://www.nicolargo.com NicoLargo

    Merci aux deux “Maître Capello” :)

  • @T1B0

    Nice ! bon article, j’ai fait presque le meme TP le mois dernier ;)

    une petite obs sur ta conf php-fpm, tu peux faire la fastcgi-pass directement par socket unix, genre :

    location ~* \.php$ {
    fastcgi_split_path_info ^(.+\.php)(.*)$;
    fastcgi_pass unix:///tmp/php5fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params.conf;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    et il y a aussi des petites directives tres sympas pour eviter de polluer tes logs, genre :

    location = /favicon.ico {
    access_log off;
    return 204;
    }

    ou pour ajouter des headers pour le cache :

    location ~* ^.+\.(jpg|jpeg|gif|css|png|js|xml)$ {
    # access_log off;
    expires 30d;
    }

    Sinon pour le python je te recommande aussi chaudement de plugger uwsgi avec nginx, ça donne une vrai bete de guerre ;)

    • http://www.nicolargo.com NicoLargo

      Merci pour ces astuces ! Quel est l’avantage d’utiliser une socket Unix plutot qu’une socket TCP ? Perfo ?

      Je rajoute de ce pas tes optimisations pour les headers et le non logs des favicons dans le billet :)

  • Pingback: Tweets that mention Installation et test de NGinx sous Ubuntu -- Topsy.com

  • skippy

    Bien que supportant plus de requêtes, sur le graphe on voit que nginx est moins stable qu’apache. Ou alors est-ce une erreur de ma part??

  • http://www.woueb.net Romain

    Chouette article !

    @Skippy > Je dirais plutôt qu’Apache arrive au max de ses performances et qu’il stagne.

  • http://www.nicolargo.com NicoLargo

    @Romain & @Skippy: c’est vrai que le fait que la courbe de perfo de NGinx ne soient pas stable est étrange. Il faut dire que je n’ai fait le test que deux fois de suite sur une machine de bureau (donc pas un serveur dédié) qui faisait tourner d’autres taches en parallèle. Je pense que NGinx arrive au limite de ma bécane.

  • http://www.radek411.org Radek411

    Un article très intéressant :-) Je testerai NGinx sur mon serveur, quand j’aurais le temps.

  • http://gpit.fr iznogoud

    Merci bcp, très bon tuto ^^ Après ça vaut pour une utilisation perso … en pro pour des clients je ne m’y risquerai pas ^^

    Merci pour la partie sécurisation ^^ A voir si il est possible de faire encore mieux ^^ Mais je vais appliquer ça sur mon site perso ^^

    • http://www.nicolargo.com NicoLargo

      De nombreux sites “pro” sont justement passés d’Apache à NGinx pour avoir de meilleures performances tout en gardant une parfaite stabilité. On peut citer WordPress, Hulu, Github, Ohloh, SourceForge ou TorrentReactor…

  • http://www.nordeen.fr Nordine

    Excellent !
    Je vais mettre ton article dans mes favoris, je pense que je vais en avoir besoin dans ma boite.

  • http://blogmotion.fr/ Mr Xhark

    Quand Nginx ne suffit pas il faut passer à Varnish :)

  • http://www.teissedre.info farwarx

    Salut,
    Tuto sympa ;)

    On peut avoir un httperf avec du php?
    Voir même un httperf avec une requête MySQL en php?

  • ninja21a

    Bonjour Nico,
    Juste un “typo mismatch” si on peut dire. Il manque un sudo devant le add-apt-repository ;)

    • http://www.nicolargo.com NicoLargo

      Corrected. Thx !

  • ninja21a

    Bonjour,

    J’ai fait un httperf après avoir installé la prise en charge de php et perl, avec les scripts basics proposés par Nicolas dans cet article.

    En voici le résultat :

    httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10
    httperf –client=0/1 –server=localhost –port=80 –uri=/ –send-buffer=4096 –recv-buffer=16384 –num-conns=5000 –num-calls=10
    Maximum connect burst length: 1

    Total: connections 5000 requests 50000 replies 50000 test-duration 285.400 s

    Connection rate: 17.5 conn/s (57.1 ms/conn, <=1 concurrent connections)
    Connection time [ms]: min 50.9 avg 57.1 max 1196.3 median 53.5 stddev 28.3
    Connection time [ms]: connect 0.2
    Connection length [replies/conn]: 10.000

    Request rate: 175.2 req/s (5.7 ms/req)
    Request size [B]: 62.0

    Reply rate [replies/s]: min 104.8 avg 175.2 max 187.4 stddev 11.8 (57 samples)
    Reply time [ms]: response 3.7 transfer 2.0
    Reply size [B]: header 191.0 content 62347.0 footer 2.0 (total 62540.0)
    Reply status: 1xx=0 2xx=50000 3xx=0 4xx=0 5xx=0

    CPU time [s]: user 146.31 system 90.10 (user 51.3% system 31.6% total 82.8%)
    Net I/O: 10710.0 KB/s (87.7*10^6 bps)

    • http://www.nicolargo.com NicoLargo

      Cela me semble très faible comme perfo. Dès que j’ai la main sur la machine sur lequel j’avais fait le test en HTML je refais le test en PHP et PERL histoire de comparer ce qui est comparable.

      • Garry3D

        En utilisant la même ligne de commande que celle que tu as fournie pour httperf j’obtiens :
        Pour un fichier index.html de 20 octets : 1218 req/sec
        Pour un fichier index.html de 10Ko : 948 req/sec
        Avec la page d’accueil d’un wordpress : 82 req/sec

        (le fichier de 10ko est une copie statique du fichier généré en PHP par wordpress)

        Du coup je me demande si c’est bien utile de s’acharner sur le serveur HTTP… quelqu’un à d’autres idées d’optimisation ? qui a fait des test avec postgresql ou un CMS statique ?

        • http://www.nicolargo.com NicoLargo

          Salut Philippe :) (bonne année à toi et tout et tout).

          Pour l’optimisation de WordPress je te conseille de jeter un coups d’oeil sur Varnish (http://blog.nicolargo.com/2010/10/booster-votre-blog-wordpress-avec-varnish.html). Il fait grosso modo ce que tu as fait à la main c’est à dire générer et cacher les pages PHP vers des pages statiques.

          Je l’utilise sur mon blog et c’est vraiment une bombe !

  • Pingback: Le panier du marché libre #4

  • http://www.nicolargo.com NicoLargo

    Avec NGinx, sur ma config, quand je fais un HttpPerf sur le fichier info.php (http://localhost/info.php), j’arrive aux perfos suivantes:

    Request rate: 385.0 req/s (2.6 ms/req)

  • Bertrand31

    Excellent tutoriel, merci beaucoup.

  • http://www.opensides.fr ajeanson

    Encore un super post merci !

    Pour info, NGinx a un module memcached qui permet de cacher le contenu static et booster les perf (cf. http://wiki.nginx.org/HttpMemcachedModule)

    Un vieil article toujours d’actu la dessus sur le sujet: http://www.igvita.com/2008/02/11/nginx-and-memcached-a-400-boost/)

  • http://www.it-wars.com Vincent RABAH

    Bonjour,

    J’utilise nginx depuis plusieurs mois avec bonheur sur mon blog http://www.it-wars.com sur un Seagate DockStar avec proc ARM et 128Mo de RAM : ÇA FONCTIONNE NICKEL !

    Néanmoins, une petite remarque, nginx fait partie du repo officiel debian et ubuntu. Pourquoi cet autre dépot ?

    Merci.
    Vincent RABAH.

    • http://www.nicolargo.com NicoLargo

      Version de Nginx dans les dépots officiel: 0.7.x

      Version de Nginx dans le dépots de ce billet: 0.8.x

      La version 0.8.x est la version stable de NGinx (dixit le site officiel: http://wiki.nginx.org/Install)

      cqfd

  • Pingback: Installation automatique de NGinx, PHP-FPM, MemCached sous Debian

  • http://www.fotopoto.fr Gabriel

    Merci pour ton tuto. Je ne connaissais pas vraiment NGINX, juste entendu parlé mais grâce à toi j’ai pu facilement le mettre en place pour tester, il ne me reste plus qu’à mettre en place Varnish ;)

  • Laurent

    Tout d’abord bravo pour ton blog.
    Une vraie mine d’informations !

    Au sujet de Nginx, peut il aussi être utilisé dans la config tout intégré reverse proxy + serveur web ?

    Je demande cela car la plupart des sites qui donnent des infos sur Nginx se limitent au serveur web.
    Et qd on trouve des sites sur la fonctionnalité de reverse proxy de Nginx , c’est presque tjs devant Apache.

    Peut être que qqchose m’échappe ???

    En parlant de reverse proxy devant Nginx, qq a t’il aussi essayé le couple Varnish/Nginx ?

    Vu les perfs de varnish en reverse proxy et de nginx en serveur web, j’imagine que cette config doit faire des étincelles.

    • http://www.nicolargo.com NicoLargo

      NGinx peut très bien être utilisé en Proxy/Serveur Web sans Apache. Je pense que la plupart des sites donnent des explications pour le couple Nginx en proxy et Apache en serveur Web car c’est transparent u niveau des applications Web qui vont continuer à être sous Apache.

      Concernant le couple infernal Varnish+Nginx je l’ai testé est je te confirme que c’est une vrai bombe !

      • Laurent

        Merci pour ta réponse.

        Je pense que je vais très probablement m’orienter vers le couple varnish/Nginx pour mon prochain serveur.

        As tu eu l’occasion de tester aussi Nginx/Nginx en proxy + serveur web ?

        Quand je vois que Cloudflare par ex. utilise massivement Nginx comme reverse proxy, je me demande finalement si cette solution Nginx/Nginx ne mérite pas d’être approfondie ?

        L’intérêt dans ce cas serait de n’avoir qu’un seul soft pour tout gérer.

  • booga

    Merci beaucoup pour ton tuto/script !
    Cependant une fois tout installé, je me suis rendu sur :
    http://mondomaine.org
    et j’ai eu droit à un:
    403 Forbidden
    nginx/0.7.65

    Une petite piste ?

  • booga

    Je m’auto-réponds :
    Ne pas oublier de faire –>
    chown -R www-data:www-data /var/www
    chmod -R 775 /var/www

    ;)

  • http://twitter.com/mmai mmai

    L’appel d’un script PHP retournait une page blanche avec cette config.
    J’ai du ajouter la ligne suivante dans /etc/nginx/fastcgi_params : fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

  • Pingback: Installation et Configuration de Nginx avec php-fpm | Notes !

  • Mid’

    Il y a un bug dans le script perl-fastcgi…

    Remplacer la ligne déclarant SSD_OPTIONS par :
    SSD_OPTIONS=”–oknodo –quiet –pidfile $FCGI_PID”

    et la ligne démarrant le script par :
    /sbin/start-stop-daemon –start $SSD_OPTIONS –exec $FCGI_CMD — $FCGI_OPTIONS

    Sinon le process n’est jamais killé car start-stop-daemon cherche un exécutable nommé /usr/bin/fastcgi-wrapper.pl qui n’existe pas…!

    A+

  • Mid’

    Autre chose, il faut remplacer dans le script fastcgi-wrapperl.pl, dans la fonction daemonize, la ligne :

    exit if $pid;

    par :

    if ($pid) {
    open(OUTPID, “>/var/run/fastcgi-wrapper.pid”);
    print OUTPID $pid;
    close(OUTPID);
    exit;
    }

  • http://www.installreparetonpc.fr Azigui

    Excellent tuto, simple et clair.
    Par contre une question :
    Du coup comme on passe pas par la compilation des sources, comment fait-on pour intégrer des modules tels que http_realip_module ?

    Merci pour l’info

    Cdlt,

    Azigui

    • http://www.nicolargo.com NicoLargo

      C’est bien pour cela que je passe par une installation depuis les sources…

  • jean

    Bonjour,
    C’est possible d’avoir un nouveau lien pour http://svn.nicolargo.com/ubuntupostinstall/trunk/perl-fastcgi ?

    Merci

  • Armand Romanic Bong

    Bonjour NicoLargo,
    j’ai essayé de configuré Nginx dans ma machine mais lorsque je teste ma page info.php ou info.pl
    je reçois :502 BAD GATEWAY et puis nginx/1.0.11

    Que faire?je n’arrive pas à tester mes formulaires
    écrit avec php.
    Merci de votre disponibilité

  • Pingback: Introduction au serveur Nginx : Performances, installation et extensions pour le serveur HTTP Engine-x | Bitpxl

  • Pingback: 4h18 - Optimiser son serveur pour wordpress

  • hqro

    attention dans ton tuto, certains chemin ne sont pas les bons:
    /etc/nginx/site-available/default
    est plutôt: /etc/nginx/sites-available/default

    Sinon très bon tuto merci :)

    • http://www.nicolargo.com nicolargo

      Merci pour la relecture :)

      Je viens de corriger.

  • Hqro

    Excellent tuto tout marche très bien exepté Javascript. Pourrais-tu expliquer quelles lignes rajouter dans mon fichier site dans sites-available/ et sites-enabled/. Cela marche t-il avec openjdk? Merci d’avance.

  • Nimbus

    D’après ce que je comprends il est préférable d’installer les sites web dans le répertoires /home plutôt que dans le répertoire /var/www

    une question cependant. Apparemment vous installez les fichiers du site web en mode root ne serait il pas préférable de les installer avec un compte utilisateur ?

    Quel compte utilise Nginx pour fonctionner ? www-data ?

    merci pour ces réponses

  • Pingback: Wordpress sur Nginx et Varnish

  • Pingback: Nginx : tips pour booster le service - K-Tux

  • Pingback: NGinx / Supervisor / Gunicorn | Pearltrees

  • Pingback: WEBmaster | Pearltrees

  • Chocobozzz

    Bonjour, je sais que le tuto est pour Ubuntu mais seulement je préfère le dire pour les utilisateurs d’une Debian.
    Par défaut, PHP-FPM écoute via un socket, donc il faut remplacer dans la conf NGINX (sinon ça provoque une 502 BAD GATEWAY sur les fichiers php) :
    fastcgi_pass 127.0.0.1:9000;

    par :
    fastcgi_pass unix:/var/run/php5-fpm.sock (dans mon cas, une Debian 7).

    Ou sinon vous modifiez la façon dont FPM écoute via le fichier dans /et/php5/fpm/pool.d/www.conf

    CF : https://blog.dbrgn.ch/2013/5/25/php-fpm-connection-refused/

  • Pingback: Liste des billets comportant le tag: nginx | B-Zup.com