Serveur dédié : installer PHP7 FPM avec FastCGI photo

Serveur dédié : installer PHP7 FPM avec FastCGI sous Debian

Aujourd’hui, on passe de PHP5 à PHP7 en moins de 20 minutes montre en main sur notre serveur dédié qui tourne sous la version stable de Debian.

Pré-requis : les dépôts Dotdeb

Avant toute chose, vous devez avoir les dépôts Dotdeb installés dans votre apt.

On édite donc la liste des dépôts:

nano /etc/apt/sources.listCode language: PHP (php)

puis on y ajoute :

# Dotdeb stable
deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable allCode language: PHP (php)

On installe la clé GPG de Dotdeb:

wget https://www.dotdeb.org/dotdeb.gpg
sudo apt-key add dotdeb.gpgCode language: JavaScript (javascript)

et on met notre liste de paquet à jour :

apt-get update && apt-get upgradeCode language: JavaScript (javascript)

Lorsque vous avez complété cette étape, vous êtes prêt à lancer la mise à jour de PHP.

Installation de PHP7

Je découpe volontairement cette installation en plusieurs sous-étapes, par souci de clarté.

Suppression des paquets PHP5

On commence par supprimer tous les paquets relatifs à PHP5 sur le serveur:

apt-get purge php5-*Code language: JavaScript (javascript)

Résultat:

The following packages will be REMOVED:
libapache2-mod-php5* php-pear* php5* php5-apc* php5-cli* php5-common* php5-curl* php5-dev* php5-fpm* php5-gd* php5-json* php5-mcrypt* php5-mysql* php5-mysqlnd* php5-pecl-http* php5-propro* php5-raphf* php5-ssh2*

On garde cette liste sous le coude en cas de problème.

Installation des paquets PHP7

On installe les paquets PHP7 qui nous sont nécessaires:

apt-get install php7.0 php7.0-fpm php7.0-gd php7.0-mysql php7.0-cli php7.0-common php7.0-curl php7.0-opcache php7.0-jsonCode language: CSS (css)

Lire la suite

8 règles d'or pour un bon déploiement de DNSSEC et DANE photo

8 règles d’or pour bien déployer DNSSEC et DANE

Vous avez sécurisé votre domaine avec DNSSEC et DANE ? Très bien ! Il a cependant quelques petites choses à garder à l’esprit pour anticiper les difficultés et bien gérer la maintenance.

De la rigueur dans la gestion des enregistrements DS (DNSSEC) et TLSA (DANE)

Les enregistrements au niveau du DNS sont à manipuler avec précaution, ce ne sont pas le genre de choses que l’on peut configurer une bonne fois pour toute. On ne publie pas des enregistrements DS (DNSSEC) et TLSA (DANE) par effet de mode.

Les zones DNSSEC doivent être signées régulièrement et les enregistrements TLSA mis à jour en cas de changement de certificats TLS. Si la maintenance n’est pas assurée correctement, le domaine risque d’être injoignable.

Automatiser la signature de la zone DNS

Vous devez absolument mettre en place un crontab qui signe votre zone DNS automatiquement et vous informe du bon fonctionnement de votre zone.

Mettre à jour les enregistrements TLSA avant la chaine de certificat du serveur

Vous devez absolument mettre à jour les enregistrements TLSA avant de mettre à jour la chaine de certificat du serveur (déploiement de nouvelles clés ou utilisation d’un nouveau certificat TLS issu par une autorité de certification).

Lorsque vous mettez à jour votre certificat, vous devez garder les anciens enregistrements TLSA dans votre fichier de zone et ajouter les nouveaux enregistrements TLSA.

Les anciens et les nouveaux doivent donc coexister, le temps que les enregistrements DNS soient mis à jour, après quelques TTLS (quelques jours seulement).

Par exemple, la key1 est déployée initialement sur le serveur :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

On ajoute la nouvelle clé key2 pendant quelques jours, juste derrière la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 
_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Après le déploiement de la key2, on supprime la key1 :

_25._tcp.mail.example.com. IN TLSA 3 0 1 Code language: CSS (css)

Lire la suite

Serveur dédié : mise en place du protocole DANE photo 2

Serveur dédié : mise en place du protocole DANE

Aujourd’hui, je vous montre comment mettre en place le protocole DANE sur votre serveur.

En pré-requis, votre domaine doit:

  1. être servi en HTTPS avec un certificat TLS valide,
  2. être signé par DNSSEC.

