Activer SSH sous CPanel photo 4

Résoudre l’erreur SSH: Missing privilege separation directory: /run/sshd

Sur un nouveau serveur à base d’Ubuntu Server 18.04, j’obtiens cette erreur à la suite d’un test du service ssh:

sshd -t

Could not load host key: /etc/ssh/ssh_host_ed25519_key
Missing privilege separation directory: /run/sshdCode language: JavaScript (javascript)

Les solutions à ces deux problèmes sont triviales, cela se règle en deux petites commandes.

L’erreur Could not load host key

L’erreur Could not load host key survient lorsque certaines clés SSH n’ont pas été générées lors de l’installation du système d’exploitation du serveur.

Dans le cas du serveur qui nous occupe, il nous manque la clé de chiffrement ED25519 qui doit se trouver à l’adresse /etc/ssh/ssh_host_ed25519_key.

Pour générer toutes les clés de chiffrement SSH manquantes, une seule commande suffit:

ssh-keygen -A

L’argument -A signifie que l’on génère toutes les clés (All keys). Voici le résultat sur le serveur:

ssh-keygen: generating new host keys: ED25519Code language: JavaScript (javascript)

L’erreur Missing privilege separation directory: /run/sshd

Cette erreur apparaît lorsque le répertoire mentionné – ici /run/sshd – n’a pas été correctement créé. Il suffit de le créer:

mkdir -p /run/sshd

Vérifiez la configuration SSH:

sshd -t

S’il n’y a plus d’erreur, vous pouvez alors redémarrer le service ssh:

service ssh restart

Et voilà, problèmes réglés.

No hotlinking for images

NginX: éviter le hotlinking

Le hotlinking

Le hotlinking (ou liaison automatique ; aussi connu en anglais sous les noms de inline linking, leeching, piggy-backing, direct linking ou offsite image grabs) consiste à utiliser l’adresse d’un fichier publié sur un site web, le plus souvent une image, pour l’afficher sur un autre site, sur un blog, dans un forum, etc.

En d’autres termes, au lieu d’enregistrer l’image et de l’installer sur son propre serveur Web, le hotlinkeur crée un lien direct vers le serveur d’origine.

Si vous êtes sous Apache, voici comment supprimer le hotlinking sous Apache Server.

Désactiver le hotlinking sous NginX

Sous NginX, il peut être très utile d’éviter que des gens publient vos photos ou images depuis votre site sur le leur, en gardant les liens de votre serveur et en consommant toute votre bande passante (ce qui peut représenter un surcoût pour vous).

Il suffit d’éditer votre server block et d’y ajouter cette directive:

location ~ \.(gif|png|jpeg|jpg|svg|webp|avif)$ {
    # Define allowed referers - your own domain and specific external domains
    valid_referers none blocked 
                  ~\.google\. 
                  ~\.bing\. 
                  ~\.yahoo\. 
                  ~\.facebook\. 
                  ~\.pinterest\. 
                  ~\.twitter\. 
                  yourdomain.com 
                  *.yourdomain.com 
                  server_names;

    # Block requests with no or invalid referer
    if ($invalid_referer) {
        return 403;
    }
}
Code language: PHP (php)

N’hésitez pas à rajouter les domaines que vous souhaitez whitelister et qui sont autorisés à utiliser vos fichiers média.

Relancez ensuite NginX avec:

service nginx restart

Cela devrait quelque peu soulager votre serveur et garantir votre bande passante à vos visiteurs.

Linux : obtenir la valeur numérique du chmod photo

Linux : obtenir la valeur numérique du chmod

chmod permissions compressor

Je vous ai déjà parlé du chmod et du chown de manière extensive mais aujourd’hui on va un tout petit peu plus loin.

La valeur du chmod telle qu’elle apparaît dans le terminal est un peu esotérique. Prenons par exemple le chmod d’un fichier standard de WordPress : -rw-r-----, cela demande une petite gymnastique intellectuelle pour réaliser quels sont les droits véritables.

Je vous propose donc une petite commande qui va vous simplifier la vie, de manière à vous donner la valeur numérique du chmod des fichiers et répertoires.

Il vous suffit d’utiliser la commande stat comme ceci, dans votre fenêtre de terminal:

stat -c '%a %U:%G %n' *Code language: JavaScript (javascript)

Notes:

  • -c permet de formater la sortie avec la template entre apostrophes
  • %a donne la valeur octale du chmod
  • %U donne le nom de l’utilisateur du chown
  • %G donne le groupe de l’utilisateur du chown
  • %n donne le nom du fichier

Et voilà simple et efficace!

Activer SSH sous CPanel photo 4

Activer SSH sous CPanel

ssh logo

Il peut être extrêmement utile d’activer la connexion SSH chez certains hébergeurs qui la proposent, comme SiteGround. Cela permet de gagner pas mal de temps, notamment lorsque l’on utilise wp-cli.

Mais avant de pouvoir se connecter, il faut d’abord l’activer dans les options de CPanel.

Activation de la connection SSH dans CPanel

Rendez-vous dans CPanel > Security > SSH Shell Access :

cpanel ssh

Ensuite, cliquez sur le bouton Manage SSH Keys:

cpanel ssh manage

Nous avons ensuite le choix entre deux solutions : soit nous créons la paire de clés privées/publiques sur le serveur et nous les copions sur notre machine locale, soit nous la créons en locale et l’envoyons sur le serveur. Je suis plutôt pour la seconde solution.

Création des clés SSH

On se rend dans le répertoire SSH de notre utilisateur et on liste le répertoire:

cd ~/.ssh
ls

Si le fichier id_rsa.pub existe déjà, il suffit d’afficher son contenu:

cat id_rsa.pubCode language: CSS (css)

Si le fichier n’existe pas, il suffit de le créer:

ssh-keygen

Copiez le contenu du fichier, il s’agit de la clé publique que nous allons importer dans CPanel.

Import de notre clé SSH dans CPanel

Cliquez sur Import Key:

cpanel ssh import

Renommez la clé pour id_rsa puis collez le contenu de votre clé SSH publique:

cpanel ssh import ssh key

Il ne vous reste plus qu’à vous connecter en SSH au serveur. Suivant votre hébergeur, le numéro du port SSH peut changer pour des raisons de sécurité. Chez SiteGround, SSH tourne sur le port 18765:

ssh CPANEL_USER@CPANEL_SERVER -p18765Code language: CSS (css)

Bon ssh !

NAS Synology : regarder les vidéos du NAS directement sur la Freebox en DLN photo

NAS Synology : regarder les vidéos du NAS directement sur la Freebox en DLNA

J’utilise mon NAS Synology tous les jours et l’une des fonctions que j’affectionne particulièrement est de pouvoir regarder des vidéos directement sur la télévision, en passant par la Freebox.

NAS Synology : regarder les vidéos du NAS directement sur la Freebox en DLN photo

Il existe plusieurs manières de regarder les vidéos stockées sur le NAS sur la télévision : depuis la Freebox, depuis un navigateur avec VideoStation ou depuis votre mobile avec l’application DS Video.

Lire des vidéos avec fichiers de sous-titres depuis la Freebox

Il suffit de se rendre dans le menu Freebox > Disques et de sélectionner votre NAS, qui s’appelle par défaut “DiskStation” chez Synology.

La Freebox affiche la liste des fichiers vidéos, films, séries tels qu’ils sont sur le NAS, ainsi que les fichiers de sous-titres au format .SRT s’ils sont présents sur le NAS, si vous avez suivi le tutoriel NAS Synology : lire des vidéos avec des fichiers de sous-titres en DLNA sur la Freebox.

Si le fichier de sous-titre porte le même nom que le fichier vidéo auquel il se rattache, alors la Freebox le chargera automatiquement. Vous pouvez alors le désactiver en appuyant sur la touche Menu verte de la télécommande Free.

C’est la méthode que j’utilise au quotidien mais il faut avoir prévu de télécharger les bons sous-titres, s’être assuré que le nom ne diffère pas et les avoir mis dans le même répertoire que le fichier vidéo… cela demande un peu de manutention avant de pouvoir se caler dans le canapé.

Lire des vidéos avec sous-titres chargés à la volée depuis le NAS

Une seconde solution consiste à lancer le fichier depuis le webdamin du Synology : démarrez l’application VideoStation et sélectionnez le fichier à lire.

