An automatic computer screen displaying the message "sorry you have been blocked".

Contourner le blocage du WAF Cloudflare pour les uploads de zip dans WordPress

Le blocage des fichiers zip par le WAF (Web Application Firewall) de Cloudflare est un casse-tête pour de nombreux développeurs WordPress, surtout lors de la mise à jour de plugins et de thèmes. Heureusement, il existe une solution pour contourner ce problème sans compromettre la sécurité de votre site WordPress.

Pourquoi le WAF bloque-t-il les fichiers Zip ?

Cloudflare met régulièrement à jour ses Managed Rules pour renforcer la sécurité. Un upload de fichier zip peut être un vecteur pour des attaques malveéillantes, comme l’installation de shells. Ainsi, Cloudflare bloque ces requêtes pour protéger votre site.

Dans notre cas, par contre, cela nous empêche de faire nos mises à jour et c’est quand même plus simple de mettre à jour les plugins et thèmes payants avec un fichier zip, plutôt que de passer par SFTP ou wp-cli.

Solution #1: créer une exception dans le WAF de Cloudflare

Évidemment, nous n’allons pas désactiver ces règles qui fonctionnent si bien et ajoutent une couche de protection à notre site. Non, nous allons simplement créer une exception aux Managed Rules, que nous placerons avant tous les autres set de règles pour qu’elle soit prise en compte en priorité.

Étape 1: rendez-vous dans le Dashboard de Cloudflare

Allez dans Security > WAF > Managed Rules.

Voici ce que vous obtenez:

A screenshot of the WAF settings in Google Analytics showcasing blocked zip files.

Cliquez ensuite sur le bouton Add exception à droite.

Lire la suite

linux ubuntu server unattended upgrade

Ubuntu : activer les mises à jour automatiques avec unattended-upgrades

La mise à niveau de votre serveur Ubuntu est une étape importante pour garantir que votre système est toujours à jour et sécurisé. Avec le paquet unattended-upgrades, vous pouvez facilement activer les mises à niveau sans avoir à vous soucier du redémarrage manuel ou des temps d’arrêt.

Comme son nom l’indique, le paquet unattended-upgrades permet de lancer les mises à jour automatiquement à intervalles réguliers, sans action de la part de l’administrateur. Vous pouvez donc planifier les mises à jour lorsque le trafic est faible, et l’outil est même capable de redémarrer le serveur si besoin.

Dans ce tutoriel, nous allons vous montrer comment installer et utiliser unattended-upgrades sous Ubuntu Server 22.04. Nous aborderons également les avantages de l’utilisation de cet outil et la manière dont il peut contribuer à garantir que votre système est toujours à jour.

Cela peut être également un très bon complément si vous avez déjà installé Ubuntu Pro avec le support étendu des mises à jour.

Installer unattended-upgrades

Pour commencer, vous devez d’abord installer le paquet unattended-upgrades sur votre serveur Ubuntu – ouvrez une fenêtre de terminal et entrez la commande suivante :

apt install unattended-upgrades

Une fois que unattended-upgrades est installé, on le paramètre:

dpkg-reconfigure -plow unattended-upgrades

Répondez “Yes” pour installer les mises à jour stable automatiquement.

Activez ensuite l’outil:

unattended-upgrades enable

Paramètrage d’unattended-upgrades

Le paquet est bien plus puissant qu’il n’y paraît. Personnellement, j’aime bien être informé des mises à jour et des changements sur le serveur, activons donc les notifications.

On édite notre fichier de configuration local (à créer si besoin). C’est le fichier qui ne sera pas écrasé si le paquet est mis à jour:

nano /etc/apt/apt.conf.d/52unattended-upgrades-local

Et en suivant la documentation, on demande la notification récapitulative des mises à jour, le redémarrage automatique si besoin, vers deux heures du matin pour ne pas gêner nos visiteurs:

// email to send notifications
Unattended-Upgrade::Mail "admin@example.com";
// automatic reboot at 2:00 AM
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";	

Lire la suite

ubuntu pro free

Ubuntu Pro : des mises à jour pour 10 ans

Canonical change son offre Ubuntu Pro. Désormais, tout le monde peut profiter gratuitement du support étendu dans la limite de 5 machines.

