Rechercher dans la communauté

Bonjour, Tout fonctionnait très bien et maintenant j'ai une erreur "The SSL connection could not be established" pour les indexeurs dans Prowalarr ou jackett ( tester les deux pour être sur). Ils fonctionnent sur d'autres indexeurs donc le problème semble localisé .... exemple de code [v1.13.0.4217] System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception. ---> System.IO.IOException: Cannot determine the frame size or a corrupted frame was received. at System.Net.Security.SslStream.GetFrameSize(ReadOnlySpan`1 buffer) at System.Net.Security.SslStream.ReceiveBlobAsync[TIOAdapter](TIOAdapter adapter) at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm) at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.AddHttp2ConnectionAsync(HttpRequestMessage request) at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.GetHttp2ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.AuthenticationHelper.SendWithAuthAsync(HttpRequestMessage request, Uri authUri, Boolean async, ICredentials credentials, Boolean preAuthenticate, Boolean isProxyAuth, Boolean doRequestAuth, HttpConnectionPool pool, CancellationToken cancellationToken) at System.Net.Http.DiagnosticsHandler.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken) at NzbDrone.Common.Http.Dispatchers.ManagedHttpDispatcher.GetResponseAsync(HttpRequest request, CookieContainer cookies) in ./Prowlarr.Common/Http/Dispatchers/ManagedHttpDispatcher.cs:line 112 at NzbDrone.Common.Http.HttpClient.ExecuteRequestAsync(HttpRequest request, CookieContainer cookieContainer) in ./Prowlarr.Common/Http/HttpClient.cs:line 171 at NzbDrone.Common.Http.HttpClient.ExecuteAsync(HttpRequest request) in ./Prowlarr.Common/Http/HttpClient.cs:line 70 at NzbDrone.Core.Indexers.IndexerHttpClient.ExecuteProxiedAsync(HttpRequest request, ProviderDefinition definition) in ./Prowlarr.Core/Indexers/IndexerHttpClient.cs:line 41 at NzbDrone.Core.Indexers.HttpIndexerBase`1.FetchIndexerResponse(IndexerRequest request) in ./Prowlarr.Core/Indexers/HttpIndexerBase.cs:line 573 at NzbDrone.Core.Indexers.HttpIndexerBase`1.FetchPage(IndexerRequest request, IParseIndexerResponse parser) in ./Prowlarr.Core/Indexers/HttpIndexerBase.cs:line 491 at NzbDrone.Core.Indexers.HttpIndexerBase`1.TestConnection() in ./Prowlarr.Core/Indexers/HttpIndexerBase.cs:line 671 ou sur jackett J'ai tout refait: reconfiguration des certificats SSL de mon syno et de mon DDNS. testé reverse proxy ssl OK Mettre dns en 8.8.8.8 et/ou 1.1.1.1 sur le syno. sur le docker avec portainer j'ai aussi taper ce DNS Après j'ai un routeur asus que j'avais déjà configuré également en 8.8.8.8 pour être sur que pas de souci avec le fournisseur ( Bouygues) . J'ai fait le test sur mon pc Windows et jackett fonctionne donc il y a bien un problème localisé vers le docker ou syno.... J'ai aussi flaresolver pour un de mes indexeurs et tous mes dockers sont à jour aussi.... Je sèche.... Une idée? Merci

Bonjour, avant toute chose je précise que tout fonctionnait avant et que du jour au lendemain plus.... accès au syno via quickonnect OK DDNS: configuré et actif: pare-feu sur le syno désactivé certificat OK options sécurité avancées: proxy inversé ok Synchronisation de l'heure du syno OK et j'ai des messages ERR_TIMED_OUT sur google chrome quand je tente de parvenir à n'importe quel DDNS autres paramètres: J'ai testé sur chrome et edge après vidage cache, etc. http et https avec ou sans le port à la fin.... la redirection sur mon routeur est toujours présente sur le port 443. J'ai principalement pris des tutos du site de https://mariushosting.com/ et comme je l'ai dis ça fonctionnait avant! Bref je ne sais plus où chercher et donc je m'en remets à votre aide. D'avance merci

Bonjour à tous, Pour ma domotique j'ai fait l'acquisition d'une clé usb Blueetooth Sena. Elle remonte bien dans les périphériques de mon NAS Syno en DSM 7.2 Cependant si je construit un container docker en mode host et avec privilèges élevés celui-ci ne la trouve pas. J'ai le sentiment qu'il manque les drivers bluetooth côté host ce qui serait cohérent car je suis en DSM 7.2 et j'ai dû ajouter ceux pour les dongles type Zigbee/Zwave. Voici les quelques commandes lancées sur mon container host. lsusb ==> OK hciconfig ==> NOK Mon NAS est un 1819+, avez-vous une idée de ce qu'il peut manquer ? Merci d'avance pour votre aide. Manu

Bonjour à tous, Ce forum est une mine d'information, merci à tous pour vos partages 🙂 J'utilise abusivement de Docker (container manager) sur mon DS1819+ et j'en apprends petit à petit les subtilités. J'ai créé récemment un Macvlan sur lequel j'héberge entre autre les containers liés à ma domotique (mqtt, jeedom, ...). Mon container Jeedom est associé à l'IP 192.168.1.204, je l'ai spécifié dans le projet docker-compose. Je souhaite ajouter un chemin de type "host_absolute_path" ce que l'interface de container manager ne permet pas, il n'autorise que des chemins de type "host_volume_file". Pour contourner celà, j'ai exporté la configuration de mon container puis édité le fichier de configuration à la main pour ensuite l'importer en tant que nouveau container. J'aimerai maintenant attribuer l'IP 192.168.1.204 à ce nouveau container en lieu et place du container initial Jeedom que j'avais créé et là je coince, je ne sais pas comment faire sans avoir à recréer mon container depuis le docker-compose ce que je veux éviter. Je me suis promené dans le chemin /volume1/@docker/network/files et le fichier local-kv.db n'est évidemment pas éditable. Avez-vous une astuce pour celà ? Un grand merci par avance pour le coup de pouce !!! Manu

Comme demandé dans le post en en-tête : Niveau : utilisateur confirmé en informatique générale, mais néophyte sur Synology Image : https://hub.docker.com/r/windev/hfsql Interface : Interface Docker de Synology : Container Manager --- Bonjour, Un peu nouveau sur Synology, je m'essaie a configurer mon nouveau 723+. Je dois mettre en place un serveur de base de donnée HFSQL, pour cela j'ai téléchargé l'image et créer un conteneur. La base fonctionne, je n'ai pas de soucis fonctionnel. Par contre ... je n'arrive pas a mapper le répertoire des données (qui est /var/lib/hfsql/ selon les infos sur le serveur) a un fichier accessible par FileStation. J'ai tenté de modifier directement le chemin des données en "/volume1/Datas/12 - HFSQL -bases" depuis l'interface de la base de données, mais j'ai une erreur "Access Denied" J'ai un peu de peine a voir comment empoigner le truc, les infos trouvées ne correspondent pas à ma version de Container Manager, mais Docker, , tout ce que j'arrive a faire quand je fais des tests de mapping, c'est : Le conteneur windev-hfsql-1 s'est arrêté de manière inattendue. Accédez à Container Manager pour plus d'informations et il n'y a pas d'infos dans le journal ... C'est bien à l'endroit en rouge (image ci-dessous) que cela se défini ou je suis complètement à côté. Une idée ? je tourne vraiment en rond ... et je n'ose pas trop mettre en place des données sans avoir tous les paramètres OK ... Merci d'avance

J'ai re-créé dans la partie Projet de Container Manager une image de Portainer. C'était pour tester le Projet mais aussi parce que, à ma connaissance on ne peut pas créer une instance de Portainer à l'aide de Portainer (c'est l'oeuf ou la poule ?). Le projet facilite vraiment le déploiement d'un container parce que tout est géré au même endroit. On peut créer le docker-compose à partir d'une feuille blanche en se servant de l'éditeur de texte de DSM ou télécharger le fichier depuis un Mac ou un PC. Le docker-compose fait partie du projet et on peut le visualiser à tout moment en cas de besoin. Après, on peut créer le container à partir de son image puis le lancer. Le principal avantage est que l'on n'a plus à se connecter en SSH puis à se déplacer dans le bon dossier pour démarrer le container. Tout se fait à travers l'interface graphique de Container Manager et cela évite bien des va-et-vient. On peut arrêter le container, modifier le docker-compose puis relancer le container. Bref cela rend les choses bien plus simples même si l'outil est moins puissant que Portainer pour faire des déploiements à grande échelle.

1. Préambule Mopidy est un serveur musical open source et modulaire permettant de streamer localement votre musique, ainsi que d'intégrer un nombre conséquent de services de streaming audio tels que Soundcloud, Youtube, Youtube Music, Tidal, etc... (Spotify n'est plus pris en charge actuellement). Il intègre également de nombreux protocoles de communication : mqtt, json rpc, tcp, etc... et le rend donc adapté à un large panel d'utilisations. Iris est une extension web de Mopidy, qui fournit une interface graphique moderne et l'intégration de différentes extensions de Mopidy et autre protocoles. Snapcast, enfin, qui est un logiciel permettant la diffusion de musique par le réseau. C'est une alternative libre et bon marché à des systèmes tels que ceux proposés par Sonos ou Apple. C'est un tutoriel que j'essaie de rédiger depuis un petit temps déjà, mais : je ne voyais pas comment présenter ça de façon simple et compréhensible par tous je n'étais pas satisfait des images Docker existantes l'intégration de Snapcast avec Iris n'était pas heureuse via Docker Depuis, une image Docker facilitant l'interconfiguration des services a été publiée, et me permet aujourd'hui de vous présenter cette pépite. 2. Objectifs Si vous naviguez un peu sur le site de Mopidy, vous verrez qu'un nombre conséquent d'intégrations sont possibles, de fait, je ne vais pas m'étendre sur tout ce qu'on peut réaliser, mais plutôt sur la fonctionnalité diffusion multiroom, qui n'est pas forcément bien documentée que ce soit sur le Github d'Iris ou de Snapcast. Encore moins dans le cadre d'un NAS, qui est pourtant une idée relativement logique dans le cadre d'un serveur de musique centralisé. Ce qui sera abordé dans ce tutoriel : L'installation et la configuration de deux instances de Mopidy (à multiplier suivant le nombre de flux différents que vous souhaitez pouvoir diffuser) La diffusion de bibliothèque musicale locale La configuration des clients Ce qui sera abordé dans un second temps si engouement pour le sujet : L'utilisation d'un proxy inversé avec Iris => quelques bugs que je trouve personnellement gênants mais certains y tiendront sûrement 😉 L'intégration des différents services de streaming online supportés par Mopidy (voir extensions) => chaque extension possède sa propre manière d'être configurée, voir la doc associée ; dans tous les cas cela passe par la modification des fichiers mopidy.conf et l'ajout de fichiers supplémentaires parfois 3. Principe de fonctionnement Configuration du système : Une seule interface pour accéder aux différentes instances, à laquelle on accède depuis PC, mobile, tablette, etc... Des clients Le NAS, qui hébergera les différents services Remarque : Un client statique est un client de type "headless", qui n'accèdera pas à l'interface d'Iris mais recevra uniquement le flux depuis Snapcast. Un client dynamique peut être le smartphone avec lequel vous ajoutez des morceaux en liste de lecture, il peut également devenir un périphérique recevant des informations de Snapcast. 5. Prérequis Difficulté : Moyenne Un NAS compatible Docker Des clients Ports 1780, 6600, 6700, 6680 et 6780 (si deuxième instance) du NAS accessibles aux clients 6. Hypothèses IP du NAS : 192.168.100.100 FQDN (nom d'hôte avec domaine) du NAS : nas.xxxxxx.synology.me => à adapter à votre domaine utilisé en local (voir tutoriel sur la mise en place d'un serveur DNS local) 7. Installation 7-A. Fichier compose L'installation se fera principalement en SSH. Avec la version 7.2 de DSM, il est possible de rédiger le fichier compose via l'interface de Container Manager (nouveau nom du paquet Docker), restent certaines commandes qui ne peuvent être accomplies que par terminal, à vous de voir ce que vous préférez, si vous savez le faire en lignes de commande vous n'aurez aucune difficulté à le faire via Container Manager. Vous pouvez consulter mon tutoriel introductif à Docker pour plus d'informations sur les étapes qui vont suivre. Et maintenant, c'est parti ! On crée le dossier pour Iris dans le dossier partagé docker : mkdir -p /volume1/docker/iris Puis on crée le fichier compose : nano /volume1/docker/iris/docker-compose.yml Remarques : On regroupe tout dans une seule stack, les services n'ayant pas vocation à fonctionner individuellement On se place sur l'hôte directement, pour faciliter la détection en broadcast sur le réseau local // IMPORTANT \\ On ne peut pas directement monter le dossier partagé "music" dans le conteneur, c'est valable pour tout autre dossier partagé a fortiori. Et ce, pour des raisons de permission : en effet les dossiers partagés ne sont pas soumis aux ACL de DSM Donc par exemple, créer un dossier intermédiaire, "bibliothèque" dans mon cas // IMPORTANT \\ On différencie l'emplacement des playlists qu'on va créer de l'emplacement des musiques car : on va chowner le dossier contenant les playlists Mopidy, on évite de faire ça sur un dossier utilisé par d'autre programmes on va monter notre médiathèque en lecture seule pour éviter toute modification accidentelle, ce qui en revanche posera problème pour des playlists qu'on sera amené à modifier J'ai nommé mes instances "iris-instance1" et "iris-instance2", à adapter à votre guise dans la suite du tutoriel. Je crée un dossier "local" commun, qui contiendra les métadonnées des morceaux scannés, ça m'évitera de devoir scanner pour chaque instance. Si pour une raison ou une autre, vous ne souhaitez pas disposer de la même bibliothèque sur l'une et l'autre des instances, créez deux dossiers "local" dans instance1 et instance2. La variable d'environnement PIP_PACKAGES est utile pour installer des extensions Mopidy supplémentaires, commentée par défaut car intégrations non traîtées ici. 7-B. Préparation des dossiers et fichiers 7-B-1. Dossiers de configuration Pas spécialement adapté pour s'installer sur un NAS, OS base Linux avec ses restrictions, on va créer en amont les dossiers dont les services auront besoin lors de la création de la stack. En SSH, connectez-vous avec un utilisateur disposant des droits d'écriture dans le dossier partagé docker : mkdir -p /volume1/docker/iris/instance1/config \ /volume1/docker/iris/instance1/data \ /volume1/docker/iris/instance2/config \ /volume1/docker/iris/instance2/data \ /volume1/docker/iris/snapserver \ /volume1/docker/iris/local \ /volume1/docker/iris/playlists On va maintenant changer la propriété des dossiers pour respectivement : pouvoir télécharger les métadonnées de nos morceaux, albums, artistes, etc... écrire et modifier des playlists Mopidy ajouter des token d'identification pour les services de stream online (non traîté ici) sudo chown 105:users /volume1/docker/iris/instance1/config \ /volume1/docker/iris/instance1/data \ /volume1/docker/iris/instance2/config \ /volume1/docker/iris/instance2/data \ /volume1/docker/iris/local \ /volume1/docker/iris/playlists Remarque : L'utilisateur d'ID 105 est celui qui écrira dans ces dossiers, or il n'est évidemment pas repris par les ACL DSM, donc pour ne pas toucher aux ACL Synology et garantir l'accès aux dossiers en question, on ne chmod pas mais on chown. 7-B-2. Fichiers de configuration On va créer un fichier de configuration qui écrasera les paramètres par défaut du serveur Mopidy, pour l'adapter à notre besoin. 7-B-2-a. Instance1 nano /volume1/docker/iris/instance1/config/mopidy.conf 7-B-2-b. Instance2 nano /volume1/docker/iris/instance2/config/mopidy.conf Remarques : Dans instance1, on pense à modifier nas.xxxxxx.synology.me par son nom de domaine Dans instance2, on a modifié le port de l'instance pour éviter la collision avec la première, on utilise le port 6780 7-B-2-b. Snapserver On va télécharger le fichier de configuration depuis le Github : wget https://raw.githubusercontent.com/badaix/snapcast/master/server/etc/snapserver.conf -P /volume1/docker/iris/snapserver/ qu'on édite ensuite : nano /volume1/docker/iris/snapserver/snapserver.conf en commentant la ligne (on ajoute un # devant) : source = pipe:///tmp/snapfifo?name=default et on ajoute les lignes suivantes directement à la suite : source = pipe:///tmp/stream1_fifo?name=STREAM1&controlscript=meta_mopidy.py&controlscriptparams=--mopidy-host=nas.xxxxxx.synology.me source = pipe:///tmp/stream2_fifo?name=STREAM2&controlscript=meta_mopidy.py&controlscriptparams=--mopidy-host=nas.xxxxxx.synology.me%20--mopidy-port=6780 Remarque : On pense à modifier nas.xxxxxx.synology.me par son nom de domaine On va également télécharger le script python faisant le lien entre Iris et Snapcast : wget https://raw.githubusercontent.com/badaix/snapcast/master/server/etc/plug-ins/meta_mopidy.py -P /volume1/docker/iris/snapserver/ 7-B-3. Dossiers de stream On crée un dossier qui accueillera nos fifo de stream Snapcast, et je les rends accessible par tous en écriture : mkdir -p /tmp/snapserver && sudo chmod 777 /tmp/snapserver 7-C. Création de la stack On est prêt, plus qu'à lancer la stack : sudo docker-compose -f /volume1/docker/iris/docker-compose.yml up -d && sudo docker-compose -f /volume1/docker/iris/docker-compose.yml logs -f Les logs devraient donner quelque chose de la sorte : 8. Interface IRIS 8-A. Configuration générale et Instance1 On se rend maintenant à l'adresse http://nas.xxxxxx.synology.me:6680: On se dirige ensuite vers les Settings, catégorie Server, et on renomme l'instance : On va ensuite dans Services configurer Snapcast, on modifie localhost pour le nom d'hôte de notre NAS, et on coche Enabled : On peut également se connecter à LastFM pour récupérer les vignettes des artistes, et à Genius pour que les paroles des chansons défilent pendant la lecture. // IMPORTANT \\ La librairie utilisée pour Mopidy n'est plus supportée par Spotify, évitez donc de vous y connecter. Dans Interface, j'aime bien généralement cocher "Wide scrollbars". 8-B. Instance2 On va maintenant rajouter notre seconde instance, vers laquelle on pourra facilement switcher d'un clic, on retourne dans Server, on clique sur "+ Add New Server" : Si tout s'est correctement exécuté auparavant, vous devriez obtenir le statut Connected, vous remarquerez également que les réglages des autres catégories persistent. 8-C. Exportation et sauvegarde de la configuration sur le serveur Afin d'éviter de répéter la majorité de ces étapes pour les prochains clients dynamiques, on peut aller dans la catégorie Advanced -> Share configuration => Export/share : Vous pourrez dorénavant importer la configuration depuis le serveur (il faut prélablement se connecter à une des instances depuis un nouveau périphérique) en cliquant sur Import from server. Cela ne fonctionne que pour les paramètres généraux, la deuxième instance devra être ajoutée comme initialement. 8-D. Indexation des morceaux On va maintenant lancer l'indexation des morceaux, on peut le faire par l'interface, suivant le CPU ça peut prendre plus ou moins de temps, comptez environ 1m30 par 1000 morceaux. Pour cela, deux méthodes : via le terminal : sudo docker exec -it iris-instance1 mopidy local scan Ou si je veux faire un test avec un nombre réduit de morceaux : sudo docker exec -it iris-instance1 mopidy local scan --limit 100 via l'interface, dans Advanced, on clique sur Start local scan (full scan par contre) : Une fois le scan terminé, je peux aller dans l'onglet Albums, et cliquer sur Refresh tout en haut à droite de la fenêtre : On va faire clic droit sur un album -> Add to queue, les morceaux sont maintenant dans l'onglet Now playing, en attente d'un ordre de lecture. 8-E. Lecture synchronisée Voilà, il ne reste plus qu'à tester, oui mais où ? et bien sur notre périphérique ! on retourne dans Settings -> Services -> Snapcast -> on coche Streaming enabled : Je peux renommer mon groupe, rez-de-chaussée (RDC) par exemple, et lui dire qu'il diffusera le flux Snapcast STREAM1, émis par Instance1. Dans ce groupe, j'ai renommé mon périphérique appelé par défaut "Snapweb client" en PC, plus parlant. Je vais maintenant ajouter un deuxième périphérique, par exemple mon smartphone, je vais donc importer les données de configuration précédemment enregistrées sur le serveur. En cliquant sur Streaming enabled, un nouveau groupe apparaît (j'ai renommé mon périphérique du nom de mon smartphone) : Allons maintenant dans Now playing, et lançons la musique depuis la barre de lecture en bas de page. Si tout se passe bien, vous devriez entendre la musique jouée conjointement, et en parfaite synchronisation, depuis les deux clients ! Pourquoi ne pas, par exemple, les mettre dans le même groupe ? On clique sur Group dans la tuile correspondant au 2ème périphérique (voir impression d'écran ci-dessus), et on choisit RDC. Maintenant, on peut contrôler le volume général du groupe depuis Volume (barre horizontale) et le volume individuel de chaque périphérique sinon (barre verticale). Si je ne veux plus qu'ils soient groupés, je reclique sur Group, puis New Group. Je peux également changer le flux lu par un groupe depuis Stream. Pas tout à fait synchronisés ? la barre de Latency est là pour ça, on peut ajuster le décalage en avance ou retard de phase des périphériques indépendamment. C'est notamment une fonction utile pour les périphériques clients qui diffusent via Bluetooth. 8-F. Playlists 8-F-1. Playlist locale Pour créer une playlist, je clic droit sur un morceau, Add to playlist -> je crée une nouvelle playlist ou j'en choisis une existante. Il faudra ensuite aller dans l'onglet Playlists et cliquer sur Refresh comme pour les albums pour les voir apparaître. 8-F-1. Radios Je vais vider ma liste d'attente, pour cela je clique sur Clear : Dans cette page, je clique ensuite sur Add en haut à droite, je vais ajouter l'URL d'une radio, par exemple M Disney : Je dois cliquer sur + Add à droite avant de cliquer Add en bas, la radio apparaît ensuite dans la liste des morceaux en attente, et je peux cliquer droit (ou ...) pour lancer la lecture ou pour l'ajouter à une playlist. 9. Configuration des clients statiques Nous allons maintenant voir comment configurer des clients statiques, par exemple sous Linux. sudo apt-get install snapclient Puis : sudo nano /etc/default/snapclient # Start the client, used only by the init.d script START_SNAPCLIENT=true # Additional command line options that will be passed to snapclient # note that user/group should be configured in the init.d script or the systemd unit file # For a list of available options, invoke "snapclient --help" SNAPCLIENT_OPTS="--host nas.xxxxxx.synology.me" Je lance le service : sudo systemctl start snapclient.service Je fais en sorte qu'il se lance au démarrage : sudo systemctl enable snapclient.service Entre temps, vous devriez voir un nouveau périphérique parmi les clients Snapcast dans votre interface Iris. 10. Quelques commandes utiles Pour supprimer la base de métadonnées : sudo docker exec -it <nom du conteur iris> mopidy local clear Pour vérifier la configuration utilisée par une instance (celle-ci affichera tous les champs, ceux par défaut et ceux que vous avez écrasés dans votre fichier de configuration) : sudo docker exec -it <nom du conteur iris> mopidy config 11. Conclusion Je ne couvre dans ce tutoriel qu'une petite partie des fonctionnalités disponibles, on peut trier les recherches suivant les sources, ce qui prend son importance si l'on commence à intégrer différents services de streaming. Il existe une extension MopiQTT(non officielle) qui prend en charge MQTT, ou encore la possibilité de créer des webhooks via Commands => Add : Ainsi qu'un module HomeAssistant : https://github.com/bushvin/hass-integrations Pour ceux qui sont un peu initiés, les possibilités domotiques sont énormes. MàJ : 06/06/2023

Bonjour, et désolé d'avance pour ma question du jour ! J'ai installé Freshrss car Feedly c'est bien mais payer 9 €uros par moi pour générer des recherches sur mes flux je trouve cela abuser. Donc, j'ai installé Freshrss sur Docker, n'en revenant pas moi même de mon exploit. Il est donc installé sur le port 8080 J'y accède sans problème à partir de l'IP locale du NAS 192.168.1.xxx:8080. Cool Mais pour y accéder de l'extérieur cela ne fonctionne pas, contrairement d'ailleurs aux applications Syno qui sont très fluides à travers l'adresse nomNAS.synology.me:5001 par exemple Ma question : est il possible d'assigner une adresse nomNAS.synology.me:8080 à mon conteneur Docker ? Ou bien est ce un problème de redirection de port sur la Freebox qui m'empêche de me connecter à 85.xxx.xxx.xxx:8080 ? Au pire, puisque je peux accéder à mon bureau DSM sur mon tél ou mon PC Maison, comment créer un raccourci bureau pour une application sous Docker afin d'y accèder de l'extérieur? Merci d'avance et une belle journée.

Bonjour, je fais tourner sur mon NAS des docker. Un serveur Minecraft, et un relai Tor. Je dois absolument les sauvegarder sur mon ordi, histoire que si il y avait un problème, que les données ne soient pas perdus. Mais en l'exportant simplement, je n'arrive pas à les lancer. Des messages d'erreurs etc. Comment je peux faire pour sauvegarder ces conteneur ?

Bonsoir, @.Shad. voilà donc un nouveau sujet où l'on va pouvoir discuter de Crowdsec. Tu as définitivement abandonné Fail2ban au profit de Crowdsec ? Peut-on discuter de Crowdsec ici ? Ou mieux vaut-il créer un sujet dédié ? (et dans quelle section ?) Pour débuter ce sujet, voilà comment je l'ai installé. J'utilise SWAG comme reverse proxy sur mon 920+, installé avec le tuto de @.Shad., mais dans SWAG, je n'utilise pas le Fail2ban intégré. Précision importante : mon SWAG est en macvlan. Et j'ai suivi ce tuto pour installer Crodwsec. Voici ci-dessous un petit résumé. J'ai ajouté ce qui suit dans le docker-compose : crowdsec: container_name: crowdsec image: crowdsecurity/crowdsec # https://hub.docker.com/r/crowdsecurity/crowdsec # https://github.com/crowdsecurity/crowdsec networks: crowdsec_network: ipv4_address: 172.19.0.2 restart: unless-stopped environment: - TZ=Europe/Paris - COLLECTIONS=crowdsecurity/nginx - GID=100 - CUSTOM_HOSTNAME=Crowdsec_sur_Syno-DS920+ depends_on: - swag volumes: - /volume4/docker/swag_macvlan/config/log/nginx/access_adguardhome.log:/var/log/nginx/access_adguardhome.log - /volume4/docker/swag_macvlan/config/log/nginx/access_gitea.log:/var/log/nginx/access_gitea.log - /volume4/docker/swag_macvlan/config/log/nginx/access.log:/var/log/nginx/access.log # - /volume4/docker/swag_macvlan/config/log/nginx/access_nextcloud.log:/var/log/nginx/access_nextcloud.log - /volume4/docker/swag_macvlan/config/log/nginx/access_tautulli.log:/var/log/nginx/access_tautulli.log - /volume4/docker/swag_macvlan/config/log/nginx/access_vaultwarden.log:/var/log/nginx/access_vaultwarden.log - /volume4/docker/swag_macvlan/config/log/nginx/error_adguardhome.log:/var/log/nginx/error_adguardhome.log - /volume4/docker/swag_macvlan/config/log/nginx/error_gitea.log:/var/log/nginx/error_gitea.log - /volume4/docker/swag_macvlan/config/log/nginx/error.log:/var/log/nginx/error.log # - /volume4/docker/swag_macvlan/config/log/nginx/error_nextcloud.log:/var/log/nginx/error_nextcloud.log - /volume4/docker/swag_macvlan/config/log/nginx/error_tautulli.log:/var/log/nginx/error_tautulli.log - /volume4/docker/swag_macvlan/config/log/nginx/error_vaultwarden.log:/var/log/nginx/error_vaultwarden.log - /volume4/docker/swag_macvlan/config/log/nginx/unauthorized.log:/var/log/nginx/unauthorized.log - /volume4/docker/swag_macvlan/crowdsec/acquis.yaml:/etc/crowdsec/acquis.yaml - /volume4/docker/swag_macvlan/crowdsec/crowdsec-db:/var/lib/crowdsec/data/ - /volume4/docker/swag_macvlan/crowdsec/crowdsec-config:/etc/crowdsec/ security_opt: - no-new-privileges=true # ############### # Le label ci-dessous permet à Watchtower de faire les mises à jour automatiquement # Cela peut-être supprimé si Watchtower n'est pas utilisé. labels: - "com.centurylinklabs.watchtower.enable=true" # ############### ports: - 8080:8080 J'ai aussi ajouté ceci dans les variables environnements de SWAG : # MODs used : - https://github.com/linuxserver/docker-mods/tree/swag-auto-reload # - https://github.com/linuxserver/docker-mods/tree/swag-dashboard # - https://github.com/linuxserver/docker-mods/tree/swag-maxmind # - https://docs.theme-park.dev/setup/#swag-docker-mod # - https://github.com/linuxserver/docker-mods/tree/swag-crowdsec - DOCKER_MODS=linuxserver/mods:swag-auto-reload|linuxserver/mods:swag-dashboard|linuxserver/mods:swag-maxmind|ghcr.io/gilbn/theme.park:swag|linuxserver/mods:swag-crowdsec - TP_COMMUNITY_THEME="true" - CROWDSEC_API_KEY=xxxxxxxxxxxxxxxxx - CROWDSEC_LAPI_URL=http://192.168.2.230:8080 - MAXMINDDB_LICENSE_KEY=xxxxxxxxxxxxxxxx Note : Certains mods ne sont pas nécessaires pour Crowdsec 😉. J'ai donc du installer le bouncer dans swag en ligne de commande, voir instructions ici : https://github.com/linuxserver/docker-mods/tree/swag-crowdsec#mod-usage-instructions Ça m'a généré la clé API qu'il a fallu mettre dans CROWDSEC_API_KEY. Vous aurez remarqué que j'ai passé pas mal de fichiers .log dans le conteneur Crowdsec pour qu'il les surveille. Pour cela, j'ai ajouté dans les fichiers .conf du reverse proxy : # Custom error files access_log /config/log/nginx/access_adguardhome_syno.log; error_log /config/log/nginx/error_adguardhome_syno.log; Je me suis dit que ça pourrait aider à diagnostiquer un souci avec Crowdsec d'avoir des fichiers logs séparés pour mes applications web. ________________________________________ Mais voilà, Crowdsec est très bien, mais beaucoup trop sensible. @.Shad. Comment as-tu configuré les bouncers ? (si tant est qu'on puisse les configurer...) Car ça m'arrive très souvent de m'auto-bannir en oubliant de fermer le navigateur dédié aux services du NAS dont certains sont en accès restreint aux IP LAN et VPN... ça génères des erreurs 403 dans les logs, et paf, Crowdsec me ban ! J'ai dû sortir les logs concernant DSM et d'autres services Synology de l'analyse de Crowdsec. J'ai même dû sortir de l'analyse de Crodwsec les logs de Nextcloud, car même si ce service est accessible depuis internet, ça engendrait quasi systématiquement des BANs. Bref, voilà. Comment utilisez-vous Crowdsec ? Comment l'avez-vous configuré ? ... Merci d'avance, et bonne fin de WE. PS : un autre sujet arrivera pour parler de Fail2ban qui bien que bannissant une IP, présente ensuite dans iptables, cette dernière peut toujours accéder aux services...

Bonjour à tous, Depuis quelques temps, je cherche à configurer un conteneur "Jeedom" sous docker et via docker-compose. Je n'y arrive absolument pas ! J'ai également essayé en VM et malheureusement, même résultat... A noter que je n'utilise pas de périphérique USB (pour le moment en tout cas). Je dispose déjà d'un réseau macvlan avec 2 ou 3 adresse IP de disponible. Est-ce que quelqu'un a déjà configuré ça et pourrait m'aider ? Merci !!!

Bonsoir , J'ai installé Calibre-web sur Docker en suivant le tuto de @quart-temps L'interface en DSM 7.1 est un peu différente mais on y arrive. J'ai bloqué pas mal de temps sur l'interface Calibre pour sélectionner la base de données. J'avais au préalable copié une bibliothèque dans un répertoire partagé. Pour ne pas avoir l'erreur 'DB Location is not Valid. Please Enter Correct Pass' , il faut sélectionner '/books' , parcourir le répertoire et sélectionner le fichier 'metadata.db' Pour ne pas avoir l'erreur 'DB Location is not Valid' il faut cocher les droits en lecture-écriture sur le répertoire pointé par '/books' En local tout fonctionne parfaitement sur l'adresse 192.168.1.20:8083 Par contre en accès externe rien ne fonctionne chez moi ... 1er essai - Web Station Par le portail de service web j'ai créé un 'portail du serveur de paquet' avec Docker Un clic sur l'icone bleue ouvre bien calibre en local Mais l'url : 'https://toto.synology.me/ebook' me retourne une erreur 404 Un ping sur 'https://toto.synology.me' me renvoie bien mon IP publique. 2 ème essai - Proxy inversé Par le portail de connexion j'ai créé un proxy inversé l'URL 'https://ebook.toto.synology.me' me retourne cette page Voilà où j'en suis ... Je dois faire une mauvaise manip, mais où ? edit : modifié la remarque sur '/books'

Bonjour à tous, Est ce que vous savez ou je peux trouver un tuto ou m'expliquer comment installer une app avec via un conteneur dans docker ( via synology). A chaque fois que j'essaie je n'arrive pas réussir l'installation. Par exemple je souhaiterais installer n8n ?

Bonjour, j'ai vu qu'il y a possibilité de brancher un tunner HdHomeRun sur un réseau, et d'y avoir accès dans Vidéo Station. Pratique pour enregistrer des émissions, ou les regarder en direct.... mais voilà, je suis pas trop tenté d'acheter un tunner. Alors j'ai cherché sur internet dans le hub de docker des images. Mais j'ai pas trouvé grand chose Est ce qu'il n'y a pas un moyen de simuler dans docker ou directement en ssh sur le NAS, un tunner pour avoir la tnt grâce à internet ? Et pour l'enregistrer dans vidéo Station. Après si ce n'est pas possible dans Vidéo station, je peux toujours utiliser d'autres plateformes comme Plex, etc....

Bonjour @.Shad. @oracle7 @maxou56 (je vous cite car je sais que vous êtes bien doué avec docker ^^) Je cherche une méthode fiable de déplacement du paquet Docker de mon volume1 vers un volume4 qui est sur SSD, avec le déplacement des données du dossier /docker. Pour déplacer le dossier docker, c'est facile, il y a une option dans DMS pour, mais pas pour un paquet. Je ne suis pas contre la désinstallation et la réinstallation, mais je n'ai pas de procédure fiable pour... Est-ce que quelqu'un pourrait me guider/aider ? Merci d'avance 🙂

Salut, Je cherche le moyen le plus pratique pour moi de faire du partage de photos avec mes proches depuis mon smartphone iOS. Je souhaite partager certaines photos que je sélectionne dans ma galerie photos de iOS , pas toutes. Il faut que l’application utilisée sur le nas puisse avoir des utilisateurs qui n’ont accès qu’en lecture seule. Avec possibilité de commentaires. Synology Photos ne me convient pas car quand je partage une photo avec, ça va dans le dossier personnel et pas moyen de partager cette photos avec d’autres. De plus je préfère ne pas utiliser un compte dsm. Il faudrait donc que l’application utilisée puisse être disponible sur iOS afin de pouvoir partager rapidement une photo avec elle, sans devoir exporter les photos sur un ordinateur et de les importer ensuite sur une interface web. Ou bien il faudrait pouvoir importer une photo depuis l’interface de l’application une photos depuis la galerie photos. Il faut aussi que l’application ne soit pas l’usine à gaz , car j’ai des utilisateurs pas dégourdi a qui partager les photos… donc ils faut qu’ils aient accès aux photos dès la connexion au service. L’objectif étant de se passer de Google Photos. Ps : J’utilise déjà Docker, mais je ne fais pas quoi choisir. Merci pour vos conseils

Bonjour à tous, j'espère être sur le bon forum et m'en excuse si ce n'est pas le cas. j'avais déjà installé une machine virtuelle sur mon nas synology ds918+ configuré avec un proxy inversé et un certificat let's encrypt (tout fonctionnel mais reverse proxy redirigé vers ip) mais ce ne semble pas fonctionner pareil pour un docker... Aussi j'aurais besoin dune âme charitable pour savoir ce je ne fais pas bien j'ai donc créer un conteneur pour bitwarden sur le docker et attribué des ports j'ai par ailleurs configuré le reverse proxy (j'ai juste effacé mon nom de domaine) j'ai également bien ajouté le port 843 sur mon routeur pointé vers l'adresse de mon serveur (j'ai rien mis pour le port 89...) et enfin dans les certificats et plus précisément celui de letsencrypt je retrouve mon nom de domaine xxxxx pointant vers mon domaine (mais ici je trouve bizarre que c'est xxxx.synology.me avec à la fin : le port sauf que je voila je peux me connecter et je suis bien redirigé vers bitwarden mais le navigateur m'indique que ce n'est pas sécurisé pourtant quand je clic sur l'Astérix rouge et qu'après je clic sur certificat non valide et chemin d'accès de certificat j'ai donc en gros je me connecte c'est a priori sécurisé mais sans l'être donc une idée svp??? car je ne suis pas rassuré de l'utiliser en l'état Merci à vous et bonne journée

Bonjour, Il est possible d'installer Docker et Virtual Machine Manager sur les DS418Play et probablement sur les DS416Play (pas testé) qui sont en fait respectivement des versions 4 baies des DS218+ et DS216+II bridés logiciellement. 1- Docker DSM6 et DSM7: Pour docker c'est simple il suffit de l'installer manuellement, seul limitation, les MAJ ne seront pas proposées, il faudra donc les faire manuellement. (c'est aussi valable pour d'autres paquets comme CMS). Pour l'obtenir: https://www.synology.com/fr-fr/support/download/DS218+?version=7.0#packages ou https://archive.synology.com/download/Package/Docker (A noter, même si ce n'est plus d'actualité (max DSM 6.2.3), DDSM était aussi possible, mais il fallait aussi activer Open vSwitch, donc voir méthode Virtual machine manager) 2- Virtual Machine Manager sur DSM7: Pour Virtual Machine manager, c'est un peu moins simple, car il faut activer Open vSwitch. Et donc il faut modifier le fichier "/etc.defaults/synoinfo.conf" pour autoriser open vSwitch. Ce qui n'est pas anodin et peut comporter des risques. Sur DSM 7 la ligne support open vSwitch est déjà présente mais marqué comme "no", il faut donc remplacer "no" par "yes". Puis on pourra activer Open vSwitch, dans Panneau de configuration > Réseau > Interface réseau > gérer > Paramètres d'Open vSwitch. Comme les MAJ de DSM risque de remettre le fichier "/etc.defaults/synoinfo.conf" à zéro, ça ne pose normalement pas de problème, une fois Open vSwitch activé il le reste. Donc le plus simple pour modifier, c'est de créer un tache déclenché au démarrage avec l'utilisateur root: sed -i 's/support_ovs="no"/support_ovs="yes"/g' /etc.defaults/synoinfo.conf Ou en SSH et en root, remplacer "no" par "yes" de la ligne support_ovs="no" du fichier /etc.defaults/synoinfo.conf Puis de l'exécuter manuellement, normalement en quittant le panneau de configuration et en rafraichissant la page, le menu Open vSwitch apparaitra dans Panneau de configuration > Réseau > Interface réseau, si ce n'est pas le cas redémarrer le NAS. Après il faudra télécharger Virtual Machine Manager, puis l'installer manuellement, le paquet Virtual machine manager nécessite le paquet "réplication service", qu'il bien faut installer avant. Et comme pour Docker les MAJ, ne seront pas proposées, il faudra les faire manuellement. Pour l'obtenir: https://www.synology.com/fr-fr/support/download/DS218+?version=7.0#packages ou https://archive.synology.com/download/Package/Virtualization (A noter, c'est aussi possible sur DSM6, mais la ligne support_ovs="no" n'existe pas, il faut donc ajouter une ligne support_ovs="yes" dans le fichier /etc.defaults/synoinfo.conf en SSH et en root)

Bonjour, Suite aux tuto de .Shad, j'ai décider de me mettre à docker en commençant par NextCloud que je voulais tester. Niveau : Première fois Image : https://hub.docker.com/r/linuxserver/nextcloud Interface : docker-compose Mode réseau : MacVLAN docker-compose.yml : --- version: "2.1" services: nextcloud: image: linuxserver/nextcloud container_name: nextcloud networks: macvlan_network: ipv4_address: 192.168.0.225 environment: - PUID=1026 - PGID=100 - TZ=Europe/Paris volumes: - /volume1/docker/nextcloud/config:/config - /volume1/docker/nextcloud/data:/data ports: - 443:443 restart: unless-stopped networks: macvlan_network: external: name: macvlan-network (l'adresse 192.168.0.225 appartient bien au macvlan) Jusque là, pas de problème... Mais, dans l'interface de Docker de DSM, dans l'onglet Conteneur, j'ai un vilain message "aucun conteneur n'a été créé", toutefois, dans l'onglet réseau, le "macvlan-network" fait bien tourner le conteneur nextcloud. Est-ce dû au fait que j'ai utilisé docker-compose plutôt que l'interface graphique de docker sur DSM ? Bref, je ping bien le conteneur (192.168.0.225), d'ailleurs, quand je m'y connecte en HTTPS (par l'ip), j'ai bien l'alerte du problème de certificat. Quand je le valide, j'ai un beau 404. Quelqu'un aurait-il une idée sur ce problème (et si quelqu'un sait pourquoi l'interface de docker me dit que je n'ai pas de conteneur) ? Autre question, au passage, est-ce que je peux utiliser un utilisateur non admin avec les droits sur le dossier docker pour faire tourner les conteneurs ? Merci beaucoup par avance Taribam

1. Préambule Ce tutoriel a pour but d'autoriser l'accès aux données du NAS via le protocole SMBv1 (ou NT1) sans pour autant impacter le niveau de sécurité d'accès au NAS. Cela permet d'assurer la compatibilité d'équipement qui n'auraient pas été mis à jour par leur fabricant. SMBv1 est un protocole déprécié et comportant des failles de sécurité. Lorsqu'il est possible de vous en passer, faites-le. 2. Prérequis Avoir un NAS compatible Docker, voir la liste ici. Savoir se connecter au NAS via SSH en root : Utiliser Docker-compose Avoir installé le paquet SynoCLI File Tools, pour ajouter le dépôt SynoCommunity voir la partie Easy Install sur cette page. IMPORTANT : Si vous souhaitez accéder aux dossiers partagés "music", "video", etc... à la racine tels quels, ça ne pourra pas fonctionner, il faudra monter des sous-dossiers de ces dossiers partagés. Autant prévenir de suite. 3. Principe Afin de ne pas devoir réduire drastiquement le niveau de sécurité du NAS en autorisant le protocole SMBv1, on va passer par un conteneur qui va monter uniquement les fichiers du NAS dont on a besoin, et qui lui, autorisera l'accès en SMBv1. Comme le NAS utilise déjà le port 445 pour parler SMB avec les autres périphériques du réseau, il n'est pas disponible, on va donc utiliser un réseau macvlan (voir point 11-A de mon tutoriel introductif à Docker). Ce réseau permet entre autre d'attribuer au conteneur une IP située sur le même sous-réseau que votre réseau local. En somme, il devient accessible comme n'importe quelle autre machine, avec une IP par exemple du 192.168.0.x. Comme il est fréquent de faire avec des machines virtuelles. Cela permet notamment d'utiliser des ports déjà utilisés sur le NAS, et facilite la détection par les autres appareils, car visible directement par tout le réseau. 4. Mise en place du réseau macvlan Je ne détaille pas cette étape, car elle est décrite avec précision au point 11-A-1 du tutoriel introductif. A noter dans ce tutoriel précis qu'il n'est pas nécessaire de mettre en application le point 11-A-2 qui s'attarde sur la création d'une interface virtuelle pour communiquer entre le NAS et le conteneur. Si vous avez déjà un réseau macvlan disponible, assurez-vous simplement de disposer d'une IP libre dans la plage utilisée. Et adaptez les hypothèses suivantes. 5. Hypothèses Je vais me baser sur la plage et le sous-réseau utilisés dans le tutoriel introductif : IP hôte (NAS) : 192.168.0.100 Passerelle : 192.168.0.1 Sous-réseau local : 192.168.0.0/24 (ou encore écrit 192.168.0.0/255.255.255.0) Plage macvlan : 192.168.0.144/28 (vous pouvez vérifier les IP que ça concerne ici : http://jodies.de/ipcalc) IP conteneur : 192.168.0.145 Les valeurs en orange sont directement héritées de la mise en place du réseau macvlan, et sont simplement répétées par rapport au tutoriel introductif dans un souci de contextualisation. Les valeurs en vert sont propres à votre installation et ce tutoriel. 6. Configuration 6-A. Fichier docker-compose On va créer le fichier docker-compose.yml qui va reprendre toute la configuration de notre conteneur. On va utiliser l'image servercontainers/samba. Elle met à disposition un serveur Samba entièrement configurable, accompagné d'Avahi et WSD pour qu'il s'annonce sur le réseau et le rendre consultable et visible dans Finder (Mac) et l'explorateur Windows. Il faut savoir que cette image a été améliorée suite à des propositions que j'ai faites à son créateur. Elle a été adaptée pour faciliter la compatibilité avec DSM et sa version particulière de Linux. Tout d'abord, on se connecte en SSH en root, puis on crée le dossier qui va contenir la configuration du conteneur mkdir -p /volume1/docker/samba/ && cd $_ mkdir conf On va ensuite créer le fichier docker-compose.yml en utilisant nano (ou le télécharger ici : docker-compose.yml et l'importer dans File Station au bon endroit). nano docker-compose.yml dont voici un modèle : version: '2.1' services: samba-nt1: image: servercontainers/samba container_name: samba-nt1 hostname: samba-nt1 networks: mac0: ipv4_address: 192.168.0.145 environment: ## Groups ## - GROUP_users=100 ## Accounts ## - ACCOUNT_media=motdepassemedia - UID_media=10XX - GROUPS_media=users ## Global variables ## - SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol=NT1 - SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth=ntlmv1-permitted - SAMBA_CONF_MAP_TO_GUEST=Never ## Shares ## - SAMBA_VOLUME_CONFIG_music=[music]; path=/shares/music; guest ok = no; read only = yes; browseable = yes; valid users = media; force group = users volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/docker/samba/conf:/etc/samba restart: unless-stopped networks: mac0: external: true 6-B. Personnalisation des paramètres 6-B-1. Général Dans un fichier docker-compose, il n'y a pas de tabulation, uniquement des espaces, et il est important de respecter l'indentation (l'alignement). Les sauts de lignes ou le nombre d'espaces que vous mettez pour décaler les items n'a en revanche aucun impact, assurez-vous juste que ce soit lisible. hostname : cette variable est importante ici car c'est le nom que vous verrez apparaître dans la découverte de réseau de Windows. Cette chaine de caractères est automatiquement convertie en majuscules sous Windows, évitez les caractères exotiques. ipv4_address : c'est l'adresse IP que j'attribue manuellement au conteneur, c'est la première disponible dans la plage que j'ai choisie pour mon réseau macvlan nommé mac0. GROUP_users : On va définir au sein du conteneur un group "users", celui-ci correspond au groupe auquel appartient naturellement votre/vos utilisateur(s) du NAS. On lui donne la valeur de 100 car c'est le gid du groupe users sur DSM également. Si pour une raison ou un autre vous utilisez un groupe personnalisé, vous devez déterminer le GID affilié à ce groupe. Pour cela, tapez en SSH : cat /etc/group | grep nom_du_groupe Il faudra utiliser le nombre à la fin de la ligne en sortie de commande. ACCOUNT_media, UID_media et GROUPS_media : Voir paragraphe 6-B-3. SAMBA_GLOBAL_CONFIG_server_SPACE_min_SPACE_protocol : En lui donnant une valeur NT1 on autorise SMBv1 comme protocole minimal, depuis Samba 4.x le protocole minimal est SMB2. NT1 est le nom officiel de SMBv1. SAMBA_GLOBAL_CONFIG_ntlm_SPACE_auth : Il faut également autoriser l'authentification NT1. SAMBA_CONF_MAP_TO_GUEST : On ne souhaite pas que les utilisateurs soient automatiquement redirigés sur guest en cas de mauvais nom d'utilisateur ou de mot de passe. Donc on désactive la directive. SAMBA_VOLUME_CONFIG_music : voir 6-B-4. volumes : voir 6-B-2. restart: unless-stopped : Le conteneur redémarre quand il s'arrête suite à une erreur, si le service Docker ou le NAS redémarrent. Sauf si on l'a arrêté manuellement. networks : Je dois définir la nature du réseau mac0 invoqué plus haut pour le paramètre ipv4_address. Il a été créé extérieurement au conteneur, ce que je précise par le paramètre external: true. 6-B-2. Volumes Pour revenir au point abordé dans les pré-requis, et sans rentrer dans les détails, l'utilisation de cette image avec DSM possède quelques limitations : Il n'est pas possible de monter directement un dossier partagé à la racine : par exemple dans mon fichier docker-compose, je monte /volume1/music/bibliotheque et pas /volume1/music dans /shares/music. Cela vient des permissions UNIX qui sont inexistantes au niveau des dossiers partagés du point de vue de l'utilisateur root, c'est la surcouche d'ACL qui gère les permissions. Par conséquent, les permissions UNIX doivent être suffisantes pour garantir un fonctionnement adéquat. Prenons un exemple : ls -l /volume1/music Les permissions UNIX pour le dossier "bibliotheque" par exemple sont définies par les caractères qui se situent à gauche du "+" : drwxr-xr-x. Cas d'utilisation : Pour traverser les dossiers et lire en lecture seule avec un utilisateur authentifié, il faut a minima : dr-x------ pour un dossier (-r-x------ pour un fichier). Pour traverser les dossiers et lire/écrire avec un utilisateur authentifié, il faut a minima : drwx------ pour un dossier (-rwx------ pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire en lecture seule avec un utilisateur guest (non authentifié), il faut a minima : d------r-x pour un dossier (-------r-x pour un fichier). NON RECOMMANDÉ : Pour traverser les dossiers et lire/écrire avec un utilisateur guest (non authentifié), il faut a minima : d------rwx pour un dossier (-------rwx pour un fichier). Je ne recommande pas les deux derniers cas d'utilisation, car SMBv1 est un protocole déprécié et ayant des failles de sécurité. Or SMB de manière générale est sûrement le moyen le plus simple d'infecter un NAS. Néanmoins, cela peut avoir son utilité par exemple pour des imprimantes d'ancienne génération, qui stocke des éléments scannés dans un répertoire du NAS via SMBv1. L'utilisation d'un guest doit rester exceptionnelle. NOTE : Avoir d------rwx n'implique pas qu'un guest aura forcément accès aux données du partage, on peut tout à fait désactiver l'accès guest par la configuration du partage (voir point 6-B-4), limiter l'accès à certains partages à certains utilisateurs uniquement, etc... c'est simplement une condition nécessaire, mais non suffisante. En revanche, si vous n'avez pas ces permissions a minima, activer le guest n'aura aucun effet. Voilà un type de montage qu'on pourrait vouloir faire : volumes: - /volume1/music/bibliotheque:/shares/music - /volume1/video/films:/shares/films - /volume1/video/series:/shares/series - /volume1/famille/documents:/shares/documents On doit aussi s'assurer d'avoir monté le dossier dans lequel se trouvera le fichier de configuration smb.conf créé par le conteneur lors de sa mise en route : - /volume1/docker/samba/conf:/etc/samba 6-B-3. Utilisateur Pour faciliter le bon fonctionnement du conteneur, il est recommandé de créer des utilisateurs dont le nom existe déjà dans DSM. Dans mon cas, j'ai un utilisateur media qui est propriétaire de tous les fichiers multimédias (musique et vidéo). ls -l /volume1/music/bibliotheque Au sein d'un même partage (par exemple le contenu musical), il est recommandé qu'un seul et même utilisateur soit propriétaire de tous les fichiers. Ca ne changera rien dans DSM car le système a sa propre couche d'ACL qui détermine les permissions de chacun, et ça facilitera l'exploitation du conteneur. Pour unifier le propriétaire d'un ensemble de fichiers et dossiers, c'est très simple, on va dans File Station, on sélectionne les éléments dont on souhaite changer la propriété, clic droit, Propriétés. En bas de la fenêtre, on choisit le propriétaire. Si on a sélectionné un dossier, on peut cocher la case "Appliquer à ce dossier, ses sous-dossiers et ses fichiers" pour que les enfants héritent du même propriétaire. NOTE : Si vous sélectionnez à la fois des dossiers et des fichiers, il se peut que le cadre Propriétaire n'apparaisse pas. Limitez votre sélection et ça marchera. Je vais donc créer un utilisateur media dans le conteneur via la variable d'environnement : ACCOUNT_media. La valeur de cette variable est le mot de passe pour l'utilisateur media dans ce conteneur. NOTE : Ce mot de passe ne doit pas être le même que celui pour l'utilisateur media du NAS ! En effet, le conteneur aura ses propres accès. La documentation de cette image permet de chiffrer ce mot de passe, pour ma part je n'en vois pas l'intérêt. Car pour accéder à ce fichier, l'utilisateur doit déjà avoir infecté le NAS. Cacher ses clés dans la maison n'a pas d'intérêt s'il y a déjà effraction. Concernant la variable UID_media, il s'agit de l'ID de l'utilisateur. Il est pratique d'utiliser le même UID que celui de l'utilisateur du NAS. Pour récupérer cet UID, il suffit de taper en SSH : id media Dans mon cas c'est 1035, dans tous les cas c'est strictement supérieur à 1025. Enfin, pour GROUPS_media, on lui donne la valeur users, par défaut l'utilisateur appartient à un groupe identique à son nom d'utilisateur. Pour DSM, le groupe users est le groupe par défaut pour les utilisateurs. On s'assure une meilleure compatibilité avec les ACL. Au final, en configurant ces trois variables, on assure la création d'un utilisateur qui pourra se servir des droits utilisateurs accordés par les permissions UNIX et ne fâchera pas les ACL de DSM. REMARQUE : Il est tout à fait possible de créer plusieurs utilisateurs, par exemple si vous décidez de monter l'espace personnel d'un utilisateur du NAS, ou simplement parce que tous les fichiers de vos partages n'appartiennent pas à un seul et même utilisateur. Exemple : - ACCOUNT_media=motdepassemedia - UID_media=1035 - GROUPS_media=users - ACCOUNT_lolita=motdepasselolita - UID_lolita=1031 - GROUPS_lolita=users 6-B-4. Configuration des partages La configuration des partages se fait via la variable d'environnement SAMBA_VOLUME_CONFIG_music (pour un partage qui se nommerait "music"). La valeur associée peut paraître étrange avec ses points virgule, mais ça représente juste un saut de ligne dans ce qui correspond habituellement à la configuration d'un partage SMB. Voyons plus en détail : path=/shares/music : correspond à l'emplacement qu'on a indiqué dans le montage de volume, c'est le chemin DANS le conteneur. [music] : c'est le nom du partage tel que vous le verrez dans votre explorateur. Vous pouvez utiliser des majuscules et des espaces ici. guest ok : prend la valeur "yes" ou "no", dans le premier cas lorsque vous vous connecterez aucun mot de passe ne vous sera demandé. Valeur recommandée : no. read only : est assez explicite, prend la valeur "yes" ou "no". En SMBv1, préférez la lecture seule. browseable : permet de voir apparaître le partage dans les onglets de découverte du réseau. valid users : permet de définir quel(s) utilisateur(s) sont autorisés à accéder au partage. Pour ajouter plusieurs utilisateurs, les séparer par une virgule. Si tous les utilisateurs peuvent accéder au partage, il n'est pas nécessaire d'utiliser cette directive. force group : Par défaut, ce sera l'utilisateur media/media qui écrira quand on est connecté avec cet utilisateur, on souhaite que le groupe par défaut soit users, d'où la valeur forcée à "users" pour ce paramètre. Autres directives majeures disponibles : comment : permet de décrire notre partage, majuscules autorisées. directory mask : permet de définir quelles seront les permissions UNIX par défaut lors de la création d'un dossier. Exemple : create directory mask = 0755 => les dossiers auront les permissions suivantes : drwxr-xr-x. Voir la page Wikipédia (Fonctionnement - Représentation des droits) pour plus d'information : https://fr.wikipedia.org/wiki/Permissions_UNIX create mask : même chose pour un fichier. guest only : nécessite d'avoir réglé guest ok sur "yes" au préalable. Accès guest seulement (pas d'authentification). Il existe énormément de paramètres configurables pour un partage SMB, voir la liste ici : https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html Tout est maintenant configuré. On n'a plus qu'à sauvegarder le fichier docker-compose (sous nano, CTRL+O puis Entrée pour sauvegarder, CTRL+X pour sortir de l'éditeur). 7. Création du conteneur Pour créer le conteneur, on vérifie qu'on se trouve toujours dans /volume1/docker/samba et on tape : docker-compose pull Ce qui va télécharger la dernière version de l'image. Puis : docker-compose up -d Si pas d'erreur à la création (souvent dues à des caractères de tabulation, une directive dans le fichier docker-compose mal orthographiée ou désalignée, etc...), vous verrez un petit done apparaître en vert. Si browseable a été activé, on voit le partage dans la découverte réseau : Tous les autres moyens habituels pour accéder à un partage SMB sont actifs (connecter un lecteur lecteur réseau, smb:// via Finder, etc...). MàJ : 13/01/2022

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 ## ## ##==============================================================================================

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.

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 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. Le tutoriel sera découpé de la sorte : - STANDARD - Utilisation et déploiement de Pi-Hole via Docker - AVANCÉ - Ses différentes utilisations 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 avec un utilisateur ayant des privilèges d'administrateur ou root directement, 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. 3. Méthode d'installation Il existe plusieurs méthodes pour installer Pi-Hole, préférentiellement je conseille : l'utilisation d'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 une machine virtuelle (avec le paquet Virtual Machine Manager, les prérequis de compatibilité étant les mêmes que pour Docker), avec une installation minimale de Debian avec 512Mo de mémoire vive et un cœur est amplement suffisante un conteneur Docker. 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). Voir ce site qui permet de calculer les masques. 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 : REMARQUE : ovs s'ajoute automatiquement au nom de l'interface lorsqu'on a activé Open vSwitch sur son NAS (automatique lors de l'installation de Virtual Machine Manager) - STANDARD - 5. Création du réseau et de l'interface virtuelle 5-A. Création du réseau macvlan On commence par se connecter via SSH avec un utilisateur admin ou root sur le NAS pour créer notre réseau macvlan. On va se placer dans le dossier partagé docker : cd /volume1/docker/ On y crée un dossier "networks" et y commencer l'édition du script : mkdir networks && cd $_ nano macvlan-network.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. _________________________ 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-network.sh Le script est prêt, on peut l'exécuter : bash macvlan-network.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 : bash 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 en plus de l'interface physique du NAS. 5-C. Création de la tâche de rétablissement de l'interface virtuelle au redémarrage 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. REMARQUE : Lorsqu'on stoppe docker, ou qu'on le met à jour, l'interface disparaît également. La tâche n'étant lancée qu'au démarrage, vous devrez réexécuter la tâche manuellement pour rétablir l'interface. 6. Création des volumes On va créer un dossier pour le conteneur et s'y placer, on va également créer deux 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 seront conservées. 7. Création d'utilisateurs et groupes dédiés et octroi de propriété Pi-Hole permet depuis quelques versions d'exécuter le conteneur par le biais d'un utilisateur non privilégié. Autrefois, c'était root qui exécutait l'application, et root dans le conteneur correspondait à root sur le NAS, ce qui en cas de faille au niveau de l'image Docker représentait une faille de sécurité potentielle. Nous allons créer deux utilisateurs ainsi que deux groupes, un tandem pour l'exécution de Pi-Hole, l'autre pour les services web qu'utilise Pi-Hole. Dans DSM : Panneau de configuration -> Utilisateur et groupe -> Groupe -> Créer. 1er groupe : Nom : pihole Description : Exécute le conteneur Pi-Hole Autorisations dossiers partagés : Aucun accès pour tous les dossiers sauf docker (Lecture/Ecriture) et homes (on ne coche rien) Autorisation applications : Tout refuser 1er utilisateur : Nom : pihole Appartient au groupe : pihole Tout le reste est issu des permissions liées au groupe 2ème groupe : Nom : pihole-www Même chose que pour pihole 2ème utilisateur : Nom : pihole-www Appartient aux groupes : pihole-www et pihole Tout le reste est issu des permissions liées aux groupes En SSH, on va attribuer la propriété des deux dossiers de configuration créés dans la section précédente à l'utilisateur pihole et au groupe pihole : cd /volume1/docker chown -R pihole:pihole pi-hole/ On vérifie que les permissions sont ok : Avant de clôturer cette partie, nous allons vérifier les uid et gid de nos utilisateurs et groupes nouvellement créés, nous en aurons besoin pour personnaliser notre fichier compose : REMARQUE : les valeurs ci-dessus sont propres à votre installation, ne les recopiez pas bêtement ! 7. Configuration et initialisation 7-A. Création du fichier compose On va utiliser Docker-compose pour créer notre conteneur. Docker-compose est une manière alternative de créer un conteneur qui possède de nombreux avantages par rapport à la ligne de commande et à l'interface proposée par DSM. De plus Docker-compose vient avec le paquet Docker de Synology, donc aucune installation supplémentaire n'est nécessaire. Venons-en à la création de notre fichier compose : nano docker-compose.yml On y colle le contenu suivant, il suffit de copier les données suivantes, revenir dans l'éditeur nano, et faire un clic droit. 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: # General - 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 - FTLCONF_LOCAL_IPV4=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 # Mapping utilisateurs et groupes - PIHOLE_UID=1045 # pihole UID - PIHOLE_GID=65548 # pihole GID - WEB_UID=1044 # pihole-www UID - WEB_GID=65547 # pihole-www GID # Conditional forwarding - REV_SERVER=true # Permet de recuperer les hostnames 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 # Personnalisation interface - TEMPERATUREUNIT=C - WEBTHEME=default-darker - WEBUIBOXEDLAYOUT=boxed 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 REMARQUES : 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. 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. 7-B. Conditional forwarding 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_ dans le fichier compose. Sinon : 7-C. 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. 8. Résolution locale 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. Pour le vérifier, il suffit de taper dans une invite de commande Windows par exemple : nslookup nas-forum.com Si les deux premières lignes du résultat sont équivalentes à : Serveur : pi.hole Address: 192.168.100.161 Félicitations, votre Pi-Hole est fonctionnel ! Pour vérifier que le blocage de publicités est actif, essayez d'aller sur http://doubleclick.net, si le nom de domaine ne peut être résolu, c'est que Pi-Hole a filtré la demande (veillez à désactiver tout bloqueur de pubs intégré au navigateur en amont). Quid du serveur DNS secondaire ? 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. 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, une machine virtuelle sur un autre serveur ou un autre NAS compatible Docker si on en possède un. La suite s'adresse aux utilisateurs souhaitant pousser plus avant la configuration de Pi-Hole. - AVANCÉ - 9. Modes d'utilisation 9-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. 9-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). 9-C. Pi-Hole en tant que serveur DNS local 9-C-1. Ajout des enregistrements Il est possible d'utiliser directement Pi-Hole comme résolveur DNS local. C'est extrêmement pratique si vous n'avez encore mis aucune résolution locale en place (avec DNS Server par exemple). 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 compose. 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 donné à domaine2.fr une IP inexistante sur le réseau, 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é et vous renverra une erreur. nas.domaine1.fr pointe sur mon NAS, sur lequel par exemple je pourrais utiliser un proxy inversé. Et maintenant dans CNAME Records, je vais par exemple définir des alias pour mes périphériques et pour mon proxy inversé : REMARQUE : 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éfinie dans la partie DNS records. Le rafraichissement de la zone se faisant à chaque nouvel ajout, il faut qu'il soit valide. 9-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). 10. Blocage différencié Un des gros avantages de Pi-Hole face à la concurrence 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. On peut laisser actif Google Shopping pour madame. 🙂 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 : 11. 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 ____________________________ Pour le mettre à jour et le reconstruire : cd /volume1/docker/pi-hole docker-compose pull docker-compose up -d MàJ : 20/01/2023

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