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.

A quand un Frama OS ?

Ce billet fait suite à mon premier billet De Framasoft à Yunohost, réapproprions nous le cloud.

Devant l'ampleur que prend le projet Degooglisons Internet avec Framasoft, devant tous les services qui sont mis en ligne, beaucoup sont les demandes d'avoir un système d'identifiant unique pour les différents services et surtout des remarques du type "à quand un Frama OS ?".

Je répondrais en mon nom, en fonction de ce que je sais et ces propos n'engage que moi. Pour le premier point, la demande revient à avoir un annuaire LDAP. Et ce n'est pas là la volonté de Framasoft. Framasoft propose et restera une vitrine de services alternatifs basés sur du logiciel libre, chaque service étant indépendant des autres. Si l'on souhaite un ensemble de services interconnectés et liés avec un même compte, il faudra se tourner vers un membre de C.H.A.T.O.N.S..

Pour le second point, à quand un Frama OS, je répondrais avec un simple mot. Jamais. Comme dit dans ma conférence De Framasoft à Yunohost, réapproprions nous le cloud, je cite : Ne réinventons pas ce qui existe : Un rapprochement et une collaboration Framasoft avec Yunohost se prépare peu à peu. Du temps salarié de Framasoft va être dédié à Yunohost. L'idée est que l'on ait tous les logiciels Framaxxx packagés pour Yunohost.

Réinventer un OS ne sert à rien. Yunohost eux-mêmes n'ont pas inventés un OS, ils utilisent une base Debian et ajoutent des fonctionnalités tels que l'automatisation de la configuration de nginx (entre autre), le développement des différents logiciels (partie utilisateur et administration) sont nécessaires car n'existant pas. Les applications elles sont simplement packagées, au plus près des applications natives... Un peu comme ce que fait Framasoft. Et du coup, les membres de la communauté Yunohost ont entrepris un travail de travail de référencement des applications Framasoft et de leurs existences (ou de ce qui serait équivalent) en tant que package pour Yunohost. Si ce n'est pas le cas, un appel à packagé (et maintenir le package) est lancé. On peut suivre tout ça ici.

