Rechercher dans la communauté

1. Qu'est-ce qu'un proxy inversé ? Un proxy inversé (reverse proxy) est un type de serveur, habituellement placé en frontal de serveurs web. Contrairement au serveur proxy qui permet à un utilisateur d'accéder à un environnement depuis un point unique, le proxy inversé permet à un utilisateur d'accéder depuis un environnement à des serveurs internes via un point d'entrée unique. Un proxy inversé écoute sur un port donné, sécurisé ou pas, toutes les requêtes à destination de ces services. Au lieu donc d'avoir de multiples portes (les ports des applications auxquelles ont souhaite accéder depuis l'extérieur), on en a une seule qui s'occupera de rediriger les requêtes vers le bon service. 2. Prérequis - Comprendre le fonctionnement de Docker (voir tutoriel introductif) - Savoir se connecter en SSH à son hôte - Savoir rediriger un port depuis sa box - Être un peu curieux Difficulté : Moyenne 3. Pourquoi ? Des solutions de proxy inversé, il en existe des tas, toutes ont leurs avantages et inconvénients. DSM utilise Nginx, mais il existe aussi entre autres HAProxy, Apache, Squid, etc... Dans notre cas ce sera également Nginx, mais via l'image Docker linuxserver/swag, car elle embarque tout un ensemble de fonctionnalités supplémentaires qui agissent en synergie. Cette solution comprend notamment : Certbot : utilitaire permettant l'obtention et le renouvellement automatique de certificats Let's Encrypt. Fail2ban : Script permettant le bannissement d'IP ayant réalisé un nombre donné de tentatives de log infructueuses. Authelia (fichiers de configuration seulement) : Logiciel d'authentification deux facteurs hautement personnalisable et applicable à n'importe quelle application. Nginx : Serveur web qu'on utilise ici pour faire office de proxy inversé. L'intérêt majeur est de pouvoir appliquer des fonctionnalités existantes dans DSM mais réservées à celui-ci, à n'importe quelle application. Et de disposer d'un serveur Nginx entièrement paramétrable a contrario de celui intégré à DSM. ATTENTION : Cette image ne permet pas de déployer automatiquement le certificat obtenu dans DSM à la manière dont le fait acme.sh (voir tutoriel de @Einsteinium pour une utilisation via Docker ou le tutoriel de @oracle7 pour les NAS incompatibles). Vous devrez l'installer manuellement dans DSM si vous souhaitez l'utiliser et le faire tous les 3 mois. Pour ma part je ne m'embête pas, j'utilise l'interface DSM pour obtenir un certificat wildcard avec le nom de domaine Synology qui se renouvelle tout seul tous les 2 mois. Ainsi, j'utilise le nom de domaine Synology pour les services comme Hyper Backup, Drive, etc... tout ce qui est intrinsèquement lié à DSM et qui n'est pas gérable au travers d'un proxy inversé. Tout le reste passe par le certificat OVH que ce conteneur va générer. 4. Hypothèses Pour mieux illustrer le propos, je conviendrai d'un certain nombre d'adresses qui faciliteront l'identification des consignes à l'application du tutoriel : Adressage réseau "physique" : 192.168.1.0/255.255.255.0 (/24 en notation CIDR) Le serveur DHCP ne couvre qu'une partie de la plage 192.168.1.0/24, par exemple 192.168.1.1 à 192.168.1.99 Passerelle (routeur ou modem) : 192.168.1.254 IP (physique, pour utilisation avec réseau macvlan) du conteneur swag : 192.168.1.145 (voir plus loin). IP de l'hôte (le NAS ici, mais ça pourrait être une autre périphérique) : 192.168.1.100 (Je pars du principe que votre hôte a une IP définie en dehors de la plage d'attribution du serveur DHCP, ce n'est pas obligatoire (mais conseillé)). IP virtuelle de l'hôte (voir plus loin) : 192.168.1.200 eth0 est le nom de mon interface physique. 5. Principe L'idée générale de ce que l'on s'apprête à mettre en place peut être résumée de la sorte : Le port 443/tcp (par défaut) est le port d'écoute du proxy inversé. Le port 80 est le port utilisé par Let's Encrypt pour renouveler les certificats si on choisit la méthode de validation HTTP-01 et/ou pour faire une redirection HTTP -> HTTPS. Deux cas de figure se présentent, soit les ports sont libres sur l'hôte, soit ils ne le sont pas : S'ils sont libres, ce qui est le cas si vous décidez d'utiliser SWAG sur une autre machine que le NAS (un Raspberry Pi fait tout à fait le job), alors on peut créer notre conteneur sur un réseau bridge. Dans ce cas-là, la lecture du tutoriel introductif devrait suffire pour la mise en place de swag. S'ils ne le sont pas, ce qui est très probablement le cas sur votre NAS (Webstation installé, Nginx en sous-main) on le rattachera à un réseau macvlan. Un réseau macvlan permet de donner une adresse IP au conteneur sur le réseau physique, par exemple ici 192.168.1.150 Il s'émancipe d'une certaine manière de l'hôte et se comporte globalement comme un périphérique à part entière relié à votre routeur. Il pourra donc utiliser tous les ports dont il a besoin. Au prix d'une impossibilité de communication avec l'IP de l'hôte (limitation intrinsèque au pilote macvlan). Mais il existe une manière de contourner le problème de communication via une interface virtuelle du NAS, vous trouverez plus de détail dans le tutoriel introductif. C'est la méthode que j'ai décidé de privilégier ici, car plus difficile d'accès que via le réseau bridge, et qu'elle permet de ne pas toucher à la configuration du NAS. Je reprendrai principalement ce qu'on peut trouver dans mon tutoriel sur Docker, en l'appliquant à notre cas d'utilisation. En parallèle; n'hésitez pas à parcourir ce magnifique guide, dont ce tutoriel est un bon complément, sur la mise en route de ce conteneur. Vous y trouverez notamment beaucoup plus d'informations sur la partie hébergement de sites, la configuration d'Nginx ; des thèmes que je n'aborderai pas dans le présent tutoriel. 6. Création du réseau macvlan Note : Si vous avez déjà créé un réseau macvlan, rendez-vous au paragraphe 7. Si en plus vous avez déjà créé une interface virtuelle pour la communication NAS <-> conteneur(s) en macvlan, rendez-vous au paragraphe 8. Pour créer le réseau macvlan, il faut définir une portion libre de l'adressage du réseau physique de notre LAN dans laquelle nous pourrons adresser notre (et éventuellement nos futurs) conteneurs. Cet outil est très pratique pour calculer des plages IP, je vois par exemple que si je choisis 192.168.1.144/28, je dispose d'un pool d'IP allant de 192.168.1.145 à 158, ce qui est je pense amplement suffisant, on peut passer le masque à /29 à la place de /28 pour réduire cette plage à 150 au lieu de 158. On peut également décider que ce sera notre seul conteneur en macvlan, pour réduire l'espace à une seule IP il suffit d'utiliser le masque /32. Ici pour couvrir le cas d'utilisation le plus général, on choisira le masque /29. Afin de garder une trace de la configuration du réseau, je vous conseille de créer un fichier macvlan_net.sh. On se rend dans le dossier de notre choix, par exemple chez moi j'ai un dossier networks dans mon dossier partagé docker : cd /volume1/docker/networks touch macvlan_net.sh nano macvlan_net.sh La commande nano est disponible sur vos NAS via les excellents paquets SynoCLI de Synocommunity, en l'occurence SynoCLI Files ici. On entre le script suivant : docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --ip-range=192.168.1.144/29 \ --gateway=192.168.1.254 \ -o parent=eth0 \ macvlan_net On le rend exécutable et l'exécute : chmod u+x macvlan_net.sh ./macvlan_net.sh Une série de caractères s'affiche si tout s'est correctement déroulé. Notes : Pensez à utiliser sudo devant les commandes docker (valable pour toute la suite du tutoriel) si vous n'êtes pas connecté avec l'utilisateur root. ip-range correspond à la plage qu'on a choisie ci-avant. Sur le NAS, si on a activé open vswitch (automatique si par exemple on utilise Virtual Machine Manager), l'interface parente n'est plus eth0 (ou eth1, eth2, ..., ethX) mais ovs_eth0 (respectivement ovs_eth1, etc...). Pour connaître le nom de l'interface physique de sa machine (il varie suivant les machines), en SSH on peut taper : ifconfig | grep -C 3 192.168.1.100 ou ip addr | grep -C 3 192.168.1.100 Il suffit alors de repérer l'interface ayant pour adresse IP l'adresse physique du NAS (ici 192.168.1.100). On peut maintenant vérifier que le réseau existe bien en tapant : docker network ls 7. Création de l'interface virtuelle 7-A. Création du script Comme dit en introduction, il y a un inconvénient majeur à utiliser le réseau macvlan car il n'est plus possible de communiquer entre l'IP de l'hôte, 192.168.1.100 et le conteneur swag dont l'IP sera sur le réseau macvlan. Pour pallier ce défaut, on va créer une interface virtuelle, un autre chemin par lequel le NAS pourra communiquer avec le(s) conteneur(s) sur le réseau macvlan. Cette interface disparaîtra à chaque redémarrage du NAS, on créera donc une tâche planifiée pour la monter automatiquement. __________________ ATTENTION (merci @EVOTk) : L'interface disparaît également lorsque vous : arrêtez désinstallez mettez à jour le paquet Docker. Il faudra donc exécuter ce script manuellement depuis l'interface DSM si cela se produit. __________________ Toute cette procédure est explicitée dans le tutoriel introductif, mais on la reprendra pas à pas ici en personnalisant les commandes à notre besoin. On peut se placer dans un dossier interfaces dans le dossier partagé docker : cd /volume1/docker/interfaces touch mac0.sh nano mac0.sh Puis de manière similaire à ce qu'on a fait pour le script du réseau macvlan, on crée un script pour la création de l'interface : #!/bin/sh # Script permettant la communication entre # un conteneur appartenant a un reseau macvlan et son hote # A lancer au demarrage de l'hote # Temporisation #sleep 60 # Creation de l interface macvlan sur l hote ip link add mac0 link eth0 type macvlan mode bridge # Configuration de l interface avec l adresse reservee ip addr add 192.168.1.200/32 dev mac0 ip link set dev mac0 address AA:BB:CC:DD:11:45 ip link set mac0 up # On fait une route entre les IPv4 du reseau mac0 et l'interface ip route add 192.168.1.144/29 dev mac0 Notes : L'adresse 192.168.1.200/32 correspond à l'IP virtuelle du NAS, le NAS sera accessible et visible également avec cette nouvelle adresse comme avec son IP réelle 192.168.1.100. Mais a contrario de cette dernière, le conteneur peut tout à fait communiquer avec. Vous noterez la présence d'une temporisation commentée de 60 secondes. Si vous rencontrez des problèmes de création de l'interface au démarrage du NAS, n'hésitez pas à décommentez, le script sera décalé d'une minute (ce qui peut permettre d'initialiser la connexion réseau, etc...). On rend le script exécutable et on l'exécute : chmod u+x mac0.sh ./mac0.sh On vérifie maintenant que l'interface est bien active : ifconfig | grep -A 5 mac0 7-A. Création de la tâche On va maintenant créer une tâche planifiée dans DSM pour exécuter ce script à chaque redémarrage du NAS. Direction Panneau de configuration -> Tâches planifiées -> Créer -> Tâche déclenchée -> Script défini par l'utilisateur On est maintenant prêt à passer à la création du conteneur. 8. Création du conteneur 8-A. Fichier docker-compose Il ne reste plus qu'à créer le conteneur, on passera par un fichier docker-compose. La documentation très complète de Linuxserver est disponible à l'adresse : https://github.com/linuxserver/docker-swag Hypothèses : Utilisation d'un nom de domaine OVH Délivrance du certificat par DNS-01 La méthode DNS-01 implique que votre certificat sera validé au niveau de votre hébergeur de zone DNS (OVH par défaut) et non votre NAS comme avec la méthode HTTP-01. DNS-01 est obligatoire en cas de demande d'un certificat wildcard. Si vous souhaitez utiliser la méthode HTTP-01, il faudra prévoir une redirection (NAT) du port 80 de votre box vers l'IP du conteneur. Plus d'information à cette adresse : https://github.com/linuxserver/docker-swag Dans le cadre de nos hypothèses, voici l'architecture du fichier docker-compose : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=ovh - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config restart: unless-stopped networks: macvlan_net: external: true Notes : Vous remarquerez que je ne translate aucun port entre le NAS et le conteneur, pourquoi ? N'oubliez pas que ce conteneur sera une machine à part entière sur le réseau physique, dès lors elle n'a pas "d'hôte" à proprement parler. J'aurai simplement mon routeur ou mon modem qui redirigera son port public 443 vers le port 443 de l'adresse IP physique du conteneur (192.168.1.145), comme il le ferait vers n'importe quelle autre machine En amont, une translation de ports depuis le modem/routeur doit être faite pour les ports : TCP 443 pour que le proxy inversé reçoive les requêtes. TCP 80 si vous validez par HTTP-01 OU si vous souhaitez avoir une redirection HTTP -> HTTPS pour vos entrées de proxy inversé (si vous tapez exemple.ndd.tld dans votre navigateur, vous serez rediriger vers https://exemple.ndd.tld). Le PUID proposé correspond à mon utilisateur admin personnalisé, et le PGID de 100 correspond au groupe users par défaut. Vous pouvez définir un utilisateur et un groupe spécifiques qui ne possèderont des droits que sur les dossiers du conteneur. Le paramètre cap_add est utile seulement si vous souhaitez utiliser fail2ban (conseillé), car le conteneur devra modifier ses iptables (pas celles de l'hôte). Notes (2) : Si vous avez utilisé la méthode réseau bridge, il faut penser dans ce cas à faire une redirection des ports sur l'hôte, ça se traduit par l'ajout du bloc "ports" suivant (par exemple entre les blocs "environment" et "volumes") : ports: - 443:443/tcp # Ecoute proxy inverse - 80:80/tcp # Redirection HTTP vers HTTPS 8-B. API OVH Je ne m'attarderai pas sur cette partie, tout est parfaitement décrit dans le tutoriel de @oracle7 sur la génération d'un certificat wildcard par acme.sh J'ajouterai simplement une nuance sur les accès API à donner, ceux-ci me semblent plus restrictifs et préférables : GET /domain/zone/ GET: /domain/zone/ndd.ovh/ GET /domain/zone/ndd.ovh/status GET /domain/zone/ndd.ovh/record GET /domain/zone/ndd.ovh/record/* POST /domain/zone/ndd.ovh/record POST /domain/zone/ndd.ovh/refresh DELETE /domain/zone/ndd.ovh/record/* Également, on peut limiter l'utilisation de l'API à une ou des IP prédéfinies, particulièrement pratique si on dispose d'une IP fixe. En bout de chaîne vous obtiendrez 3 clés permettant un accès à l'API OVH : l'application key, l'application secret et la consumer key. 8-C. Création du fichier ovh.ini Avant la création du conteneur, on va créer en amont le fichier ovh.ini et le préremplir avec vos accès OVH obtenus ci-avant. Ainsi lorsqu'on créera le conteneur, on évitera le message d'erreur comme quoi le conteneur ne dispose pas des accès à l'API. En SSH, connecté avec de préférence l'utilisateur dont on reprendra le PUID/PGID dans les variables d'environnement du fichier docker-compose.yml, on se place dans le dossier destiné à accueillir la configuration du conteneur : cd /volume1/docker/swag Ensuite : mkdir -p config/dns-conf/ cd config/dns-conf/ curl -s https://raw.githubusercontent.com/linuxserver/docker-swag/master/root/defaults/dns-conf/ovh.ini -o ./ovh.ini On édite ensuite le fichier, avec son éditeur préféré (vim, nano, WinSCP, File Station, etc...) et on remplit les champs avec les accès API d'OVH obtenus précédemment : # Instructions: https://github.com/certbot/certbot/blob/master/certbot-dns-ovh/certbot_dns_ovh/__init__.py#L20 # Replace with your values dns_ovh_endpoint = ovh-eu dns_ovh_application_key = VALEUR_APPLICATION_KEY dns_ovh_application_secret = VALEUR_APPLICATION_SECRET dns_ovh_consumer_key = VALEUR_CONSUMER_KEY Pour éviter un message lié aux permissions laxistes du fichier, on va le chmoder : chmod 600 ovh.ini Si en revanche vous obtenez plus tard un erreur due à un des permissions insuffisantes, exécutez de nouveau la commande en remplaçant 600 par 640. 8-D. Création du conteneur Une fois le fichier ovh.ini correctement complété, on peut créer le conteneur, on se place dans le dossier où se trouve le fichier docker-compose et on écrit : docker-compose up -d On peut suivre l'évolution de l'initialisation du conteneur via : docker-compose logs --follow (CTRL+C pour arrêter le défilement des logs en direct). Ou alors via le paquet Docker de DSM ou encore Portainer (voir tutoriel). Normalement à ce stade vous disposez d'un certificat fonctionnel dans /volume1/docker/swag/config/keys/letsencrypt. Il sera tout à fait possible des copier les fichiers ou de créer des liens symboliques pour d'autres applications vers ces fichiers. Autre possibilité, monter ce dossier en tant que volume pour un service qui nécessiterait ses propres certificats, bref ils sont à vous, faites-en ce que bon vous semble ! Passons à la configuration du proxy inversé. 9. Configuration du proxy inversé 9-A. Configuration d'une entrée Nginx est une application assez dense, et demande de comprendre les procédés à l'œuvre, le tutoriel sur la mise en place d'un VPS comme frontend de @Einsteinium entre plus en détail dans le sujet, dans notre cas, on a la chance que Linuxserver propose dans son image toute une liste d'applications grand public préconfigurées, dirigeons-nous pour cela dans le dossier suivant : cd /volume1/docker/swag/config/nginx/proxy-confs Et voyons ce qu'on y trouve : ls -l On voit tout un tas d'entrée préconfigurées, qui se classent en deux catégories : subdomain et subfolder. Le proxy inversé peut fonctionner soit en fonction du sous-domaine sollicité, soit du "path" (chemin) après le nom de domaine. Dans notre cas on s'intéressera aux entrées de type subdomain, exemple avec une entrée pour Resilio-sync : Faisons un rapide tour des directives, les champs en vert sont ceux que vous êtes a priori susceptibles de modifier : server { => on commence la définition d'une entrée du proxy inversé listen 443 ssl; et listen [::]:443 ssl; => le proxy inversé va écouter sur le port 443 les requêtes en IPv4 et IPv6 de toutes les sources disponibles. server_name resilio-sync.*; => la condition pour que le proxy inversé réagisse est que l'adresse commence par resilio-sync, exemple -> resilio-sync.ndd.ovh. include /config/nginx/ssl.conf; => à l'exécution, nginx va importer tous les paramètres définis dans le fichier ssl.conf, entre autre le chemin du certificat à utiliser, les algorithmes de chiffrement, etc... #include /config/nginx/ldap.conf; => pour ceux qui souhaitent s'authentifier au travers du proxy à partir d'un serveur d'authentification LDAP. Cette image n'embarque pas de serveur LDAP, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut. #include /config/nginx/authelia-server.conf; => permet d'intégrer une authentification deux facteurs ou simple facteur conditionnelle, fera l'objet d'un autre tutoriel. Cette image n'embarque pas de serveur Authelia, elle permet juste de l'intégrer facilement au proxy inversé. Commenté par défaut. location / { : on définit le comportement de Nginx pour la racine ("/") du sous-domaine. Viennent ensuite trois blocs (de la ligne 21 à 30) affiliés respectivement à une authentification http (l'explorateur demandera un identifiant et un mot de passe au chargement de la page), des paramètres liés à l'authentification par LDAP, et des paramètres liés à Authelia. On n'y touchera pas ici. include /config/nginx/proxy.conf; => Importation d'en-têtes (timeouts, transmission des IP, gestion des cookies, etc...) include /config/nginx/resolver.conf; => Le résolveur DNS utilisé sera le résolveur Docker embarqué dans chaque conteneur. La partie suivante est la partie la plus importante, elle définit comment le conteneur swag va accéder à l'application qu'on souhaite dissimuler derrière le proxy inversé. Il faut garder à l'esprit que la façon dont le conteneur accède au réseau peut être bien différente de la façon dont vous, vous accédez à vos applications par le navigateur. Dans notre cas, vu que le conteneur est sur le réseau macvlan, donc sur le réseau physique, comme la machine depuis laquelle vous tentez d'accéder à ces applications. A une différence près, si vous avez bien suivi, c'est que le conteneur ne pourra pas accéder à son hôte via son IP physique, mais seulement par son IP virtuelle, donc dans notre cas 192.168.1.200 au lieu de 192.168.1.100. Voyons la signification des trois champs : 9-A-1. $upstream_app set $upstream_app resilio-sync; Ici c'est très trompeur, ce que vous lisez là, "resilio-sync", c'est le nom du conteneur. Cette résolution par nom de conteneur, donc ici que le conteneur de nom "swag" cherche à contacter le conteneur de nom "resilio-sync" ne peut s'opérer que si les deux conteneurs se trouvent dans le même réseau. Dans notre cas, si on avait bien un conteneur resilio-sync, il serait probablement en bridge sur son hôte. Par défaut inaccessible au conteneur Let's Encrypt sauf si on a translaté le port du conteneur sur celui du NAS. Dans ce dernier cas on peut tout à fait y accéder en entrant l'adresse IP ou le nom DNS du NAS : 192.168.1.200 (rappelez-vous, IP virtuelle). 9-A-2. $upstream_port set $upstream_port 8888; Il s'agit du port tel qu'il sera accessible pour le conteneur SWAG. Si par exemple sur votre NAS vous avez un conteneur Bitwarden, que par défaut l'interface est émise sur le port 8080 dans le conteneur, mais que vous avez décalé le port pour une raison qui vous appartient, disons vers 5080, il faudra alors utiliser 5080 et pas 8080. 9-A-3. $upstream_proto set $upstream_proto http; Le protocole lié au port, souvent http (on évite de chiffrer entre le NAS et lui-même), mais parfois https (certaines applications comme Unifi-controller n'expose leur interface que via HTTPS), à vous d'adapter en fonction du besoin. 9-A-4. Récapitulatif Prenons le cas de l'application Resilio-sync qu'on aurait installé sur notre NAS, via le centre des paquets (sans Docker donc), j'utiliserai la configuration suivante : set $upstream_app 192.168.1.200; set $upstream_port 8888; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; La ligne proxy_pass construit l'URL à partir des variables précédemment définies, on n'a pas à y toucher. D'autres exemples : Moments set $upstream_app 192.168.1.200; set $upstream_port 10004; # Port personnalisé de Moments dans Portail des applications set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Jeedom auquel j'accède via un nom de domaine local : set $upstream_app raspberrypi.local; set $upstream_port 8088; set $upstream_proto http; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Mon routeur, dont l'interface émet sur le port sécurisé 8443 : set $upstream_app 192.168.1.1; set $upstream_port 8443; set $upstream_proto https; proxy_pass $upstream_proto://$upstream_app:$upstream_port; Une fois toutes nos entrées configurées, on redémarre le conteneur : docker restart swag Et normalement, tout devrait être fonctionnel. 9-B. Redirection HTTP -> HTTPS Par défaut, SWAG écoute sur le port 80. Si vous souhaitez que SWAG fasse une redirection automatique 80 -> 443 pour les requêtes extérieures, il faut faire une redirection du port 80 depuis votre box vers le port 80 de l'IP (192.168.1.145) du conteneur. Si vous aviez l'habitude de faire une demande de certificat depuis DSM via HTTP-01, vous risquez d'être embêté car une seule redirection simultanée du port 80 est possible. 9-C. Validation par HTTP-01 Il se peut que votre hébergeur DNS n'ait pas d'API pour permettre une validation du certificat à son niveau, dans ce cas-là vous pourriez vouloir utiliser un certificat délivré par HTTP-01. Il faut dans ce cas-là rediriger le port 80 de votre box/routeur vers le port 80 de l'IP du conteneur 192.168.1.145 Un fichier docker-compose type pour un renouvellement HTTP-01 pourrait être le suivant : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=plex,bitwarden,wordpress,dsm, # on liste les sous-domaine, attention à la virgule finale - VALIDATION=http # on remplace dns par http et on supprime la variable DNSPLUGIN - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config restart: unless-stopped networks: macvlan_net: external: true Remarque : Si notre certificat racine (ndd.ovh) est déjà géré ailleurs, mais qu'on souhaite avoir un deuxième proxy inversé sur une autre machine (un VPS par exemple) avec le même domaine, on peut passer la variable ONLY_SUBDOMAINS à true. Ainsi le certificat ne sera généré que pour les sous-domaines. 10. Fail2ban 10-A. Configuration Fail2ban est une application très pratique qu'on retrouve dans DSM, c'est le service qui permet de bannir une personne tentant de se logger plusieurs fois d'affilée de manière infructueuse à un service Synology. Ici, on va pouvoir l'appliquer à ce qu'on veut. Dans DSM c'est configurable dans l'onglet "Blocage". Il y a cependant une condition, fail2ban se base sur la lecture de logs, et en les analysant il va identifier des IP et des résultats de login : échec ou succès. La plupart des logs d'accès sont lisibles par fail2ban, car il embarque tout un set d'expressions régulières lui permettant d'analyser les logs, mais c'est un point à vérifier en amont. Fail2ban se base sur ce qu'on appelle des prisons, ou "jails" en anglais. Allons donc dans le dossier de fail2ban : cd /volume1/docker/swag/config/fail2ban && ls -l $_ filter.d comprend les fichiers de configuration permettant d'analyser et filtrer le contenu des logs en extrayant les informations utiles au moyen d'expressions régulières. action.d comprend les actions à entreprendre quand une analyse répond à un critère de filtrage. Ces dossiers comprennent un grand nombre de fichiers de configuration prédéfinis propres à tout un ensemble d'applications. Remarque : Si l'application que vous souhaitez protéger n'est pas incluse, il faudra alors créer vos propres filtres. fail2ban.sqlite3 est la base de données embarquée. jail.local est le fichier qui nous intéresse en particulier : La section [DEFAULT] définit le comportement global, il peut être écrasé au sein des sections suivantes qui définissent chaque service qu'on souhaite surveiller (maxretry, etc...). Intéressant, et qui n'apparaît pas dans l'impression d'écran, il est possible d'ajouter une directive ignoreip qui permet de whitelister des plages d'IP : ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 Ici je whitelist les IP pivées qui peuvent vouloir se connecter, pas de risque de me verrouiller du coup. Le fichier jail.local surveille par défaut les 4 services Nginx. On a également un bloc ssh désactivé par défaut. Pour l'activer c'est assez simple : [ssh] enabled = true port = ssh filter = sshd logpath = /log/host_ssh_auth.log Notes : port : ssh représente ici le port SSH par défaut (22), dans les faits si vous avez changé le port SSH sur votre hôte, mettez directement son numéro. filter : cela correspond au nom du fichier .conf qu'on trouvera dans le dossier filter.d, ici on appellera donc le fichier sshd.conf logpath : normalement le contenu des logs SSH se trouve dans /var/log/auth.log, pourquoi ne pas mettre ça ? Si vous écrivez /var/log/auth.log, vous allez surveiller le log d'accès SSH ... au conteneur. A priori ça ne nous intéresse pas, on cherche à lire les logs SSH de l'hôte. Pour que le conteneur y ait accès, il faut les monter via un volume. Il suffit pour cela d'éditer le fichier docker-compose.yml et d'y monter les logs de l'hôte dans un fichier à l'intérieur du conteneur, qu'on définit arbitrairement : version: '2.1' services: swag: image: linuxserver/swag container_name: swag networks: macvlan_net: ipv4_address: 192.168.1.145 cap_add: - NET_ADMIN environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris - URL=ndd.ovh - SUBDOMAINS=wildcard - VALIDATION=dns - DNSPLUGIN=ovh - DHLEVEL=2048 - EMAIL=mail@ndd.tld - ONLY_SUBDOMAINS=false - STAGING=false volumes: - ./config:/config - /var/log/auth.log:/log/host_ssh_auth.log:ro # on ajoute ro pour read-only (lecture seule) restart: unless-stopped networks: macvlan_net: external: true On recrée le conteneur : docker-compose down && docker-compose up -d On aura maintenant fail2ban qui pourra analyser les connexions SSH sur l'hôte. Quelques commandes utiles pour vérifier le bon fonctionnement des prisons : Pour renvoyer la liste des prisons : docker exec -it swag fail2ban-client status Pour afficher le statut d'une prison en particulier, ici ssh : docker exec -it swag fail2ban-client status ssh le terme swag dans les commandes précédentes correspond au nom que vous avez donné au conteneur SWAG. 10-B. Proxy fiable Par défaut, DSM empêche l'identification de l'IP source, sauf si on a précisément ajouter à la liste des proxy fiables l'IP de notre conteneur swag. Pour cela, Panneau de configuration -> Sécurité -> Proxies fiables et on ajoute l'IP du conteneur: On valide, maintenant ce sera l'IP source qui sera lue et non plus l'IP du conteneur SWAG. Ce qui revêt son importance pour fail2ban, sinon vous allez simplement bannir votre proxy inversé, ce serait bête non ? Pour ceux qui souhaitent pousser la configuration de fail2ban plus en profondeur : https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/ https://manpages.debian.org/testing/fail2ban/jail.conf.5.en.html (très intéressant) https://github.com/linuxserver/docker-swag#using-fail2ban (commandes utiles) 11. Conclusion Ce conteneur est un package tout-en-un pour la gestion de vos certificats de vos accès externes et internes. Et il est assez facile à manipuler une fois qu'on a compris le principe. Il a surtout l'avantage de ne pas toucher au système, qu'il s'agisse de DSM ou d'une distribution Linux autre. Dans le cas de DSM particulièrement, il est possible de réaliser ce genre de manipulations car DSM utilise Nginx pour son proxy inversé, mais chaque mise à jour de paquet ou d'OS supprimera toutes vos modifications. Il existe un ancien tutoriel de @CoolRaoul pour proxy inversé sur le forum qui explorait justement une solution à ce problème, mais à l'époque le portail des applications DSM n'existait pas encore. Enfin c'est tout à fait portable, le jour où vous souhaitez héberger le proxy inversé sur un Raspberry Pi, un VPS, ou tout autre périphérique, il n'y aura qu'à copier vos fichiers de configuration d'une machine à l'autre, et faire les quelques adaptations nécessaires (adresses des services internes + redirection des ports). Màj : 22/07/2021

1. Préambule Ce tutoriel est dédié à la mise en service de trois applications qui œuvrent de concert pour récolter (Telegraf), stocker (InfluxDB) et afficher (Grafana) sous la forme désirée des métriques liées à des équipements informatiques. Les applications sont extrêmement vastes, cela va de la surveillance d'un système domotique, un système d'arrosage piloté par une vanne intelligente par exemple, à la supervision d'une infrastructure réseau, d'un serveur VPS, etc... Ce trio d'applications va être mis en service par le biais de Docker, un paquet disponible dans le centre de paquets Synology pour les modèles "haut de gamme" du constructeur. Comme vous le constaterez si vous parcourez les nombreuses pages de commentaires de ce tutoriel, des membres du forum ont activement apporté leur contribution à l'amélioration de ce fil et je les en remercie tous grandement, nous avons tous appris les uns des autres. Pour illustrer le propos, quelques exemples de tableaux de bord qu'il est possible de réaliser via Grafana : Fig. 1 Supervision d'un serveur Linux sous Debian 10 Fig. 2 Mise en place d'un speedtest régulier pour mesurer les performances de sa connexion (@oracle7 @bruno78) Fig. 3 Supervision combinée d'un DS920+ et d'un RT2600AC (@MilesTEG1) Fig. 4 Supervision d'une Freebox (@bruno78) Fig. 5 Supervision du trafic Wifi d'un routeur RT2600AC (@oracle7) 2. Prérequis Difficulté : facile-moyenne Ce tutoriel prend le temps d'expliciter la très grande majorité des commandes, néanmoins, afin de mieux comprendre ce qui est expliqué ici, il est conseillé de prendre connaissance des bases du fonctionnement de Docker, un tutoriel introductif est disponible sur le forum : Il est également important de savoir se connecter en SSH : 3. Matériel nécessaire Docker est un logiciel multiplateforme : Linux, Mac, Windows Ce tutoriel aborde en particulier les spécificités liées à DSM et à son implémentation de Docker, mais il est transposable (surtout via docker-compose) à toutes les machines compatibles. Avoir un NAS n'est donc pas une obligation pour mener ce tutoriel à terme. Vous pouvez vérifier quels NAS Synology sont capables d'utiliser Docker à cette adresse. 4. Outils et informations utiles 4-A. Docker-compose Docker-compose est une commande embarquée avec le paquet Docker de Synology, codé en Python et disponible via SSH. Il permet de structurer, de manière plus analytique qu'un script docker en ligne de commande, les variables, volumes, etc... d'un conteneur au sein d'un fichier au format yaml/yml. Ce fichier reste après création du conteneur, on conserve ainsi les paramètres de personnalisation de notre image Docker à tout moment. Pour crée un fichier docker-compose.yml, c'est assez simple : 4-A-1. Linux Si vous utilisez une distribution avec interface graphique, vous pouvez utiliser l'éditeur de texte embarqué. Sur DSM, vous avez le paquet éditeur de texte qui convient parfaitement. En ligne de commande, utilisez l'outil qui vous convient le mieux : vi, vim, nano, emacs, etc... Conseil : nano est un des éditeurs les plus simples à prendre en main, pour l'installer sur votre NAS (DSM ne l'embarque pas par défaut), vous pouvez télécharger le paquet SynoCli File Tools du dépôt Synocommunity. Je recommande d'ailleurs vivement l'installation de la suite de paquets SynoCli, ils sont très pratiques dès que vous commencez à prendre vos aises avec l'interface en ligne de commande. 4-A-1. Mac La plupart des éditeurs de texte font l'affaire, sinon via le Terminal. 4-A-1. Windows Je vous conseille d'utiliser Notepad++ Une fois lancé, aller dans le menu Encodage et vérifier que "Encoder en UTF-8" est sélectionné. Une fois votre fichier prêt, Enregistrer sous pour nommer le fichier et choisir le type : YAML Ain't Makeup Language (fin de la liste déroulante). A des fins de simplification du tutoriel, veuillez toujours nommer le fichier docker-compose (hors extension), cela permettra d'exécuter la commande de création de conteneur avec le moins d'arguments possibles. 4-B. Persistance des données Afin de stocker de manière pérenne les données d'un conteneur, on va créer un dossier par conteneur (ou groupe de conteneurs travaillant ensemble). A l'installation de Docker sur DSM, un dossier partagé "docker" est automatiquement créé, donc autant l'utiliser pour y stocker nos différents dossiers. Par exemple, pour Telegraf, le chemin absolu de son dossier sera /volume1/docker/telegraf Rien ne vous oblige à respecter cette règle. Quelque soit le dossier choisi, on va généralement y placer le fichier docker-compose.yml 4-C. SNMP Aucune connaissance réellement nécessaire pour la stricte application du tutoriel, mais si vous comptez faire de la surveillance d'autres équipements réseaux, ce sera incontournable d'en comprendre le fonctionnement global. On trouve la plupart des informations sur la page wikipédia (notamment les deux premiers paragraphes). 4-D. Fichiers MIB Les fichiers MIB traduisent traduisent et mettent en forme pour les humains les données qui sont mises à disposition par un système pour sa supervision. Exemple : .1.3.6.1.4.1.6574.5 => synologyDiskSMART La suite de caractères à gauche de la flèche est un OID, et à droite son nom : synologyDiskSMART. L'OID se construit via une arborescence : pour inspecter les sous-catégories de synologyDiskSMART, l'OID va s'enrichir de nouveaux caractères : .1.3.6.1.4.1.6574.5.1 => diskSMARTInfoIndex .1.3.6.1.4.1.6574.5.7 => diskSMARTAttrThreshold .1.3.6.1.4.1.6574.5.9 => diskSMARTAttrStatus Ainsi de suite... Synology met à disposition un PDF comprenant la liste non exhaustive des OID principaux disponibles dans DSM. 5. Serveur SNMP Pour pouvoir récolter les informations mises à disposition par le NAS, il faut d'abord activer le serveur SNMP, désactivé par défaut. Pour y remédier, on va dans Panneau de configuration -> Terminal & SNMP -> SNMP pour arriver à l'écran suivant : Fig. 6 Activation du protocole SNMP Remarques : - SNMPv2 est parfaitement adapté à une utilisation locale. Si vous souhaitiez superviser un NAS distant depuis votre NAS local, SNMPv3 est un choix plus avisé de par sa sécurité renforcée. - Je vous recommande de changer le nom de la communauté, j'utilise la logique suivante pour nommer mes périphériques : <nom_du_périphérique><suite_de_chiffres_XYZ> Exemples : vpsXYZ, nas1XYZ, raspberrypiXYZ, etc... - Au niveau du pare-feu, veuillez vous assurer d'avoir autorisé la plage d'IP 172.16.0.0/255.240.0.0 à communiquer avec le NAS, c'est la plage d'IP utilisée par Docker. A minima, autorisez le port UDP 161 depuis cette plage IP, si vous ne souhaitez pas autoriser tous les ports. 6. Alchimie L'ensemble de ces trois applications, qu'on retrouve parfois sous l'appellation TIG (Telegraf InfluxDB Grafana), opère de la sorte : - Telegraf C'est un agent de récupération de métriques (entendez des données relatives au fonctionnement du système que vous souhaitez surveiller). - InfluxDB InfluxDB est une base de données qui va stocker les métriques recueillies par Telegraf. - Grafana C'est un outil de supervision et d'agrégation de métriques, ce qui va nous permettre de manipuler les données stockées dans InfluxDB. 7. Mise en place 7-A. Images On télécharge les trois images docker suivantes (voir tutoriel introductif) : telegraf influxdb:1.8 grafana/grafana ATTENTION : InfluxDB 2.x nécessite une configuration totalement et un usage au sein de Grafana totalement différents de ce qui est abordé par la suite. Ce tutoriel ne s'adresse donc qu'aux installations utilisant les versions 1.x de InfluxDB. 7-B. Création d'un réseau bridge personnalisé (user-defined bridge network) Pour permettre la communication entre deux conteneurs, on distingue deux méthodes : 7-B-1. Lien On utilise la fonction de lien (link) présente dans l'interface de création d'un conteneur sur DSM qui pointe vers le conteneur avec lequel on souhaite établir une communication. Cette méthode fonctionne encore, mais est dépréciée par Docker. 7-B-2. Réseau Il y a deux catégories de réseau bridge : le réseau bridge par défaut et le réseau bridge personnalisé. 7-B-2-a. Bridge par défaut Le conteneur est isolé dans le sous-réseau 172.17.0.0/255.255.0.0 Depuis le conteneur, le NAS est accessible à l'adresse 172.17.0.1, il est sa passerelle vers le monde extérieur. Un conteneur attaché à ce réseau est joignable uniquement par son IP (pas de résolution DNS possible). 7-B-2-b. Bridge personnalisé C'est un réseau créé par l'utilisateur. Tous les conteneurs qui feront partie de ce réseau pourront communiquer via leur nom de conteneur, cette résolution DNS est extrêmement pratique car elle ne fait pas intervenir les IP qui peuvent être amenées à changer d'une fois à l'autre. Via docker-compose, si on ne précise rien concernant le réseau dans le fichier docker-compose.yml, Docker créera un réseau bridge personnalisé dédié au(x) service(s) de façon automatique. C'est ce qu'on appelle un réseau interne, car il est créé dans la foulée de la mise en route d'un service Ici, nous allons créer un réseau externe, comme ça même si tous les conteneurs sont supprimés, le réseau persiste et est prêt à accueillir de nouveaux conteneurs. Remarque : Au sein d'un réseau bridge personnalisé, les ports des conteneurs sont intégralement exposés les uns envers les autres, il est donc primordial de ne placer dans un même réseau que des conteneurs qui ont vocation à communiquer entre eux. 7-B-2-b-1. Par DSM Pour créer un réseau bridge personnalisé sur DSM, c'est très simple, on clique sur le paquet Docker -> Réseau -> Ajouter -> Fig. 7 Création du réseau bridge personnalisé via DSM On peut tout à fait choisir d'obtenir une configuration automatique, mais cela ne coûte pas bien plus cher de définir la configuration de notre réseau. Tous nos conteneurs auront des IP dans la plage 172.18.0.1 à 172.18.0.254, l'adresse 172.18.0.1 étant réservée au NAS (passerelle), à la manière du réseau bridge par défaut. On valide, le réseau est maintenant créé, il suffira d'indiquer à nos conteneurs de s'y connecter à leur création. 7-B-2-b-2. Par ligne de commande (CLI) Alternative à l'interface DSM, via SSH, on tape la commande suivante : docker network create -d bridge \ --subnet=172.18.0.0/24 \ --gateway=172.18.0.1 \ --opt "com.docker.network.bridge.name"="br_monitoring" \ monitoring L'avantage avec cette méthode est qu'on définit le nom de l'interface, sinon une suite de caractères aléatoires est générée, utiliser ifconfig pour le vérifier. Remarques : - Penser à ajouter "sudo" devant la commande si vous n'êtes pas connecté en root. - Il est possible de faire rejoindre d'autres réseaux à un conteneur après sa création, voir dans la documentation officielle de Docker. 7-C. Docker-compose : fichiers multiples ou fichier unique Un fichier docker-compose a l'avantage de pouvoir gérer plusieurs services simultanément (un service entrainant la création d'un conteneur), définir un ordre de démarrage, des paramètres (volumes et réseaux par exemple) communs, etc... La méthode du fichier unique est donc toute indiquée ici, car nos conteneurs sont dépendants les uns des autres. Cependant, à des fins didactiques, je proposerai pour chacune des applications un code autonome. Je présente dans un premier temps la méthode avec des fichiers séparés, rendez-vous au point 9. pour des détails concernant l'utilisation d'un fichier unique. 8. Création des conteneurs 8-A. InfluxDB L'ordre dans lequel on ajoute les services dans le fichier docker-compose.yml n'a pas d'importance, c'est le paramètre "depends_on" qui permettra de définir un ordre de mise en route (uniquement pour un fichier unique, voir plus loin). Commençons par définir les paramètres de notre conteneur InfluxDB. La liste des variables d'environnement pour InfluxDB est disponible à cette adresse. Cela peut être utile si vous souhaitez définir une police de rétention des données. On crée un dossier influxdb dans le dossier partagé docker, soit par File Station, soit en SSH : mkdir /volume1/docker/influxdb Puis on va créer le fichier docker-compose.yml : IMPORTANT: Un fichier docker-compose.yml n'accepte pas les tabulations !!! Seuls les espaces sont acceptés !! version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true ports: # Optionnel - 8086:8086 # Optionnel volumes: - /volume1/docker/influxdb/data:/var/lib/influxdb restart: unless-stopped networks: monitoring: external: true Une fois ceci fait, on se place dans le répertoire d'InfluxDB : cd /volume1/docker/influxdb On va devoir créer un dossier data dans le dossier présent : mkdir data Puis : docker-compose up -d En cas d'erreur, pour supprimer un conteneur par docker-compose, c'est tout simplement : docker-compose down Remarques : Concernant la forme, le nombre d'espaces n'a pas d'importance, le tout étant de garder la même logique, et d'aligner les éléments comme proposé. Concernant le fond : - On a défini un nom pour notre conteneur : influxdb - On a créé une base de données par défaut => nas_telegraf - On a créé un utilisateur administrateur pour gérer l'ensemble des base de données dans InfluxDB => admin / admin - On a créé un utilisateur avec les droits de lecture et écriture sur la base de données nas_telegraf => nas_telegraf / nas_telegraf - On a activé l'authentification HTTP (nécessaire pour que les autres variables d'environnement soient prises en compte). - Le dossier data créé ci-avant comportera ce qu'on trouvera dans le conteneur dans son dossier /var/lib/influxdb. ATTENTION : Il est important de noter que la translation de ports n'est nécessaire que si d'autres périphériques doivent accéder à cette instance d'InfluxDB. Par exemple un conteneur Telegraf sur un Raspberry Pi qui enverrait ses données vers InfluxDB. Par défaut, je commente (avec le # en début de ligne) les lignes relatives à la translation de ports. En effet, les trois applications étant dans le même réseau personnalisé, tous leurs ports sont exposés les uns aux autres, aucun besoin de redirection en ce cas. Si on souhaite que des instances Telegraf externes au NAS (sur une autre machine du réseau), décommentez la définition des ports (supprimez les #), supprimez le conteneur et recréez-le. Notre instance InfluxDB est donc maintenant prête à accueillir des données depuis Telegraf. 8-B. Telegraf 8-B-1. Génération du fichier de configuration Telegraf utilise un fichier de configuration .conf, qu'on va générer en amont de la création du conteneur. Comme pour InfluxDB on crée un dossier telegraf : mkdir /volume1/docker/telegraf Puis on va dans le dossier de Telegraf : cd /volume1/docker/telegraf Puis : docker run --rm telegraf telegraf config > telegraf.conf Un fichier telegraf.conf va apparaître dans le dossier, avant de l'éditer je vous conseille d'en faire une copie, en SSH il suffit de taper la commande suivante (merci @unPixel pour la suggestion) : cp telegraf.conf telegraf.conf.back Ceci fait, le fichier de configuration de Telegraf se décompose en trois sections : - Les paramètres globaux de Telegraf - Les plugins de sortie - Les plugins d'entrée 8-B-2. Paramétrage 8-B-2-a. Global Ce sont les paramètres globaux de Telegraf, c'est-à-dire ceux qui s'appliqueront si un plugin ne contient pas une directive contraire (intervalle de récolte des données par exemple). # Telegraf Configuration # # Telegraf is entirely plugin driven. All metrics are gathered from the # declared inputs, and sent to the declared outputs. # # Plugins must be declared in here to be active. # To deactivate a plugin, comment out the name and any variables. # # Use 'telegraf -config telegraf.conf -test' to see what metrics a config # file would generate. # # Environment variables can be used anywhere in this config file, simply prepend # them with $. For strings the variable must be within quotes (ie, "$STR_VAR"), # for numbers and booleans they should be plain (ie, $INT_VAR, $BOOL_VAR) # Global tags can be specified here in key="value" format. [global_tags] # dc = "us-east-1" # will tag all metrics with dc=us-east-1 # rack = "1a" ## Environment variables can be used as tags, and throughout the config file # user = "$USER" # Configuration for telegraf agent [agent] ## Default data collection interval for all inputs interval = "10s" ## Rounds collection interval to 'interval' ## ie, if interval="10s" then always collect on :00, :10, :20, etc. round_interval = true ## Telegraf will send metrics to outputs in batches of at most ## metric_batch_size metrics. ## This controls the size of writes that Telegraf sends to output plugins. metric_batch_size = 1000 ## For failed writes, telegraf will cache metric_buffer_limit metrics for each ## output, and will flush this buffer on a successful write. Oldest metrics ## are dropped first when this buffer fills. ## This buffer only fills when writes fail to output plugin(s). metric_buffer_limit = 10000 ## Collection jitter is used to jitter the collection by a random amount. ## Each plugin will sleep for a random time within jitter before collecting. ## This can be used to avoid many plugins querying things like sysfs at the ## same time, which can have a measurable effect on the system. collection_jitter = "0s" ## Default flushing interval for all outputs. Maximum flush_interval will be ## flush_interval + flush_jitter flush_interval = "10s" ## Jitter the flush interval by a random amount. This is primarily to avoid ## large write spikes for users running a large number of telegraf instances. ## ie, a jitter of 5s and interval 10s means flushes will happen every 10-15s flush_jitter = "0s" ## By default or when set to "0s", precision will be set to the same ## timestamp order as the collection interval, with the maximum being 1s. ## ie, when interval = "10s", precision will be "1s" ## when interval = "250ms", precision will be "1ms" ## Precision will NOT be used for service inputs. It is up to each individual ## service input to set the timestamp at the appropriate precision. ## Valid time units are "ns", "us" (or "µs"), "ms", "s". precision = "" ## Logging configuration: ## Run telegraf with debug log messages. debug = false ## Run telegraf in quiet mode (error log messages only). quiet = false ## Specify the log file name. The empty string means to log to stderr. logfile = "" ## Override default hostname, if empty use os.Hostname() hostname = "" ## If set to true, do no set the "host" tag in the telegraf agent. omit_hostname = false Les champs notables sont : - le champ interval dans la section [agent] : il définit à quel intervalle les données sont récoltées. - le champ debug dans la même section : le passer à true passe le niveau de verbosité à debug. Pour ma part, j'ai réglé à 60s l'intervalle et réglé debug à true, toujours plus pratique pour identifier la source d'un problème. 8-B-2-b. InfluxDB ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://influxdb:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "nas_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. # database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. # write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "nas_telegraf" password = "nas_telegraf" ## HTTP User-Agent # user_agent = "telegraf" ## UDP payload size is the maximum packet size to send. # udp_payload = "512B" ## Optional TLS Config for use on HTTP connections. # tls_ca = "/etc/telegraf/ca.pem" # tls_cert = "/etc/telegraf/cert.pem" # tls_key = "/etc/telegraf/key.pem" ## Use TLS but skip chain & host verification # insecure_skip_verify = false ## HTTP Proxy override, if unset values the standard proxy environment ## variables are consulted to determine which proxy, if any, should be used. # http_proxy = "http://corporate.proxy:3128" ## Additional HTTP headers # http_headers = {"X-Special-Header" = "Special-Value"} ## HTTP Content-Encoding for write request body, can be set to "gzip" to ## compress body or "identity" to apply no encoding. # content_encoding = "identity" ## When true, Telegraf will output unsigned integers as unsigned values, ## i.e.: "42u". You will need a version of InfluxDB supporting unsigned ## integer values. Enabling this option will result in field type errors if ## existing data has been written. # influx_uint_support = false Remarques : - urls = ["http://influxdb:8086"] -> Si vous avez bien suivi, notre conteneur Telegraf peut contacter InfluxDB directement par son nom de conteneur, et tous les ports étant exposés entre eux, on peut l'écrire de la sorte. - database = "nas_telegraf" -> c'est le nom qu'on a donné à notre base de données lors de la création du conteneur influxdb (variable d'environnement INFLUXDB_DB). - skip_database_creation = true -> créée en même temps que le conteneur influxdb, on peut régler cette option sur "true". - HTTP Basic Auth : on entre le nom d'utilisateur et le mot de passe (respectivement les variables d'environnement INFLUXDB_USER et INFLUXDB_USER_PASSWORD) qu'on a également définis dans notre fichier docker-compose pour InfluxDB : nas_telegraf / nas_telegraf En l'état, le fichier de configuration est suffisamment paramétré pour envoyer certaines données que Telegraf collecte par défaut à notre base de données InfluxDB : CPU, mémoire, kernel, etc... C'est là que vont intervenir les fichiers MIB, ceux-ci permettent une supervision plus poussée du NAS, mais pour cela il va falloir donner à Telegraf les OID relatifs aux informations que Synology fournit via SNMP. 8-B-2-c. SNMP Pour cela on peut se baser sur le travail de jperillo sur Github, notamment son listing des OID de DSM. Au fil des mois, les différents contributeurs de ce tutoriel ont fourni une aide précieuse pour compléter les OID liés au monitoring d'un onduleur branché au NAS, vous retrouverez dans le fichier suivant une version plus complète que ce proposé sur le lien ci-dessus : snmp-dsm.conf Le contenu de ce fichier est à placer juste après le début de la section INPUT PLUGINS. Il reste quelques champs à personnaliser : agents : agents = [ "xxx.xxx.xxx.xxx", "xxx.xxx.xxx.xxx" ] Ce sont les IP des NAS à superviser, vous pouvez parfaitement passer par l'IP passerelle du NAS sur lequel Telegraf est installé : 172.18.0.1 Si vous souhaitez superviser d'autres NAS, il faut entrer l'IP par laquelle vous-même les contacteriez : IP locale si sur le réseau local, IP publique si NAS à distance, etc... Si vous ne supervisez qu'un seul NAS, pensez à supprimer la virgule et le deuxième bloc IP : agents = [ "xxx.xxx.xxx.xxx" ] community : On pense à changer le nom de la communauté si on l'a modifié dans DSM. interval : Intervalle entre chaque récolte de données (écrase la valeur donnée dans les paramètres généraux de Telegraf pour ce plugin uniquement). 8-B-3. Fichier docker-compose version: '2.1' services: telegraf: image: telegraf container_name: telegraf networks: - monitoring # ports: # Optionnel # - 8125:8125 # Optionnel # - 8092:8092/udp # Optionnel # - 8094:8094 # Optionnel volumes: - /volume1/docker/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro - /etc/localtime:/etc/localtime:ro - /etc/TZ:/etc/timezone:ro restart: unless-stopped networks: monitoring: external: true On vérifie qu'on se trouve bien dans /volume1/docker/telegraf puis : docker-compose up -d Remarques : - Le suffixe ":ro" à la fin du montage de volume signifie read-only (lecture seule), pour éviter toute modification indésirable des fichiers par le conteneur. - Les fichiers MIB de Synology sont déjà présents sur le NAS, on va donc monter le dossier dans le conteneur pour que Telegraf y ait accès. - Si votre instance Telegraf collecte les données d'un NAS distant, et que l'hôte de Telegraf n'est pas un NAS Synology, il aura besoin des fichiers MIB disponibles à cette adresse. - Une fois de plus je n'expose aucun port sur le NAS même, ce serait utile uniquement si je souhaitais qu'un script envoie des données à Telegraf par exemple. Telegraf va dorénavant envoyer périodiquement les métriques à InfluxDB, on peut le vérifier en tapant dans le dossier de Telegraf : docker-compose logs -f telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 109.726214ms telegraf | 2021-01-08T23:55:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 144.489076ms telegraf | 2021-01-08T23:55:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:55:52Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Wrote batch of 469 metrics in 145.368898ms telegraf | 2021-01-08T23:56:02Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:12Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:22Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Wrote batch of 469 metrics in 119.228603ms telegraf | 2021-01-08T23:56:32Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics telegraf | 2021-01-08T23:56:42Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics et vérifier dans InfluxDB également en se plaçant dans son dossier et en utilisant la même commande : [httpd] 172.18.0.3,172.18.0.2 - nas_telegraf [08/Jan/2021:23:59:07 +0000] "POST /write?consistency=any&db=nas_telegraf HTTP/1.1" 204 0 "-" "Telegraf/1.16.3 Go/1.15.2" 7e616302-520d-11eb-aead-0242ac130002 15706 8-C. Grafana 8-C-1. Fichier docker-compose Il ne reste plus qu'à configurer Grafana pour pouvoir visualiser les données stockées dans InfluxDB. Comme pour les deux autres conteneurs, on crée un dossier dédié pour Grafana, et un dossier data dans ce dernier. version: '2.1' services: grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/grafana/data:/var/lib/grafana user: "1026" # Optionnel ports: - 3000:3000 restart: unless-stopped networks: monitoring: external: true Puis : docker-compose up -d Remarques : - Ici je suis forcé de translater le port correspondant à l'interface de Grafana si je souhaite pouvoir y accéder d'une autre machine que le NAS, ce qui sera nécessairement le cas. - Il est possible d'accéder à Grafana au travers d'un proxy inversé. 8-C-2. Création de la source de données On se rend sur la page http://IP_DU_NAS:3000 (ou le port qu'on a choisi) pour accéder à Grafana : Fig. 8 Page d'authentification de Grafana Les accès par défaut sont admin/admin, la première fois qu'on se connecte on nous invite à changer le mot de passe du compte admin. Fig. 9 Écran d'accueil de Grafana On suit les indications de Grafana et on commence par ajouter la source de données, ici notre conteneur InfluxDB. On clique sur Add data source. On choisit InfluxDB. On remplit ensuite l'écran suivant de la sorte : Fig. 10 Configuration de la source de données InfluxDB pour les données du NAS Remarques : - On donne un nom à notre datasource, ici j'ai choisi NAS_InfluxDB. - influxdb dans http://influxdb:8086 représente le nom que vous avez donné au conteneur. - On coche Basic Auth car on a activé l'authentification http à la création du conteneur InfluxDB. - Les informations à entrer dans "InfluxDB Details" correspondent aux variables d'environnement du conteneur InfluxDB : Database : INFLUXDB_DB User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD - Basic Auth Details : User : INFLUXDB_USER Password : INFLUXDB_USER_PASSWORD On clique sur Save & Test, on obtient un message écrit en vert Datasource is working si tout est bien paramétré. 8-C-3. Création d'un tableau de bord (dashboard) On peut soit créer son propre tableau de bord, soit en importer un, pour cela il suffit d'aller sur le site de Grafana, plus précisément sur cette page. En tapant Synology dans le cadre de recherche, on peut par exemple choisir le tableau de bord de Yann Bizeul. Fig. 11 Page du tableau de bord publique de Yann Bizeul sur le site de Grafana On clique sur "Copy ID to Clipboard", on retourne sur notre instance de Grafana et on clique sur import dans le menu rapide à la gauche de l'écran : Fig. 12 Importation d'un tableau de bord 1/2 Dans l'écran suivant on colle dans "Grafana.com dashboard" le numéro de du tableau de bord qu'on a choisi. On valide en cliquant sur "Load" et on arrive sur l'écran suivant : Fig. 13 Importation d'un tableau de bord 2/2 Dans InfluxDB on choisit la datasource définie ci-avant, on valide en cliquant sur "Import". Il est aussi possible d'importer des tableaux de bord depuis un fichier JSON, n'hésitez pas à en demander sur ce fil, plusieurs des participants sont prêts à partager les leurs (impressions d'écran en début de tutoriel). 9. Fichier docker-compose unique Si on avait voulu le définir en un seul fichier, on aurait pu faire ainsi : - Créer un dossier monitoring dans /volume1/docker : cd /volume1/docker mkdir monitoring Puis créer des dossiers data pour InfluxDB et Grafana : mkdir influxdb-data grafana-data telegraf-data Et créer enfin un fichier docker-compose.yml : version: '2.1' services: influxdb: image: influxdb:1.8 container_name: influxdb networks: - monitoring environment: - INFLUXDB_DB=nas_telegraf - INFLUXDB_ADMIN_USER=admin - INFLUXDB_ADMIN_PASSWORD=admin - INFLUXDB_USER=nas_telegraf - INFLUXDB_USER_PASSWORD=nas_telegraf - INFLUXDB_HTTP_AUTH_ENABLED=true ports: # Optionnel - 8086:8086 # Optionnel volumes: - /volume1/docker/monitoring/influxdb-data:/var/lib/influxdb restart: unless-stopped grafana: image: grafana/grafana container_name: grafana networks: - monitoring volumes: - /volume1/docker/monitoring/grafana-data:/var/lib/grafana user: "1026" # Optionnel ports: - 3000:3000 depends_on: - telegraf - influxdb restart: unless-stopped telegraf: image: telegraf container_name: telegraf networks: - monitoring ports: # Optionnel - 8125:8125 # Optionnel - 8092:8092/udp # Optionnel - 8094:8094 # Optionnel depends_on: - influxdb volumes: - /volume1/docker/monitoring/telegraf-data/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /usr/share/snmp/mibs:/usr/share/snmp/mibs:ro restart: unless-stopped networks: monitoring: external: true __________________________________________ 10. Supervision de Docker La manipulation est très simple, dans le fichier telegraf.conf, il suffit de décommenter les options qui nous intéressent. Il y a possibilité de trier les conteneurs dont on souhaite réaliser la surveillance suivant différents critères : nom, état, label... # # Read metrics about docker containers [[inputs.docker]] # ## Docker Endpoint # ## To use TCP, set endpoint = "tcp://[ip]:[port]" # ## To use environment variables (ie, docker-machine), set endpoint = "ENV" endpoint = "unix:///var/run/docker.sock" # # ## Set to true to collect Swarm metrics(desired_replicas, running_replicas) # gather_services = false # # ## Only collect metrics for these containers, collect all if empty container_names = [] # # ## Set the source tag for the metrics to the container ID hostname, eg first 12 chars # source_tag = false # # ## Containers to include and exclude. Globs accepted. # ## Note that an empty array for both will include all containers # container_name_include = [] # container_name_exclude = [] # # ## Container states to include and exclude. Globs accepted. # ## When empty only containers in the "running" state will be captured. # ## example: container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] # ## example: container_state_exclude = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] container_state_include = ["created", "restarting", "running", "removing", "paused", "exited", "dead"] container_state_exclude = [] # # ## Timeout for docker list, info, and stats commands timeout = "5s" # # ## Whether to report for each container per-device blkio (8:0, 8:1...) and # ## network (eth0, eth1, ...) stats or not perdevice = true # # ## Whether to report for each container total blkio and network stats or not total = false # # ## Which environment variables should we use as a tag # ##tag_env = ["JAVA_HOME", "HEAP_SIZE"] # # ## docker labels to include and exclude as tags. Globs accepted. # ## Note that an empty array for both will include all labels as tags docker_label_include = [] docker_label_exclude = [] # # ## Optional TLS Config # # tls_ca = "/etc/telegraf/ca.pem" # # tls_cert = "/etc/telegraf/cert.pem" # # tls_key = "/etc/telegraf/key.pem" # ## Use TLS but skip chain & host verification # # insecure_skip_verify = false Une étape supplémentaire est nécessaire, il faut qu'on donne accès au fichier docker.sock en lecture seule à Telegraf, il suffit pour cela de rajouter dans le fichier docker-compose de Telegraf le volume suivant : - /var/run/docker.sock:/var/run/docker.sock:ro On relance le conteneur, en SSH via la commande suivante : docker restart telegraf 11. Supervision de Raspi OS (ou tout autre distribution Linux) Dans mon cas, j'ai choisi de continuer à utiliser l'instance InfluxDB du NAS et avoir une instance de Telegraf sur le Raspberry Pi, pourquoi ? Vous aurez pu remarquer qu'InfluxDB est friand de mémoire vive. Donc autant limiter la charge sur le Raspberry Pi, dont les performances sont généralement en deçà d'un modèle de NAS "+". 11-A. Docker ATTENTION : Si vous n'avez pas activé l'accès SSH sur votre Raspberry Pi, c'est une option à cocher sur le bureau, le service SSH est désactivé par défaut à l'installation depuis 2016, voir guide ici. Pour installer Docker sous Raspbian, on passe par le script tout-en-un. Si vous n'utilisez pas Raspbian, mais une Debian, Ubuntu, ou autre... sélectionnez votre système d'exploitation sur cette page et suivez le guide. Si vous avez une installation précédente de Docker et que vous ne seriez pas passé par cette méthode, vous risquez de vous retrouver avec des versions obsolètes du Docker Engine et donc potentiellement de Docker-compose (merci @Jeff777), veuillez donc avant tout désinstaller Docker et ses reliques en suivant ces étapes. Remarques : On n'oublie pas d'ajouter notre utilisateur au groupe docker, ça évitera par la suite de devoir utiliser "sudo" pour chaque commande liée à Docker, pour l'utilisateur "pi" par exemple : sudo usermod -aG docker pi Pour que la modification soit effective, il faut redémarrer sa session SSH. 11-B. Docker-compose Pour installer Docker-compose, on va utiliser la source la plus à jour : pip3 Toujours en SSH : sudo apt-get install -y libffi-dev libssl-dev python3 python3-pip sudo pip3 install docker-compose 11-C. Telegraf On télécharge l'image de Telegraf : docker pull telegraf Comme précédemment on va créer un dossier dans lequel stocker notre fichier telegraf.conf, personnellement j'ai utilisé le dossier /opt qui est généralement réservé aux applications tierces : sudo mkdir -p /opt/containers/telegraf On va générer le fichier originel telegraf.conf : cd /opt/containers/telegraf docker run --rm telegraf telegraf config | sudo tee telegraf.conf Une fois la configuration faite, on va créer le fichier docker-compose.yml pour Telegraf. On s'inspire du fichier docker-compose qu'on a utilisé pour le NAS, en opérant quelques modifications : version: '2.1' services: telegraf: image: telegraf container_name: telegraf hostname: raspberrypi network_mode: bridge environment: - HOST_PROC=/hostfs/proc - HOST_MOUNT_PREFIX=/hostfs ports: # Optionnel - 8125:8125 # Optionnel - 8092:8092/udp # Optionnel - 8094:8094 # Optionnel volumes: - /opt/containers/telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro - /proc:/hostfs/proc:ro - /run/udev:/run/udev:ro - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro restart: unless-stopped Remarques : - Pour plus d'info sur les variables et volumes avec "hostfs", voir : https://github.com/influxdata/telegraf/blob/master/docs/FAQ.md - On remarquera l'ajout du paramètres hostname, qui permettra de voir un nom à la place d'une suite de chiffres dans Grafana. - On remarquera également le paramètre network_mode: bridge => Ici je n'ai pas créé de réseau bridge personnalisé, mon conteneur telegraf est tout seul, il peut être donc être dans le réseau bridge par défaut. Pour l'instant on ne démarre pas le conteneur, il va falloir créer la base de données dans laquelle stocker nos informations. 11-D. Création d'une base de données dans InfluxDB Rappelez-vous, sur le NAS nous avions précisé dans le fichier telegraf.conf un nom de base de données à utiliser, ainsi que les données d'identification pour les droits d'écriture. Cette base de données avait été créée à la création du conteneur influxdb, donc il n'y avait rien eu à configurer manuellement. Ici on va stocker les données dans une base de données séparée, donc il va falloir créer un nouvel utilisateur, et une nouvelle base de données. Pour cela il faut se connecter directement dans le conteneur influxdb du NAS. Donc retour en SSH sur celui-ci. On se connecte en root et on entre la commande suivante : docker exec -it influxdb influx -username admin -password admin Remarques : docker exec -it influxdb permet la connexion au conteneur influxdb, influx c'est la commande ouvrant la base de données, si on avait écrit bash à la place on serait arrivé sur l'invite de commande propre au conteneur et on aurait pu écrire influx pour faire la même chose, mais en plus long. Vu qu'on a activé l'authentification HTTP dans notre conteneur, si on ne précise rien à la connexion, toute tentative de modification se soldera pas un échec dû à un défaut de permission. De plus, vu qu'on souhaite créer de nouveaux éléments, il faut que le compte utilisé ait les pouvoirs d'administration. Il faut donc préciser les données d'authentification administrateur au lancement de la commande influx. Ces données sont celles que l'on avait renseignées à la création du conteneur InfluxDB, dans le tutoriel on a choisi admin / admin comme username / password. Fig. 14 Connexion à InfluxDB par ligne de commande Première étape : on crée la base de données, il suffit de taper la commande suivante : CREATE DATABASE raspi_telegraf puis on sélectionne la base de données qu'on vient juste de créer : USE raspi_telegraf On crée maintenant l'utilisateur dédié au raspberry : CREATE USER raspi_telegraf WITH PASSWORD 'raspi_telegraf' Remarques : - Ne pas oublier les simples quotes autour du mot de passe. - Si on s'est trompé dans l'écriture, il est toujours possible de supprimer un utilisateur ou une base de données avec les commandes DROP USER nom_utilisateur et DROP DATABASE nom_bdd. On peut vérifier à ce stade que tout se passe bien, il suffit de taper les commandes SHOW DATABASES et SHOW USERS : Fig. 15 Listing utilisateurs et bases de données dans InfluxDB La dernière étape consiste à donner des droits à notre utilisateur raspi_telegraf sur la base de données du même nom, ce qui se fait par la commande : GRANT ALL ON raspi_telegraf TO raspi_telegraf On tape ensuite exit pour sortir de influx (gestion de la base de données). On relance ensuite le conteneur pour s'assurer que les modifications ont été prises en compte : docker restart influxdb On peut maintenant quitter la session SSH sur le NAS et revenir sur celle du Raspberry Pi. A ce stade, notre base de données est prête à l'emploi, il suffit maintenant de renseigner dans notre fichier telegraf.conf sur le Raspberry Pi les données d'exportation vers influxdb sur le NAS. On peut le faire avec la commande nano ou vi : cd /opt/containers/telegraf nano telegraf.conf ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] ## The full HTTP or UDP URL for your InfluxDB instance. ## ## Multiple URLs can be specified for a single cluster, only ONE of the ## urls will be written to each interval. # urls = ["unix:///var/run/influxdb.sock"] # urls = ["udp://127.0.0.1:8089"] # urls = ["http://127.0.0.1:8086"] urls = ["http://192.168.0.51:8086"] ## The target database for metrics; will be created as needed. ## For UDP url endpoint database needs to be configured on server side. database = "raspi_telegraf" ## The value of this tag will be used to determine the database. If this ## tag is not set the 'database' option is used as the default. database_tag = "" ## If true, no CREATE DATABASE queries will be sent. Set to true when using ## Telegraf with a user without permissions to create databases or when the ## database already exists. skip_database_creation = true ## Name of existing retention policy to write to. Empty string writes to ## the default retention policy. Only takes effect when using HTTP. retention_policy = "" ## Write consistency (clusters only), can be: "any", "one", "quorum", "all". ## Only takes effect when using HTTP. write_consistency = "any" ## Timeout for HTTP messages. timeout = "5s" ## HTTP Basic Auth username = "raspi_telegraf" password = "raspi_telegraf" Notes : - Dans urls, on doit entrer l'adresse IP locale du NAS (ou son nom NetBios), et préciser le port sur lequel InfluxDB est exposé, par défaut 8086 dans notre installation précédente. - On s'assure d'avoir exposé le port 8086 du conteneur influxdb sur le NAS (ce qui était optionnel ne l'est plus). - On pense bien à préciser le nom de la base de données dans database et les login/password de notre utlisateur dans la partie HTTP Basic Auth. - On passe skip_database_creation à true. Tout est maintenant configuré sur le Raspberry Pi, il suffit de lancer le conteneur Telegraf : docker-compose -f /opt/containers/telegraf/docker-compose.yml up -d L'argument -f permet de créer un conteneur depuis un fichier compose n'importe où, et avec un nom différent de "docker-compose.yml". Cela permet d'éviter de devoir se placer dans le dossier du fichier docker-compose.yml avant d'exécuter la commande. 11-D. Création de la source de données Direction Grafana => panneau latéral : Configuration (roue dentée) => Datasources On clique sur Add data source : Fig. 16 Configuration de la source de données InfluxDB pour les données du Raspberry Pi On valide, si tout a bien été configuré, on verra le message "Datasource is working" apparaître en vert au moment du clic. 11-D. Création d'un tableau de bord Il s'agit juste ici de vérifier que les données sont accessibles : Fig. 17 Exemple de configuration d'une requête Ici j'ai créé un graphique pour suivre l'état d'utilisation de la mémoire vive : - On notera le choix de la datasource relative au raspberry. - Dans la liste "host" vous devriez voir le nom que vous avez précisé dans le champ hostname du script de création du conteneur. Si vous avez laissé le réglage par défaut, il affichera la valeur hostname du système. MàJ : 03/05/21