Cela prend environ 20 minutes à configurer, auxquelles s’ajouteront quelques heures afin que la résolution DNS avec les changements soit complète.

DANE : l’authentification TLS sans autorité de certification

Serveur dédié : mise en place du protocole DANE photo 2

DANE (DNS-based Authentication of Named Entities) est un protocole qui permet aux certificats X.509 – généralement utilisés pour TLS – d’être liés au DNS en s’appuyant sur DNSSEC.

L’IETF a défini DANE dans la RFC 6698 comme un moyen d’authentifier des clients TLS et des serveurs sans passer par une autorité de certification (AC).

Cette démarche s’enregistre dans une logique de sécurisation des accès clients-serveurs pour d’une part sécuriser les requêtes DNS effectuées depuis les postes clients au travers des protocoles/mécanismes DNSSEC et TLS, et d’autre part mieux sécuriser les accès chiffrés des clients vers le serveurs.

Le chiffrement TLS est actuellement basé sur des certificats qui sont délivrés par des Autorités de Certification (AC ou Certificate Authority, CA en anglais).

Or, ces dernières années ont vu un certain nombre d’AC qui ont souffert de sérieux problèmes d’intrusions et de failles de sécurité, ce qui a permis la délivrance de certificats pour des sites très connus à des personnes qui ne détenaient pas ces domaines.

Faire confiance à un large nombre d’Autorités de Certification peut être un problème, étant donné que n’importe laquelle d’entre elles, si elle est compromise, pourrait délivrer un certificat pour n’importe quel nom de domaine.

Le protocole DANE permet à l’administrateur d’un nom de domaine de certifier les clés utilisées dans les clients ou serveurs TLS de ce domaine en les insérant au niveau du DNS.

DANE a donc besoin que les enregistrements DNS soient signés avec DNSSEC pour que son modèle de sécurité fonctionne.

De surcroit, DANE permet à l’adminstrateur du domaine de spécifier quelle autorité de certification est autorisée à délivrer des certificats pour une ressource particulière, ce qui résoud le problème des autorités de certification qui sont capables de délivrer des certificats pour n’importe quel nom de domaine.

Serveur dédié : mise en place du protocole DANE photo 3

Les enregistrements TLSA

DANE utilise des enregistrements TLSA, qui incluent l’empreinte du certificats X.509 qui protège un nom de domaine.

Nous devons tout d’abord générer cet enregistrement TLSA en nous basant sur le certificat installé sur notre serveur. Ensuite, cet enregistrement TLSA sera ajouté à notre zone DNS.

Lire la suite

Postfix : résoudre l'erreur SASL "_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql" photo

Postfix : résoudre l’erreur SASL “_sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql”

postfix-logo

Il y a quelques mois, j’ai aperçu quelques messages d’erreurs récurrents dans les fichiers logs du serveur de mail Postfix, concernant SASL.

Voici un extrait de ces messages:

Oct 10 11:35:05 mail postfix/smtpd[18553]: sql_select option missing
Oct 10 11:35:05 mail postfix/smtpd[18553]: auxpropfunc error no mechanism available
Oct 10 11:35:05 mail postfix/smtpd[18553]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: sql

La solution est toute simple – commencez par éditer le fichier de configuration de Postfix:

nano /etc/postfix/main.cf

Puis commentez la ligne qui commence par smtpd_sasl_path. Chez moi, cela donne :

#smtpd_sasl_path = private/authCode language: PHP (php)

Et enfin, il suffit de relancer tous les services relatifs à l’identification SASL ainsi que Postfix :

find /etc/init.d/ | grep courier | while read line; do $line restart; done
service saslauthd restart
service postfix restartCode language: PHP (php)

Et voilà, plus de messages d’erreur dans les logs.

Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine photo

Serveur dédié : mettre en place DNSSEC pour sécuriser les DNS du domaine

Aujourd’hui, nous allons mettre en place DNSSEC afin d’ajouter une couche de sécurité supplémentaire dans la gestion des DNS de notre domaine.

Principe de fonctionnement du DNS

Le DNS (Domain Name System) est un maillon clé du fonctionnement d’Internet car la quasi-totalité des services en ligne utilisent des noms de domaine à un moment ou à un autre.

Le DNS est organisé sous la forme d’une arborescence inversée, avec une « racine » dont dépendent les différentes « branches ».