La distribution Linux Ubuntu est maintenue et développée par l’entreprise Canonical. La distribution en elle-même est disponible gratuitement, mais en parallèle Canonical propose des services payants, notamment Ubuntu Pro, un abonnement qui permet d’avoir une maintenance étendue pour la sécurité et la conformité. En temps normal, Ubuntu Pro est facturé 25 dollars par an et par machine, ainsi que 500 dollars par an et par serveur.

Canonical fait évoluer son offre Ubuntu Pro, ce qui permet aux utilisateurs d’en bénéficier gratuitement dans la limite de 5 machines, que ce soit des ordinateurs ou des serveurs, et que ce soit pour un usage personnel ou commercial.

Ubuntu Pro permet d’avoir des correctifs de sécurité plus rapidement lorsqu’une faille de sécurité est découverte, notamment pour avoir une meilleure protection. Ceci s’applique aux failles critiques, élevées ou moyennes, avec un niveau de réactivité qui peut varier. Des milliers d’applications sont prises en charge dans le cadre du programme Ubuntu Pro : Ansible, Apache Tomcat, Apache Zookeeper, Docker, Drupal, Nagios, Node.js, phpMyAdmin, Puppet, PowerDNS, Python 2, Redis, Rust, WordPress, etc.

Support à long terme de niveau « entreprise »

La proposition s’applique uniquement aux versions avec support à long terme (LTS) du système d’exploitation basé sur le noyau GNU/Linux. Et ce à partir de Ubuntu LTS 16.04.

Il s’agit de versions de niveau « entreprise » de l’OS. Les LTS sont aussi les plus utilisées par l’écosystème et représentent 95% des déploiements, selon Canonical.

Les utilisateurs peuvent obtenir leur abonnement gratuit à Ubuntu Pro sur la page dédiée au programme. Ubuntu One étant le compte unique dont l’utilisateur a besoin pour en bénéficier et se connecter à l’ensemble des services et sites liés à l’OS.

Lorsque l’on connecte les machines à Ubuntu Pro, elles bénéficient donc d’une couverture de maintenance de sécurité étendue, soit 10 ans au total.

Aussi, l’offre gratuite inclut le service Ubuntu Livepatch, celui-ci permet d’installer des mises à jour critiques du noyau sans redémarrer la machine.

Pour les serveurs, lorsque le système hôte physique exécute Ubuntu, l’ensemble des machines virtuelles Ubuntu sur ce serveur sont couvertes. Ubuntu Pro s’étend également à Google Cloud et AWS.

Configurez Ubuntu Pro sur votre serveur

Avec autant d’avantages, il ne nous reste plus qu’à configurer Ubuntu Pro sur le serveur.

Si votre serveur tourne sous Ubuntu Server, le paquet pro est normalement déjà installé. Vous pouvez vérifier cela avec la commande:

pro --version

Résultat de la commande:

27.11.2~22.04.1

La version minimale que vous devez posséder est la 27.11.2.

Lire la suite

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

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

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 !

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.0

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!

WorddPress : éviter d'avoir à mettre le même plugin à jour sur chaque site hébergé sur le serveur photo

WordPress: mettre un plugin à jour sur plusieurs sites sur le serveur en une seule opération

Sur un serveur qui héberge plusieurs sites WordPress différents, il est fort probable qu’il y ait quelques plugins en commun sur chaque installation.

WordPress permet de mettre à jour les thèmes et plugins en quelques clics mais cela suppose de s’identifier sur chaque site ou alors de donner permission à une application tierce comme JetPack pour vous faciliter la tâche.

Cela suppose toutefois de bien vouloir rassembler toutes les autorisations sur un seul compte, ce qui n’est pas optimal puisqu’il n’y a plus cloisonnement entre les sites hébergés.

Nous allons donc mettre en place un système de liens symboliques (symlink ou symbolic link en anglais) pour gagner pas mal de temps lors des mises à jour.

Principe d’optimisation de la mise à jour des plugins récurrents

Sur le serveur, j’utilise une petite astuce tout simple : j’utilise mon site comme master officiel du serveur. C’est lui que je mets à jour en premier et tous les autres sites “hériteront” des nouvelles mises à jour, automatiquement et sans manipulation de ma part.

Mise en place de liens symboliques

Comme le serveur tourne sous Linux, il nous suffit de faire un lien symbolique sur le site slave vers le dossier d’un plugin qui se trouve sur le site master.

