Yunohost, Let’s Encrypt – Soucis de renouvellement automatique pour un sous-domaines

J'aime bien avoir des sous-domaines thématiques et une application installé à la racine de sous domaine. Exemple cloud.toto.com avec Nextcloud à la racine (accessible via cloud.toto.com), rss.toto.com... Sur chacun de sous-domaines j'ai activé les certificats Let's Encrypt (fonctionnalité inclue par défaut dans l'interface d'administration des domaines de Yunohost).

J'avais un soucis de renouvellement automatique d'un certificat Let's Encrypt d'un sous-domaine qui arrivait à expiration, signalé par mail via la tâche cron qui gère ce renouvellement.

J'ai tenté via l'interface de renouveler le certificat ( Accueil > Domaines > status.toto.com > Certificat) et j'ai eu l'erreur du type

Wrote file to /tmp/acme-challenge-public/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw, but couldn't download http://
status.toto.com/.well-known/acme-challenge/MtjRxzsCW2l5NCj7Y-vfMoIviNHmtxv0eJp1FS9kuaw

L'application installée (Cachet) était à la racine du domaine status.toto.com

Depuis la gestion de l'application dans la partie administration de Yunohost, j'ai migré l'application vers /cachet (Applications > Cachet > Changer l'URL)

J'ai alors relancé le renouvellement du Certificat depuis l'interface d'administration (clic sur le bouton "Renouveler manuellement maintenant).

Ça a marché !

J'ai rechangé l'url de l'application Cachet pour qu'elle soit de nouveau vers /, l'application Cachet est donc à la racine du domaine status.toto.com et la seule application du sous-domaine. Et le certificat pour le domaine status.toto.com est bon pour 89 jours...

A voir si lors de l'arrivée de la prochaine expiration du certificat pour ce sous-domaine je dois faire la même chose...

A noter que pour d'autres sous-domaines plus anciens ayant eux aussi des applications installées à la racine du sous-domaine (du coup une seule application par sous-domaine), je n'ai pas de soucis de renouvellement automatisé. A creuser via les logs à l'occasion.

Chatonkademy – Billet N°3 – FreshRSS, Yunohost et plusieurs utilisateurs

Série de billets sur le projet Chatonkademy

Dans ce billet je voudrais parler du cas de FreshRSS sur Yunohost avec plusieurs utilisateurs. Pour rappel, FreshRSS est une application de type agrégateur RSS, fort pratique (on peut se connecter dessus via son API pour avoir une application mobile avec EasyRSS (voir Yunohost, FreshRSS et EasyRSS pour Android).

A la suite de la création et de l'installation de l'instance Yunohost, j'ai créer un utilisateur pour moi (Genma), qui est l'utilisateur par défaur puis installer différentes applications dont FreshRSS. J'ai ensuite fait la création des utilisateurs en masse (une quarantaine) sur cette instance.

L'application n'est pas une application publique et partagée, chaque utilisateur a donc l'application disponible pour lui et aura la gestion de son propre contenu.

Le soucis est que les différents utilisateurs au moment du premier usage de FreshRSS (et des fois suivantes), rencontraient différents soucis : pas de possibilité d'importer un fil RSS, pas de possibilité de changement de langue...

La solution est de reprendre le répertoire FreshRSS de l'utilisateur qui était là à l'installation de FreshRSS et de dupliquer ce répertoire nécessaire au bon fonctionnement de FreshRSS.

Cela se fait via

cd /var/www/freshrss/data/users
# On prend comme liste d'utilisateurs ceux qui ont un dossier dans /home (créer automatiquement par Yunohost, à l'exception des dossiers Yuno*
for user in `ls /home -I yuno*` do
# On copie le dossier existant de l'utilisateur qui était initialement présent avant l'installation de FreshRSS
cp -R genma/ $user
# on change les droits car il faut que ce soit www-data le propriétaire du dossier
chown -R www-data: ./$user
done

On remarque donc que les données pour l'application FreshRSS dans Yunohost se trouvent dans le dossier /var/www/freshrss/data/users/
Ces données sont un fichier config.php qui contient des préférences / paramétrage de l'application et un fichier de log, log.txt qui contient des logs spécifiques à l'application (différents des logs liés à nginx qui se trouvent dans /var/log/nginx/).

Les données (fils RSS auxquels on est abonné, catégorie, lu ou non lu...) sont dans la base de données et sont bien sauvegardées par le script de l'application. Seul le paramétrage de l'interface n'est donc pas sauvegardé par défaut. A prendre en compte dans le processus de sauvegarde.

Yunohost 3.0 sur Debian 9 – Retour d’expérience rapide

Jusqu'à présent, Yunohost n'était compatible avec Debian 9 Stretch (uniquement Debian 8 Jessie). A l'annonce du passage en phase de test Beta sur le forum pour la compatibilité Debian 9, ayant un peu de temps, pour tester, je me suis lancé.

Yunohost 3.0 ?

Actuellement la version stable est la version 2.7.x. La version 3 apporte la compatibilité avec Debian 9 : une migration sur une instance déjà installée fait que la machine passe sous Debian 9. On a alors des versions plus récentes de PHP (passage de 5 à 7), ce qui sera mieux pour les futures versions à venir de Nextcloud qui nécessitent Php7. Et on est enfin sous Debian 9. Et ça c'est cool aussi.

Test dans une machine virtuelle clone de mon instance de production

Pour avoir un bac à sable qui ne craint rien, j'ai refait un clone complet via Clonezilla de mon instance de production (et j'ai ainsi un backup complet tout frais, en plus des sauvegardes régulières) que j'ai réimporté dans une nouvelle VM Virtualbox. Pour me connecter à celle-ci, j'ai modifié mon fichier hosts pour que l'IP de la VM corresponde aux noms de domaines de mon Yunohost de production. Je résume vite fait car je me suis basé sur mon expérience précédente abordée dans les billets précédemment écrit Yunohost dans Virtualbox et Yunohost, Clonezilla et Virtualbox

Et j'ai trouvé des bugs

J'ai ainsi pu tester plusieurs fois la migration (et repartir du snapshot fonctionnel de la VM), en indiquant à chaque fois les erreurs rencontrées, cherchant des solutions et contribuant ainsi, modestement, à mon niveau à Yunohost. Je suis assez content car mes tests ont permis de détecter des erreurs sur les applications suivantes Sonerezh et Nextcloud.

Dont voici la correction...