Le rapprochement Framasoft avec Yunohost permettra, à terme, à chacun d'avoir les équivalents ou les applications Framasoft disponibles de façon simple. Il suffira pour cela d'installer Yunohost sur un Raspberry Pi autohébergé, sur une Brique Internet (qui rappelons le, utilise Yunohost comme Système d'exploitation), sur un PC ou encore sur un serveur dédié en ligne. Yunohost répondra alors aux deux besoins évoqués ci-dessus. En effet Yunohost intègre un système LDAP et on pourra donc (pour les applications le permettant), avoir un compte unique pour l'ensemble des applications. Et Yunohost répond également à la demande / remarque sur le Frama OS.

Yunohost – Supervision du trafic réseau

Dans mon billet Yunohost - Supervision en ligne de commande, je parlais de quelques commandes que j'utilise pour faire de la supervision / monitoring de ma machine Yunohost (les commandes étant des commandes génériques d'administration d'un système GNU/Linux). Dans ce billet, je m'attarderai plus sur les commandes liées au réseau que j'utilise.

Ces commandes ont été testée sur Debian dans mon cas, mais devraient marcher sur n'importe quel distribution Linux.

netstat

Outil qui permet de voir les ports et connexions en cours :

$ netstat -puant
$ netstat -lapute

Oui l'ordre des options donne un mot explicite, mais au moins c'est facile à retenir et on a là un bonne combinaison des options de la commande.

Ce type de commande donne un résultat comme

Proto Recv-Q Send-Q Adresse locale Adresse distante Etat PID/Program name
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN -

Cette commande est intéressante car elle permet de très rapidement voir quels sont les ports ouverts et utilisés et d'alors régler / affiner le paramétrage de son pare-feu / firewall.

Nethogs

Nethogs permet de surveiller par processus, l'usage de la bande passante en temps réel. Par processus ce sont tous les logiciels utilisant le réseau : client SSH, navigateur etc.

Si en lançant la commande

sudo nethogs eth0
creating socket failed while establishing local IP - are you root?

vous avez une erreur, c'est liée au fait que la version packagée dans Debian n'est pas la dernière version et pour ne pas avoir cette erreur, il faut compiler la dernière version. C'est très rapide eFt ça se fait depuis les sources en suivant ce tutoriel par exemple.

Une fois que c'est fait, on peut lancer la commande et on a alors le résultat :

netHogs version 0.8.5
PID USER PROGRAM DEV SENT RECEIVED
11145 genma sshd: genma@pts/0 eth0 0.131 0.064 KB/sec
? root unknown TCP 0.000 0.000 KB/sec
(...)
TOTAL 0.131 0.064 KB/sec

iftop

Iftop est une commande qui est au réseau ce que Htop est au processus. Iftop liste toutes les connexion en IPv4 et IPv6 que la machine fait et indique l'adresse IPv4 ou IPv6 cible avec laquelle le serveur (ici une machine Yunohost) communique. On n'a pas le type de connexion, juste Ip source / Ip Cible et les consommations en bande passante / quantité de données échangées en temps réel.

Si vous voulez par exemple voir le trafic sous forme d'adresses IP, il suffit d'ajouter l'option -n. On peut afficher les différents ports impliqués dans le trafic grâce à l'options -P.

Il y a d'autres options mais ceux sont les deux que j'utilise principalement.

Dans la liste des connexions, je vois par exemple
- ma connexion SSH
- une connexion vers freeplayer.freebox.fr, ce qui correspond au fait que je monte le répertoire partagé de la freebox v6 (fonction NAS)
- ...

J'ai par exemple pu voir avec la commande iftop un certain nombre de connexion établie dans le sens locale vers des serveurs de cache DNS, en IPv4 et IPv6. C'est toujours marrant de voir que le résolveur de DNS locale travaille...

Conclusion

Netstat, Nethogs et Iftop, trois commandes que j'utilise régulièrement et de façon complémentaire. Si vous avez d'autres outils du même type, les commentaires du billet sont ouverts pour recevoir vos conseils et suggestions.

Coupure de courant et auto-hébergement

Dans ce billet je voudrais raconter une mésaventure qui m'est arrivé le week-end du réveillon entre le 31/12/2016 et le 01/01/2017.

Mon anecdote

En début de soirée le 31 décembre, soirée traditionnelle de réveillon pour beaucoup, coupure de courant dans toute la maison où j'habite (chez moi). Je vérifie les disjoncteurs, tout est ok. Je sors dehors, je vois des voisins qui font de même. La coupure de courant est dans une bonne partie du quartier. Certains reçoivent, d'autres pensent à leurs chauffages qui dépend de l'électricité... Dans le froid de la rue (il fait une température négative dehors et il est seulement 19h), je cherche le numéro d'urgence d'EDF (devenu Enedis). Remarque de mon voisin "y a plus de wifi". Oui je sais, c'est pour ça que je passe par la 3G ;) On finit après un peu d'attente par joindre EDF qui nous informe que le problème a déjà été remonté et qu'une équipe est en cours d'intervention. Il n'y a plus qu'à attendre.

Pendant ce temps, ma compagne télécharge l'application Enedis sur son téléphone Android. L'application nous confirme l'étendue de la coupure, l'intervention en cours et une prévision de retour du courant (vers 23h....)

Dans ma maison, on cherche les bougies, le feu de cheminée qu'on avait lancé permet d'avoir un peu de lumière. Et on essaie tant bien que mal de voir ce qu'on va pouvoir manger, vu que pour cuisiner, nous dépendons de plaques électriques... Le repas de réveillon est reporté au lendemain finalement, on grignote et manque froid... Le courant finit par revenir dans la soirée.

Le lendemain dans l'après-midi, dimanche, j'ai lancé une lessive. Et elle se coupe pendant que la machine tourne... Nouvelle coupure de courant dans le quartier, nouvel appel. Coupure d'une heure et demi.

Le soir, on regarde une série devant la télévision. Nouvelle coupure brusque dans le quartier. Nouvel appel, nouveau tour chez les voisins pour les informer que j'ai eu Enedis et qu'ils interviennent (je fais court). Une heure et demi après c'est revenu.

