Install Nginx + PHP5 + MariaDB + WordPress sur Debian Jessie
Sources :
https://wiki.debian.org/fr/Lamp
https://fr.wikibooks.org/wiki/Administration_réseau_sous_Linux
https://www.maximejobin.com/wordpress/introduction-nginx-wordpress/
https://itc-life.ru/install-php7-nginx-mariadb-wordpress-on-debian-jessie/
1. Vérifier que votre distribution est à jour :
Verifier la presence de ces sources :
deb http://deb.debian.org/debian jessie main contrib non-free
deb-src http://deb.debian.org/debian jessie main contrib non-free
deb http://deb.debian.org/debian jessie-updates main contrib non-free
deb-src http://deb.debian.org/debian jessie-updates main contrib non-free
deb http://security.debian.org/ jessie/updates main contrib non-free
deb-src http://security.debian.org/ jessie/updates main contrib non-free
Avec :
# nano /etc/apt/sources.list
Puis :
# aptitude update && aptitude upgrade
2.Installez le serveur web Nginx :
[Arrêt du service :
# service apache2 stop
Puis désinstallation :
# aptitude remove --purge apache2
# rm -v /etc/init.d/apache2
Puis mise a jour de la distribution (étape 1)]
Installation :
# aptitude install nginx
Démarrage du service :
# service nginx start
(on peux remplacer « start » par stop, restart, ou reload (qui recharge de la configuration de Nginx))
Quand vous faites une modification à la configuration de Nginx, seul un « reload » est nécessaire. Contrairement à Apache qui vérifie chaque fois le contenu du fichier .htaccess, Nginx lit la configuration uniquement au démarrage et lors d’un « reload ». Cela aide à accélérer la vitesse d’affichage puisque la lecture d’un fichier est un processus lent (contrairement à l’utilisation d’information en mémoire).
En tapant l'adresse IP du serveur dans un navigateur (http://192.168.0.89), une page doit chargée (soit celle de Nginx, ou apache si précédemment installer) … notre serveur fonctionne !
Pour dégommer la page apache :
# rm /var/www/html/index.html
Édition du fichier de configuration principale (du serveur) :
# nano /etc/nginx/nginx.conf
(Par sécurité je copie toujours les originaux : # cp nginx.conf nginx.conf_ORI)
Ajoutez ou ajustez (si elles sont déjà là) ces valeurs entre "{" et "}" dans le bloc http :
client_body_buffer_size 10K;
client_header_buffer_size 1k;
client_max_body_size 50m;
large_client_header_buffers 4 16k;
#prevent upstream sent too big header while reading response header from upstream errors with buffers
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
Edition du fichier de configuration de base (du site) :
# nano /etc/nginx/sites-available/mon_site
Exemple de code que l'on peux écrire dans notre ficher de conf :
## Gestion www
server {
listen 80 ;
listen [::]:80 ;
## Gestion sans www (redirection vers www)
#server {
# server_name monsite.com;
# return 301 http://www.mon_site.com$request_uri;
#}
## SSL configuration
#
# listen 443 ssl default_server;
# listen [::]:443 ssl default_server;
#
# Self signed certs generated by the ssl-cert package
# Don't use them in a production server!
#
# include snippets/snakeoil.conf;
## Hostname
server_name mon_site.com;
## Repertoire dans le quel se trouve le site
root /home/user/Public;
## Noms que peut avoir le fichier qui contient la page principale
index index.html index.htm index.php ;
## Logs (acces et erreurs)
access_log /var/log/nginx/mon_site.com.access.log;
error_log /var/log/nginx/mon_site.com.error.log;
## Bloc location
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
### Complement pour Word Press
## Ne pas logger les erreurs 404 et ajouter expires header
location ~* ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|b$
access_log off; log_not_found off; expires max;
}
## RESTRICTION
## Pas de log pour le favicon
location = /favicon.ico {
log_not_found off;
access_log off;
}
## Pas de log pour le robots.txt
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
## Refus de servir tous fichiers debutants avec un .
location ~ /\. {
deny all;
}
## Refus d'upload d'un fichier php (piratage)
location ~* /(?:uploads|files)/.*\.php$ {
deny all;
}
### Fin de Complement pour Word Press
}
Attention comme nous le rappel Maxime Jobin sur son site les « if » sont a proscrire !! « À noter : plusieurs scripts trouvés sur internet contiennent des « if ». Je vous invite à lire l’article ifs are evil trouvé dans la documentation de Nginx.) »
Deux répertoires à retenir :
/etc/nginx/sites-available ← sites disponibles
/etc/nginx/sites-enabled ← sites activés
De manière générale, on crée la configuration d’un site dans le répertoire des sites disponibles et on ajoute un lien symbolique dans le répertoire des sites activés. Ainsi, si on doit désactiver le site, on peut supprimer uniquement le lien symbolique et garder la configuration
Ajout du lien symbolique :
# ln -s /etc/nginx/sites-available/mon_site /etc/nginx/sites-enabled/mon_site
(Suppression de celui ci : # rm /etc/nginx/sites-enabled/mon_site)
Après modifs il est possible de vérifier si la syntaxe est correcte grâce à cette commande :
# /usr/sbin/nginx -t
Puis on recharge : # service nginx reload
En cas de problèmes ces commandes peuvent aider :
# systemctl status nginx.service
# journalctl -xn
En resumer :
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)
Multi-sites / Server Blocks (en réseau local) : (à compléter !!)
Dans le cas ou le serveur héberge plusieurs sites, afin de pouvoir y accéder à partir du navigateur il faudra éditer le/les fichiers hosts :
# nano /etc/hosts
127.0.0.1 server_name (par exemple : mon_site.com)
127.0.0.1 server_name2 (par exemple : mon_site2.com)
… sur un poste autre que le serveur lui même :
I.P.DU.SERVER server_name (par exemple : mon_site.com)
192.168.0.89 server_name2 (par exemple : mon_site2.com)
3.Installation de PHP5 :
Pour installer :
# aptitude install php5-mysql php5-cli php5-fpm -y
Configuration minimale de PHP :
# nano /etc/php5/fpm/php.ini
Trouver la ligne: ";cgi.fix_pathinfo=1" et la changer pour: "cgi.fix_pathinfo = 0"
(N’hésiter pas a utiliser la recherche avec Ctrl+W)
Trouver la ligne: "post_max_size = 8M" et la changer pour: "post_max_size = 50M"
Trouver la ligne: "upload_max_filesize = 2M" et la changer pour: "upload_max_filesize = 50M"
Le premier changement est pour une question de sécurité. Les deux suivants sont pour vous permettre d’envoyer vos extensions et thèmes sans être trop restreints au niveau de la taille du fichier qui peut être envoyé, on notera que la valeur choisie pour le dernier doit être inférieur ou égale à celle renseignée pour client_max_body_size dans le fichier de configuration principale (nginx.conf) de Nginx.
Pour optimiser l’exécution du PHP, il est fortement conseillé d’activer OPcache afin de pouvoir garder en mémoire le code pré-compilé. Voyez une réponse complète sur StackOverflow.
Configuration de PHP-FPM :
Présentement, notre installation de Nginx prend les fichiers tels qu’ils sont sur le serveur et les retourne. C’est bien sauf dans le cas des fichiers PHP qui doivent être exécutés. Nginx devra donc intercepter les fichiers avec l’extension PHP pour qu’ils soient exécutés.
Emplacement du fichier de configuration : /etc/php5/fpm/php-fpm.conf
La gestion de PHP-FPM se fait via un « pool » de connexions. Il est possible d’utiliser un seul pool par serveur ou un pool par site. Pour WordPress, tel que mentionné plus haut pour la gestion des droits de fichiers, il est préférable d’avoir un pool par site. Ainsi, nous créerons et ouvrons un nouveau fichier nommé mon_site.conf dans le répertoire /etc/php5/fpm/pool.d/ avec cette commande :
# nano /etc/php5/fpm/pool.d/mon_site.conf
Puis on y ajoute les lignes suivantes :
[mon_site]
user = user
group = groupe
listen = /var/run/php5-fpm.mon_site.sock
listen.owner = www-data
listen.group = www-data
pm = dynamic
pm.max_children = 75
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
Après les modifs, on redémarre le service :
# service php5-fpm restart
Gestion des fichiers PHP (envoi vers PHP-FPM) :
On remplace les lignes du « bloc location » dans le fichier de conf du site par celle ci :
(# nano /etc/nginx/sites-available/mon_site)
location ~ \.php$ {
try_files $uri =404;
fastcgi_pass unix:/var/run/php5-fpm.mon_site.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
(Puis on redémarre Nginx)
Afin de s’assurer que la gestion fonctionne nous créons sur notre site un fichier en .PHP dans lequel on colle cette ligne :
<?php phpinfo(); ?>
Si tous fonctionne bien lorsque l on ouvre notre fichier en .PHP depuis notre site le résultat doit ressembler à çà :
(capture de http://www.mon_site.com/fichier.php)
4.Installation de MariaDB :
Installation :
# aptitude install mariadb-server mariadb-client -y
(Pour connaître sa version : mysql -V)
Création d’une base de données MySQL :
On ouvre le prompt avec cette commande :
$ mysql -u root -p
(le mot de passe choisi lors de l'installation vous sera demandé pour poursuivre)
On créer une nouvelle base :
> CREATE DATABASE Nom_de_la_base;
On créer un utilisateur :
> grant usage on *.* to user_test@localhost identified by 'password';
Puis on lui donne tous les droits à sur la base de donnée « monsitewebdb » via les commandes suivantes :
> grant all privileges on Nom_de_la_base.* to user_test@localhost ;
> flush privileges;
On quitte le serveur MariaDB :
> quit
Voici le récapitulatif des informations pour configurer l’accès à la base de donnée que nous venons de créer :
Nom de la base de donnée : Nom_de_la_base
Utilisateur de la base de donnée : user_test
Mot de passe de l’utilisateur de la base de donnée : password
Serveur : localhost
Ensuite, on teste notre utilisateur en se connectant a la base :
> mysql -u user_test -p
(Password)
Si tous est bon vous devais avoir qqch qui resemble a ça (Welcome to the MariaDB monitor …) :
Base de donnée bien en fonction, on quitte le prompt :
> quit
5-1.Installation de Word Press :
La partie la plus simple du tuto;)
Direction le site de Word Press via ce lien : https://fr.wordpress.org/txt-install/
Comme expliqué sur la capture, on télécharge notre archive, on décompresse le contenu du répertoire « wordpress » a la racine de notre site, on se rends sur notre site via un navigateur, on complète les champs demandés … et voilà en moins de 5 minutes notre site est né !
5-2 Migration d'un site Word Press déjà existant :
Pour importer un site déjà existant, hébergé sur un autre serveur (que celui que l’on viens de créer^^)
1.Rapatriement des fichiers du site :
Cela consiste à copier l’intégralité du contenu du répertoire racine du site existant, vers le répertoire racine de notre nouveau site.
Rien de plus simple, il suffit de se connecter au serveur FTP de votre hébergeur avec FileZilla par exemple.
On renseigne le nom d’hôte (exemple pour free : ftpperso.free.fr), votre nom d'user, et votre mot de passe, puis une fois connecter on télécharge tout ce qui se trouve à la racine, afin de le replacer à la racine du repertoire de notre nouveau site.
2.Rapatriement de la base de données :
Généralement les hébergeurs fonctionnent avec phpMyAdmin, Si vous ne vous souvenez plus de vos identifiants, ils sont dans le fichier « wp-config.php » à la racine du site, et vous permettrons de vous connecter à la page ci-dessous :
1.On clique sur l’onglet « Export »
2.Normalement tout est déjà sélectionné, sinon « Select All »
3.On choisi le format SQL
4.On compresse en archive .bz (ou .gz (mais plus volumineux))
5.On télécharge en cliquant sur « Go »
Voilà ! Nous avons récupérer notre base de données…
3.Importation de la base de données dans MariaDB :
On extrait le fichier « nom_base_de_données.sql » de l'archive précédemment téléchargée dans /un_repertoire_tmp
Et on l'importe dans notre nouvelle base à l'aide de cette commande :
# mysql -u root -p nom_nouvelle_base_donnees < /un_repertoire_tmp/nom_base_de_données .sql
Pour vérifier :
# mysql -u root -p
MariaDB [(none)]> use nom_nouvelle_base_donnees;
MariaDB [nom_nouvelle_base_donnees]> SHOW FULL TABLES;
+--------------------------+------------+
| Tables_in_nom_nouvelle_bd| Table_type |
+--------------------------+------------+
| wp_commentmeta | BASE TABLE |
| wp_comments | BASE TABLE |
| wp_links | BASE TABLE |
| wp_options | BASE TABLE |
| wp_postmeta | BASE TABLE |
| wp_posts | BASE TABLE |
| wp_term_relationships | BASE TABLE |
| wp_term_taxonomy | BASE TABLE |
| wp_terms | BASE TABLE |
| wp_usermeta | BASE TABLE |
| wp_users | BASE TABLE |
+--------------------------+------------+
11 rows in set (0.00 sec)
Nos tables doivent apparaître;)
Maintenant que cette nouvelle base de données est en place, on va mettre à jour le fichier « wp-config.php » au niveau du paragraphe « Réglages MySQL » voir capture ci-dessous, quatre lignes a mettre a jour (nom de la base de données, nom d’utilisateur, mot de passe et l’hôte) ;
// ** Réglages MySQL - Votre hébergeur doit vous fournir ces informations. ** //
/** Nom de la base de données de WordPress. */
define('DB_NAME', 'nom_nouvelle_base_donnees');
/** Utilisateur de la base de données MySQL. */
define('DB_USER', 'user_test');
/** Mot de passe de la base de données MySQL. */
define('DB_PASSWORD', 'password');
/** Adresse de l'hébergement MySQL. */
define('DB_HOST', 'mon_site.com');
/** Jeu de caractères à utiliser par la base de données lors de la création des tables. */
define('DB_CHARSET', 'utf8');
Vous pensez avoir fini … malheureusement toutes les urls sont cassées, il va falloir renommer une multitude de liens en masse !
4.Mise à jour des URLs :
A première vu, on est tenté de ce dire que c'est easy, pourquoi pas ouvrir notre fichier .sql avec notre éditeur de texte préféré pour remplacer tout les « mon_ancien_site.com » par « mon_nouveau_site.fr » ?
Mauvaise idée, car il se peut que certaines urls soient « serialized », c'est a dire quel n’apparaissent pas en claire dans les écritures.
Heureusement ! Pour réaliser ce travail laborieux il existe un script nommé « Search-Replace-DB » devellpé par Interconnectit.
Une fois l'archive téléchargée, on extrait le repertoire « Search-Replace-DB-master » que l'on place à la racine du site, puis direction http://mon_site.com/Search-Replace-DB-master/index.php via le navigateur, ce qui nous ouvre la pages ci dessous :
1 On rentre l'adresse de l’ancien site (sans slash a la fin)
2 On rentre l'adresse du nouveau site (sans slash a la fin)
3 On entre les identifiants pour se connecter à la base de données (non de la base, utilisateur, mot de passe, hote … ils se trouvent toujours également dans wp-config,php)
4 On sélectionne l'ensemble des tables
5 On met a jour le tout en cliquant sur update details
6 On fait un test en cliquant sur dry run, et si concluant …
7 … on exécute en cliquant sur live run. Le travail fini un récapitulatif vous indique ce qui a été fait (capture ci dessous)
8 On ferme la fenêtre, et l'on supprime le répertoire « Search-Replace-DB-master » que l'on avait placé à la racine du site.
Finalisation (verification des liens) :
Pour finir, (et a faire de temps a autre) on vas s'assurer qu'il n'y a pas de liens morts, quelle galère pour trouver un outil gratuit, pour aller tester tout les liens.
J'en ai trouver un du nom de LinkChecker (fonctionne aussi sur Windaube apparemment), pour l'installer :
# aptitude install linkchecker
# aptitude update && aptitude upgrade
Exemple d'utilisation :
$ linkchecker --ignore-url=http://ii.crazy.dave.ii.free.fr/xmlrpc.php http://ii.crazy.dave.ii.free.fr/ > /home/user/log_LC_site
Sachez qu'un site aussi superbe qu'il soit, se fait pourrir par les robots de référencements si il comporte des liens mort.
Voilà … j’espère que c'est notes pourrons aider 😉
CrazyDaveX89 Rev_20170828_01