Le détail et toute la démarche faite durant quelques heures passées à comprendre et chercher est sur le forum, je donne directement les solutions :

Sonerezh

Il y a deux lignes où il y a des # et non des ; (ancien système de commentaire de PHP non compatible avec PHP 7).
On édite le fichier de configuration pour faire la correction :

nano -l /etc/php/7.0/fpm/pool.d/sonerezh.conf

Nextcloud

Module PHP manquant conduisant à une erreur Interne (500 dans les logs)

apt-get install php7.0-apcu -y
service nginx restart

J'ai au passage vu que les logs de Nextcloud ne sont pas dans /var/log/nginx/monsousdomaine.domaine.log (soit les logs du domaine nginx lié à Nextcloud) mais dans le fichier /home/yunohost.app/nextcloud/data/nextcloud.log

Reste à voir comment on peut faire pour ajouter tout ça en patch / proposée que ces corrections soient faites automatiquement dans les migrations et installations des applications dans YunoHost.

Sachant que pour Sonerezh, le code source de l'application en elle-même n'est plus maintenue, il faut probablement ajouter la modification dans le script de migration ou d'installation de Sonerezh en tant qu'application YunoHost. A voir.

Migrer ou non ?

La version est encore en Beta. Je ne l'ai pas testé assez longtemps pour voir si il n'y a pas d'autres soucis. J'attendrai donc la sortie officielle en version stable courant juin pour migrer mon instance de production (que j'utilise tous les jours), en attendant, dès que j'ai un peu de temps, je continuerai sur l'instance de test dans Virtualbox pour voir comment je peux continuer à aider un peu un projet que j'utilise quotidiennement. La moindre des choses étant, à mon niveau, d'aider un peu.

Mais dès à présent, de ce que j'ai pu voir, les applications suivantes sont fonctionnelles : Amapache, Dokuwiki, FreshRSS, Kanboard, Shaarli, Roundcube, Wallabag, Sonerezh (suite à la correction), WemaWema, Phpmyadmin et Nextcloud. Reste quand même à tester ça en profondeur.

Chatonkademy – Billet N°1 – Les utilisateurs

Série de billets sur le projet Chatonkademy

Introduction
Le projet continue et d'autres billets sont en cours de rédaction. Je publie celui-ci pour partager quelques astuces de bases dont j'ai eu besoin. Dans celui-ci, quelques astuces sur les utilisateurs et Yunohost (rappel : dans le projet il y a une instance Yunohost multi utilisateur).

Créer des utilisateurs en masse dans Yunohost

On fait appel à la moulinette. On crée un script du type
Dans le présent script, les mot de passe sont en dur

#!/bin/bash

yunohost user create chaton01 -p motDePasseChaton01 -f chaton01 -l chaton01 -m chaton01@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton02 -p motDePasseChaton02 -f chaton02 -l chaton02 -m chaton02@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton03 -p motDePasseChaton03 -f chaton03 -l chaton03 -m chaton03@chatonkademy.com --admin-password motDePassAdminYunohost
yunohost user create chaton0X -p motDePasseChaton04 -f chaton0X -l chaton0X -m chaton0X@chatonkademy.com --admin-password motDePassAdminYunohost

Largement améliorable en utilisant des variables pour les mots de passe utilisateur et le mot de passe administrateur, ce qui évite de les mettre en dur au sein du script.

Applications

Dans mon cas, tous les utilisateurs ont accès à toutes les applications. J'ai installé les applications après la création des utilisateurs.
Je ferai un billet (ou plusieurs) sur le cas des applications.

Surveiller leurs connexions

Le besoin est le suivant : les utilisateurs ont été crées, le mot de passe communiqués. Comment suivre si l'instance Yunohost est bien utilisée et si oui par quels utilisateurs. Il y a plusieurs façons de faire et de voir il y a des connexions des utilisateurs.

Tous les logs de connexion se trouvent dans le fichier /var/log/nginx/chatonkademy.com-access.log

Les logs étant compressés, on peut passer par zcat et créer un fichier de cumul des logs dans /tmp/access.log pour avoir un suivi depuis le début de la création de l'instance.

cat /var/log/nginx/chatonkademy.com-access.log >> /tmp/access.log
zcat /var/log/nginx/chatonkademy.com-access.log.*.gz >> /tmp/access.log

Un peu de shell en une ligne permet de faire pas mal de choses, selon les besoins. Quelques exemples :

Ip et utilisateur

root@cloud:# cat /tmp/access.log |cut -f1 -d '[' |sort -u
1.2.3.1 - chaton01
1.2.4.5 - chaton02
1.2.1.2 - chaton03
1.2.1.2 - chaton01
1.2.1.4 - chaton04

Nombre de connexion par utilisateur

cat /tmp/access.log |grep -v "\- \-" |cut -f1 -d '['|cut -d "-" -f2 |sort |uniq -c |sort -nr
5733 chaton03
1525 chaton02
1334 chaton01
913 chaton04

Quel(s) utilisateur(s) se connecte quel jour ?

cat /tmp/access.log |cut -f1 -d ']' |grep -v "\- \-" |cut -f1 -d ':'|cut -f2 -d '-'|uniq |sed 's/\[//g'
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton04 11/Apr/2018
chaton01 11/Apr/2018
chaton03 12/Apr/2018
chaton02 12/Apr/2018
chaton01 12/Apr/2018
chaton02 12/Apr/2018
chaton03 12/Apr/2018

Analyse des logs en graphique

On pourra envisager l'installation de la suite ELK (ElasticSearch Logstash Kibana, pourquoi pas) avec des dashbords qui vont bien pour avoir le reporting des connexions. Pour faire faire plus simple et déjà avoir quelques graphiques, j'ai eu recours un GoAccess. Voir à ce sujet Yunohost - Goaccess - Rapport HTML depuis des logs d'un serveur web.

J'ai repris l'idée de faire l'installation de customWebApp dans Yunohost appelée "Logs" dans laquelle je dépose un fichier index.html qui est le rapport généré par GoAccess

Création d'un script qui contient

#/bin/bash
goaccess --log-format=COMBINED -f /tmp/access.log -a -o /var/www/my_webapp/www/index.html

On le lance via

./root/script_goaccess.sh

On consulte les logs via https://chatonkademy.com/logs/ tout simplement.

Chatonkademy – Billet N°0 – Présentation du projet

Dans le cadre du projet d'une école du numérique auquel je participe, l'OpenHackademy, nous (des membres d'une de mes équipes et moi-même) avons été amené à mettre en place l'infrastructure informatique qui sert aux apprenants dans le cadre de leur formation.

Au fur et à mesure, nous documentons tout ça en interne. Comme je me dis que l'expérience peut être utile à d'autres, je débute par le présent billet une une série de billets techniques relatant tout ce que nous avons pu apprendre dans la mise en place de cette infrastructure et son maintien au quotidien, son évolution...

Ce retour d'expérience se basera également sur l'expérience d'autres CHATONS avec lesquels j'ai pu échangé et discuté, venant ainsi compléter si besoin mes propos, proposer d'autres solutions logicielles que celle que j'ai pu mettre en place si il y a lieu, justifiant ainsi les choix techniques réalisés.

Présentation du projet

Pourquoi Chatonkademy ? Ce petit nom n'est autre que la contraction de CHATON et OpenHackademy. Pour l'OpenHackademy je vous renvoie vers >mon billet de blog dédié sur le sujet. Pour les CHATONS, le Collectif des Hébergeurs Alternatifs,Transparents, Ouverts, Neutres et Solidaires, vers le site du projet : https://chatons.org

En quelques mots, CHATONS ce sont les AMAP de l'informatique libre. Promouvant le projet au travers mon implication au sein de l'association Framasoft.

L'infrastructure

L'infrastructure repose sur un hyperviseur tournant sous Proxmox avec une IP fixe (en IPv4) et une IPv6, les différentes problématiques liées à l'usage d'une seule IP publique avec des ports particuliers (web, ssh etc.) seront abordés dans des billets dédiés.

Les machines virtuelles

Chaque étudiant a sa propre machine virtuelle pour son apprentissage. Les machines virtuelles sont gérées par les étudiants qui ont les droits administrateurs sur les machines (via un compte sudoers). Nous avons déployés ces machines sous Debian 9 et nous les avons "ansibelisées" : les playbooks etc. seront mis à disposition dans des billets dédiés. L'intervention sur plusieurs machines à distance en même temps (pour saisir la même commande), la gestion des logs centralisés pour ces différentes machines, leurs sauvegardes etc. Toutes ces problématiques donneront lieu, là encore, droit à des billets dédiés.

Yunohost

Ayant sensibilisé les apprenants au projets aux problématiques tel Le cloud, c'est l'ordinateur d'un autre et à celui de faire de la veille, (voir à ce sujet mon billet Le combo gagnant pour optimiser sa veille), j'ai mis en place une instance Yunohost multi-utilisateurs. Je suis administrateur de l'instance, chaque étudiant a son compte sur Yunohost et les applications que je lui mets à disposition.

Je ferai un ou plusieurs billets dédiés sur la gestion de Yunohost dans le cadre d'un certain nombre d'utilisateurs (40), le côté mono ou multi-utilisateur des applications (partagée publiquement ou non, cloisonnée pour chaque utilisateur ou non). Cette expérience sera également l'occasion de passer d'une instance Yunohost personnelle à une instance de plus grand niveau. Selon la sollicitation de l'instance, je serai amené à augmenter ou réduire sa capacité matérielle (ce qui se fait aisément vu qu'il s'agit d'une machine virtuelle), je ferai des retours d'expériences sur quelle type de machine pour combien d'utilisateur en même temps.

Conclusion

Pour conclure ce premier billet numéroté 0, il y a déjà pas mal de choses à rédiger et mettre en forme, à anonymisée avant de mettre à disposition sous la forme de tutoriels et billets de blogs. Ce premier billet donne, je pense, une bonne idée des billets et projets à venir (tous les chantiers ne sont pas finis et pour beaucoup la peinture n'est pas encore sèche). A suivre donc :)

Yunohost – Usage depuis le réseau local

Configuration du réseau : mon PC portable et mon serveur Yunohost sont branchés tout deux derrière la Freebox, qui crée un réseau locale entre ces deux machines. La Freebox est configuré en routeur, son IP publique est associée au nom de domaine du serveur Yunohost et la configuration NAT fait que toute entrée depuis l'extérieur (via l'IP publique), sur le bon port, est redirigée vers le serveur Yunohost.

Dans son message sur le forum Yunohost, Koantig a une configuration similaire et s'inquiète de l'usage du nom de domaine quand on est en local

Le hic, c'est que tout ça passe par internet, alors que tout est local. J'aimerais faire en sorte que si je suis sur le réseau local, les requêtes ne passent pas par internet.

Et arrive à la conclusion qu'il faut associer l'IP locale de la machine au nom de domaine dans le fichier /etc/hosts.

Sa solution marche, mais dans le cas où on déplace la machine (cas d'un PC portable par exemple), il faut penser à enlever cette ligne.

Est-ce que ça sort vraiment sur Internet ?

Pour le vérifier, si je fais depuis mon réseau local un "traceroute mondomaine.fr", on voit qu'on s'arrête au premier routeur, qui a pour IP l'IP publique de la Freebox. On ne sort donc pas de la Freebox et d'Internet. Certe la Freebox va refaire du transfert NAT et changer les paquets pour les retransferer à la machine Yunohost, ce qui est une étape de plus contrairement à l'usage directement de l'IP locale (dans ce cas les fonctions de routeur et de NAT de la Freebox ne sont pas sollicités)

Sur le réseau local, derrière ma Freebox, ma Freebox sait que si une machine local demande l'IP publique correspondant à Yunohost, elle doit rediriger le trafic vers mon Yunohost. La Freebox fait une redirection NAT en interne, mais ça "ne sort" pas sur Internet.

Est-ce qu'on perd du temps ?
Si je fais
ping IP locale, j'ai :

64 bytes from IP Locale: icmp_seq=1 ttl=64 time=0.303 ms
64 bytes from IP Locale: icmp_seq=2 ttl=64 time=0.314 ms
64 bytes from IP Locale: icmp_seq=3 ttl=64 time=0.306 ms
64 bytes from IP Locale: icmp_seq=4 ttl=64 time=0.273 ms
64 bytes from IP Locale: icmp_seq=5 ttl=64 time=0.269 ms

Soit 289 ms de moyenne.

Si je fais ping IP publique, j'ai :

64 bytes from IP Publique: icmp_seq=1 ttl=64 time=0.253 ms
64 bytes from IP Publique: icmp_seq=2 ttl=64 time=0.488 ms
64 bytes from IP Publique: icmp_seq=3 ttl=64 time=0.488 ms
64 bytes from IP Publique: icmp_seq=4 ttl=64 time=0.253 ms

Soit 370 ms de moyenne.

C'est effectivement "un peu plus lent" (vu qu'on fait le routage et la redirection NAT avec l'IP publique), mais ce n'est pas suffisament sensible.

Yunohost, deux ans après

Un petit billet rapide, en attendant le retour des billets techniques les prochaines semaines (et prochains mois).

Début décembre 2015, suite à une discussion avec l'ami Solarus lors du Capitole du libre de Toulouse, je me décidais enfin à franchir le pas de l'autohébergement. Je débutais donc l'année 2016 en publiant 2016 année de l'autohébergement ? au sein duquel j'expliquais le début de mon aventure sur le sujet. Depuis nombreux sont les billets que j'ai publié tagué et Yunohost, écrit au fur et à mesure des mois et de mon apprentissage et appropriation du système.

De la plupart de mes services hébergés sur les serveurs de Framasoft dans le cadre du projet Degooglisons, je suis passé à du tout auto-hébergé pour tout ce qui concerne mon propre besoin en terme de cloud. D'un Raspberry et carte SD, je suis passé à une machine de type mini-pc de récupération, avec 2 Go de mémoire et un processeur Intel Atom, une machine de faible consommation électrique, qui a presque 10 ans mais qui tourne toujours et convient parfaitement à mes besoins.

J'ai suivi et je suis les évolutions des différents projets autres, comme CozyCloud, mais je suis et je reste fidèle à Yunohost qui correspond vraiment à ce dont j'avais besoin. Ca marche, c'est stable (ça reste une base Debian stable et donc par définition, c'est stable). Je n'ai jamais réinstallé ma machine qui tourne depuis plus d'un an et demi et ma machine tourne H24. Je l'ai déjà redémarré (mise à jour du kernel), éteinte volontairement (ou involontairement comme dans le cas d'une coupure de courant prolongée).

