Installation pas à pas d’un serveur de blog WordPress sur Debian Squeeze

Date: 25/08/2011 | Catégories: Blog,Open-source,Planet-libre,Systeme,Web | Tags: ,,,,,,

Je viens de passer le cap et de m'abonner à un serveur dédié chez Online.net. Mon choix s'est porté vers une Dedibox DC. J'ai longtemps hésité avec une OVH Kimsufi 16G mais le fait que la Dedibox propose en standard deux disques fonctionnant en RAID1 à fait la différence (avec l'âge ou privilégie la sécurité à la performance...).

Avant de migrer mon blog sur ce nouveau serveur (il est actuellement hébergé chez un VPS Gandi 4 parts), j'ai profité de disposer d'un serveur tout neuf pour valider une procédure complète d'installation et d'optimisation d'un blog WordPress sur un serveur Debian Squeeze en utilisant le "stack" Web suivant: Varnish + Nginx + MemCached.

L'objectif de ce billet est de partager cette procédure avec vous.

Introduction

Nous allons donc détaillé l'installation d'un blog WordPress sur une installation toute fraîche de Debian Squeeze (version stable) pré-installé dans mon cas par Online.net avec un minimum de logiciels (pas d'Apache ni d'autres serveurs Web). Vous l'avez compris, pour suivre la procédure suivante, il faut s'assurer qu'aucun serveur Web n'est installé sur votre machine.

Post installation du système

J'ai pris l'habitude de créer des scripts de post installation pour les OS (desktop et server) que j'utilise. Dans le cas qui nous intéresse je vais donc utiliser le script: squeezeserverpostinstall.sh.

Pour le télécharger puis le lancer, il suffit de saisir les commandes suivantes à partir d'un compte administrateur ou directement en root):

Comme le serveur est directement connecté à Internet et à moins d'être très joueur, je vous conseille de configurer quelques règles de Firewall. J'ai mis à disposition un jeu de règles assez facile à modifier en éditant le fichier /etc/init.d/firewall.sh. Pour le télécharger et l'installer:

Note: par défaut les ports SSH entrant et HTTP et DNS sortant sont autorisés.

Pour modifier ces listes, il suffit de configurer les variables suivantes dans le fichier /etc/init.d/firewall.sh:

A ce stade, vous devriez avoir un serveur à jour et sécurisé. Passons donc à l'étape suivante.

Installation de Nginx + PHP-FPM + Memcached

C'est actuellement une des combos les plus performantes pour héberger des serveurs Web basées sur PHP (ce qui est le cas du CMS WordPress). Pour effectuer simplement et rapidement ces logiciels, j'utilise un script maisonnginxautoinstall.sh. Il faut donc saisir les commandes suivantes:

Le script va installer la dernière version stable de Nginx puis le daemon PHP-FPM qui permet de booster les performances des scripts PHP et enfin le gestionnaire de cache mémoire MemCached (note: le script fonctionne également sur Debian Lenny 5).

Pour adapter les performances de Nginx à votre CPU, il faut modifier la variable worker_processes le fichier /etc/nginx/nginx.conf. Pour obtenir la valeur optimale pour votre système, vous pouvez lancer la commande suivante:

Qui donne la valeur 4 sur ma Dedibox (4 coeurs/CPU). On édite le fichier nginx.conf de la manière suivante:

On relance le serveur pour prendre en compte la configuration:

Installation du langage PHP

WordPress use et abuse du langage PHP, une installation optimisé du moteur permettant d'exécuter le code est donc nécessaire. Personnellement j'utilise l'implémentation PHP5 FPM qui est réputé pour ses performances. Elle est installé par défaut avec mon script d'auto-install de Nginx.

La configuration est stocké dans le répertoire /etc/php5/fpm. Mon fichier php-fpm.conf ressemble à cela:

Avec WordPress comme CMS, je vous encourage à stocker les fichiers de sessions dans une base NoSQL de type Redis afin de ne pas se retrouver avec des milliers de petits fichiers dans le répertoire /tmp. Pour cela, il suffit d'ajouter les lignes suivantes dans le fichier /etc/php5/fpm/php.ini:

Dernière étape et non des moindres, la configuration du pool de processus PHP-FPM que vous allez dédier à votre blog WordPress (par exemple /etc/php5/fpm/pool.d/www.conf dans mon cas):

On peut relancer PHP

et passer à l'étape suivante, la base de donnée...

Installation de MySQL

A l'heure actuelle, WordPress utilise une base de donnée MySQL pour fonctionner (je préférerai PgSQL mais bon...). Il faut donc installer le serveur de base de donnée MySQL:

Optimiser un peu celle-ci en modifiant quelques variables dans le fichier /etc/mysql/my.cnf:

et relancer le daemon pour que la configuration soit prise en compte:

On passe ensuite à la phase de création de la base de données nommée wordpress accessible par utilisateur/motdepasse:

Installation du CMS WordPress

J'utilise la dernière version stable de WordPress disponible sur le site officiel:

Ensuite on configure la base de donnée dans le fichier wordpress/wp-config.php:

Il suffit ensuite de finaliser l'installation de WordPress en pointant un navigateur Web vers http://votredomaine.com/wordpress/wp-admin/install.php.

Si vous avez changé la structure du permalink (par exemple chez moi c'est /%year%/%monthnum%/%postname%.html), il faut modifer la configuration Nginx, plus précisément la section "Location /" dans le fichier /etc/nginx/sites-enabled/default-site:

avec les fichiers inclus suivants:

Securité /etc/nginx/global/security.conf:

et PHP-FPM /etc/nginx/global/php-fpm.conf:

Ne pas oublier de relancer NGinx pour prendre en compte cette modification:

Installation du plugin WP Super Cache

Après quelques années sous d'utilisation de W3 Total Cache et la mise en place de mon proxy/cache Varnish, j'ai choisi d'utiliser le plugin WP Super Cache qui s'occupe de cacher les pages demandées par les utilisateurs non identifiées (donc pas 90% du trafic) afin que PHP et MySQL ne soit pas appelé lors de ces requêtes.

Il est également possible de précharger la mise en cache des pages les plus visitées et de les mettre automatiquement à jour de manière régulière.

Une fois installé et activé il faut se rendre dans le menu de configuration du plugin et de cliquer sur l'onglet "Easy" et "Mise en cache Activée (Recommandé)".

A ce stade, on peut faire quelques tests de performances avec Apache Bench (disponible dans le paquet Debian apache2-utils):

[cce lang="bash"]

Requests per second: 219.53 [#/sec] (mean) (options -t 30 -c 5)

[/cce]

ou avec le service en ligne Load Impact qui permet de simuler gratuitement jusqu'à 50 utilisateurs simultanés sur votre site:

On voit bien que les page du blog se chargent rapidement (environ 500ms) même avec 50 utilisateurs simultanés.

Puis arriva Varnish...

J'ai mis à jour ma configuration de Varnish+Nginx pour WordPress dans le billet suivant. Vous pouvez le suivre en lieu et place du chapitre qui suit...

Vous savez tout le bien que je pense de Varnish. Nous allons donc maintenant ajouter cet accélérateur de site Web dans notre configuration. Il est à noter que cette étape est optionnelle. Vous pouvez tout à fait rester avec la configuration du chapitre précédent qui offre déjà de belles performances.

On commence par installer la dernière version de Varnish en utilisant le dépôt officiel.

La version 3 de Varnish apporte certaines modifications au niveau de la syntaxe des fichiers de configuration. Si vous avez donc une config fonctionnelle en version 2, je vous conseille de lire cette page pour l'adapter.

On commence par éditer le fichier de configuration /etc/varnish/default.vcl:

Puis la manière dont le daemon va se lancer dans le fichier /etc/default/varnish:

Enfin on reconfigure NGinx pour ne plus écouter sur le port 80 (c'est Varnish qui va prendre le relais) mais sur le port 8080. Il suffit de changer la deuxième ligne du fichier /etc/nginx/sites-enabled/wordpress:

On n'oublie pas d'ouvrir les port au niveau du Firewall (fichier /etc/init.d/firewall.sh):

On relance les services:

Afin pour que Varnish soit prévenu quand un billet est modifié, il faut installer et activier le plugin Varnish HTTP purge.

Le site devrait fonctionner normalement mais avec des performances boostées. Par exemple, le même test Apache Bench donne les résultats suivants:

A comparer avec 220 requêtes par secondes sans Varnish...

On voit même une amélioration du temps de chargement des pages (300ms vs 500ms) qui reste constant avec  Load Impact:

Conclusion

On arrive à la fin de ce (trop ?) long billet. Le sujet est vaste et il y a sûrement des améliorations à faire dans la configuration que je viens de vous présenter. Les commentaires ci-dessous sont fait pour partager vos expériences.

Je vous signale également que je regroupe tout les billets sur l'hébergement sur la page suivante.

  • je test de suite en labo vm et je te tiens au jus, mais cela risque fort de me pousser a faire le grand saut pour un auto hébergement d’un petit blog.

    encore merci pour la qualité de ton travail.

  • Il me semble que dans le premier bloc de code, tu ais oublié le wget 🙂

  • Yann

    Très bon article !

    – Pour fpm je préfère passer par socket que je trouve bien plus élégant avec une configuration dynamique des child.
    – fw: la loopback étant autorisé inutile de rajouter le port 8080, le mettre dans les rc n’est pas la méthode recommandé (/etc/network/if-up.d)
    – sur WP il n’y a aucune table en innoDB ? car je ne vois aucune optim de mysql dans ce sens (innodb_file_per_table, innodb_buffer_pool_size, …).

    Quel est le facteur limitant de cette solution ?

    • >> Pour fpm je préfère passer par socket que je trouve bien plus élégant avec une configuration dynamique des childs.

      Peux tu nous donner la configuration que tu utilises ? Quels sont les avantages par rapport à une écoute sur un port TCP ?

      >> fw: la loopback étant autorisé inutile de rajouter le port 8080, le mettre dans les rc n’est pas la méthode recommandé (/etc/network/if-up.d) ?

      C’est exact, j’avais laissé ces ports ouverts pour pouvoir faire mes tests de perfos, je corrige le billet dans ce sens.

      >>> sur WP il n’y a aucune table en innoDB ? car je ne vois aucune optim de mysql dans ce sens (innodb_file_per_table, innodb_buffer_pool_size, …).

      Il semble possible d’utiliser innoDB (http://www.619cloud.com/blog/5-essential-steps-for-hosting-wordpress/). Mais je dois avouer que je n’ai jamais testé. Je ne pense pas que l’accès à la BD SQL soit un goulot d’étranglement au niveau des performances.

  • Super tuto, qui va surement me servir très bientot. Merci pour ce boulot et le partage !!

  • Je suis plutôt Drupal voire Joomla!, mais ton article est très intéressant. Notamment les scripts, que je vais suivre de ce pas sur Github 😉

  • Pour fpm:

    Pourquoi je préfère la socket au port? : gérant de multiple compte, chacun chez sois c’est mieux (open_basedir tout ça) plutôt que tout le monde tournant en www-data. Je gagne en sécurité, visibilité avec mes socket /var/run/php5-fpm_nom.sock et applique les bon droits. Je ne serais mesurer l’écart de performance mais la socket unix est plus rapide que TCP, pas de poignée de main toussa.

    Ma config fpm:

    listen = /var/run/php5-fpm_yann.sock
    user = yann
    group = yann
    pm = dynamic
    pm.max_children = 10
    pm.start_servers = 2
    pm.min_spare_servers = 2
    pm.max_spare_servers = 10
    pm.max_requests = 500

    Les valeurs des PM sont basses volontairement à tweaker suivant le traffic 😉

    la seul modif dans nginx étant :

    fastcgi_pass unix:/var/run/php5-fpm_yann.sock;

    Pour mysql, myisam n’est plus du tout amélioré vs innoDB qui possèdent pas mal de tweak sympa. Si WP est encore en myisam c’est sûrement pour la compatibilité avec de vieille version de mysql.

  • Tout simplement excellent !

    Je ne m’étais pas vraiment penché sur l’optimisation de mon WordPress, à part W3 Total Cache et Memcached. Je sais maintenant ce qu’il me reste à faire.

    Merci

  • Fantastique! J’avais fait un petit pas a pas pour moi même avec une configuration très similaire, mais sans les scripts, qui sont très utiles.

    Vous avez fait des tests de performance avec ab? Combien the req/s as toi avec cette serveur?

    Une autre question: vous prévoyez d’utiliser des versions compilées de Nginx/PHP/Varnish pour avoir les dernieres versions et profiter de toutes les nouvelles?

    Merci pour le billet! Et pardonne-moi pour mon francais (je suis espagnol), Je ne l’ai pas utilisé à long 🙁

    • Ton Françcais est aussi bon que certains Francophones :).

      Au niveau des performances obtenues avec ab sur le blog de test (une page du blog par défaut de WordPress), j’obtient les performances suivantes avec ab (options -t 30 -c 5):

      Sans Varnish:
      Requests per second: 219.53 [#/sec] (mean)

      Avec Varnish:
      Requests per second: 9425.03 [#/sec] (mean)

      Au niveau des versions utilisées dans les scripts:
      * Nginx: version compilée depuis les sources de la dernière version stable.
      * PHP-FPM: le script utilise le dépôt Dotdeb qui est mis à jour rapidement.
      * Varnish: J’utilise le dépôt officiel Varnish qui propose la dernière version stable.

      A bientôt !

      • Merci bien 🙂 J’essayerai d’ecrire (et lire) plus!

        Le performance est excellent, mon serveur de test (Linode 1024, quad-core Xen VPS) a aussi une fantastique performance (sous Ubuntu 10.10). J’ai une petite probleme avec les nouveaux billets: Varnish ‘purge’ doit etre très bien configurée pour charger la home et les commentaires en temps réel. Je ne utilise pas le W3 Total Cache, mais je dois le tester.

        Je n’avais pas lu les scripts, mais certainement les versions utilisees sont les dernieres. Bon travail!!

        A bientôt!

  • Superbe article très complete. Je voulais justement changer de dédibox, du coup je pense passer sur ce stack !

    Je me posait quand même la question: Varnish et MemCached? En lisant tes autres articles sur Varnish je me demande si ce dernier n’est pas suffisant pour un blog (qui doit avoir 90% de read).

    http://stackoverflow.com/questions/4490140/memcached-vs-varnish

    Tu me diras, ca ne peut pas faire de mal…

  • Pingback: Installation pas à pas d’un serveur de blog WordPress sur Debian Squeeze par NicoLargo | LorfDotNet()

  • mysql> create database wptest;
    Query OK, 1 row affected (0.00 sec)
    mysql> GRANT ALL PRIVILEGES ON wordpress.* TO « utilisateur »@ »localhost » IDENTIFIED BY « motdepasse »;

    Il y a une petite coquille qui est facile à repérer mais qui peut être modifier dans le post.

    En effet on crée une base de donné nommé wptest
    et après on donne les privilège à la database : wordpress.*

    Il serait peut-être mieux de dire :
    db : wordpress
    privilège : wordpress.*

    C’est le seul point noir que j’ai trouvé à ce post, c’était ma première expérience sur wordpress ( je suis actuellement sous dotclear) et je pense sérieusement à une migration en auto-hébergement.
    Merci à toi nico

  • Pingback: Installation pas à pas d’un serveur de blog WordPress sur Debian Squeeze | Actualités de l'open source | Scoop.it()

  • Hardware

    Petite erreur dans le fichier global/security.conf :

    Ce bloc ne fonctionne pas :

    location ~ /. {
    deny all;
    access_log off;
    log_not_found off;
    }

    il faut le remplacer par :

    location ~ /\. {
    deny all;
    access_log off;
    log_not_found off;
    }

    Voila 🙂

    • Merci, je corrige !

      • C’est bizarre, dans l’éditeur de mon billet il y a bien le \…

        • C’est bon, c’était juste un pb d’affichage dans mon thème…

  • Pingback: Installation pas à pas d’un serveur de blog Wordpress sur Debian Squeeze | Wordpress | Scoop.it()

  • Bonjour merci pour cet article nicolargo!
    J’ai moi aussi installé varnish pour optimiser les performance de mon wordpress avec apache2 et les résultats sont là :p

    Cependant une petite question:
    Comment fait tu pour continuer de collecter des statistiques sur les visites via piwik par exemple sans que la seule ip soit 127.0.0.1, soit lorsque varnish contacte apache ?

    • Premièrement tu ne cache pas le vhost piwik dans varnish. Ensuite tu ajoute le champ X-Forwarded-For dans varnish et tu patch le code de piwik pour le prendre en compte.

      La conf varnish3 devrais ressembler à (dans ton vcl_recv) :

      if (req.http.X-forwarded-For) {
      set req.http.X-Forwarded-For =
      req.http.X-Forwarded-For + « ,  » + client.ip;
      } else {
      set req.http.X-Forwarded-For = client.ip;
      }

      J’ai greper un peu le code de piwik, le proxy semble géré (la variable HTTP_X_FORWARDED_FOR)

      • Merci Yann pour ton indication! J’étais pas loin et ta réponse m’a mis sur la voie.
        Au niveau de varnish il faut effectivement ne pas cacher piwik (c’était ok), configurer l’en tête X-varnish pour conserver l’ip du client, adapter les logs Apache comme l’a indiqué nicolargo là : http://goo.gl/EfwKV, et il faut ensuite décommentez la ligne proxy_client_headers[] = HTTP_X_FORWARDED_FOR dans config/config.ini.php de piwik (cf faq piwik http://goo.gl/5CGdr)

  • Merci pour ce tuto 😉

    je m’en suis inspiré pour ma conf wordpress sur une dedibox SC (lighttp, apc, et maintenant varnish).

    Avant j’avais ça (même test ab -t 30 -c 5 http://URL_A_TESTER/ )

    Complete requests: 1584
    Requests per second: 52.80 [#/sec] (mean)

    après:

    Complete requests: 44148
    Requests per second: 1471.56 [#/sec] (mean)

  • Premièrement tu ne cache pas le vhost piwik dans varnish. Ensuite tu ajoute le champ X-Forwarded-For dans varnish et tu patch le code de piwik pour le prendre en compte.!

  • J’ai essayé plusieurs fois la procédure sur un serveur physique puis sur une VM et ca ne fonctionne pas quand je veux finir l’installation de wordpress… j’ai l’impression que la partie firewall.sh pas exactement comme il faudrait… les ports restent fermés ???

  • Pingback: Le grand YAKA ! » Blog Archive » Petite liste de lecture #16()

  • Bon après plusieurs heures de recherche et d’essais j’ai trouvé… en fait il manque qq explications sur la configuration des vhosts et surtout de penser à rajouter dans /etc/nginx/nginx.conf dans la section html et juste avant la section server : include /etc/nginx/sites-enabled/*;
    Bien sûr il aura fallu donner le bon chemin vers le site root /var/www/dossier_site;

  • Pierre

    Hello, j’ai suivi ta procédure sur une debian squeeze mais je n’arrive pas aux résultats souhaités, j’ai un petit problème avec tes scripts : manque les lsb-flags ? Une piste ?

  • Salut, ce billet est vraiment très efficace pour configurer wordpress sur un serveur dédié !

    J’ai juste deux contributions en tant que relecteur :

    Dans le bloc :
    mkdir /etc/nginx/sites-available
    (snip)

    Par la suite le répertoire devient /etc/nginx/site-availables/ , ce qui n’est pas la même chose et ne fonctionne donc pas si l’on ne corrige pas..

    D’autre part j’ai aussi vu des >> transformés en > comme ici (attention il y en a peut etre d’autres)

    echo « deb http://repo.varnish-cache.org/debian/ $(lsb_release -s -c) varnish-3.0″ >> /etc/apt/sources.list.d/varnish.list

    En tout cas merci pour ce travail très utile.

    mv /etc/nginx/sites-enabled/default-site /etc/nginx/site-availables/

    cp /etc/nginx/site-availables/default-site /etc/nginx/site-availables/wordpress

    ln -s /etc/nginx/site-availables/wordpress /etc/nginx/sites-enabled/wordpress

  • Je pense qu’il faudrait rajouter une petite ligne pour expliquer juste après l’installation toute fraiche de WordPress et changement des permaliens, qu’il faut penser à aller dans les réglages – Général pour modifier les liens adresse web de wordpress et adresse du site et enlever wordpress (je me suis pris longtemps la tête car sinon cela ne fonctionne pas ensuite)

    Petite question : dès que l’on modifie les réglages dans W3 total cache, il faut à chaque fois copier le nginx.conf dans le dossier /etc/nginx/global ?

    Dernière chose, il reste quelques coquilles pour mettre sites-available au lieu de site-available

  • Nice enjoy,
    Moi qui cherche à passer vers nginx, avec tous les boost web c’est parfait pour ma migration ^^
    Nginx est également puissant en tant que reverse proxy et cache !!

  • Le script pour le firewall ne me semble gérer que l’ipv4 et pas l’ipv6, et je viens de recevoir un mail de Dedibox/Online indiquant qu’ils vont l’activer sur le réseau de mon serveur.

    Il semble qu’il faille dupliquer les commandes du scripts en utilisant ip6tables en sus de iptables. J’ai trouvé cet article : http://cipherdyne.org/blog/2009/07/iptables-script-update-logging-and-ipv6-issues.html

  • Bonjour Nicolas,

    Je suis entrain de lire ton script sh, vois-tu un inconvénient à ce que je puisse reprendre ton script pour l’adapter à un tout autre usage (téléchargement & compilation & génération d’un deb pour firefox 7) ?

    • C’est avec plaisir si cela peut te servir.

      • Un grand merci, pour info :

        J’en suis à la dernière étape : création d’un deb.

        En tout cas vraiment bien fait ton script

  • En regardant ton script je me suis aperçu que tu ne récupérais pas la clé pour les packages de dotdeb : regarde le commentaire suivant (http://www.dotdeb.org/2010/07/11/dotdeb-packages-are-now-signed/#comment-2758) tu auras la clé officielle

    • J’ai mal lu ton script… la clé est bien intégrée

  • Bonjour,

    Tous d’abord merci pour tes scripts qui me son d’une grande aide quotidiennement.

    Je me permet de réagir sur le script d’installation de Nginx sur Ubuntu qui utilise les PPA installer Nginx.
    Si on utilise la version 10.04 de Ubuntu de base l’import des clés RSA ne fonctionne pas il faut ajouter le logiciel python-software-properties.
    J’èspère que sa pourras aider 😀

  • Pingback: WordPress by wwwcdorg - Pearltrees()

  • alouestn1

    Bonsoir, merci pour ce tuto fort interessant. J’essaye de le mettre en pratique sur un hébergement GANDI Squeeze 64 bits et je rencontre le problème suivant :

    # update-rc.d firewall.sh defaults 20
    update-rc.d: using dependency based boot sequencing
    insserv: warning: script ‘firewall.sh’ missing LSB tags and overrides

    • Ce n’est qu’un « warning ». Tu peux l’ignorer sans problème. Le service Firewall se lancera quand même au démarrage.

  • alouestn1

    OK, mais comment faire pour outrepasser ce warning ?

  • senjy

    Bonjour,

    J’ai un soucis avec le script suivant.
    nginxautoinstall.sh

    qui me retourne ca

    grep: /etc/apt/sources.list.d/*.list: No such file or directory
    [OK] Update the repositories list
    [ERROR] Install development tools
    [ERROR] Install PHP 5
    [ERROR] Install MemCached

    ——————————————————————————
    Install NGinx version 1.1.11
    ——————————————————————————
    [OK] Download NGinx version 1.1.11
    [OK] Uncompress NGinx version 1.1.11
    [ERROR] Configure NGinx version 1.1.11
    [ERROR] Compile NGinx version 1.1.11
    [ERROR] Install NGinx version 1.1.11
    [OK] Post installation script for NGinx version 1.1.11
    [ERROR] Init the default configuration file for NGinx
    [OK] Install the NGinx init script

    Merci pour ton aide

    • senjy

      Je me repond, car j’ai testé en que c’est le script firewall.sh qui bloque tout.
      Peut etre y a t’il quelques chose qui n’est pas correcte ?

  • Salut,
    Merci pour la partie sur varnish, les scripts d’autoinstall d’nginx et du firewall.

    J’ai condensé la magie de ton pas-à-pas, mis un peu de ma sauce dans tout ça, mis des fichiers sur Github pour donner un script de postinstall pour debian qui installe ce que tu as mis dans cette page etc. (en gros, un ./debian-server-6.sh, une adresse mail et deux « y » et tout est installé et configuré) : https://github.com/Pierrecle/Postinstalls/blob/master/debian-server-6.sh

    En tout cas merci pour ces posts, à chaque fois c’est très instructif.

  • Très bon article, une install parfaite grâce à ton tuto. Essai concluant 😉

  • iTeush

    Excellent article j’ai tous suivi et ça marche parfaitement. 🙂
    Juste une question, après avoir suivi ce tuto, quelles sont les étapes restantes nécessaires pour sécuriser son serveur debian et son site wordpress ?
    Merci d’avance 🙂

  • Blackmam3a

    Bonjour,

    Merci pour vos scripts, j’essaye d’utiliser le script « firewall » mais dès que je l’active, je ne peu plus accéder à mon serveur. Le port SSH ne semble plus répondre, et tout les connexions actives sont coupées

    Blackmam3a

    • C’est étrange, peux tu nous faire un « pastebin » des commandes suivantes:

      # cat /etc/init.d/firewall.sh

      # sudo iptables -L

      • Blackmam3a

        Le problème c’est qu’une fois le script lancé, je n’ai plus du tout accès au serveur donc impossible de taper des commandes 🙁

      • Blackmam3a

        Je viens de trouver l’erreur, ça venait de moi car je n’avais que survolé le script firewall.sh ! Ça m’apprendra à travailler tard le soir…

        J’utilisais stop au lieu de clear voilà ! Honte à moi !

        Merci en tout cas pour tes scripts !

  • julien64

    Bonjour, merci beaucoup pour l’aide apporté grâce à votre script cependant j’ai un petit problème quand je lance l’installation de wordpress (install.php) :

    Impossible de sélectionner la base de données

    La connexion au serveur de base de données s’est bien faite (donc votre identifiant et votre mot de passe sont les bons), mais la base de données wordpress n’a pas pu être sélectionnée.

    cela viens t’il de php ?
    merci d’avance

  • Jean-Bruno

    Bonjour et merci pour ce tutoscript (un gain de temps énorme ces scripts, d’ailleurs je serais preneur d’un tuto sur « comment faire son script » 😉 )

    J’ai un souci. Tout se passe bien mais impossible d’acceder à mon install WordPress. J’ai une erreur 500. Je présume que c’est un problème de permissions / chmod car je suis sur un virtuel kimsufi.
    Si tu as une idée je suis preneur.
    Encore merci

  • Bonsoir,
    Merci pour cet excellent tutorial que j’ai suivi du début à la fin; j’aimerais poser une question : est-il normal que le site ne soit pas accesible avec le www et qu’il le soit sans ?

  • Greg

    Hello,

    J’ai juste essayé la partie firewall et ça ne joue pas chez moi…malheureusement.

    Ca me bloque tout et je perds même la connexion ssh après un moment. Obligé de stopper le service en local et de rebooter pour me reconnecter via ssh.

    iptables -L me retourne :

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all — anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT tcp — anywhere anywhere tcp dpt:ssh
    ACCEPT tcp — anywhere anywhere tcp dpt:ssh
    ACCEPT icmp — anywhere anywhere
    ACCEPT all — anywhere anywhere
    LOG all — anywhere anywhere LOG level warning

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy DROP)
    target prot opt source destination
    ACCEPT all — anywhere anywhere
    ACCEPT all — anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT icmp — anywhere anywhere
    ACCEPT tcp — anywhere villa.debian.org tcp dpt:http
    ACCEPT tcp — anywhere lobos.debian.org tcp dpt:http
    ACCEPT tcp — anywhere wieck.debian.org tcp dpt:http
    ACCEPT tcp — anywhere anywhere tcp dpt:http
    ACCEPT tcp — anywhere anywhere tcp dpt:https
    ACCEPT udp — anywhere anywhere udp dpt:domain
    LOG all — anywhere anywhere LOG level warning
    REJECT all — anywhere anywhere reject-with icmp-port-unreachable

  • Aurélien

    Hello,

    Petite question, comment mettre à jour NGINX avec votre installation?

    Merci

  • Pingback: Installer WordPress sur Debian Squeezy | Malo BLANCHARD()

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