Au premier niveau de l’arborescence se trouvent les « Top Level Domains » (TLD) ou domaines de premier niveau, comme les .fr, .com, .net etc.

Au second niveau, nous avons les noms de domaine « classiques » comme « skyminds.net ».

Fonctionnant comme une base de données distribuée sur des millions de machines, le DNS repose sur des interactions entre ces machines permettant d’identifier celle qui est la plus susceptible de pouvoir répondre à la requête d’un internaute.

Serveur dédié : mise en place de DNSSEC pour sécuriser les DNS d'un nom de domaine photo 2

Dans l’exemple ci-dessus, l’utilisateur veut se connecter au site http://www.wikipedia.fr. Il envoie sa requête via son navigateur. Celle-ci est reçue par un serveur dit « résolveur » qui a pour première mission d’identifier la machine sur laquelle est installé le nom de domaine wikipedia.fr.

Le résolveur s’adresse d’abord à la « racine » du DNS, qui lui indique quels sont les serveurs « faisant autorité » (c’est-à-dire compétents) pour .fr puisque le nom de domaine est en .fr.

Dans un second temps, les serveurs du .fr indiquent à leur tour au résolveur que le nom de domaine wikipedia.fr est hébergé sur tel serveur.

Celui-ci est alors en mesure d’indiquer au navigateur l’adresse IP du serveur web hébergeant les contenus du site web www.wikipedia.fr.

Ce schéma se vérifie quel que soit le site web auquel on souhaite accéder.

DNSSEC : authentifier l’origine et l’intégrité des données

DNSSEC, acronyme de Domain Name System Security Extensions, désigne un ensemble défini d’extensions de sécurité du protocole DNS, standardisé par l’IETF dans la RFC 4033.

Lire la suite

Serveur dédié : générer de l'entropie additionnelle avec Haveged photo

Serveur dédié : produire une meilleure réserve d’entropie avec haveged

Sur notre serveur dédié, nous avons parfois besoin de générer des nombres aléatoires avec une forte entropie, par exemple lorsque l’on génère une clé SSH, un certificat SSL/TLS ou une clé pour DNSSEC.

Aujourd’hui, je vous propose donc un article un petit peu plus théorique, qui nous permettra d’améliorer la qualité des données aléatoires et l’entropie générale de notre serveur.

On commence donc par la théorie et on enchaîne sur la partie technique.

L’entropie ou le caractère aléatoire sous Linux

Le chiffrement est basé sur deux facteurs principaux : les nombres premiers et les nombres aléatoires.

Sous Linux, les nombres aléatoires sont générés par le pseudo random number generator (PRNG) qui génère des données aléatoires depuis les interruptions matérielles (clavier, souris, accès disque, accès réseau…) et depuis d’autres sources provenant du système d’exploitation.

Serveur dédié : générer de l'entropie additionnelle avec Haveged photo 1

Une interruption matérielle (en anglais Interrupt ReQuest ou IRQ) est une interruption déclenchée par un périphérique d’entrée-sortie d’un microprocesseur ou d’un microcontrôleur.

Ce caractère aléatoire ou aléa, que l’on désigne sous le terme entropie, est utilisé principalement pour le chiffrement comme SSL/TLS mais peut aussi avoir plein d’utilisations pratiques (génération de mots de passe, de clés, de chaînes de caractères aléatoires…).

Lire la suite

BASH : lister, bloquer et débloquer des adresses IP avec iptables photo 1

BASH : lister, bloquer et débloquer des adresses IP avec iptables

Sur un serveur dédié, il n’est pas rare d’avoir des adresses IP à bannir pour se débarrasser de visiteurs malveillants, de spammeurs ou de bots qui effectuent des requêtes farfelues visant à perturber le bon fonctionnement des services du serveur.

Heureusement, toutes ces petites contrariétés peuvent être résolues en quelques secondes grâce à un firewall comme iptables.

Ce petit tutoriel vous montre les quelques commandes à retenir pour lister, bannir ou débloquer des adresses IP avec iptables ainsi qu’un petit script bash qui vous permettra d’automatiser la gestion de ces trois fonctions très simplement.

Bannir une IP

Pour bannir une adresse IP avec iptables, il suffit de lancer cette commande:

iptables -I INPUT -s x.x.x.x -j DROPCode language: CSS (css)

L’argument DROP indique que l’adresse IP indiquée (x.x.x.x) n’aura plus accès à la machine.

