Tag: root | Page 3 | SkyMinds.Net

wp-cli : importer et exporter les utilisateurs WP

20 December 202314 juin 2022 by Matt Biscay · Lecture: 3 minutes

Voici une méthode simple pour exporter tous les utilisateurs d’une base de données WordPress, pour les réimporter sur un autre site, à l’aide de l’excellent wp-cli.

Nous ferons référence à la base de données source en tant que source-db et à la base de données cible en tant que target-db et je supposerai que vous avez accès aux deux instances WordPress via wp-cli.

Étape 1 : exporter les utilisateurs WordPress

Cette étape fonctionnera avec la base de données source-db:

wp db export --tables = $(wp db tables 'wp_*_users') users.sqlCode language: JavaScript (javascript)

notez l’astérisque dans le nom de la table – utilisez-le pour éviter de taper le nom exact de la table pour votre base de données WordPress spécifique
notez le nom du fichier exporté, users.sql – cela permet d’identifier clairement le contenu de ce fichier.

Étape 2 : exporter la méta utilisateur WordPress

Cette étape fonctionnera avec la base source-db. Comme ci-dessus, notez le caractère générique et le nom de fichier:

wp db export --tables = $(wp db tables 'wp_*_usermeta') usermeta.sqlCode language: JavaScript (javascript)

Étape 3 : sauvegarde facultative des utilisateurs et usermeta

Cette étape fonctionnera avec la base target-db. Il s’agit d’une sauvegarde facultative des utilisateurs et des tables usermeta avant d’importer les nouvelles données:

répétez l’étape 1 (mais en travaillant avec target-db)
nommez le fichier backup-users.sql
répétez l’étape 2 (mais en travaillant avec target-db)
nommez le fichier backup-usermeta.sql

Cela nous donne donc:

wp db export --tables = $(wp db tables 'wp_*_users') backup-users.sql
wp db export --tables = $(wp db tables 'wp_*_usermeta') backup-usermeta.sqlCode language: JavaScript (javascript)

APT : the following packages have been kept back

21 February 202423 mai 2022 by Matt Biscay · Lecture: 3 minutes

Après la mise à jour d’Ubuntu Server sur le serveur, j’ai eu cette erreur récurrente après chaque mise à jour apt :

The following packages have been kept back:
  mysql-client mysql-server

Il m’était donc impossible de mettre à jour le serveur et client mysql , ce qui n’est évidemment pas idéal.

Et si l’on essaie de les installer directement avec:

apt install mysql-client mysql-server

On obtient alors ce message:

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mysql-common : Conflicts: mysql-client-8.0 but 8.0.29-0ubuntu0.22.04.2 is to be installed
                Conflicts: mysql-client-core-8.0 but 8.0.29-0ubuntu0.22.04.2 is to be installed
 mysql-server : Depends: mysql-server-8.0 but it is not installable
E: Unable to correct problems, you have held broken packages.Code language: CSS (css)

Réinstaller mysql-apt-config

On commence donc par réinstaller le package mysql-apt-config :

wget https://dev.mysql.com/get/mysql-apt-config_0.8.22-1_all.debCode language: JavaScript (javascript)

Et on installe le paquet :

dpkg -i mysql-apt-config_0.8.22-1_all.debCode language: CSS (css)

On relance donc la mise à jour :

apt update && apt upgrade

Les nouvelles versions des paquets peuvent désormais être installées :

9 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: http://repo.mysql.com/apt/ubuntu/dists/bionic/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Listing... Done
libmysqlclient21/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.29-0ubuntu0.22.04.2]
mysql-client/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-common/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client-core/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client-plugins/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-client/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-server-core/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-community-server/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
mysql-server/unknown 8.0.29-1ubuntu18.04 amd64 [upgradable from: 8.0.28-1ubuntu18.04]
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  linux-headers-5.15.0-25 linux-headers-5.15.0-25-generic linux-image-5.15.0-25-generic linux-modules-5.15.0-25-generic
  linux-modules-extra-5.15.0-25-generic
Use 'apt autoremove' to remove them.
The following packages will be upgraded:
  libmysqlclient21 mysql-client mysql-common mysql-community-client mysql-community-client-core mysql-community-client-plugins
  mysql-community-server mysql-community-server-core mysql-server
9 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Code language: JavaScript (javascript)

J’ai également écrit un script bash qui automatise tout cela : Mettre à jour mysql-client-server-apt-config

Résoudre le message “Key is stored in legacy trusted.gpg keyring”

Dans le message précédent, nous pouvons trouvez ce message d’avertissement:

W: http://repo.mysql.com/apt/ubuntu/dists/bionic/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.Code language: JavaScript (javascript)

Je l’ai résolu en déplaçant le fichier dans le répertoire trusted.gpg.d :

mv trusted.gpg trusted.gpg.d/

Et voilà, plus d’erreur avec apt et notre système met bien tous ses paquets à jour.

Serveur: migration d’Ubuntu 20.04 à 22.04 LTS

