Matt Biscay: développeur WordPress et WooCommerce pour SkyMinds
ubuntu 2204 jammy jellyfish

Serveur: migration d’Ubuntu 20.04 à 22.04 LTS

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_64

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

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

Lire la suite

Serveur dédié: gérez comptes et alias email avec PostfixAdmin photo

Serveur dédié: gérez comptes et alias email avec PostfixAdmin

Si vous possédez et gérez votre propre serveur email, il peut être très intéressant de proposer des comptes emails et des alias pour vos utilisateurs.

J’ai écrit il y a quelques années un tutoriel qui faisait cela à la main avec une base SQL et des domaines virtuels mais il y a aujourd’hui beaucoup plus simple avec PostfixAdmin.

PostfixAdmin

PostfixAdmin est une interface web open-source qui permet de gérer des comptes mails, des domaines et des alias sur un serveur mail Postfix.

il s’intègre avec

  • Postfix
  • un server IMAP/POP3 comme Dovecot ou Courier
  • une base de données (sqlite, mysql, postgresql)
  • Fetchmail (optionnel)

Il est très utile pour créer des alias à la volée ou des comptes mail rapidement.

Création du sous-domaine

Je trouve cela plus simple de créer un sous-domaine pour ce type d’application. Dans votre gestionnaire DNS, il suffit d’ajouter un enregistrement de type A:

XXXXX.EXAMPLE.COM IN A xxx.xxxx.xxx.xxx

XXXXX est votre sous-domaine sur EXAMPLE.COM et xxx.xxx.xxx.xxx l’adresse IPv4 de votre serveur.

Création de la base de données

Nous utilisons MySQL/MariaDB pour postfix donc on s’identifie sur la console mysql :

mysql -u root -p 

[MOT DE PASSE ROOT]

Et on lance:

CREATE DATABASE postfix; 
CREATE USER 'mymailadmin'@'localhost' IDENTIFIED WITH mysql_native_password BY '1nyXI7Y)$spmslgz4HhdE4Lc_vm&)Gh!MsZFf64645fek'; 
GRANT ALL PRIVILEGES ON postfix.* TO 'mymailadmin'@'localhost'; 
FLUSH PRIVILEGES; EXIT;

Nous avons donc un nouvel utilisateur et une nouvelle base de données, spécifiques pour PostfixAdmin.

Configuration NginX pour PostfixAdmin

On crée un nouveau server block spécifique à PostfixAdmin:

nano /etc/nginx/sites-available/postfixadmin.conf

Lire la suite

Dovecot : solution pour les erreurs SASL, stats-writer, SSL et Diffie-Hellman photo

Dovecot : solution pour les erreurs SASL, stats-writer, SSL et Diffie-Hellman

La dernière version du serveur mail Dovecot nécessite quelques petits changements par rapport à la version antérieure.

Erreurs SASL

Voici ce que l’on peut lire dans les logs:

postfix/smtps/smtpd: warning: SASL: Connect to private/auth failed: Connection refused
postfix/smtps/smtpd: fatal: no SASL authentication mechanisms
postfix/master: warning: process /usr/lib/postfix/sbin/smtpd pid 635413 exit status 1
postfix/master: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

Solution: il faut éditer /etc/dovecot/conf.d/10-master.conf:

nano /etc/dovecot/conf.d/10-master.conf

et ajouter ce bloc de directives à la fin du bloc service auth:

service auth {
  # ... Previous config blocks
 
  # auth-master
  unix_listener auth-master {
    mode = 0660
    user = vmail
    group = vmail
  }

}

Stats writer

Dovecot inclut maintenant un module de statistiques et donne une erreur si jamais il n’est pas défini dans la configuration. Voici le message d’erreur:

Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied))

Il faut donc le rajouter:

nano /etc/dovecot/conf.d/10-master.conf

et ajouter ce bloc à la toute fin du fichier:

# fix Error: net_connect_unix(/var/run/dovecot/stats-writer) failed: Permission denied))
service stats {
    unix_listener stats-reader {
        user = vmail
        group = vmail
        mode = 0660
    }

    unix_listener stats-writer {
        user = vmail
        group = vmail
        mode = 0660
    }
}

Lire la suite

Auto Draft photo 1

Mise à jour du serveur vers Ubuntu Focal Fossa (20.04 LTS)

Ce soir, on lance la mise à jour du serveur: nous passons notre version d’Ubuntu Server de Bionic Beaver (18.04 LTS) à Focal Fossa (20.04 LTS).

On commence par les précautions d’usage: faire ses sauvegardes et vérifier qu’elles sont bien intègres avant de commencer la mise à jour. C’est votre bouée en cas de soucis!

Étape 1: avoir l’installation d’Ubuntu actuelle à jour

Assurez-vous d’avoir une installation à jour avant de commencer:

apt update && apt dist-upgrade

On reboot ensuite pour appliquer les changements:

shutdown -r now

Étape 2: installation de screen et ouverture du port 1022 pour SSH

Comme nous allons lancer la mise à jour via un terminal SSH, il est possible que pour une raison ou un autre la connexion soit coupée. Cela arrive et cela peut être vraiment tendu à certaines étapes de la mise à jour (kernel anyone?).

