Réinitialiser le mot de passe root de MySQL ou MariaDB sous Debian photo

Réinitialiser le mot de passe root de MySQL ou MariaDB sous Debian

Chez l’un de mes clients, nous avons eu besoin de réinitialiser le mot de passe MySQL de l’utilisateur root, qui a été oublié.

Je vous avais déjà décrit comment réinitialiser le mot de passe root d’un serveur MySQL ou MariaDB sous Ubuntu.

Comme le serveur tourne sous Debian, nous avons un moyen très simple d’avoir accès à la base mysql pour modifier le mot de passe root. Cela ne prend que quelques secondes.

L’utilisateur debian-maintenance à la rescousse

Sous les systèmes à base Debian, il existe par défaut un utilisateur nommé debian-sys-maint, qui se charge de routines de maintenance sur la base SQL et qui possède tous les droits d’administration sur toutes les bases de données.

Il se trouve que le mot de passe de l’utilisateur debian-sys-maint est visible, en clair dans ce fichier:

nano /etc/mysql/debian.cnf

Copiez le mot de passe. Ensuite, connectez-vous avec debian-sys-maint au serveur de base de données:

mysql -u debian-sys-maint -p

Vous êtes maintenant connecté au serveur de base de données, en tant qu’administrateur, sous l’utilisateur debian-sys-maint.

Tous les utilisateurs de la base de données sont stockés dans la base mysqldonc on commence par la sélectionner:

use mysql;

Et on peut maintenant changer le mot de passe de l’utilisateur root avec une simple mise à jour du mot de passe:

SET PASSWORD FOR 'root'@'localhost' = PASSWORD('^*p4!_BHLn6Q&xuft*^5tjyby7^_$)d7_fgf&zec8#ExV@xY');
flush privileges;

Il ne reste plus qu’à quitter MySQL monitor:

quit;

Voilà, le mot de passe de l’utilisateur rootest désormais changé. Vous pouvez vous identifier normalement avec le nouveau mot de passe que vous venez de définir plus haut:

mysql -u root -p
Enter password:

Une astuce toujours utile à garder sous le coude!

WordPress : résoudre l'erreur

WordPress : résoudre l’erreur “ftp_nlist() expects parameter 1 to be resource, null given”

Sous WordPress 5.3.x et en utilisant wp-cli, on peut obtenir cette erreur lors de la mise à jour de plugins et thèmes:

Warning: ftp_nlist() expects parameter 1 to be resource, null given in /var/www/html/wp-admin/includes/class-wp-filesystem-ftpext.php on line 402

PHP Warning:  ftp_pwd() expects parameter 1 to be resource, null given in /var/www/html/wp-admin/includes/class-wp-filesystem-ftpext.php on line 226

Le tout répété cinq à six fois pour la mise à jour d’un plugin. En regardant le ticket trac qui rapporte ce problème, il s’agit d’une erreur qui était auparavant cachée (avec un @ devant la fonction) et qui est maintenant affichée.

Au -delà du fait de cacher ou ne plus cacher l’erreur, il semble qu’il manque une routine qui vérifie que le lien wp_filesystem est bien actif avant de pouvoir l’utiliser.

En attendant que cela soit réglé dans une prochaine version de WordPress, voici ce que l’on peut ajouter au fichier wp-config.php pour se débarrasser de l’erreur proprement:

if ( !defined( 'FS_METHOD' ) ):
    define( 'FS_METHOD', 'direct' );
endif;

Enregistrez le fichier, problème réglé !

Changer le nom de fichier par défaut de l'outil capture d'écran sous MacOS X photo

Changer le nom de fichier par défaut de l’outil capture d’écran sous MacOS X

Depuis que je suis passé à MacOS X Catalina, j’ai ajouté l’outil capture d’écran dans la Touchbar, histoire de toujours l’avoir à portée de main.

Pour les puristes, vous pouvez capturer l’écran avec Shift-Command-5 (à partir de Mojave et supérieur) ou Shift-Command-3.

Par contre, toutes les captures d’écran sont préfixées par défaut avec “Capture d’écran” suivie de la date et de l’heure. Cela peut être gênant lorsque l’on publie cette image sur internet, étant donné que les noms de fichiers accentués ne sont pas toujours bien gérés.

Voici donc une petite astuce pour changer le préfixe pour celui de votre choix. Dans mon exemple, je l’ai tout simplement changé pour “Screenshot”.