Bref, 3 coupures, dont on ne sait pas trop pourquoi. Il fait froid dehors, température négative. La personne au téléphone m'informe que la coupure de l'après-midi était planifiée pour une bascule sur un autre disjoncteur de quartier et que si ça a relâché, c'est que quelqu'un dans le quartier consomme de façon anormale...

Trois coupures qui ont causées des soucis plus embêtant qu'autre chose : repas de réveillon reporté, la lessive qui est décalée, la fin de l'épisode qu'on ne voit que le lendemain... Mais surtout des questions qui commencent à se poser : combien de temps le congélateur peut conserver les aliments si ça la coupure doit durée plusieurs heures, est-ce que le courant ne va pas relâcher dès que le courant va revenir car les radiateurs électriques vont se remettre à chauffer à fond... (Nous avons perdu 2 degré dans le salon durant la coupure en soirée, malgré le feu de cheminée).

Ce qu'il faut retenir et comprendre de cette anecdote...

... qui m'a amené à ce titre de billet de blog. Les préoccupations que j'ai eu durant ces trois coupures de courant n'ont pas été sur mon auto-hébergement vers des préoccupations plus terre à terre. Ne pas avoir de chauffage pendant plusieurs heures, vu les températures extérieures, manger froid et ne pas pouvoir cuisiner un jour où on devrait faire la fête est plus important que de ne pas avoir accès à mon cloud personnel.

N'évoquez pas un onduleur : oui le serveur serait allumé mais je n'avais plus de connexion Internet et même si j'étais chez moi, pouvoir me connecter à mon serveur ne m'aurait pas beaucoup avancé, été utile... De même, héberger ce cloud personnel sur un serveur qui tourne H24, vu que je n'avais pas d'accès à Internet (en fait si via mon téléphone, mais est-ce que ce qu'on peut vraiment appeler un accès Internet : réseau filté/natté, non neutre...)

Là où je veux en venir, c'est que mon auto-hébergement ne concerne que mon cloud personnel. Mes mails et mon blog sont (encore et y resteront) sur des serveurs qui eux tournent H24, dans des datacenters, gérér par des professionnels. Blog et mails sont pour moi des services critiques et ils ne sont donc pas chez moi. Dans le cas de mon cloud personnel, sous Yunohost, je peux m'en passer quelques heures voir quelques jours. J'ai tout prévu pour. Mon agenda, mes contacts, mes documents, mes notes et todo-listes, dont la référence est sur le cloud, je les ai aussi sur mon téléphone, sur mon PC fixe (qui lui ne marche que s'il y a du courant). Si je ne peux pas synchroniser en temps réel, je le ferai plus tard. Mon cloud est un confort et non une nécessité absolue. Je l'utilise tous les jours, parce que je peux le faire. Mais je ne suis pas dépendant de ce cloud. J'ai des sauvegardes accessibles me permettant de passer en mode "dégradé" si besoin (si la machine lâche par exemple). Je sais en combien de temps je peux restaurer un cloud personnel... J'avais évoqué la partie matérielle dans mon billet Yunohost - Autohébergement - Le Spare. Il y a l'agrégateur RSS, le Wallabag, le Shaarli, le wiki.... Tant pis si je ne peux pas ajouter des favoris de suite. Je mets dans ça dans un fichier texte et ferai le rattrapage /intégration plus tard. Pour les RSS, je vais consulter les sites les plus importants directement en ligne. Pour le Wiki, j'ai ma sauvegarde (Dokuwiki ça reste des fichiers textes bruts/markdown donc lisibles). J'ai donc des solutions alternatives en cas de coupure sur le long terme de mon cloud personnel.

Et comme l'a montré mon anecdote, mon cloud personnel est un plus, une lubie de geek. Dans la pyramide de Maslow, il n'est pas au plus haut, il y a des choses plus importantes qui passent avant.

Yunohost et Sonerezh

C'est via les différents billets de blog de l'ami Dadda, sur Sonerezh que j'ai découvert Sonerezh il y a quelques mois. Depuis j'utilise ce logiciel au quotidien.

Sonerezh est une application qui permet de lire des fichiers musicaux stockés sur son serveur via son navigateur https://www.sonerezh.bzh/

