J’écrivais récemment pourquoi je souhaitais passer à l’auto-hébergement. Du fait des possibilités qui s’offraient à moi, et surtout parce que je suis fainéant, j’ai décidé de tester Yunohost. Aujourd’hui, je vous présente mes premiers pas avec Yunohost, et vous donne quelques astuces là où j’ai dû creusé.

Yunohost

Sous ce nom qui résonne moitié japonais-anglais, se cache une signification des plus prometteuses : Why you no host. Comprenez ‘Pourquoi vous ne vous hébergeriez pas‘.

C’est une distribution légère basée sur Debian qui contient l’essentiel pour monter votre propre serveur. Ici pas d’environnement de bureau ou de logiciels bureautique : Le serveur et le réseau.

La version actuelle permet d’installer presque sans configuration un serveur mail, web, messagerie instantanée, monter un blog, wiki, cloud personnel, … Tout ça, sans terminal. Pour ceux qui veulent se la péter, c’est quand même possible

Pour ma part, j’ai choisi de partir avec cette solution plutôt que de tout me taper à la main car je déteste les emmerdes gratuites. Pour avoir monté un serveur lamp à la main il y a quelques années, je peux vous garantir que c’est le jour et la nuit.
Avec Yunohost, même les réfractaires de la ligne de commande peuvent créer leur propre serveur.

Pour bien démarrer

Je vous passe les détails du téléchargement et de l’installation, ça se fait vraiment comme une Debian (donc bien).

A noter : Ça peut paraître inutile mais l’installation de la distro fonctionne avec l’ethernet et le wifi. J’ai tenté avec le wifi, ça marche. En revanche, une fois Yunohost en marche ça ne fonctionne plus, et il ne prend plus l’ethernet. Il faut donc exclusivement installer Debian en ethernet.

Post Install

Une fois la bécane démarrée,  on vous demande de vous loguer. Les identifiants sont root pour le login, et yunohost pour le pass. Ça, c’est donné dans la doc, plutôt bien foutue d’ailleurs.
En revanche, une fois loggué, ça n’y ressemble plus. Chez moi pas d’affichage de l’IP, pas de post install, rien :

Du coup, il faut lancer la post install à la main. Tapez la commande suivante :

yunohost tools postinstall

Et là, l’installation se lance :

Domaine principal : Nom de domaine qui sera utilisé pour accéder à votre serveur. Si vous n’en avez pas, Yunohost permet d’obtenir gratuitement en sous domaine en nohost.me ou noho.st. Mettez donc simplement ‘monsite.no-host.me’ par exemple.

Notez que j’ai mis yunohost.local, car j’ai installé Yunohost sur une machine virtuelle et que celle-ci n’a pas pour finalité d’être accessible par le web.

Mot de passe d’administration : Mot de passe qui vous sera demandé lorsque vous tenterez de vous connecter au serveur par accès distant.
Ce mot de passe ne remplace pas celui par défaut que vous avez entré plus haut, à savoir yunohost.

IP

Comme dit plus haut, la version actuelle n’affiche plus l’IP de la bécane, et c’est un peu emmerdant pour configurer le bordel.
Il faut donc utiliser la commande de la Debian pour la récupérer :

ip -4 addr

Accès au serveur

Une fois le tout configuré, vous avez alors 2 moyens d’accéder au serveur depuis un autre poste, en local : Par l’IP, ou le domaine choisi.

Je vous laisse y aller avec un navigateur.
Si vous n’avez pas de certificat SSL pour le domaine, vous devriez avoir un beau message vous prévenant que la connexion au serveur n’est pas sécurisée :

N’ayez pas peur, c’est votre serveur. Selon le navigateur, confirmez l’exception de sécurité pour accéder au site :

Et vous voilà normalement sur la page d’administration de votre serveur Yunohost, vous demandant le mot de passe d’administration configuré tout à l’heure :

À partir de là, je vous laisse explorer les différents menus de l’administration de votre serveur Yunohost.

Configuration de la box

Je suis un particulier. Aussi j’ai comme beaucoup de monde une Box internet. Plus que de simplement vous fournir un accès internet, elle est aussi un gardien des mauvaises intentions que pourraient subir votre réseau personnel (local). Elle bloque en fait toutes les connexions entrantes non autorisées, afin que personne ne puisse s’introduire chez vous. Notez que c’est de la théorie hein

Le problème avec ça, c’est que si vous montez un serveur destiné à être consultable depuis l’extérieur, et bien votre box ne fera pas la distinction entre une requête en bonne et due forme, destinée à consulter votre site, et une tentative d’intrusion. Elle bloquera tout.