Changer le nom de fichier par défaut de l’outil capture d’écran

Ouvrez le terminal puis lancez la commande suivante, en remplaçant “Screenshot” par le préfixe de votre choix:

defaults write com.apple.screencapture name "Screenshot"

Relancez ensuite le service SystemUI:

killall SystemUIServer

Lancez ensuite l’outil de capture d’écran et enregistrez votre capture. Elle est maintenant préfixée par ce que vous avez choisi.

NAS Synology: renouveller le certificat TLS photo 1

NAS Synology: renouveler le certificat TLS

Je suis en train de faire le ménage sur d’anciennes machines que je donne sur donnons.org : cela me permet de récupérer quelques (vieilles) données pour les sauvegarder sur le NAS avant de formater les disques durs pour leur nouvelle vie.

En changeant de machine, je me suis aperçu que le certificat TLS du NAS n’était plus valide… depuis fin février 2019! What??

Après quelques infructueux essais de renouveler le certificat, il semblerait que le passage à DSM 6.2 soit à l’origine du problème.

Visiblement, je ne suis pas le seul affecté.

La redirection No-IP

J’utilise depuis des années une redirection No-IP pour accéder à différents services comme le NAS ou la webradio.

Sur une session SSH sur le NAS, j’ai lancé la commande suivante:

sudo syno-letsencrypt renew-all -vv

Voilà le résultat:

HTTP/1.1 403 Forbidden
Server: nginx
Date: Fri, 01 Nov 2019 10:43:12 GMT
Content-Type: application/problem+json
Content-Length: 98
Connection: keep-alive
Boulder-Requester: 6426144
Cache-Control: public, max-age=0, no-cache
Replay-Nonce: 0002Lw7vG9KbJRj_7s8e0Zuqit27lxN7Om7tdFuqaB2iCKQ

] Body: [{
  "type": "urn:acme:error:unauthorized",
  "detail": "Certificate is expired",
  "status": 403
}]
terminate called after throwing an instance of 'SLError'
Aborted (core dumped)

Je n’ai jamais réussi à renouveller ou à recréer ce certificat.

J’ai donc changé mon fusil d’épaule et utilisé le service DDNS de Synology.

Lire la suite

Useful snippets photo

WordPress : trouver tous les articles de moins de 300 mots

Useful snippets photo

On m’a demandé sur Codeable un audit SEO sur un site qui avait plusieurs années d’existence et dont la ligne éditoriale a évolué avec le temps.

Les vieux articles, très courts et peu informatifs, offraient peu de valeur aux visiteurs et devaient donc être listés dans le but de les amender ou de les supprimer.

Le site était sous WordPress donc voici la requête que j’ai utilisée pour dresser la liste de tous les articles qui contiennent moins de 300 mots (on ne compte pas les espaces):

SELECT LENGTH(post_content) - LENGTH(REPLACE(post_content, ' ', ''))+1, post_title, ID
FROM wp_posts WHERE post_type='post' AND post_status='publish' AND ((LENGTH(post_content) - LENGTH(REPLACE(post_content, ' ', ''))+1) < 300);

Vous pouvez lancer cette requête SQL sur votre serveur MySQL ou dans un outil comme PHPMyAdmin ou Adminer: cela vous renvoie un tableau de 3 entrées qui contiennent le nombre de mots de l’article, le titre de l’article et son ID.

Au point de vue du SEO, il est recommandé de supprimer les articles zombies qui n’offrent pas de valeur aux visiteurs. Ces pages ne sont généralement pas indexées et n’apparaissent donc pas dans les résultats de recherche.

Mieux vaut consolider le site avec des pages à fort potentiel et avec un contenu conséquent. Ce n’est pas tant le nombre de mots qui compte que la richesse de contenu mais un nombre très faible de mots est un bon indicateur d’un article peu qualifié.

Installer LineageOS (Android 9.0 Pie) sur le OnePlus One photo

Installer LineageOS (Android 9.0 Pie) sur le OnePlus One

lineageos

Aujourd’hui, j’ai installé LineageOS (Android 9.0 Pie) sur mon OnePlus One, histoire de lui redonner un second souffle et de bénéficier des dernières mises à jour de sécurité Android.

