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”

by · 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 bigCode language: 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

Transférer des fichiers d'un serveur à un autre avec rsync sous Linux photo 1

Rsync : corriger l’erreur “protocol version mismatch — is your shell clean?”

by · Lecture: 6 minutes

Lors d’une synchronisation avec rsync over SSH, il peut arriver de tomber sur cette erreur :

TERM environment variable not set.
protocol version mismatch -- is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2)Code language: JavaScript (javascript)

Le message est un peu cryptique, mais la cause est souvent simple : le shell distant affiche du texte au moment où rsync s’attend à parler uniquement avec le processus rsync distant.

Autrement dit, la connexion SSH fonctionne, mais quelque chose pollue le flux : un echo, un message de bienvenue, une commande interactive, un script dans .bashrc, un fortune, un neofetch, un tput, une bannière, ou un message lancé depuis /etc/ssh/sshrc.

Et rsync, lui, n’a aucun humour dans ce cas. Il lit du texte inattendu au lieu du protocole attendu, puis il répond : “is your shell clean?”. Traduction libre : “ton shell bavarde trop”.

Pourquoi rsync affiche “is your shell clean?”

Quand vous lancez une commande comme celle-ci :

rsync -avz ./site/ user@example.com:/var/www/site/Code language: JavaScript (javascript)

rsync ouvre une connexion distante, souvent via SSH, puis démarre un autre processus rsync sur le serveur distant. Les deux processus échangent ensuite des données selon le protocole rsync.

Si le shell distant imprime quelque chose avant le démarrage du rsync distant, le protocole est contaminé. Quelques caractères suffisent à casser l’échange.

La documentation rsync explique que l’erreur “protocol version mismatch — is your shell clean?” vient généralement de scripts de démarrage ou de la couche shell distante qui produisent une sortie parasite sur le flux utilisé par rsync. La méthode de diagnostic recommandée consiste à lancer une commande distante silencieuse et à vérifier qu’elle ne produit aucune sortie.

Lire la suite

CSS : définir la taille d'un champ texte photo

CSS : définir la largeur d’un champ texte proprement

by · Lecture: 6 minutes

Lorsqu’un champ texte déborde d’un formulaire, d’une barre de recherche ou d’un bloc latéral, on pense souvent que l’attribut HTML size suffit à régler le problème.

En pratique, ce n’est pas le bon réflexe. Pour contrôler proprement la largeur d’un champ texte, il faut utiliser CSS : width, max-width, box-sizing, et parfois clamp() pour un comportement responsive.

L’attribut HTML size définit le nombre de caractères visibles dans certains champs input. Il ne remplace pas une largeur CSS fiable dans une interface moderne. MDN précise que, pour un élément input, size correspond au nombre de caractères visibles pendant l’édition de la valeur.

Le problème : un champ texte trop large

Imaginons un champ de recherche placé dans une zone étroite : une sidebar, un menu mobile, un header, un widget WordPress ou un petit formulaire d’inscription.

Le HTML ressemble souvent à ceci :

<label for="recherche">Recherche</label>
<input
    id="recherche"
    name="recherche"
    type="search"
    size="15"
>Code language: HTML, XML (xml)

On pourrait croire que size="15" force le champ à mesurer exactement quinze caractères de large. Pourtant, selon la police, le navigateur, les styles hérités, le padding, la bordure et le contexte du layout, le résultat peut varier.

Et surtout, size ne règle pas le vrai problème : intégrer le champ dans une mise en page CSS.

Lire la suite

Suivant →