Lorsque je mettrai certains plugins de SkyMinds à jour par exemple, ces plugins qui sont également installés sur le site du Centre de Kriya Yoga France seront également à jour. En fait, aucun fichier de ce plugin ne sera présent chez eux, seul un lien symbolique.

Concrètement, voici la marche à suivre :

  1. On se place dans le répertoire /wp-content/plugins du site slave (kriyayoga.fr dans cet exemple):
    cd /kriyayoga/wp-content/plugins
  2. On crée un lien symbolique qui va pointer vers le répertoire qui se trouve dans le répertoire de SkyMinds :
    ln -s /skyminds/wp-content/plugins/my-plugin my-plugin
  3. Et voilà !

Lire la suite

Serveur dédié : script bash pour réparer les tables MySQL en cas de crash photo

Serveur dédié : mise à jour vers PHP 7.2

Aujourd’hui, le serveur passe à PHP 7.2 !

PHP 7.2 accroît fortement les performances des versions précédentes, notamment au travers de plusieurs améliorations en matière de sécurité. Ainsi, l’algorithme Argon2 qui sert au hachage sécurisé des mots de passe corrige les défauts des algorithmes actuels. Celui-ci permet notamment un taux de remplissage plus élevé de la mémoire.

PHP 7.2 intègre désormais dans son noyau la bibliothèque de cryptographie Sodium, utilisée pour le chiffrement authentifié, est désormais une extension de base et les performances de la bibliothèque pour la cryptographie sur les courbes elliptiques ont été améliorées.

Niveau programmation

Au-delà de Sodium, PHP 7.2 vient avec des améliorations et nouvelles fonctionnalités comme :

  • la possibilité de convertir des clés numériques dans les objets et tableaux lors de cast.
  • les clés numériques sont maintenant mieux appréhendées lors de cast d’un tableau en objet et d’objet en tableau (cast explicite ou par la fonction settype()) ;
  • le comptage d’objets non dénombrables. Un E_WARNING sera émis lors de la tentative d’utilisation de la fonction count() sur un type non dénombrable ;
  • HashContext en tant qu’objet ;
  • ajout d’Argon2 à l’API pour le hachage de mot de passe ;
  • amélioration des constantes TLS ;
  • la suppression de l’extension Mcrypt. L’extension MCrypt a maintenant été déplacée du noyau vers PECL. Étant donné que la bibliothèque mcrypt n’a pas eu de mises à jour depuis 2007, son utilisation est fortement découragée. Au lieu de cette extension, soit OpenSSL ou l’extension sodium doit être utilisé.

Les fonctions Deprecated (déconseillées) et supprimées pour PHP 8.0:

__autoload
$php_errormsg
create_function()
mbstring.func_overload
(unset) cast
parse_str() sans le second argument
gmp_random()
each()
assert() avec un argument string(texte)
$errcontext

La conversion des clés numériques dans les distributions objet/tableau résout un problème rencontré avec le moteur open source Zend Engine qui fait tourner PHP 7. Dans certaines situations, les tables de hachage de tableaux pouvaient contenir des chaînes numériques alors que les tables de hachage d’objets pouvaient contenir des clés entières, ce qui empêchait le code PHP de retrouver les clés. Le correctif apporté par PHP 7.2 convertit les clés des tables de hashage des tableaux et des tables de hachage des objets sont converties dans les bons formats, de sorte que les chaînes de format numériques personnalisées sont traduites en clefs entières, résolvant le problème d’inaccessibilité.

Les typages explicites d’objets ou « type hints » corrigent une situation dans laquelle un développeur ne peut pas déclarer une fonction supposée recevoir un objet en tant que paramètre ou déclarer qu’une fonction doit retourner un objet. Le correctif utilise l’objet comme type de paramètre et type de retour. HashContext en tant qu’objet, migre l’extension de hachage pour utiliser une extension objet pour les contextes de hachage au lieu d’utiliser des ressources. A noter aussi une nouvelle alerte ajoutée pour l’appel de la fonction count avec un paramètre scalaire ou nul, ou un objet qui n’implémente pas l’interface « Countable »

Mise à jour vers PHP7.2

Cela n’a pris que quelques minutes :

apt update && apt upgrade

