Le sujet de ce billet n'est pas de parler de la configuration de Yunohost en tant que serveur mail, je pars du principe que tout est bien configuré (niveau DNS) et que Yunohost est bien fonctionnel.

L'objet de ce billet est de recensé les différents mails qui sont envoyés de façon automatique par différents traitement et processus automatisés depuis un serveur tournant sous Yunohost.

Prérequis - les alias mails

Dans l'espace d'administration de Yunohost, sur ma fiche utilisateur, j'ai les alias mails suivants :

Tout mail envoyé à l'une de ces adresses est envoyé à l'adresse mail principal de mon utilisateur Genma. J'ai configuré ce mail dans Thunderbird pour pouvoir les lire. J'ai d'ailleurs faits des filtres selon le destinataire pour les classer.

Remarque : tous ces mails sont envoyés par le serveur de mail tournant sur Yunohost à lui-même (si les alias sont bien sur le domaine lié à la machine Yunohost) mais peuvent également être envoyés en copie à un mail autre (chez Free par exemple, dans mon cas) si le champ "Adresses de transfert" est "également rempli".

Les mails envoyés automatiquement par Yunohost

Ci-dessous, j'ai essayé de classer une bonne partie des mails que je reçois sur ma boite, envoyé par un serveur Yunohost. Pour chacun je donne l'expéditeur, le sujet, le destinataire, le corps du message si pertinent et un petit texte explicatif.

Les mails de diagnostique automatique

* Expéditeur : Cron Daemon
* Sujet : 'Cron test -x /usr/sbin/anacron || ( cd / && run-parts —report /etc/cron.daily )'
* Destinataire : root@mondomaine.fr
* Corps du message : Automatic diagnosis on mondomaine.fr 'Issues found by automatic diagnosis on mondomaine.fr' The automatic diagnosis on your YunoHost server identified some issues on your server. You will find a description of the issues below. You can manage those issues in the 'Diagnosis' section in your webadmin.

Depuis la version 3.8, Yunohost propose en graphique au sein de l'espace d'administration et en ligne de commande, un outil de diagnostique automatique assez complet indiquant les modifications à faire sur le paramétrage DNS et autre. Ce rapport est envoyé par mail chaque nuit.

Remarque : il faut que je rédige un billet de blog dédié sur ce sujet.

Renouvellement des certificats (Let's Encrypt)

* Expéditeur : certmanager@mondomaine.fr
* Destinataire : root@mondomaine.fr
* Sujet : Certificate renewing attempt for mondomaine.fr failed !
* Corps du message : An attempt for renewing the certificate for domain mondomaine.fr failed with the following
error : Certificate renewing for mondomaine.fr failed ! Here's the tail of /var/log/yunohost/yunohost-cli.log, which might help to investigate :

Les domaines et sous-domaines pour lesquels le certificat autosigné a été remplacé par un certificat Let's Encrypt voient leurs certificats renouvellés de façon automatique. Parfois, le renouvellement peut présenter une erreur (temps de latence ou autre).

Suite à l'installation d'une application

* Expéditeur : root
* Sujet :`etherpad_mypads` has just been installed
* Destinataire : root@mondomaine.fr
* Corps du message : This is an automated message from your beloved YunoHost server. Specific information for the application etherpad_mypads.

A l'installation d'une nouvelle application, le compte root reçoit un mail.

Mail non envoyé

* Expéditeur : MAILER-DAEMON@mondomaine.fr
* Destinataire : genma@mondomaine.fr
* Sujet : Undelivered Mail Returned to Sender

Quand on utilise sa boite mail / le serveur Yunohost compte serveur de mail et qu'il y a eu un soucis à l'envoi du mail (destinataire inconnu ou autre...)

Message d'alerte

* Expéditeur : genma@mondomaine.fr
* Sujet : *** SECURITY information for genma.ynh.fr ***
* Corps du message : yunohost : Apr 30 12:23:09 : genma : 1 incorrect password attempt ; TTY=pts/1 ; PWD=/var/www/nextcloud/config ; USER=root ; COMMAND=/bin/nano config.php

Quand on tente de se connecter plusieurs fois via la commande sudo et que l'on fait une faute de frappe dans son mot de passe, le compte reçoit un mail pour informer de l'erreur (et de la potentielle tentative de brute force par exemple).

Le bulletin de sécurité

* Expéditeur : daemon@mondomaine.fr
* Destinataire : root@mondomaine.fr
* Sujet : Debian security status of Yunohost

Mail non envoyé par défaut par Yunohost, ce mail est lié au fait que j'ai installé le paquet "Unattended Upgrades" pour avoir des mises à jour de sécurité automatique de mes instances Yunohost.

Conclusion

J'espère que ce petit billet sera utile. Il aurait probablement sa place dans la documentation officielle de Yunohost. A faire par moi ou toute personne souhaitant le faire ;)

J'écoute beaucoup de podcasts, sur des sujets divers et variés, je fais des critiques de ces derniers au bout de quelques numéros, une fois que je suis définitivement abonné. Suivant l'actualité de Nextcloud de près, car c'est mon sujet du moment, c'est avec intérêt et curiosité que j'ai vu l'annonce de la sortie d'un 1er épisode d'un podcast Nextcloud par Nextcloud.

Le podcast Nextcloud est une interview / discussion autour d'un thème, à confirmer avec les épisodes futurs. Épisodes non encore annoncés et aucune information sur une quelconque fréquence ou rythme de publication. Le podcast Nextcloud est un podcast anglophone (Jos est allemand) sobre et sans fioriture : il n'y a pour l'instant pas de virgule sonore, pas de jingle. Le son de l'enregistrement est de bonne qualité.

Au moment de la publication du présent billet, une seule émission a été publiée, sobrement intitulée Introducing : the Nextcloud Podcast !, d'une durée de 35 minutes, dans ce tout premier épisode, on a le droit à une présentation du concept de ce podcast, suivi d'une discussion avec le concepteur et gestionnaire de communauté de Nextcloud, Jan Christoph Borchardt. La discussion est axée sur la création de Nextcloud avec l'histoire du fork d'Owncloud et la relation qu'à Nextcloud avec Owncloud.

A noter que c'est animé par Jos Poortvliet, Head of Marketing, Cofondateur de Nextcloud.

Le podcast est disponible à l'écoute en ligne via un player intégrée ou via différents canaux (téléchargement d'un fichier au format mp3, aac ; écoute via Apple /itunes, Spotify...), toutes les adresses étant sur l'url

