Un Raspberry pi headless, wireless, ip fixe, sans se prendre la tête

Cet article a été publié il y a 5 ans 1 mois 12 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

J’ai hésité à l’appeler « la fibre chez ma mère, épisode 5 », puisque c’est la raison première qui me pousse à faire cette installation. Mais après tout, ça pourra servir dans pas mal de situations, donc autant garder le titre générique, j’ai beau me foutre habituellement du référencement il s’avère tout de même qu’une grande partie de mon public vient des moteurs de recherche, sans surprise Google en tête. Et si j’ai décidé de réecrire sur ce sujet, c’est que j’ai rarement voire jamais trouvé dans un seul billet tous les éléments dont j’avais besoin. Du coup c’est parti pour un tour du proprio de la framboise.

J’ai donc décidé de monter un bastion chez ma maman pour pouvoir accéder à distance au réseau. Dans l’immédiat seul le SSH est prévu, au pire si j’ai besoin j’ouvre en mode tunnel et je passe dedans en mode proxy, bref les bricoles habituelles. Une simple redirection de port est donc au programme pour l’instant, et si l’interface client de NordNet est limitée, elle est aussi très peu claire, car par défaut, seul les services standards sont proposés dans une liste déroulante pour être redirigés. Et en mode avancé, le formulaire est cryptique, mais je m’en suis sorti. Je vous laisse lire la documentation sur le site de NordNet pour vous en convaincre.

Reste ensuite à installer ce Raspberry Pi. Je veux le connecter en Wi-Fi, avec une IP fixe, avec le service SSH, tout ça sans avoir à brancher un clavier ou un écran dessus, juste l’alimentation 3A très compacte que j’ai pu acheter sur Amazon pour éviter un nouveau cauchemar de blocs d’alims monstrueux. Ah oui et mettre en place un DNS dynamique, car si pour l’instant l’adresse IP n’a pas bougé j’ai eu la confirmation par le service client qu’elle était susceptible de changer. Et si tout ça n’est pas compliqué à faire, j’ai du chercher les infos à plusieurs endroits. J’ai aussi voulu capitaliser sur mon boulot réalisé avec Ansible sur le déploiement des VMs de mon serveur Pimousse. Voilà donc le programme.

Première étape : installation, SSH, Wi-Fi, IP Fixe, personnalisation

Pour la partie installation, grosso modo vous pouvez suivre le guide de NextINPact. Vous aurez les deux premières parties, à savoir le SSH et le Wi-Fi, mais à cette étape, l’adresse IP du Raspberry Pi est attribuée via DHCP. Soit vous pouvez coller un bail statique sur votre box, sois vous souhaitez avoir plus de contrôle comme moi, donc une étape de plus avant d’insérer la carte dans la bestiole. Sur Raspbian, le réseau est géré par dhcpcd, c’est donc dans le fichier /etc/dhcpcd.conf qu’il faut ajouter quelques lignes à la fin du fichier :

C’est tout bête. J’en profite aussi, comme je n’ai pas trop le contrôle des DNS sur la connexion pour l’instant, pour lui dire d’en utiliser un propre (merci FDN 🙂 ) le temps que j’en installe un plus sous contrôle. Dès lors on peut démonter le tout, insérer la carte dans le Raspberry Pi, et le brancher, la diode rouge puis la verte devraient s’allumer, la verte clignotant pour indiquer une activité. Laisser plusieurs secondes, surveillez avec un ping par exemple, et quand ça répond, vous pouvez lancer la connexion ssh sur le compte par défaut. Nice.

Après avoir modifié le nom du raspberry pi, et redimensionné la partition, j’attaque l’installation de mon environnement. En effet, les premières étapes de l’installation de Raspbian se font avec un compte par défaut, pi, qui a tous les droits sur la machine et dont le mot de passe par défaut est connu. Il est donc recommandé à minima de le changer (via l’utilitaire raspi-config), voire carrément de supprimer le compte. Et j’ai voulu vérifier à quel point mon playbook dédié au déploiement de l’environnement de mes VMs du serveur Pimousse était fiable. Le playbook en question s’occupe de tout mettre à jour, d’installer et de supprimer quelques outils, de vamper le compte root et de créer/vamper mon compte; enfin, la configuration SSH est un peu renforcée, pas de connexion root ni de mot de passe.