Mais... Je fais les mises à jour. Je teste les packages dans une machine virtuelle avant (Voir Yunohost, Clonezilla et Virtualbox & Yunohost, Virtualbox, Interfaces réseaux). Je sais revenir en arrière. Je fais et j'ai testé la restauration de mes sauvegardes... Je ne bidouille pas ma machine de production.

J'ai déjà eu des coupures de courant, je n'ai pas de corruption majeure mais ce n'est pas une carte SD dedans. Mon mini PC tient la route est solide, le matériel est éprouvé et supporté depuis longtemps par Linux. Il n'a rien d'exotique et a été conçu pour tourner en continue (c'est le genre de mini-PC qu'on branchait derrière un écran, il a d'ailleurs le format VESA).

J'avais écris différents billets dont celui sur l'élitisme de l'auto-hébergement je vous y renvoie pour plus de détails, mais je continue de penser que l'auto-hébergement reste quelque chose destiné à des personnes s'y connaissant et ayant le temps d'apprendre (La preuve est le fait que j'ai une VM de recette, que je ne fais pas modifications directement sur ma machine finale, je fais des sauvegardes etc.).

Mais l'initiative de CHATONS, le Collectif des Hébergeurs Alternatifs, Transparents, Ouverts, Neutres et Solidaires continue son petit bonhomme de chemin. Je pense que cela reste la solution viable pour le grand public, pour celles et ceux qui n'ont pas, comme moi, la possibilité d'avoir du temps, l'envie d'apprendre etc. car ils ou elles ont plein d'autres choses à faire (et à juste titre). Car le plus important, que ce soit via soi-même ou via un CHATONS, c'est d'avoir un cloud respectueux de ses données personnelles.

Un Meetup Yunohost ? Appel pour aider ce projet

Présentation du Meetup

Qu'est ce que le projet #Yunohost ? En quoi est-il facile de se créer un #cloud personnel et de passer à l'autohébergement ? Quelles sont les contraintes ? Comment et pourquoi doit-on décentraliser Internet ? Quel est le rapport avec #Framasoft et #DégooglisonsInternet ? Et avec la #BriqueInternet ? Comment s'approprier ce projet et contribuer ? Comment packager une application ?

Durée : 1h30 de présentation suivie des questions

Objectif de date : courant janvier 2018.

Présentation de Yunohost

Je parle assez régulièrement de Yunohost sur ce blog, pour le reste je vous renvoie sur le site Internet http://yunohost.org/. Toutefois, en quelques mots et en résumé, Yunohost c'est le système qui fait tourner la Brique Internet, mais pas que. Yunohost est une surcouche à Debian mais reste du Debian (ce sont juste des scripts en plus). Framasoft dédié une journée de temps d'un de ses salariés durant laquelle, chaque semaine, du travail est fait pour packager les applications (ajouter des scripts shell simples qui permettent une installation et configuration des applications dans Yunohost).

Ce dont j'ai besoin ?

Je recherche actuellement lieu pour accueillir le meetup le temps d'une soirée. Il n'y a pas de budget pour cette soirée, le lieu doit donc être gratuit et je compte sur la bonne volonté des participant.e.s pour apporter un petit quelque chose à grignoter. Le lieu doit être facile d'accès (idéalement sur Paris) et mettre à disposition un vidéo-projeteur (ou un système de projection équivalent) et une connexion à Internet.

Remarque : le lieu d'accueil pourra faire sa promotion (principe du meetup).

Aider le projet ?

Si votre entreprise peut accueillir ce meetup, si vous voulez m'aider à trouver un lieu d'accueuil, si vous voulez m'aider à accueillir les personnes lors de cette soirée, vous êtes le.la bienvenu.e et je vous invite à me contacter.

Foire aux questions

Je compléterai cette série de questions en fonction des retours et demandes que je recevrai. Date de dernière mise à jour : le lundi 27 novembre 2017

Pourquoi ne pas le faire au sein de ton entreprise ?

Ce projet est un projet personnel et sera fait sur mon temps personnel et d'un commun accord avec mon employeur, je souhaite séparer mes activités professionnelles de mes activités personnelles.

Pourquoi un meetup et pas...

L'appellation meetup est le buzzword à la mode et l'objectif est d'organiser une soirée qui regroupera des personnes de la communauté Yunohost tout comme d'attirer des personnes ne connaissant pas le projet mais ayant l'habitude de participer aux événements regroupés sous l'appellation Meetup.

Est-ce que je peux parler lors de cette soirée ?

Pourquoi pas. Le support de présentation du meetup est quasiment réalisé et est prêt et je suis plus sur la demande d'aide sur l'organisation du projet en lui-même que sur le contenu.

Comment on s'inscrit ?

Faites signe et je mettrai en place une liste de diffusion par mail. Et pour l'inscription, je lancerai très probablement un framadate.

Yunohost – Pourquoi les ports 80 et 25 sont ils toujours utilisés ?

Telle est la question que l'on trouve, en anglais, sur le forum de YunoHost.

La question est légitime car ces deux ports, ne présentent pas, par défaut, de connexion sécurisé. Pour avoir une connexion avec du chiffrement, il faudra passer par une connexion en httpS (et le port 443), ou en ImapS (et le port 993).

Une explication est donnée en anglais, par ljf, Groupe Core Dev (développeur du projet). Je la cite et je la traduit ci-dessous, la diffusion de l'information en langue française pouvant être utile au non anglophone.

Port 25 is necessary to send email to other unsecured smtp (if we close this port, some mails couldn't be delivered.


Port 80 is needed by let's encrypt for the ACME challenge, by some YunoHost setup without internet connexion ( in Africa or Asia) which users need to be able to access page without warning, by some website which users are under the "TLS intermediate config" (not so old android device, XP...). In general application packagers make choice or not to redirect port 80 to HTTPS. Sometime just one part of the app (web administration) force https.

A new settings system has been introduce to be able to let more option to the yunohost administrator, but for now, there are no settings developped to let the admin to be able to configure it.

Traduction libre

Le port 25 est nécessaire pour envoyer un courriel à d'autres serveurs smtp qui eux ne sont pas sécurisés (si ce port est fermé, cela aura pour conséquence que certains mails ne puissent être livrés.

Le port 80 est nécessaire pour le challenge ACME de Let's Encrypt, et pour des cas d'installation YunoHost sans connexion internet (en Afrique ou en Asie) pour lesquelles les utilisateurs ont besoin d'accéder à la page de connexion sans avoir un avertissement, pour des mises à dispositions d'applications pour des utilisateurs qui n'ont pas accès au niveau de configuration nécessaire pour une connexion TLS (vieux appareil Android, XP ...). En général, les packageurs d'applications choisissent ou non de rediriger le port 80 vers HTTPS. Par défaut, une seule partie de l'application YunoHost (la partie administration Web) force une redirection vers https.

Un nouveau système de paramétrage a été introduit pour être en mesure de laisser plus de latitude à un administrateur yunohost, mais pour l'instant, il n'y a pas d'interface de développer permettant à l'administrateur d'être en mesure de le configurer.

Yunohost, Virtualbox, Interfaces réseaux

J'avais publié rapidement un billet Yunohost, Clonezilla et Virtualbox expliquant que j'avais fait un clone via Clonezilla de ma machine Yunohost et cloner celle-ci au sein d'une machine virtuelle dans VirtualBox. Dans ce billet, je voudrais aller un peu plus loin et aborder l'aspect configuration et paramétrage réseau.

Remarque :
- Par YunohostProd, je désignerai la machine / serveur sur laquelle j'ai mon Yunohost que j'utilise tous les jours ;
- Par YunohostTest, je désignerai le clone / la machine virtuelle dans VirtualBox.

Mon besoin

Mon besoin est donc d'avoir une machine de test, aussi proche que possible de ma machie de production. L'avantage de la machine virtuelle est de pouvoir jouer avec et faire des tests, revenir en arrière très facilement via les snapshots.

VirtualBox - Quelles cartes réseaux ?

Cet environement de test est testé essentiellement sur deux types de réseaux : chez moi, derrière une Freebox. Et sur un réseau d'entreprise.

Sur chacun des machines virtuelles (que j'utilise dans VirtualBox, indépendamment du fait que ce soit une instance Yunohost), je crée à minima deux cartes réseaux :
- une carte eth0 en mode NAT : l'accès Internet de la machine hôte est alors partagé, je peux faire des mises à jour etc. La machine virtuelle voit Internet mais n'est pas vu du réseau local (elle est derrière un NAT qui est géré par VirtualBox).
- une carte eth1 en mode Réseau Privé hôte sur vbonet0 : la machine est visible et voit la machine hôte et réciproquement. Cette interface réseau me sert pour me connecter en SSH depuis ma machine hôte sur la machine virtuelle.

A ces deux interfaces réseaux, j'en ajoute une troisième :
- une carte eth2 en mode Accès par pont (Bridge). Cette interface est uniquement valable dans le cas où le réseau permet à la machine virtuelle d'avoir une IP dédiée (fixe ou via le DHCP). En entreprise (par exemple), là où les IP sont souvent associées aux adresses MAC, il n'est pas possible d'avoir une IP dédiée pour les machines virtuelles de test ; je désactive donc cette interface. De chez moi, quand je suis connecté sur le réseau de la Freebox, j'active cette carte eth2, ma machine virtuelle a donc une IP dédiée sur le réseau local.
Remarque : vu que via cette interface, la machine hôte voit également la machine virtuelle étant donné qu'elles sont sur le même réseau local, je pourrais désactiver l'interface eth1 quand je peux activer eth2.

Qui voit quoi ?
- via la carte en NAT : la VM a accès à Internet pour les mises à jour derrière un NAT. Elle est invisible du réseau local et de la machine hôte, à moins de faire des redirections de port ;
- via la carte Réseau privé : accès à la machine hôte et réciproquement ; la VM est également visible des autres machines virtuelles situées dans le même réseau privé.
- via la carte Réseau Accès par Pont : comme la machine virtuelle a accès au réseau local et sa propre IP sur le réseau, elle est visible des machines du réseau local en accès direct.

Configuration réseau - DHCP par défaut Pour chacune des interfaces réseaux de ma machine virtuelle, je reste en DHCP par défaut. Je pourrais lui affecter des IP fixes, mais je peux savoir facilement (c'est indiqué au lancement de Yunohost) les différentes adresses IP associées aux différentes interfaces réseaux ; le bail DHCP étant assez long - la machine garde toujours les mêmes IP pour les différentes interfaces.

Connexions à la VM Yunohost

Les connexions Yunohost se font de deux façons :
- par un navigateur pour l'accès aux différentes applications dans Yunohost ;
- par SSH

Sur ma machine hôte (un Linux), pour me simplifier la tâche et Yunohost utilisant les noms de domaines qu'ont lui a associé plutôt que les IP, quand je lance ma machine virtuelle, je pense à modifier le fichier /etc/host

monyunohost.fr 192.168.0.100

avec :
- monyunohost.fr : mon domaine yunohost
- 192.168.0.100 : l'IP du réseau privé affecté par VirtualBox à la machine virtuelle (interface eth1).

Et ainsi, en allant sur https://monyunohost.fr, je peux faire ce que j'ai à faire.

Reste à faire

- Du routage avancé Tout le trafic passe par défaut - est routé via l'interface eth0, celle qui est donc Naté. Cela ne pose pas de soucis pour tout ce qui sort. Mais pour ce qui entre, il est nécessaire de passer par la carte eth1.
=> Il faut que je vois les possibilités de ce côté.

- Mise en place d'une synchronisation Prod vers Recette Je peux très facilement cloner la machine virtuelle YunohostTest pour avoir une machine pour les tests et une machine "Sauvegarde".
J'aurai donc une seconde machine virtuelle, YunoBackup, qui aura une interface eth2 avec une IP du réseau sur lequel se trouve la machine YunohostProd. Les deux machines se voient. Mon idée est de mettre en place un système (un script) qui au démarrage de la machine virtuelle de Sauvegarde (YunoBackup) va se connecter en SSH à ma machine de production, et se synchroniser (à base de Rsync) pour récupérer les principaux changements.
Autre possibilité : récupérer les sauvegardes et les restaurer au sein de cette machine YunoBackup (un bon moyen de valider la procédure de sauvegarde / restoration). Toujours via un script.
=> Je note ça dans ma todo liste de projets personnels. A suivre.

Yunohost – Goaccess – Rapport HTML depuis des logs d’un serveur web

Présentation de GoAcess

GoAccess présente des statistiques en lisant les logs de votre serveur Web, non pas en exécutant du code côté utilisateur.

Site : https://goaccess.io/

GoAccess fonctionne en ligne de commande et présente par défaut ses résultats dans la console, en temps réel. Une série de panels (que l'on peut étendre individuellement) présentent les différents types de données : nombres de visiteurs uniques, URL non trouvées, OS, etc. Classique. Il est également possible de générer une − plutôt jolie − page html

Le site GoAccess : analyse simple et efficace des logs d'un serveur Web - https://hal-9000.fr/?s11R3Q a fait un tutoriel qui montre qu'il est assez simple d'installer et d'utiliser GoAccess.

Autres tutoriels présentant des astuces complémentaires :
- Goaccess : un autre outil de Web Analytics par Denis Szalkowski
- GoAccess – Des logs web en temps réel et en cli

GoAccess répond à mon besoin

J'ai étudié différents systèmes permettant de générer des rapports à partir de logs, je connais un peu ELK (ElasticSearch, LogStash, Kibana), mais ça reste très complexe et un peu usine à gaz pour mon besoin qui est de tout simplement superviser / avoir des rapports issus des logs de mon serveur Yunohost. Donc GoAcess correspond bien à mon besoin.

Par défaut, Yunohost conserve les logs du serveur Nginx un certain temps (il faudra que je regarde en détail la configuration de logrotate), cela convient

Automatisons un peu tout ça...

L'objectif est d'avoir des rapports réguliers en HTML. Pour ça, j'ai mis en place une tâche CROn qui va faire une concatènation des différents fichiers de logs et générer un seul et même rapport HTML via GoAccess qui contient donc une visualisation graphique de l'ensemble des données issues de ces logs. Je peux ensuite m'envoyer le rapport par mail, le récupérer, le mettre à disposition dans un espace dédié du serveur web...

#/bin/bash

# On fait le cat dans /tmp pour que ce soit effacer ensuite
cat /var/log/nginx/blog.genma.fr-access.log* > /tmp/blog.genma.fr-access.full.log
echo "Goacess - Lancement de la generation des rapports HTML"
goaccess --log-format=COMBINED -f /tmp/blog.genma.fr-access.full.log -a -o BlogFullReport.html
# Le fichier BlogFullReport.html contient un beau rapport HTML complet généré par Goaccess.
echo "Goacess - Fini"

Yunohost ?

Yunohost propose la création de coquille vide pour des applications, via les Multi Custom Webapp, une version forkée des Custom Webapp qui permettent d'en créer plusieurs.

J'installe l'application en indiquant comme paramétrage :
- Nom de l'application : GoAccess
- Adresse et chemin : moninstanceyunohost.fr et /goacess comme sous répertoire
- Utilisateur : genma

Ca mouline (il y a la création et modification de la configuration nginx qui se fait) et ensuite j'ai bien une tuile "GoAccess" dans la liste des applications et un dossier "/var/www/webapp_genma/GoAccess" dans lequel j'ai par défaut le fichier "index.html".

Il ne reste qu'à ajouter au script ci-dessus une ligne du type

mv /tmp/BlogFullReport.html /var/www/webapp_genma/GoAccess

et depuis un navigateur web, en étant connecté à Yunohost d'aller sur
https://moninstanceyunohost.org/goacess/BlogFullReport.html

pour avoir le beau rapport généré par GoAccess !

Aller plus loin ?

Il suffit de faire un script un peu plus avancé, de le mettre en tâche planifiée (cron) et de créer par exemple un fichier index.html qui contiendra par exemple une série de liens :
- BlogFullReport_Jour1.html
- BlogFullReport_Jour2.html
- BlogFullReport_Jour3.html
- InstanceFullReport_Jour1.html
- InstanceFullReport_Jour2.html
- InstanceFullReport_Jour3.html

Ici les fichers InstanceFullReport_JourX.html étant généré par une ligne faisant appel à GoAcess mais pour un cumul de logs de fichiers Nginx pour l'instance (cumul des fichiers de log nginx pour monistanceyunohost.fr).

Yunohost et les applications Framasoft

Comme je le disais dans mon billet et ma conférence De Framasoft à Yunohost, réapproprions nous le cloud un partenariat avait été mis en place entre Framasoft et Yunohost avec du temps d'un salarié de Framasoft consacré au packaging d'application Framasoft pour Yunohost.

Quelques mois après, où en est-on ?

L'idée n'est pas de parler au nom de Framasoft mais plus de remettre en avant cette collaboration et de faire un petit suivi de l'avancement. Une image valant mieux qu'un long discours :

On peut donc voir qu'il reste donc encore des applications à packagées, il faut maintenir les packages existant (en les faisant évoluer pour que les applications installées sur une instance Yunohost soient mises à jour ou qu'une installation fraîche installe la dernière version de l'application...)

Si vous souhaitez aider, si vous avez un peu de temps ou tout simplement des retours d'expérience à faire, il y a un topic dédié dans le forum Yunohost sur le sujet.

Contribuez à Yunohost

D'une façon plus générale, Yunohost a besoin de contributeurs pour tous les aspects du projet. A savoir :
- backend : python (simple), bash (lua)
- frontend : html/js (sammy.js)
- packging des apps : full bash, et des connaissance en sysadmin sont nécessaires (configuration nginx)
- sécurité : revue de code
- infrastructure du projet : debian, deb toolchain, ruby
- relation avec la communauté : communication, support via le forum, dans les issues de Git...
- aide à la traduction et à la documentation
- testing (les versions beta) avec rapport de bugs
- ...

Debian – Rester sur une version ; passer de stable en stable

Yunohost n'est pas compatible avec Stretch

Debian Stretch est sortie en version stable au début de l'été. Pour le détail, voir la dépêche Linuxfr Debian 9 : Stretch déploie ses tentacules.

Les changements apportés par cette version sont suffisamment importantes pour que Yunohost ne soit pas encore compatible. Pour rappel, Yunohost repose sur Debian en n'étant qu'une surcouche (les manipulations spécifiques à Debian restent possibles, même si il faut savoir ce que l'on fait pour ne pas casser la compatibilité avec Yunohost).

Pour en savoir plus, voir le sujet dans le forum : Debian Stretch | YunoHost is NOT YET compatible | YunoHost N'EST PAS ENCORE compatible

Comment rester sur une version de Debian

Comme indiqué dans le message du forum, il faut donc conserver la mention "jessie" comme version dans le fichier sources.list et autres.

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr jessie main
deb-src http://url_du_depot.fr jessie main
deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

Autre façon de faire, avec la commande sed, pour remplacer "main" par "jessie".
Dans le fichier "install" de l'application non officielle (à utiliser en connaissance de cause)
no_stretch_ynh

# Backup old sources.list
sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

sudo cp -R /etc/apt/sources.list.d /etc/apt/sources.list.d.bak

# Change sources.list with "stable" as distribution
sudo sed -i "s@ stable \+main@ jessie main@g" /etc/apt/sources.list
sudo sed -i "s@ stable-updates @ jessie-updates @g" /etc/apt/sources.list
sudo sed -i "s@ stable/updates @ jessie/updates @g" /etc/apt/sources.list

# Idem for sources.list.d/*.list
sudo sed -i "s@ stable \+main@ jessie main@g" /etc/apt/sources.list.d/*.list
sudo sed -i "s@ stable-updates @ jessie-updates @g" /etc/apt/sources.list.d/*.list
sudo sed -i "s@ stable/updates @ jessie/updates @g" /etc/apt/sources.list.d/*.list

Ou au contraire, comment migrer d'une version stable à une autre

Si on souhaite faire des montées de version stable en version stable pour suivre les évolutions de Debian (pour un serveur ou un poste bureautique sur lequel cela est possible), au contraire, on aura un fichier sources.list du type :

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr stable main
deb-src http://url_du_depot.fr stable main
deb http://security.debian.org/ stable/updates main
deb-src http://security.debian.org/ stable/updates main

Et si c'est en version testing de Debian que l'on veut être (pourquoi pas), ce sera donc :

$ cat /etc/apt/sources.list
deb http://url_du_depot.fr testing main
deb-src http://url_du_depot.fr testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main

Au revoir Twitter ?

Dans ce billet je ne présenterai pas Mastodon. Beaucoup de billets expliquent le phénomène Mastodon et je vous renvoie vers eux pour en savoir plus, le fonctionnement etc. En quelques mots, Mastodon c'est Twitter, mais en version décentralisé. La décentralisation a plusieurs avantages comme permettre de ne plus avoir un SILO de type GAFAM mais un réseau social réparti.

Twitter et moi, une longue histoire

Je suis présent sur Twitter depuis ses débuts en France ; j'ai commencé sur Twitter en 2008 à une époque où Patrick Beja, le podcasteur du Rendez-vous Tech en parlait régulièrement et personne ne comprenait l'intérêt et le but... Il y a quelques années au début des années 2010, j'ai écris un certain nombre de billets sur Twitter, les réseaux sociaux étant alors en pleine croissance et n'étant pas encore devenu grand public. Les milieux technophiles se les étaient déjà bien appropriés mais Twitter n'était pas encore utilisé sur les chaînes de télévision pour les missions en direct...

N'étant pas un blogueur influent comme Korben, une célébrité ou autre, je tourne à un peu de plus de 2.000 comptes de personnes que je qualifierai de sensibiliser au logiciel libre, ce qui me semble être un dénominateur commun assez large. Afin d'éviter d'être dans une bulle, je suis aussi des comptes autres…. J'ai régulièrement fait du tri, pour limiter le nombre de compte que je suis. Trop de personnes suivies, c'est beaucoup de bruit, trop d'informations...

J'ai eu des phases où j'ai passé beaucoup (beaucoup trop) de temps sur Twitter. En ce moment, je suis plus dans une phase où je regarde de temps en temps. Au petit déjeuner le matin, un peu le midi, le soir en rentrant. Rapidement en journée. Je réponds au mention, j'ai quelques interactions. Mais je ne suis plus aussi actif que j'ai pu l'être. Je suis passé à autre chose.

Pourquoi partir ?

Avec le temps, je pense que je vais peu à peu partir de Twitter car Mastodon correspond à ce que je cherche et attends de Twitter. Plusieurs personnes ont le même sentiment, celui que Mastodon rappelle les débuts d'Internet. Pour moi qui suis sur Internet depuis 1998 (et là je me rencontre que je vais fêter mes 20 ans d'Internet l'année prochaine), qui suis arrivé sur Twitter 10 ans après, qui est vu l'évolution de Twitter, l'évolution et son arrivée dans le grand public et auprès des stars, des politiques etc. Je me rappelle d'avoir refait le monde en suivant en direct les débats sur Hadopi via Twitter... J'ai eu de très bons moments. Mais Twitter, même si c'est moins pire, ça reste centralisé et quand un outil offre ce que je cherche, correspond à mes besoins et attentes et la question de "Est-ce que Twitter ça vaut encore la peine ?" se pose...

Diaspora ?

Quand on pense décentralisation et réseau social, on pense à ce qui existe déjà, à savoir Diaspora. Diaspora et Mastodon ne sont pas concurrent pas plus que Facebook et Twitter ne sont concurrents. Je dirais que ce sont deux réseaux complémentaires et deux réseaux alternatifs. Et pourtant, Diaspora ne me convient pas. Comme je l'expliquais dans mon billet Diaspora et ses principales spécificités, Diaspora, d'une certaine façon, m'impose de suivre des personnes. C'est le contraire que je cherche et que l'on a sur Twitter et donc sur Mastodon. Je suis une personne car je la connais ou je m'intéresse. Si la personne pense que je l'intéresse ou veut me suivre, elle me suit. Diaspora, j'ai régulièrement des mentions "A commencé à partager avec vous" de parfait inconnus. Et je me retrouve alors avec des messages non sollicités. Je fais régulièrement le travail de partager en retour, en me disant que si la personne a décidé "de partager avec moi", c'est qu'elle s'intéresse à ce que je peux publier. Mais ce mode de fonctionnement en me convient pas.

Le design aussi. Mastodon a repris Twitter à travers Tweetdeck, Diaspora est plus proche d'un Facebook. Avec Mastodon je vais à l'essentiel, j'ai les messages que je suis, ceux qu'on m'envoie et ceux de l'instance publique. J'ai tout rapidement.

Diaspora est plus proche de "Un sujet peut entrainer une longue discussion et des échanges, des messages qui se suivent de type forum" là où Mastodon c'est plus des réactions courtes. Et ce format court qui me plaisait chez Twitter, j'ai le même avec toutefois plus de caractères me permettant de réagir de façon un peu plus longue, mais sans que ce soit digne d'un forum….

Je ne dis pas que Diaspora est à revoir ou autre, juste que à l'heure actuel, cela ne convient pas à mes usages, besoins, attentes. La preuve : j'ai un client Twitter et Mastodon sur mon smartphone, je n'ai plus le client Diaspora (je passe par un ordinateur à chaque fois).

Trop de réseaux ?

Je n'ai pas le temps de maintenir 3, 4, 5 réseaux sociaux. J'avais crée un compte Facebook à la même époque que mon compte Twitter et je n'ai jamais vraiment utilisé Facebook. Ça a été un moment un copier-coller automatisé de mes messages publics Twitter, histoire de toucher un public un peu différent des quelques personnes. Sur Facebook, je suivais quelques personnes qui étaient dessus et qu'on ne trouvait nulle part autre, qui utilisaient Facebook comme un blog et un outil de communication pour parler avec leurs fans (des personnes de la télé des années 80, les stars de mon enfance...)

Le manque de temps, les conditions générales de Facebook, le copier-coller automatisé, font que j'ai enlevé ce système de copier-coller, purger les connexions et pages auxquelles j'étais abonné et mon compte Facebook, bien qu'encore ouvert, ne me sert à rien et je ne me connecte plus dessus depuis des mois (j'ai toutefois une alerte par mail si une connexion se fait, une phrase de passe longue et unique, vu que le compte n'est pas encore fermé).

Et pourtant Twitter m'a permis de faire de belles rencontres

Via Twitter, j'ai découvert beaucoup de personnes, quasiment toutes celles qui constituent mon réseau sociale du monde non numérique actuellement.Des personnes que je ne connais que par leurs personnages publics, que j'ai plaisir à revoir dans le monde non numérique (je rappelle que je parle de monde numérique et non numérique, et non de monde virtuelle et de vraie vie car tout ce que je fais sur Internet et tout autant ma vraie vie si ce n'est plus). Des personnes qui, en dehors du réseau, sont devenu.e.s de véritables ami.e.s, ou au moins des personnes très proches.

Rester ou pas ?

Peu à peu, les personnes qui m'intéressent sur Twitter, mes proches, migrent toutes sur une instance de Mastodon. J'ai besoin de me retrouver avec les miens, dans une sorte de cocon. Ce cocon ce sera Mastodon.

Mais moi qui suis assez régulièrement à aller parler à un public de néophyte, à faire de l'éducation populaire, je me dois d'être là où ce public cible est et il est sur Twitter. Alors je reste, pour utiliser Twitter comme je l'ai toujours fait, comme canal de communication publique et gratuit, pour faire ma propre promotion (publicité ?) ou relayer celles de projets qui me tiennent à cœur, y avoir encore quelques interactions avec les gens n'ayant pas de présence sur Mastodon.

La conclusion ?

Vous pouvez me retrouver sur https://framapiaf.org/@genma, Framapiaf étant une instance Mastodon par Framasoft, un nouveau service du grand projet Degooglisons-internet.org/. En attendant que je lance ma propre instance pour vraiment décentralisé ? Ça tombe bien, des supers contributeurs Yunohost ont fait un package Mastodon. C'est dans la todo-liste et ce sera le sujet d'un prochain billet...

Yunohost – Surveiller l’état de son disque dur

C'est le billet de l'ami Seb0S666 Petit inventaire des disques dur à jeter dans lequel il parle de la vérification de l'état de différents disques durs avant de les mettre au recyclage qui m'a fait pensé qu'il serait peut être important que moi-même je regarde régulièrement l'état du disque dur qui fait tourner mon instance Yunohost sur mon PC maison.

Mon objectif est simple : anticiper la panne physique du disque pour le remplacer avant de perdre des données. A côté de celà, bien sûr, il y a le fait qu'il faille Faire des sauvegardes régulièrement, vérifier qu'elles sont correctes car ce n'est pas le jour où on aura besoin de la sauvegarde qu'il faut s'apercevoir qu'elle ne marche pas, n'est pas valable et qu'on ne peut pas récupérer ses données.

Pour tester l'état du disque dur, il y a l'outil Smartmontools. Un tuto rapide a été fait ici MemoInfo - Comment tester son disque dur pour éviter les pannes et il nous dit que la commande est :

smartctl -a /dev/sda1

Le lancer de temps à la main c'est un bon début, aller plus loin en automatisant tout ça c'est mieux et du coup, comme Yunohost est et reste une surcouche à Debian, on a toute la base Debian. On peut donc suivre le tutoriel Smartmontools - Wiki debian-fr pour automatiser tout ça et avoir le mail qui va bien pour prévenir les erreurs.