https://nextcloud.com/fr_FR/podcast/.

Les RPM d'AMC (Auto Multiple Choice) version 1.4.0 pour Fedora 32 sont disponibles dans le dépôt eddy33.

$ sudo dnf install perl-Gtk3 perl-Clone
$ sudo dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-32.rpm 
$ sudo dnf install auto-multiple-choice

Depuis que j'ai la Freebox Révolution (depuis bientôt 7 ans), j'utilise la fonction NAS qu'offre cette dernière via son boîtier serveur, qui intègre un disque dur. Le disque dur est utilisé pour les enregistrements fait par la Freebox, mais permet aussi de stocker et partager des vidéos, des photos, des fichiers directement téléchargés par la Freebox. Je ne détaillerai pas plus les fonctionnalités de la Freebox, on retrouve facilement des tas d'informations à ce sujet.

Dans les fonctions de partage, il est possible de partager le disque dur via le protocole Samba (Partage Windows). Cela marchait très bien jusqu'à ce que je passe ma machine principale sous Ubuntu 20.04 en avril dernier. La Freebox est bien vu sur le réseau dans l'interface du gestionnaire de fichiers (Nautilus), mais quand je clique pour me connecter et consulter le contenu du disque dur comme j'avais l'habitude de faire, je tombe sur un message

J'ai essayé pas mal de choses, dont la connexion au répertoire partagé via la ligne de commande avec les commandes liées à samba sans succès, jusqu'à ce que je tombe sur ce message dans le forum d'Ubuntu-fr.

Le protocole samba de la freebox est bloqué sur SMB1, ce qui est obsolète et non sécurisé. Ce qui fait qu'avec la dernière MAJ, les disques ne sont plus lisibles. J'ai contourné le soucis en activant le serveur ftp depuis le Freebox OS. Du coup, tout est redevenu comme avant, juste une petite manip supplémentaire à effectuer.

Confirmé par une mise en avant de la note suivante sur la page de documentation de la freebox v6 dans le wiki d'ubuntu-fr : A partir de Ubuntu 17.10 : Il est possible que vos montages réseaux utilisant cifs ne fonctionne plus. En effet, suite à la monté en version du protocole Samba (SMB3 désormais, au lieu de SMB1). Un palliatif est de forcer l'utilisation de Samba en version 1 en rajoutant vers=1.0 dans les options de montage. Comme dans l'exemple ci-dessus.

Deux solutions :
forcer le protocole samba en version 1 en ligne de commande pour le montage du partage réseau (c'est documenté, on a des lignes de commandes et le fichier /etc/fstab à modifier) ;
activer le FTP.

Je suis parti sur l'option 2 pour changer un peu. Le soucis est que, via FTP, quand je saisis l'url ftp://mafreebox.freebox.fr/ dans le champ "Connexion à un serveur" de Nautilus, même si je vois le contenu du disque dur, je ne peux pas lire / ouvrir un fichier directement depuis la Freebox, il faut que je le télécharge en local.

Pour remédier à ça, il faut monter le disque distant via ftp avec fuse et curlftpfs. Là encore, c'est documenté sur
https://doc.ubuntu-fr.org/curlftpfs

Et pour le montage avec les droits de lecture /écriture, il faut saisir la commande ainsi :

Je me suis fais un alias Bash pour me faciliter la vie. Je lance l'alias depuis un terminal et dans Nautilus, j'ai mon disque monté en lecture / écriture à distance.