Il va donc falloir configurer votre box pour laisser passer certaines connexions entrantes, et les rediriger vers le serveur, qui répondra à la requête du client.

Dans ce qui va suivre, je vais vous détailler comment j’ai configuré ma Freebox. Pour les autres FAI, l’interface changera forcément, mais le gros de la manipulation reste la même.

Accès distant

J’ignore pour les autres box, mais si j’essaye d’accéder à mon adresse IP, je tombe sur l’interface permettant de configurer ma Free. Ça, c’est la première emmerde pour quelqu’un qui veut s’auto-héberger.

Donc sur la Freebox Révolution, il suffit de se rendre dans ‘Connexion Internet’ / ‘Configuration’ de l’administration.
Se trouve alors un cadre ‘Accès à Freebox OS’ :

Ce qui nous intéresse est le port accès distant et accès distant sécurisé.
Par défaut, le port est 80, ce qui veut dire que toute requête HTTP du navigateur sur votre IP ou domaine provoquera l’affichage de la page Freebox OS.
Le port accès distant sécurisé est le port à utiliser pour vous connecter en HTTPS à votre Free depuis l’extérieur.

Il va donc falloir changer ces 2 ports pour que vos visiteurs ne tombent pas sur votre Freebox en voulant visiter votre site.
Je vous conseille de consulter la liste des ports connus, et d’en sélectionner 2 qui ne sont pas utilisés. Pour ma part, j’en ai choppé dans les 30 000, que je préfère garder secret, bien que ma box protège des attaques brute-force.

Pour vous connecter ensuite depuis l’extérieur, il faudra se rendre à l’adresse :

• http://mon-ip:80 ou
• https://mon-ip:41254

Depuis le réseau local, l’adresse directe de la box fonctionnera toujours : http://192.168.0.254

Routage

Nous voilà dans la partie intéressante : Le routage de votre box.
Jusqu’à présent, nous n’avons vu que des banalités. Mais si vous êtes là, je sais que c’est pour de la technique, le reste n’est que du flan

Le routage est le fait d’utiliser votre box pour transmettre les requêtes qu’elle va recevoir, à votre serveur fraîchement installé.

Pour cela il faut comprendre au moins une chose.

Ports et applications

Je n’expliquerai pas ici le modèle TCP/IP, sinon on va partir trop loin et le post va encore s’allonger. Sinon, un peu de lecture chez sebsauvage concernant le TCP, très bien fait.
Mais ce qu’il faut savoir, c’est que chaque type d’ application du modèle TCP/IP (HTTP, FTP, Telnet, …) utilise son propre port pour échanger. Les ports sont comme des portes (ouais j’ai pas été le chercher loin celui-là ) qu’il faut ouvrir dans votre box et rediriger vers votre serveur.

Sans importance : Les ports de 0 à 1023 sont généralement utilisés par Internet et assignés par l’IANA, les autres (jusqu’à 65535) sont destinés plus globalement à une utilisation en réseau local.

Nous disions donc que chaque application utilisait son propre port. Par exemple la plus connue, le protocole Hypertext Transfer Protocol (HTTP), utilise le port 80. Sa version sécurisée, HTTPS, utilise quand à elle le port 443.
Pour chaque besoin, chaque fonctionnalité que proposera votre serveur, il faudra donc gérer le routage de ces ports vers la machine. Le cas échéant, votre box stoppera ces requêtes qu’elle jugera comme nocive.

Configuration

Alors, chez Free, la gestion des ports se fait dans ‘Connexion Internet’ / ‘Gestion des ports’.

Sur la fenêtre, il va falloir, pour chaque port, ajouter une redirection vers le serveur :

• IP Destination : Adresse IP du serveur
• IP source : Toutes pour rediriger toutes les machines vers le serveur
• Protocole : TCP (ou UDP si réel besoin, mais les protocoles internet sont globalement basés sur TCP)
• Port de début et Port de fin : Si vous souhaitez utiliser une plage de ports à rediriger. A déconseiller car les redirections ne seront faits que sur un seul port (en tous cas sur Free), et les applications sur le serveur pourraient ignorer ces requêtes.
• Port de destination : Le même que le port de début.

Pour ma part, voilà les redirections que j’ai mises en place :

Certaines sont inutiles dans le cas précis de Yunohost, comme les ports dédiés au FTP (20 et 21), car Yunohost n’autorise le transfert de fichiers que par le protocole SSH (port 22).

Cas de la DMZ