Allumez ensuite votre télévision et le Freebox Player pour qu’il soit détecté par l’application VideoStation.

Si vous cliquez sur la petite icône Réglages du lecteur vidéo, il est possible de charger des sous-titres à la volée dans la section Sous-Titres :

Synology : regarder les vidéos du NAS sur la Freebox photo

Il ne vous reste plus qu’à sélectionner la destination vidéo vers laquelle envoyer la vidéo en flux DLNA dans la section Source. Ici, nous choisissons Freebox Player en DLNA:

Synology : regarder les vidéos du NAS sur la Freebox photo 1

Il suffit de cliquer sur le bouton lecture et la vidéo sera directement projetée sur la télévision par le biais du Freebox Player.

Lire vidéos et sous-titres depuis l’application mobile DS Video

Je vous ai gardé le meilleur pour la fin : vous pouvez lancer les vidéos du Synology et activer les sous-titres à la volée depuis l’application mobile DS Video, à installer sur votre téléphone portable.

DS Video est une application gratuite, à télécharger : DS Video pour Android (Play Store) ou alors DS Video pour iPhone (AppStore).

Synology : regarder les vidéos du NAS sur la Freebox photo 2

C’est le meilleur des deux mondes : plus besoin de courir sur l’ordinateur pour lancer la vidéo. Il suffit de :

  1. lancer DS Video,
  2. se connecter au Synology avec votre compte habituel,
  3. ne pas activer HTTPS (très important),
  4. choisir la vidéo à lire,
  5. régler les options : sous-titres, sortie vidéo vers le Freebox Player.

Et profiter ! Plus besoin de quitter le canapé cette fois ;-)

Redémarrer la machine virtuelle de Local by Flywheel photo

Redémarrer la machine virtuelle de Local by Flywheel

Si vous utilisez Local by Flywheel pour développer un site WordPress en local, il peut arriver que la machine virtuelle ne réponde plus et ne veuille plus redémarrer, ce qui rend toute utilisation de Local impossible.

Voici donc comment redémarrer la machine virtuelle de Local by Flywheel.

Redémarrer la machine virtuelle de Local by Flywheel

Si la machine virtuelle ne répons plus, il faut redémarrer la VM local-by-flywheel dans VirtualBox.

1. Ouvrez VirtualBox:

  • macOS: appuyez sur Command + Espace et tapez “VirtualBox” et validez avec Entrée pour ouvrir VirtualBox.
  • Windows: ouvrez le menu Démarrer de Windows ettapez “VirtualBox” et validez avec Entrée pour ouvrir VirtualBox.

2. Faites un clic droit sur local-by-flywheel et cliquez sur Fermer » Redémarrage ACPI.

3. Attendez que la machine virtuelle affiche “Powered Off…”

Si la machine virtuelle n’affiche pas “Powered Off…” après 5 minutes, répétez l’étape 2 et sélectionnez Fermer > Éteindre.

4. Fermez VirtualBox.

5. Ouvrez de nouveau Local.

J’espère que cela peut vous aider.

La machine virtuelle a souvent tendance à planter et fermer/réouvrir Local ne suffit pas toujours. Il faut vraiment relancer le conteneur sous VirtualBox puis relancer Local.

Serveur dédié : installation de MariaDB 10.3 photo

MariaDB : résoudre l’erreur “Column count of mysql.proc is wrong”

Sur l’un des serveurs de mes clients Codeable, j’ai mis à jour MariaDB de la version 10.1 à la version 10.3 et voici ce que retournait MariaDB lors du lancement de procédures:

ERROR 1558 (HY000): Column count of mysql.proc is wrong. Expected 21, found 20. 
Created with MariaDB 100212, now running 100303. 
Please use mysql_upgrade to fix this errorCode language: JavaScript (javascript)

Si cela arrive, pas de panique: MariaDB fonctionne et le site s’affiche mais la base de données mysql n’a pas été mise à jour par apt, il faut lancer la procédure d’installation manuellement, depuis le terminal.

On met donc la base mysql à jour avec mysql-upgrade:

mysql_upgrade -u root -p

et on relance MariaDB:

service mysql restart

La routine de mise à jour mysql_upgrade permet de mettre à jour la base interne de MariaDB, qui évolue au fil des mises à jour.