16 August 202429 avril 2022 by Matt Biscay · Lecture: 5 minutes

Aujourd’hui, nous mettons le serveur à jour et passons d’Ubuntu Server 20.04 (Focal Fossa) à la version 22.04 LTS (Jammy Jellyfish).

Chaque nouvelle mise à jour d’Ubuntu en version LTS (Long Time Support) permet de bénéficier des mises à jour de sécurité et de maintenance pendant 5 ans, c’est-à-dire jusqu’en 2027 pour la version Jammy Jellyfish.

Lecture des changements apportés

Je vous conseille fortement de lire le changelog de la version 22.04 pour avoir un aperçu des changements apportés au niveau du kernel, openSSL, certains services.

Sont maintenant disponibles:

Apache 2.4.52
BIND 9.18
Linux kernel v5.15.0-25
MySQL 8.0.28
NetworkManager 1.36
nftables est le backend par défaut pour le parefeu
Perl v5.34.0
PHP 8.1.2
PostgreSQL 14.2
Python 3.10.4
Ruby 3.0
ssh-rsa est maintenant désactivé par défaut dans OpenSSH.

Cela donne aussi une idée des potentielles complications qui pourraient subvenir à la suite de la mise à jour, ainsi que leur remédiation.

Sauvegarde des données du serveur

Je ne vous apprends rien : il va falloir sauvegarder les données importantes du serveur avant de commencer la mise à jour de l’OS.

Pensez-donc au dossier /home et /var/www mais aussi aux fichiers de configuration dans /etc et /root.

Vérification des prérequis

Vérification de la version actuelle

On vérifie notre noyau actuel:

uname -mrs

> Linux 5.4.0-109-generic x86_64Code language: CSS (css)

On vérifie notre version actuelle:

lsb_release -a


No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.4 LTS
Release:	20.04
Codename:	focalCode language: CSS (css)

Mise à jour des paquets de la version actuelle

On met à jour la version actuelle avec les derniers paquets et les derniers noyaux:

apt update && apt upgrade

Redémarrage du serveur

On redémarre le serveur pour appliquer les changements et partir sur une base propre:

shutdown -r now

Installer LineageOS (Android 11) sur le OnePlus One

3 January 202202 janvier 2022 by Matt Biscay · Lecture: 4 minutes

Aujourd’hui, j’ai installé LineageOS (Android 11) 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!

Si votre téléphone possède déjà LineageOS, vous pouvez vous rendre directement à l’étape 5.

Étape 1: activer le mode développeur

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

Ouvrez Paramètres > A propos du téléphone.
Tapez 7 fois sur le numéro de build.
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.

Étape 2 : activer le mode déboggage USB

Pour activer le débogage USB:

Ouvrez Paramètres > Système > Options pour les développeurs
Activez l’option Débogage Android

Étape 3 : 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	deviceCode language: PHP (php)

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, la commande suivante va effacer vos données donc pensez à sauvegarder les données importantes de votre téléphone avant!

On déverrouille le bootloader avec:

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

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

30 September 202128 décembre 2019 by Matt Biscay · Lecture: 2 minutes

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;Code language: PHP (php)

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;Code language: JavaScript (javascript)

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!

Installer LineageOS (Android 9.0 Pie) sur le OnePlus One

3 October 202108 octobre 2019 by Matt Biscay · Lecture: 5 minutes

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.

Étape 1: activer le débogage USB

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

Ouvrez Paramètres > A propos du téléphone.
Tapez 7 fois sur le numéro de build.
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:

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

Étape 2: installation d’ADB

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	deviceCode language: PHP (php)

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.643sCode language: JavaScript (javascript)

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

15 March 202229 septembre 2019 by Matt Biscay · Lecture: 1 minute

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 permissionsCode language: PHP (php)

Voici la commande que j’avais entré:

ssh -i ~/.ssh/id_ed25519.pub -o IdentitiesOnly=yes EXAMPLE@wEXAMPLE.ssh.wpengine.netCode language: JavaScript (javascript)

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.netCode language: JavaScript (javascript)

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

26 septembre 2019 by Matt Biscay · Lecture: 2 minutes

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 statusCode language: JavaScript (javascript)

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:Code language: PHP (php)

A garder dans sa trousse à outils!

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

30 September 202108 septembre 2019 by Matt Biscay · Lecture: 3 minutes

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 failedCode language: JavaScript (javascript)

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';Code language: JavaScript (javascript)

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)Code language: JavaScript (javascript)

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';Code language: JavaScript (javascript)

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.

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

24 March 202212 août 2019 by Matt Biscay · Lecture: 2 minutes

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.

Linux : obtenir la valeur numérique du chmod

28 juin 2019 by Matt Biscay · Lecture: 1 minute

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!

Serveur dédié : installation de MariaDB 10.3 photo

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

3 October 202127 avril 2019 by Matt Biscay · Lecture: 1 minute

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.

← Précédent Suivant →