Lister les IP bloquées

Pour voir la liste des adresses IP bloquées, il suffit de demander à iptables la liste et de ne sélectionner que celles qui sont en DROP:

iptables -L INPUT -v -n | grep DROP

Résultat :

Chain INPUT (policy DROP 23 packets, 4122 bytes)

Débloquer une IP

Pour débloquer une IP, il faut d’abord afficher la liste des IP bannies:

iptables -L INPUT -v -n | grep DROP

Toutes les IP sont classées dans un ordre numéroté, ligne par ligne. Il suffit d’indiquer le numéro de la ligne de la règle à supprimer avec la commande:

iptables -D INPUT numero-de-la-regle

L’argument -D (pour delete) permet de supprimer la règle qui correspond à l’adresse IP que nous souhaitons supprimer. Par exemple, si on veut supprimer la règle 1, il suffit d’indiquer:

iptables -D INPUT 1

Vous aurez remarqué que toutes ces commandes sont bien fastidieuses et leurs syntaxes assez complexes à retenir.

Voyons donc comment créer un script bash qui prendrait en charge toutes ces commandes.

Script Bash pour automatiser la gestion des IP bannies dans iptables

Bash

Voici un script bash qui devrait grandement vous simplifier la gestion des IP dans iptables.

Il permet de bloquer, débloquer et lister les adresses IP en toute simplicité.

Lire la suite

Serveur dédié : migration de MySQL vers MariaDB photo

Serveur dédié : migration de MySQL vers MariaDB

Aujourd’hui, on aborde la migration du serveur de base de données : nous passons de l’historique MySQL à son fork libre MariaDB.

Les raisons de remplacer Oracle MySQL avec MariaDB sont nombreuses.

MySQL vs MariaDB

Tout d’abord, MariaDB assure la compatibilité et la continuité de service avec MySQL. Les librairies sont exactement équivalentes et permettent d’utiliser les APIs et commandes de MySQL.

Les performances de MariaDB sont souvent meilleures que celles de MySQL, notamment grâce à l’amélioration de l’optimiseur de requêtes et l’intégration du moteur XtraDB de Percona, qui vise à remplacer InnoDB.

Un nouveau moteur de stockage, Aria, a été écrit pour devenir un moteur à la fois transactionnel et non-transactionnel pour remplacer MyISAM. Il pourrait même être inclus dans de prochaines versions de MySQL.

Dans un autre registre, Oracle semble ne pas vouloir garder le modèle libre de MySQL : pas mal de choses (rapports de bugs, scénarios de test) sont maintenant disponibles uniquement pour les grands comptes payants.

Michael “Monty” Widenius, le fondateur de MySQL AB, a quitté Sun Microsystems lors de son rachat par Oracle pour créer Monty Program AB puis la Fondation MariaDB. Il est rapidement rejoint par de nombreux développeurs originaux de MySQL.

Ces développeurs maîtrisent donc parfaitement le code source du système de gestion de base de données, cela promet encore de nombreuses nouveautés et optimisations pour les versions suivantes.

Installation de MariaDB

Avant toute chose, faîtes une sauvegarde de vos bases de données. On ne sait jamais.

Notre serveur dédié tourne toujours sur Debian stable et les paquets de MariaDB sont disponibles dans les dépôts officiels.

mariadb-seal-logo

MariaDB est un “drop-in replacement” pour MySQL, c’est -à-dire qu’il suffit de désinstaller MySQL et d’installer MariaDB : rien ne change, pas de pertes de données, pas de lignes de code à changer, tout est compatible.

L’installation est donc très simple :

apt-get install mariadb-serverCode language: JavaScript (javascript)

Résultat:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common
  mariadb-server-10.0 mariadb-server-core-10.0
Suggested packages:
  mariadb-test tinyca
The following packages will be REMOVED:
  mysql-client-5.6 mysql-client-core-5.6 mysql-server mysql-server-5.6
  mysql-server-core-5.6
The following NEW packages will be installed:
  mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server
  mariadb-server-10.0 mariadb-server-core-10.0
0 upgraded, 6 newly installed, 5 to remove and 0 not upgraded.
Need to get 11.8 MB of archives.
After this operation, 18.4 MB disk space will be freed.Code language: CSS (css)