Au redémarrage du service, plus de problème avec les procédures SQL.

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key photo

WordPress : résoudre le problème de la table wp_options à qui manquent une colonne Unique et une Primary Key

Chez Codeable, j’ai travaillé sur l’optimisation d’un site e-commerce propulsé par WooCommerce récemment, qui connaissait quelques problèmes de lenteur.

Sous phpMyAdmin, on trouvait également cette erreur:

Current selection does not contain a unique column

Si vous obtenez cette erreur, c’est que la structure de la table wp_options n’est pas à jour donc nous la vérifions avec wp-cli:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Le résultat obtenu nous montre qu’il n’y a pas de clé primaire (primary key) qui est normalement option_id et qu’il n’y a pas de restriction unique imposée sur la colonne option_name:

+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| option_id    | bigint(20) unsigned | NO   |     | NULL    |       |
| option_name  | varchar(191)        | YES  |     | NULL    |       |
| option_value | longtext            | NO   |     | NULL    |       |
| autoload     | varchar(20)         | NO   |     | yes     |       |
+--------------+---------------------+------+-----+---------+-------+Code language: PHP (php)

Et c’est là que le bât blesse – voici à quoi ressemble la structure standard de la table wp-options:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI | NULL    |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   | MUL | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Ajouter la Primary Key manquante à wp_options

On ajoute à la colonne option_id la clé primaire qui lui manque:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options MODIFY option_id INT AUTO_INCREMENT PRIMARY KEY;" --allow-rootCode language: JavaScript (javascript)

Et on vérifie le résultat:

wp db query "DESCRIBE $(wp db prefix --allow-root)options" --allow-rootCode language: JavaScript (javascript)

Ajouter la contrainte Unique qui manque à wp_options

Pour ajouter la contrainte UNIQUE à la colonne option_name, on lance:

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Là, il est possible que cela bloque, suivant ce qui se trouve dans votre table wp_options.

Résoudre le problème des doublons

Si vous obtenez une erreur comme :

ERROR 1062 (23000) at line 1: Duplicate entry 'jetpack_available_modules' for key 'option_name'Code language: JavaScript (javascript)

alors cela signifie qu’il existe des enregistrements option_name dupliqués, des doublons qui portent le même nom alors que chaque nom option_name devrait être unique.

On peut obtenir la liste des enregistrements option_name doublons avec cette requête:

wp db query "SELECT option_name, COUNT(*) optioncount FROM $(wp db prefix --allow-root)options GROUP BY option_name HAVING optioncount > 1 ORDER BY optioncount DESC;" --allow-rootCode language: JavaScript (javascript)

Par ordre ascendant, voici la liste des doublons:

+---------------------------------------------+-------------+
| option_name                                 | optioncount |
+---------------------------------------------+-------------+
| jetpack_callables_sync_checksum             |       47123 |
| jetpack_sync_full_config                    |          50 |
| jetpack_sync_full_enqueue_status            |          43 |
| jpsq_sync_checkout                          |          10 |
| jetpack_sync_full__params                   |           5 |
| jetpack_sync_settings_sync_via_cron         |           4 |
| jetpack_sync_full__started                  |           4 |
+---------------------------------------------+-------------+

On peut supprimer automatiquement tous les doublons option_name de deux manières différentes, soit en utilisant la plus vieille valeuroption_id(donc la plus petite valeur d’ID), soit en utilisant la valeuroption_id la plus récente (plus grande valeur d’ID).

Garder le doublon option_name le plus ancien

Voici la requête SQL qui montre uniquement le plus ancien enregistrement (MIN) option_id pour chaque doublon de valeur option_name:

SELECT *
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options
        GROUP BY n.option_name) x)Code language: CSS (css)

Une fois que vous avez vérifié le résultat, on peut passer à la suppression.

Cette requête SQL garde l’enregistrement (MIN) option_id le plus ancien de tous les doublonsoption_name et supprime tous les enregistrements plus récents que la valeur trouvée:

DELETE
FROM wp options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MIN(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MIN(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Garder le doublon option_name le plus récent

Cette requête SQL ne montre que les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name :

SELECT *
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Et voici la requête qui permet de garder les enregistrements option_id les plus récents (MAX) pour tous les doublons option_name en supprimant tous les doublons les plus anciens:

DELETE
FROM wp_options
WHERE option_id NOT IN
    (SELECT *
     FROM
       (SELECT MAX(n.option_id)
        FROM wp_options n
        GROUP BY n.option_name) x)Code language: CSS (css)

Voici l’équivalent wp-cli pour garder l’enregistrement option_name le plus récent:

wp db query "DELETE FROM $(wp db prefix --allow-root)options WHERE option_id NOT IN (SELECT * FROM (SELECT MAX(n.option_id) FROM $(wp db prefix --allow-root)options n GROUP BY n.option_name) x)" --allow-rootCode language: JavaScript (javascript)

Vérifier les clés et contraintes de la table wp_options

Ajoutons de nouveau la contrainte UNIQUE sur la colonne option_name :

wp db query "ALTER TABLE $(wp db prefix --allow-root)options ADD UNIQUE (option_name);" --allow-rootCode language: JavaScript (javascript)

Si vous n’obtenez pas d’erreur, vérifiez la table une nouvelle fois pour constater les changements:

wp db query "DESCRIBE $(wp db prefix --allow-root)options;" --allow-rootCode language: JavaScript (javascript)

Kaboom! Votre table wp_options possède maintenant une PRIMARY KEY sur la colonne option_id et la contrainte UNIQUE sur la colonne option_name:

+--------------+---------------------+------+-----+---------+----------------+
| Field        | Type                | Null | Key | Default | Extra          |
+--------------+---------------------+------+-----+---------+----------------+
| option_id    | bigint(20) unsigned | NO   | PRI | NULL    | auto_increment |
| option_name  | varchar(191)        | NO   | UNI |         |                |
| option_value | longtext            | NO   |     | NULL    |                |
| autoload     | varchar(20)         | NO   |     | yes     |                |
+--------------+---------------------+------+-----+---------+----------------+Code language: PHP (php)

Je vous conseille de vérifier la structure de la table de temps à autre, notamment si vous constatez une prise de poids anormale en très peu de temps

Serveur dédié : installation de MariaDB 10.3 photo

MariaDB ne veut plus redémarrer : quelques solutions

MariaDB ne veut plus se lancer

Sur le serveur chinois que j’ai monté pour un de mes clients sur Codeable, le site a commencé à afficher des erreurs étranges : erreur 502 pour nginx sur certaines pages et des nombres étranges en lieu et place des données de la base de données.

Après un redémarrage des services PHP, nginx et mysql, je constate que MariaDB veut bien s’arrêter mais ne veut plus de lancer.

Voici ce que donne:

systemctl status mariadb.serviceCode language: CSS (css)

Résultat:

● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Mon 2019-04-22 18:14:22 CST; 59s ago
  Process: 721 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 718 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12274 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=1/FAILURE)
  Process: 12179 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12176 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12173 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12274 (code=exited, status=1/FAILURE)
   Status: "MariaDB server is down"
systemd[1]: Starting MariaDB database server…
mysqld[12274]: 2019-04-22 18:14:19 140194687476288 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12274 …
systemd[1]: mariadb.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start MariaDB database server.
systemd[1]: mariadb.service: Unit entered failed state.
systemd[1]: mariadb.service: Failed with result 'exit-code'.Code language: PHP (php)

Bon, chou blanc. Cela ne nous donne aucune information exploitable quand à l’erreur qui empêche le démarrage du service de base de données.

Solution: vérifier l’espace disponible sur le disque du serveur

On regarde ensuite ce que nous donnent les logs de MariaDB:

tail -f /var/log/mysql/error.logCode language: JavaScript (javascript)

Résultat:

2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Completed initialization of buffer pool
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Highest supported file format is Barracuda.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: 128 rollback segment(s) are active.
2019-04-22 18:14:19 140194687476288 [Note] InnoDB: Waiting for purge to start
2019-04-22 18:14:19 140194687476288 [Note] InnoDB:  Percona XtraDB (http://www.percona.com) 5.6.36-82.1 started; log sequence number 11397472969
2019-04-22 18:14:19 140194687476288 [Note] Plugin 'FEEDBACK' is disabled.
2019-04-22 18:14:19 140194687476288 [ERROR] mysqld: Can't change size of file (Errcode: 28 "No space left on device")
2019-04-22 18:14:19 140194687476288 [ERROR] Can't init tc log
2019-04-22 18:14:19 140194687476288 [ERROR] AbortingCode language: PHP (php)

Là, c’est beaucoup plus intéressant. Visiblement, deux erreurs majeures sont à l’origine du non-démarrage du service:

  • il n’y a plus d’espace disponible sur le disque dur du serveur,
  • le fichier /var/lib/mysql/tc.log ne peut pas être initialisé.

Après un petit df, il s’avère que le client a installé un plugin de sauvegarde qui a littéralement saturé tout l’espace disponible.

Après un petit ménage, il ne reste plus qu’à gérer la seconde erreur, Can’t init tc log.

Le fichier /var/lib/mysql/tc.log peut parfois souffrir d’un problème de permission.

Dans le cas du client, on l’archive par précaution:

mv /var/lib/mysql/tc.log /var/lib/mysql/tc_bakup.logCode language: JavaScript (javascript)

Puis on relance le serveur MariaDB:

service mysql start

On vérifie le statut du service:

service mysql status

qui nous retourne:

service mysql status
● mariadb.service - MariaDB database server
   Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-04-22 18:17:22 CST; 1h 37min ago
  Process: 12467 ExecStartPost=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12464 ExecStartPost=/etc/mysql/debian-start (code=exited, status=0/SUCCESS)
  Process: 12340 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= ||   VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ]   && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited,
  Process: 12337 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS)
  Process: 12334 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS)
 Main PID: 12437 (mysqld)
   Status: "Taking your SQL requests now..."
    Tasks: 29 (limit: 4915)
   CGroup: /system.slice/mariadb.service
           └─12437 /usr/sbin/mysqld