Le OnePlus One (OPO) est sorti en mai 2014, il a donc quelques années derrière lui et tourne sous CyanogenMod 13, c’est-à-dire Android 6.0.1 (Marshmallow). Autant dire qu’il n’a pas vu de correctifs de sécurité depuis quelques années!

Étape 1: activer le débogage USB

Sur le téléphone, on commence par activer le mode développeur:

  1. Ouvrez Paramètres > A propos du téléphone.
  2. Tapez 7 fois sur le numéro de build.
  3. Vous venez d’activer le mode développeur!

Grâce au mode développeur, vous avez maintenant accès à des options qui n’étaient pas visibles auparavant et qui vont nous être nécessaires.

Pour activer le débogage USB:

  1. Ouvrez Paramètres > Options pour les développeurs
  2. Activez l’option Débogage Android
  3. Désactivez l’option Mettre à jour la récupération CyanogenMod (sinon l’installation du recovery sera impossible).

Étape 2: installation d’ADB

Android Debug Bridge (adb) est un outil de développement qui facilite la communication entre un appareil Android et un ordinateur. Cette communication s’effectue soit par câble USB, soit en WiFi.

Branchez votre OnePlus One en USB.

Téléchargez les derniers pilotes ADB issus du SDK Android puis décompressez l’archive.

Ouvrez le terminal, rendez-vous dans le répertoire platform-tools et listez ensuite votre téléphone avec cette commande:

./adb devices

Résultat:
List of devices attached
b4be4c53	device

Notre OnePlus One est bien détecté. On reboot en mode fastboot:

./adb reboot bootloader

On liste les appareils détectés par fastboot:

./fastboot devices

Résultat:
b4be4c53    fastboot

Attention, c’est la commande qui va effacer vos données donc pensez à sauvegarder avant!

On déverrouille le bootloader avec:

./fastboot oem unlock
                                                    OKAY [  0.168s]
 Finished. Total time: 0.168s

La partition est effacée, le téléphone va rebooter deux fois puis vous présenter le choix de la langue… comme au premier jour.

Comme c’est un reset de l’appareil, il faut de nouveau activer le débogage USB (étape 1).

Étape 3: installation de TWRP (custom recovery)

Téléchargez TWRP pour OnePlus One (bacon) puis placez le fichier dans le dossier platform-tools, c’est plus commode.

Connectez le téléphone en USB. Ouvrez le terminal et entrez:

./adb reboot bootloader

Puis, on vérifie que fastbootdétecte bien le téléphone:

./fastboot devices
b4be4c53	fastboot

Et on flash TWRP:

./fastboot flash recovery twrp-3.2.3-20190125-bacon.img

Sending 'recovery' (12068 KB)                      OKAY [  0.382s]
Writing 'recovery'                                 OKAY [  0.224s]
Finished. Total time: 0.643s

Lire la suite

Activer SSH sous CPanel photo 4

SSH : solution pour l’erreur “Permissions 0644 for ‘id_rsa.pub’ are too open”

Lors d’une connexion SSH sur le serveur d’un client chez WPEngine, je suis tombé sur le message d’erreur suivant:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/matt/.ssh/id_ed25519.pub' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/Users/matt/.ssh/id_ed25519.pub": bad permissions

Voici la commande que j’avais entré:

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.net

Au lieu d’utiliser ma clé privée, j’ai utilisé ma clé publique (id_ed25519.pub) qui – comme elle est publique – bénéficie de droits plus large que la clé privée.

Il faut donc relancer la commande en retirant l’extension .pub du chemin de la clé, pour que la clé privée soit prise en compte:

ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.net

Dès lors, plus de problème de connexion et la connexion sur le serveur WPEngine se fait sans souci:

  ____  _____  _____
 ╱   ▕ ▕    ▕ ▕    ▕
▕    ▕ ▕    ▕ ▕    ▕
▕____▕  ╲___╱  ╲___▕                                      ▫
 ____           ____     ▃  ▃  ▃  ▃▃▃    ___   __    __      __   ___
▕    ▕    _    ╱   ▕     █  █  █ ▕█▀▀▙  ▕___) |  ▕  ╱  ▕ ▕  |  ▕ ▕___)
▕    ▕   ( )  ▕    ▕      ██ ██  ▕███▛  ▕     |  ▕ ▕   ▕ ▕  |  ▕ ▕
▕____╱    ‾    ╲___▕       █ █   ▕█      ╲__╱ |  ▕  ╲__▕ ▕  |  ▕  ╲__╱
 ____    ___   ___                                  ___╱