Pour prévenir cela, on vérifie que screen est bien installé:

apt install screen

On peut lancer une session screen avec:

screen

et si la connexion SSH est interrompue lors de la mise à jour, on peut se raccrocher à la session de mise à jour avec la commande:

screen -Dr

Ensuite, au niveau du pare-feu, on ouvre le port 1022. C’est via ce port que l’on pourra reprendre la MAJ en cas de pépin. Suivant la configuration du serveur, on peut utiliser iptables:

iptables -I INPUT -p tcp --dport 1022 -j ACCEPT

ou alors ufw:

ufw allow 1022

Lire la suite

Solution pour l'erreur cURL error 7: Failed to connect to XXX port 443: Connection refused photo 1

Solution pour l’erreur cURL error 7: Failed to connect to XXX port 443: Connection refused

Sur un serveur hébergé en Chine continentale, j’ai eu la surprise de ne pas être en mesure de mettre à jour wp-cli:

wp cli update

Error: Failed to get url 'https://api.github.com/repos/wp-cli/wp-cli/releases?per_page=100': cURL error 7: Failed to connect to api.github.com port 443: Connection refused.

Visiblement, certaines adresses sont injoignables, notamment lorsqu’elles utilisent le port 443 (https).

Evidemment, on peut télécharger wp-cli manuellement et le réinstaller mais si vous souhaitez une solution plus rapide, voilà comment j’ai procédé.

Première solution: édition de /etc/hosts

1. On récupère l’adresse IP de l’adresse api.github.com:

curl --ipv4 -v https://api.github.com

Résultat: 13.250.94.254 port 443

2. On édite le fichier /etc/hosts du serveur:

nano /etc/hosts

3. On y ajoute l’adresse IP correspondante à api.github.com:

13.250.94.254 api.github.com

Et voilà, le téléchargement depuis github est de nouveau accessible.

Lire la suite

WordPress : résoudre l'erreur

Lister tous les articles publiés sur un blog WordPress avec wp-cli

wordpress banner 1280x512

Lister les URLs de tous les articles publiés

J’ai récemment eu besoin de lister toutes les URLs des articles du site, pour les promouvoir sur les réseaux sociaux. L’un des services que j’utilise, SocialBee, permet de soumettre une liste de 100 URLs à chaque soumission du formulaire.

Il nous faut donc une liste d’adresse de 100 articles publiés, ce qui est très facile à obtenir grâce à wp-cli. Voici la commande que j’ai écrite:

wp post list --field=url --post_status=publish --allow-root --posts_per_page=100 --paged=1

Explications:

  • wp est un alias de wp-cli, installé sur le serveur
  • post indique l’on va interroger les articles
  • list: on va lister!
  • --field=url : on veut le champ URL
  • --post_status=publish : les articles publiés uniquement
  • --allow-root : parce que je suis en root
  • --posts_per_page=100: le nombre d’article à récupérer
  • --paged=1 : le numéro de la pagination de la requête

Il vous suffit ensuite d’incrémenter la valeur de --paged pour passer en revue toutes les pages de la requête.

Ou alors retirer totalement les arguments --posts_per_page=100 --paged=1 pour obtenir la liste complète des URLs de tous les articles publiés.

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!

Serveur dédié: passage à PHP 7.4 photo

Serveur dédié: passage à PHP 7.4

C’est Noël avant l’heure : PHP version 7.4 est désormais disponible! Ni une ni deux, elle est déjà installée sur le serveur.

Je vous conseille de jeter un petit coup d’oeil aux nouveautés de PHP 7.4, cela se modernise!

Si vous souhaitez sauter le pas, voici un petit tuto pour l’installation.

Étape 1 : installer le dépôt d’Ondrej

Dans le terminal, installez le dépôt d’Ondrej. Il est très souvent mis à jour et permet de bénéficier de pas mal de paquets à jour, même sur des distributions anciennes:

add-apt-repository ppa:ondrej/php

Étape 2 : installation de PHP 7.4

J’ai juste repris la liste des paquets PHP7.3 déjà installés puis changé le numéro de version.

Cela nous donne donc:

apt install php-igbinary php-imagick php-redis php7.4 php7.4-bcmath php7.4-cli php7.4-common php7.4-curl php7.4-fpm php7.4-gd php7.4-imap php7.4-intl php7.4-json php7.4-mbstring php7.4-mysql php7.4-opcache php7.4-readline php7.4-soap php7.4-xml php7.4-zip

Note: il vous reste ensuite à modifier php.iniainsi que votre pool PHP selon vos besoins.

Étape 3: modification du server block

L’étape finale est la modification de votre server block. Sous NginX, éditez le fichier de configuration de votre site pour pointer vers le socket de PHP7.4:

#fastcgi_pass unix:/run/php/php7.3-fpm.sock;
fastcgi_pass unix:/run/php/php7.4-fpm.sock;

Il suffit ensuite de relancer NginX et PHP:

service php7.4-fpm start && service nginx restart

Et voilà! Bonnes mises à jour !

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.

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)$ {
     valid_referers none blocked ~.google. ~.bing. ~.yahoo. ~.facebook. ~.pinterest. ~.twitter. yourdomain.com *.yourdomain.com server_names;
     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.