Apr 22 18:17:20 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Starting MariaDB database server...
Apr 22 18:17:21 iZuf6aj6jz83uxa0jgbgcrZ mysqld[12437]: 2019-04-22 18:17:21 139940495544896 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 12437 ...
Apr 22 18:17:22 iZuf6aj6jz83uxa0jgbgcrZ systemd[1]: Started MariaDB database server.Code language: PHP (php)

A noter que l’erreur 502 de nginx n’était pas due à une mauvaise configuration du server block mais bien d’un manque d’espace disque.

C’est important à vérifier, avant de se lancer dans la dissection du fichier de configuration d’nginx (qui n’aurait pas réglé le problème dans ce cas précis).

WordPress : nettoyer les tables wp_options et wp_postmeta photo

WordPress : nettoyer les tables wp_options et wp_postmeta

Nous allons aujourd’hui examiner deux tables importantes de votre base de données WordPress, wp_options et wp_postmeta.

C’est un domaine qui est souvent négligé en ce qui concerne les performances globales de WordPress et de la base de données.

Cela est très visible sur les sites les plus anciens et les plus gros et peut être la cause des temps de requête lents sur votre site en raison des données à chargement automatique laissées par les plugins et les thèmes tiers.

Voici quelques conseils pour vérifier, dépanner et nettoyer vos tables wp_options et wp_postmeta.

Que contient la table wp_options ?

La table wp_options contient toutes les données relatives aux options et paramètres de votre site WordPress telles que:

  • URL du site, URL de la page d’accueil, adresse électronique de l’administrateur, catégorie par défaut, publications par page, format d’heure, etc.
  • Paramètres pour les plugins, les thèmes, les widgets,
  • Données temporairement mises en cache.

La table wp_options contient plusieurs champs :

  • option_id
  • option_name
  • option_value
  • autoload

Le champ qui nous intéresse particulièrement est le champ autoload, qui contient un drapeau qui peut être soit “yes”, soit “no”. Cela contrôle essentiellement si la valeur est chargée ou non par la fonction wp_load_alloptions().

Les données à chargement automatique sont des données qui sont chargées sur chaque page de votre site WordPress. L’attribut autoload est défini sur «yes» par défaut pour les développeurs, mais tous les plugins ne doivent théoriquement pas charger leurs données sur chaque page.

Le problème que les sites WordPress peuvent rencontrer est celui où la table wp_options contient une grande quantité de données auto-chargées. Cependant, la table wp_options n’a pas non plus été conçue pour contenir des milliers de lignes.