D'autres logiciels du même type existe, comme Ampache. Je l'avais testé mais je n'avais pas été convaincu. Sonerezh, je l'ai adopté dès que je l'ai essayé.

Sonerezh est disponible en package pour Yunohost. Toutefois, ce n'est pas la dernière version, en attendant que ce soit le cas, on peut toujours installer ce package pour profiter de l'automatisation de l'installation et de la configuration (principe de Yunohost). Dans la page principale des applications Yunohost installée, parmi les tuiles on aura l'ajout d'une tuile de raccourci vers l'application Sonerezh.

Et ensuite, on récupéra l'archive sur github, on la dézipera et copiera les fichiers de la dernière version à la place de la version installée.

wget https://github.com/Sonerezh/sonerezh/archive/1.1.3.zip
unzip 1.1.3.zip
sudo cp -r sonerezh-1.1.3 /var/www/sonerezh/

Comme indiqué sur la page du package, il y a une étape de post-installation à faire la première fois. Cela crée un utilisateur au sein de l'application Sonerezh et cela n'utilise donc pas l'utilisateur de Yunohost (voir à ce sujet Pourquoi Yunohost crée des comptes automatiquement ?. Ce sera donc cet utilisateur et ce mot de passe que l'on utilise (et non ceux de l'instance Yunohost).

Sonerezh propose ce que j'attends d'un lecteur de musique en ligne comme fonctionnalité. C'est simple et intuitif (pour l'import des fichiers : ça lit les tags et remplit la base de données). C'est plutôt rapide, on peut ajouter d'autres répertoires / sources par la suite, à tout moment. Dans mon cas, les fichiers de musique sont stockés sur la partie NAS de ma Freebox. Un simple montage réseau et le dossier est accessible en lecture seule depuis Yunohost. Et c'est ce chemin (vers le montage réseau) que j'ai défini dans la configuration / interface de paramétrage de Sonerezh. Il scanne alors les tags des fichiers pour ensuite proposer de les rechercher / des classements par album, titre, artistes. On peut créer des listes de lecture (je n'ai pas encore utilisé cette fonctionnalité).

En terme de débit, une simple connexion ADSL suffit comme je l'évoquais dans mon billet Autohébergement et ADSL. Je cite Si j'écoute de la musique en streaming dans le navigateur depuis l'extérieur (c'est donc ma machine de cloud qui diffuse la musique), cela consomme un peu moins de 70 ko/s sur une bande passante totale brut de 126,8 ko (1120 kbit/s). Et ce pour des musiques au format mp3 ou ogg en qualité 256 kbit/s.

Quelle plaisir c'est, quand on travaille en openspace, un casque sur les oreilles de pouvoir écouter ses musiques et albums préférés.

Comme vous l'avez compris, je recommande le logiciel Sonerezh. Et bien évidemment, c'est du logiciel libre, vu que c'est sous licence AGPL3. Mais qui en doutait :)

Pourquoi Yunohost crée des comptes automatiquement ?

C'est dans le cadre de mon projet que j'évoque dans mon billet Lifehacking - Wallabag, Liseuse et fainéantise : mon projet. Billet N°1 que je me suis posé la question de pourquoi Yunohost créé des comptes automatiquement pour certaines applications (à l'installation de celle-ci).

Je n'ai pas encore creuser le côté technique (mais ça viendra), voici ce que je sais et ai compris :
- Yunohost dispose d'un SSO ce qui permet d'avoir un seul identifiant/mot de passe (un seul compte) qui permette une fois connecté à Yunohost d'utiliser différentes applications sans avoir à se connecter sur chacune d'elles ;
- Il faut que les applications gèrent l'authentification HTTP et la création automatique de compte (ou les comptes LDAP).

Par conséquence toutes les applications ne peuvent / ne pourront pas être gérées par le même utilisateur et il faut pour certaines, créer un compte dédié (ex : Sonerezh). Pour les autres, comme Wallabag, un utilisateur et un mot de passe sont créés à l'installation de l'application packagée pour Yunohost et un lien est fait entre l'utilisateur Yunohost et l'utilisateur spécifiquement créé pour Wallabag.