1. Préambule Pi-hole est un logiciel libre permettant le blocage de publicités sur les périphériques qui l'utilisent en tant que serveur DNS. Il sert aussi à contrôler les données de télémétrie que vos appareils envoient, parfois (souvent ? ) de manière non-désirée. Vu que le blocage s'effectue au niveau de la résolution DNS, il a l'avantage de pouvoir s'appliquer à tous les types de périphériques, contrairement aux bloqueurs de navigateurs qui se limitent souvent aux ordinateurs. On va aborder ici plusieurs points : L'installation de Pi-hole via Docker Son utilisation éventuelle en tant que serveur DNS local La personnalisation du blocage suivant les périphériques Quelques commandes utiles 2. Prérequis Difficulté : facile-moyenne Vous devez disposer d'un NAS compatible Docker, vous pouvez en retrouver la liste mise à jour à cette adresse : https://www.synology.com/fr-fr/dsm/packages/Docker Au niveau des connaissances : Avoir une idée de ce qu'est Docker, voir tutoriel introductif. Savoir se connecter via SSH en root, voir tutoriel. OPTIONNEL : je conseille d'installer le paquet SynoCLI File Tools de Synocommunity disponible dans le centre de paquets. Pour ajouter le dépôt Synocommunity au centre de paquets, se référer à ce tutoriel : https://sys-advisor.com/2017/11/05/tuto-synology-comment-ajouter-le-depot-synocomunity/. Après cela, la commande nano, certes moins complète que vi, mais beaucoup plus accessible pour les non-initiés, permettra d'éditer facilement les fichiers en console. ATTENTION : SynoCLI File Tools n'est pas compatible avec DSM 7 ! Éditez via File Station, vi, WinSCP, ce que vous préférez... 3. Méthode d'installation Il existe plusieurs méthodes pour installer Pi-hole, préférentiellement je conseille toujours d'utiliser un matériel dédié type Raspberry Pi quand on en a un sous la main et sur lequel il est facile de l'installer nativement, la procédure est très simplement décrite ici : https://pi-hole.net/ Sur un NAS Synology en revanche, on préfèrera son installation dans une machine virtuelle dédiée (en utilisant le paquet Virtual Machine Manager, paquet reprenant la liste de compatibilité précédemment évoquée) ou dans un conteneur Docker. Le problème étant qu'une machine virtuelle nécessite beaucoup plus de mémoire qu'un simple conteneur, c'est intéressant si on commence à cumuler quelques services sur cette machine virtuelle. Il faut savoir que l'utilisation via Docker demande certains ajustements, et ce pour plusieurs raisons : Pi-hole utilise les ports 80 et 443, qui sont utilisés par DSM pour Webstation et Nginx (notamment le proxy inversé). Si le conteneur est en mode bridge, les requêtes DNS passant alors par l'hôte (le NAS) avant d'arriver au conteneur, vous verrez l'ensemble des requêtes provenant de l'IP passerelle du NAS dans le réseau bridge par défaut, donc 172.17.0.1. Ce qui posera très vite problème si on souhaite différencier le comportement de blocage pour sa tablette, pour sa TV, etc... (voir à la fin du tutoriel) On privilégiera donc l'utilisation d'un réseau macvlan, celui-ci a entre autres l'avantage de pouvoir donner une IP du réseau local à votre conteneur, par exemple 192.168.100.161, il est donc joignable par les périphériques de votre réseau comme n'importe quelle autre machine. Il y a cependant un écueil à l'utilisation d'un réseau macvlan : tous les conteneurs qui en font partie sont incapables de communiquer avec leur hôte par leur IP physique. Concrètement mon NAS sera incapable de joindre Pi-hole, donc sa résolution DNS sera non fonctionnelle. Pour pallier ce problème, on va créer une interface virtuelle sur le NAS. En gros si la porte est fermée, on passe par la fenêtre. C'est une manipulation très simple, qui ne survit toutefois pas à un redémarrage du NAS, on exécutera donc un script au démarrage pour recréer automatiquement cette interface. L'ensemble de cette procédure est décrite dans le tutoriel introductif, et est, par commodité, reprise dans la partie suivante. 4. Hypothèses Pour faciliter la lecture du tutoriel, on définira un certain nombre d'IP et de notations, vous devez évidemment adapter ces valeurs à votre propre installation, notamment les sous-réseaux. Les IP : de l'interface physique du NAS : 192.168.100.100 de l'interface virtuelle du NAS : 192.168.100.200 du conteneur pi-hole : 192.168.100.161 de la passerelle du réseau (votre box ou votre routeur) : 192.168.100.1 de votre serveur DNS local (si vous n'en avez pas mis en place, c'est l'IP de votre passerelle) : 192.168.100.120 Les sous-réseaux : de votre réseau local : 192.168.100.0/24 (correspond à 192.168.100.0/255.255.255.0). du réseau macvlan : 192.168.100.160/28 (correspond à une plage utilisable de 14 IP allant de 192.168.100.161 à 192.168.100.174). Les notations : macvlan-network : c'est le nom du réseau docker macvlan. mac0 : c'est le nom de l'interface virtuelle du NAS. ovs_eth0 : le nom de l'interface qui a pour IP l'IP physique de votre NAS, 192.168.100.100 dans notre exemple. Pour trouver le nom de l'interface en SSH : ifconfig | grep -B 1 192.168.100.100 C'est le nom qui apparaît à gauche de l'écran sur la première ligne : ATTENTION : ovs_eth0 est le nom de l'interface quand on a installé Virtual Machine Manager une première fois ou si on a activé Open vSwitch. 5. Installation 5-A. Création du réseau macvlan On commence par se connecter via SSH en root sur le NAS pour créer notre réseau macvlan. On va se placer dans le dossier partagé docker : cd /volume1/docker On crée un dossier "networks" et y commencer l'édition du script : mkdir networks && cd $_ nano macvlan-net.sh S'ouvre une fenêtre dans laquelle on va pouvoir rédiger notre script, en voici un canevas : docker network create -d macvlan \ --subnet=192.168.100.0/24 \ --ip-range=192.168.100.160/28 \ --gateway=192.168.100.1 \ -o parent=ovs_eth0 \ macvlan-network Notes : subnet : correspond à votre sous-réseau local. ip-range : correspond à la portion de ce sous-réseau qu'on se réserve pour le réseau macvlan, les 14 adresses IP définies dans les hypothèses. Ces 14 IP permettront d'accueillir d'autres conteneurs éventuels. Par conséquent, la plage du serveur DHCP et du réseau macvlan ne doivent absolument pas se chevaucher ! gateway : c'est notre passerelle. parent : l'interface physique à laquelle on rattache notre réseau. Ici j'ai mis ovs_eth0 car j'ai activé Open vSwitch sur mon NAS, pour savoir quel est le nom de l'interface que vous utilisez, en SSH : ifconfig | grep 192.168.100.100 -B 1 Le nom de la l'interface apparaîtra au début de la première ligne. _________________________ Pour sauvegarder les modifications effectuées, on fait CTRL+O, on valide en appuyant sur Entrée puis CTRL+X pour sortir de l'éditeur et revenir sur le prompt. On va maintenant régler les permissions : chmod 740 macvlan-net.sh Le script est prêt, on peut l'exécuter : ./macvlan-net.sh Si tout va bien, on obtient une suite de caractères, cela signifie que le réseau est créé. On peut vérifier en tapant : docker network ls Et vérifier qu'il apparaît bien dans la liste. En cas d'erreur dans la transcription, il suffit de supprimer le réseau malformé pour recommencer : docker network rm macvlan-network 5-B. Création de l'interface virtuelle On va créer un second script dans le dossier courant : nano mac0-interface.sh Le contenu du script : ip link add mac0 link ovs_eth0 type macvlan mode bridge ip addr add 192.168.100.200/32 dev mac0 ip link set dev mac0 address 5E:11:4F:AF:D6:D2 ip link set mac0 up ip route add 192.168.100.160/28 dev mac0 Notes : Concernant l'adresse MAC 5E:11:4F:AF:D6:D2 : c'est une adresse que j'ai choisie, sous les conditions suivantes : - Elle n'existe pas déjà sur mon hôte et sur mon réseau. - Elle respecte la base hexadécimale, les notations allant de 0 à F. - Le premier nombre doit être pair, ici 5E = 94 en base 10, c'est donc OK (vous pouvez utiliser ce convertisseur en ligne, ou faire vos divisions euclidiennes ). S'il est impair, vous aurez un message : RTNETLINK answers: Cannot assign requested address Merci à @bruno78 pour la précision. _________________________ On valide et on sort du fichier. On accorde les permissions : chmod 740 mac0-interface.sh On exécute le script : ./mac0-interface.sh Sauf erreur, rien n'indiquera que le script a bien fonctionné, on vérifie en tapant : ifconfig | grep -A 9 mac0 Ce qui doit donner un résultat du type : Un autre moyen de vérifier que ça a marché est de lancer Synology Assistant, l'interface virtuelle devrait dorénavant apparaître. _________________________ Comme dit plus avant, cette interface ne persiste pas au redémarrage du NAS, on va pour cela définir une tâche planifiée, il faut aller dans DSM -> Panneau de configuration -> Planificateur de tâches -> Créer -> Tâche déclenchée : Puis on valide. 5-C. Création du conteneur Pi-Hole 5-C-1. Docker-compose Maintenant que le réseau est prêt, on va utiliser Docker-compose pour créer notre conteneur. Docker-compose est une autre manière de créer un conteneur, qui possède de nombreux avantages par rapport à la ligne de commande (lisibilité et fonctionnalités) et à DSM (fonctionnalités très limitées). Docker-compose vient avec le paquet Docker de Synology, donc rien de plus à installer. On va créer un dossier pour le conteneur et s'y placer, on va également créer trois dossiers pour la persistance des données de configuration de Pi-hole. mkdir -p /volume1/docker/pi-hole && cd $_ mkdir etc-pihole etc-dnsmasq.d Ainsi, même si le conteneur est supprimé, les données sont conservées. On peut utiliser le modèle ci-joint : docker-compose.yml Ou rédiger le fichier avec nano (évitez les copier-coller depuis le forum, faites-le depuis le modèle, il ne faut jamais de tabulations dans un fichier de type YAML, que des espaces). nano docker-compose.yml Et le contenu : version: '2.1' services: pi-hole: image: pihole/pihole container_name: pi-hole hostname: pi-hole networks: macvlan-network: ipv4_address: 192.168.100.161 environment: - ADMIN_EMAIL=xxx@yyy.zzz - TZ=Europe/Paris - PIHOLE_DNS_=80.67.169.12;9.9.9.9 # IP des serveurs DNS FdN et Quad9 - DNSSEC=false - DNS_BOGUS_PRIV=true - DNS_FQDN_REQUIRED=true - DNSMASQ_LISTENING=local - INTERFACE=ovs_eth0 - REV_SERVER=true # Permet de recuperer les noms d hote des peripheriques du reseau - REV_SERVER_TARGET=192.168.100.xxx # Voir paragraphe CONDITIONAL FORWARDING - REV_SERVER_CIDR=192.168.100.0/24 # Votre sous-reseau local - REV_SERVER_DOMAIN=ndd.tld # Domaine local - TEMPERATUREUNIT=C - WEBUIBOXEDLAYOUT=boxed - ServerIP=192.168.100.161 # IP du conteneur Pi-hole - VIRTUAL_HOST=pi-hole.ndd.tld # Si on souhaite acceder a Pi-hole par un nom de domaine (proxy inverse par exemple) - WEBPASSWORD=xxxxxxxxxxxxxxxxxxxx volumes: - /volume1/docker/pi-hole/etc-pihole:/etc/pihole/ - /volume1/docker/pi-hole/etc-dnsmasq.d:/etc/dnsmasq.d/ dns: - 127.0.0.1 - 80.67.169.12 restart: unless-stopped networks: macvlan-network: external: true Notes : Il est important de respecter l'indentation (l'alignement des paramètres). Si vos serveurs publiques définis dans PIHOLE_DNS_ prennent en charge DNSSEC, vous pouvez passer cette dernière variable à true. On a défini ici 2 serveurs publics différents, pour limiter les risques d'indisponibilité (merci à @Einsteinium pour sa suggestion). Si vous n'utilisez pas de proxy inversé, il n'est pas nécessaire de définir la variable VIRTUAL_HOST. Si vous pouvez vous contenter de l'affichage des IP au lieu des noms d'hôte des périphériques, vous pouvez vous abstenir de définir les quatre variables d'environnement REV_SERVER_... (précédemment, ces variables se nommaient CONDITIONAL_FORWARDING_..., qui seront dépréciées à terme, merci à @anorec pour la remarque). Ce fichier permet de définir dès le lancement avec précision la valeur de la plupart des paramètres, pour la liste exhaustive de toutes les variables d'environnement disponibles, consultez cette page. EDIT : Dans une version antérieure du tutoriel, je montais dans un dossier var-logs, à la manière de etc-pihole et etc-dnsmasq.d, les logs de Pi-hole. Pour des questions d'uid/gid d'utilisateur et de permissions, le conteneur n'arrivait pas à démarrer car il n'avait pas les privilèges suffisants pour écrire les logs dans ce dossier. J'ai donc supprimé ce dossier, pour consulter les logs plusieurs alternatives existent : via l'interface Docker dans DSM via Portainer (c'est une interface de gestion complète de Docker, plus poussée que celle intégrée à DSM, voir tutoriel pour son installation) dans de nombreux cas, les logs donnés par les outils précédents ne sont pas assez verbeux, on peut utiliser les commandes suivantes : docker exec -it pi-hole tail -n 100 /var/log/pihole.log où pi-hole est le nom du conteneur. Pour voir précisément les requêtes effectuées. Si on veut les suivre en continu, on peut remplacer l'argument "-n" par -fn", pour sortir du suivi, il suffit de faire CTRL+C. docker exec -it pi-hole tail -n 100 /var/log/pihole-FTL.log Pour les logs systèmes, même remarque pour le suivi des logs que précédemment. Si vous souhaitez les copier sur le NAS, il existe une commande toute simple : docker cp pi-hole:/var/log/pihole-FTL.log /volume1/docker/pi-hole/ où /volume1/docker/pi-hole/ est le dossier de destination, et pi-hole le nom du conteneur (merci à @Tordux). 5-C-2. Conditional forwarding C'est une question qui revient souvent, les utilisateurs de Pi-hole n'arrivent pas à afficher les noms d'hôte des périphériques. Il faut comprendre que Pi-hole n'a connaissance que de ce qu'on lui transmet. L'option est composée de trois champs, qui seront déjà complétés par les variables d'environnement REV_SERVER_CIDR, REV_SERVER_TARGET et REV_SERVER_DOMAIN. REV_SERVER_CIDR : comme indiqué dans le fichier docker-compose ci-dessus, on y inscrit notre sous-réseau local sous notation CIDR, voir hypothèses de départ, ici ce sera 192.168.100.0/24 ATTENTION : il semblerait que seuls les sous-réseaux avec un CIDR de /8, /16, /24 et /32 soient autorisés. Si votre CIDR est situé entre ces valeurs, prenez le CIDR qui englobe votre plage d'IP. Exemple : si vous utilisez un /25, utilisez /24, si vous utilisez un /20, utilisez /16, etc... (merci à @PPJP). REV_SERVER_DOMAIN : comme indiqué c'est optionnel, c'est le domaine qu'accole automatiquement votre serveur DHCP aux noms d'hôte des périphériques du réseau local. REV_SERVER_TARGET : suivant votre installation, ça peut être plus ou moins simple, par exemple si utilisez déjà un autre serveur DNS sur votre réseau local par exemple, différents cas de figure sont à considérer : Serveur DHCP et serveur DNS local sont confondus sur le même matériel, le serveur DHCP récupère le nom d'hôte envoyé par le périphérique , et l'inscrit dans sa zone DNS. En définissant REV_SERVER_TARGET avec l'IP du serveur DHCP/DNS (étant confondus dans ce cas précis), Pi-hole affichera les noms d'hôte de l'ensemble de vos périphériques dans son tableau de bord. C'est le cas le plus fréquent, ces deux serveurs sont hébergés sur la passerelle (votre box ou routeur). Dans ce cas, vous devez mettre l'IP du serveur dhcp/dns, ou celle de la passerelle (box ou routeur) si tout y est localisé. Serveur DHCP et serveur DNS local sont distincts. Or, Pi-hole ne permet d'interroger qu'une seule IP. Dans ce cas-là vous devez faire pointer REV_SERVER_TARGET sur le serveur qui définit un nom d'hôte et un domaine pour chaque périphérique, donc a priori votre serveur DNS, mais attention, tous les périphériques pour lesquels vous n'avez pas associé d'enregistrement dans votre serveur DNS (car purement des clients par exemple, ce sont eux qui accèdent au monde, pas l'inverse, utilisation typique : vous n'auriez jamais besoin d'accéder à votre tablette, smartphone, etc...) n'auront pas de nom d'hôte attribué, et seule apparaîtra l'IP, si vous avez bien suivi c'est normal car c'est le serveur DHCP qui dispose de cette information. Il faut donc dans ce cas-là définir un nom d'hôte pour chacun des périphériques de votre réseau utilisant Pi-hole comme serveur DNS dans votre zone DNS. La troisième possibilité est d'utiliser Pi-hole comme serveur DNS local, dans ce cas-là le conditional forwarding peut être désactivé. Ce point est abordé plus loin dans le tutoriel. 5-C-3. Création du conteneur Il n'y a plus qu'à créer le conteneur, pour cela on a juste à taper : docker-compose pull && docker-compose up -d Docker va télécharger l'image, et créer le conteneur. Attendez une minute ou deux au premier lancement, Pi-hole met un peu de temps pour démarrer. On peut ensuite se rendre sur l'adresse IP du conteneur (ou le nom de domaine défini dans VIRTUAL_HOST si on a défini cette variable), si tout va bien on arrive sur la page d'accueil de Pi-hole. 5-C-4. Configuration du réseau local L'étape ultime, mais la plus importante, est de faire en sorte que votre serveur DHCP envoie à ses clients l'adresse IP de Pi-hole comme serveur DNS primaire. Bien qu'il puisse être rassurant d'envoyer comme serveur DNS secondaire l'IP d'un serveur DNS publique, pour qu'en cas d'indisponibilité de Pi-hole, la résolution DNS globale soit toujours active sur le votre réseau local, il arrive qu'un périphérique préfère s'adresser au DNS secondaire plutôt que primaire, et dans ce cas-là les requêtes n'étant accessibles que localement échoueront. Si vos périphériques ont un adressage statique directement dans leur système, pensez à leur donner comme IP de serveur DNS l'IP du conteneur Pi-hole. Pour éviter ces désagréments, on peut mettre en place un deuxième serveur Pi-hole sur un périphérique simple comme un Raspberry Pi, ou un autre NAS compatible Docker si on en possède un. Si on a un serveur DNS local préexistant, le serveur DHCP peut également envoyer son IP comme serveur DNS secondaire. 6. Résolveur local 6-A. Pi-hole + serveur DNS local + serveur DHCP Ce point n'est pas abordé dans le tutoriel, je ne trouve pas ça prudent de laisser un conteneur du NAS gérer le serveur DHCP, c'est beaucoup moins stable qu'un périphérique dédié comme un routeur, avec une installation native. Et sans DHCP, vos périphériques ne pourront non seulement pas discuter entre eux, mais pas accéder à Internet non plus. 6-B. Pi-hole + serveur DNS local Dans le cas où vous avez déjà un serveur DNS local actif sur votre NAS ou tout autre périphérique, vous pouvez placer Pi-hole en amont du serveur DNS local. Il faudra alors donner comme valeur à la variable d'environnement DNS1 l'IP de l'hôte du serveur DNS. Si vous avez une redondance de serveurs DNS local, pensez à compléter DNS2 de manière analogue. Vos périphériques interrogeront d'abord Pi-hole, qui transmettra ensuite la requête à votre serveur DNS local, lui-même transmettra aux redirecteurs que vous lui avez précisés si la requête n'est pas résoluble localement. Périphérique -> Pi-hole -> Serveur DNS local -> Serveur publique "upstream" ATTENTION : Si vous utilisez un serveur DNS sur l'hôte même (par exemple DNS Server), il faut utiliser l'IP virtuelle du NAS, pas son IP physique habituelle (merci à @anorec). 6-C. Pi-hole en tant que serveur DNS local 6-C-1. Ajout des enregistrements Depuis la version 5 de Pi-hole, il est possible d'utiliser directement Pi-hole comme résolveur DNS local. C'est extrêmement pratique si vous n'avez encore rien mis en place. ATTENTION : Pi-hole n'est pas en mesure d'être source d'autorité pour une zone publique, il faut pour cela passer par exemple par des logiciels comme BIND ou DNS Server de DSM, qui n'en est qu'une surcouche. Pour se faire on se rend sur la page d'accueil de Pi-hole, on se connecte en cliquant sur Login, on utilise le mot de passe précédemment défini dans le fichier docker-compose.yml Dans le menu latéral apparaît l'onglet Local DNS, deux sous-menus apparaissent : DNS Records et CNAME Records : Le premier permet de définir les enregistrements A pour le domaine et les périphériques de votre réseau. Le second permet de définir des alias pour les domaines précédemment définis. Une image est plus parlante qu'un long discours : Notes : Depuis mon réseau local, taper domaine1.fr dans mon navigateur m'amènera sur l'IP de ma passerelle. Si ma box ou mon routeur expose son interface sur le port 80, j'arriverai dessus. J'ai volontairement donner à domaine2.fr une IP inexistante sur le réseau témoin, Pi-hole ne vous indiquera aucune erreur, il se contente de vous indiquer la direction, même s'il y a un fossé trois mètres plus loin. C'est votre navigateur qui y sera confronté. nas.domaine1.fr pointe sur mon NAS, sur lequel par exemple j'utilise le proxy inversé embarqué. Et maintenant dans CNAME Records, je vais par exemple définir des alias pour mes périphériques et pour mon proxy inversé : Notes : La seule règle doit être que la cible de l'enregistrement CNAME (le contenu de la colonne Target) doit avoir été préalablement défini dans la partie DNS records. Le rafraichissement de la zone se faisant à chaque nouvel ajout, il faut qu'il soit valide. 6-C-2. Vérification On peut vérifier par acquis de conscience que la résolution est bien effective : docker exec -it pi-hole bash En tapant ceci on se connecte directement dans le conteneur, à la suite de quoi on réalise quelques tests de résolution DNS : nslookup domaine1.fr nslookup domaine2.fr nslookup nas.domaine1.fr nslookup bitwarden.domaine1.fr nslookup nas.fauxdomaine.fr On peut ainsi vérifier qu'un ensemble d'enregistrements existent dans notre zone locale de Pi-hole, et même d'autres qui n'existent pas pour lesquels Pi-hole devrait nous renvoyer une valeur NXDOMAIN (Non-existent domain). 7. Blocage différencié L'autre nouveauté de la version 5 de Pi-hole est la possibilité de créer des groupes de périphériques pour lesquels on peut personnaliser les listes de blocage, ou même désactiver Pi-hole complètement. Ou a contrario d'être beaucoup plus restrictif. Quelques exemples concrets : Jeux mobiles : certains jeux gratuits nécessitent de visionner des vidéos pour pouvoir continuer de jouer. Il y a des grandes chances que Pi-hole bloque ces publicités et altère en conséquence votre expérience de jeu. Il n'est pas rare qu'on souhaite contrôler strictement ce que du matériel domotique (caméra, détecteur, etc...) peut envoyer sur la toile. En ajoutant certaines listes de blocage pour cette catégorie d'équipements, on peut avoir la maîtrise des données transférées sans pour autant générer un nombre importants de faux-positifs sur les autres périphériques du réseau. C'est dans l'onglet Group Management que ça se passe, lequel comprend quatre sous-menus : Groups, Clients, Domains et Adlists. On se dirige en premier lieu dans Groups, dans lequel j'ai ajouté un groupe pour mon smartphone : Si je clique sur Enabled, la valeur passera à Disabled et Pi-hole sera désactivé pour ce groupe, les requêtes seront directement transmises au(x) redirecteur(s). Dans Clients, je peux choisir dans la liste déroulante un des périphériques vus par Pi-hole par son adresse MAC (ainsi que l'IP et éventuellement le nom d'hôte s'il en a connaissance). Il faut également choisir à quel groupe le périphérique appartient dans la cellule Group Management, et penser à appuyer sur Apply une fois le choix effectué : Dans Domains, je peux ajouter des domaines (liste blanche ou noire) manuellement (avec ou sans wildcard), ici j'utilise une chaîne regex pour autoriser certaines publicités pour un jeu installé sur mon smartphone : Dans le dernier sous-menu Adlists, je n'ai rien touché aux listes, j'ai laissé celles par défaut pour tous mes périphériques : 8. Commandes utiles Pour redémarrer le conteneur : docker restart pi-hole où pi-hole est le nom donné au conteneur. ____________________________ Pour l'arrêter et le supprimer : docker-compose -f /volume1/docker/pi-hole/docker-compose.yml down L'argument -f permettant de spécifier un fichier en dehors du dossier courant. ____________________________ Pour supprimer toutes les données de Pi-hole (pour refaire une installation propre par exemple), il suffit de supprimer les dossiers dans le dossier du conteneur : cd /volume1/docker/pi-hole docker-compose down rm -ri etc-pihole etc-dnsmasq.d var-logs ____________________________ Pour le mettre à jour et le reconstruire : cd /volume1/docker/pi-hole docker-compose pull docker-compose up -d MàJ : 24/07/2021

