Illustration d'un ordinateur portable fonctionnant sous Ubuntu avec du code sur son écran, un grand bouclier avec un cadenas devant, et des serveurs derrière. Des engrenages, des camemberts et des graphiques représentent la cybersécurité, la protection des données et l'importance de réparer la mise à niveau.

Ubuntu : réparer une mise à niveau plantée ou interrompue

par · Lecture: 14 minutes

Une mise à niveau Ubuntu peut parfois mal se terminer : coupure de courant, batterie vide, paquet cassé, pilote graphique incompatible, partition pleine, GRUB endommagé ou redémarrage au mauvais moment. Résultat : Ubuntu ne démarre plus, reste bloqué sur un écran noir, affiche un shell d’urgence ou refuse d’ouvrir la session graphique.

Bonne nouvelle : dans beaucoup de cas, le système n’est pas perdu. Il faut surtout terminer proprement la mise à niveau, réparer les paquets cassés, régénérer GRUB ou corriger les pilotes. Mauvaise nouvelle : il faut procéder méthodiquement. Le mode “je tape dix commandes trouvées au hasard” marche rarement mieux qu’un tournevis dans un grille-pain.

Voici une méthode moderne pour réparer Ubuntu après une mise à niveau plantée ou interrompue, depuis le mode recovery ou depuis une clé USB live.

Lire la suite

Le logo de MySQL représente le contour minimaliste d'un dauphin sautant au-dessus du mot "MySQL". Le mot "My" est en bleu et le mot "SQL" en orange, le tout dans une police de caractères moderne et arrondie. Le dauphin symbolise la vitesse et la fiabilité lors des opérations sur les tables.

MySQL : gérer, purger ou désactiver les binary logs

par · Lecture: 7 minutes

Sur un serveur MySQL, les binary logs peuvent vite prendre beaucoup de place. Il n’est pas rare de découvrir plusieurs dizaines, voire plusieurs centaines de gigaoctets de fichiers binlog.* après quelques mois d’activité.

Ces fichiers ne sont pas des logs applicatifs classiques. Ils enregistrent les modifications effectuées sur les bases de données, afin de permettre la réplication, certaines stratégies de sauvegarde, et la restauration à un point précis dans le temps.

En clair : avant de les supprimer ou de les désactiver, il faut comprendre à quoi ils servent sur votre serveur. Sinon, vous risquez de récupérer de l’espace disque tout en cassant votre stratégie de backup. Mauvais troc.

À quoi servent les binary logs MySQL ?

Les binary logs, ou journaux binaires, enregistrent les événements qui modifient les données : INSERT, UPDATE, DELETE, créations de tables, modifications de structure, etc.

Ils servent principalement à trois choses :

  • répliquer les modifications vers un ou plusieurs serveurs replicas ;
  • rejouer des transactions après une restauration de sauvegarde ;
  • faire du point-in-time recovery, c’est-à-dire restaurer une base jusqu’à un instant précis.

Si votre serveur MySQL est autonome, sans réplication, sans cluster, sans sauvegarde incrémentale basée sur les binary logs, et sans besoin de restauration fine, vous pouvez envisager de désactiver les binary logs.

En revanche, si vous utilisez la réplication, MySQL Router, un cluster, un service de backup qui lit les binlogs, ou une stratégie de restauration avancée, ne les désactivez pas. Dans ce cas, configurez plutôt une rétention raisonnable.

Lire la suite

Une souris grise de dessin animé court énergiquement avec un grand sac postal beige étiqueté "MAIL" sur son épaule, l'air enthousiaste dans des gants et des chaussures jaunes. En dessous, "POSTFIX" est écrit en gras, ce qui indique une livraison rapide et non une erreur verify_cache.db ou un bogue de la base de données Berkeley.

Postfix : corriger l’erreur « message file too big »

par · Lecture: 6 minutes

En consultant les logs d’un serveur mail, vous pouvez tomber sur une erreur Postfix de ce type :

postfix/sendmail[6460]: fatal: www-data(33): message file too bigLangage du code : HTTP (http)

Dans un contexte WordPress, cette erreur apparaît souvent lorsqu’une extension tente d’envoyer une sauvegarde de base de données, une archive ZIP, un export ou un rapport volumineux par email.

Le message est assez clair : l’utilisateur système www-data, donc PHP/WordPress sur Debian ou Ubuntu, essaye de soumettre un email trop gros pour la configuration Postfix actuelle.

La correction consiste à vérifier la limite configurée, l’ajuster si besoin, puis se demander si l’email est vraiment le bon transport pour ce type de fichier. Spoiler : pour des backups WordPress lourds, la réponse est souvent non.

Comprendre l’erreur “message file too big”

Postfix limite la taille maximale d’un message avec le paramètre message_size_limit. D’après la documentation officielle Postfix, sa valeur par défaut est 10240000 octets, soit environ 10 Mo. Cette limite concerne la taille complète du message, enveloppe comprise, et pas seulement la pièce jointe. Documentation officielle Postfix postconf(5).

C’est un détail important : une pièce jointe de 8 Mo peut produire un email plus gros que 8 Mo, car l’encodage MIME/Base64 ajoute du poids. En pratique, l’email final peut être environ un tiers plus gros que le fichier attaché.

Donc, si une sauvegarde SQL compressée pèse 9 Mo, elle peut tout à fait dépasser une limite Postfix de 10 Mo une fois transformée en pièce jointe email. Charmant, n’est-ce pas ?

Lire la suite

Suivant →