▕    ╲  ╱   ╲ ▕    ╲
▕    ▕ ▕    ▕ ▕    ▕
▕____╱ ▕____▕ ▕____▕

WP Engine Shell - PHP 7.3
Obtenir le statut de toutes les jails fail2ban photo

Obtenir le statut de toutes les jails fail2ban

fail2ban jails 1280x853

Si vous utilisez fail2ban sur votre serveur dédié – et vous devriez! – il peut être vraiment utile de lister les statuts de toutes les jails fail2ban.

Cela permet de voir quelles sont les jails actives et de vérifier qu’il n’y a aucun problème de configuration.

On peut obtenir le statuts de toutes les jails fail2ban avec la commande suivante:

fail2ban-client status | sed -n 's/,//g;s/.*Jail list://p' | xargs -n1 fail2ban-client status

Voici un exemple de résultat de la commande:

Status for the jail: pam-generic
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:
Status for the jail: postfix
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	4482
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	223
   `- Banned IP list:
Status for the jail: sasl
|- Filter
|  |- Currently failed:	4
|  |- Total failed:	14126
|  `- File list:	/var/log/mail.log
`- Actions
   |- Currently banned:	4
   |- Total banned:	1927
   `- Banned IP list:	45.148.10.70 46.38.144.17 46.38.144.202 46.38.144.32
Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- File list:	/var/log/auth.log
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

A garder dans sa trousse à outils!

MySQL: résoudre l'erreur

MySQL: résoudre l’erreur “Incorrect datetime value” lors d’opérations sur les tables

mysql logo compressor 1280x662

Depuis le passage du site sur le nouveau serveur, ORION, j’utilise MySQL 8 en lieu et place de MariaDB, histoire de tester les les gains de performance.

Or, avec la nouvelle configuration de MySQL par défaut, vous pouvez obtenir cette erreur lors de simples opération de maintenance comme l’optimisation des tables:

example.wp_comments: Table does not support optimize, doing recreate + analyze instead
example.wp_comments: Invalid default value for 'comment_date'
example.wp_comments: Operation failed
example.wp_et_social_stats: Incorrect datetime value: '0000-00-00 00:00:00' for column 'comment_date' at row 1
example.wp_et_social_stats: Invalid default value for 'comment_date'
example.wp_et_social_stats: Table does not support optimize, doing recreate + analyze instead
example.wp_et_social_stats: Invalid default value for 'sharing_date'
example.wp_et_social_stats: Operation failed

Cela est dû à un changement de configuration, notamment dans la directive sql_mode depuis MySQL 5.7.

Voyons-donc ce que contient la directive par défaut. Identifiez-vous sur le serveur MySQL:

mysql -u root -p

Puis vérifiez le contenu de la variable de configuration sql_mode:

show variables like 'sql_mode';

Résultat:

+---------------+-----------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                 |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION |
+---------------+-----------------------------------------------------------------------------------------------------------------------+
1 row in set (0.02 sec)

Ce qui pose problème, ce sont ces deux directives: NO_ZERO_IN_DATE et NO_ZERO_DATE.

Deux solutions s’offrent à nous : éditer la valeur directement depuis la console mysql ou alors depuis le fichier de configuration my.cnf.

Méthode 1 : éditer la valeur de sql_mode depuis la console MySQL

Si vous vous trouvez toujours dans la console mysql, vous pouvez lancer la reqête suivante, qui enlève les drapeaux NO_ZERO_IN_DATE et NO_ZERO_DATE à notre directive sql_mode:

SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION';

Relancez ensuite le serveur:

service mysql restart

Méthode 2 : éditer la valeur de sql_mode depuis le fichier de configuration MySQL (my.cnf)

Nous allons donc éditer notre fichier de configuration MySQL:

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

Et ajouter (ou modifier) la variable de configuration sql_mode en l’amputant des valeurs NO_ZERO_IN_DATE et NO_ZERO_DATE:

sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

Enregistrez le fichier puis redémarrez le serveur mysql:

service mysql restart

Vous pouvez désormais lancer des requêtes de maintenance ou de modification de la structure des tables de la base de données sans problèmes.

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/sshd

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: ED25519

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;
    }
}

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' *

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!