L’installation vous demandera de donner un mot de passe pour l’utilisateur root. De manière à assurer la continuité avec MySQL, j’ai redonné le même mot de passe que pour mon utilisateur root sous MySQL.

Lire la suite

hourglass

Serveur dédié : optimiser toutes les images GIF avec GIFsicle

Après avoir vu comment optimiser les fichiers JPG et PNG sur le serveur, voici comment optimiser les fichiers GIF.

hourglass

Comme dans le tutoriel précédent, nous allons optimiser toutes nos images d’un seul coup, de manière à charger nos pages plus rapidement et à consommer moins de bande passante.

Pour optimiser les fichiers GIF, j’ai choisi GIFsicle.

L’installation et la compression de vos répertoires d’images prend à peine quelques minutes.

Installation de GIFsicle

On installe le paquet :

apt-get install gifsicleCode language: JavaScript (javascript)

et on RTFM :

man gifsicle

Optimisation des PNG

Pour optimiser les fichiers GIF, il suffit de lancer :

gifsicle --batch -O3 *.gifCode language: CSS (css)

L’argument --batch permet de gérer plusieurs fichiers et -O3 permet la meilleure optimisation possible, en essayant plusieurs combinaisons de compression pour trouver le ratio le plus intéressant.

Lire la suite

Serveur dédié : installer la dernière version d'OpenSSL sous Debian photo

Bash : lister et redémarrer tous les services qui utilisent libssl après une mise à jour d’OpenSSL

Lorsque l’on met à jour OpenSSL, tous les services qui utilisent les librairies SSL et qui sont chargés en mémoire ne rechargent pas les librairies (dont libssl) qui viennent d’être mises à jour.

Idéalement, il faudrait rebooter le système mais lorsqu’il s’agit d’un serveur, ce n’est pas toujours possible. Si les services ne sont pas redémarrés (restart) ou rechargés (reload) après une mise à jour, ils seront toujours vulnérables aux problèmes de sécurité que corrige la nouvelle version.

Voici donc comment détecter les services qui utilisent les librairies d’OpenSSL afin de les redémarrer et éviter de rebooter la machine.

Lister les services qui utilisent libssl

Vérifiez que votre système possède la commande lsof. Elle devrait normalement être prise en charge par votre gestionnaire de paquets.

Pour lister les services qui utilisent OpenSSL, il suffit de vérifier lesquels utilisent le paquet libssl en les classant par ordre alphabétique et en supprimant les doublons:

lsof | grep libssl | awk '{print $1}' | sort | uniqCode language: JavaScript (javascript)

Résultat:

apache2
fail2ban-
opendkim
php5-fpm
tlsmgr

Il ne vous reste plus qu’à redémarrer les services présents dans cette liste qui font appel à OpenSSL.

Lister les services qui utilisent une ancienne version de libssl

Si vous avez mis à jour OpenSSL mais que vous n’avez pas redémarré votre serveur, il est possible que certains services utilisent toujours une ancienne librairie non-patchée d’OpenSSL.

Lire la suite

Bash : réparer les tables MySQL en cas de crash photo

Bash : rechercher une chaîne dans des fichiers de manière récursive avec Grep

Bash

Voici une petite technique utile pour rechercher la présence d’une chaine de texte dans le contenu des fichiers d’un répertoire.

Sous linux, j’utilise très fréquemment la commande grep.

La syntaxe de grep

La syntaxe de grep est toute simple puisqu’elle consiste à définir des options de recherche, suivies des mot-clés à chercher, et enfin du répertoire de travail.

Voilà ce que cela nous donne :

grep [option] "text string to search" directory-pathCode language: JavaScript (javascript)

Grep en action

Sur le serveur, on se place dans le répertoire de travail pour y lancer cette commande :

grep --color --include=\*.{php,js,css} -rnwe "recherche" . Code language: PHP (php)

Voici le détail des arguments :

  • --color : pour activer la colorisation des résultats
  • --include=\*.{php,js,css} : les extensions de fichiers à cibler
  • -r : de manière récursive
  • -n : avec les numéros de ligne
  • -w : mots complets de la recherche (recherche stricte)
  • -e : active la regex sur les extensions de fichiers

Note : le terme à recherche doit être entre guillemets et il faut bien ajouter le point (.) final ou alors explicitement donner le chemin complet du répertoire de travail.

Grep et les expressions régulières

Il est également possible d’utiliser des expressions régulières avec Grep :