Résultat :

Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
  php7.1-cli php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-opcache
  php7.1-readline php7.1-xml php7.1-xmlrpc
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  libargon2-0 libsodium23 php7.2-cli php7.2-common php7.2-curl php7.2-fpm php7.2-gd php7.2-json
  php7.2-mbstring php7.2-opcache php7.2-readline php7.2-xml php7.2-xmlrpc
The following packages will be upgraded:
  php-common php-curl php-fpm php-gd php-mbstring php-xml php-xmlrpc php7.1-cli php7.1-common
  php7.1-curl php7.1-fpm php7.1-gd php7.1-json php7.1-mbstring php7.1-mcrypt php7.1-mysql
  php7.1-opcache php7.1-readline php7.1-soap php7.1-xml php7.1-xmlrpc php7.1-zip
22 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
Need to get 8,656 kB of archives.
After this operation, 19.7 MB of additional disk space will be used.

A ce stade, nous avons php7.1 et php7.2 installés séparément sur le serveur.

On installe les paquets manquants (toujours les deux mêmes):

apt install php7.2-mysql

On édite chacun des VirtualHosts sous Nginx, en éditant cette ligne:

fastcgi_pass unix:/run/php/php7.2-fpm.sock;

On relance NginX et PHP:

service php7.2-fpm restart && service nginx restart

Si tout va bien, il suffit de supprimer PHP7.1, ses dépendances et ses fichiers de configuration:

apt purge php7.1-*

Test de votre code sous PHP 7.2

Vous hésitez encore à sauter le pas ? Copiez-collez votre code sur le site d’3v4l, vous saurez immédiatement si cela produit des erreurs de type Notice.

Bonne mise à jour !

Serveur dédié : mise à jour vers Debian 9 Stretch photo

Serveur dédié : mise à jour vers Debian 9 Stretch

Cette semaine, le système d’exploitation du serveur principal passe de Debian 8 Jessie à Debian 9 Stretch.

Mise à jour des paquets du système

La mise à jour s’est faite plutôt simplement pour la majeure partie des paquets :

apt update && apt upgrade

mais il a fallu s’y reprendre à plusieurs fois pour les paquets restants :

apt install 

Changements dans la configuration

Quelques changements notables sont à noter.

Configuration apt

On vérifie que tous nos dépôts pointent bien vers la version Stretch:

nano /etc/apt/sources.list

On sauvegarde et on lance les mises à jour:

apt update && apt upgrade

Configuration SSH

La configuration SSH a été modifiée et certaines directives ne sont plus valables. Avant de redémarrer le serveur SSH ou de rebooter et de perdre tout accès au serveur SSH, assurez-vous que la configuration est correcte :

sshd -t

Résultats :

/etc/ssh/sshd_config line 25: Deprecated option KeyRegenerationInterval
/etc/ssh/sshd_config line 26: Deprecated option ServerKeyBits
/etc/ssh/sshd_config line 44: Deprecated option RhostsRSAAuthentication

Il ne vous reste plus qu’à éditer le fichier de configuration SSH:

nano /etc/ssh/sshd_config

J’ai désactivé les lignes qui posaient problème et ai rajouté de nouveaux protocoles de clé :

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Sauvegardez le fichier puis lancez cette commande pour créer les couples de clés privées/publiques dans /etc/ssl:

ssh-keygen -A

Résultat:

ssh-keygen: generating new host keys: ECDSA ED25519

Vérifiez une dernière fois qu’il n’y a aucun problème avec le fichier de configuration SSH:

sshd -t

et redémarrez le service SSH:

service ssh restart

Configuration de Courier

C’est le bon moment de revoir la configuration IMAP et POP de Courier.

On commence par renouveler notre fichier Diffie-Hellman en 4096 bits:

cd /etc/courier
openssl dhparam -out dhparams4096.pem 4096

et on revoit la configuration de /etc/courier/imap-ssl :

SSLPORT=993

SSLADDRESS=0

SSLPIDFILE=/run/courier/imapd-ssl.pid

SSLLOGGEROPTS="-name=imapd-ssl"

IMAPDSSLSTART=YES

IMAPDSTARTTLS=YES

IMAP_TLS_REQUIRED=1

COURIERTLS=/usr/bin/couriertls

TLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_STARTTLS_PROTOCOL=TLS1_2:TLS1_1:TLS1