Monitoring de la Livebox4 avec le triplet d’outils docker InfluxDB, Telegraf et Grafana 07/03/2021 Edit : 20210330 v1.0.1 : Correction bug sur le champ ‘Protocole’ de la table (measurement) ‘LB_NATports’ (voir détail à la fin du présent TUTO). Objectif de ce tutoriel : Réaliser la collecte (via « Telegraf »), le stockage (via « InfluxDB ») et l’affichage après mise en forme (via « Grafana ») des métriques spécifiques de la Livebox4 d’Orange. Nota : Il y a de forces chances que ce tutoriel soit aussi applicable à une Livebox5 mais sans aucune garantie de ma part. Ce tutoriel s’inscrit dans le prolongement du TUTO « Monitoring NAS et Réseau » de @.Shad. et représente en quelque sorte, un complément à ce dernier qui reste et restera dans tous les cas la référence tout comme son autre TUTO « Docker : Introduction ». Je n’expliquerais donc pas plus avant certaines fonctionnalités ou paramétrages de configuration du monitoring car parfaitement et clairement décrits dans les dits tutoriels. En conséquence, il est clair que le bon fonctionnement du présent tutoriel nécessite impérativement (et c’est un préalable incontournable), que vous ayez mis en place le monitoring de votre NAS selon les dispositions et recommandations du TUTO « Monitoring NAS et Réseau ». Tous mes remerciements à @MilesTEG1 qui a très aimablement joué le jeu du bêta testeur afin de m’aider à déverminer ce tutoriel. Quelques images du résultat final : Difficulté et temps de réalisation : Pour être honnête, je dirai que c’est comme pour le « fût du canon » Autant ce sera facile et rapide (quoique …) pour des « initiés », autant cela risque d’être plus compliqué et plus long pour des « novices ». Non pas je veuille décourager ces derniers de mettre en œuvre le présent tutoriel mais il n’est pas question de faire ici une course et cela prendra pour eux le temps qu’il faut à chacun selon ses compétences et ses connaissances. Du point de vue difficulté, j’ai essayé de fournir dans ce tutoriel, un maximum d’explications du moins pour ce qui n’a pas déjà été clairement explicité par @.Shad. dans ses tutoriels sus-cités. En clair, tout est fait pour que les « novices » comprennent les opérations qu’ils réalisent et en assimilent bien les tenants et aboutissants. Ainsi je l’espère, ils pourront progresser dans la connaissance de leur NAS. Genèse du TUTO : En premier lieu, il vous faut savoir qu’Orange ne met à disposition que peu de données descriptives des « entrailles » et du fonctionnement interne de la Livebox (pour les plus curieux voir ici les sources diffusées par Orange). A priori il s’avère aussi qu’il n’existe aucune API documentée chez Orange, contrairement à la « FreeBox ». Ceci étant, on verra dans la suite de ce tutoriel, que même si la Livebox4 ne permet pas de récupérer autant d'informations que la Freebox, malgré tout, celles disponibles, sont amplement suffisantes pour notre besoin. Je vous précise aussi que j’ai fait volontairement abstraction de certaines données car je les ai jugées soit non pertinentes ou soit parce que je ne connaissais pas ou ne comprenais pas leur finalité ou encore simplement parce que je n’utilise pas certaines fonctionnalités donc vous comprendrez aisément qu’il était inutile pour moi de les superviser. Il faut également relever, que très souvent les exemples de monitoring de Livebox que l’on peut trouver de ci de là sur Internet, ne concernent que des Livebox2 ou 3 avec une connexion de type « ADSL » ou « VDSL2 ». Dans mon cas avec une Livebox4 et une connexion de type « Fibre », cela ne correspondait guère d’où une difficulté supplémentaire pour obtenir de l’information sur cette configuration. Toutefois, pour les titulaires d’une ligne avec une connexion de type « ADSL » ou « VDSL2 », la porte n’est pas complétement fermée. Ils pourront tout de même visualiser des données propres à ces types de connexion. La réalisation de panels dédiés leur incombera s’ils veulent assurer la supervision des données associées. Ceci étant, vous allez tout de même découvrir au travers de ce tutoriel un certain nombre d’informations à propos de la Livebox4 sûrement insoupçonnées jusqu’à présent, car masquées par l’interface d’administration de celle-ci. Mais autant prévenir de suite les amateurs de belles courbes de suivi d’évolution que ceux-ci (tout comme moi initialement) seront déçus et vont en rester « sur leur faim » si je puis dire. En effet, force est de constater que l’essentiel des données que l’on va recueillir, sont des données que je qualifierai de « statiques ». Non pas qu’il n’existe pas de données à caractère « dynamique », mais pour élaborer des courbes significatives, il faudrait collecter ces données avec une fréquence assez importante (a minima toutes les 30 secondes à une minute pour bien faire) ce qui : d’une part et à un tel rythme, risque fort de déstabiliser la Livebox en la sollicitant trop souvent, et d’autre part, vu le processus de collecte mis en œuvre, on génèrerait alors un trafic réseau très important qui pourrait avoir un impact non négligeable sur le fonctionnement courant du réseau local. Mais libre à vous de modifier la fréquence d’acquisition que j’ai retenue, si toutefois vous avez une bonne et réelle raison. Vous êtes prévenus, c’est vous qui voyez … Donc dans cette démarche, toute la difficulté aura été de trouver : d’abord, comment accéder (se connecter) au système interne de la Livebox, et ensuite, de savoir quelles données étaient accessibles et les quelles il était possible d’extraire à des fins de supervision. Sachez néanmoins que même si l’on arrive à identifier des données particulières à certaines fonctionnalités celles-ci ne sont pas pour autant accessibles. Orange a vraiment verrouillé la Livebox sur certains points. Lors de mes recherches sur Internet, je n’ai finalement et principalement trouvé et retenu que deux sources d’informations qui m’ont permis d’atteindre l’objectif sus-cité. En premier lieu, l'idée de base m’a été inspirée par un Shell script BASH proposé par « ItHasU » sur son blog et disponible ici : https://blog.ithasu.org/2019/01/monitoring-de-la-livebox-4-avec-grafana/. Dans ce script, « ItHasU » utilise la commande « curl » pour simuler l’accès à l’API (Application Programming Interface) JSON (JavaScript Object Notation) de la Livebox4, comme si c’était le navigateur Web lui-même qui effectuait les requêtes à la Livebox4. Bien que très « light » ce script donne au moins déjà la façon de se connecter à la Livebox4 et un très simple exemple de requête pour extraire des données. Fort de cette base, d’autres recherches m’ont alors conduit aux travaux de « Rene DEVICHI » qui lui, a exploré bien plus avant le contenu logiciel de la Livebox4. Il a ainsi découvert au travers du jeu de pistes et d’énigmes offert par Orange, que la Livebox4 disposait d’un « datamodel » (modèle de données) interne qui communique avec l'extérieur via une interface HTTP et du JSON, nommée "sysbus". Il a donc développé un script Python 3 nommé « sysbus.py » qui exploite cette interface. La mise en œuvre de ce script (en ligne de commandes dans une distribution Linux ou sous Windows) permet de contrôler une Livebox4 par programme et d'en explorer les possibilités de contrôle et d’autres informations masquées. Comme le dit son auteur, je le cite : « c'est un outil ‘ expérimental ‘ », mais qui reste suffisamment abouti à mon sens pour satisfaire notre besoin de monitoring. Ce script est disponible ici : https://pypi.org/project/sysbus/ et en français sur Github : https://github.com/rene-d/sysbus. Comme vous le constaterez l’usage de la commande « curl » pour un « non initié » n’est pas des plus simple (de par notamment sa syntaxe sous Shell script BASH) pour effectuer les requêtes vers le système interne de la Livebox4. Par contre l’usage du script « sysbus.py » facilite très largement la constitution de ces requêtes. Il permet notamment de faire de façon très simple et complètement transparente pour l’utilisateur, une requête HTTP de type « GET » sur le nom d’un objet du « datamodel ». Le JSON retourné décrit alors le modèle lié à cet objet. Autre avantage et intérêt du script « sysbus.py » est qu’il est capable de rendre plus lisible le retour en détectant les fonctions, les paramètres et les instances d'objet interrogé. Ensuite, le décodage, basé uniquement sur l'observation, est peut-être incomplet selon l’auteur mais à mon humble avis il permet déjà d’avoir une bonne idée de l’objet et des données qu’il manipule ce qui me paraît suffisant pour notre utilisation finale. Mais ce n’est que mon avis, je vous laisse juger … C’est donc l’usage ce script « sysbus.py » qui aura été le centre de mes requêtes d’analyse du « datamodel » de la Livebox4 afin de déterminer d’une part les structures d’objets supportant les données que je souhaitais extraire et d’autre part identifier les procédures à utiliser pour ce faire. Autant vous dire que cette recherche n’a pas été au demeurant une mince affaire, compte tenu de la complexité du « datamodel » et du fait de l’inaccessibilité à certains objets. Cela dit, je vous rassure de suite, dans le présent tutoriel, on ne va pas installer de distribution Linux pour y installer et exécuter le script Python « sysbus.py » de « René DIVICHI ». Il vous faut simplement voir cet outil comme un outil d’analyse annexe du « datamodel » de la Livebox4. Les plus curieux ne manqueront pas de mettre en œuvre, j’en suis sûr ... Dans le cas présent, j’ai identifié avec cet outil à peu près toutes les requêtes pertinentes pour réaliser le présent monitoring donc le travail d’identification est déjà fait. Vous n’avez donc rien à faire à ce niveau, c’est cool non ? Toutefois, les « initiés » ayant de très bonnes connaissances en Shell script BASH pourront toujours rechercher et, à leur risques et périls, ajouter des requêtes spécifiques à leur propres besoins afin de récupérer d’autres données plus « exotiques ». Enfin un dernier point : pour votre information contrairement au monitoring du NAS qui utilise des MIB (Management Information Base) pour acquérir les données via le protocole SNMP (Simple Network Management Protocol), sachez que, et je cite encore « René DEVICHI », les MIBs Orange, qui semblent apparemment proches des MIB SNMP, sans toutefois en être, sont en fait des MIB propriétaires et sont inaccessibles en SNMP. Ce qui explique le présent changement de méthode d’acquisition via le module « telegraf » et qui va être détaillé ci-après. Je vous livre donc ci-après la méthode que j'ai suivie pour réaliser le monitoring/la supervision de ma Livebox 4. J’ai essayé de la rendre aussi détaillée que possible. En fait elle est conçue pour « les nuls » , mais pas que ... Principe de réalisation : Sur la base du monitoring du NAS, on va créer une seconde instance du module « telegraf » nommée « telegraf_lb4 » qui aura la charge de collecter les données de la Livebox4. Pour ce faire, ce module « telegraf_lb4 » via un plugin d’entrée spécifique, exécutera périodiquement un Shell script BASH nommé « livebox4.sh » qui lui interrogera la Livebox4 pour en extraire les données qu’il mettra en forme pour ensuite les transmettre au plugin de sortie du module « telegraf_lb4 » qui lui se chargera de les écrire dans une nouvelle base de données « Influxdb » dédiée, elle-même nommée : « livebox4_db ». Enfin, le module « grafana » exploitera cette base de données « livebox4_db » comme source de données pour les requêtes qui alimenteront dans un « Dashboard » les différents « panels » (un par thème/collection de données) de visualisation de ces données. Voilà pour le discours préliminaire, on passe maintenant aux choses sérieuses … 1 Pré-requis Disposer d’un monitoring du NAS avec le triplet de conteneurs docker « Infludb », « telegraf » et « grafana » opérationnels et actifs sur un réseau de type bridge externe. Pour mémoire, le réseau bridge externe en question a les caractéristiques suivantes : - Nom : « monitoring » - Sous réseau d’adresses IP (@IP) en 172.20.0.0 et CIDR = 28 (soit 172.20.0.0/28) - Masque de s/réseau : 255.255.255.240 - Plage d’@IP disponibles : 172.20.0.1 à 172.20.0.14 (soit 14 machines) - Passerelle du s/réseau ayant l’@IP : 172.20.0.1 (ce qui correspond normalement à votre NAS) - @IP de diffusion/broadcast : 172.20.0.15 Nota : Selon vos besoins vous pouvez réduire le nombre de machines sur ce réseau à 6 avec un CIDR = 29 De même, libre à vous d’utiliser d’autres @IP réseau, tant que vous êtes cohérents avec les choix faits précédemment pour le monitoring du NAS. Sur ce sous-réseau « monitoring » les @IP des conteneurs docker « Infludb », « telegraf » et « grafana » sont telles que : Influxdb : @IP 172.20.0.2, @MAC d2:ca:ab:cd:00:02 telegraf : @IP 172.20.0.3, @MAC d2:ca:ab:cd:00:03 grafana : @IP 172.20.0.4, @MAC d2:ca:ab:cd:00:04 · ⚠ Pour des problèmes de compatibilité, le conteneur « Influxdb » doit avoir été créé impérativement à partir d’une image en version 1.8. Ne pas utiliser la version dite « latest » qui correspond à la date de rédaction du présent tutoriel à la version 2.0.4 et qui dans tous les cas est incompatible avec l’organisation actuelle du monitoring. 2 Organisation des répertoires Comme préconisé dans le TUTO « Monitoring NAS et Réseau » on va définir une arborescence d’accueil pour le stockage du script d’installation de l’instance « telegraf_lb4 » et du Shell script BASH « livebox4.sh » ainsi que des sous-répertoires destinés à stocker les données extraites et les fichiers log de journalisation. Sous Windows ouvrez une session SSH sur le NAS (en tant qu’utilisateur « root ») avec « PuTTY » ou « WinSCP ». Sous Mac ouvrez une session SSH en lançant le « Terminal » puis tapez : o ssh utilisateur-admin@ipdunas (si le port n'est pas 22 alors il faut rajouter « -pXXXXX » où XXXXX = No du port personnalisé) o sudo -i (pour passer en « root »). Tapez successivement les commandes suivantes : Nota : Pour mémoire et ceci est valable pour toute la suite : le symbole « $ » présent en début des lignes de commandes Shell présentées ici, est ce qu’on appelle l’invite de commande du Shell. Dans le cas présent, il est propre à l’outil « WinSCP » que j’ai utilisé pour exécuter les différentes commandes Shell de cette procédure. Si vous utilisez « PuTTY » ce sera le symbole « # ». Bien évidemment, il ne faut pas le sélectionner si vous faites des Copier/Coller du texte de ces commandes. Je préfère prévenir même si c’est évident pour certains initiés … o On crée le répertoire du conteneur « telegraph_lb4 » : $ cd /volume1 $ mkdir -p docker/telegraf_lb4 o Comme je préfère séparer les genres, tous les scripts d’installation de mes conteneurs docker sont stockés dans un répertoire dédié à chaque conteneur eux-mêmes regroupés dans un répertoire nommé « scripts_instal » lequel est situé dans le dossier « /volume1/docker ». Mais libre à vous d’utiliser une autre organisation, du moment que vous vous y retrouvez et que vous restez cohérents dans la suite de ce tutoriel … On crée le répertoire du fichier d’installation du conteneur « telegraph_lb4 » : $ cd /volume1/docker/ $ mkdir -p scripts_instal/telegraf_lb4 o On crée le répertoire d’installation du Shell script BASH « livebox4 » et on s’y place : $ mkdir -p docker/livebox4 $ cd /volume1/docker/livebox4 o On crée les sous-répertoires de données et des fichiers log de journalisation : Nota : Ne les créez pas ailleurs ! Le Shell script « livebox4 » s’attend à les trouver à son niveau. $ mkdir -p data $ mkdir -p data_json $ mkdir -p log NE PAS quitter la session SSH 3 Création de l’instance « telegraf_lb4 » 3.1 Création du fichier de configuration « telegraf.conf » Avant de créer le conteneur docker proprement dit de l’instance « telegraf_lb4 », on va donc commencer ici par créer le fichier de configuration « telegraf.conf » que cette dernière utilisera. Je vous renvoie au TUTO « Monitoring NAS et Réseau » pour créer une version générique par défaut de ce fichier « telegraf.conf ». Une fois cela fait, on va « élaguer » très largement ce fichier pour ne conserver que la partie utile et que l’on va aussi adapter à notre besoin. Au final, on aura un fichier qui ressemble à celui ci-après, au détail près de quelques particularités propres à votre environnement effectif. Vous trouverez aussi ci-joint un fichier : telegraf.conf préconfiguré que vous adapterez éventuellement selon vos convenances personnelles. Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Soit vous ouvrez la version générique du fichier « telegraf.conf » et vous supprimez tout ce qui n’est pas utile de façon à obtenir quelque chose qui ressemble au texte ci-dessous. Soit plus simplement, vous ouvrez la version du fichier « telegraf.conf » ci-jointe et vous l’éditez. Ou encore vous créez un nouveau document au format texte et vous Copiez/Collez le texte ci-dessous dans ce document : Nota : Si d’aventure vous ajoutez des commentaires dans ce fichier pour votre convenance personnelle, veillez à ne pas saisir de caractères accentués. En effet leur présence perturbe l’outil d’analyse (« parser ») du module « telegraf » et génère des erreurs d’exécution dont il est ensuite très difficile d’en identifier la cause (à savoir ces caractères accentués). Vous êtes donc prévenus … # Telegraf Configuration # # Use 'telegraf -config telegraf.conf -test' to see what metrics a config # file would generate. # # Environment variables can be used anywhere in this config file, simply surround # them with ${}. For strings the variable must be within quotes (ie, "${STR_VAR}"), # for numbers and booleans they should be plain (ie, ${INT_VAR}, ${BOOL_VAR}) # Global tags can be specified here in key="value" format. [global_tags] # dc = "us-east-1" # will tag all metrics with dc=us-east-1 # rack = "1a" ## Environment variables can be used as tags, and throughout the config file # user = "$USER" # Configuration for telegraf agent [agent] # Pour test les donnees sont recoltees toutes les heures (3600s), puis en exploitation toutes les 12 heures (43200s) # ---- Vpd interval = "10s" interval = "43200s" round_interval = true metric_batch_size = 1000 metric_buffer_limit = 10000 collection_jitter = "0s" # ---- Vpd flush_interval = "10s" flush_interval = "60s" flush_jitter = "0s" precision = "" # Run telegraf with debug log messages # ---- Vpd debug = false debug = true # Run telegraf in quiet mode (error log messages only) # quiet = false # logtarget = "file" # Specify the log file name. The empty string means to log to stderr. # logfile = "" # logfile_rotation_interval = "15d" # VpD "0d" # logfile_rotation_max_size = "100MB" # VpD "0MB" # logfile_rotation_max_archives = 5 hostname = "" omit_hostname = false ############################################################################### # OUTPUT PLUGINS # ############################################################################### # Configuration for sending metrics to InfluxDB [[outputs.influxdb]] # urls = ["http://influxdb:8086"] urls = ["http://172.20.0.2:8086"] database = "livebox4_db" database_tag = "" # exclude_database_tag = false skip_database_creation = true retention_policy = "" # retention_policy_tag = "" # exclude_retention_policy_tag = false write_consistency = "any" timeout = "5s" username = "livebox4" password = "livebox4" content_encoding = "gzip" ############################################################################### # INPUT PLUGINS # ############################################################################### # Read metrics from one or more commands that can output to stdout [[inputs.exec]] # Commands array commands = [ "/bin/bash /opt/livebox4/livebox4.sh" ] # # Timeout for each command to complete. timeout = "60s" # # measurement name suffix (for separating different commands) name_suffix = "" # # Data format to consume. # Each data format has its own unique set of configuration options, read # more about them here: # https://github.com/influxdata/telegraf/blob/master/docs/DATA_FORMATS_INPUT.md data_format = "influx" ############################################################################### # SERVICE INPUT PLUGINS # ############################################################################### Dans ce fichier « telegraf.conf » quelques champs remarquables nécessitent un paramétrage spécifique : Dans la section « [agent] » : o Le champ « interval » (qui définit l’intervalle de temps entre deux récoltes de données et dont la valeur par défaut est « 10s ») sera fixé à 43200 secondes soit 12 heures. Vous le constatez, avec cette nouvelle valeur, on est aux antipodes du fonctionnement traditionnel d’une instance « telegraf » en termes de fréquence d’acquisition de données … Vous pouvez bien entendu modifier à votre guise cette valeur mais comme expliqué plus haut, vu que l’on a affaire à des données essentiellement « statiques » ces dernières n’évoluent donc que ponctuellement dans le temps voire pour certaines pas du tout. En conséquence, il ne me paraît pas utile de réduire la fréquence d’acquisition en deçà. Au contraire, peut-être même qu’un relevé journalier serait finalement suffisant. Mais c’est vous qui voyez … o Le champ « flush_interval » (qui définit l’intervalle de temps entre deux « vidage » des données de sorties) sera fixé à 60 secondes. Par défaut, ce champ est fixé à « 10s » mais à l’usage j’ai constaté que cette valeur était insuffisante. En effet, elle avait pour conséquences de tronquer une partie des données extraites du fait (c’est du moins le constat et l’analyse que j’ai pu faire mais j’ai pu me tromper …) que le Shell script « livebox4.sh » à la date de rédaction du présent tutoriel, met environ entre 15 et 20 secondes pour s’exécuter dans mon environnement (mémoire, puissance processeur du NAS, etc…). D’où ce choix (arbitraire certes, mais potentiellement ajustable) de 60 secondes dans mon cas particulier. Je vous laisse voir selon votre environnement s’il sera nécessaire/judicieux ou pas d’augmenter ou encore réduire cette valeur. o Le champ « debug » (valeur par défaut = « false ») est lui passé à la valeur « true » afin d’activer/augmenter le niveau de verbosité, ce qui est bien utile pour identifier l’origine d’un éventuel problème. Dans la section « [outputs.influxdb] » : o Le champ « urls » est définit avec la valeur « ["http://172.20.0.2:8086"] ». Il est clair que l’@IP 172.20.0.2 est celle du conteneur « influxdb » existant et défini pour le monitoring du NAS. À noter qu’il n'est pas possible d’utiliser l’URL suivante : « ["http://influxdb:8086"] ». En effet, dans son environnement d'exécution, le conteneur « telegraf_lb4 » ne "voit" pas le conteneur « InfluxDB » quand on utilise son nom. Il faut impérativement passer par son @IP. Nota : Dans cette URL, « influxdb » est le nom attribué au conteneur « InfluxDB » qui a été créé précédemment pour le monitoring du NAS. o Le champ « database » est défini avec le nom de la base de données spécifique « livebox4_db » que l’on va créer plus loin et donc utiliser pour notre monitoring. o Les champs « username » et « password » sont définis avec vos propres valeurs (attention : n’utilisez pas de caractères exotiques !). Ici par défaut pour les besoins du tutoriel c’est simplement « livebox4 » et respectivement « livebox4 ». o Le champ « content_encoding » avec la valeur "gzip" est un ajout inspiré des recommandations Influxdb (best practices) afin d’accélérer les écritures lors du chargement des données dans la base de données. Dans la section « [inputs.exec] » : Avec l’usage de cette section spécifique, réside toute « l’astuce », en quelque sorte, pour collecter les données extraites de la Livebox4. En effet, puisqu’il n’est pas possible d’utiliser comme d’ordinaire le protocole SNMP pour collecter les données (pour mémoire : pas de MIBs SNMP existantes pour la Livebox4). On va donc utiliser ce plugin de « Telegraf » dont l’objet est de permettre d’exécuter, selon l’intervalle défini dans le champ « interval » ci-avant, un (ou des) programme(s) quelconque(s) et de récupérer les données de sortie de ce(s) programme(s) sur la sortie standard (STDOUT) qui est en général l’écran, pour les envoyer au plugin « [outputs.influxdb] » qui lui se chargera de les enregistrer dans la base de données définie précédemment dans le champ « database ». On va donc configurer cette section pour que l’instance « telegraf_lb4 » exécute périodiquement le programme en question à savoir dans notre cas, le Shell script « livebox4.sh ». o Le champ « commands » (qui énumère tous les programmes à lancer est défini avec la valeur « /bin/bash /opt/livebox4/livebox4.sh ». Cette commande utilise le Shell BASH et indique d’exécuter le programme « livebox4.sh » situé dans le répertoire « /opt/livebox4 ». Vous comprendrez plus loin pourquoi on utilise ce répertoire. ⚠ATTENTION à la syntaxe ! o Le champ « timeout » (qui définit le délai d'expiration de chaque commande pour se terminer) sera fixé à 60 secondes. Par défaut, ce champ est fixé à « 5s » mais à l’usage j’ai constaté que cette valeur était très insuffisante. En effet, elle avait aussi pour conséquences de tronquer une partie des données extraites en interrompant le Shell script « livebox4.sh » avant sa fin normale. Du coup, toutes les données n’étaient pas extraites voire non traitées. o Le champ « name_suffix » (qui ajoute un suffixe au nom des tables -- « measurement » selon la terminologie InfluxDB -- de la base de données ne sera pas renseigné – valeur = vide). Libre à vous de renseigner un suffixe quand bien même, mais comme les noms des tables sont déjà « préfixées » avec « LB_ » cela me paraît inutile de surcharger plus encore leur nom. Mais c’est vous qui voyez … o Le champ « data_format » (qui définit le format des données collectées) sera fixé à la valeur « influx ». Ce format est décrit ici en détail. Donc, sachez que les données envoyées par le Shell script « livebox4.sh » sur la sortie standard STDOUT via notamment une commande Shell « echo » seront formatées au préalable selon le protocole imposé par « InfluxDB ». Maintenant que le fichier « telegraf.conf » est correctement renseigné : Enregistrez sur votre PC/Mac, le fichier « telegraf.conf ». Pour simplifier les choses, enregistrez-le de préférence à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/telegraf_lb4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/telegraf.conf /volume1/docker/telegraf_lb4/ NE PAS quitter la session SSH 3.2 Création du fichier de déclaration du service « telegraf_lb4 » Pour faire simple et éviter de se lancer dans une suite de commandes manuelles pour écrire un script docker, on va ici constituer un fichier nommé « docker-compose » au format « yaml/yml » (YAML Ain't Markup Language). Ce fichier va nous permettre de structurer, de manière plus analytique qu’en ligne de commande, les variables, volumes, etc. donc tous les paramètres propres au conteneur « telegraf_lb4 » qui lui ne sera effectivement créé qu’au §7 ci-dessous avec l’exécution du présent fichier « docker-compose.yml ». Ce fichier à l’avantage d’être persistant après la création du conteneur, on va donc ainsi conserver tous les paramètres de personnalisation de notre image Docker associée. Au final, on aura un fichier qui ressemble à celui ci-après, au détail près de quelques particularités propres à votre environnement effectif. Vous trouverez ci-joint un fichier : docker-compose.yml préconfiguré que vous adapterez éventuellement selon vos convenances personnelles. Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Créez un nouveau document de type texte. Copiez/Collez le texte ci-dessous dans ce document : Notas : - Même avertissement à propos de la saisie de caractères accentués dans ce fichier. Cette fois, c’est l’outil d’analyse (« parser ») du module « docker» qui ne les aime pas ! Vous êtes donc encore prévenus … - Toutefois, si vous avez pris la précaution de coder votre fichier en UTF8 (voir les préférences de votre éditeur de texte), cela ne devrait pas poser de problèmes. - Je vous rappelle également que dans ce fichier les marques de ‘tabulations’ sont proscrites, l’indentation des différents éléments se fait avec des caractères ‘espace’ ou ‘blanc’ (peu importe leur nombre du moment que vous êtes cohérents !). # # Doc de Telegraf : https://docs.influxdata.com/telegraf/v1.17/ # Depot GitHub : https://github.com/influxdata/telegraf # #--- version: "2.1" services: telegraf_lb4: image: telegraf:latest container_name: telegraf_lb4 hostname: telegraf_lb4 environment: - TZ=Europe/Paris - PUID=1030 - PGID=101 labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - "/volume1/docker/telegraf_lb4/telegraf.conf:/etc/telegraf/telegraf.conf:ro" - "/volume1/docker/livebox4:/opt/livebox4/" - "/usr/bin/jq:/usr/bin/jq" mac_address: d2:ca:ab:cd:00:06 networks: monitoring: ipv4_address: 172.20.0.6 mem_limit: 256M restart: unless-stopped networks: monitoring: external: true Dans ce fichier, les champs remarquables que l’on va configurer sont : Le champ « services » : Dans ce champ il faut nommer le service que l’on va utiliser, en l’occurrence « telegraf_lb4 ». Les champs « container_name » et « hostname » : Ces champs comme leur nom l’indique, portent en toute logique le nom de notre instance « telegraf » à savoir « telegraf_lb4 ». Le champ « volumes » : Ce champ a pour finalité de « monter » des informations nécessaires pour son bon fonctionnement dans l’environnement d’exécution du conteneur « telegraf_lb4 ». C’est un peu comme quand vous montez un lecteur réseau sur votre PC pour accéder à certaines données. Pour le coup, là c’est pareil on va indiquer de mettre à la disposition du conteneur des informations externes à un endroit bien précis dans son environnement. Donc dans notre cas ces informations externes sont : Le chemin complet d’accès au fichier de configuration « telegraf.conf » qui sera monté en lecture seulement (suffixe « :ro ») dans le répertoire « /etc/telegraf/ » du conteneur « telegraf_lb4 ». Le chemin complet d’accès au Shell script « livebox4.sh » qui sera monté dans le répertoire « /opt/livebox4 » du conteneur « telegraf_lb4 ». Ce répertoire « /opt/ » est usuellement utilisé dans le monde Linux pour y installer des programmes tiers. Vous comprenez alors mieux maintenant la configuration correspondante effectuée précédemment dans le fichier « telegraf.conf » pour le champ « commands » dans la section « [inputs.exec] » . Le chemin complet au programme « jq » qui sera monté dans le même répertoire (par le nom) que celui d’origine mais dans l’environnement propre au conteneur « telegraf_lb4 ». Ce programme « jq » est un outil qui permet d’analyser un fichier de données au format « .json ». Il permet aussi notamment de rendre « lisible » humainement un fichier de données en appliquant une méthode de transformation nommée « pretty print ». Ce programme est intensivement utilisé dans le Shell script « livebox4.sh » pour manipuler les données extraites de la Livebox4. Comme, il n’est pas naturellement intégré à l'image docker "telegraf", il est donc nécessaire de le monter pour qu’il soit utilisable par le Shell script « livebox4.sh ». Le champ « network :monitoring :ipv4 address » : Ce champ a pour finalité de simplement indiquer l’@IP du conteneur « telegraf_lb4 ». A vous d’adapter sa valeur à votre environnement tout en restant bien entendu dans la plage d’@IP que vous avez fixée lors de la création du réseau bridge externe « monitoring ». Les autres champs de ce fichier n’appellent pas de commentaires particuliers, ils sont similaires à ceux de l’instance « telegraf » que vous avez créée précédemment pour le monitoring du NAS. Nota : Si vous n’utilisez pas l’outil de mise à jour automatique des images docker « watchtower », alors supprimer purement et simplement le champ « labels » et sa valeur qui apparaissent dans l’exemple ci-dessus. Donc, Modifiez ce texte selon vos besoins comme indiqué ci-avant. Enregistrez sur votre PC/Mac, le document au format « YAML » c’est-à-dire avec l’extension de fichier « .yml » en le nommant « docker-compose » (et pas autrement !) soit « docker-compose.yml ». Pour simplifier les choses, enregistrez de préférence ce fichier « docker-compose.yml » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant le commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/docker-compose.yml /volume1/docker/scripts_instal/telegraf_lb4/ NE PAS quitter la session SSH 4 Création de la base de données « livebox4_db » sous InfluxDB Par rapport au monitoring du NAS, nous allons maintenant créer une nouvelle base de données (en fait une seconde) mais qui sera spécifique aux données extraites de la Livebox4 afin d’y stocker ces dernières et cela toujours dans l’environnement « InfluxDB ». Pour ce faire, retournez dans la session SSH : Connectez-vous au conteneur « influxdb » en tapant les commandes suivantes : # cd /volume1/docker/influxdb # docker exec -it influxdb influx -username admin -password admin Vous devriez obtenir quelque chose qui ressemble à cela : # docker exec -it influxdb influx -username admin -password admin Connected to http://localhost:8086 version 1.8.4 InfluxDB shell version: 1.8.4 > Nota : le symbole de l’invite de commande est maintenant le symbole « > » prouvant que l’on est bien dans l’environnement « InfluxDB ». o Tapez successivement les commandes suivantes : Nota : Bien évidemment, vous pouvez adapter le mot de passe à la valeur de votre choix (attention à le placer entre simples cotes « ‘ »). > CREATE DATABASE livebox4_db > USE livebox4_db Using database livebox4_db > CREATE USER livebox4 WITH PASSWORD 'livebox4' > GRANT ALL ON livebox4_db TO livebox4 > SHOW DATABASES name: databases name ---- nas_telegraf _internal livebox4_db > SHOW USERS user admin ---- ----- admin true nas_telegraf false livebox4 false > exit o Redémarrez le conteneur « influxdb » afin de prendre en compte immédiatement la création de la base de données « livebox4_db » : # docker restart influxdb NE PAS quitter la session SSH 5 Configuration de « Grafana » 5.1 Création de la source de données La base de données « livebox4_db » étant définie et opérationnelle, on va maintenant procéder à la définition d’une nouvelle source de données sur l’outil « Grafana ». Rendez-vous sur l’outil « Grafana » en saisissant cette URL dans un navigateur Web : http://@IPdeVotreNAS:3000. Comme je vous l’ai indiqué au début de ce tutoriel, vous avez normalement mis en place le « Monitoring du NAS », donc pour créer une nouvelle source de données il vous suffit de cliquer dans le menu vertical de gauche sur la l’icône en forme d’engrenage « Configuration » et dans le popup qui apparaît, de sélectionner l’item « Data Sources » : Dans le nouvel écran, cliquez sur le bouton bleu « Add data source » Dans le nouvel écran, pour le groupe « Times series databases » sélectionnez « InfluxDB » et cliquez sur le bouton bleu « Select » : Dans l’écran suivant, saisissez les informations ci-après dans les champs correspondants : Name : Livebox4_InfluxDB HTTP : URL : http://influxdb:8086 Access : Serveur (default) Auth : Basic auth : cochez pour activer en bleu Basic Auth Details : User : livebox4 Password : livebox4 InfluxDB Details : Database : livebox4_db User : livebox4 Password : livebox4 HTTP Method : GET Validez en cliquant sur le bouton bleu « SAVE & TEST »et si tout est OK vous obtenez ceci : Il ne vous reste plus qu'à créer le ou les Dashboard souhaités ! 5.2 Importation du Dashbord « Livebox4 » Là pas de soucis, je vous ai maché le travail. Vous trouverez ci-joint le fichier « JSON » d’un Dashboard qui regroupe un ensemble de panels préconfigurés pour chaque domaine cité au §6.2.2 ci-dessous. Si ces panels ne vous plaisent pas, libre à vous de les modifier … Mais attention, « Grafana » n’est pas un outil très convivial pour réaliser des panels. Enfin vous verrez bien par vous-même … Le fichier « JSON » : Livebox4.json Normalement après importation du fichier « JSON » du Dashboard, vous ne devriez pas avoir besoin de reprendre chacun des panels pour préciser la source origine des données affichées. Néanmoins si aucune donnée ne s’affiche, le plus simple est d’éditer avec votre éditeur de texte préféré, le fichier « JSON » et rechercher chaque champ intitulé « datasource » et de remplacer sa valeur par le nom que vous avez donné à votre source de données. Ici c’est « Livebox4_InfluxDB ». Ensuite vous supprimez le Dashboard précédemment créé et vous en créez un nouveau en important le fichier « JSON » modifié. Pour importer ce fichier « JSON » et créer le Dashboard : Depuis la page d’accueil de « Grafana » : dans le menu vertical à gauche de l’écran, cliquez sur l’icône en forme de « + » et sélectionnez dans le popup « Import » : Dans l’écran qui s’affiche alors, cliquez sur le bouton bleu « Upload JSON File » : Une fenêtre d’explorateur de fichier s’affiche, naviguez jusqu’au fichier « Livebox4.json », et validez son importation (bouton « Ouvrir ») Un nouvel écran s’affiche avec le nom prédéfini du Dashboard. Pour le champ « Folder » sélectionnez « General » et ne modifiez pas le champ « Unique Identifier (uid) » : Enfin cliquez sur le bouton bleu « Import ». Admirez … En fait il n’y a pas grand-chose à admirer puisqu’il n’y a pas encore de données dans la base de données « livebox4_db ». Rassurez-vous cela va venir, encore un peu de patience … Tout n’est pas encore en place … 6 Création du Shell script « livebox4.sh ». Compte-tenu du titre de ce paragraphe, là aussi pas d’inquiétude à avoir, on ne va pas écrire ce Shell script ! Je ne vous ferais pas ce coup-là … Je vais simplement vous décrire ses fonctionnalités afin que vous sachiez tout ce que fait le Shell script « livebox4.sh » et ce qu’il est capable de faire, ce sera déjà pas mal … Pour commencer, sachez en premier lieu que ce Shell script est paramétrable, c’est-à-dire qu’il vous laisse la possibilité d’adapter son environnement d’exécution selon vos propres besoins. Pour cela, il a besoin d’aller chercher ses paramètres de personnalisation dans un fichier particulier au format « .json » que l’on va maintenant constituer. 6.1 Création du fichier de configuration « config.json » Le fichier de configuration « config.json » est un élément incontournable pour le bon fonctionnement du Shell script « livebox4.sh ». C’est lui qui va lui fournir les éléments nécessaires pour, par exemple, établir une connexion avec le système interne de la Livebox4. Ce fichier de configuration « config.json » comporte les paramètres suivants dont vous adapterez la valeur à votre propre environnement et/ou vos propres besoins : « host » : ce paramètre correspond à l’URL de connexion à votre Livebox4, en clair c’est l’@IP de votre Livebox4. Généralement c’est « 192.168.1.1 » mais elle peut être différente. « password » : ce paramètre est le mot de passe que vous utilisez pour vous connecter habituellement à votre Livebox4 en mode « admin » notamment lorsque vous consultez son interface d’administration. Sauf si vous l’avez modifié, ce mot de passe est constitué par défaut des huit (8) premiers caractères de la clé Wifi de votre Livebox4. « url_db » : ce paramètre est l’URL de connexion à l’instance « Influxdb ». Elle est ici de la forme : http://<@IP du conteneur InfluxDB>: 8086. À vous de renseigner la bonne valeur en cohérence avec ce que vous avez défini pour le monitoring du NAS. « db » : ce paramètre est le nom de la base de données « InfluxDB » que l’on utilise pour y stocker les données extraites. En l’occurrence sa valeur sera : « livebox4_db ». « user_db » : ce paramètre est le nom d’utilisateur qui a été défini lors de la création de la base de données et qui sera le seul à pouvoir s’y connecter et écrire dans celle-ci. Donc on lui donne la valeur : « livebox4 ». « user_pass_db » : ce paramètre est le mot de passe de l’utilisateur « livebox4 » qui a été aussi fixé lors de la création de la base de données. Par défaut on lui donne la valeur « livebox4 » sinon indiquez la valeur personnalisée que vous avez retenue pour lui. « type_cnx » : ce paramètre correspond au type de connexion dont vous bénéficiez. Trois valeurs sont possibles : « Fibre », « VDSL2 » ou « ADSL » (veillez à bien respecter la syntaxe de ces valeurs). Adaptez donc la valeur à votre type de connexion. « nb_log » : ce paramètre correspond au nombre maximum de fichiers de log de journalisation qui seront conservés. Par défaut ce nombre est fixé à 9 mais rien ne vous empêche d’augmenter ou de diminuer cette valeur. C’est vous qui voyez … Ci-joint le fichier « config.json » : config.json Donc, sur votre PC/Mac à l’aide de votre éditeur de texte préféré : Créez un nouveau document de type texte. Copiez/Collez le texte ci-dessous dans ce document : Nota : N’introduisez surtout pas de commentaires dans ce fichier, sinon rien ne marchera, le parser « jq » que j’ai évoqué précédemment, ne s’accommode pas du tout de ce type d’informations. Vous noterez également que toutes les valeurs des paramètres sont à encadrer par des guillemets « " » et que chaque ligne se termine par une virgule « , » sauf la dernière. Les accolades ouvrante et fermante marquent le début et la fin du fichier. { "host": "192.168.1.1", "password": "xxxxxxxxx", "url_db": "http://172.20.0.2:8086", "db": "livebox4_db", "user_db": "livebox4", "user_pass_db": "livebox4", "type_cnx": "Fibre", "nb_log": "9" } Modifiez ce texte selon vos besoins comme indiqué ci-avant. Enregistrez sur votre PC/Mac, le document au format JSON c’est-à-dire avec l’extension de fichier « .json » en le nommant « config » (et pas autrement !) soit « config.json ». Pour simplifier les choses, enregistrez de préférence ce fichier « config.json » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire « /volume1/docker/livebox4/ ». o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac : # cp -p /volume1/MonDossierPartage/config.json /volume1/docker/livebox4/ 6.2 A propos du Shell script « livebox4.sh » 6.2.1 Principe d’exécution Sans attendre, pour satisfaire la curiosité des utilisateurs « initiés », de façon succincte le Shell script « livebox4.sh » réalise les opérations suivantes : Vérification que le fichier de configuration est bien présent et accessible. Vérification que les répertoires de stockage des fichiers de données sont bien présents et accessibles. Vérification que les répertoires de stockage des fichiers log de journalisation sont bien présents et accessibles. Initialisation de la journalisation des logs. Récupération des informations pour la connexion à la Livebox4. Envoi des commandes d’extraction des données de la Livebox4. Sauvegarde des données extraites dans des fichiers ‘.txt’ pour consultation et « conversion » de chacun de ces fichiers en un fichier "lisible" humainement '.json'. Extraction des champs de données par thèmes : Caractéristiques générales de la Livebox4. Informations sur les utilisateurs enregistrés. Informations sur l’état de la ligne DSL (non significatif avec la fibre). Informations sur l'uptime débit et marge de bruit de la ligne DSL (non significatif avec la fibre). Informations sur le trafic temps réel de la ligne DSL (non significatif avec la fibre). Informations sur les caractéristiques de la ligne DSL (non significatif avec la fibre). Informations générales sur la partie WAN. Informations générales sur la partie DHCP WAN. Informations générales sur la partie DHCP LAN. Informations sur le réseau LO (boucle locale). Informations sur le réseau LAN Ethernet (ports eth1 à 4). Informations sur le réseau LAN Wifi. Informations sur le réseau VoIP-Téléphonie. Informations sur le journal des appels téléphoniques. Informations sur le module Fibre SFP. Informations sur le transfert NAT de ports. Informations sur les services Orange. Informations sur le service IPTV d’Orange. Informations sur le service Wifi partagé d’Orange. Informations sur les équipements périphériques connectés. Par table, formatage des champs selon le protocole « InfluxDB » et envoi sur la sortie STDOUT. Au-delà des opérations réalisées par le Shell script « livebox4.sh », il faut bien comprendre qu’il fonctionne selon deux modes que j’appellerai : « Docker » et « Shell ». En mode « Docker » : le Shell script « livebox4.sh » s’exécute dans l’environnement spécifique du conteneur « telegraf_lb4 » et il n’accepte et ne peux accepter aucune option en paramètre. Les données extraites de la Livebox4 sont reformatées et compilées au standard « InfluxDB » dans une chaîne spécifique constituante des champs extraits avec leurs valeurs à raison d’une chaîne par enregistrement pour chaque table (measurement). Cette chaîne est ensuite envoyée sur la sortie standard STDOUT grâce à une simple commande « echo ». Là, les chaines de données de chaque table sont tour à tour interceptées par la partie « [outputs.influxdb] » du module « telegraf_lb4 » qui se charge alors de les « décrypter » (i.e. les décomposer en champs) puis d’écrire les valeurs de ces champs dans la table correspondante de la base de données « livebox4_db ». Le module « grafana » se charge ensuite d’afficher les données de la base de données dans des « panels » dédiés. En mode « Shell » : le Shell script « livebox4.sh » s’exécute dans l’environnement « normal » du NAS et il peut alors accepter soit aucune option, soit une et une seule option en paramètre. o Si aucune option n’est passée au script : alors, on se retrouve dans une exécution dite « à blanc » dans le sens où les données extraites de la Livebox4, ne sont pas écrites dans la base de données. Elles sont simplement affichées à l‘écran (par la même commande « echo » sus-citée). En fait, on visualise simplement à l’écran, comme dans tout Shell, la chaine formatée au standard « InfluxDB » normalement destinée à être écrite en base de données avec le mode « Docker ». o Si une option est passée au script via la ligne de commande dans une session SSH : alors cette option peut prendre différentes valeurs. Chacune de ces valeurs donne lieu à une fonctionnalité spécifique. 6.2.2 Options du Shell script En mode d’exécution « Shell », les différentes options qui peuvent être passées en paramètre au Shell Script « livebox4.sh » sont consultables en tapant la commande : # cd /volume1/docker/livebox4 # ./livebox4.sh -h Vous obtenez à l’écran l’usage du Shell script « livebox4.sh » : USAGE : livebox4.sh [-eDhTv] | [xyz | all] -e | --exec : active le mode 'Shell' (ou 'Manuel') et ecrit les donnees extraites dans la BD InfluxDB (comme le fait le plugin 'outputs.influxdb' de telegraf) -D | --debug : active le mode debug -h | --help : affiche la presente aide d'usage -T | --trace : active le mode trace -v | --version : affiche la version du present Shell script xyz : affiche les informations extraites selon le domaine 'xyz' 'xyz' = igl ium eld fld tld iew iwd ild ilo ile irw ivt ivs sfp nat iso stv ctv iwc iec all : affiche toutes les informations extraites pour tous les domaines Option « D » et « T » : En utilisant l’une de ces deux options « Debug » ou « Trace », on est dans un mode d’exécution dit « à blanc » à l’instar de ne passer aucune option au Shell script « livebox4.sh ». Dans tous les cas, aucune donnée n’est écrite en base de données. Ces deux options permettent seulement d’obtenir des logs plus « verbeux » en cas de problème avec un mode « Trace » plus bavard que le mode « Debug » qui l’est lui aussi plus que le log normal/standard par défaut : « INFO ». Option « e » : Cette option permet de reproduire en mode « Shell » exactement la même exécution qu’en mode « Docker », le résultat en est strictement identique. C’est à dire que les données sont aussi écrites dans la base de données « livebox4_db ». Option « xyz » : Le terme « xyz » correspond en fait à un trigramme spécifique de chaque thème de données extraites. Cette option permet donc de visualiser à l’écran les données extraites de la Livebox4 pour un thème donné ou pour l’ensemble des thèmes en indiquant « xyz » ou « all » pour tout voir. Par exemple pour le trigramme « igl » correspondant aux données générales de la Livebox4, vous obtiendriez une sortie écran de ce type en tapant la commande : # cd /volume1/docker/livebox4 # ./livebox4.sh igl igl----------------DeviceInfo-------------------- SocFab = Sercomm Modele = SercommVD836_Livebox4 Produit = Livebox 4 NoSerie = AH1xxxxxxxxxxxxxx vHard = SR_LB4_A.0.7 vSoft = SR40_sip-fr-4.01.12.1_7.21.3.1 vSecours = SR40_sip-fr-3.103.16.1 vSoftAdd = g0-f-sip-fr TpsFonc = 1223548 DateDemar = 2021-02-15 13:54:40+01:00 AdrIpExt = 86.xxx.yyy.zzz Etat_LB = 1 NbReboot = 4 AdrMac = aa:bb:cc:dd:ee:ff NomUtil = fti/xxxxxxxx DMZ = 1 DMZAdresDest = 192.168.1.2 MemTotale = 959192 MemLibre = 724988 L’ensemble des trigrammes et de leurs thèmes de données associés est le suivant : igl : Caractéristiques générales de la Livebox4 ? ium : Informations sur les utilisateurs enregistrés. eld : Informations sur l’état de la ligne DSL (non significatif avec la fibre). fld : Informations sur l'uptime débit et marge de bruit de la ligne DSL (non significatif avec la fibre). tld : Informations sur le trafic temps réel et sur les caractéristiques de la ligne DSL (non significatif avec la fibre). iew : Informations générales sur la partie WAN. iwd : Informations générales sur la partie DHCP WAN. ild : Informations générales sur la partie DHCP LAN. ilo : Informations sur le réseau LO (boucle locale). ile : Informations sur le réseau LAN Ethernet (ports eth1 à 4). irw : Informations sur le réseau LAN Wifi. ivt : Informations sur le réseau VoIP-Téléphonie. ivs : Informations sur le journal des appels téléphoniques. sfp : Informations sur le module Fibre SFP. nat : Informations sur le transfert NAT de ports. iso : Informations sur les services Orange. stv : Informations sur le statut du service IPTV d’Orange. ctv : Informations sur la configuration du service IPTV d’Orange. iwc : Informations sur le service Wifi partagé d’Orange. iec : Informations sur les équipements périphériques connectés. 6.2.3 Gestion des répertoires de données « data », « data_json » et « log » Le chemin d’accès aux répertoires de données « data », « data_json » et « log » ne doit pas être modifié car ce chemin diffère selon l’environnement d’exécution du Shell script « livebox4.sh » . En mode « Shell » (ou « Manuel ») ces répertoires sont définis dans le dossier partagé « docker » et leur chemin d’accès naturel est : « /volume1/docker/livebox4/ ». En mode « Docker » via l’instruction « volumes : » du fichier « docker-compose.yml » du conteneur « telegraf_lb4 » ils sont montés dans l’environnement spécifique de ce conteneur et leur chemin d’accès est alors : « /opt/libebox4/ ». Répertoire « data » : ce répertoire est destiné au stockage des fichiers bruts des données extraites par thèmes. Les fichiers stockés dans ce répertoire sont tous nommés tel que : « Domaine.txt » où « Domaine » correspond au type des données extraites (DHCPv4Server, Wifi, Devices, VoiceService, SFP, etc…). Ils sont consultables avec n’importe quel éditeur de fichiers texte mais vous verrez rapidement qu’ils ne sont pas lisibles humainement ! Répertoire « data_json » : ce répertoire est destiné au stockage des fichiers dits « lisibles » des données extraites par thèmes. Ils sont le résultat d’une transformation de type « pretty print » des fichiers « Domaine.txt » sus-cités. C’est un répertoire que vous consulterez naturellement après avoir vu le caractère « imbuvable » de ce qu’était un fichier brut « Domaine.txt » de données du répertoire « data » précédent. À leur vue, vous pourrez vous rendre compte plus facilement de comment sont agencées les données dans le « datamodel » de la Livebox4. Les fichiers stockés dans ce répertoire sont tous nommés tel que : « jqDomaine.json » et sont consultables avec n’importe quel éditeur de fichiers texte. Répertoire « log » : ce répertoire est destiné au stockage des fichiers log de journalisation. En cours d’exploitation pour y trouverez un certain nombre de fichiers de log de journalisation des évènements se produisant durant l’exécution du Shell script « livebox4.sh ». Ce nombre de fichiers dépendra de la valeur que vous aurez fixée précédemment dans le paramètre « nb_log » dans le fichier « config.json ». Ces fichiers de log sont numérotés de 1 à ‘nb_log’ tel que « livebox4.log.n ». À chaque exécution du Shell script « livebox4.sh », une rotation automatique de ces fichiers de log est réalisée. Le fichier d’indice ‘nb_log’ est supprimé (c’est le plus ancien), le fichier d’indice ‘nb_log-1’ passe à l’indice ‘nb_log’ et ainsi de suite jusqu’à libérer le fichier d’indice 1 qui passe lui à l’indice 2. Un nouveau fichier d’indice 1 est alors créé dès le début de l’exécution du Shell script « livebox4.sh ». Ce fichier d’indice 1 sera toujours représentatif de la dernière exécution du Shell script « livebox4.sh » et donc forcément le plus récent. 6.2.4 Cas des données « binaires » ou booléennes Dans l’outil « Grafana », il n’est pas possible d’affecter une couleur à un champ en fonction de la valeur littérale de ce champ. Par exemple si vous vouliez colorer en vert un champ indiquant l’état d’un système lorsque sa valeur est par exemple « Enabled » ou « ON » et en rouge lorsque la valeur est « Disabled » ou « OFF », eh bien vous ne le pourriez pas. Par contre, l’outil « Grafana » ne permet une coloration du champ que si ce dernier a une valeur numérique. Vous pouvez alors mettre en correspondance la valeur numérique avec la couleur que vous souhaitez à l’aide de « Thresholds ». Donc, pour singulariser certaines données (champs) lors de leur affichage dans un panel afin que l’état correspondant soit mis plus en évidence, j’ai utilisé/exploité cette dernière caractéristique. Pour ce faire, lors de l’extraction des données lorsqu’un champ est de type « binaire », c’est-à-dire qu’il a au plus deux valeurs littérales du type « Enabled/Disabled » ou « On/Off », etc …, ou qu’il est de type « booléen » (true/false), j’ai mis en place dans le code, une conversion automatique de cette valeur littérale en valeur numérique du type « 0 / 1 ». Ainsi lors de la conception d’un panel qui contient ce type de champ, j’ai pu attribuer une couleur dite contextuelle (qu’elle soit de premier plan ou d’arrière-plan) selon la valeur de ce champ. Par exemple : vert pour un champ d’état qui indique que le système est « actif/en marche » et rouge quand il est « inactif/à l’arrêt ». Cerise sur le gâteau si je puis dire, afin de ne pas afficher les valeurs numériques « 0 ou 1 » résultantes de la précédente conversion et qui s’avèrent en pratique peu parlantes, j’en ai profité pour traduire au passage les valeurs initiales littérales en utilisant le système de « Mapping Values » de l’outil « Grafana » pour faire correspondre les valeurs numériques associées à ces valeurs initiales en valeurs littérales adaptées. Au final, par exemple pour un champ d’état initial à « Enable », j’ai maintenant ce même champ qui s’affiche sur fond vert avec comme libellé « Marche »et si sa valeur bascule à « Disable » alors il s’affichera sur fond rouge avec le libellé « Arrêt ». C’est quand même plus sympathique, non ? 6.3 Mise en place et test du Shell script « livebox4.sh » Vous trouverez ci-joint le fichier : livebox4.sh (v1.0.1) Téléchargez et enregistrez sur votre PC/Mac, ce fichier. Pour simplifier les choses, enregistrez de préférence ce fichier « livebox4.sh » à la racine d’un répertoire partagé de votre NAS : par exemple dans « //MonDossierPartage ». Transférez ensuite ce fichier dans le répertoire o soit par Glisser/Déposer via l’interface de l’outil « WinSCP » sur PC, o soit en tapant la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac. Retournez dans la session SSH : # cp -p /volume1/MonDossierPartage/livebox4.sh /volume1/docker/livebox4/ NE PAS quitter la session SSH Maintenant que tout est en place (enfin presque tout !), on va pouvoir procéder à un premier test d’exécution du Shell script « livebox4.sh » et ce en mode « Shell ». Pour ce faire, retournez dans la session SSH : Placez-vous dans le répertoire « /volume1/docker/livebox4/ » : # cd /volume1/docker/livebox4/ Exécutez le Shell script « livebox4.sh » avec l’option « e » afin de créer un premier jeu de données dans la base de données « livebox4_db ». Pour cela, tapez la commande suivante : # ./livebox4.sh -e Normalement, après environ quinze à vingt de secondes le script sera terminé et vous ne devriez pas obtenir de message d’erreur. Consultez le fichier log de journalisation : # cd log Visualisez le fichier log « livebox4.log.1 » (normalement il est le seul suite à cette première exécution du script). o Soit en l’éditant directement depuis l’interface de « WinSCP » (c’est le plus simple), o Soit à l’aide de la commande suivante dans une fenêtre « PuTTY » sur PC ou un « Terminal » sur Mac (tapez la barre ‘espace’ pour visualiser écran/écran puis ‘q’ pour sortir) : # more livebox4.log.1 Normalement, vous ne devriez avoir que des messages de type « INFO » et tout doit être OK Sinon analysez les messages d’erreur pour trouver l’origine du problème … 7 Création et mise en service du conteneur « telegraf_lb4 » Voilà, on arrive enfin à la dernière étape de mise en place du monitoring de la Livebox4. On récapitule les opérations précédentes (profitez-en pour vous assurer que tout est conforme) : Le fichier « telegraf.conf » de configuration de l’instance « telegraf_lb4 » est créé, configuré et en place dans le répertoire « /volume1/docker/telegraf_lb4 ». Le fichier « docker-compose.yml » de déclaration de service et d’installation du conteneur « telegraf_lb4 » est créé, configuré et en place dans le répertoire « /volume1/docker/scripts_insta/telegraf_lb4l ». La base de données « livebox4_db » est créée sur « InfluxDB ». La source données « Livebox4_InfluxDB » est créée dans « Grafana ». Le Dashboard « Livebox4 » a été importé dans « Grafana ». Le fichier « config.json » de configuration du Shell script « livebox4.sh » est créé, configuré et en place dans le répertoire « /volume1/docker/livebox4 ». Le Shell script « livebox4.sh » est opérationnel et en place dans le répertoire « /volume1/docker/livebox4 ». Il ne reste plus qu’à créer le conteneur « telegraf_lb4 » pour le rendre opérationnel. Pour ce faire, retournez dans la session SSH : Placez-vous dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4 » : # cd /volume1/docker/scrips_instal/telegraf_lb4/ Lancer la création du conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose up -d Vérifier que la création du conteneur et son lancement se sont bien passés en examinant en « live » le log de l’instance « telegraf_lb4 ». Pour ce faire, tapez la commande suivante : # docker logs -f telegraf_lb4 Vous devriez obtenir quelque chose qui ressemble à ceci (tapez « CTRL + C » pour quitter) : # docker logs -f telegraf_lb4 2021-03-02T10:41:38Z I! Starting Telegraf 1.17.3 2021-03-02T10:41:38Z I! Using config file: /etc/telegraf/telegraf.conf 2021-03-02T10:41:38Z I! Loaded inputs: exec 2021-03-02T10:41:38Z I! Loaded aggregators: 2021-03-02T10:41:38Z I! Loaded processors: 2021-03-02T10:41:38Z I! Loaded outputs: influxdb 2021-03-02T10:41:38Z I! Tags enabled: host=telegraf_lb4 2021-03-02T10:41:38Z I! [agent] Config: Interval:12h0m0s, Quiet:false, Hostname:"telegraf_lb4", Flush Interval:1m0s 2021-03-02T10:41:38Z D! [agent] Initializing plugins 2021-03-02T10:41:38Z D! [agent] Connecting outputs 2021-03-02T10:41:38Z D! [agent] Attempting connection to [outputs.influxdb] 2021-03-02T10:41:38Z D! [agent] Successfully connected to outputs.influxdb 2021-03-02T10:41:38Z D! [agent] Starting service inputs 2021-03-02T10:42:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T10:43:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T10:44:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics ... Si tout se passe bien à 00:00:00 ou 12:00:00 heures vous devriez voir un message du type : ... 2021-03-02T11:59:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics 2021-03-02T12:00:38Z D! [outputs.influxdb] Wrote batch of 122 metrics in 15.870839ms 2021-03-02T12:00:38Z D! [outputs.influxdb] Buffer fullness: 0 / 10000 metrics ... Cela signifie alors qu’une exécution du Shell script « livebox4.sh » pilotée par l’instance docker « telegraf_lb4 » s’est bien déroulée et que les données extraites ont bien été écrites dans la base de données « livebox4_db ». Si vous retournez dans votre navigateur Web sur la page de « Grafana » (http://@IPdeVotreNAS:3000) et que vous rafraichissez votre Dashboard « Livebox4 », vous devriez maintenant pourvoir enfin admirer votre supervision de la Livebox4 cette fois avec des données ! Ci-joint le fichier PDF du présent tutoriel : [TUTO] Monitoring de la Livebox4_20210330.pdf Voilà c’est fini, profitez bien de votre supervision « Livebox4 »!!! Bien évidemment, je prendrai en compte toutes remarques et suggestions visant à corriger si besoin mais surtout à améliorer ce tutoriel. MERCI de vos retours ... Cordialement oracle7 EDIT : 20210330 v1.0.1 Correction bug sur le champ ‘Protocole’ de la table (measurement) ‘LB_NATpors’ Ce champ pouvant finalement prendre plusieurs valeurs (TCP/UDP) il a été nécessaire de modifier son type de « numérique » à « alphanumérique ». De fait, il est nécessaire de modifier la table (measurement) « LB_NATports ». Pour ce faire, voici ci-après la procédure à suivre : Dans une session SSH, connectez-vous au conteneur « influxdb » en tapant les commandes suivantes : # cd /volume1/docker/influxdb # docker exec -it influxdb influx -username admin -password admin > USE livebox4_db > SHOW MEASUREMENTS Vous devriez obtenir quelque chose qui ressemble à cela : name: measurements name ---- LB_DHCPv4_Serv LB_DeviceInfo LB_EquipmtConnect LB_IPTVConfig LB_IPTVStatus LB_LAN_Ethx LB_LO LB_NATports LB_SFP LB_ServicesOrange LB_Users LB_VoIP LB_VoiceService LB_WANStatus LB_WAN_DHCP LB_Wifi LB_Wificom On supprime la table « LB_NATports » pour qu’à la prochaine exécution du script « livebox4.sh » elle soit automatiquement recréée, cette fois avec le bon type (alphanumérique) pour le champ « Protocole ». > DROP MEASUREMENT LB_Natports > exit Dans le répertoire « /volume1/docker/livebox4 » remplacez le Shell script « livebox4.sh » par le nouveau (version 1.0.1 --> § 6.3). # cp -p /volume1/MonDossierPartage/livebox4.sh /volume1/docker/livebox4/ Reconstruisez le conteneur « telegraf_lb4 » afin de prendre en compte immédiatement ce nouveau fichier : Placez-vous dans le répertoire « /volume1/docker/scripts_instal/telegraf_lb4 » : # cd /volume1/docker/scrips_instal/telegraf_lb4/ Supprimez le conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose down Relancer la création du conteneur « telegraf_lb4 ». Pour cela, tapez la commande suivante : # docker-compose up -d Voilà, c’est tout. Lors de la prochaine exécution programmée du Shell script « livebox4.sh », la table « LB_NATports » sera automatiquement recréée. À partir de là, si vous créez une translation de port dans la Livebox qui utilise à la fois les protocoles UDP et TCP, l’information s’affichera correctement dans votre panel sous réserve bien entendu que vous ayez édité votre panel en conséquence. C’est à dire pour le champ « Protocole » il suffira d’ajouter en « Overrides » le « value mappings » suivant : ⚠N’oubliez pas d’enregistrer votre dashboard !