Et ça a tout fonctionné du premier coup, juste petite adaptation, dans mon fichier host_vars j’ai un « ansible_user » adapté à mon template de déploiement de VM, là ce n’était pas le cas, pour pas être emmerdé et juste avant de supprimer le compte, j’ai collé une de mes clés publiques sur le compte pi pour faciliter le boulot d’ansible, et lancé le playbook avec une petite modification :

Tout s’est déroulé comme prévu, j’ai testé la connexion à mon compte, vérifié la configuation SSH et sudo, dès lors j’ai pu supprimer le compte par défaut, c’est toujours plus simple quand on ne laisse pas les comptes par défaut.

Deuxième étape : OVH, DNS dynamique, tâche cron

Pour la connexion et l’exposition des futurs services, et dans l’optique de mon départ, j’avais déjà enregistré chez OVH un domaine en .ovh pour ma maman, ça coûte une misère et le DNS chez eux est un service qui n’a pas trop à rougir en termes de fonctionnalités. L’une de celles qui m’intéresse en l’occurrence est le dyn-host, autrement dit le DNS dynamique. Vous définissez un utilisateur, ensuite vous déclarez un sous-domaine comme dynamique (attention, il ne doit pas exister au préalable), et la mise à jour se fait via un simple appel HTTP, en mode API donc.

Pour ça, et même si j’ai un poil tâtonné sur la validation du fonctionnement de toute la procédure, j’ai suivi la documentation officielle. Alors eux disent qu’ils ne proposent pas d’outils dédiés, juste la possibilité de piloter en mode API, là comme la fin de weekend approchait je suis allé au plus simple avec un curl. Petit glitch que je compte leur remonter, la documentation mentionne encore l’appel en HTTP, ce qui est affreux, il n’y a pas de redirection vers HTTPS, mais comme celui-ci est fonctionnel c’est le protocole que j’ai conservé dans mon script. Je reprendrai un peu de temps pour le refaire en python soit pur soit via flask (mais ça n’a pas non plus un intérêt de dingue), dans tous les cas, la commande ressemble à ça :

Pour obtenir current_ip, plusieurs possibilités, moi je passe par ifconfig.co, qui a l’élégance d’adapter la réponse au type de client (via le user-agent), donc pas besoin de filtrer la réponse.

Mélangez le tout dans une tâche cron qui se lance toutes les cinq minutes, et laissez cuire gentiment jusqu’à ce qu’on ait des réseaux propres quelque soit l’opérateur (ce qui n’est pas près d’arriver).

Prochaines étapes : j’en sais encore trop rien

Il y aura certainement d’autres choses par la suite, juste avant de partir, j’ai installé docker en mode Swarm, parce que je peux le faire, mais je ne sais pas encore ce que je vais en faire. L’accès au bastion fonctionne parfaitement, ça me fait un point de test indépendant de plus, ça permet aussi d’accéder à certains paramètres de l’interface client qui ne sont accessibles que si on est sur la connexion de l’abonnement.

Je vais certainement utiliser le Pi pour déployer un autre DHCP que celui fourni par la box, seule solution pour pouvoir avoir la main sur les serveurs DNS. En parlant du DNS, il y a des chances qu’un cache soit installé, j’ai déjà évoqué la possibilité de tester pi-hole, je vais très probablement aussi installer un reverse-proxy, je sais pas encore qui sera l’heureux élu, je n’ai pas encore utilisé traefik qui peut vous gérer Let’s Encrypt tout seul, ce qui serait un gros plus par rapport à la solution actuelle chez moi où j’utilise nginx et acme.sh en mode semi-manuel (j’ai scripté la génération du certificat après le vhost créé).

Ça j’ai envie de dire, chacun verra midi à sa porte si l’envie de disposer d’un tel outil vous prend, sur ce, je retourne pleurer sur mon ADSL qui est pourtant déjà bien confortable, mais tellement frustrant quand on passe un weekend dans le 21° siècle #semitroll