Gestion des messages sortants de Postfix (queues)

Récemment, j’ai eu des problèmes d’envoi d’emails avec le serveur SMTP Postfix, étant une chose rare, je ne me souviens jamais de certaines commandes de gestion des files d’attente de messages sortants de Postfix. Voici un petit mémo.

Lister les files d’attente Postfix

Postfix possède 2 queues d’envoi d’emails : la liste d’emails en cours d’envoi (pending mails) et la liste d’emails differés (deferred mails). La queue des emails différés sont les messages qui ont été en soft-fail et sont mis en attente pour essayer d’être envoyés plus tard. Leur statut est Temporary failure. Par défaut, Postfix essaie 5 minutes plus tard.

  • Lister les messages en cours d’envoi :
    mailq
  • Lister les messages différés :
    postqueue -p

Supprimer les messages

  • Pour supprimer les messages de la queue :
    postsuper -d ALL
  • Pour supprimer tous les messages dans la queue des emails différés :
    postsuper -d ALL deferred

Envoyer les messages

Si inversement vous voulez envoyer les messages et ainsi vider la file d’attente :

postqueue -f

ou

postfix flush

Envoi automatique d’un email lorsque le téléchargement d’un fichier torrent est terminé avec Transmission

C’est assez sympa d’être prévenu lorsqu’un fichier torrent est totalement téléchargé, donc disponible. Avec la version daemon de Transmission, voici comment faire pour recevoir un email de notification dès qu’un fichier est téléchargé à 100%.

  • Ajouter ce script dans le répertoire de votre choix. Dans mon exemple je l’ai nommé complete.sh :
    #!/bin/bash
    
    echo "Ceci est un message automatique de votre tant aimé transmission-daemon ($TR_APP_VERSION), vos fichiers sont prêts dans $TR_TORRENT_DIR " | /usr/bin/mail -s "Torrent terminé : $TR_TORRENT_NAME" nom@domaine.net
  • Stopper le service transmission-daemon, sous Fedora 25 :
    sudo systemctl stop transmission-daemon
  • Éditer les lignes suivantes du fichier de configuration de Transmission qui se situe sous ~/.config/transmission-daemon/settings.json :
    "script-torrent-done-enabled": true,
    "script-torrent-done-filename": "/votre/chemin/vers/complete.sh",
  • Redémarrer transmission-daemon :
    sudo systemctl start transmission-daemon

C’est tout, maintenant dès que le téléchargement d’un fichier est terminé, vous recevrez un email.

Erreur urn:acme:error:connection lors du renouvellement d’un certificat Certbot

Vous avez un certificat Certbot (Let’s Encrypt) que vous renouvelez toujours sans problème tous les 90 jours, et récemment une erreur du type de celle ci-dessous survient alors que votre serveur fonctionne normalement.

Failed authorization procedure. mon.domaine.net (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: Could not connect to mon-domaine.net

Il y a des dizaines et des dizaines de publications sur ce message d’erreur, qui logiquement renvoient vers des problèmes d’accessibilité au serveur (DNS) ou aux fichiers de celui-ci (permissions). D’ailleurs Certbot vous donne des indices dans ce sens :

To fix these errors, please make sure that your domain name was
 entered correctly and the DNS A record(s) for that domain
 contain(s) the right IP address. Additionally, please check that
 your computer has a publicly routable IP address and that no
 firewalls are preventing the server from communicating with the
 client. If you're using the webroot plugin, you should also verify
 that you are serving files from the webroot path you provided.

Mais comme dans mon cas, tout était fonctionnel.

IPv4 et IPv6

Après des heures à chercher et trifouiller ma configuration, je me suis rendu compte qu’un telnet mon.domaine.net 80 faisait déjà une résolution sur l’IPv6 de mon domaine avant de passer en IPv4. J’ai donc cherché dans ce sens et découvert que depuis peu Certbot privilégie IPv6 si un enregistrement DNS de type AAAA existe pour le domaine, ce qui était mon cas.

J’ai supprimé l’enregistrement AAAA (ce n’est peut-être pas le plus préférable, mais pour l’instant je m’en contente), et le renouvellement s’est bien déroulé avec succès.

Protéger un accès SSH avec fail2ban sous CentOS 7

Se prémunir de tentatives d’intrusion serveur en protégeant l’accès SSH avec fail2ban sous CentOS 7

Une connexion SSH sur un serveur est une opération plutôt sécurisée, mais cela ne veut pas dire que le serveur en question est protégé d’une quelconque tentative d’intrusion, notamment par force brute. D’ailleurs en analysant les logs système, même sur un petit serveur anodin, on peut en général voir des dizaines, voir des centaines de connexions avec des utilisateurs connus (root) ou inconnus qui échouent. Ce ne sont pas des attaques à proprement parler, mais des tentatives de connexion en essayant des combinaisons de nom d’utilisateur et de mot de passe. C’est sur ce genre de terrain que fail2ban peut aider à mieux protéger un serveur de connexions non voulues en créant des règles de pare-feu automatiquement suivant certaines conditions.

Continuer la lecture de « Protéger un accès SSH avec fail2ban sous CentOS 7 »