1. Préambule Ce guide a pour but de permettre à tout un chacun de centraliser la gestion de ses conteneurs sur une seule et même instance Docker, et ce de manière sécurisée. Sur une distribution Linux classique ou même Windows il est possible d'exposer une instance Docker via TCP, donc la rendre accessible sur un port de la machine hôte, 2375 en non-sécurisé, 2376 par TLS. De manière générale c'est quelque chose qu'on évite, car Docker possède des privilèges élevés sur sa machine hôte, c'est donc une source de contamination potentiellement dévastatrice. En prenant soin de placer un certain nombre de garde-fous, et en maîtrisant les points de sécurisation abordés dans les tutoriels références du forum (en premier lieu celui sur la sécurisation), l'idée devient tout à fait envisageable. Il y a deux avantages majeurs à cette méthode : - Elle est applicable à n'importe quelle machine, votre NAS, un PC sous Linux, un micro-processeur type Raspberry, un VPS, un serveur dédié, etc... - Elle permet de s'affranchir des limitations de certains OS, typiquement DSM. On peut tout à fait exposer par TCP l'instance Docker d'un NAS Syno sans passer par un proxy sauf qu'à chaque redémarrage les modifications sont effacées et il faudra de nouveau modifier la ligne de commande de démarrage du démon Docker. Un script pourrait sûrement tout à fait se charger de la tâche, reste que l'on touche à des fichiers systèmes sensibles, je suis partisan du fait de garder un DSM "stock" pour éviter des problèmes lors des mises à jour et des incompatibilités/bugs qui en découlent fréquemment. 2. Prérequis Savoir protéger ses périphériques (pare-feu) Savoir établir une connexion suffisamment sécurisée entre deux machines Savoir rediriger un port Avoir des bases concernant Docker (voir tutoriel introductif) Savoir se connecter en SSH à un périphérique Avoir défini un nom de domaine entièrement qualifié (FQDN en anglais - Fully Qualified Domain Name) pour l'instance Docker cible Difficulté : Moyenne 3. Sécurisation Pour garantir un certain degré de sécurité, l'idée va être d'exposer le socket Docker via un proxy, ce qui sera réalisé par un conteneur sur l'hôte cible, avec lequel nous établirons une connexion TLS depuis l'instance centralisatrice. Sa localisation peut être quelconque : sur le même réseau local, accessible à distance par HTTPS ou encore par VPN. Le choix de la solution et la sécurisation de l'environnement sont à votre discrétion et découlent des pré-requis stipulés ci-dessus. 4. Portainer Pour faciliter la visualisation de mes instances Docker (ou endpoint) et mes conteneurs, j'utilise l'application Portainer sur la machine qui va servir de centre névralgique pour toutes mes instances. Elle a l'avantage de fournir une interface claire, efficace et intuitive. (Notons qu'il est tout à fait possible de s'en passer et de se cantonner à de la ligne de commande, voir documentation Docker dont le lien est donné plus loin). Un fichier docker-compose.yml adapté aux NAS pour Portainer : version: '2.1' services: portainer: image: portainer/portainer container_name: portainer network_mode: bridge volumes: - /volume1/docker/portainer/data:/data - /var/run/docker.sock:/var/run/docker.sock ports: - 9000:9000 restart: unless-stopped Puis on se place dans le dossier où se trouve le fichier docker-compose.yml précédent et on tape la commande suivante : docker-compose up -d Ou on passe par lignes de commande : docker create \ --name=portainer \ --net=bridge \ --restart=unless-stopped \ -v /volume1/docker/portainer/data:/data \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9000:9000 \ portainer/portainer Puis on tape : docker start portainer Remarque : /volume1/docker/portainer/data est un emplacement adapté pour un NAS Synology, il faudra auparavant créer le dossier portainer et data dans le dossier partagé docker dans File Station. La première fois qu'on se connecte (via http://IP:9000), on est amené à choisir un login et un mot de passe admin. Ce faisant on arrive sur un écran demandant de choisir l'endpoint qu'on souhaite configurer, il faut choisir local et valider successivement les écrans. On arrive rapidement à un écran de la sorte : Je ne rentre pas dans le détail de l'utilisation de Portainer, on trouve des tutoriels relativement bien faits sur Youtube et Google, et c'est de toute façon assez simple à prendre en main : - https://www.youtube.com/watch?v=GNG6PDFxQyQ (à 1:36 on parle précisément de ce qu'on cherche à faire dans ce guide) - https://domopi.eu/ameliorer-la-gestion-de-vos-containers-docker-avec-portainer/ 5. Méthodes au choix Plusieurs méthodes sont disponibles : 5-A. Portainer-agent Avantage : - Facile et rapide à mettre en place Inconvénients : - Utilisation de certificats client/serveur auto-signés - Fonctionne uniquement avec Portainer Utilisation recommandée : réseau local ou VPN Pour le mettre en place sur le serveur distant qu'on souhaite superviser via notre instance centralisatrice, on passera par Docker-compose ou par lignes de commande. Un exemple de fichier docker-compose : version: '2.1' services: portainer-agent: image: portainer/agent container_name: portainer-agent network_mode: bridge volumes: - /var/lib/docker/volumes:/var/lib/docker/volumes - /var/run/docker.sock:/var/run/docker.sock ports: - 9001:9001 restart: unless-stopped Puis : docker-compose up -d Ou par lignes de commande : docker create \ --name=portainer-agent \ --net=bridge \ --restart=unless-stopped \ -v /var/lib/docker/volumes:/var/lib/docker/volumes \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 9001:9001 \ portainer/agent Puis : docker start portainer-agent Remarques : - On expose le port 9001 du conteneur sur le port 9001 de l'hôte (ou un autre port quelconque non utilisé). - On monte le dossier contenant les volumes Docker, dont le principe est repris dans le tutoriel introductif. Cela permettra de parcourir ces dossiers depuis l'interface Portainer, très pratique pour aller télécharger certains fichiers internes au conteneur (logs, fichiers de configuration, etc...). Dernières étapes, si la machine cliente est derrière un routeur, on pense à faire la redirection du port 9001 vers celle-ci. Et que son pare-feu autorise les connexions ce port. Rendez-vous au paragraphe 6-A pour l'ajout de notre agent dans l'interface Portainer. 5-B. Portainer Edge agent A venir. 5-C. Liaison TLS + Proxy 5-C-1. Préambule Avantage : - Sécurisé par certificat client/serveur auto-signé (mais généré par vous-même donc auto-signé). - Utilisable dans toutes les utilisations envisageables d'une liaison TLS entre un serveur et un client Inconvénients : - Plus long et difficile à mettre en place - Image docker du proxy obsolète. Utilisation recommandée : réseau local / VPN ou serveur distant Ici je vais prendre l'exemple d'un VPS OVH entrée de gamme. 5-C-2. Préparation La première étape consiste à se connecter en SSH avec l'utilisateur de notre choix sur la cible (le VPS en l'occurence pour moi) et de définir la variable HOST avec le FQDN de notre machine. Dans mon cas, j'utilise le nom de domaine que j'ai défini dans ma zone DNS OVH via un enregistrement A vers l'IP fixe de mon VPS. De manière générale, le FQDN peut être local ou externe, peu importe, car c'est un certificat auto-signé que nous allons générer pour l'atteindre, le tout étant que la résolution du FQDN soit adaptée à l'environnement (je ne peux pas utiliser vps.local si je passe par une résolution externe). Cela peut donc se faire comme moi avec un FQDN externe, si vous souhaitez gérer l'instance Docker d'un raspberry de votre réseau local, il peut s'agir de son enregistrement A correspondant dans votre serveur DNS local, ou simplement ce que vous avez renseigné dans le fichier /etc/hosts de votre instance centralisatrice. Pour l'exemple : HOST=target.ndd.tld En tapant : echo $HOST On doit obtenir le FQDN défini ci-avant. 5-C-3. Certificat serveur On va créer un dossier docker_tls dans le /home de notre utilisateur et on commence à suivre (pas bêtement, mais presque) les consignes de la documentation Docker, les étapes étant parfaitement décrites, je ménage vos touches Alt+Tab ou vous évite un torticolis si vous êtes en double écran en recopiant les étapes ici. Si vous souhaitez plus de détail sur l'explication de chaque étape, Rendez-vous sur la page. mkdir docker_tls cd docker_tls Puis on poursuit avec les commandes fournies par le guide : openssl genrsa -aes256 -out ca-key.pem 4096 openssl req -new -x509 -days 365 -key ca-key.pem -sha256 -out ca.pem openssl genrsa -out server-key.pem 4096 openssl req -subj "/CN=$HOST" -sha256 -new -key server-key.pem -out server.csr [[[ ATTENTION : Il se peut que vous obteniez l'erreur suivante : Il suffit dans ce cas-là de créer le fichier manquant : touch .rnd et de recommencer ]]] Arrive le passage le plus subtil, il va falloir définir les IP et les FQDN capables d'accéder à cette instance, ça se présente sous cette forme : echo subjectAltName = DNS:,IP: >> extfile.cnf Évidemment, il va falloir renseigner les valeurs de manière exhaustive, sous peine de devoir recommencer depuis cette étape. Ce passage permet de renforcer la sécurisation également, car tout nom de domaine (et donc IP associée) et IP non déclarés se verront refuser l'accès au socket (Connection refused sur Portainer). Il faudra au minimum ajouter $HOST (que l'hôte puisse accéder à sa propre instance, ça ne mange pas de pain), la boucle locale 127.0.0.1, et le FQDN et/ou l'IP de notre instance centralisatrice. Un exemple, où j'autorise en plus par exemple : - l'IP fixe publique de mon instance centralisatrice 51.25.152.236 (fictive) (en cas d'un problème de résolution DNS, je peux toujours y accéder) - l'enregistrement A qui lui est associé central.ndd.tld (ça peut également être mon dynhost pour les IP dynamiques) - l'IP privée de mon instance centralisatrice lorsque connectée au serveur VPN de mon VPS 10.0.0.2 echo subjectAltName = DNS:$HOST,DNS:central.ndd.tld,IP:51.25.152.236,IP:10.0.0.2,IP:127.0.0.1 >> extfile.cnf On poursuit : echo extendedKeyUsage = serverAuth >> extfile.cnf openssl x509 -req -days 365 -sha256 -in server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out server-cert.pem -extfile extfile.cnf . 5-C-4. Certificat client Par facilité, on va rester sur la machine hôte et créer les certificats et la clé privée client. openssl genrsa -out key.pem 4096 openssl req -subj '/CN=client' -new -key key.pem -out client.csr echo extendedKeyUsage = clientAuth > extfile-client.cnf openssl x509 -req -days 365 -sha256 -in client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out cert.pem -extfile extfile-client.cnf rm -v client.csr server.csr extfile.cnf extfile-client.cnf chmod -v 0400 ca-key.pem key.pem server-key.pem chmod -v 0444 ca.pem server-cert.pem cert.pem 5-C-5. Récapitulatif Si tout s'est bien déroulé, un petit ls -lt devrait donner ceci : 5-C-6. Proxy Il nous faut maintenant créer le conteneur servant de proxy, dont voici la page GitHub de l'image. Un modèle de fichier docker-compose : version: '2.1' services: docker-socket-proxy: image: sjawhar/docker-socket-proxy container_name: docker-socket-proxy network_mode: bridge volumes: - /path/to/the/server/certs:/run/secrets:ro - /var/run/docker.sock:/var/run/docker.sock:ro ports: - 2376:2376 restart: unless-stopped Puis : docker-compose up -d Ou par lignes de commande : docker create \ --name=docker-socket-proxy \ --net=bridge \ --restart=unless-stopped \ -v /path/to/the/server/certs:/run/secrets:ro \ -v /var/run/docker.sock:/var/run/docker.sock:ro \ -p 2376:2376 \ sjawhar/docker-socket-proxy Puis : docker start docker-socket-proxy Remarques : - /path/to/the/server/certs représente le dossier dans lequel vous allez placer vos certificats, cela dépend de l'OS de la machine cliente. Sur une distribution Linux classique, ça peut être dans le /home d'un utilisateur, dans /root ou partout ailleurs. Parmi les huit fichiers restants, trois nous intéressent pour ce conteneur : ca.pem, server-key.pem, server-cert.pem Ces trois fichiers doivent se trouver dans le chemin que vous aurez choisi pour /path/to/the/server/certs, pour ma part j'ai créé un sous-dossier certs dans le dossier du conteneur et je les y ai copiés. Le port 2376 est à ouvrir (et rediriger si besoin) sur la machine cible, évidemment. Et que le pare-feu de la machine, s'il y en a un, autorise les connexions sur ce port. Une fois le conteneur démarré, si tout va bien les logs du conteneur n'affichent rien, on le vérifie en tapant : docker logs docker-socket-proxy 6. Ajout de l'endpoint sur Portainer 6-A. Portainer agent On va ajouter l'agent en cliquant simplement dans Endpoints dans le menu latéral, puis + Add endpoint. On sélectionne Agent, puis on complète de cette manière : L'IP 192.168.1.50 est un exemple évidemment, on pense à préciser le port. On peut éventuellement ajouter des tags pour trier facilement les endpoints (utile si on supervise beaucoup de machines). Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. 6-B. Proxy On commence par rapatrier les trois fichiers utiles pour le client : ca.pem (le même que pour le serveur), cert.pem et key.pem. La sélection des fichiers se fera par une fenêtre de parcours, comme sur une interface graphique classique Linux ou Windows. Pour ceux que ça n'aide pas, j'ai utilisé scp et ai mis les fichiers sur mon bureau Linux (attention à la majuscule, c'est -P, pas -p) scp -P <port-SSH> ca.pem cert.pem key.pem toto@central.ndd.tld:~/Bureau Pour Windows, vous pouvez récupérer les fichiers avec WinSCP par exemple via connexion SSH. Le serveur est maintenant accessible, il ne reste plus qu'à se connecter à Portainer et ajouter l'endpoint. Dans le menu déroulant de gauche, on clique sur Endpoints, puis + Add endpoint. Puis on complète de la sorte, en adaptant évidemment à ses propres données : On notera la sélection des certificats et de la clé en bas de la page. On clique ensuite sur "Add endpoint". Si vous cliquez sur Home dans le menu latéral, vous voyez maintenant votre instance distante avec le statut Up. MàJ : 10/04/2021