Combien coûte trop de données autoloadées? Cela peut varier, bien sûr, mais idéalement, vous voulez que la taille de votre ordinateur soit comprise entre 300 Ko et 1 Mo.

Une fois que vous commencez à approcher la plage de 3 à 5 Mo ou plus, il existe très probablement des éléments pouvant être optimisés ou supprimés du chargement automatique.

Et tout ce qui dépasse 10 Mo doit être traité immédiatement. Cela ne signifie pas toujours que cela posera un problème, mais c’est un bon point de départ.

Vérifier la taille totale des données auto-chargées

On peut calculer la taille totale des données auto-chargées d’un site WordPress en effectuant la requête suivante sous MySQL:

SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Code language: JavaScript (javascript)

La valeur d’autoload_size est exprimée en octets. Il y a 1024 octets dans un KB et 1024 KB dans un MB. Dans notre cas, 622 138 octets sont donc égaux à 0,62 MB. Donc pour ce site, c’est une bonne taille! Si vous restituez moins de 1 Mo, ne vous inquiétez pas. Cependant, si le résultat était beaucoup plus grand, passez à l’étape suivante.

Lire la suite

Ajouter un lien avec le nombre d'articles et le total du panier WooCommerce photo

Mettre à jour la base de données de WooCommerce avec wp-cli

Il existe certaines situations dans lesquelles le plugin WooCommerce est mis à jour mais la mise à jour de la base de données du plugin échoue.

Cet échec de la mise à jour de la base de données est généralement causé par le délai d’attente de PHP, en particulier sur l’environnement d’hébergement partagé, puisque PHP ne dispose que de 60 secondes pour s’exécuter via une requête Web.

La non-concordance de version entre la version de la base de données WooCommerce et celle du plugin WooCommerce peut être à l’origine de problèmes.

Mise à jour de la base WooCommerce en ligne de commande

Pour résoudre ces problèmes, nous pouvons mettre à jour la base de données WooCommerce via la ligne de commande, en utilisant wp-cli.

1. Connectez-vous au serveur en SSH.

2. Naviguez jusqu’à la racine du site via SSH et exécutez la commande de mise à jour de WooCommerce:

wp wc update

Pour une grosse base de données, cela peut prendre un certain temps. Voici le résultat que vous devriez obtenir une fois le processus de mise à jour de la base de données terminé :

wp wc update

Calling update function: wc_update_350_db_version
Success: 2 updates complete. Database version is 3.5.0Code language: CSS (css)

3. Vérifiez dans WooCommerce > Status que la version de la base de données correspond bien à la version du plugin WooCommerce.

Et voilà votre base de données WooCommerce à jour!

Désactiver les binary logs sous MySQL 8 photo

Désactiver les binary logs sous MySQL 8

mysql 8

J’ai récemment monté un nouveau serveur qui utilise MySQL 8 et après quelques jours d’utilisation, je me suis rendu compte que l’espace disque avait considérablement augmenté.

La cause ? Une multitude de fichiers logs binaires dans le répertoire d’exécution de MySQL 8 : il y en avait pour plus de 260 Go !

Les fichiers logs binaires enregistrent toutes les requêtes qui ont été effectuées par le serveur de bases de données. Inutile de dire qu’il est assez improbable que vous cherchiez à savoir quelles requêtes ont été lancées le mois dernier!

Désactivation des logs binaires

Sous MySQL 8, voici comment désactiver les logs binaires : éditez le fichier de configuration de MySQL:

nano /etc/mysql/mysql.conf.d/mysqld.cnf

et ajoutez cette ligne sous [mysqld] :

skip-log-bin

Vous pouvez également vous connecter au serveur MySQL en ligne de commande:

mysql -u root -p

et lancer la commande suivante dans l’invite de commande MySQL:

SET sql_log_bin = 0;
PURGE BINARY LOGS BEFORE '2019-03-31';Code language: JavaScript (javascript)

Relancez ensuite le serveur MySQL:

service mysql restart

Il ne vous reste plus qu’à vous rendre dans le dossier d’exécution de MySQL – /etc/mysql par défaut, sauf si vous l’avez modifié – et supprimer les fichiers binlog*.