TLS_CIPHER_LIST="ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS"

TLS_KX_LIST=ALL

TLS_COMPRESSION=ALL

TLS_CERTS=X509

TLS_DHCERTFILE=/etc/courier/dhparams4096.pem

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

TLS_TRUSTCERTS=/etc/ssl/certs

TLS_VERIFYPEER=NONE

TLS_CACHEFILE=/var/lib/courier/couriersslcache
TLS_CACHESIZE=524288

MAILDIRPATH=Maildir

Le chemin de SSLPIDFILE a changé donc pensez à le vérifier.

Certificat TLS pour Courier

Depuis que j’utilise les certificats TLS de Let’s Encrypt, il y a une petite modification a exécuter pour que le certificat s’applique aussi à notre serveur de mail : créer automatiquement un certificat pour Courier dès que notre certificat principal est généré.

On crée un script bash pour compiler notre clé privée et notre certificat Let’s Encrypt :

nano /home/scripts/letsencrypt-skyminds-mailserver.sh

avec :

#!/bin/bash
cat /etc/letsencrypt/live/skyminds.net/privkey.pem /etc/letsencrypt/live/skyminds.net/fullchain.pem > /etc/courier/skyminds-cert.pem

et on édite notre fichier Let’s Encrypt pour le renouvellement :

nano /etc/letsencrypt/renewal/skyminds.net.conf

et on ajoute la directive renew_hook avec notre nouveau script:

[renewalparams]
account = ...
renew_hook = /home/scripts/letsencrypt-skyminds-mailserver.sh

Il ne reste plus qu’à éditer la configuration IMAP:

nano /etc/courier/imapd-ssl

et y mettre :

TLS_CERTFILE=/etc/courier/skyminds-cert.pem

puis redémarrez le service:

service courier-imap-ssl restart

Voilà, ce sont les principales modifications a effectuer lors de la mise à jour vers Debian 9.

The Reaper : mise à jour vers Ubuntu 16.04 Xenial Xerus photo

The Reaper : mise à jour vers Ubuntu 16.04 Xenial Xerus

Aujourd’hui, ma machine desktop – The Reaper – vient d’avoir une jolie petite mise à jour et passe d’Ubuntu 14.04 à 16.04, codename Xenial Xerus.

The Reaper : mise à jour vers Ubuntu 16.04 Xenial Xerus photo

Mise à jour d’Ubuntu

La mise à jour se fait assez simplement :

sudo apt update && sudo apt upgrade
sudo apt autoremove
sudo apt dist-upgrade

Comme je n’installe que des versions LTS (Long-Time Support) sur cette machine, il y avait plus de 2.3 Go de paquets à télécharger soit un sacré paquet de mises à jour.

Plusieurs erreurs sont apparues pendant l’installation, qui a laissé à peu près une trentaine de paquets non configurés et non des moindres : GRUB, initramfs-tools etc.

En regardant les messages d’erreurs, j’ai vu que le problème se situait au niveau de DPKG.

Lorsqu’un paquet obsolète bloque DPKG

Si cela vous arrive, pas de panique. Il faut juste régler le problème *avant* de redémarrer la machine.

On commence par relancer la configuration des paquets non configurés:

dpkg --configure -a

En résultat, vous obtenez une (très) longue liste de tous les paquets non configurés avec tous les messages d’erreurs associés. Ce qui importe, ce sont les premières lignes du résultat : le paquet qui bloque est toujours mentionné en premier.

Dans mon cas, il s’agissait d’un paquet obsolète depuis Ubuntu 12.04 (donc depuis 4 ans), virtuoso-nepomuk. Je l’ai donc totalement supprimé :

sudo apt purge virtuoso-nepomuk

On relance ensuite la configuration des paquets :

dpkg --configure -a

Puis une petite vérification des nouveaux paquets au cas où et la suppression des paquets obsolètes :

sudo apt update && sudo apt upgrade && sudo apt autoremove

Un reboot plus tard, Ubuntu 16.04 boote tranquillement. Je conseille de régler le problème des paquets non configurés avant le reboot, c’est bien plus galère autrement.

Réactiver les dépôts désactivés pendant la mise à niveau

Enfin, il reste à réactiver les dépôts APT qui ont été désactivés pendant la mise à niveau.

Lire la suite