grep --color -HnR "add_[a-zA-Z].*_page.*, [0-9]*," /home/public_html/wp-content/plugins/Code language: JavaScript (javascript)

Très utile pour rapidement trouver une fonction devenue obsolète ou un bout de code utilisé dans plusieurs fichiers.

MySQL : convertir les tables MyISAM au format InnoDB photo

MySQL : convertir les tables MyISAM au format InnoDB

MySQL : MyISAM et InnoDB

A ses débuts, MySQL utilisait le moteur de stockage MyISAM.

C’est la raison pour laquelle on retrouve beaucoup d’exemples de création de tables sur Internet avec l’instruction engine=MyISAM (ce qui, au passage, peut faire planter pas mal de créations de bases/tables).

Aujourd’hui, le moteur de stockage par défaut de MySQL est InnoDB.

MyISAM n’est plus activement développé, à l’inverse d’InnoDB. Il est donc recommandé de convertir les tables MyISAM au format InnoDB, afin de bénéficier des dernières optimisations de performance du nouveau moteur.

innodb-myisam-mysql

Le moteur InnoDB

InnoDB est un moteur de stockage inclus d’origine dans toutes les distributions fournies par MySQL AB. Son principal avantage par rapport aux autres moteurs de stockage de MySQL est qu’il permet des transactions ACID (Atomiques, Cohérentes, Isolées et Durables), ainsi que la gestion des clés étrangères (avec vérification de la cohérence).

Toutes les bases de données sont stockées au même endroit. Par défaut dans le fichier ibdata1 qui, sous les systèmes de type unix, se trouve généralement dans /var/lib/mysql. Il est également possible d’utiliser plusieurs fichiers ou même d’utiliser directement une ou plusieurs partitions sur le disque en mode RAW.

Ce moteur de base de données utilise aussi deux fichiers de logs, d’habitude ib_logfile0 et ib_logfile1. Les fichiers de définitions de table .frm sont également dans un dossier au nom de la base comme pour MyISAM.

Depuis sa version 5.5, MySQL utilise InnoDB comme moteur par défaut.

Comment connaitre le format actuel de vos tables ?

Pour faire un petit état des lieux du format actuel des tables de votre base de données, il suffit de vous identifier sur le serveur SQL et de lancer cette requête :

SHOW TABLE STATUS FROM `database`;Code language: JavaScript (javascript)

Il vous suffit de remplacer database par le nom de votre base de données et de regarder la valeur de la colonne Engine.

Convertir les tables MyISAM au format InnoDB

Pour convertir des tables MyISAM au format InnoDB, il suffit de lancer une requête SQL va grandement nous simplifier la vie:

SELECT CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')
FROM information_schema.tables
WHERE 1=1
    AND engine = 'MyISAM'
    AND table_schema NOT IN ('information_schema', 'mysql', 'performance_schema');Code language: JavaScript (javascript)

Le résultat de cette requête est une liste bien formatée de requêtes à lancer pour que toutes nos tables soient converties au format InnoDB.

Voici le résultat de cette requête sur le serveur :

+-----------------------------------------------------------+
| CONCAT('ALTER TABLE ',table_schema,'.',table_name,' ENGINE=InnoDB;')   |
+-----------------------------------------------------------+
| ALTER TABLE blog.blog_wc_comments_subscription ENGINE=InnoDB;
| ALTER TABLE blog.blog_wc_phrases ENGINE=InnoDB;
| ALTER TABLE blog.blog_wc_users_voted ENGINE=InnoDB;
+-----------------------------------------------------------+Code language: JavaScript (javascript)

Toutes les tables des bases de données qui sont au format MyISAM au format InnoDB sont listées, à l’exception des tables utilisées dans la gestion de MySQL (‘information_schema’, ‘mysql’, ‘performance_schema’) qui doivent rester en MyISAM.

Etape de Conversion

Il vous suffit ensuite de lancer cette liste de requêtes ALTER TABLE sous MySQL, Adminer ou PHPMyAdmin pour convertir vos tables. Lancez la liste de commandes que vous venez de trouver :

ALTER TABLE blog.blog_wc_comments_subscription ENGINE=InnoDB;
ALTER TABLE blog.blog_wc_phrases ENGINE=InnoDB;
ALTER TABLE blog.blog_wc_users_voted ENGINE=InnoDB;

Et voilà, vos tables MyISAM sont maintenant devenues des tables InnoDB.

Lire la suite