1. Qu'est-ce que Docker ? Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur. On ne parle pas ici de virtualisation mais de conteneurisation, une forme plus légère, qui s'appuie sur certaines parties de la machine hôte pour son fonctionnement. En effet, une machine virtuelle nécessite son propre système d'exploitation et nécessite donc une certaine quantité de mémoire dédiée, tout cela parfois dans le but de faire tourner une seule application. Synology fournit sa propre version du moteur Docker via le centre de paquets. 2. Prérequis On peut trouver la liste des modèles compatibles sur le site de Synology. 3. Pourquoi utiliser Docker sur un NAS Synology ? DSM est un système basé sur un noyau Linux, cependant c'est un système propriétaire et si certains éditeurs de logiciels font l'effort et ont les ressources pour développer un paquet adapté, force est de reconnaître que ça reste limité. SynoCommunity fournit certains paquets très utiles, mais les paquets étant maintenus sur la base du volontariat, les mises à jour sont fréquemment en retard par rapport aux versions officielles. DSM fournit une interface relativement claire et épurée pour Docker, mais limitée pour certains cas d'utilisation. Vous pouvez a priori exécuter n'importe quelle application disponible pour une distribution Linux classique. Enfin, le point le plus intéressant, le système n'est en rien affecté et aucune dépendance n'a besoin d'être installée. Corollairement, sous réserve que le paquet Docker soit implémenté correctement par Synology, les mises à jour de DSM (même majeures) ne devraient poser aucun problème de compatibilité. 4. Aller plus loin J'ai réalisé quelques autres tutoriels sur le forum qui permettent une fois les bases acquises, de mettre en place quelques outils intéressants, que ce soit par la réflexion que ça amène ou leur finalité, souvent les deux - Mise à jour automatisée de ses images et conteneurs (en cours d'adaptation pour watchtower au lieu d'ouroboros) : https://www.nas-forum.com/forum/topic/63740-tuto-mise-à-jour-automatique-des-containers-docker/ - Centralisation de la gestion de plusieurs instances Docker : https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ - Monitoring du réseau : https://www.nas-forum.com/forum/topic/63273-tuto-monitoring-nas-et-réseau/ (pour le monitoring de la Freebox voir le tutoriel de @bruno78 : https://www.nas-forum.com/forum/topic/66394-tuto-monitorer-sa-freebox-revolution/) - Gestion de certificat SSL et proxy inversé : https://www.nas-forum.com/forum/topic/67311-tuto-certificat-ssl-reverse-proxy-via-docker/ - Installation de Pi-hole via réseau macvlan sur un NAS (ou tout autre périphérique) : https://www.nas-forum.com/forum/topic/69319-tuto-docker-macvlan-pi-hole/ 5. Comment utiliser Docker ? Nous verrons trois méthodes pour créer des conteneurs : Par l'interface intégrée à DSM via SSH par ligne de commande via SSH en utilisant docker-compose La première peut paraître séduisante mais on est vite limité dans nos possibilités, dans les faits l'utilisation de docker-compose (qui permet une sorte de mise en forme analytique de la ligne de commande) est un excellent compromis entre de la ligne de commande pure et dure et une interface graphique. Pour ceux qui tiennent absolument à avoir une interface graphique, il peut être intéressant de s'orienter vers Portainer, dont je propose un guide d'installation dans mon tutoriel sur la centralisation des instances Docker. 6. Installation de Docker et bonnes pratiques Pour installer Docker, il suffit de se rendre dans le centre de paquets et de chercher Docker dans la liste des paquets tiers, on clique sur Installer. Done ! Suite à une remarque de @oracle7, assurez-vous de ne pas avoir créé de dossier partagé "docker" en amont de son installation, cela peut amener à des erreurs dûes au fait que le dossier existe déjà. Mais avant de commencer le tutoriel et de télécharger vos premières images, un peu de contexte, pour les besoins du tutoriel j'utiliserai comme exemple Heimdall, qui est une dashboard permettant de créer des liens rapidement vers ses applications via des épingles. Docker Hub est un centre de dépôts où la qualité des images peut très fortement varier, dès lors à moins de ne pas avoir le choix, évitez les images qui ne fournissent aucune documentation. Parfois, la page Docker Hub d'une image ne fournit pas beaucoup d'information, vous trouverez généralement plus d'informations concernant la dite image sur GitHub (page GitHub / page DockerHub). En cas de difficulté pour créer un conteneur fonctionnel, il est toujours intéressant d'aller consulter les pages relatives au support (généralement appelé "wiki" et dont le lien est rapidement donné dans le Readme, ou la page liée aux soucis techniques sur GitHub (https://github.com/linuxserver/Heimdall/issues). Il n'est pas toujours plus simple d'utiliser la version conteneurisée d'une application que sa version native (paquet DSM ou paquet Linux classique). Si pour X ou Y raisons il existe des incompatibilités avec un NAS Synology, s'il y a des problèmes de droit d'écriture (ça représente une bonne partie des difficultés qu'on peut rencontrer avec Docker sur un NAS), si les difficultés sont trop nombreuses, si la documentation fait cruellement défaut, ou encore que l'image est à l'abandon, je vous conseille d'opter pour une machine virtuelle et réaliser une installation classique. Ou déporter l'ensemble sur un Raspberry Pi par exemple. C'est du temps gagné et des cheveux épargnés. 7. Interface de Docker dans DSM On clique sur Docker pour arriver sur cette interface : On peut voir l'utilisation globale du processeur et de la mémoire, ainsi que l'utilisation des ressources pour chaque conteneur créé. Dans l'onglet Conteneur, on peut venir éditer nos différents conteneurs : les arrêter et les démarrer (interrupteur à droite), les modifier, les supprimer, etc... L'onglet Registre est celui qui permet de télécharger les images des applications qui nous intéressent. Ce sont les images que l'on trouve dans le dépôt publique d'images Docker, disponible ici, il peut être intéressant d'y faire un tour. L'onglet Image liste les images qu'on a téléchargées sur le NAS et la taille qu'elles occupent dans l'espace de stockage dédié : L'onglet Réseau définit les réseaux (ou interfaces) sur lesquels nos conteneurs seront actifs. L'onglet Journal est un fichier log des différentes actions réalisées (création et suppression de conteneurs, téléchargement d'images, etc...) 7-A. Chronologie La logique est la suivante : On télécharge l'image d'une application qui nous intéresse. Cette image correspond à notre application, qu'on va adapter à nos besoins en 2). On crée un conteneur basé sur cette image en personnalisant les données à notre utilisation : les variables (un login/mdp, l'utilisateur du NAS qui va exécuter l'application, un fuseau horaire, etc...), les ports (comment on y accède), les volumes (souhaite-t-on stocker des données de manière persistante? par défaut, Docker supprime les données lorsqu'un conteneur est arrêté ou supprimé), les réseaux (liés à l'accessibilité et à la communication), etc... On démarre le conteneur. 7-B. Exemple 7-B-1. Image Je reprends l'exemple de l'image linuxserver/heimdall : le terme à gauche est le nom de l'éditeur de l'image, à droite le nom de l'application. Par défaut, toutes les images qu'on peut rechercher dans l'interface Docker de DSM correspondent aux images hébergées sur Docker Hub. Il est possible d'ajouter des registres supplémentaires (GitLab et d'autres). Il suffit de cliquer sur Paramètres puis Ajouter. Dans 99% des cas Docker Hub est la seule source dont vous avez besoin. Pour notre image en question, on trouve différentes informations : Le tag latest correspond à la dernière version stable en date, development parle d'elle-même, vous pouvez également avoir des numéros de version spécifique, si vous ne souhaitez sur une version bien précise de l'image. La plupart du temps, c'est la version latest qui nous intéressera. Par convention (respectée dans l'immense majorité), si le tag n'est pas précisé, on parle de la version latest. On retourne dans l'onglet Registre, et on double-clique sur l'image une fois trouvée via le champ de recherche : On sélectionne le tag latest. L'image se télécharge, on peut voir l'avancement dans l'onglet Image, à droite la taille que l'image occupe sur votre NAS : L'image est téléchargée, on va maintenant pouvoir créer le conteneur. 7-B-2. Paramétrage du Conteneur On va donc créer notre conteneur, ce sera la version exécutée de notre image. Pour en créer un, il suffit de double-cliquer sur l'image qu'on a fini de télécharger : Un nom nous est proposé par défaut, on peut évidemment le modifier pour quelque chose de plus simple. On laisse décocher Exécuter le conteneur à l'aide de privilèges élevés car cela revient à donner un accès root au conteneur, sauf cas très précis c'est déconseillé. C'est une des rares options dans Docker qui peut compromettre l'intégrité de votre NAS si mal utilisée. Si un tutoriel demande à cocher cette option, prenez le temps de comprendre pourquoi et vous demander si c'est vraiment utile. On peut limiter la quantité de mémoire que le conteneur utilisera pour s'exécuter. On clique ensuite sur Paramètres avancés pour poursuivre la configuration du conteneur. 7-B-2-a. Conditions d'exécution En cas d'arrêt inopportun du NAS ou du paquet Docker, on peut autoriser le redémarrage automatique, suivant l'application concernée c'est généralement un paramètre intéressant, on le coche donc. On peut créer un raccourci sur le bureau si on le souhaite. D'autres comportements que le redémarrage automatique sont disponibles mais à ma connaissance, non sélectionnables via l'interface graphique Docker de DSM. 7-B-2-b. Volumes Pour utiliser une application via Docker, les données de cette application doivent bien être écrites quelque part. Précisions : Il n'est pas possible de gérer cet aspect de Docker via l'interface de DSM, uniquement en ligne de commande ou par Docker-compose. Sans aucune précision de votre part concernant l'emplacement de ces données, elles sont écrites, sur nos NAS, dans /volume1/@docker/volumes/ (à ne pas confondre avec /volume1/docker, le premier étant un dossier "caché" dans File Station (visiblement uniquement via SSH/Telnet), le deuxième visible, accessible et créé par le paquet Docker à son installation), et sur une distribution Linux classique, /var/lib/docker/volumes/ Ces volumes, lorsqu'ils ne sont pas déclarés à la création du conteneur, sont quand même créés par Docker, mais à la suppression du conteneur, ils sont effacés. Lorsqu'on recherche la persistance des données, ces volumes ne doivent pas être effacés à la suppression du conteneur. En ce cas, trois méthodes sont possibles : - On définit un volume au moment de la création du conteneur, voir ici. Ce volume ne sera pas supprimé à la suppression du conteneur, en revanche il n'est utilisable que par le conteneur en question. - On définit un volume indépendamment d'un conteneur. Il est donc autonome des conteneurs qui l'utilisent, car en effet n'importe quel conteneur peut décider de charger son contenu en son sein à sa création. - On demande au conteneur d'utiliser des dossiers existants du NAS pour y lire ou écrire des données existantes. Ce ne sont pas des volumes Docker à proprement parler. Donc toutes les opérations disponibles via la commande docker volume ne sont pas disponibles pour ce procédé, on appelle plus généralement ces volumes des bind pour les différencier des volumes Docker. Cette troisième solution est pourtant la méthode la plus rapide pour charger des données du NAS dans nos conteneurs et c'est la méthode qu'on privilégiera par la suite. Pour illustrer ce que contient un conteneur, à l'instar de tout système d'exploitation, il est tout à fait possible d'explorer l’arborescence d'un conteneur comme on le ferait pour notre NAS ou n'importe quelle autre machine. Ci-dessous, l’arborescence à la racine du NAS (à gauche) et l'arborescence du conteneur (à droite) : Reprenons les directives du créateur de l'image : On s'intéresse aux paramètres précédés d'un -v, ici on nous dit que /config (chemin dans le conteneur, que les plus observateurs auront vu dans l'arborescence du conteneur sur l'image de droite un peu plus haut) peut être monté vers le NAS si on souhaite assurer la persistance (on le veut dans ce cas, on n'a pas envie de tout reconfigurer à chaque redémarrage du conteneur). On va donc dans l'onglet Volume : Et on clique sur Ajouter un dossier. On est alors amené à choisir le dossier dans lequel on va monter /config. Lorsqu'on installe Docker sur son NAS, un dossier partagé docker est créé, libre à vous de vous organiser de la manière qui vous conviendra le mieux. Souvent, on crée un dossier par conteneur. Je choisis mon dossier et valide : Dans la colonne Chemin d'accès, je suis venu écrire manuellement le chemin absolu du dossier dans lequel je vais monter mes données. 7-B-2-c. Réseau Pour l'accessibilité du tutoriel, je ne mentionne dans cette partie que deux types de réseau : le mode bridge (défaut) et le mode host. Le fonctionnement avancé des réseaux faisant l'objet d'une description plus exhaustive en fin de tutoriel pour ceux que ça intéresse. 7-B-2-c-1. Bridge Par défaut, le mode bridge est sélectionné. Dans ce mode, lorsqu'un conteneur est créé, il obtient une adresse IP privée libre dans le sous-réseau 172.17.0.0/16. La passerelle de ce conteneur sera toujours 172.17.0.1, qui est une des nouvelles interfaces du NAS (consécutivement à l'installation de Docker). Pour s'en assurer, connectez-vous en SSH sur votre NAS et tapez : ifconfig Vous verrez une interface docker0 avec l'IP 172.17.0.1, c'est la porte vers le monde extérieur (LAN + WAN) pour tous les conteneurs dans le réseau bridge 172.17.0.0/24 : c'est l'équivalent de votre box par rapport à Internet. En mode bridge, si les ports ne sont pas translatés de la passerelle (le NAS) vers le conteneur, le conteneur n'est pas accessible depuis votre réseau local (hormis le NAS). On a un fonctionnement similaire à un routeur auquel on dit de translater certains ports vers une machine de notre réseau pour y accéder de l'extérieur. 7-B-2-c-2. host Le mode host permet lui d'exposer directement le conteneur sur le NAS, à la manière de n'importe quel paquet Synology. En gardant l'avantage de conserver les dépendances en son sein et de ne pas impacter le système d'exploitation. Il n'y a dans ce cas aucune redirection de ports à effectuer, ils sont directement joignables sur l'IP du NAS (sous réserve que le pare-feu l'autorise). Dans l'onglet Réseau, on va donc laisser tel quel pour rester en mode bridge : Si on veut passer en mode host, il faut cocher l'option Utiliser le même réseau que Docker host. On notera en dernier lieu qu'il est possible par l'intermédiaire du "+" de créer des réseaux bridge différents de celui par défaut, on appelle ça des réseaux bridge personnalisés ou définis par l'utilisateur. Les réseaux bridge personnalisés font l'objet de remarques supplémentaires en fin de tutoriel. 7-B-2-d. Ports Si on a choisi le mode bridge, Docker liste par défaut les différents ports qu'utilise le conteneur, en proposant la valeur Auto pour le port du NAS. Si vous laissez Auto, alors un port libre aléatoire sera choisi par le système. Dans l'extrême majorité des cas, on préfère définir nous même les ports à exposer, il faut simplement s'assurer qu'ils ne sont pas déjà en cours d'utilisation par un autre service en utilisant via SSH en root la commande : sudo netstat -tulpn | grep LISTEN Autrement, DSM nous préviendra au moment de la création du conteneur que le ou les ports choisis sont déjà utilisés et la création échouera. On aurait pu garder les mêmes ports que dans le conteneur, mais dans le cas présent, 80 est le port utilisé par Web Station, et 443 est utilisé par Nginx, donc j'en ai choisi d'autres qui, eux, sont libres : NDLR : Lorsque la documentation ne précise pas le protocole du transport des données par le dit port, on parle du port TCP par défaut. NOTE : Si on a choisi le mode host, on n'a pas besoin de faire de redirection de ports 7-B-2-e. Liens Les liens permettent de connecter plusieurs conteneurs entre eux, dans la partie de gauche on choisit un autre conteneur, dans la partie de droite un alias, qui permettra de personnaliser des variables d'environnement dans le conteneur lié. Cette fonctionnalité étant dépréciée, je ne m'étendrai pas plus dessus, voir le chapitre Réseau en fin de tutoriel pour une méthode alternative. 7-B-2-f. Variables d'environnement Elles permettent de personnaliser le conteneur pour notre utilisation personnelle. Dans l'image ci-dessus, elles sont identifiées par le -e, on en identifie donc trois : PUID, PGID et TZ Dans l'onglet correspondant, je crée ces trois variables en utilisant le "+" en haut à gauche du cadre : Concernant les variables PUID et PGID, elles vont permettre de définir l'utilisateur du NAS qui exécutera le conteneur. On les retrouve par exemple, mais pas seulement, dans toutes les images Linuxserver, qui est un collectif de développeurs réalisant le portage d'applications phares vers des images Docker standardisées et surtout NAS friendly. Lorsque vous cherchez une application, je vous conseille en premier lieu d'aller jeter un oeil à la liste de leur releases, les ajouts sont fréquents et les mises à jour encore plus. Pour connaître les valeurs numériques à entrer, il faut se connecter en SSH sur le NAS, et taper : id user user étant l'utilisateur qu'on souhaite employer. On obtient plusieurs valeurs, un UID >= 1026, un GID = 100 ou plus, d'autres valeurs de GID dont on ne se servira pas ici. On fait correspondre le PUID au UID et le PGID au GID. Il faut également remplir deux autres conditions pour ne pas avoir de problème de permissions d'écriture dans nos volumes : que l'utilisateur choisi a des droits suffisants dans les dossiers partagés qui seront utilisés, dans mon cas le dossier partagé docker que l'utilisateur soit idéalement propriétaire du dossier heimdall, dans lequel j'ai décidé de monter /config du conteneur. Ces conditions sont très importantes pour que tout fonctionne sans accroc. Les NAS sont généralement assez capricieux au niveau des permissions, car les dossiers sont régis par des ACL (Access Control List), ce qui correspond à l'onglet Utilisateur et Groupe dans le panneau de configuration de DSM. On rencontre beaucoup moins de problèmes sur une distrubition Linux classique. Pour TZ, c'est une variable permettant de définir le fuseau horaire à l'intérieur du conteneur, vous pouvez trouver sur cette page une liste des valeurs à entrer suivant votre localisation. 7-B-3. Création du conteneur On valide les Paramètres avancés, et on clique sur Suivant, un dernier écran propose un récapitulatif de la configuration du conteneur, on applique. On peut vérifier dans l'onglet Conteneur que le conteneur est en cours d'exécution. Il ne reste plus qu'à aller sur notre navigateur et entrer l'adresse du NAS suivi du port HTTP qu'on a translaté depuis le conteneur vers le NAS : Et pour la version HTTPS : 7-B-4. Aperçu et Logs du conteneur Dans notre cas c'est merveilleux tout marche bien, mais il faut savoir que toutes les images ne sont pas aussi bien documentées, et qu'on n'est jamais à l'abri d'une erreur. Dans l'onglet Conteneur, si on en sélectionne un et qu'on clique sur Détail, on peut avoir un aperçu des statistiques du conteneur, et surtout les logs du conteneur dans l'onglet Journal, c'est la première chose à regarder en cas de conteneur non fonctionnel (accès impossible, redémarrage en boucle, etc...). ________________________________________ Ceci conclut la partie destinée à l'interface Docker de DSM, elle conviendra pour la majorité de vos besoins mais peut clairement révéler des insuffisances dans des cas plus poussés. 8. Docker via SSH 8-A. Analyse Un des principaux problèmes qu'on peut rencontrer avec l'interface de DSM c'est l'impossibilité de choisir des dossiers sur le NAS en dehors de /volume1, or Docker s'appuyant sur le système d'exploitation de l'hôte, il peut avoir besoin d'accéder à ses ressources. il est possible de contourner ce problème avec l'interface DSM de Docker via des liens symboliques (symlink) mais je trouve ça plus personnellement plus compliqué qu'un bête script. Par chance, pour les images comportant peu d'infos, il y a souvent a minima le script de démarrage du conteneur, exemple avec l'image utilisée ci-avant : On comprend assez vite la correspondance entre ce qu'on a fait précédemment et ce qu'on lit ici, quelques remarques tout de même : les \ permettent d'effectuer un retour à la ligne et de rendre le script présentable, il est tout à fait possible d'écrire tout à la suite. si j'écris -p 8080:80, je demande de faire correspondre le port 8080 de l'hôte avec le port 80 du conteneur, l'ordre est donc primordial. de la même manière qu'on peut mapper les ports, on peut mapper les volumes : /volume1/docker/heimdall est ici mon dossier sur le NAS, /config mon dossier dans le conteneur, j'écrirai donc ça : -v /volume1/docker/heimdall:/config on voit qu'ici il est possible de définir un autre type de comportement pour le redémarrage (celui qu'on avait validé dans l'interface correspondant à --restart always), ici on empêche le redémarrage automatique si le conteneur a été stoppé correctement. la dernière ligne reprend le nom de l'image, si aucun tag n'est précisé alors latest est implicite. il n'est pas nécessaire de télécharger l'image au préalable, au lancement du script il va aller chercher la version la plus récente du tag demandé, la re-télécharger si l'image est obsolète et enchaîner sur la création du conteneur. il faut ajouter sudo en début de commande si on n'est pas connecté en root au terminal. Cette commande permet de créer le conteneur, on doit ensuite taper : docker start heimdall pour exécuter le conteneur (pensez à ajouter sudo aux commandes docker si vous n'êtes pas connecté en root). 8-B. En détail Voyons plus en détail les possibilités pour chaque paramètre. Lorsqu'un paramètre n'est pas précisé lors de la création du conteneur, Docker regarde dans son démon, à savoir un fichier qui contient des directives à utiliser par défaut sans précision contradictoire de la part de l'utilisateur. Ce fichier se trouve à l'emplacement : /var/packages/Docker/etc/dockerd.json 8-B-1. Restart policies L'argument restart permet de définir le comportement de redémarrage du conteneur : --restart=no : C'est le comportement par défaut, le conteneur ne redémarrera pas s'il s'arrête, que ce soit proprement ou à cause d'une erreur. --restart=always : A contrario, le conteneur tente continuellement d'être redémarré, sauf s'il a été stoppé manuellement. Par contre, en cas de redémarrage du service Docker ou du NAS, le conteneur sera redémarré. --restart=unless-stopped : En cas d'erreur, le conteneur tentera de redémarrer indéfiniment. S'il est arrête manuellement, le conteneur ne sera pas relancé. En cas de redémarrage du service Docker ou du NAS, le conteneur ne sera pas redémarré. --restart=on-failure[:4] : Le conteneur ne sera redémarré qu'en cas d'arrêt pour cause d'erreur, et ce par exemple ici dans une limite de quatre fois. 8-B-2. Network L'argument network permet de définir la connectivité d'un conteneur par rapport à son environnement : --network=none : le conteneur est totalement isolé et autonome, le seul moyen d'y accéder est par terminal. --network=my-network : permet de se connecter à un réseau bridge personnalisé ou macvlan nommé my-network. Si on ne précise rien, le conteneur rejoint le réseau bridge par défaut (voir 7-B-2-c-1). 8-B-3. Ports La gestion des ports permet de rendre une application dans un conteneur accessible sur son hôte via des ports spécifiques. C'est indispensable si on souhaite accéder à un conteneur sur un réseau bridge. Un conteneur sur réseau macvlan a tous ses ports exposés sur sa propre IP, il est comme une machine à part entière sur le réseau, tous ses ports sont accessibles sur le réseau sur lequel il se trouve. 8-B-3-a. Interfaces Pour translater un port, on désigne le port sur lequel l'application est exposée dans le conteneur ainsi que le port sur l'hôte par lequel on accède à cette application. Par exemple : -p 8080:80 L'application disponible sur le port 80 dans le conteneur est translatée sur le port 8080 de l'hôte. -p 0.0.0.0:8080:80 Écrire 8080:80 revient à écrire 0.0.0.0:8080:80 0.0.0.0:8080 signifie l'application est disponible sur le port 8080 de l'hôte sur toutes ses interfaces. Que ce soit localhost (127.0.0.1 => seul l'hôte peut y accéder), l'IP local (par exemple 192.168.0.10), l'IP passerelle bridge 172.17.0.1 ou encore l'IP VPN. Je voudrais par exemple pouvoir vouloir n'accéder à une application que lorsque la requête arrive sur l'IP VPN de l'hôte : -p 10.0.8.1:8080:80 http://10.0.8.1:8080 aboutira, alors que 192.168.0.10:8080 ne donnera rien. 8-B-3-b. Protocoles Si on souhaite autoriser uniquement un protocole, il suffit de le préciser à la fin de l'argument : -p 8080:80/tcp -p 1194:1194/udp 8-B-3. Commandes utiles Assez intuitivement, pour arrêter le conteneur on tape : docker stop heimdall Pour supprimer le conteneur : docker rm heimdall Pour voir la liste des conteneurs actifs, on écrit la commande : docker ps Pour voir les logs d'un conteneur en direct, on écrit (CTRL+C pour arrêter la visualisation) : docker logs -f heimdall Pour gérer les réseaux, reportez-vous à l'aide via la commande : docker network --help Enfin, ça peut être parfois très utile, il est possible de se connecter à l'intérieur d'un conteneur, pour cela : docker exec -it heimdall bash Notes : En général, le paquet bash est présent dans la plupart des images que vous utiliserez. Parfois, si bash ne fonctionne pas, essayez ash. Si bash n'est pas disponible, rien ne vous empêche de taper directement la commande qui vous intéresse, par exemple : docker exec -it heimdall ls -la /etc Pour sortir du conteneur, tapez exit. A vous d'explorer l'ensemble des commandes à votre disposition en consultant le manuel d'aide : docker --help En dernier lieu, je vous invite à parcourir la documentation de Docker, bien que touffue elle est extrêmement claire : https://docs.docker.com/ Comme je disais au début du chapitre, le gros avantage de cette méthode est qu'elle permet de définir des chemins absolus hors /volume1 pour nos volumes. Rien ne m'empêcherait d'aller mapper /var/lib/temperature pour un dossier quelconque du conteneur. Cette possibilité est particulièrement utile quand une application va devoir utiliser le cœur de docker, le fichier /var/run/docker.sock. Ce fichier est particulièrement important, car à partir du moment où on le mappe en tant que volume vers un conteneur, on peut prendre le contrôle de Docker avec cette application. Typiquement, Portainer est une interface graphique à la manière de l'interface Docker de DSM pour gérer ses conteneurs, ses images, et toutes les infos exploitables (mais en mieux ). Avertissement !! A partir du moment où vous donnez accès à d'autres dossiers que ceux dans /volume1, le conteneur sera nécessairement lancé avec l'utilsateur root du NAS, car seul lui a accès à cette partie du système. Soyez donc attentifs aux nécessaires précautions que cela implique. 9. Docker-compose via SSH Docker-compose vient compenser les lacunes de la création de conteneur par Docker, dont voici un exemple : Les points forts de docker-compose sont : - écriture analytique, plus lisible qu'un script - possède beaucoup plus de fonctionnalités (dont on n'aborde ici qu'une infime partie) - possibilité de définir plus applications (appelés services) au sein d'un même fichier Dans un fichier docker-compose.yml, on peut définir 3 types d'objets : - des services : ce sont les applications en elles-mêmes - des volumes : ce sont des dossiers dans lesquels on va pouvoir écrire des données de manière persistante - des réseaux (networks) : ils définissent la manière dont sont exposés les conteneurs Il suffit de placer ce fichier dans un dossier, d'en faire le répertoire de travail dans son terminal, et de taper : docker-compose up -d Si je souhaite supprimer les conteneurs (et les éventuels réseaux définis dans le fichier), il me suffit de taper : docker-compose down Ça a également l'avantage de garder la configuration du conteneur au sein d'un fichier. Ce fichier docker-compose.yml peut être créé par Notepad++ sous Windows, ou via l'éditeur de texte sous Linux. Attention !! le fichier ne doit pas contenir de tabulation, tous les décalages sont réalisés à partir d'espace !! Plus d'infos sur Docker-compose à cette page. 10. Quelques autres commandes utiles docker stats Affiche les ressources utilisées par vos conteneurs, se rafraîchit constamment. docker network inspect <nom_du_réseau> Permet d'avoir toutes les informations relatives à un réseau donné. docker rmi <nom_image> Permet de supprimer l'image avec le nom spécifié. 11. Informations complémentaires 11-A. Réseaux Le mode bridge par défaut (c'est-à-dire si on utilise le driver bridge, et qu'on ne rattache le conteneur à aucun réseau bridge particulier) n'est pas idéal si l'on souhaite isoler les conteneurs les uns des autres. Tous les conteneurs appartenant au réseau bridge par défaut peuvent communiquer les uns avec les autres par leur IP, et se situent sur un même sous-réseau (par exemple 172.17.0.0). Si on souhaite s'affranchir des adresses IP (qui peuvent changer entre chaque création et suppression de conteneur) et utiliser plutôt le nom du conteneur pour communiquer avec, il existe deux méthodes : Les liens (évoqués plus avant) : c'est une fonctionnalité officiellement dépréciée dans les nouvelles versions de Docker, elle est cependant présente dans l'inteface Docker de DSM, dans l'onglet Lien lorsqu'on crée ou modifie un conteneur. En précisant le nom d'un autre conteneur, on autorise la communication notre conteneur en devenir et celui-ci. Les réseaux bridge définis par l'utilisateur : la commande docker network permet de gérer les réseaux docker et donc d'en créer de nouveaux. Lorsqu'on crée un réseau bridge, celui-ci aura la propriété intrinsèque que tous les conteneurs qui y sont connectés pourront communiquer entre eux via leurs noms de conteneur. Le réseau 172.17.0.0/24 étant réservé au réseau bridge par défaut, le premier réseau disponible est le 172.18.0.0/24, et ce jusqu'à 172.32.0.0/24. Un réseau de type bridge créé dans l'interface Docker de DSM est un réseau de cette catégorie. Il existe un autre type de réseau appelé macvlan : il permet de donner une IP sur le réseau physique à un conteneur, donc par exemple 192.168.0.0/24, et sera donc directement accessible par les autres périphériques de votre réseau local. Merci à @bruno78 pour son apport sur ce sujet en particulier, la suite est très largement inspirée de ses commentaires, et @Didier3L dont les questions ont permis de défricher le terrain. Ce driver possède de gros avantages et un gros défaut : Si le conteneur a une IP sur le réseau physique, elle est directement accessible via tous ses ports. C'est excessivement pratique si certaines applications de l'hôte, ici le NAS, utilisent déjà certains ports : 80, 443, 53, etc... Prenez l'exemple parlant de Pihole, ce dernier utilise le port 80 pour plusieurs tâches, ainsi que le port 53 qui est le port DNS non sécurisé. Si vous utilisez le paquet DNS Server du NAS, le port 53 est déjà en écoute, pareil avec le port 80 si Webstation est exécuté. Nous avons précédemment vu qu'il était possible de translater, sauf que certains ports comme le port 53 ne sont pas réellement déplaçables sur un autre port. Je n'ai donc aucune redirection à faire, j'accéderai à mon application via par exemple 192.168.0.101:80, tout simplement, sans me soucier de ce que le NAS utilise. Attention cependant, en macvlan, l'hôte ne peut plus communiquer, via son interface physique, avec le conteneur !! Ce n'est pas gênant dans le cas du contrôleur Unifi d'Ubiquity, mais beaucoup plus dans le cas de Pihole par exemple. Pour créer un réseau macvlan, on peut le créer de manière externe, via docker network via ligne de commande ou de manière interne lors de l'écriture d'un script ou dans un fichier docker-compose. Dans ce cas, on va créer le réseau macvlan toto de façon externe : docker network create -d macvlan \ --subnet=192.168.0.0/24 \ --ip-range=192.168.0.144/28 \ --gateway=192.168.0.254 \ -o parent=ovs_eth0 \ toto Notes : (les valeurs sont données à titre d'exemple évidemment) - subnet => on choisit le sous-réseau physique, celui de nos machines. - ip-range => on va définir la plage d'IP couverte par le réseau, un calculateur d'IP sera d'une grande aide pour définir le nombre d'IP qu'on réserve et ajuster à notre besoin. Important !! Il est fortement recommandé que la plage d'IP couverte par le serveur DHCP de votre réseau soit dissociée de la plage d'IP allouée au réseau macvlan. - gateway => c'est notre passerelle, vu qu'on est sur le réseau physique c'est généralement votre box ou votre routeur. - parent => c'est le nom de l'interface physique (tapez ifconfig pour vérifier) On valide et notre réseau est créé. Maintenant, il reste un problème à résoudre ; comme évoqué plus haut, tout conteneur dans ce réseau ne sera pas joignable par l'hôte, quelque soit le protocole (ICMP, TCP, UDP, HTTP, etc...) Une solution existe toutefois, il suffit de créer une nouvelle interface sur le NAS, une interface virtuelle, par lequel il sera aussi normalement accessible que par son interface physique. Pour illustrer, si j'accède à DSM via 192.168.0.100:5000 en temps normal, je pourrai depuis un conteneur sur le réseau macvlan y accéder via l'adresse 192.168.0.200:5000 Le conteneur pourra donc communiquer avec le NAS via cette nouvelle interface. Pour cela, il suffit de taper quelques lignes de commande en SSH : ip link add <nom_interface_macvlan> link <interface_physique> type macvlan mode bridge ip addr add <IP_virtuelle>/32 dev <nom_interface_macvlan> ip link set dev <nom_interface_macvlan> address <adresse_MAC> ip link set <nom_interface_macvlan> up ip route add <Plage_DHCP_réseau_macvlan> dev <nom_interface_macvlan> Si on veut faire correspondre à l'exemple du réseau ci-dessus : - <nom_interface_macvlan> => un nom au hasard, pas de caractères spéciaux, macvlan_int par exemple, peu importe - <interface_physique> => ovs_eth0 - <IP_virtuelle> => on avait choisi arbitrairement l'adresse 192.168.0.140, on vérifie que cette IP n'est pas dans la plage couverte par le réseau macvlan toto - <adresse MAC> => on peut définir une adresse MAC pour notre interface - <Plage_DHCP_réseau_macvlan> => ça correspond à --ip-range dans le script plus haut Vous devriez maintenant avoir maintenant une nouvelle interface visible en tapant ifconfig en SSH. Vous verrez également cette interface sur l'assistant Synology par exemple. Si vous tentez un ping depuis votre NAS vers un conteneur sur le réseau macvlan, cela devrait marcher. Inconvénient majeur : Au reboot, l'interface sera supprimée et le code précédent devra être réintroduit. Pour éviter cela, on peut créer une tâche dans le planificateur de tâches, à exécuter au démarrage du NAS, qui exécute un script comprenant toutes les commandes ci-dessus (celles commençant par IP). On peut également ajouter un sleep 60 pour temporiser 60 secondes avant l'exécution du script, on s'assure ainsi que la machine a bien démarré avant toute chose. En dernier lieu, il existe un driver dhcp, qui se comporte vraiment comme un périphérique physique, dans le sens où, contrairement au driver macvlan où la plage d'IP est pré-déterminée, le conteneur ira chercher son IP auprès du serveur DHCP du réseau, très probablement la box ou le routeur. On a donc les avantages du driver macvlan sans les inconvénients. Ce driver reste toutefois à l'heure actuelle à l'état de beta, mais affaire à suivre... MàJ : 01/04/2021

Créer son site Wordpress avec Docker sur Synology PrérequisInstallation des images DockerConfiguration de MariaDBConfiguration de WordpressConfiguration du Reverse ProxyConclusion Prérequis Premièrement assurez-vous bien que votre NAS Synology soit compatible avec Docker, vous pourrez trouver cette information dans la liste des modèles compatibles. Deuxièmement , ce tutoriel supposera que vous ayez déjà votre accès externe au NAS configuré, c'est-à-dire : Un nom de domaine pointant sur l'IP de votre routeur, potentiellement un nom de domaine dynamique comme dans mon cas. Configurer votre routeur pour les redirections monNomDeDomaine.synology.me:80 → IPdeMonNAS:80 monNomDeDomaine.synology.me:443 → IPdeMonNAS:443 Attention : l'IP du NAS doit être statique car en cas de panne électrique, lors du redémarrage du NAS, celui-ci obtiendra une nouvelle IP, potentiellement différente de la précédente, cela est dû au DHCP fourni par le routeur si tel est le cas. Installation des images Docker Installez le paquet Docker via le centre de paquets Synology. Ouvrez Docker : Téléchargez les images de Wordpress et MariaDB Configuration de MariaDB Lancez le conteneur mariadb : Donnez le nom que vous voulez à votre conteneur, pour ma part j'ai choisi "mariadb" car je n'ai pas prévu d'instancier plusieurs sites wordpress ni d'utiliser d'autres bases de données mariadb. En revanche par souci de sécurité, je vous déconseille de l'exécuter à l'aide de privilèges élevés. Ensuite, choisissez d'activer ou non la limitation de ressources, il est vrai que si vous envisagez que votre site web soit très largement visité il vaut mieux fixer un quota en fonction de la mémoire RAM disponible sur votre NAS. Allez dans les Paramètres avancés : cochez l'option redémarrage automatique Je détaillerai cette section lors de la configuration de Wordpress. Volumes : Réseau : Paramètres des ports : Laissez le port 3306 par défaut du conteneur de mariadb car il est configuré ainsi dans le conteneur, seul le port de l'hôte (port local) doit être modifié au besoin. Choisissez un port disponible sur votre système pour le port local de l'hôte, par exemple : 32552. Liens : Laissez comme tel Je détaillerai également cette section lors de la configuration de Wordpress. Environnement : Sur la page officielle de MariaDB sur Docker Hub, des variables d'environnement peuvent être configurées, certaines sont optionnelles (MYSQL_USER, MYSQL_PASSWORD, etc) mais une seule est obligatoire : MYSQL_ROOT_PASSWORD ! MYSQL_USER: mariadb MYSQL_PASSWORD: My$uP3RP@$$w0rD MYSQL_ROOT_PASSWORD: My$uP3RP@$$w0rD Je vous propose d'ajouter ces trois variables à celles déjà existantes. Attention à ne pas réutiliser ce mot de passe, il ne s'agit pas de celui que j'utilise bien évidemment. Configuration de Wordpress Lancez le conteneur wordpress : De même que pour MariaDB, j'ai choisi : wordpress aucun privilège pas de limitation de ressources Allez dans les Paramètres avancés : Pour un site web disponible 24H/24 je vous conseille d'activer l'option de redémarrage automatique, cela sera bien plus pratique au lieu de devoir se reconnecter au NAS chaque fois que son site sera indisponible. Surtout si vous comptez utiliser un plugin comme Jetpack sur votre site wordpress, il vous enverra automatiquement un mail dès que votre site ne sera plus accessible. Cochez l'option de la page web pour indiquer son FQDN (fully qualified domain name) au cas où vous souhaiteriez mettre en place par la suite plusieurs sites web sous le même nom de domaine. Volumes : De même que pour MariaDB, je spécifie le répertoire dans lequel mon conteneur va écrire. Réseau : Laissez comme tel Paramètres des ports : Laissez le port 80 par défaut du conteneur de wordpress car il est configuré ainsi dans le conteneur, seul le port de l'hôte (port local) doit être modifié au besoin. Choisissez un port disponible sur votre système pour le port local de l'hôte, par exemple : 32551. Liens : C'est le moment de paramétrer les liens de son conteneur wordpress en créant un lien avec le conteneur mariadb créé juste avant pour que wordpress puisse communiquer avec sa base de données mariadb. Environnement Sur la page officielle de Wordpress sur Docker Hub, des variables d'environnement peuvent être configurées, trois variables sont obligatoires : If you'd like to use an external database instead of a mysql container, specify the hostname and port with WORDPRESS_DB_HOST along with the password in WORDPRESS_DB_PASSWORD and the username in WORDPRESS_DB_USER WORDPRESS_DB_HOST: mariadb WORDPRESS_DB_USER: root WORDPRESS_DB_PASSWORD: My$uP3RP@$$w0rD Je vous propose d'ajouter ces trois variables à celles déjà existantes. Configuration du Reverse Proxy Allez dans Panneau de configuration > Portail des Applications > Proxy Inversé On va configurer le reverse proxy (proxy inversé en français) pour rediriger les requêtes sur le port 80 de votre nom de domaine. On va avoir deux configurations : une pour le http et une autre pour le https. Le HTTP de mon NAS Synology est toujours redirigé vers le HTTPS par sécurité, donc on pourrait se passer de la première configuration. Sans toucher aux autres options (En-tête personnalisé et Paramètres avancés), on va rediriger les requêtes HTTPS du port par défaut (443) vers notre port 32551 spécifique au conteneur wordpress. Conclusion Et voilà ! Notre site est prêt à être développé ! À vous de jouer maintenant pour créer votre site wordpress avec Docker sur votre NAS Synology. Pour aller plus loin, je vous invite à installer de la même façon phpMyAdmin avec Docker pour le connecter à MariaDB et gérer votre base de données.

Bonjour, J'ai un soucis avec le script en fin de message (car il est un peu long...). La commande docker suivante ne passe pas : docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(/usr/local/bin/docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini" Et même la version sans variables ne passe pas : docker exec -u 1060 -it -w /backup-data $(/usr/local/bin/docker ps -qf "name=gitea") bash -c "/app/gitea/gitea dump -c /data/gitea/conf/app.ini" L'erreur retournée dans le mail de notification est : Que la commande soit précédée par un sudo ou non, ou que le chemin /usr/local/bin/ devant ou non, ça ne fonctionne pas mieux... Pour être sûr que la commande docker fonctionne dans uns script, j'ai fait un petit script test avec : docker ps Dans l'email de notification je reçois bien le résultat d'un docker ps avec la liste des conteneurs lancés. Donc la commande docker est bien reconnue. Ce qui ne va pas est donc ce qui suit... Je précise que lancer le script depuis une invite SSH (iTerm2 ou Windows Terminal), fonctionne bien : Donc voilà, comment rendre fonctionnelle cette ligne de commande permettant de faire la sauvegarde des données via ce qui est fourni par la doc officielle ? Merci d'avance. Le script lui même : ##============================================================================================== ## ## ## Script gitea-backup.sh ## ## ## ##============================================================================================== ## ## ## gitea-backup.sh [<méthode de backup>] ## ## <méthode de backup> est facultatif. S'il n'est pas spécifié, on fait les deux ! ## ## <méthode de backup> = gitea_dump ## ## = archive_dossier ## ## ## ##============================================================================================== ##============================================================================================== ## ## ## Objectif du script : faire une sauvegarde de l'installation Gitea @ Docker ## ## Il y a aura un shutdown du conteneur le temps de la sauvegarde afin que la base de ## ## données ne soit pas modifiée pendant le backup, puis le conteneur sera redémarré. ## ## ## ## Il faudra créer une tâche planifiée pour lancer la sauvegarde toutes les nuits, par ## ## exemple à 3h du matin. ## ## ## ##============================================================================================== ## ## ## Une méthode officielle de backup de la base de données est présente ici : ## ## https://docs.gitea.io/en-us/backup-and-restore/#backup-command-dump ## ## ## ##============================================================================================== # Récupération des arguments qu'on place dans des variables constantes declare -r nb_arg=$# # Nombre d'argument(s) fourni(s) au script. declare -r methode="$1" # 1er argument fourni if [ "$methode" = "--help" ] || [ "$methode" = "-help" ] || [ "$methode" = "-h" ] || [ "$methode" = "--h" ]; then echo "Le script gitea-backup.sh permet de faire une sauvegarde des données du conteneur Gitea." echo "Utilisation : gitea-backup.sh [<méthode de backup>]" echo "L'argument <méthode de backup> est facultatif. S'il n'est pas spécifié, on fait les deux !" echo " <méthode de backup> = gitea_dump" echo " = archive_dossier" echo exit 0 fi mode_backup=0 # 0 = aucune méthode indiquée ; 1 = gitea_dump ; 2 = archive_dossier ##──── ──────────────────────────────────────────────────────────────────────────────────────── ##──── ──────────────────────────────────────────────────────────────────────────────────────── ## ## ## VALEURS À PERSONNALISER ## ## ## ## Chemin d'accès vers votre dossier docker et vers le dossier de backup de gitea ## # Chemin du dossier qui contient le dossier des données (data) et des backups (backup-data) GITEA_DOCKER_DIR=/volume1/docker/gitea # Les noms des dossiers montés dans le conteneur doivent êtres identiques à ceux présents sur la machine hôte. Sinon faudra modifier le script... # Nom du dossier contenant les backups qui doit exister car il doit être monté dans le conteneur à l'aide du docker-compose.yml. GITEA_BACKUP_DIR=backup-data # Nom du dossier contenant les donneés de Gitea (data) GITEA_DATA_DIR=data # Nom du conteneur NOM_CONTENEUR=gitea # ID de l'utilisateur du NAS qui a les droits sur le conteneur ID_USER_NAS=1060 ##──── ──────────────────────────────────────────────────────────────────────────────────────── ##──── ──────────────────────────────────────────────────────────────────────────────────────── echo "$(date "+%R:%S - ") Script de sauvegarde des données du conteneur Gitea" ##============================================================================================== ## Vérification de la présence des dossiers du conteneur ## cd $GITEA_DOCKER_DIR num_erreur=$? # On stocke le code de retour de la commande précédente. if [ $num_erreur -ne 0 ]; then # Si ce code n'est pas 0, il y a eu une erreur, on arrète le script. echo " Le chemin '$GITEA_DOCKER_DIR' est invalide ! Veuillez vérifier le chemin d'accès..." echo " Abandon, avec code d'erreur $num_erreur" exit $num_erreur fi if [ ! -d "$GITEA_BACKUP_DIR" ] || [ ! -d "$GITEA_DATA_DIR" ]; then # Au moins un des dossiers n'existe pas if [ ! -d "$GITEA_BACKUP_DIR" ]; then # Le dossier $GITEA_BACKUP_DIR n'existe pas ! echo " Le dossier '$GITEA_BACKUP_DIR' n'existe pas !" fi if [ ! -d "$GITEA_DATA_DIR" ]; then # Le dossier $GITEA_DATA_DIR n'existe pas ! echo " Le dossier '$GITEA_DATA_DIR' n'existe pas !" fi echo " Abandon, avec code d'erreur $num_erreur" exit 999 else echo "-- Les dossiers $GITEA_BACKUP_DIR et $GITEA_DATA_DIR existent bien. On peut continuer." fi ##============================================================================================== ##============================================================================================== ## ## ## Définition du mode de backup à faire en fonction de la méthode donnée en argument ## case $methode in gitea_dump) # Méthode gitea_dump sélectionnée ## mode_backup=1 #echo "mode_backup=$mode_backup" ;; archive_dossier) # Méthode archive_dossier sélectionnée ## mode_backup=2 #echo "mode_backup=$mode_backup" ;; *) # Aucune méthode sélectionnée ## mode_backup=0 #echo "mode_backup=$mode_backup" ;; esac ##============================================================================================== ##============================================================================================== ## ## ## Partie concernant les sauvegardes ## if [ $mode_backup -eq 0 ] || [ $mode_backup -eq 1 ]; then # Aucune méthode n'est choisie ou bien méthode gitea_dump sélectionnée # Rappel des variables : # GITEA_DOCKER_DIR=/volume1/docker/gitea # GITEA_BACKUP_DIR=backup-data # GITEA_DATA_DIR=data # NOM_CONTENEUR=gitea # ID_USER_NAS=1060 echo "-- Sauvegarde via Gitea dump. (un peu chiant à restaurer...)" echo "###############################################################################" # Dans la commande suivante, les chemins d'accès donnés en paramètres sont des chemins d'accès à l'intérieur du conteneur, montés avec le docker-compose.yml. # Exemple de commande sans variables : # docker exec -u 1060 -it -w /backup-data $(docker ps -qf "name=gitea") bash -c '/app/gitea/gitea dump -c /data/gitea/conf/app.ini' docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(/usr/local/bin/docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini" num_erreur=$? # On stocke le code de retour de la commande précédente. if [ $num_erreur -ne 0 ]; then # Si ce code n'est pas 0, il y a eu une erreur, on arrète le script. echo "!!!!!! Erreur lors de la commande de backup gitea dump." #echo "!!!!!! Commande lancée :" #echo " docker exec -u $ID_USER_NAS -it -w /$GITEA_BACKUP_DIR $(docker ps -qf "name=$NOM_CONTENEUR") bash -c "/app/gitea/gitea dump -c /$GITEA_DATA_DIR/gitea/conf/app.ini"" echo "!!!!!! Abandon, avec code d'erreur $num_erreur" exit $num_erreur fi echo "###############################################################################" echo "-- Sauvegarde via Gitea dump terminée." fi if [ $mode_backup -eq 0 ] || [ $mode_backup -eq 2 ]; then # Aucune méthode n'est choisie ou bien méthode archive_dossier sélectionnée echo "-- Sauvegarde par création d'une archive de tout le dossier $GITEA_DATA_DIR" echo "###############################################################################" echo "-- Extinction du conteneur $NOM_CONTENEUR" cd $GITEA_DOCKER_DIR # Même si on est censé déjà être là... docker stop $NOM_CONTENEUR tar -czf $GITEA_BACKUP_DIR/Gitea-Data-Backup-`date +%Y-%m-%d--%Hh%Mm%Ss`.tar.gz ./$GITEA_DATA_DIR # On Linux/Unix, in order to backup directories you must use tar : # - to backup a directory : tar cf - directory | 7z a -si directory.tar.7z # - to restore your backup : 7z x -so directory.tar.7z | tar xf - tar cf - ./$GITEA_DATA_DIR | 7z a -si $GITEA_BACKUP_DIR/Gitea-Data-Backup-`date +%Y-%m-%d--%Hh%Mm%Ss`.7z echo "-- Archive de tout le dossier $GITEA_DATA_DIR créée." echo "-- Redémarrage du conteneur Gitea..." docker start $NOM_CONTENEUR echo "###############################################################################" echo "-- Processus de sauvegarde par création d'archive terminé." fi echo "$(date "+%R:%S - ") Fin du script de sauvegarde des donneés du conteneur Gitea" exit 0 ## ## ##==============================================================================================

WATCHTOWER 1. Préambule Le but de ce tutoriel est de mettre en place une application, containrrr/watchtower (Docker Hub, Github) qui va vérifier suivant un intervalle que vous définirez la présence d'une nouvelle version pour totalité ou partie de vos images Docker. C'est un fork de v2tec/watchtower qui n'est maintenant plus mis à jour depuis près de deux ans. Ce tutoriel se basait historiquement sur l'image pyouroboros/ouroboros, qui n'est plus maintenue. NOTES : Les commentaires concernant watchtower (et pas ouroboros) commencent au milieu de la page 2. Avantages : - Plus besoin de vérifier via Docker Hub si une mise à jour est disponible - Processus entièrement automatisé - Ne consomme quasi aucune ressource Inconvénients : - Nécessite un accès à docker.sock, d'un point de vue sécurité ça peut être gênant pour certains - Suivant l'intervalle de vérification que vous définissez, la quantité de données échangée peut être importante, à surveiller si vous avez un quota - On ne peut l'installer par l'interface Docker de DSM (en fait si, mais c'est fastidieux). Je pondérerai le volet concernant la sécurité, si vous avez bien respecté les conseils de sécurité développés dans les tutoriels de référence de ce forum vous ne devriez pas avoir de souci à vous faire. 2. Prérequis - Savoir se connecter en SSH (root) - Avoir Docker installé sur son NAS C'est parti ! On commence par se connecter en SSH avec l'utilisateur root (voir le tutoriel [TUTO] Accès SSH et ROOT via DSM 6). On télécharge l'image : docker pull containrrr/watchtower Il ne reste plus qu'à créer le conteneur, mais il est avant tout intéressant de voir les fonctionnalités que l'application propose dans la documentation, et en particulier sur cette page. C3es paramètres sont personnalisés par l'ajout de variables d'environnement à la création du conteneur. 3. Configuration 3-A. Fréquence de mise à jour - INTERVAL : Définit un intervalle de mise à jour en secondes. Ex : WATCHTOWER_POLL_INTERVAL=300 - SCHEDULING : Le plus intéressant pour des particuliers je trouve, cron permet de définir une périodicité très personnalisable : tous les x jours, tous les mardi, 3 fois par jour le mercredi et le vendredi, à telle heure, x fois par mois, etc... la documentation de l'image renvoie vers ce site, mais je trouve ce générateur ou celui-ci très pratiques. L'image utilise un format CRON à 6 champs, contrairement aux liens ci-avant qui n'utilisent que 5 champs, en réalité, tous les champs sont décalés vers la droite pour proposer un réglage sur les secondes. Donc au lieu d'avoir : minutes | heures | jour du mois | mois | jour de la semaine vous avez secondes | minutes | heures | jour du mois | mois | jour de la semaine Ex : WATCHTOWER_SCHEDULE=0 0 5 * * 6 Cela correspond à une exécution hebdomadaire, tous les samedi matin à 5:00 Un conseil : Évitez d'utiliser 2:00 ou 3:00, à cause des changements d'heure Ces deux méthodes sont exclusives, c'est donc l'une ou l'autre. 3-B. Tri sélectif Par défaut, watchtower surveille tous les conteneurs. Mais on ne souhaite pas spécialement mettre à jour tous ses conteneurs automatiquement, certains sont gérés par des scripts de mise à jour (Bitwarden par exemple), d'autres sont peu maintenus, et il est plus risqué de mettre à jour aveuglément ce type d'images que celles issues de collectifs reconnus (Linuxserver, Bitnami, etc...). Plusieurs méthodes de tri sont proposées : - LABEL ENABLE : Permet d'utiliser les labels (des tags en quelque sorte) comme signes de distinction. Lorsqu'on crée un conteneur, on peut décider de lui ajouter un label, composé d'un intitulé et d'une valeur de type chaîne ou entier. Pour permettre à watchtower de mettre à jour un conteneur donné, il doit avoir parmi ses labels : com.centurylinklabs.watchtower.enable=true L' avantage énorme c'est que le nom du conteneur cible n'a pas d'importance, le fait qu'il n'existerait plus à un instant t n'a pas davantage d'incidence. Pour faire en sorte que la sélection des conteneurs à surveiller se fasse par label, il faut ajouter la variable suivante à la création du conteneur watchtower : WATCHTOWER_LABEL_ENABLE=true - FULL EXCLUDE (Ce n'est pas une variable d'environnement !!) : L'approche est exclusive au lieu d'être inclusive, elle se base sur le comportement par défaut de watchtower (surveillance de tous les conteneurs), mais il n'y a ici aucune variable d'environnement à préciser à la création du conteneur watchtower, en revanche les conteneurs que vous ne souhaiteriez pas surveiller doivent avoir le label suivant : com.centurylinklabs.watchtower.enable=false Notes : - Il n'est pas possible d'ajouter un label à un conteneur déjà existant. Il faut le recréer et insérer le label dans le script de création du conteneur. Si vous savez les recréer facilement (peu de paramètres à entrer, vos volumes sont persistants et les fichiers de configuration sont maintenus à la suppression du conteneur, ou si vous utilisez docker-compose) alors je préconise la méthode des labels, dans le cas contraire préférez la méthode FULL EXCLUDE. - La documentation est particulièrement claire à ce sujet. 3-C. Gestion des images - CLEANUP : Supprime la version précédente de l'image quand une plus récente a été téléchargée et qu'un nouveau conteneur a été créé. Cette fonctionnalité est désactivée par défaut. Ex : WATCHTOWER_CLEANUP=true - ROLLING RESTART : Par défaut, watchtower met à jour toutes les images avant de relancer les conteneurs, cette variable d'environnement permet de relancer les conteneurs au fur et à mesure, utilise si on souhaite réduire les périodes d'indisponibilités. Ex : WATCHTOWER_ROLLING_RESTART=true - WAIT UNTIL TIMEOUT : Par défaut, watchtower attend 10 secondes qu'un conteneur s'arrête une fois le signal d'extinction transmis. Certaines applications lourdes nécessitent plus de temps, cette variable permet d'ajuster ce délai. Ex : WATCHTOWER_TIMEOUT=30s Notes : - On notera la présence du "s" pour "seconde". - LINKED CONTAINERS : Certains conteneurs peuvent nécessiter que d'autres conteneurs soient opérationnels avant d'être créés, on prend souvent comme exemple le cas typique d'une application et d'une base de données. Afin d'éviter des erreurs, on souhaite que la base de données soit disponible avant l'application à la création, et inversement à la suppression. Ces relations existent par exemple lorsqu'on utilise l'argument --link en ligne de commande, ou avec l'instruction depends_on via docker-compose. On peut écraser ces réglages via le label : com.centurylinklabs.watchtower.depends-on tel que par exemple, si on applique ce label à un conteneur MariaDB : com.centurylinklabs.watchtower.depends-on=wordpress,caldav En cas de mise à jour disponible pour ce dernier, watchtower arrêtera au préalable les conteneurs wordpress et caldav. 3-D. Autres paramètres - DEBUG : Augmente le niveau de verbosité du stdout dans les logs du conteneur. Ex : WATCHTOWER_DEBUG=true - TRACE : Un debug encore plus verbeux, attention les credentials éventuels sont en clair ! Ex : WATCHTOWER_TRACE=true - TZ : Permet de définir le fuseau horaire, assure le lien entre la variable CRON si vous l'utilisez et votre fuseau horaire. La liste des timezone est disponible à cette adresse. Ex : TZ=Europe/Brussels Il y a encore énormément de fonctionnalités que je n'aborderai pas ici, citons parmi les plus notables : - les notifications => https://containrrr.dev/watchtower/notifications/ - La supervision de plusieurs instances Docker via un seul conteneur watchtower => https://containrrr.dev/watchtower/remote-hosts/ et https://containrrr.dev/watchtower/secure-connections/ (pour une connexion sécurisée (TLS), une lecture de https://www.nas-forum.com/forum/topic/66422-tuto-centralisation-des-instances-docker/ peut être instructive ) - la possibilité d'exécuter des scripts avant et après la mise à jour (par l'utilisation de labels) => https://containrrr.dev/watchtower/lifecycle-hooks/ - la possibilité d'utiliser d'autres dépôts que Docker Hub, ouvrant la voie à des dépôts privés => https://containrrr.dev/watchtower/private-registries/ Au final ce tutoriel se contente de traduire et de mettre en valeur les variables importantes, la documentation (je crois que je me répète ) est très complète. 4. Création du conteneur On a maintenant tous les outils en main, on va pouvoir créer notre conteneur. Pour se faire, plusieurs possibilités : 4-A. En lignes de commande (SSH) Voici un exemple de configuration : docker create --name=watchtower \ --hostname=watchtower-nas --restart=unless-stopped \ --label "com.centurylinklabs.watchtower.enable=true" \ -e WATCHTOWER_CLEANUP=true \ -e WATCHTOWER_DEBUG=true \ -e WATCHTOWER_LABEL_ENABLE=true\ -e WATCHTOWER_TIMEOUT=30s \ -e WATCHTOWER_SCHEDULE="0 0 5 * * 6"\ -e TZ=Europe/Brussels \ -v /var/run/docker.sock:/var/run/docker.sock \ containrrr/watchtower Notes : - On est obligé de monter en volume le socket Docker au vu des opérations que doit pouvoir effectuer watchtower sur les autres conteneurs. - On peut tout à fait demander via le label de mise à jour que watchtower se mette lui-même à jour. Si tout a bien fonctionné, vous devriez avoir comme retour une suite de chiffres et de lettres (correspondant à l'ID du conteneur), il ne reste plus qu'à le démarrer : docker start watchtower 4-B. Par Docker-compose (SSH) Une autre personnalisation de l'image au format docker-compose : docker-compose.yml version: '2.1' services: watchtower: image: containrrr/watchtower container_name: watchtower hostname: watchtower-nas network_mode: bridge environment: - WATCHTOWER_NOTIFICATIONS=email - WATCHTOWER_CLEANUP=true - WATCHTOWER_DEBUG=true - WATCHTOWER_LABEL_ENABLE=true - WATCHTOWER_TIMEOUT=30s - WATCHTOWER_SCHEDULE=0 0 5 * * 6 - TZ=Europe/Brussels env_file: - /volume1/docker/watchtower/watchtower.env labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - /var/run/docker.sock:/var/run/docker.sock - /volume1/docker/watchtower/config.json:/root/.docker/config.json restart: unless-stopped Notes : - J'ai cette fois-ci ajouté les notifications par mail, mais on remarque qu'on ne retrouve pas les autres variables qui sont liées au relais SMTP (https://containrrr.dev/watchtower/notifications/#email). En réalité, pour des raisons de confidentialié, j'ai regroupé les variables qui sont plus "sensibles" dans un fichier .env qui est invoqué par : env_file: - /volume1/docker/watchtower/watchtower.env Fichier qui se présente sous la forme, et dont les permissions sont correctement réglées pour assurer le niveau de confidentialité désiré : WATCHTOWER_NOTIFICATION_EMAIL_FROM=... WATCHTOWER_NOTIFICATION_EMAIL_TO=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_USER=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PASSWORD=... WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT=... WATCHTOWER_NOTIFICATION_EMAIL_SUBJECTTAG=... - J'ai monté le fichier config.json pour y ajouter des credentials pour des dépôts privés. Pour créer le conteneur, on se place (cd) dans le dossier où se trouve le fichier docker-compose.yml et on tape : docker-compose up -d 5. Configuration Ci-après un exemple de logs suite à un déclenchement programmé de Watchtower : 2020-11-14 05:01:31 (info): Found new grafana/grafana:latest image (sha256:68f75fcab5a9372fb0844f5898c65a40b0ca34cff4176e269bade17ddb17ee75) 2020-11-14 05:01:48 (info): Found new telegraf:latest image (sha256:146c415345a26f48f8ef06c2f62ebde90c8ca4ca518db5d88137e60eeb0abeec) 2020-11-14 05:01:59 (info): Found new authelia/authelia:latest image (sha256:d05b2f15beecd4c164a861e0464ddfef1d574b1c67f8e343779daec26c7bbde9) 2020-11-14 05:03:17 (info): Found new linuxserver/mariadb:latest image (sha256:f48f265a3ed8b786973e85c2c681f2f79db1b64d38660c43900bfc48651c6f83) 2020-11-14 05:03:19 (info): Stopping /grafana (bfdbba3a284d51c1a5c5c807f8583857a0c6a03718a083e93e5bcf9671f7130f) with SIGTERM 2020-11-14 05:03:21 (info): Stopping /telegraf (56e1c8624a98344cba07ca6f745c0cd8a93d66b36ebc0af8992cac210c8e0d51) with SIGTERM 2020-11-14 05:03:22 (info): Stopping /authelia (6d4202898398cf0b46886d38c6591a15b83334e00fe20a0025fcd4437747f84c) with SIGTERM 2020-11-14 05:03:23 (info): Stopping /mariadb (763aeebe73c029c20de2a15d114c054ba70b26879fdaf82b3019944179f31573) with SIGTERM 2020-11-14 05:03:27 (info): Creating /mariadb 2020-11-14 05:03:31 (info): Creating /authelia 2020-11-14 05:03:34 (info): Creating /telegraf 2020-11-14 05:03:40 (info): Creating /grafana 2020-11-14 05:03:42 (info): Removing image sha256:ec8e3ebf50429170fa6387bb04e64e5b5f3d87f3221c42750b7fb5d922c5e978 2020-11-14 05:03:43 (info): Removing image sha256:48121fbe19c845fa401be9fdbf3cbeef50840b7537d8a0b9ca2eab081117beb6 2020-11-14 05:03:43 (info): Removing image sha256:7606d5ee069fcab20036c4bd521e1133ac8ca31e44f7d241f0d83a36315d6ca6 2020-11-14 05:03:43 (info): Removing image sha256:900b03b57e41a8bf7f43b8979872bb2d6642d9a4bcb738d053fb67e1d989e926 MàJ : 10/04/2021

Bonjour, Je fais ce sujet afin de partager mon expérience d'installation Fail2ban (donc ce que j'ai compris de mes lectures) et surtout pour poser quelques questions. Je précise que je suis loin d'avoir tout compris, d'où les questions qui arriveront. @.Shad. Je sais que tu utilises Fail2ban, et donc je me dis que tu t'y connais mieux que moi Tu pourras peut-être répondre aux diverses questions éparpillées dans ce message. Je vais les mettre en couleur/gras ^^ L'objectif de cette installation de Fail2ban est de protéger contre les attaques bruteforce (ce qui n'est pas forcément indispensable quand ce qui est protégé utilise la 2FA). En ce qui me concerne, ce sera Bitwarden_RS et Gitea. (et peut-être d'autres plus tard en fonction de ce que je vais mettre sous un nom de domaine). PS : Je n'utilise pas la solution qu'a bien documenté @.Shad. dans son tuto SWAG : [TUTO] Certificat SSL & reverse proxy via Docker - Page 3 - Tutoriels - NAS-Forum (nas-forum.com). Cependant j'ai pris quelques infos sur Fail2ban dans son tuto 1. Installation : J'ai installé Fail2ban dans un conteneur docker avec Portainer. Pour ce faire j'ai cloner/télécharger le dépôt suivant qui contient les fichiers à utiliser : https://github.com/sosandroid/docker-fail2ban-synology.git mais je n'ai pas utilisé directement le docker-compose.yml qui vient avec : (Voir mon fichier docker-compose.yml en fin de post, §5. , attention, il y a du commentaire ) En fin de compte mes fichiers ne sont plus vraiment comme ceux de ce dépôt, mais ils m'ont servi de base pour faire les miens. Vois en fin de message pour ce qui ne sera pas juste ci-dessous. Le seul fichier que j'ai conservé tel-quel, c'est le fichier action.d/iptables-common.local. 2. Paramétrages / Organisation des dossiers : J'ai renommé les fichiers .conf en .local, afin que ces derniers prennent toujours le dessus sur des éventuels fichier .conf présents dans le conteneur. Mais est-ce vraiment utile ? Bref, un petit point sur l'organisation des dossiers. Dans le dossier fail2ban, il y a 3 dossiers + un 4ème quand le conteneur sera lancé : On garde tel quel le contenu du dossier action.d/ avec le fichier iptables-common.local. Le dossier db contiendra la base de données, il ne faut pas y toucher. Le dossier filter.d/ contiendra les fichier permettant de définir les filtres à partir desquels fail2ban va réagir pour chaque prison définie. Le dossier jail.d/ contiendra les fichier définissant les prisons et les actions à réaliser si une détection est faite via ce qui est dans le dossier filter.d/ . Je ne me suis occupé que de ces deux derniers dossiers. Note importante : pour que Fail2ban fonctionne, il faut lui donner accès au fichier log des conteneurs/services à protéger. C'est ce que j'ai fait avec les volumes dans le fichier docker-compose.yml. 2.1. Dossier filter.d : Je me suis aidé des documentations officielles des conteneurs Bitwarden_RS et Gitea pour les règles. Ça fonctionne avec des expressions régulières, que je maitrise très très mal/peu... Ces expressions régulières seront utilisées pour trouver dans les fichiers log les lignes où les échecs de connexion ont eu lieu. Voilà les fichiers en question : # /volume1/docker/fail2ban/filter.d/bitwarden_rs.conf [INCLUDES] before = common.conf [Definition] failregex = ^.*Username or password is incorrect\. Try again\. IP: <ADDR>\. Username:.*$ ignoreregex = # /volume1/docker/fail2ban/filter.d/bitwarden_rs-admin.conf [INCLUDES] before = common.conf [Definition] failregex = ^.*Invalid admin token\. IP: <ADDR>.*$ ignoreregex = # /volume1/docker/fail2ban/filter.d/gitea.conf [Definition] failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST> ignoreregex = 2.2. Dossier jail.d : Je me suis aidé des documentations officielles des conteneurs Bitwarden_RS et Gitea pour les règles, en ajoutant modifiant certaines choses. Je veux être averti des ban lorsqu'il y en a, j'ai choisi comme action action = %(action_mwl)s. Les actions sont définies dans le fichier jail.conf situé dans le conteneur, donc non accessible directement (je ne me souviens plus du mot de passe). Dans le message suivant, je collerais le contenu de ce fichier. Voilà les fichiers que j'ai utilisé : # /volume1/docker/fail2ban/jail.d/bitwarden_rs-admin.conf [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 # Changes the default ban action from "iptables-multiport", which causes issues on some platforms, to "iptables-allports". banaction = iptables-allports # "bantime" is the number of seconds that a host is banned. bantime = 600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 5 destemail = mon-email@gmail.com sender = mon-email@gmail.com sendername = Fail2Ban action = %(action_mwl)s backend = auto [bitwarden_rs-admin] enabled = true port = 882,3012 # Doit correspondre au nom du fichier .conf dans le dossier filter.d filter = bitwarden_rs-admin logpath = /bitwarden/bitwarden.log # /volume1/docker/fail2ban/jail.d/bitwarden_rs.conf [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 # Changes the default ban action from "iptables-multiport", which causes issues on some platforms, to "iptables-allports". banaction = iptables-allports # "bantime" is the number of seconds that a host is banned. bantime = 600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 5 destemail = mon-email@gmail.com sender = mon-email@gmail.com sendername = Fail2Ban action = %(action_mwl)s backend = auto [bitwarden_rs] enabled = true port = 882,3012 # Doit correspondre au nom du fichier .conf dans le dossier filter.d filter = bitwarden_rs logpath = /bitwarden/bitwarden.log # /volume1/docker/fail2ban/jail.d/gitea.conf [DEFAULT] # "ignoreip" can be an IP address, a CIDR mask or a DNS host. Fail2ban will not # ban a host which matches an address in this list. Several addresses can be # defined using space separator. ignoreip = 172.16.0.0/12 192.168.0.0/16 10.0.0.0/8 # Changes the default ban action from "iptables-multiport", which causes issues on some platforms, to "iptables-allports". banaction = iptables-allports # "bantime" is the number of seconds that a host is banned. bantime = 600 # A host is banned if it has generated "maxretry" during the last "findtime" # seconds. findtime = 600 # "maxretry" is the number of failures before a host get banned. maxretry = 5 destemail = mon-email@gmail.com sender = mon-email@gmail.com sendername = Fail2Ban action = %(action_mwl)s backend = auto [gitea] enabled = true # Doit correspondre au nom du fichier .conf dans le dossier filter.d filter = gitea logpath = /gitea/gitea.log maxretry = 10 findtime = 3600 bantime = 900 Ce dernier fichier me semble servir aussi pour le fait que c'est sous Docker que Gitea est utilisé. La doc officielle place un autre fichier pour docker, avec une action différente, mais je ne saisi pas trop ce qu'elle a de différent, et comme je veux une notification email, j'ai mis la même chose, donc un fichier inutile... @.Shad. Qu'est-ce que tu en penses ? 3. Tester Fail2ban : Il suffit de lancer le conteneur, et de tenter de se connecter sur un des services protégés en foirant volontairement l'identification (mauvais mot de passe, mauvais login). Au bout du nombre de tentatives échouées, pouf, plus d'accès possible au service. Le log de fail2ban l'indique : 2021-04-09 17:43:03,716 fail2ban.filter [1]: INFO Added logfile: '/gitea/gitea.log' (pos = 28078, hash = 02020a73934340975ebecb822ad602221ce1ff76) 2021-04-09 17:43:03,719 fail2ban.jail [1]: INFO Jail 'bitwarden_rs-admin' started 2021-04-09 17:43:03,722 fail2ban.jail [1]: INFO Jail 'bitwarden_rs' started 2021-04-09 17:43:03,724 fail2ban.jail [1]: INFO Jail 'gitea-docker' started 2021-04-09 17:43:03,726 fail2ban.jail [1]: INFO Jail 'gitea' started 2021-04-09 17:44:16,039 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:15 2021-04-09 17:44:16,040 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:15 2021-04-09 17:44:38,498 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:38 2021-04-09 17:44:38,518 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:38 2021-04-09 17:44:38,926 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:38 2021-04-09 17:44:38,927 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:38 2021-04-09 17:44:39,630 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:39 2021-04-09 17:44:39,630 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:39 2021-04-09 17:44:40,132 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:40 2021-04-09 17:44:40,134 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:40 2021-04-09 17:44:40,836 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:40 2021-04-09 17:44:40,837 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:40 2021-04-09 17:44:41,123 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:41,124 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:41,446 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:41,447 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:41,750 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:41,751 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:41 2021-04-09 17:44:42,056 fail2ban.filter [1]: INFO [gitea-docker] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:42 2021-04-09 17:44:42,058 fail2ban.filter [1]: INFO [gitea] Found xxx.xxx.xxx.xxx - 2021-04-09 17:44:42 2021-04-09 17:44:42,064 fail2ban.actions [1]: NOTICE [gitea] Ban xxx.xxx.xxx.xxx 2021-04-09 17:44:42,087 fail2ban.actions [1]: NOTICE [gitea-docker] Ban xxx.xxx.xxx.xxx Dans mon cas, vu que je passe par le nom de domaine de Gitea, ça passe par le loopback de ma livebox, et l'ip détectée est l'IP internet de la livebox... Je ne sais pas comment faire pour que ce soit l'ip de mon PC qui soit détectée... Si quelqu'un sait... je suis preneur. Pour débannir, il faut utiliser une ligne de commande : sudo docker exec -t fail2ban fail2ban-client set bitwarden_rs unbanip xx.xx.xx.xx ou sudo docker exec -t fail2ban fail2ban-client unban <IP> ... <IP> L'effet sera constaté dans le log : 2021-04-09 17:46:14,847 fail2ban.actions [1]: NOTICE [gitea-docker] Unban xxx.xxx.xxx.xxx 2021-04-09 17:46:14,903 fail2ban.actions [1]: NOTICE [gitea] Unban xxx.xxx.xxx.xxx Y-a-t-il une autre manière de tester ? 4. Remarque et essai infructueux : J'ai tenté de créer un fichier jail.local dans le dossier fail2ban/, dont le contenu reprenait les partie [DEFAULT] histoire de ne pas avoir à placer ça dans chaque fichier .local du dossier jail.d. Mais ce fut un échec, ce fichier ne semblait pas être pris en compte. Est-ce normal ? À un moment je me suis dit que j'allais aussi mettre en place Fail2ban pour les connexions SSH, mais finalement non, je n'accède en SSH au NAS que depuis le LAN, le port SSH n'étant pas ouvert sur la box, et il a été changé. Je pense que je n'ai pas grand chose à craindre... Question : est-il possible de récupérer via une commande l'adresse IP internet en cours, et de l'injecter dans le ignoreip= ? Voilà, avez-vous des suggestions, conseils, d'autres méthodes ? 5. Fichier docker-compse.yml : ##============================================================================================== ## ## ## Docker-compose file for Fail2ban ## ## ## ##============================================================================================== --- version: "2" ##============================================================================================== ## ## ## Sources utilisées pour personnaliser ce fichier et ceux dans les sous-dossiers ## ## ## ##============================================================================================== ## ## ## https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/ ## ## https://www.linuxtricks.fr/wiki/print.php?id=40 ## ## https://github.com/dani-garcia/bitwarden_rs/wiki/Fail2Ban-Setup#synology-dsm ## ## https://github.com/sosandroid/docker-fail2ban-synology ## ## ## ##──── ──────────────────────────────────────────────────────────────────────────────────────── ##──── ──────────────────────────────────────────────────────────────────────────────────────── ## ## ## Cloner/télécharger le dépôt suivant qui contient les fichiers à utiliser : ## ## https://github.com/sosandroid/docker-fail2ban-synology.git ## ## Il faudra juste modifier le docker-compose.yml qui vient avec ou utiliser celui-ci. ## ## ## ##──── ──────────────────────────────────────────────────────────────────────────────────────── ## ## ## Pour supprimer une IP bannie, lancer la commande suivante : ## ## sudo docker exec -t fail2ban fail2ban-client set bitwarden_rs unbanip xx.xx.xx.xx ## ## ## ## Pour Voir le log de fail2ban, lancer la commande : ## ## cat /volume1/docker/fail2ban/fail2ban.log ## ## ## ## ## ## Quelques commandes utiles : ## ## docker exec -t fail2ban fail2ban-client status ## ## docker exec -t fail2ban fail2ban-client status bitwarden_rs ## ## ## ## unbans <IP> (in all jails and database) : ## ## docker exec -t fail2ban fail2ban-client unban <IP> ... <IP> ## ## ## ## docker exec -t fail2ban fail2ban-client --help ## ## docker exec -t fail2ban fail2ban-client restart ## ## docker exec -t fail2ban fail2ban-client reload --restart --unban --all ## ## ## ## flushes the logtarget if a file and reopens it. For log rotation. : ## ## docker exec -t fail2ban fail2ban-client flushlogs ## ## ## ##============================================================================================== services: fail2ban: image: ghcr.io/crazy-max/fail2ban:latest container_name: fail2ban network_mode: host environment: - TZ=Europe/Paris - F2B_DB_PURGE_AGE=30d - F2B_LOG_TARGET=/data/fail2ban.log - F2B_LOG_LEVEL=INFO - F2B_IPTABLES_CHAIN=INPUT - SSMTP_HOST=smtp.gmail.com - SSMTP_PORT=587 - SSMTP_HOSTNAME=Docker-Fail2ban - SSMTP_USER=XXxxXX@gmail.com - SSMTP_PASSWORD=XXxxXX - SSMTP_TLS=YES - SSMTP_STARTTLS=YES labels: - "com.centurylinklabs.watchtower.enable=true" volumes: - "/volume1/docker/fail2ban:/data" # Les différents chemins d'accès vers les fichiers log des services à protéger par fail2ban # On ajoute ro pour read-only (lecture seule) - "/volume1/docker/bitwarden_rs/bitwarden-data:/bitwarden:ro" # Bitwarden_RS - "/volume1/docker/gitea/data/gitea/log:/gitea:ro" # Gitea #- "/var/log/auth.log:/log/host_ssh_auth.log:ro" # SSH sur l'hôte (Synology) cap_add: - NET_ADMIN - NET_RAW restart: always