Certaines box, comme vous pouvez le voir sur la précédente image, propose d’utiliser une DMZ. Une DMZ (DeMilitarised Zone), ou zone démilitarisée, permet de créer un sous-réseau accessible depuis le web dans un réseau local. Dans votre box, elle ne fait ni plus ni moins que rediriger toutes les requêtes entrantes vers une IP déterminée.
Si cela peut sembler la solution facile, il faut alors y réfléchir 2 minutes. Avec cette solution, c’est la porte grande ouverte, votre box ne s’occupe de plus rien du tout. Fini le videur, toutes les requêtes vers les ports sont redirigés vers votre serveur.
Sans aucun doute, il faudra encore plus sécuriser la machine (parefeu …), ce qui n’est pas une tâche facile pour tout le monde.

Personnellement, je suis d’avis à ne pas utiliser cette facilité, mais plutôt ouvrir les ports uniquement dont on a besoin. On ferme la porte au maximum

IP, DNS et CRON

Lorsque j’ai mis en place mon serveur de messagerie (mail avec RoundCube), j’ai commencé à recevoir des tas de mails, avec pour titre :

« Cron yunohost dyndns update >> /dev/null »
Dans le corps, plusieurs messages possibles :

« Impossible de mettre à jour l’adresse IP sur le domaine DynDNS »
« Une instance est déjà en cours d’exécution »

Pourquoi ce CRON ?

Lorsque vous choisissez d’utiliser un nom de domaine chez Yunohost (nohost.me ou noho.st), celui-ci créé une tâche CRON, une tâche planifiée, qui va s’exécuter toutes les 2 minutes afin de mettre à jour les DNS. Les DNS (Domain Name System) permettent de retrouver un domaine grâce à son IP dans la multitude des terminaux reliés à Internet.
Si vous avez une IP fixe, pas de problème, à l’enregistrement du nom de domaine, l’adresse IP de votre serveur est fournie, et celle-ci n’en changera pas.
En revanche, si vous avez une IP dynamique, il faut régulièrement mettre à jour le DNS avec votre nouvelle IP pour rediriger correctement vers votre serveur lorsque quelqu’un cherche à accéder à votre nom de domaine. Et bien ça, c’est le job de ce CRON.

Donc si vous recevez comme moi des mails avec pour titre : « Cron yunohost dyndns update >> /dev/null », cela signifie qu’il y a une coquille dans l’exécution de cette tâche.

Cas d’une IP fixe

Si vous avez une IP fixe, ce CRON s’exécutera quand même. Il se peut même que vous ne receviez jamais de mails.
Dans tous les cas, il s’avère que laisser cette tâche n’est pas conseillée, car comme toute exécution, elle consomme de la ressource sur votre serveur.
La solution la plus simple est donc de supprimer tout bonnement cette tâche.

Directement sur votre serveur, une fois loggué, tapez la commande ci-dessous :

rm /etc/cron.d/yunohost-dyndns

Et vous ne serez plus embêté.

Cas d’une IP dynamique

En revanche, si votre IP change régulièrement, supprimer la tâche CRON n’est pas une bonne solution : Votre serveur ne serait plus accessible.
En revanche, comme on peut considérer que votre IP ne change pas toutes les 2 minutes, on peut simplement modifier la tâche planifiée, et la lancer toutes les 5 ou 30 minutes.

Pourquoi ? Comme dit plus haut, cette tâche consomme de la ressource, et il est inutile qu’elle ne se lance aussi souvent. De plus, sur certains systèmes lents, comme un Raspberry première génération, la tâche n’a pas forcément fini de mettre à jour le DNS qu’on lui demande déjà de remettre à jour le serveur. D’où les mails que vous recevez.
Pour cela, nous allons simplement modifier le temps de la tâche qui, au lieu de s’exécuter toutes les 2 minutes, s’exécutera moins souvent.

Sur votre serveur, tapez la commande suivante, afin d’éditer le fichier du CRON :

nano /etc/cron.d/yunohost-dyndns

Puis modifiez la ligne qui nous intéresse :

*/2 * * * * root yunohost dyndns update >> /dev/null

En remplaçant le 2 par le nombre de minutes qui doivent espacer chaque lancement de la tâche :

*/5 * * * * root yunohost dyndns update >> /dev/null

Vous pouvez essayer 5 minutes dans un premier temps, et augmenter si cela ne suffit pas. Si vous arrivez à 30 minutes et que le problème ne se résorbe pas, c’est qu’il y a une autre anguille

L’article Premiers pas avec Yunohost est apparu en premier sur Max-Koder.

Original post of Max Koder.Votez pour ce billet sur Planet Libre.