Nas on Pascal's weblog

Vorta for Borg Backup

Sun, 28 Jun 2026 15:22:44 +0000

Ce matin, pris d’une inspiration subite, j’ai décidé de faire une nouvelle sauvegarde de mon dossier Home. Ce dossier est déjà synchronisé grâce à Nextcloud sur un serveur distant, ainsi que sur un autre HD du PC, grâce à Timeshift.

Mais lorsque j’avais remis en service mon vieil odroid-hc2, l’idée était de l’utiliser comme serveur de backup, avec son HD de 2 To disponible. J’avais bien redirigé les tâches rsync du serveur OMV (NAS) sur ce serveur (contenu Plex et Calibre), et puis j’étais passé à autre chose. J’avais prévu des sauvegardes à partir du PC, sans aller plus loin.

Cette fois, j’ai utilisé Vorta, une interface graphique pour Borg, un logiciel de backup qui a une très bonne réputation (sauvegarde chiffrées, sécurisées, compressées). L’opération a été facilité par cet article sur le FLOZz’ Blog, que j’ai adapté à mon contexte et à ce que je voulais faire, puisque je bénéficiais déjà d’une connexion SSH entre mon PC et le serveur Odroid, ainsi que d’une clef de login. Une fois le dépôt Borg créé, le reste est simplissime.

Voilà le détail des opérations, ça m’a permis un petit refresh sur ssh et les clefs privées et publiques…

Sur le serveur Odroid

Cette machine tourne donc Ubuntu. Le HD externe de 2 To est monté sur le dossier /satadisk, et comprend deux sous-dossiers, un pour les sauvegardes en provenance du NAS (déjà utilisé), un autre pour celles en provenance du PC (pas encore utilisé) :

$ cd /satadisk
$ tree --du -h --sort=size . | sed -E "/^[^[]{8,}\[/d"
[192G]  .
├── [191G]  NAS-N150
└── [  0G]  PC-RYZEN

On commence par installer borgbackup :

$ sudo apt install borgbackup

Je vais aussi créer un utilisateur dédié pour ces backups, ce sera plus clair.

$ sudo adduser borg --home /satadisk/PC-RYZEN

On va aussi lui copier la clef publique SSH du PC déjà créée. Pour ce faire, sur le PC, on copie le contenu du fichier /home/pascal/.shh/id_ed25519.pub dans un nouveau fichier créé sur la machine Odroid dans /satadisk/PC-RYZEN/.ssh/authorized_key qui doit donc ressembler à ceci :

borg@odroid:~$ cat .ssh/authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAp2Bz0e1GjYGMvLyw4WxXTGHN/Pla9CmJbApNnrlESM pascal@pascal-eos

Et on teste à partir du PC que la commande $ ssh borg@192.168.1.XX (soit la machine odroid) fonctionne bien. Dans la foulée, je crée un dossier pascal-eos-home-backup à partir de la home de l’utilisateur borg (pour le dépôt de Borg):

borg@odroid:~$ pwd
/satadisk/PC-RYZEN
borg@odroid:~$ mkdir pascal-eos-home-backup

Voilà, on a donc notre utilisateur borg qui peut se connecter sans avoir à saisir de mot de passe sur la machine odroid à partir du PC.

Sur le PC

On commence donc par installer Vorta, qui se chargera d’installer Borg en tant que dépendance :

$ sudo pacman -S vorta

On le lance, et on crée le fameux dépôt, selon la terminologie de Borg. On rentre le dépôt sous la forme ssh://<USER>@<MACHINE><PATH>, ce qui donne :

$ borg init --encryption=repokey ssh://borg@192.168.1.XX/satadisk/PC-RYZEN/pascal-eos-home-backup

Borg va vous demander une “passphrase”, choisissez un mot de passe et notez le précieusement. C’est ce qui va permettre à Borg de faire des sauvegardes chiffrées et donc sécurisées.

Il ne reste plus qu’à lancer Vorta, et lui indiquer de dépôt comme destination : on clique sur le + à droite, on choisit “dépôt existant”, et on rentre le dépôt sous la même forme, en indiquant le mot de passe (la passphrase demandée lors de la création du dépôt) :

Et voilà, le plus dur est fait. À noter que j’ai laissé l’option Clé SSH : Choisir automatiquement une clef SHH (par défaut), puisque comme expliqué au début de l’article, j’ai déjà implémenté un clef SSH entre les deux machines.

Sur l’onglet Sources, il ne reste plus qu’à définir la source du backup que l’on souhaite effectuer ( /home/pascal dans mon cas), gérer les dossiers à exclure (temp, cache, etc…) :

Et sur l’onglet Planification, la périodicité souhaitée pour les sauvegardes :

Et voilà, il ne reste plus qu’à lancer la sauvegarde :

Et la taille occupée sur le disque :

$ cd /satadisk
$ tree --du -h --sort=size . | sed -E "/^[^[]{8,}\[/d"
[208G]  .
├── [191G]  NAS-N150
└── [ 16G]  PC-RYZEN

Conclusion

Franchement, cela a été très facile à mettre en place, et Vorta avec son interface graphique rend l’utilisation de Borg très facile.

On peut bien sûr définir d’autres sauvegardes, ou d’autres dépôts dans un autre profil selon l’organisation souhaitée de ,os précieuses sauvegardes ! :cool:

Feishin et Navidrome

Tue, 19 May 2026 13:15:31 +0000

J’ai peut-être trouvé le bon lecteur audio sur le PC, j’ai nommé Feishin. Le seul souci c’est que c’est un client de serveurs comme Navidrome, Jellyfin ou compatibles avec l’API OpenSubsonic. En clair, il ne lit pas directement les fichiers audio sur votre PC, et a besoin d’un serveur audio.

Qu’à cela ne tienne, le jeu en valait la chandelle me semble-t-il lorsque j’ai vu à quoi Feishin ressemblait : beau, moderne, avec plein de fonctionnalités comme d’afficher les paroles, de s’adapter à la couleur de la pochette, d’obtenir des infos sur l’artiste, etc…

Il a donc fallu choisir et installer un serveur sur le NAS : j’ai choisi Navidrome qui a l’air d’être une référence du genre, et accéder à ma bibliothèque musicale, ce qui m’a amené à quelques changements dans mon organisation, mais l’ensemble a été plutôt facile et je suis assez content du résultat.

Voyons voir tout ça…

Navidrome

Quel serveur installer ? J’ai déjà un Nextcloud Music qui tourne sur mon hébergeur qui me permet d’écouter ma musique quand je suis à l’extérieur, et j’aurais pu faire pareil en local puisque j’ai déjà une instance Nextcloud, mais j’ai regardé un peu les alternatives et vu que Navidrome avait une bonne réputation, était une sorte de référence dans le genre, et proposait une version Docker. Et il est bien sûr Open Source. Je suis donc parti sur ce serveur.

L’installation via Dockge du container Docker s’est faite en quelques minutes, je suis toujours surpris de la facilité que Docker apporte, c’est vraiment génial. Voilà le fichier compose.yaml que j’ai utilisé. Les deux paramètres LASTFM sont optionnels, j’y reviens plus bas :

services:
  navidrome:
    image: deluan/navidrome:latest
    user: 1000:1000 # should be owner of volumes
    ports:
      - 4533:4533
    restart: unless-stopped
    environment:
      ND_DEFAULTLANGUAGE: fr
      ND_SCANSCHEDULE: 0 3 * * *
      ND_LOGLEVEL: info
      ND_LASTFM_APIKEY: 2931xxxxxxxxxxxxxxxxxxxxxxxx38f0
      ND_LASTFM_SECRET: 24e2xxxxxxxxxxxxxxxxxxxxxxxx7e3d
    volumes:
      - /srv/dev-disk-by-uuid-yyyyyyy-xxxx-xxxx-xxxx-yyyyyyyyyy/AppData/navidrome/data:/data
      - /mnt/RpiMusic:/music:ro
networks: {}

Une fois le container lancé, Navidrome va lire le contenu de la bibliothèque musicale indiquée pour “/music”, à savoir /mnt/RpiMusic dans le fichier compose, qui est un point de montage NFS, j’y reviens. Si c’est un simple dossier local, il n’y a plus qu’à y copier la musique. Une fois ceci fait, le serveur est disponible dans le navigateur :

La bibliothèque musicale

La question de la bibliothèque s’est vite posée : devais-je dupliquer sur le NAS celle présente sur le PC et que j’utilisais auparavant avec un lecteur audio classique (DeadBeef en l’occurence) ? Comme je dupliquais déjà cette bibliothèque musicale sur le Raspberry pour mon lecteur “de salon”MoOde, il y avait sans doute mieux à faire.

Et puisque j’ai désormais Ubuntu 22.04 Server LTS qui tourne sur le odroid-hc2 (voir cet article), j’ai fini par installer un serveur NFS, et ajouter ceci dans /etc/exports, pour partager le chemin d’accès à ma bibliothèque musicale sur le disque USB de mon Raspberry à toute machine sur mon réseau local :

/srv/nfs/usb/Music	192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

Info

Comme indiqué sur l’article en lien, j’avais eu des problèmes pour installer le service NFS (“Dependency failed for rpc_pipefs.target”) sur le serveur Ubuntu, mais j’ai finalement réussi puisque ça tourne aujourd’hui. N’ayant pas pris de notes à ce moment là, je ne sais plus trop comment c’est “tombé en marche”. :wink:

Côté NAS, je suis allé ajouter dans le fichier /etc/fstab les lignes suivantes :

###############################
# NFS MOUNT RPI MUSIC LIBRARY #
###############################
192.168.1.17:/media/Music /mnt/RpiMusic nfs rw 0 0

Pour résumer, côté Navidrome (donc sur le NAS), on a /mnt/RpiMusic de défini dans le fichier compose.yaml pour le dossier /music du container. Dans /etc/fstab du NAS, on monte ce dossier via NFS sur le dossier srv/nfs/usb/Music, qui correspond sur le Raspberry au dossier /media/Music, partagé via le serveur NFS.

Et voilà, ça fonctionne parfaitement, Navidrome s’accommode fort bien de ce montage NFS, ce qui n’était pas forcément le cas d’Ubuntu Music, d’après les quelques essais que j’avais pu faire précédemment.

Concernant mon organisation, le PC reste tout de même l’endroit où j’ajoute ma nouvelle musique. Ensuite, un script rsync la synchronise sur le Raspberry. Il ne me reste qu’à faire un scan rapide sur l’interface de Navidrome et le tour est joué, je retrouve la musique dans Feishin immédiatement.

Les playlists

Comme toujours, il faut maintenant recréer mes playlists. J’utilise des dossiers dédiés pour les playlists, cela a ses avantages et ses inconvénients, mais globalement je trouve ça plutôt pas mal, et il y a toujours moyen de les recréer facilement comme j’ai pu le faire avec MoOde. L’inconvénient, c’est que les morceaux se retrouvent dupliqués dans la bibliothèque musicale, mais bon…

Avec Navidrome, c’est en fait très simple : il suffit d’aller dans chaque dossier, et de créer un fichier nom_playlist.m3u, et le tour est joué : au prochain scan, Navidrome va automatiquement importer la playlist. Et donc sous Linux, la simple commande suivante suffit :

$ ls > nom_playlist.m3u

Et voilà, il suffit de le faire dans chaque dossier “playlist”, et de relancer un scan dans Navidrome. Côté Feishin, il n’y a rien à faire, la playlist va tout de suite apparaître.

En cas de problème avec les pochettes (j’avais quelques playlists qui n’affichaient le fichier cover.jpg pourtant présent), tout est très bien détaillé dans la documentation. Dans mon cas, j’ai simplement été sélectionner le fichier manuellement via l’interface de Navidrome.

Scrobbling

Tant que j’y étais, et puisque je l’avais activé pour MoOde, j’ai regardé ce que l’on pouvait faire de ce côté avec Navidrome. C’est malheureusement impossible à l’heure actuelle pour Libre.fm, l’idée a été soumise, mais pas encore implémentée (si elle doit l’être un jour). Reste au choix Last.fm ou ListenBrainz. C’est très simple et bien intégré.

Last.fm

Il faut bien sûr se créer un compte last.fm (gratuit) si ce n’est déjà pas le cas, et obtenir une API key sur https://www.last.fm/api/account/create (seul le champ “Application name” est requis). Puis on copie les valeurs obtenues dans le fichier compose.yaml (voir ci-dessus). Redémarrer Navidrome. Puis aller dans le profil utilisateur et activer le scrobbling :

On est redirigé vers une page last.fm où il suffit d’autoriser Navidrome à “scrobbler” vers last.fm. Et voilà, le scrobbling doit fonctionner.

Music.Brainz

Côté MusicBrainz (ou ListenBrainz), une fois le compte créé, il faut aussi activer l’option dans Navidrome.

Une boite de dialogue s’ouvre, il faut alors cliquer sur le lien pour recevoir le token :

On arrive alors sur une page de ListenBrainz, on copie le token fourni, et on le colle dans Navidrome, et le tour est joué, le scrobbling doit fonctionner sur listenbrainz :

Feishin

Le lecteur Feishin est disponible dans les dépôts AUR, c’est donc très facile de l’installer avec pamac (il est aussi disponible sur Flathub au cas où) :

On peut juste regretter qu’il ne soit pas intégré au style de Gnome (fenêtre), mais c’est vraiment un détail. Une fois lancé, il suffit d’aller dans les paramètres “Gérer les serveurs”, et de saisir les informations du serveur Navidrome (adresse et port, nom, mot de passe) :

Comme je suis sur le réseau local, je n’ai pas de connexion HTTPS, il faudrait que je passe par le proxy, mais je ne me suis pas pris la tête avec ça. Et c’est tout, Feishin est opérationnel :

Homepage Dashboard

Comme tout service Docker installé, il me faut l’ajouter à mon dashboard Homepage. Par contre, il a fallu chercher un peu pour trouver comment générer le token pour que les données fonctionnent.

Il faut aller sur le site https://www.md5hashgenerator.com/ et générer le token en concaténant votre mot de passe navidrome + le salt indiqué dans le fichier compose (voir le fichier ci-dessous). On obtient alors le token :

Et voilà la partie du fichier services.yaml de Homepage correspondant à Navidrome :

  - Navidrome:
      icon: navidrome
      href: http://192.168.1.32:4533
      description: Navidrome Music Server
      server: my-docker
      container: navidrome-navidrome-1
      widget:
        type: navidrome
        url: http://192.168.1.32:4533
        user: pascal
        token: 036905dfd8917194a13195ddd6dd1352
        salt: randomsalt

Comme toujours, faire attention au nom du container, et cela fonctionne nickel du premier coup. Bonus, il affiche le morceau en train d’être joué ! :cool:

Conclusion

Voilà plusieurs semaines que j’utilise cette nouvelle configuration pour écouter de la musique sur le PC, et j’en suis très satisfait. Je n’ai observé aucun problème avec le montage NFS pour accéder à la musique, et Feishin est vraiment très esthétique, cela change de Rhythmbox que utilisé pendant si longtemps, et même de DeadBeef que j’utilisais depuis mon passage à EndeavourOS.

Immich : installation et découverte

Fri, 13 Mar 2026 17:29:16 +0000

Voilà un petit bout de temps que j’avais noté Immich comme futur container Docker à installer. Il s’agit d’une solution auto-hébergée de gestion de photos et de vidéos. Elle est souvent donnée comme un remplacement à Google Photos.

En ce qui me concerne, ce sera en remplacement de Nextcloud pour synchroniser les photos prises avec le smartphone sur un serveur local. C’est d’ailleurs la fonction principale d’Immich, celle pour laquelle le développeur l’a créé au début.

Car depuis les premières versions, Immich s’est beaucoup développé, d’autres fonctionnalités, comme la géolocalisation, la détection de visages, la création d’albums, le partage, un éditeur basique (recadrer, rotation), et j’en oublie sûrement. Immich propose aussi un outil en ligne de commande pour importer des photos ou des vidéos d’une autre source que le smartphone, comme des photos déjà archivées. On serait donc tenté de l’utiliser comme un album photo en ligne… Ce qui ne va finalement pas me convaincre, j’y reviens en fin d’article.

Voyons voir tout cela, l’installation a été hyper facile et rapide, il m’a fallu un peu plus de temps pour les réglages et la prise en main de l’interface, car on n’est plus dans la simple vue d’une arborescence de fichiers, tout passe par une base de données, ce qui change pas mal de choses.

Nextcloud

La synchro des photos proposée par Nextcloud ne fonctionne pas toujours très bien, et surtout on n’a aucun moyen d’agir dessus. La synchro peut être immédiate, ou arriver dix minutes plus tard, voir pas du tout (certains fichiers peuvent être omis, typiquement après une mise à jour de l’appli, c’est arrivé plusieurs fois).

Ce qui me dérange le plus, c’est dans le scénario suivant : je suis en train d’écrire un article pour le blog, ou de créer une bug sur Github, et j’ai besoin de prendre un screenshot sur mon tel. Je m’attend à ce que la synchro soit rapide, et que je puisse récupérer rapidement le fichier sur le PC, or ce n’est pas le cas, et j’ai plus vite fait de me l’envoyer par mail du smartphone, ce qui est quand même navrant.

Évidemment, la perte de fonctionnalité ou l’apparition de bugs après une mise à jour est également un sérieux problème. Dans l’ensemble, le manque de fiabilité est vraiment problématique (je ne suis pas le seul à m’en plaindre), et il était temps de passer à une autre solution.

Installation d’Immich

J’ai donc installé Immich en mode Docker, et l’installation a été d’une extrême simplicité, j’en étais même surpris !

Il y a deux fichiers à récupérer comme expliqué sur la page d’aide : un fichier docker-compose.yml dont je copie tel quel le contenu dans Dockge, et un fichier .env qu’il faudra personnaliser (toujours dans Dockge).

J’ai d’abord créé sur le NAS un dossier immich dans AppData, puis créé deux sous-dossiers library et postgres. Puis dans le fichier .env, j’ai renseigné les deux variables correspondantes :

UPLOAD_LOCATION=/srv/dev-disk-by-uuid-wwwwwwww-xxxxxx-yyyy-zzzzzzzz/AppData/immich/library DB_DATA_LOCATION=/srv/dev-disk-by-uuid-wwwwwwww-xxxxxx-yyyy-zzzzzzzz/AppData/immich/postgres

Voilà pour l’essentiel. Reste la Timezone à définir, ainsi que le mot de passe pour la base de données :

TZ=Europe/Paris DB_PASSWORD=mot_de_passe

Et voilà, rien d’autre à faire, le fichier compose.yaml de Dockge reste inchangé. Je démarre le container, et hop ! tout fonctionne immédiatement, c’est vraiment cool. :cool:

Je passe les différents écrans pour déclarer l’utilisateur, et voilà, c’est fini côté serveur pour Immich.

Comme indiqué dans la page d’aide, je teste l’ajout d’une première photo avec le bouton “Envoyer” en haut à droite :

Et ma première photo apparaît dans Immich, tout paraît tellement facile, c’est impressionnant.

Accès à partir d’internet

Pour le rendre accessible de l’extérieur de mon LAN (et donc du smartphone), il reste comme d’habitude (je ne détaille pas, c’est toujours la même chose) à configurer le nom de sous-domaine côté hébergeur (CNAME), le fichier immich.subdomain.conf du proxy swag (voir plus bas), et enfin l’ajout de immich comme SUBDOMAINS dans le fichier docker de swag afin qu’il aille chercher un certificat Let’s Encrypt, puis de redémarrer le proxy. À partir de là, j’accède à mon serveur immich via HTTPS, c’est parfait.

Smartphone

Je passe alors sur le smartphone, désactive le Téléchargement automatique du client Nextcloud, puis installe Immich à partir de F-Droid.

Je configure les dossiers à synchroniser (les photos et mes captures d’écran), et c’est parti, la synchronisation se met en route, et au bout de quelques minutes, tout est synchronisé.

Je n’aurai finalement qu’un seul problème lors de cette installation d’Immich, ce sera lors de synchronisation des vidéos sur le smartphone, qui sont dans le même dossier que les photos. Tout a l’air de bien se passer, je vois la progression du transfert, mais elles échouent toutes avec un message du type ’ Connection reset by host" (je ne l’ai pas noté).

C’était le fichier du proxy qui provoquait cette erreur, et c’était de ma faute.

Fichier proxy

J’ai dans un premier temps utilisé un fichier proxy ( immich.subdomain.conf) assez basique, ne contenant que le minimum, et que j’adapte à chaque nouveau serveur. J’ai bien vu qu’il existait deux fichiers d’exemples de fournis pour immich par swag/nginx, mais j’ai d’abord fait au plus simple, et comme le serveur fonctionnait…

Quand j’ai eu le problème d’upload des vidéos, le “reset by host” m’a tout de suite orienté vers le proxy. Le fichier que j’utilisais avec cette ligne :

client_max_body_size 20m;

Ce paramètre limite la taille des fichiers envoyés au serveur à 20 Mo. Dans les fichiers d’exemple fourni pour immich, ce paramètre est mis à zéro, ce qui désactive le test de la taille du fichier. J’ai donc fait pareil et le problème a été résolu, les vidéos ont pu être transférées sans problème :

client_max_body_size 0;

J’avais aussi un petit souci sur l’interface web d’Immich, où la version du serveur et son statut n’était pas affiché :

Après quelques recherches, je vois que cela vient probablement du proxy car Immich utilise les webSockets. J’ai donc fini par utiliser le fichier d’exemple fourni par Swag à savoir immich.subdomain.conf.sample, afin de partir d’une base plus solide. Et là aussi le problème est résolu :

Pour info, voilà le contenu de mon fichier immich.subdomain.conf :

Info

J’ai modifié la valeur de server_name pour correspondre à mon sous-domaine.
Par défaut, $upstream_app a la valeur immich. Pour ne pas avoir à modifier ma config (container name, cname), je l’ai remplacé par mon adresse IP locale 192.168.x.y (2 occurrences).
Tout le reste a été laissé par défaut.

$ cat immich.subdomain.conf
## Version 2025/07/18
# make sure that your immich container is named immich
# make sure that your dns has a cname set for immich
# immich v1.118+ only. For earlier versions, change $upstream_port to 3001

server {
    listen 443 ssl;
#    listen 443 quic;
    listen [::]:443 ssl;
#    listen [::]:443 quic;

    server_name immich.subdomain.domain.fr;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth (requires ldap-location.conf in the location block)
    #include /config/nginx/ldap-server.conf;

    # enable for Authelia (requires authelia-location.conf in the location block)
    #include /config/nginx/authelia-server.conf;

    # enable for Authentik (requires authentik-location.conf in the location block)
    #include /config/nginx/authentik-server.conf;

    # enable for Tinyauth (requires tinyauth-location.conf in the location block)
    #include /config/nginx/tinyauth-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable for ldap auth (requires ldap-server.conf in the server block)
        #include /config/nginx/ldap-location.conf;

        # enable for Authelia (requires authelia-server.conf in the server block)
        #include /config/nginx/authelia-location.conf;

        # enable for Authentik (requires authentik-server.conf in the server block)
        #include /config/nginx/authentik-location.conf;

        # enable for Tinyauth (requires tinyauth-server.conf in the server block)
        #include /config/nginx/tinyauth-location.conf;

        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.x.y;
        set $upstream_port 2283;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }

    location ~ (/immich)?/api {
        include /config/nginx/proxy.conf;
        include /config/nginx/resolver.conf;
        set $upstream_app 192.168.x.y;
        set $upstream_port 2283;
        set $upstream_proto http;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

Adresse mail

Dans les paramètres d’administration, il peut être utile de créer une adresse mail, que ce soit pour les notifications du serveur que pour envoyer un mail d’invitation (Immich est multi-utilisateurs, vous pouvez faire profiter vos amis de votre serveur auto-hébergé).

On saisit les informations habituelles d’un compte mail (serveur SMTP), en faisant bien attention à utiliser une adresse valide dans le champ “Depuis l’adresse”, sinon le serveur SMTP refusera probablement d’envoyer le mail avec un message du genre “Sender mismatch”. Pour ce faire, j’ai choisi de créer un alias à mon compte mail, ce qui me permettra d’identifier facilement les mails en provenance du serveur :

Découverte & Utilisation

Une fois les photos du smartphone ajoutées, il ne reste plus qu’à explorer l’interface. Le mieux est de regarder cette vidéo, en français, qui en fait le tour, et qui se termine même par une installation docker d’Immich.

https://youtu.be/N31SQQQQvqI

Franchement, ça a l’air pas mal :

une vue globale en mode “time line”
une vue “Explorer” où l’on peut chercher par lieu ou par personne (il y a un container machine-learning qui offre ces options, avec aussi une détection de doublons).
une vue carte pour chercher en fonction des données GPS des photos.
la possibilité d’éditer une photo avec les fonctions de base (rotation, redimensionner, etc…).

Il est possible d’ajouter dans la colonne de gauche une vue par dossier (Paramètres du compte - Fonctionnalités- Dossiers) qui apparaîtra en fonction du modèle de stockage défini (Administration - Modèle de stockage). Pour ma part, j’ai choisi le même que j’utilisais dans Nextcloud, à savoir Année & Mois :

Ce qui donne :

C’est la seule façon que j’ai trouvé pour afficher les photos en mode “mosaïque” et pas en mode “timeline” :

On peut aussi définir des favoris, créer des albums, partager des photos ou des albums avec des personnes. Enfin, on peut aussi archiver certaines photos, qui n’apparaîtront plus mais seront tout de même conservées.

Immich CLI

Il me reste une chose à faire : importer d’anciennes photos qui ne sont plus sur le smartphone, mais que je souhaite ajouter à Immich. Pour ce faire, Immich propose un outil en ligne de commande.

NPM et Node.js

La doc est là : The Immich CLI. Pour utiliser le CLI d’Imich, il faut installer npm et node.Js. NPM est un package manager dédié pour Node.js, soit le runtime JavaScript (à utiliser avec précaution, composant pouvant apporter des brèches de sécurité à votre système).

Selon cette page : https://linuxconfig.org/install-npm-on-linux, et puisque je suis sous Arch (EndeavourOS), il suffit de taper cette commande :

$ sudo pacman -S npm # also installs nodejs

Puis on installe le client Immich :

$ sudo npm i -g @immich/cli

Le CLI

Il suffit ensuite de se logguer avec l’API Key que l’on peut générer dans “Paramètres du Compte - Clés d’API” (NOTE : il faudra accorder toutes les autorisations pour cette clef d’accès) :

immich login http://192.168.x.y:2283/api IMMICH_API_KEY

Et voilà, on peut utiliser les commandes pour ajouter des images dans un nouvel album, par exemple (le nom du dossier contenant les photos sera le nom de l’album) :

immich upload --album --recursive nom_du_dossier/

On peut aussi ajouter l’option --recursive s’il y a des sous-dossiers : dans ce cas, chaque sous-dossier deviendra le nom d’un nouvel album. On peut aussi ajouter des images à un album existant ( --album-name "Voyage 2023"). Mais on ne peut pas créer de sous-albums.

Attention, si Immich détecte que l’image existe déjà, il ne l’ajoutera pas :

Crawling for assets...
Hashing files           | ████████████████████████████████████████ | 100% | ETA: 0s | 1/1 assets
Checking for duplicates | ████████████████████████████████████████ | 100% | ETA: 0s | 1/1 assets
Found 0 new files and 1 duplicate
All assets were already uploaded, nothing to do.

En fait, pour chaque image, un hash est créé et stocké dans la base de données. Mettre comme j’avais fait l’image dans la corbeille ne l’efface pas, l’image en question n’est simplement plus affichée dans Immich. Il faudra donc vider la corbeille pour pouvoir l’uploader à nouveau…

Toutes les infos et les exemples d’utilisation sont sur cette page.

Les commandes sont finalement assez limitées, j’espérais pouvoir par exemple forcer un upload pour remplacer une photo existante, ou pouvoir effacer un album ET ses photos. Ce n’est apparemment pas possible.

Sauvegarde

Il y a aussi l’aspect sauvegarde à prendre en compte, qui est expliqué ici. Une stratégie 3-2-1 est recommandée, soit une copie locale, une autre dans le cloud, et une troisième dans un lieu physique éloigné de quelques kms minimum… Mais bon, à chacun de voir l’importance qu’il accorde à ses photos et au risque que sa maison brûle alors que le cloud vient de perdre les données. :mad:

On peut retrouver l’arborescence de ses photos dans AppData/immich/library/user (selon le choix de modèle de stockage choisi (voir plus haut). La base de données est sauvegardée automatiquement chaque jour dans AppData/immich/library/backups.

Immich stocke deux types de contenu dans le système de fichiers : (a) les ressources originales non modifiées (photos et vidéos), et (b) le contenu généré. Le plus simple est donc de sauvegarder tout le contenu de AppData/immich/library/ pour être tranquille.

Un script pour les recopier sur un autre disque en local, typiquement sur une autre machine est une première étape. Les recopier aussi dans un cloud me paraît déjà pas mal comme niveau de sauvegarde.

Homepage Dashboard

Pour finir, j’ai bien sûr créé une entrée Immich dans mon Homepage Dashboard, en suivant la documentation pour le widget, mais j’ai d’abord eu un message d’erreur API :

C’était bizarre, puisque j’avais bien les infos sur le nombre de photos etc… mais pas celles sur le CPU, la MEM et le réseau. Logiquement, j’avais indiqué un mauvais nom pour le container (immich) : la stack créée dans Dockge s’appelle bien immich, mais le container pour le server s’appelle immich_server (en fait immich crée 4 containers, dont un pour le machine-learning).

Et donc en indiquant le bon nom de container, tout a fonctionné comme attendu :

Conclusion et ressenti

L’ensemble est vraiment pas mal, auto-héberger toutes les photos du smartphone de façon très simple, avec plein d’options très sympathiques (géolocalisation et détection de visage) est vraiment sympa. Et surtout, cela a l’air d’être beaucoup plus fiable que Nextcloud, ma solution précédente.

Je constate déjà qu’une photo ou un screenshot est immédiatement téléchargé sur le serveur, et visualiser la photo dans Immich (via Firefox) est plus rapide et semble plus pratique que de parcourir l’arborescence fichier de Nextcloud pour retrouver la photo.

J’aime bien avoir la possibilité de rechercher par localisation, et aussi par personne. C’est le genre de truc plutôt sympa ! :cool:

Avec les autres fonctionnalités, j’avais envisagé la création d’albums pour certaines photos comme celles de mes voyages, afin de les avoir facilement sur le tel grâce à l’application android. Mais les limitations en terme d’affichage, le mode “timeline”, ne me conviennent pas vraiment. J’aurais préféré avoir une vue mosaïque en option. J’aurais aussi aimé pouvoir créer des sous-albums pour mieux organiser les photos, mais c’est impossible. Enfin, les possibilités en mode commande (CLI) sont assez limitées.

On s’aperçoit alors des limitations d’Immich. Comme je le disais en début d’article, il a été créé au départ pour copier automatiquement les photos du smartphone sur une serveur sans avoir à remettre ses photos entre les mains de Google. Je pense que dans un premier temps, je vais me contenter de l’utiliser de cette manière, on verra si par la suite Immich évolue dans la direction que je souhaite.

FMD : Find My Device

Fri, 07 Nov 2025 15:18:18 +0000

Voilà une solution très pratique quand on veut localiser son téléphone, soit en le faisant simplement sonner soit en retrouvant sa position GPS (perte, vol). Ainsi que d’autres options plus radicales, comme de l’effacer à distance.

Je parle ici d’une application Android bien sûr, mais aussi de la partie serveur, l’ensemble fournissant une solution autonome totalement open source et sécurisée, respectant votre vie privée comme il se doit :

FMD vous permet de localiser, de faire sonner, d’effacer et d’envoyer d’autres commandes à votre appareil lorsqu’il est perdu. Il se veut une alternative open source sécurisée à Find My Device de Google.

Le serveur étant disponible en mode Docker, je l’ai installé très facilementsur mon NAS. Le client Android, disponible sur F-Droid, demandera lui un peu plus d’attention, car il a besoin d’un système de Push Notification, et de permissions particulières. Cela me prendra donc un peu plus de temps, mais finalement tout fonctionne comme attendu.

Voilà les différentes étapes à suivre…

Serveur

Le serveur s’installe en quelques minutes grâce à Dockge, rien de particulier à signaler, voilà le fichier compose.yaml :

services:
  fmd:
    # Use the prebuilt image
    image: registry.gitlab.com/fmd-foss/fmd-server:v0.12.0
    container_name: fmd
    ports:
      - 8182:8080
    volumes:
      - /srv/dev-disk-by-uuid-12354-67890/AppData/fmddata/db/:/var/lib/fmd-server/db/
    # hardening container
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges
    # end hardening
    restart: unless-stopped
networks: {}

J’ai juste changé le port par défaut, et ajouté les paramètres de sécurité.

Comme d’habitude, il va falloir déclarer un sous-domaine et créer un fichier fmd.subdomain.conf sur le proxy :

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name fmd.mon-domaine.fr;

    client_max_body_size 20m;

location / {
    proxy_pass http://192.168.1.32:8182;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Je ne réexplique pas cette partie, voir les autres articles (celui-ci par exemple), c’est toujours la même chose.

Et on démarre le serveur. De ce côté tout est prêt.

Info

Si vous ne souhaitez pas installer votre propre serveur, il est possible d’utiliser celui du développeur :

https://fmd.nulide.de et d’y créer un compte pour son smartphone.

Dans ce cas, seule la partie ci-dessous concernant le smartphone vous concerne.

Client Android

Côté smartphone, ça va se révéler un peu plus complexe à mettre en œuvre, d’abord pour les permissions à accorder à l’application, puis au système de notification qui oblige à installer une application supplémentaire (Sunup).

La doc officielle pour le client Android est bien détaillée. À noter aussi cet article sur le forum de GrapheneOS très intéressant. On commence par installer le client FMD à partir de F-Droid.

On lance l’application, puis il faut dans un premier choisir de s’inscrire pour créer un compte sur le serveur. Choisir un nom pour le FMD ID (“Pixel6a” par exemple, puisque le serveur peut-être utilisé pour plusieurs téléphones) et un mot de passe. Laisser le champ “Token” vide.

Mais la connexion échoue avec un beau message d’erreur :

Après quelques recherches, je tombe vite sur un bug déjà créé, et finalement lié à un autre concernant les certificats auto-signés, comme ceux que mon proxy swag utilise (Letsencrypt). Il est désormais corrigé, mais il faudra attendre la prochaine version du client Android.

En attendant, je désinstalle la version 0.12.1 que j’utilisais (la plus récente), et installe la 0.11.0 qui accepte les certificats LetsEncrypt. Cette fois la création du compte fonctionne ! Il faut ensuite accorder toutes les autorisations nécessaires à l’application selon les fonctionnalités que vous souhaitez activer/utiliser :

Comme vous le voyez, je n’ai pas activé l’option “Delete” ni l’option “Lock”. La première me paraît ultime, la deuxième me paraît peu importante, partant du principe que l’appareil est déjà verrouillé si je le perds ou que l’on me le vole. À voir, la réflexion est tout de même en cours… Pour l’option “Delete”, j’ai lu que votre code PIN vous sera demandé, ce qui sécurise quand même l’action.

Les deux options qui m’intéressent le plus, c’est de pouvoir le faire sonner, ou d’obtenir sa position GPS. Accessoirement, prendre une photo peut aussi se révéler utilse.

Mais pour pouvoir autoriser la fonction GPS, FMD doit pouvoir activer automatiquement les services de localisation lorsque vous déclenchez une commande fmd locate (depuis le serveur), puis les désactiver à nouveau. Cela nécessite une autorisation spéciale : WRITE_SECURE_SETTINGS, et c’est là que ça se complique un peu.

Pour ce faire, il va falloir utiliser une commande adb.Tout est expliqué ici dans la doc officielle, je ne répète donc pas chaque étape. Il faut que côté smartphone le mode Débogage USB soit activé dans les options pour les développeurs :

Avoir adb installé sur le PC, puis taper la commande suivante :

pm grant de.nulide.findmydevice android.permission.WRITE_SECURE_SETTINGS

Sunup

Terminé ? pas tout à fait ! FMD utilise UnifiedPush pour recevoir des notifications push. Aucune donnée sensible n’est envoyée dans les notifications push, elles servent uniquement à réveiller FMD. Celui recommandé est Sunup. L’installation est très simple, et il faut ensuite relancer FMD et le faire s’enregistrer sur Sunup:

Une fois ceci fait, on voit FMD dans les applications enregistrées par l’appli Sunup :

Cette fois, tout est prêt côté Android, on peut désormais aller sur l’interface web du serveur et tester les différentes commandes.

SMS

Vous pouvez aussi déclarer des contacts de confiance autorisés à vous envoyer des commandes via SMS ( fmd locate, fmd ring, fmd camera, etc…), et recevoir des réponses par SMS. Pratique si l’appareil a perdu sa connexion internet mais a au moins accès au réseau 2G.

Je n’ai pas testé cette fonctionnalité (contacts de confiance & SMS), mais on peut tester les commandes en local très facilement :

Utilisation du service

L’interface web du serveur se présente comme suit :

Il faut donc s’identifier avec l’identifiant utilisé sur l’application Android précédemment(“Pixel6a”) et le mot de passe choisi. Une fois connecté, les différentes commandes possibles apparaissent sous la carte :

On peut donc géolocaliser son smartphone, faire sonner, verrouiller, effacer, prendre une photo et la visualiser. Enfin, avec le dernier bouton “paramètres”, on peut exporter les données ou supprimer le compte. L’interface est assez basique, mais fonctionnelle. Voilà ce que cela donne :

À l’heure actuelle " seuls les n derniers emplacements et images sont stockés. Cela dépend de ce que l’opérateur du serveur a configuré." . On peut donc configurer le nombre d’emplacements et de photos conservés dans le fichier compose.yaml :

# How many location points or pictures FMD Server should save per account
MaxSavedLoc: 1000
MaxSavedPic: 10

Apparemment, le développement est actif, et de nouvelles fonctionnalités vont être ajoutées, y compris la gestion des emplacements et des photos.

Missing API token

Pour info, en faisant des essais, j’ai vu ce message d’erreur dans les logs :

Cette erreur se produit quand on fait une demande de localisation en mode “ALL” : cela inclut OpenCellId qui nécessite de créer un compte sur leur serveur et donc un API token. C’est donc normal, et une simple requête de localisation en mode “GPS” suffit pour obtenir la position :

Conclusion

Cette solution est vraiment satisfaisante, et totalement autonome. Comme le dit la personne sur le forum GrapheneOS :

I am absolutely aware that tracking application are problematic, however having an option to track down your mobile phone (if lost or stolen), ring it, factory reset it, etc., is a very useful one, especially if you have a complete control of your data.

Le développement a l’air très sérieux, avec la sécurité en tête. C’est vrai plus d’avoir cette fonctionnalité sur le tel !

Serveur Joplin en mode Docker

Sat, 25 Oct 2025 14:20:13 +0000

J’utilise depuis longtemps Joplin comme application de prise de notes. Elle est vraiment très complète, propose un client Android, et permet la synchronisation entre les appareils bien sûr. Tout ce qu’il me fallait entre le PC et le smartphone.

Puis j’ai vu qu’il était possible d’installer un serveur avec Docker pour synchroniser et partager les notes de manière plus efficace, j’ai donc décidé d’installer ce serveur sur mon joli NAS.

Joplin est vraiment très complet : il permet de créer des carnets dans lesquels on peut créer des notes (deux niveaux de classement donc, indispensable), il accepte tous types d’attachements aux notes (images, pdf, audio, etc…), propose un nombre impressionnants de plugins (+350 ?), dispose d’un éditeur markdown (le format de stockage des notes) mais aussi au format “rich text”, ou encore d’utiliser un éditeur externe, etc, etc… Difficile de faire plus complet ! Et bien sûr disponible sur toutes les plateformes (Windows, Linux, Android, iOS). Sans oublier une caractéristique importante :

Joplin est “hors ligne d’abord”, ce qui signifie que vous avez toujours toutes vos données sur votre téléphone ou votre ordinateur. Cela garantit que vos notes sont toujours accessibles, que vous ayez ou non une connexion Internet.

Enfin c’est un français, Laurent Cozic (un breton en plus ! :cool: ) qui en est le créateur. Il s’est lancé dans ce projet en 2016, ne trouvant pas ce qu’il voulait dans les solutions existantes : un logiciel open-source axé sur la sécurité et la vie privée. Bravo à lui ! On peut se dire que depuis preques 10 ans, Joplin est devenu un logiciel assez abouti avec plein de fonctionnalités.

Voilà l’interface du client sur Linux :

Mais cet article concerne la mise en place du serveur : ça a été assez simple, mais voyons voir cela tout de même…

Configuration Nextcloud

Jusqu’ici, j’utilisais mon serveur Nextcloud pour stocker mes notes. Joplin propose un mode Nextcloud pour la synchronisation, mais j’utilisais plutôt le mode WebDAV car le premier ne fonctionnait pas ou mal (c’est pourtant du webdav dans les deux cas)). Et dans les deux cas, la synchronisation était très lente. Les notes étaient stockées dans un dossier, à plat et en mode texte, dans un format markdown classique ( .md).

Et puis j’ai vu qu’il existait une version serveur pour stocker ses notes, et qu’elle existait au format Docker. L’intérêt de passer en mode serveur (outre celui de monter nouveau container Docker sur mon NAS ! :razz: ) est d’améliorer la vitesse de synchronisation et la sécurité avec une connexion HTTPS, une base de données pour les notes, mais aussi de gérer plusieurs utilisateurs, et même la possibilité de partager des notes entre eux.

Le container Docker

Comme toujours, j’utilise Dockge pour gérer mes containers. Voilà le contenu du fichier compose.yaml pour Joplin :

services:
  db:
    image: postgres:16
    volumes:
      - /srv/dev-disk-by-uuid-aaaa-bbbb-cccc-dddd/AppData/joplin/joplindb:/var/lib/postgresql/data
    ports:
      - 5432:5432
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=votremotdepasse
      - POSTGRES_USER=user
      - POSTGRES_DB=postgres
  app:
    image: joplin/server:latest
    depends_on:
      - db
    ports:
      - 22300:22300
    restart: unless-stopped
    environment:
      - APP_PORT=22300
      - APP_BASE_URL=https://adresse_externe_de_mon_serveur_joplin
      - DB_CLIENT=pg
      - POSTGRES_PASSWORD=votremotdepasse
      - POSTGRES_DATABASE=postgres
      - POSTGRES_USER=user
      - POSTGRES_PORT=5432
      - POSTGRES_HOST=db
networks: {}

On voit que l’on installe un container Postgres (version Docker de la base de données PostgreSQL) où le serveur Joplin ira stocker les notes.
Adapter les user, password et db de la base de données.
Pour Joplin, veiller à bien indiquer l’adresse externe par laquelle on accédera au serveur de l’extérieur.

Sous-domaine

Comme d’habitude, il faut commencer par créer un enregistrement CNAME pour le sous-domaine que l’on va utiliser pour Joplin. Cela se passe chez l’hébergeur web du blog, Infomaniak dans mon cas, et fait partie de l’offre. Et c’est toujours le même principe, petit rappel au cas où :

J’ai donc un domaine pour héberger mon blog ( pled.fr) pour lequel je paie chaque année un peu moins de 10€.
Je crée sur le site de l’hébergeur un sous-domaine mon-nas.pled.fr (enregistrement de type A) qui pointe vers l’adresse IP de ma box.
Puis je crée autant de sous-domaines (enregistrement de type CNAME) pour tous mes services docker ( nextcloud.mon-nas.pled.fr, joplin.mon-nas.pled.fr, etc…) qui tournent sur mon NAS, dont la valeur pointe vers mon premier sous-domaine de type A. Le routage vers les services sera traité par mon proxy (nginx ou swag en l’occurrence).

Voilà donc ce qu’il faut avoir pour le service Joplin :

TypeNomAdresse BoxAmon-nas.pled.fr1.2.3.4TypeNomAlias deCNAMEjoplin.mon-nas.pled.frmon-nas.pled.fr

Toutes les requêtes vers les services Docker vont être adressées à l’enregistrement de type A, soit vers l’adresse IP de la box. C’est aussi simple que ça. C’est ensuite au proxy de gérer la distribution des messages vers chaque service, grâce au numéro de port.

Configuration du proxy

Le tri est donc gérée par le proxy. Dans mon cas, il s’agit de Swag, installé avec le container Nextcloud. C’est essentiellement un serveur web nginx avec php7, fail2ban (prévention des intrusions) et la validation de certificats Let’s Encrypt intégrée.

Comme pour chaque service Docker, j’ai créé un fichier joplin.subdomain.conf dans le dossier AppData/swag/nginx/proxy-confs :

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name joplin.mon-nas.pled.fr;

    client_max_body_size 20m;

location / {
    proxy_pass http://192.168.x.y:22300;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Le proxy écoute sur le port 443 (https) puis redirige les messages adressés au sous-domaine joplin vers le port 22300 indiqué dans le fichier compose.yaml plus haut.

Info

Cette fois, j’ai du y ajouter quelques règles supplémentaires pour que l’accès au serveur Joplin soit possible. Sans les trois règles “proxy_set” ci-dessus, j’obtenais cette erreur :
Invalid origin: http://192.168.1.xx:22300
dans le navigateur.

Enfin, pour obtenir le certificat LetsEncrypt, il ne faut pas oublier d’ajouter joplin à la liste des sous-domaines dans le fichier concernant swag :

services :
...
  swag:
...
    environment:
...
      - SUBDOMAINS=nextcloud, joplin
...

Et on redémarre le proxy pour prendre ces modifications en compte.

Le serveur Joplin

Une fois le container Joplin démarré, on peut donc accéder à l’adresse du type https://joplin.mon-nas.mon-domaine.fr :

Pour la première connexion, utiliser :

Email : admin@localhost
Password : admin

Une fois identifié, il convient bien sûr de changer le mot de passe comme demandé :

Profitez-en pour changer à la fois l’adresse mail et le mot de passe. Un mail de confirmation va alors être envoyé. Comme nous n’avons pas configuré de serveur mail, tout se passe en interne à Joplin : il faut aller dans la partie Admin et sélectionner Emails dans le menu de gauche : puis ouvrir le mail intitulé “Confirm your new Joplin Server account email” :

Et enfin cliquer sur “Confirm email” :

Et voilà, le serveur Joplin est opérationnel.

Les clients

J’utilise deux clients pour l’instant, un sur le PC et l’autre sur le tel.

Linux

Sur le PC Debian, l’installation et la mise à jour se fait avec la même commande :

wget -O - https://raw.githubusercontent.com/laurent22/joplin/master/Joplin_install_and_update.sh | bash

Le script s’occupe de tout, il installe en fait l’application au format AppImage ici : /home/pascal/.joplin/Joplin.AppImage, ainsi que le fichier .desktop nécessaire pour l’intégration à Gnome (icône) là : .local/share/applications/appimagekit-joplin.desktop.

Ici il va détecter la version existante, et la mettre à jour :

Pour la synchronisation, il suffira d’aller dans Outils - Options, et d’y définir la nouvelle méthode de synchronisation avec l’adresse du serveur ainsi que l’adresse mail et le mot de passe définis précédemment :

Puis je lance une synchronisation (ou Ctrl-S) et toutes mes notes existantes seront immédiatement copiées vers le serveur. J’observe déjà le gain de vitesse par rapport à la synchro WebDAV utilisée précédemment.

Android

Côté Android, c’est la même chose. L’appli est disponible sur le Google Play Store mais aussi sur F-Droid.

Conclusion

Je vais désormais faire de Joplin mon unique logiciel de prises de notes.

Car j’avais commencé à utiliser en parallèle Nextcloud Notes, qui possède aussi sa propre application Android. Mais à l’usage, c’est beaucoup moins abouti que Joplin, et l’appli souffre de problèmes récurrents, comme la synchronisation que l’on doit parfois forcer, ou l’affichage en mode “text enrichi” qui ne fonctionne pas.

L’application Joplin est plus fiable et pratique à l’usage, et je crois qu’il y a en projet de refonte totale afin d’en améliorer l’ergonomie.

NAS

Voilà un serveur de plus d’ajouté à mon NAS ! Je peux commencer à parler sérieusement d’auto-hébergement ! :cool:

Gokapi pour échanger des fichiers

Tue, 02 Sep 2025 15:05:11 +0000

Il vient toujours un moment où l’on a besoin d’échanger des fichiers avec un proche. J’avais jusqu’à présent utilisé Nextcloud, mais sa fonctionnalité de partage ne me convenait pas, alors je me suis mis à la recherche d’une solution alternative, si possible utilisant Docker, afin de l’installer sur mon NAS.

J’ai posé la question sur le forum d’OMV, et j’ai vite obtenu deux réponses, la première m’indiquait un site github très intéressant : Awesome self-hosted, qui liste des applications (en logiciel libre) qui peuvent être auto-hébergés (il y a même une page pour les logiciels non libres). La liste est impressionnante. La deuxième réponse m’indiquait plus précisément l’un d’entre eux, à savoir Gokapi, qui répondait parfaitement à mes attentes.

Voyons voir cette installation qui s’est révélée très simple, en commençant par la raison pour laquelle Nextcloud ne convient pas à ce besoin.

Nextcloud

Avec Nextcloud, lorsque l’on crée un lien de partage public, ce dernier va chercher automatiquement à ouvrir le fichier dans le navigateur, que ce soit une vidéo, un pdf, etc… : si le navigateur peut afficher le fichier, il le fera. Il y a bien un mini menu en haut à droite pour télécharger le fichier, mais ce n’est pas ce que je souhaite :

J’ai vu que l’on pouvait ajouter /download au lien fourni, mais dans ce cas, le téléchargement démarre immédiatement. Or ce n’est pas le comportement que je souhaite : lorsque j’envoie un lien à un ami, je veux qu’un bouton s’affiche et lui propose de télécharger ce fichier.

De ce que j’ai pu lire sur le net, Nextcloud se considère comme une plateforme de collaboration et pas de téléchargement. Il ne faut donc rien attendre de ce côté, même si cette justification me paraît un peu tirée par les cheveux.

Gokapi

J’ai donc installé Gokapi. C’est parfait pour mon utilisation :

Gokapi est un serveur léger pour partager des fichiers, qui expirent après un certain nombre de téléchargements ou de jours. Il est similaire à l’ancien Firefox Send, à la différence que seul l’administrateur est autorisé à télécharger des fichiers.

Ses possibilités sont assez étendues : chiffrement, stockage cloud (AWS) ou local, expiration fichiers et effacement automatique, protection par mot de passe, partage de fichier par simple lien (et même QR Code)… Il dispose aussi d’une API. Tout est bien expliqué dans la documentation. Dans cet article, je vais juste faire une installation en mode Docker, et utiliser mon NAS pour le stockage, tout simplement.

Comme d’habitude, j’utilise Dockge pour installer le container. Le fichier compose.yaml est très simple :

services:
  gokapi:
    image: f0rc3/gokapi:latest
    container_name: gokapi
    environment:
      - TZ=Europe/Paris
      - GOKAPI_MAX_FILESIZE=350000
    ports:
      - 53842:53842
    volumes:
      - /srv/dev-disk-by-uuid-12345-6789-abcd-ef/AppData/Gokapi/gokapi-data:/app/data
      - /srv/dev-disk-by-uuid-12345-6789-abcd-ef/AppData/Gokapi/gokapi-config:/app/config
    restart: always
networks: {}

Puis on démarre le container, qui affiche le lien vers la page de configuration :

gokapi  |
gokapi  | ██████   ██████   ██   ██  █████  ██████  ██
gokapi  | ██       ██    ██ ██  ██  ██   ██ ██   ██ ██
gokapi  | ██   ███ ██    ██ █████   ███████ ██████  ██
gokapi  | ██    ██ ██    ██ ██  ██  ██   ██ ██      ██
gokapi  |  ██████   ██████  ██   ██ ██   ██ ██      ██
gokapi  |
gokapi  | Gokapi v2.1.0 starting
gokapi  | Please open http://127.0.0.1:53842/setup to setup Gokapi.

Dans mon cas, j’ai bien sûr remplacé l’adresse locale par celle de mon NAS, et j’ai complété l’installation en répondant aux questions de l’assistant. Il faut juste faire attention à l’URL publique (“public facing URL”) que l’on vous demande de saisir à l’étape Webserver 2/2 :

Comme pour d’autre containers, j’avais précédemment créé un sous-domaine chez mon hébergeur pour pointer sur mon NAS : gokapi.mondomaine.fr, ajouté le sous-domaine à ma stack nextcloud-swag (pour obtenir un certificat), et créé un fichier gokapi.subdomain.conf sur le serveur nginx.

$ cat gokapi.subdomain.conf
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name gokapi.mondomaine.fr;

location / {
    proxy_pass http://192.168.x.y:53842;
    }
}

C’est donc cette adresse qu’il faut saisir pour que les liens soient accessibles de l’extérieur. Et voilà, tout fonctionne sans accroc. Pour plus de détails sur l’installation de Gokapi, vous pouvez aller voir cette page Installer Gokapi avec Docker, bien détaillée et expliquée.

Personnalisation

La documentation est plutôt bien faite, et comprend une partie Customization.

En mode docker, ça n’a pas l’air évident et je n’ai pas creusé plus que ça. On peut ajouter un volume supplémentaire au fichier compose.yaml pour monter un dossier supplémentaire appelé custom, et le monter sur /app/custom :

    volumes:
      - /srv/dev-disk-by-uuid-12345-6789-abcd-ef/AppData/Gokapi/gokapi-data:/app/data
      - /srv/dev-disk-by-uuid-12345-6789-abcd-ef/AppData/Gokapi/gokapi-config:/app/config
      - /srv/dev-disk-by-uuid-12345-6789-abcd-ef/AppData/Gokapi/custom:/app/custom

Dès lors, il suffit d’y créer un fichier custom.css pour que son contenu soit appliqué à toutes les pages. Idem pour le JavaScript avec un fichier public.js ou admin.js (pour les pages liées à l’admin).

Pour avoir une favicon personnalisée, il suffit de placer dans ce dossier une image de type PNG et d’une taille 512x512. Cette fonctionnalité est récente (3j) et n’est pas encore disponible dans la dernière version release (v2.1.0 à ce jour).

J’ai lu ici que l’on pouvait aussi monter /app/templates et /app/static folders comme des volumes, y copier les fichiers sources (télécharger par exemple le fichier Gokapi-2.1.0.zip pour ce faire), et modifier les fichiers (HTML/CSS) à l’intérieur de ces dossiers. Mais en cas de changement de version, il faudra sans doute refaire l’opération…

Conclusion

Voilà un service bien pratique d’installé. On peut très facilement partager un fichier, indiquer une date d’expiration ou un nombre de téléchargement maximum. Je me limiterai à cet usage, et pour cela, Gokapi est parfait.

Memos, prise de notes rapides

Fri, 22 Aug 2025 13:43:19 +0000

La gestion de notes est une problématique récurrente en informatique et l’on est toujours à la recherche de la solution parfaite, qui n’existe pas vraiment puisque chacun voit midi à sa porte sur le sujet d’une part, et peut aussi avoir des besoins contradictoires d’autre part.

À chacun donc de trouver sa ou ses solutions, ce ne sont pas les applications qui manquent sur le marché. La première chose à faire est d’ailleurs sans doute de définir ses besoins. Pour ma part, j’utilise deux applications différentes (Joplin et Nextcloud Notes), le seconde me permettant de partager une note par un lien web (pratique). Cela pourrait changer avec Memos…

Car j’avais aussi le besoin de pouvoir noter quelque chose rapidement, une info, une idée, un titre de bouquin, pas forcément pour la conserver dans le futur (encore que…), mais à avoir sous la main en cas de besoin, et surtout rapide à saisir.

Puisque j’ai un joli NAS désormais, et que j’apprécie la simplicité de Docker, j’ai regardé de ce qui existait de ce côté et trouvé Memos, qui sert exactement à cela :

L’interface Web est claire et bien conçue, le serveur s’installe via Docker en deux minutes, Memos semble tout à fait convenir à mes besoins. Et pas besoin d’applications spécifiques pour l’utiliser, tout se passe dans le navigateur.

Voyons voir un peu tout cela, en commençant par la solution que j’utilisais jusqu’à présent, puis à l’installation et l’utilisation de Memos.

Messagerie Signal

Pour ce besoin de prises de notes rapides, j’utilisais une appli de messagerie, Signal en l’occurrence (mais on peut faire la même chose avec Whatsapp), et aussi pour copier/coller rapidement une info ou un fichier entre le PC et le smartphone. Les applis de messagerie créent toutes un compte pour l’utilisateur, et il me servait donc pour ces petites notes rapides :

L’inconvénient, c’est que mes messages Signal sont paramétrés pour s’effacer automatiquement au bout de 6 mois. L’idée étant de ne pas avoir à les conserver ces notes, c’était la solution que j’avais choisi. Mais à l’usage, retrouver même ce genre de notes quelques mois plus tard peut s’avérer pratique.

Installation de Memos

Je cherchais donc une autre façon de faire, avec une solution à base de Docker, et je suis tombé sur Memos. L’interface claire et lisible m’a plu, la recherche par date avec le calendrier aussi, et enfin la possibilité d’ajouter un #tag pour catégoriser à minima les notes, tout cela m’a paru cohérent et répondant à mes besoins.

L’installation en mode Docker, avec l’aide de Dockge, est simplissime. Le fichier compose.yaml est d’ailleurs très court :

services:
  memos:
    image: neosmemo/memos:stable
    container_name: memos
    volumes:
      - /srv/dev-disk-by-uuid-f12c345a-67e8-910/AppData/memos/:/var/opt/memos
    ports:
      - 5230:5230
networks: {}

On démarre, et c’est tout. Pour obtenir un accès depuis l’extérieur, j’ai procédé comme d’habitude :

Créer un sous-domaine, soit un nouvel enregistrement de type CNAME pour le service memos, sous la forme : memos.sous-domaine.domaine via l’interface de mon hébergeur.
un fichier un fichier memos.subdomain.conf dans AppData/swag/nginx/proxy-confs/ :

$ cat memos.subdomain.conf
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name memos.nas-n150.pled.fr;

location / {
    proxy_pass http://192.168.1.32:5230;
    }
}

Sans oublier d’ajouter au ficher compose.yaml de swag le nouveau sous-domaine, afin d’obtenir le certificat letsencrypt, et pouvoir me connecter en https :

- SUBDOMAINS=nextcloud,homepage,calibre,memos

Et voilà, tout est prêt et fonctionnel.

Utilisation

Le serveur Memos étant multi-utilisateurs, on commence par se créer un compte et un mot de passe, choisir le français comme langue, choisir en thème (j’ai choisi “paper”), etc…

La prise de notes

La syntaxe est du markdown, c’est donc assez classique, tout est expliqué sur cette page. On peut créer des titres, des listes, des cases à cocher, des tableaux, etc…

Il y a 5 petites icônes proposées par défaut pour se faciliter la vie : le premier affiche les tags existants afin de pouvoir en sélectionner, le second propose d’insérer du code ou des cases à cocher, vient ensuite les attachements, puis l’insertion de liens, et enfin la localisation si vous souhaitez l’ajouter à votre note :

Partager une note

Sur la droite, on peut choisir de partager la note en la rendant publique. L’autre option, “espace de travail”, doit permettre de la partager avec d’autres utilisateurs de l’instance de Memos, je ne l’ai pas testée.

Une fois “Public” sélectionné, une option “Copier le lien” apparaît dans le menu de droite :

Voilà ce que donne le lien partagé d’une note contenant du texte, une image insérée et un document PDF en attachement :

Memos peut donc aussi remplacer mon utilisation de Nexcloud Notes qui ne me satisfait pas totalement. D’abord, elle nécessite une application dédiée sur le smartphone (“less is more”), et le même problème revient régulièrement : le passage du mode d’affichage de “Édition simple’ à “Édition texte enrichi” provoque un message d’erreur sur la synchronisation et affiche un conflit alors qu’aucune modification n’a été apportée à la note :

De fait, l’utilisation d’une appli web résout facilement tous ces problèmes d’affichage de texte enrichi qui semblent un peu “bugués” sur l’appli Nextcloud.

Smartphone

Côté smartphone, il n’y a pas d’applications dédiée, c’est une Web App (PWA) : il suffit de créer un raccourci sur le bureau avec le navigateur, en ouvrant l’URL de la page (par exemple https://memos.mondomaine.fr), puis en allant choisir “Ajouter à l’écran d’accueil” dans le menu en haut à droite.

Conclusion

Je vais voir à l’usage ce que cela donne. À priori, cela correspond bien à mon besoin. L’installation est super simple, c’est très facile d’obtenir l’accès en HTTPS grâce à swag, tout comme créer le sous-domaine. Quant à l’interface de Memos, je la trouve hyper propre, sans fioritures, très sobre, bien pensée et très efficace. Bravo aux devs !

Pi-hole en container Docker et serveur DHCP

Tue, 29 Jul 2025 08:50:54 +0000

Je continue de profiter de mon nouveau NAS, et cette fois j’installe Pi-Hole dans un container Docker. Je vais ainsi pouvoir dédié mon Raspberry à Volumio, et éviter de devoir faire des modifications à l’image Volumio pour faire tourner Pi-Hole, ce qui me compliquait (ou même bloquait) les mises à jour (de l’un comme de l’autre). Une bonne chose à faire donc.

De plus, avec Pi-hole en mode Docker, va désormais télécharger automatiquement la dernière version (paramètre “latest”) à chaque démarrage. Les “Ads lists” seront également automatiquement mises à jour une fois par semaine. Ce qui est bien pratique, le serveur restera ainsi à jour en permanence.

Mais comme je l’utilise comme serveur DHCP, cela va poser quelques contraintes car il faudra que le serveur réponde aux messages DHCP qui passent en broadcast sur mon LAN. Or ce n’est pas le cas par défaut d’un container Docker (interface réseau en mode bridge). Il m’a donc fallu faire mon choix entre les solutions proposées pour le “network mode”. J’ai finalement opté pour la méthode macvlan, et j’expliquerai pourquoi et les contraintes de ce choix. J’avoue que je me suis bien pris la tête avec ça ! :shock:

Pour le reste, tout a été assez facile à réaliser, une fois le bon fichier compose.yaml configuré. En effet, pas mal de choses ont changé avec la v6, y compris les paramètres, etc… Et les tutos que l’on trouve concernent souvent la v5. D’ailleurs, cet article fait référence à la version Docker actuelle (2025.07.1) et donc Pi-hole v6.2.3.

C’est parti !

Pi-hole DHCP & Docker

Le principe de base de Docker, c’est d’isoler les containers, et donc par défaut c’est le mode bridge qui est utilisé et recommandé pour l’adaptateur réseau par défaut (le container passe par le host). Or les messages de type ‘broadcast’ utilisés par DHCP ne passeront pas sur le LAN, ce qui est nécessaire si l’on souhaite utiliser Pi-hole comme serveur DHCP.

En utilisant Pi-hole comme serveur DHCP, il va fournir aux clients l’adresse du serveur DNS en même temps que l’adresse IP, et ainsi tous les appareils de mon réseau sont automatiquement configurés comme je le souhaite, et bénéficieront du filtrage de Pi-hole, que ce soit la TV ou l’imprimante comme je peux le constater sur les stats Pi-hole :

Les modes réseau

Puisque je veux utiliser Pi-hole comme serveur DHCP dans un container Docker, je dois choisir un mode réseau. Les différentes possibilités sont décrites sur cette page.

Le host networking mode est le plus simple à mettre en place, mais le serveur Pi-hole aura la même adresse IP que l’hôte (mon NAS), ce qui peut générer des conflits de ports avec le NAS.
Le macvlan network mode attribuera sa propre adresse sur votre LAN au serveur Pi-hole. Il n’y a donc aucun problème de conflit de port à craindre. Le container ainsi créé pourra communiquer avec les machines sur mon LAN, mais par contre ne pourra pas communiquer avec les autres containers du NAS en mode bridge.
Le bridge networking mode nécessite un DHCP relay sur le LAN qui va renvoyer le port 67 (DHCP) à Pi-hole. Cette solution permet de conserver le mode bridge mais nécessite une autre pièce logicielle sur le LAN et me semble donc plus complexe. Je ne l’ai pas essayée, mais cet article fournit un bon exemple sur sa réalisation (attention aux paramètres du fichier compose, ce n’est pas la v6).

J’ai donc choisi le mode macvlan, qui me paraissait le plus adapté à ce que je souhaitais. Par défaut, ce container ne pourra donc pas communiquer avec mes autres containers, puisqu’ils sont en mode bridge. Il est possible de contourner cette limitation, mais cela oblige à revoir pas mal de choses. Vous trouverez en fin d’article plus de détails sur le fonctionnement de cette interface macvlan, du pourquoi et du comment, c’est assez technique. Personnellement, je ne suis pas allé jusque là : finalement, seul mon tableau de bord Homepage était impacté par cette limitation, et franchement la meilleure solution était de s’en passer ! :cool:

Création du macvlan network

Il faut donc commencer par créer une interface réseau de type macvlan pour le container Docker Pi-hole que l’on va ensuite créer. On peut utiliser l’interface d’OMV (dans Services-Compose-Networks), mais une commande Docker fera très bien l’affaire :

pascal@NAS-N150:~$ sudo docker network create --driver macvlan --attachable --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=enp1s0 macvlan-ntw

J’indique donc le driver souhaité (mavclan), puis les infos de mon LAN (subnet, gateway), le nom de l’interface réseau du NAS (enp1s0) et enfin je lui donne un nom (macvlan-ntw).

On retrouve l’interface créée dans OMV-Services-Compose-Networks, et on peut cliquer sur ‘Inspect’ pour en voir les détails.

Le container Pi-hole

On peut désormais créer le container pour Pi-hole. J’ai eu un peu de mal à trouver de bons tutos, avec les bons paramètres. Pour trouver les bonnes infos, il faut que le tuto concerne la v6 de Pi-hole, que ce soit une installation en mode Docker, et qu’enfin Pi-hole soit utilisé comme serveur DHCP.

Bref, voilà mon fichier compose.yaml, à adapter à votre cas (UID, GID, adresse réseau, adresse mail, mot de passe, volumes). NOTE : j’utilise Dockge pour gérer mes containers.

On utilise bien sûr l’interface macvlan créée plus haut, et on définit une adresse statique pour le serveur Pi-hole (dans l’idéal, en dehors du range d’adresse que l’on va attribuer au serveur DHCP). Et on mappe les ports que l’on va utiliser, notamment le 53 (DNS), 80/443 (interface web) et 67 (DHCP).

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      # DNS Ports
      - 53:53/tcp
      - 53:53/udp
      # Default HTTP Port
      - 80:80/tcp
      # Default HTTPs Port. FTL will generate a self-signed certificate
      - 443:443/tcp
      # Uncomment the below if using Pi-hole as your DHCP Server
      - 67:67/udp
    environment:
      # Set the appropriate timezone for your location (https://en.wikipedia.org/wiki/List_of_tz_database_time_zones), e.g:
      - TZ=Europe/Paris
      - PIHOLE_UID=996
      - PIHOLE_GID=100
      - ADMIN_EMAIL=user@mail.com
      # Set a password to access the web interface. Not setting one will result in a random password being assigned
      - FTLCONF_webserver_api_password=xxxxxxxx
    # Volumes store your data between container upgrades
    volumes:
      # For persisting Pi-hole's databases and common configuration file
      - /srv/dev-disk-by-uuid-xxxxx-yyyy-zzzz-7697ca5/AppData/Pi-hole/etc-pihole:/etc/pihole
      - /srv/dev-disk-by-uuid-xxxxx-yyyy-zzzz-7697ca5/AppData/Pi-hole/etc-dnsmask.d:/etc/dnsmask.d
    cap_add:
      - NET_ADMIN
    restart: unless-stopped
    networks:
      macvlan-ntw:
        ipv4_address: 192.168.x.y
networks:
  macvlan-ntw:
    external: true

Et voilà, il n’y a plus qu’à démarrer le container, et à se connecter via l’interface web à l’adresse http:pi.hole/admin/login ou mieux https://<adresse ip pi-hole>/admin/login.

Post-Installation

DNS

La première chose à faire, c’est de définir les DNS. Je choisis Cloudfare, que j’utilisais déjà avec la version précédente de Pi-hole :

À noter que j’avais dans un premier temps coché également les cases IPv6, mais cela me générait des erreurs dans les logs de Pi-hole :

WARNING: Connection error (2606:4700:4700::1111#53): failed to send UDP request (Network unreachable)

C’était parce que mon LAN est en IPv4 et que l’IPv6 est désactivé. Logique.

DHCP

Ensuite, on active le service DHCP, et on attribue un range d’adresse pour les différents appareils sur mon réseau, et je laisse bien sûr la box comme passerelle par défaut :

Dans l’exemple ci-dessus, je m’arrête donc à l’adresse 192.168.1.100, ce qui me laisse encore pas mal d’adresses de libres que je pourrai utiliser selon les besoins : adresse IP statique pour certains serveurs, nouveau range d’adresses pour d’autres besoins (voir en fin d’article le cas macvlan).

Toujours sur cette page (en mode expert), j’ai d’ailleurs assigné des adresses IP fixes aux élément de mon réseau, avec un bail infinite, histoire de me simplifier la vie :

Box SFR

Concernant la box et le décodeur TV, j’ai procédé de la même manière qu’avec la box orange, même si c’est susceptible de changer. Pour l’instant, ma box a toujours le service DHCP activé, mais seulement pour 2 adresses :

Et je démarre le décodeur TV avec le DHCP de Pi-hole arrêté pour que le décodeur obtienne l’adresse 192.168.1.2. Je l’ai même ajouté en adresse statique :

J’ai bien essayé de mettre la dernière adresse à 192.168.1.2 pour qu’il n’y ait qu’une seule adresse offerte par le serveur DHCP de la box, mais cela ne passe pas, l’adresse de début et de fin doivent être différentes. J’ai donc une adresse 192.168.1.3 disponible et qui peut être attribuée à un autre élément du réseau, ce que je ne souhaite pas, mais pour l’instant je n’ai pas d’autre solution. Ce n’est pas parfait, mais cela fonctionne.

Mais comme je le disais dans l’article sur mon passage à la fibre, j’ai vu que contrairement à Orange, la décodeur TV SFR accepte de recevoir son adresse IP du serveur Pi-hole. Cela me permettait même de regarder le Replay de M6 sans publicités (génial !), mais par contre le Replay de FranceTV ne fonctionnait plus du tout.

J’aimerais donc bien désactiver le serveur DHCP de la box, et de procéder par ajout dans la liste blanche de Pi-hole quand je lance le Replay de FranceTV ou quand j’ai une situation de blocage, et voir si cette solution est viable… Au mieux, j’arrive à faire fonctionner le tout en supprimant un certain nombres de publicités des différents services de Replay (et je n’ai qu’un seul serveur DHCP). Au pire, je reviens à la configuration actuelle.

Ads listes

Par défaut, Pi-hole est fourni avec une liste de sites de pubs ou de trackers à bloquer, et qui est déjà conséquente (~500 000). Il est recommandé de commencer avec cette liste, et de voir si elle convient. J’ai trouvé cet avis qui me paraît pertinent :

Je suggérerais d’utiliser la liste par défaut, et éventuellement d’autres listes qui sont mises à jour régulièrement. Beaucoup de listes se chevauchent, il y a donc probablement un point de rendement décroissant. De plus, vous pourriez commencer à découvrir que vous incorporez une liste qui bloque certains contenus que vous souhaiteriez voir, mais que le créateur de la liste ne veut pas voir.

Sinon, ce ne sont pas les articles qui manquent sur le sujet, et qui proposent tout un tas de listes. Comme dit ci-dessus, il est important qu’elles soient tenues à jour. J’ai tout de même noté qui semble être une bonne référence : https://firebog.net/.

Info

IMPORTANT :Une fois les listes ajoutées ou modifiées, il faut aller dans le menu Tools > Update Gravity pour lancer une mise à jour de la base de données.

Cerise sur la gâteau : la mise à jour de ces listes est automatisée par une tâche cron dans le container Docker. Elle se déclenche une fois par semaine.

Problème avec Homepage

Le seul problème que j’ai rencontré est donc celui lié au mode réseau choisi (macvlan). Comme expliqué, avec ce type d’interface, on ne peut plus communiquer avec le host, et donc avec les autres containers en mode bridge. Or j’utilise Homepage comme tableau de bord de mes serveurs, qui tourne dans un autre container. Et donc quand j’ai voulu utiliser les fonctions “widget” de Homepage pour le serveur Pi-hole, qui doivent m’afficher des stats :

J’avais un beau message d’erreur à la place, et le “ping” ne fonctionnait pas non plus :

Comme expliqué plus haut, je préfère m’en passer que de revoir toute la configuration réseau de mes containers. Je garde juste la définition du serveur Pi-hole dans le dashboard, sans widget ou ping, afin de pouvoir y accéder rapidement d’un clic, ce qui est mon utilisation essentielle de ce dashboard.

Tout fonctionne donc concernant le serveur Pi-hole.

L’adaptateur macvlan en détail

De tout ce qui a été dit plus haut, il est intéressant de revenir sur cet adaptateur macvlan, et de l’expliquer en détail, y compris comment on peut contourner sa limitation, à savoir qu’il est impossible de communiquer avec le host (donc le NAS en ce qui me concerne).

Les bases

Par défaut les containers Dockers utilisent donc le mode bridge, c’est-à-dire qu’ils vont utiliser l’interface réseau du host et ce dernier s’occupera de transmettre les messages aux containers. Pour le reste, le réseau est isolé par sécurité, c’est une des caractéristiques de Docker.

En mode macvlan, on assigne une adresse MAC à un container (et aussi une adresse IP). Pour ce faire, il faut que l’adaptateur réseau de l’hôte accepte le “promiscuous mode” (où une interface physique peut se voir attribuer plusieurs adresses MAC). L’hôte Docker accepte dès lors les demandes pour plusieurs adresses MAC, et achemine ces demandes vers le conteneur approprié. Dit autrement : le type de réseau macvlan vous permet de créer des “clones” d’une interface physique sur votre hôte et de l’utiliser pour attacher des conteneurs directement à votre réseau local.

Je peux le vérifier sur mon réseau avec la commande ip n : je vois bien l’adresse IP de mon NAS (192.168.1.xx) mais aussi celle assigné au serveur Pi-hole (192.168.1.yyy). Et leurs adresse MAC sont différentes :

$ ip n
192.168.1.yyy dev enp9s0 lladdr 4e:3d:e7:f7:1e:96 REACHABLE
...
192.168.1.xx dev enp9s0 lladdr e8:ff:1e:xx:yy:zz REACHABLE
...

La limitation

Si vous créez un tel conteneur et essayez d’envoyer un ping à l’interface réseau de l’hôte Docker, cela ne fonctionnera pas. Ce trafic est explicitement filtré par les modules du noyau eux-mêmes afin d’offrir une isolation et une sécurité supplémentaires.

Avec un conteneur attaché à un réseau macvlan, vous constaterez que s’il peut contacter sans problème d’autres systèmes sur votre réseau local, le conteneur ne pourra pas se connecter à votre hôte (et votre hôte ne pourra pas se connecter à votre conteneur). Il s’agit d’une limitation des interfaces macvlan : sans l’aide spéciale d’un commutateur réseau, votre hôte n’est pas en mesure d’envoyer des paquets à ses propres interfaces macvlan.

Donc il n’y a pas de solution ? Et bien si, et elle est décrite dans cet excellent article : Using Docker macvlan networks. Mais ce n’est pas simple, j’ai du relire l’article plusieurs fois avant de comprendre ! :wink:

Il s’agit donc de créer une première interface de type macvlan, mais en lui assignant un ‘range’ d’adresse IP qui sera utilisé par tous les containers du NAS dont vous voulez qu’ils communiquent avec le host. Chaque container aura donc sa propre adresse sur le LAN, ce qui implique d’utiliser un range en dehors de celui du serveur DHCP pour éviter des conflits. Dès lors, tous nos containers peuvent communiquer entre eux, mais ne peuvent toujours pas communiquer avec le host. On crée cette interface de cette façon (je reprends l’exemple de la page) :

docker network create -d macvlan -o parent=eno1 \
  --subnet 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  --ip-range 192.168.1.192/27 \
  --aux-address 'host=192.168.1.223' \
  mynet

ip-range indique que l’on va utiliser 32 adresses de 92.168.1.192 à 192.168.1.223 qui seront utilisées par les containers Docker.
aux-address réserve l’adresse 192.168.1.223 pour le host.

Puis on va créer sur le NAS un adaptateur macvlan qui sera en charge de communiquer avec les containers. Pour ce faire on lui assigne l’adresse précédemment réservée dans le “range macvlan” ci-dessus, et enfin on l’active :

ip link add mynet-shim link eno1 type macvlan mode bridge
ip addr add 192.168.1.223/32 dev mynet-shim
ip link set mynet-shim up

Il ne reste plus qu’à définir la route pour dire au host d’utiliser cette interface pour communiquer avec les adresses IP utilisées par les containers :

ip route add 192.168.1.192/27 dev mynet-shim

Le cas est d’ailleurs aussi décrit dans la documentation d’OMV : How to Create a VLAN (Pi-hole, Adguard, …).

Comme vous le voyez, cela nécessite quand même un peu de modifications, et mon petit souci cosmétique avec le dashboard de Homepage ne justifie pas de mettre tout cela en œuvre.

Conclusion

Voilà, j’ai désormais un serveur Pi-hole qui tourne en mode Docker, ce qui va lui permettre d’être mis à jour automatiquement, et me simplifier la mise à jour de Volumio sur le Raspberry, désormais dédié à ce dernier.

Et j’ai appris pas mal de choses sur le réseau des containers Docker, ce n’était pas inintéressant, loin de là. Peut-être m’en servirai-je un jour…

Calibre-Web

Tue, 22 Jul 2025 16:48:09 +0000

Puisque maintenant j’ai un beau NAS x64 qui tourne, je peux penser à installer de nouveaux containers. Et j’ai vu qu’il en existait un pour Calibre, le gestionnaire de livres numériques que j’utilise sur le PC.

L’idée est intéressante : rendre la bibliothèque disponible via internet. Le scénario typique, c’est que vous êtes en vacances loin de chez vous, et en manque de lecture : rien de plus simple alors que d’accéder à votre bibliothèque via internet, et de télécharger un livre de votre choix.

L’interface est propre et très fluide :

L’installation du container est simplissime, puis on verra comment copier les livres récupérés sur la liseuse.

La bibliothèque

La première chose à faire est bien sûr de déplacer l’ensemble de la bibliothèque (les livres au format .epub en ce qui me concerne) vers le NAS. J’ai donc créé un dossier au même niveau que ma bibliothèque Plex, soit dans le dossier OMV-DATA :

Puis j’y ai copié toute l’arborescence des mes livres, y compris le fichier metadata.db. Je vérifie ensuite avec Calibre (l’application sur le PC) que je retrouve bien tous mes livres à cet emplacement, puis j’efface l’ancien dossier que j’utilisais en local sur le PC.

Container Calibre-Web

Pour installer le container docker, je passe par Dockge, puisque je trouve cet outil si pratique. J’y crée le fichier compose.yaml comme suit :

services:
  calibre-web:
    image: lscr.io/linuxserver/calibre-web:latest
    container_name: calibre-web
    environment:
      - PUID=996
      - PGID=1000
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-uuid-xxxxx-yyyy-zzzz-7697ca5/AppData/Calibre/data:/config
      - /srv/dev-disk-by-uuid-xxxxx-yyyy-zzzz-7697ca5/OMV-DATA/Calibre:/books
    ports:
      - 8083:8083
    restart: unless-stopped
networks: {}

À adapter avec vos valeurs bien sûr. On retrouve le dossier OMV-DATA/Calibre précédemment créé, et un dossier AppData/Calibre. Le port 8083 proposé par défaut n’était pas utilisé, je le garde donc. Voilà, c’est hyper simple, il n’y a plus qu’à lancer le container. Reste à gérer l’accès depuis l’extérieur.

DNS, Proxy

Pour ce faire, je crée d’abord un nouvel enregistrement chez l’hébergeur de mon blog (Infomaniak) comme suit : puisque j’ai déjà créé un sous-domaine lors de la mise en place de mon serveur Nextcloud (j’avais alors créé un enregistrement de type A avec l’adresse IP de ma box, puis un enregistrement de type CNAME pour le service Nextcloud), je n’ai cette fois qu’à créer un nouvel enregistrement de type CNAME pour le service calibre, sous la forme : calibre.sous-domaine.domaine.

Reste à configurer Swag, le proxy-serveur, pour qu’il autorise cet accès : je procède la même façon que pour Nextcloud en créant un fichier calibre.subdomain.conf dans AppData/swag/nginx/proxy-confs/ :

$ cat calibre.subdomain.conf
server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name calibre.xxx.pled.fr;

location / {
    proxy_pass http://192.168.x.y:8083;
    }
}

Il faut également que Swag obtienne un certificat Letsencrypt pour que l’on puisse utiliser le HTTPS lorsque l’on ouvre la page d’accueil de Calibre-Web. Il suffit pour cela d’ajouter le sous-domaine à Nextcloud dans le fichier compose de la stack Nextcloud/Mariadb/Swag :

- SUBDOMAINS=nextcloud,calibre

Et de redémarrer le container. Voilà, tout fonctionne du premier coup, c’est parfait.

Utilisation Calibre-Web

Tout est hyper simple et intuitif. La fonction recherche est efficace, mais dépend forcément des informations saisies dans Calibre, comme les étiquettes, les séries, etc…

Une option sympa sur Calibre-Web est de pouvoir créer “une étagère”, où l’on peut sélectionner des livres qui nous intéressent sans pour autant vouloir les télécharger immédiatement. J’en ai créé une qui s’appelle “À lire” :

Il suffit ensuite de cliquer sur un livre pour soit le télécharger, soit l’ajouter à la bibliothèque :

Copier sur la liseuse Kobo

Quand je suis à domicile, je branche ma liseuse Kobo Aura HD sur le PC, et j’utilise Calibre pour y ajouter de nouveaux livres. Mais comment procéder si je suis en voyage ? (je n’emmène pas de PC dans mon sac à dos!).

Intégration Kobo

Il existe bien une option d’intégration de Kobo dans Calibre-Web, mais je ne l’ai pas testée. On peut trouver des infos sur cette page, mais c’est encore en phase de développement, et comme le dit le développeur, il est préférable d’attendre pour l’utiliser. Je vais suivre son conseil, mais c’est une très bonne nouvelle !

Connexion au smartphone

J’ai donc testé la solution la plus simple : utiliser mon smartphone. Je télécharge donc un livre à partir de mon instance Calibre-Web via le navigateur de mon tel, puis je connecte ma liseuse avec le câble habituel micro USB -> USB 2.0 auquel j’ajoute un adaptateur USB 2 -> USB C (qui était fourni avec mon Pixel). Le Koboreader apparaît dans le gestionnaire de fichiers, et je n’ai plus qu’à copier le fichier .epub téléchargé sur la liseuse.

C’est mieux de créer manuellement un dossier avec le nom de l’auteur s’il n’existe pas déjà, afin de garder le même type d’organisation (Calibre le faisant automatiquement). Puis y copier le fichier .epub dans ce répertoire.

Voilà, je peux partir en vacances ou en voyage l’esprit tranquille, je pourrais toujours récupérer des livres à distance et les ajouter à ma liseuse ! :cool:

Nouveau NAS : installation des containers

Wed, 02 Jul 2025 09:45:59 +0000

Suite de l’installation d’OMV sur le nouveau NAS, avec cette fois l’installation des containers Docker qui tournaient sur l’ancienne machine, à savoir Dockge, Plex, Homepage, Qbittorrent et Nextcloud.

Je ne vais pas reprendre ici chaque installation en détail, des articles existent déjà à ce sujet. D’autant que je vais tout simplement reprendre les fichiers compose.yaml que j’utilisais sur l’ancienne machine pour recréer les containers avec l’aide de Dockge. J’aurai juste quelques paramètres à adapter à chaque fois pour le nouveau NAS (chemin fichiers typiquement), ça devrait donc être assez facile.

Je me contenterai donc dans cet article des quelques problèmes rencontrés (ou changements effectués) sachant que dans l’ensemble tout s’est bien passé. Mais forcément, il arrive de tomber sur un problème jamais rencontré auparavant, on peut appeler cela les joies de l’informatique.

Au menu donc : un souci de token avec Plex pour Homepage, un problème réseau avec la WebUI de Qbittorrent, et même un changement de container pour d’autres raisons. Enfin, Nextcloud, le container que j’appréhendais le plus à réinstaller, n’a lui posé aucun problème : une autre joie de l’informatique sans doute ! :wink:

C’est parti !

OMV

J’en étais resté dans l’article précédent à l’installation des OMV-Extras et de “openmediavault-compose” depuis Système-Extensions. Il me restait à configurer les dossiers partagés dans le menu Stockage, puis à aller dans le menu Service-Compose-Paramètres, et y définir l’emplacement des “Compose Files” et “Data”, soit respectivement AppData et OMV-DATA dans mon cas (je reproduis ce que j’avais sur l’autre machine).

J’en profite aussi pour déplacer Docker vers le disque NVMe plutôt que de laisser sur le disque système :

Puis en bas de la page, je choisis “Reinstall Docker” et “Restart Docker”. Voilà, tout est prêt côté OMV.

Dockge

Je commence donc par Dockge, qui va permettre de créer tous les autres containers, cet outil est vraiment génial, et je me passe complètement de Portainer (proposé par OMV), que je n’ai d’ailleurs pas installé. Je suis la procédure d’installation de la page sur GiHub, et démarre le container. R.A.S.

Homepage

Puis j’installe mon premier container via Dockge, à savoir Homepage, très pratique pour se créer un “Dashboard”, ou un tableau de bord bien pratique pour gérer l’ensemble de mes services, qu’ils soient auto-hébergés ou chez mon fournisseur. Voilà ce que cela donnera à la fin :

Problème avec Plex et Homepage

Je commence ensuite par Plex. Le container s’installe sans souci particulier, et je copie les fichiers de ma bibliothèque média via une connexion NFS fait entre les deux machines. Tout se déroule sans encombre, et côté TV, je vois deux instances apparaître au lancement de la smart application, et je choisis la nouvelle instance. R.A.S.

Je vais en fait passer plus de temps à l’intégrer dans le dashboard Homepage, car il me faut trouver le “token” et je ne savais plus comment j’avais fait : sur cette page , il faut suivre la procédure pour " The device token". Ensuite, copier le token pour la valeur de key dans le fichier services.yaml que l’on vient de créer pour définir le serveur Plex :

- NAS-N150:
    - Docker:
      - Plex:
          icon: plex.png
          href: http://192.168.1.32:32400/
          description: Media Server - Séries, films, documentaires...
          server: my-docker
          container: plex_n150
          widget:
            type: plex
            url: http://192.168.1.32:32400
            key: 92xxxxxxxxxxxxxxxXj

Mais cela ne fonctionnait toujours pas, j’avais une API Error sur le dashboard d’Homepage :

Le problème venait de la ligne server: my-docker (que j’avais copier/coller du précédent serveur) : c’est bien la valeur par défaut, mais il faut toutefois aller dans le fichier docker.yaml et dé-commenter les lignes correspondantes, ce qui n’est pas fait par défaut lors de l’installation de Homepage :

---
# For configuration options and examples, please see:
# https://gethomepage.dev/configs/docker/

# my-docker:
#   host: 127.0.0.1
#   port: 2375

 my-docker:
   socket: /var/run/docker.sock

Et l’accès via l’API au container Plex fonctionne enfin :

Problème avec Qbittorrent

Je reprends donc la même stack que j’utilisais (il s’agit d’une version de Qbittorrent avec OpenVPN d’intégré et compatible armv7l soit une architecture x32), et lance le container. Au premier démarrage, il me demande un fichier .ovpn comme je l’avais noté lors de ma première installation, pas de surprise. Je copie donc le fichier dans le dossier créé lors du premier démarrage ( AppData/Qbittorrent/openvpn), et je relance. Tout semble aller pour le mieux, et j’ai bien le message [info] Started qBittorrent daemon successfully...

Mais par contre impossible d’accéder à l’interface WebUI, pas de réponse… Et quand je regarde l’état des ports de mon NAS depuis le PC, je vois ceci :

$ nmap -sT 192.168.1.32
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-25 10:00 CEST
Nmap scan report for NAS-N150.lan (192.168.1.32)
Host is up (0.00021s latency).
Not shown: 991 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
..
8080/tcp filtered http-proxy
8090/tcp open  opsmessaging
..

Le port 8090 est celui que j’utilise pour l’interface d’OMV, il apparaît bien “open” et est parfaitement fonctionnel.
Le port 8080 est celui que j’ai défini pour la WebUI de Qbittorrent, et il apparaît " filtered".

J’essaie un autre port, avec le même résultat. Peut-être problème de pare-feu alors ? mais je vois dans les logs du container que les règles sont créées (sans trop creuser), et je me dis que ce problème va être compliqué à résoudre, je sèche un peu. Je pose alors une question sur le forum d’OMV à tout hasard. Mais je continue de chercher une solution, et :idea: je me rends compte que la route définie dans le container est incomplète (heureusement que je peux la comparer avec celle du container tournant encore sur l’autre machine !). Voilà la route que je vois sur l’ancien NAS dont l’accès à la WebUI fonctionne :

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
...
192.168.1.0     172.27.0.1      255.255.255.0   UG    0      0        0 eth0
...

Alors que sur le nouveau NAS je n’ai aucune route concernant mon LAN (192.168.1.x), ce qui explique pourquoi mon interface est injoignable. Elle est pourtant bien définie dans le fichier compose.yaml sur les deux machines de manière identique ( LAN_NETWORK=192.168.1.0/24) mais pour une raison inconnue elle n’a pas été créée. Je l’ajoute donc à la main :

# ip route add 192.168.1.0/24 via 172.27.0.1 dev eth0

Bingo ! je peux enfin accéder à mon interface WebUI de QBittorrent ! :cool:

J’ai tout de même un dernier souci, impossible de m’identifier avec le mot de passe par défaut ! En fait, le mot de passe est regénéré à chaque démarrage tant que l’on ne s’est pas loggué une première fois pour le modifier via l’interface : avec tous mes essais de démarrage, ce n’est donc plus le même ! :sad: Il faut alors aller dans AppData/Qbittorrent/qBittorrent/data/logs et lire le fichier qbittorrent-daemon.log pour trouver sa dernière valeur :

root@NAS-N150:/srv/dev-disk-by-uuid-f39c071a-91e2-4184-971f-a722a7697ca5/AppData/Qbittorrent/qBittorrent/data/logs# cat qbittorrent-daemon.log
...
******** Information ********
To control qBittorrent, access the WebUI at: http://localhost:8080

The WebUI administrator username is: admin
The WebUI administrator password was not set. A temporary password is provided for this session: uw6bJP8kR
You should set your own password in program preferences.

Voilà, mon interface WebUI de Qbittorrent fonctionne enfin ! Tout content, je renseigne la question posée sur le forum OMV avec la solution à mon problème. Quelqu’un avait d’ailleurs répondu à ma question initiale en me demandant ma config.

Après avoir vu ma solution, cette même personne me conseille quand même de vérifier le réseau utilisé par QB, et que ce soit bien celui de mon VPN. Je lui répond que vu les logs, et le fait que j’ai sélectionné l’interface tun0 dans la WebUI de QB, ça doit être bon. Il me donne alors une autre méthode de vérification très pratique.

Tester l’adresse réseau utilisée par qBittorrent

Il suffit d’aller sur ce site de TorGuard : le test est assez malin, puisqu’il s’agit de charger un fichier torrent sur lequel ils sont également connectés, et vont alors pouvoir vérifier l’adresse IP utilisée par mon client.

Je fais donc un click droit sur le bouton “Download Now” et je copie le lien. Puis je passe sur la WebUI de QB et je fais “Fichier-Ajouter un lien torrent”, et je colle le lien précédemment copié. Je vois alors le torrent apparaître :

Après quelques secondes, il suffit de revenir sur la page d’origine de TorGuard, et l’on voit l’adresse IP utilisée par notre client Qbittorrent :

Un simple whois dans un terminal de cette adresse me confirmera que c’est une adresse de mon fournisseur de VPN.

Nouveau container qBittorrent

Mais la personne du forum OMV me conseille également d’utiliser un autre container Qbittorrent-OpenVPN, car le mien date un peu : je vois dans les logs que je suis en v4.6.7. Le container qu’il me conseille utilise la v5.1.1 (comme on peut le voir sur le screenshot ci-dessus, pris avec ce nouveau container).

En fait, j’étais resté avec ce container car c’était l’un des seuls incluant OpenVPN ET supportant l’architecture armlv7 x32, ce qui n’était pas évident à trouver. C’est d’ailleurs la raison pour laquelle j’installe ce nouveau NAS.

J’arrête donc mon container QB, adapte les paramètres du nouveau compose.yaml avec mes valeurs, et le lance : même chose qu’avec l’autre container, il faut copier le fichier du fournisseur de VPN dans le répertoire créé après le premier démarrage. Pour le reste, tout fonctionne immédiatement et je peux me logguer via la WebUI sans problème.

Finalement ce problème d’accès à la WebUI a été positif, puisque j’ai maintenant un container plus à jour, et appris une méthode intéressante pour tester l’IP utilisée par le client Qbittorrent.

La WebUI est plus récente : elle affiche dans le bas de la fenêtre l’adresse IP externe utilisée. J’en profite aussi pour activer une option évitant d’avoir saisir le mot de passe à partir de mon PC :

Installation Nextcloud

Ce que j’imaginais le plus difficile s’est finalement plutôt très bien passé. Il faut par contre tout définir correctement au niveau réseau avant de lancer le container :

au niveau d’internet, via mon fournisseur d’accès, pour définir le sous-domaine DNS que j’ai défini.
au niveau de la box internet, pour bien rediriger les port 80 et 443 sur la bonne machine.
Dans les fichiers de configuration Nextcloud et Swag, pour bien obtenir les certificats LetsEncrypt.

Sinon, je précise tout de même que l’on ne peut accéder à l’interface Web de Nextcloud (pour la phase “web-based” installation de Nextcloud) via l’adresse IP locale (sinon on arrive sur la page de swag) :

Il faut absolument utiliser le nom de domaine que l’on a défini dans le fichier compose.yaml. En même temps, c’est le rôle de Swag de protéger l’accès du serveur, donc rien de vraiment surprenant en y réfléchissant !

Après la web-install de Nextcloud (on ne peut le faire avant), je modifie le fichier /srv/dev-disk-by-uuid-f39c071a-91e2-4184-971f-a722a7697ca5/AppData/Nextcloud/config/www/nextcloud/config/config.php de Nextcloud comme je l’avais fait sur l’ancienne machine :

  'trusted_proxies' =>
  array (
    0 => '127.21.0.0/16',
  ),
  'trusted_domains' =>
  array (
    0 => '192.168.1.32:443',
    1 => 'nextcloud.xxxx.yyy.fr',
  ),

J’ajoute la ligne avec l’adresse IP dans la section “trusted-domains” mais cela ne résout pas le pb swag rencontré plus haut comme je le pensais : cette ligne ne sert donc peut-être à rien.
Et j’ajoute la partie “trusted_proxies” qui n’existe pas par défaut, après avoir vérifié l’adresse utilisée par le container (accès au terminal via Dockge) :

Ce n’est pas obligatoire, mais cela génère un avertissement dans Nextcloud-Paramètres d’administration, dans les Avertissements de sécurité & configuration (voir cet article).

Conclusion

Finalement, tout a été assez facile. C’est évidemment très pratique d’avoir encore la machine précédente qui fonctionne si l’on a besoin de comparer des choses. Grâce à ma question sur le forum d’OMV, j’ai même un container QB incluant OpenVPN plus récent et activement mis à jour.

Mes containers sont désormais tous à jour avec des versions x64 supportées, ce qui n’était plus le cas depuis un bout de temps avec l’architecture x32.

Ce nouveau NAS est beaucoup plus puissant et rapide, je suis curieux de voir si j’aurai encore des problèmes à visionner certaines vidéos comme je l’avais sur l’ancien : notamment le “bit rate” qui semblait poser problème à partir d’un certain seuil. Ce ne devrait plus être le cas désormais…

Voilà, il ne me reste qu’à voir quels nouveaux containers je vais pouvoir installer maintenant que mon serveur est en x64 : sans doute pi-hole qui me permettra de dédier mon raspberry à Volumio et m’évitera d’avoir à bidouiller l’image système pour faire cohabiter les deux… et peut-être Calibre, l’idée de disposer de ses e-books à distance me plaît pas mal… et peut-être d’autres puisque je ne suis limité par un hardware dépassé !

Beelink Me mini, mon nouveau NAS

Mon, 23 Jun 2025 09:56:14 +0000

Ça y est, j’ai craqué pour un nouveau NAS avec ce Beelink Me mini qui me semble bien prometteur, et qui coche toutes les cases demandées, et même plus.

Mon NAS actuel, un Odroid-HC2, avec son architecture x32 (plus de containers docker disponibles), devenait problématique à maintenir à jour, il était temps de le remplacer.

En premier lieu, je souhaitais donc un processeur de la génération N100 d’Intel pour sa faible consommation (TDP 6W) alliée à de bonnes performances (architecture Alder Lake) ainsi que la capacité à décoder les formats vidéos (techno QuickSync pour le décodage hardware).

Et la deuxième chose que je souhaitais, c’était du stockage sous forme de NVMe SSD pour le gain de place. Quelque chose de pas vraiment nécessaire pour mon usage, un stockage en SSD SATA aurait été largement suffisant, mais le côté mini-machine me plaisait pas mal.

Avec ce Beelink Me mini, j’ai donc :

un processeur N150 (arch. Twin Lake), soit la toute dernière génération.
12 Go de RAM (soudé, impossible d’avoir plus).
64 Go de stockage de base en eMMC, typiquement pour l’OS.
6 ports M.2 compatibles du 2230 au 2280 NVMe représentant 24 To de stockage potentiel !
2 ports Ethernet de 2.5 Gbps.

Belle petite machine tout de même ! :cool: Ce modèle est actuellement vendu sur AMZ au prix de 409 €, incluant 1 NVMe de 2 To Micron Crucial. (On dirait que le prix a déjà augmenté : je le vois désormais 489 € ?). Il reste semble-t-il la possibilité de le commander directement sur le site constructeur, voir cet article sur le site minimachines).

Voyons la bête d’un peu plus près, ainsi que l’installation d’OpenMediaVault pour commencer à exploiter cette belle machine.

Recherche du NAS

Avec les pré-requis que j’avais défini, j’ai commencé à faire des recherches, et j’avais bien repéré ce modèle Beelink, mais il n’était pas encore disponible. Je m’étais alors rabattu vers un mini PC de marque CWWK, qui offre 4 slots NVMe, et qui me revenait à 374 € avec 16 Go de RAM, 1 SSD de 128 Go pour l’OS, et un autre de 2 To pour les data.

À noter qu’avec ce type de matériel, on est obligé de sacrifier un NVMe pour le système… Hélas (ou plutôt tant mieux), au moment de commander sur AMZ, un beau message d’erreur s’affichait :

Je les ai contacté sans vraiment obtenir de réponse satisfaisante (une vague vérification serait en cours par Amazon auprès de ses revendeurs chinois), mais c’est peut-être bien lié aux taxes que Trump veut imposer… Il restait la solution AliExpress, mais j’ai un peu de mal à leur faire confiance en cas de problème : j’ai vu des prix pour des NVMe SSD de 2 To irréalistes, peu crédibles et cela ne donne pas confiance en la plateforme. Amazon, on peut critiquer, mais le service client est au top.

Bref, j’ai du me remettre à chercher un autre modèle, et le temps passant (il faut toujours prendre son temps), j’ai soudain vu que le Beelink Me mini était enfin disponible ! J’ai vite passé la commande.

Beelink Me mini

Le premier avantage de cette machine, c’est ce stockage eMMC de 64 Go qui permet d’y installer le système de son choix (même si la machine est vendue avec Windows 11 est préinstallé sur la barette NVMe de 2 To). Cela permet de dédier les 6 emplacements NVMe au stockage, de monter des configs RAID, etc…

Ensuite, la conception a l’air sérieuse, avec une structure en aluminium pour la dissipation calorifique (les NVMe chauffent pas mal). Lors de mes recherches, j’ai vu pas mal de modèles tout en plastique, qui posent question sur ce sujet. La conception avec le positionnement en vertical des disques NVMe est aussi très bien pensée je trouve.

Bref, on a là une belle machine, totalement silencieuse, qui pourrait d’ailleurs très bien fonctionner comme un mini PC pour un usage de bureautique : en plus, le design est soigné et le coffret très esthétique.

Sauvegarde image Windows 11

La machine est livrée avec Windows 11 préinstallé sur le disque NVMe de 2 To. J’ai donc démarré sur une clef USB Clonezilla (enfin sur ma clef Ventoy), et fait une image de ce disque (4 partitions), au cas où je voudrais l’utiliser (il y a une licence MS). L’ensemble de l’image fait 11,1 Go, il faut donc prévoir où la sauvegarder avec Clonezilla. Heureusement que j’ai mis Ventoy sur ma nouvelle clef SSD de 1 To :cool:

Je branche un écran, un clavier USB et ma clef Ventoy, rentre donc dans le BIOS, modifie l’ordre de boot, et voilà c’est parti ! Et je sauvegarde l’image du disque que me génère Clonezilla.

TrueNAS ou OMV ?

Après, je me suis posé la question d’installer soit TrueNAS (dont on entend beaucoup parler) ou bien de continuer avec OpenMediaVault que je connais déjà. Après quelques lectures, j’ai choisi de rester avec OMV car il reste moins gourmand en ressource mémoire.

Car s’il y a bien un TrueNAS “Scale” basé sur Debian, le pré-requis mémoire est de 8 Go minimum, et même 16 Go de recommandé. C’est semble-t-il lié au système de fichier ZFS, adapté aux NAS pour sa performance, ses capacités de configurations RAID, les snapshots de disques, etc… Or mon utilisation n’est pas celle d’un NAS très sollicité sur son système de fichiers. Je n’ai pas encore prévu de faire du RAID d’ailleurs, on verra ça plus tard, pour l’instant, de simples sauvegardes de ce qu’il serait gênant de perdre me suffit.

Sur ce NAS, il y a 12 Go de RAM soudée, et donc sans possibilité de changement. Donc TrueNAS aurait fonctionné, mais quand je compare avec OMV qui demande 1 Go mini et 8 Go recommandé, vu mes besoins, il n’y a pas photo.

Installation OMV

Je redémarre donc sur une clef OMV 7.4 et procède à l’installation sur l’eMMC de 64 GB. L’installation d’OMV se fait sans problème, je fais une mise à jour et je redémarre. Pour cela, j’ai suivi la doc officielle, c’est très simple.

Après la phase installation proprement dite, je peux dès lors débrancher l’écran et y accéder via l’interface Web (ou par SSH quand nécessaire). J’utilise d’ailleurs cette dernière en root pour la création d’un user “pascal” avec ajout groupe sudo + _ssh. Ceci afin d’éviter le login en root, toujours déconseillé…

# adduser pascal
# usermod -aG sudo pascal
# usermod -aG _ssh pascal

Puis côté PC, je copie la clef SSH avec ssh-copy-id pour le user pascal pour pouvoir me logguer sur le NAS sans avoir à taper le mot de passe à chaque fois.

$ ssh-keygen # pour identifier mon fichier de clefs
$ ssh-copy-id -i /home/pascal/.ssh/id_ed25519 pascal@192.168.1.XX

Voilà, enfin je crée un alias sshn150 et voilà l’accès ssh du PC vers le NAS prêt à l’emploi.

Pour la partie “Basic OMV configuration”, j’installe bien sûr les OMV-Extras comme indiqué via SSH :

# wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Puis j’active “Docker repo” dans menu Système - OMV-Extras. J’installe aussi “openmediavault-compose” depuis Système-Extensions.

Côté disque, j’utilise bien sûr le disque NVMe de 2 To : j’efface le contenu, puis je le formatte en NTFS puis configure le Mount.

Voilà, cette première étape est achevée, le système est prêt à être utilisé. Ce sera l’objet de futurs articles, je devrais commencer par installer un container Plex, et pouvoir tester si certaines vidéos que je ne pouvais décoder avec mon odroid-hc2 passent désormais sans problème ni lag…

Réinstallation d'OMV7 et Docker après perte du serveur

Tue, 18 Feb 2025 17:05:42 +0000

Mauvaise surprise la semaine dernière : mon serveur OMV ne démarre plus. Impossible d’y accéder donc, même après un arrêt électrique. Le boot du système apparemment ne va pas très loin, je n’entends même pas le HD se mettre en route. Pas de réseau donc, et aucun moyen d’intervenir pour investiguer le problème. :sad:

J’ai vérifié l’intégrité (scandisk) de la sdcard sur le PC : aucune erreur de détectée, réessayé un démarrage, rien à faire. À ce stade, j’étais un peu en panne d’inspiration pour dépanner le système… Je ne sais pas ce qui s’est passé, j’avais reçu un mail me demandant de redémarrer après une mise à jour : manifestement celle-ci s’est mal passée… sans doute aurais-je du regarder les logs avant de lancer ce redémarrage, mais bon, c’est plutôt courant comme opération, alors…

Ma dernière sauvegarde datait d’environ un an, j’étais encore en OMV5 à l’époque ! j’ai pu démarre dessus, et pensé à refaire la mise à jour vers OMV6 puis OMV7, mais j’ai eu de beaux messages d’erreur que je n’ai pas cherché à comprendre (OMV5 c’est vieux maintenant), et je suis vite parti sur l’idée de refaire une installation tout fraîche d’OMV7.

L’Odroid-HC2 est plutôt bien conçu : une sdcard pour le système (soit Armbian+OMV) et un bon vieux HD 3,5" que l’on vient connecter directement sur la carte. Toutes mes données, y compris Docker, sont installées sur le HD, je n’ai donc qu’à installer OMV7 et recréer les liens vers le HD.

Tout s’est passé assez facilement, revenir à un système opérationnel a finalement été assez rapide et sans aucune perte de données. :cool:

Voyons voir tout ça : je ne reprends pas une installation d’OMV en détail (déjà fait), mais les seulement étapes importantes de cette réinstallation.

Le système

Malgré que mon Odroid-HC2 se fasse un peu vieux maintenant, et surtout soit une machine x32, j’ai pu retrouver une image armbian disponible sur cette page : c’est la même image que pour le modèle XU4.

Il faut télécharger l’image, la dézipper, puis copier l’image sur la sd-card, puis on démarre dessus. Ensuite, on se connecte en SSH avec le compte root(mdp : 1234), rien de très compliqué. On peut ensuite aller optimiser un peu la configuration pour les modèles HC (1 ou 2) en lançant l’outil armbian-config, choisir Système puis Kernel, et enfin “Select Odroid board configuration” où l’on pourra sélectionne la série “HC” :

OMV 7

Ensuite on installe OMV7 en suivant la doc , ce qui se résume aux commandes suivantes :

# apt update
# apt upgrade
# wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | bash

Cela prend un peu de temps (30 min), puis le système redémarre. Voilà, OMV est installé, on peut se logguer via l’interface web.

Quand on a déjà installé OMV une fois, le reste est assez simple, sinon on suit la doc. En gros, on change, le port 80 de l’interface, puis on va dans Stockage créer les dossiers partagés pour les services Docker. Comme tout est déjà existant sur mon HD, il suffit de recréer les liens.

La seule différence que j’ai noté c’est le chemin absolu vers mes dossiers sur le HD n’est plus le même : je suis passé de :
/srv/dev-disk-by-label-DATA
à
/srv/dev-disk-by-uuid-ecc74bd0-fd45-4e9b-a223-60dbfe940601

Je vais devoir modifier mes fichiers docker compose en conséquence (voir ci-dessous).

Passons à l’installation de Docker, comme indiqué dans la doc. J’installe d’abord l’extension openmediavault-compose à partir du menu Système - Extensions :

Ensuite je vais dans Services - Compose - Parameters : il s’agit essentiellement de définir le dossier AppData comme défini dans les dossiers partagés précédemment :

J’en profite aussi pour déplacer Docker sur le HD :

Et je fais une réinstallation afin d’être sûr que tout est à jour grâce au bouton en bas de page :

Dockge

Maintenant que mon système OMV est opérationnel, il ne me reste plus qu’à réinstaller mes containers Docker. J’utilise depuis quelque temps Dockge pour les gérer, c’est vraiment très bien fait et beaucoup plus efficace que les interfaces proposées par OMV. J’installe donc ce container en premier, en suivant l’article que j’avais fait : /dockge-gestion-des-container-docker/

Une fois démarré, Docke voit bien mes containers Dockers (Nextcloud, Plex, Qbittorrent) mais affiche “This stack is not managed by Dockge”.

C’est normal, je dois les redéfinir comme expliqué dans l’article. Heureusement, j’ai gardé les fichiers compose.yaml de chacun de mes services, je modifie donc toutes les références à /srv/dev-disk-by-label-DATA et je les remplace par /srv/dev-disk-by-uuid-ecc74bd0-fd45-4e9b-a223-60dbfe940601.

Tout cela prend très peu de temps à remettre en place, je redémarre tous mes services, et voilà ! tout fonctionne comme auparavant ! :cool:

Swag Dashboard

J’en ai profité pour réinstaller Swag Dashboard en suivant cet article. C’est extrêmement simple, je modifie la stack de Nextcloud, section swag, en y ajoutant 2 lignes :
- DOCKER_MODS=linuxserver/mods:swag-dashboard dans environment
- 81:81dans ports.
Ce qui donne pour la partie Swag :

swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=995
      - PGID=100
      - TZ=Europe/Paris
      - URL=xxx.pled.fr
      - SUBDOMAINS=nextcloud
      - DOCKER_MODS=linuxserver/mods:swag-dashboard
      - VALIDATION=http
      - EMAIL=xxx@pled.fr
    volumes:
      - /srv/dev-disk-by-uuid-ecc74bd0-fd45-4e9b-a223-60dbfe940601/AppData/swag:/config
    ports:
      - 443:443
      - 80:80
      - 81:81
    restart: unless-stopped

Puis grâce à Dockge un arrêt suivi d’un redémarrage suffit à prendre en compte le nouveau fichier et créer un nouveau container.

J’ai désormais un dashboard pour Swag, ce qui n’est pas sans intérêt :

Conclusion

Tout remettre en état s’est finalement révélé assez simple et rapide. L’installation de l’image armbian et d’OMV7 est tout de même simplissime. L’expérience de la première installation s’est révélée utile pour le paramétrage d’OMV, et l’utilisation de Dockge simplifie beaucoup la gestion des containers Docker. Tout cela est globalement positif.

Évidemment, si j’avais eu une sauvegarde récente, tout aurait été encore plus simple. Lorsque je suis passé à OMV7 (en mars 2024), j’aurais du faire une sauvegarde de la sdcard, j’ai vraiment m… sur ce coup là. D’ailleurs, j’en fais une immédiatement après cette installation, avec l’outil Disques de Gnome :

Si j’avais perdu le HD, la situation serait sans doute plus compliquée, mais gérable avec la sauvegarde de mes containers plus celles de la médiathèque Plex avec mes sauvegardes rsync.

J’ai tout de même vu que je pourrais ajouter à ces sauvegardes rsync un ou deux dossiers comme le home de mon utilisateur sur mon NAS, où traînent quelques scripts utiles, ou encore les dossiers des fichiers compose.yaml de Dockge.

Mais bon, globalement, une bonne expérience qui se termine bien.

Un dernier petit screenshot :

Streaming de sa propre musique avec l'application Nextcloud Music

Mon, 05 Aug 2024 15:33:58 +0000

Tout a commencé par la lecture de cet article : Je quitte Spotify pour mon propre cloud musical autohébergé ! L’auteur y explique comment il est passé de Spotify à une solution auto-hébergée avec Nextcloud et son application Music.

Il y soulève d’ailleurs plusieurs points intéressants à propos de l’usage de Spotify : d’abord l’absence de certains artistes, ou de leur disparition soudaine pour d’obscures raisons contractuelles, en d’autres termes l’absence de contrôle sur la musique que l’on souhaite écouter. Mais aussi un autre point très intéressant : utilisateur des “Daily Mix” (des playlists générées chaque jour en fonction de vos goûts), il s’est vite vu s’auto-censurer en n’allant pas écouter une musique dont il avait entendu parler de peur que l’algorithme ne vienne altérer ses “Daily Mix” !

On voit par ces deux exemples les limites de ce que propose Spotify ou Deezer : on perd le contrôle, jusqu’à s’auto-censurer à cause d’algorithmes qui font des choix à notre place. C’est d’ailleurs de plus en plus vrai, avec l’AI qui arrive partout, yc dans les navigateurs, et que je m’empresserai de désactiver quand le pourrai, vu que cela n’apporte rien à part de la confusion. Ce n’est pour moi que le dernier élément marketing des GAFAMs pour vendre leur tambouille du rêve et collecter encore plus de données.

Mais revenons à l’article : je me suis dit pourquoi ne pas “streamer” ma propre musique puisque j’ai mon instance Nextcloud qui tourne sur mon NAS OMV et qui est accessible depuis internet grâce à swag/nginx, le Proxy Server installé ? (voir cet article pour la configuration de mon serveur Nextcloud sur le NAS OpenMediaVault). Le seul souci que je voyais finalement était que ma bibliothèque musicale est assez importante (+14 000 titres) et que je ne voulais surtout pas avoir à dupliquer sur le NAS.

Concernant l’application de lecture côté Android (puisqu’il s’agit de streamer sa propre musique en dehors de chez soi), j’ai utilisé celle mentionnée dans l’article de Flozz, qui m’avait l’air très bien (totalement open-source) puisque Nextcloud Music accepte les clients utilisant l’ API Ampache. C’est là que je suis tombé sur un sérieux problème, car il était impossible de me connecter à mon instance Nextcloud Music. J’ai mis du temps à identifier l’origine du problème, mais avec de l’aide côté dev Ampache et Nextcloud, nous avons finis par identifier un problème de configuration sur le proxy serveur nginx.

J’ai également du mettre à jour mon instance Nextcloud, et là je suis tombé sur un nouveau problème lors de l’upgrade. Enfin un problème d’affichage de pochettes m’a embêté quelque temps avant de me rendre compte que cela provenait de la configuration réseau sur mon LAN.

Cela n’a donc pas été sans peine, mais j’ai finalement réussi à tout mettre en ordre de marche. Je vais essayer de reprendre ici toutes les étapes et les problèmes rencontrés.

C’est parti !

Bibliothèque musicale

Ma bibliothèque musicale est en premier lieu sur mon PC, mais celui-ci n’est pas allumé en permanence. Pour l’utiliser avec Volumio sur mon Raspberry, je la synchronise donc sur un disque USB du Raspberry via un script rsync et un accès SSH (voir cet article). Le raspberry est lui tout le temps allumé, et la connexion SSH était donc déjà toute configurée. :cool:

Comme je ne voulais exposer toute ma bibliothèque, je l’ai vite réorganisée, en créant deux dossiers à la base de l’arborescence : Intranet (pour la maison uniquement) et Internet (accessible de l’extérieur). Puis j’ai déplacé l’essentiel dans Intranet, et disons toutes mes playlists dans Internet (ce que j’écoute le plus facilement), qui représente tout de même 3 400 titres. Ce devrait être suffisant pour streamer hors de la maison…

Un mot sur les playlists

Sur mon PC, les playlists (avec Rhythmbox) sont en fait des titres réunis dans un même dossier. Or l’API Ampache n’offre pas de fonction de type “vue dossier”. Elle affiche par contre les Playlists que Nextcloud Music permet de créer, et NC Music offre une vue dossier : voir en fin d’article comment gérer cela, c’est très simple.

Nextcloud External Storage Support

Nextcloud fournit une application “External Storage support” qui va me permettre de configurer un accès via SFTP à ma bibliothèque musicale sur le disque USB de Volumio. Il suffit donc d’installer cette application, de créer d’abord un dossier dans Nextcloud Fichiers qui servira de point de montage (ici MyMusic), puis d’aller dans “Paramètres d’administration - Administration - Stockage externe”, et d’y donner les informations de connexion à la machine Volumio :

Il faut ensuite aller dans l’application Music, de définir le chemin de votre collection de musique, puis de lancer le scan… qui peut prendre plus ou moins de temps ! On peut d’ailleurs exclure certains dossiers du scan si on le souhaite à ce moment (autre approche).

Cette partie a été vraiment très simple à régler, et j’ai pu tout de suite tester le lecteur dans le navigateur. Tout fonctionnait parfaitement.

Reste tout de même à configurer l’accès à partir du client Ampache : pour ce faire, aller sur la page Nextcloud Music, choisir Settings en bas à gauche, vous y trouverez l’URL qu’il faudra utiliser côté client, ainsi que la possibilité de générer le mot de passe à utiliser pour l’utilisateur Nextcloud :

Notez bien le mot de passe qui est fourni, car une fois la boîte fermée, il n’apparaîtra plus nulle part. On ne peut que l’effacer et en créer un nouveau.

Voilà, côté Nexcloud, tout est prêt. Passons maintenant au client Ampache côté Android.

Power Ampache 2

Power Ampache 2, disponible sur F-Droid, est une application totalement open source, et comme j’ai eu l’occasion d’aborder le sujet avec le développeur, elle ne comporte aucun tracking : en effet, alors que j’investiguais le problème des pochettes (voir plus bas), j’avais noté que Exodus Privacy avait repéré un tracker dans l’application :

Et voilà la réponse du développeur :

All the requests Power Ampache 2 makes are directed to the ampache server you specified at login. I absolutely do not make any third party or tracking requests. All the libraries used are open source and do not make any network request on their own.

Even the “(1) pisteur” you see in your report, that’s for email crash report, and you can just refuse to send the email if a crash happens, if you want.

Tout est parfait donc, et l’application est très esthétique je trouve :

Mais il faut d’abord se connecter au serveur, et c’est là que les ennuis ont commencé, il m’était impossible de me connecter :

J’ai commencé à regarder les logs que fourni l’application dans les paramètres (bonne conception) :

2024-06-23 15:51:54
retrofit2.HttpException: HTTP 404 { "exception" : "java.security.cert.CertPathValidatorException: Trust anchor for certification path not found." }
    at retrofit2.KotlinExtensions$await$2$2.onResponse(KotlinExtensions.kt:53)
    at retrofit2.OkHttpCall$1.onResponse(OkHttpCall.java:161)
    at okhttp3.internal.connection.RealCall$AsyncCall.run(RealCall.kt:535)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:644)
    at java.lang.Thread.run(Thread.java:1012)

authorize() - cannot load data HttpException {"code":404,"message":"{ \"exception\" : \"java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.\" }","detailMessage":"HTTP 404 { \"exception\" : \"java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.\" }","stackTrace":[],"suppressedExceptions":[]}

Le message semblait pointer un problème de certification (“Trust anchor for certification…”), or mon certificat était bien valide, puisque je pouvais accéder en HTTPS via le navigateur. Je ne comprenais donc pas le problème. En regardant les logs du serveur nginx, je pouvais voir quelque chose de ce genre :

92.xxx.yyy.zzz - - [23/Jun/2024:18:11:56 +0200] "GET /apps/music/ampache/server/json.server.php?action=handshake&auth=0dc8eab854xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx289e9ded5423&user=xxxxxxx×tamp=1719159117 HTTP/2.0" 404 146 "-" "PowerAmpache2-1.00-60-fdroid"

Erreur 404(not found), celle-là tout le monde la connaît ! Mais cela ne m’aidait guère… Je me suis alors tourné vers le dev Ampache pour leur demander de l’aide. Le dev a vite pensé à un problème avec le proxy et les “Nextcloud rewrites” (on verra plus tard que c’était bien le problème). Il ajoutait que cela pouvait être aussi un problème avec la version de Nextcloud ou celle de Nextcloud Music…

Mise à jour serveur Nextcloud

Je me suis donc d’abord tourné vers mon serveur Nextcloud, qui n’était effectivement pas à jour : je devais être à la version 25 alors que la 29 venait de sortir. Il était temps de me mettre à jour.

J’ai donc dans un premier temps fait les mises à jour via l’interface de Nextcloud, passant de la 25 à la 26, puis 26 -> 27 -> 28 -> jusqu’à la dernière version disponible, soit la 29.0.3. Tout s’est très bien passé à ce niveau, c’est vraiment la meilleure façon de mettre à jour Nextcloud dans son container Docker. Les scripts de Nextcloud sont vraiment bien faits, ils font même une sauvegarde de la version de départ au cas où un problème surviendrait.

En écrivant cet article, j’ai vérifié si une nouvelle version était dispo, et c’était le cas avec la 29.0.4. J’ai donc en toute confiance lancé la mise à jour, et bien sûr, comme je venais d’écrire que les scripts étaient super bien faits, cette fois ça a planté :

Et là, j’étais bloqué, le bouton “Retry update” ne donnait rien. J’ai fini par recharger la page, et j’ai alors eu droit à ce message et cette commande un peu rebutante :

C’est un peu obscur à première vue, mais en fait assez simple à gérer : d’abord se connecter en SSH sur la machine, et coller la commande indiquée.

pascal@odroidhc2:~$ php -r '$password = trim(shell_exec("openssl rand -base64 48"));if(strlen($password) === 64) {$hash = password_hash($password, PASSWORD_DEFAULT) . "\n"; echo "Insert as \"updater.secret\": ".$hash; echo "The plaintext value is: ".$password."\n";}else{echo "Could not execute OpenSSL.\n";};'
Insert as "updater.secret": $2y$10$5q.oWf0b.bBlGxxxxxx
The plaintext value is: MUk9s3iBnUFjip0mptqSxxxxxx
pascal@odroidhc2:~$

Il suffit lors d’ajouter la valeur de “updater.secret” à la fin du fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php :

  'dbpassword' => 'keepsecret',
  'installed' => true,
  'theme' => '',
  'loglevel' => 0,
  'maintenance' => false,
  'maintenance_window_start' => 1,
  'has_rebuilt_cache' => true,
  'app_install_overwrite' =>
  array (
    0 => 'carnet',
  ),
  'updater.secret' => '$2y$10$5q.oWf0b.bBlGxxxxxxxxx'
);

Puis sur la page web de rentrer le mot de passe en “plain text value” et de cliquer sur le bouton “Login”. La mise à jour vous propose alors de reprendre où elle avait échouée, et se termine sans encombres.

NOTE : La ligne ajoutée précédemment au fichier config.php est automatiquement supprimée une fois utilisée ! Encore une bonne chose d’apprise avec Nextcloud ! :oops:

Une fois cette première phase terminée, on peut soit continuer via l’interface Web (une nouvelle page s’ouvre) pour démarrer la mise à jour proprement dit. On peut tout aussi bien ouvrir une boite de commande via Portainer ou Dockge (au passage un très bon outil pour gérer ses containers, j’en suis très content) pour lancer la mise à jour très simplement avec la commande occ upgrade :

J’ai ensuite pu installer l’application Music à la version 2.0.0 comme recommandé sur l’écran de connexion du client Power Ampache (voir plus haut).

Messages d’erreur (warnings)

Toujours dans Nextcloud, j’avais deux alertes (en rouge) dans la page “Vue d’ensemble” des paramètres d’administration que je me suis attaché à corriger, afin de partir d’une situation la plus propre possible :

Le premier message a été corrigé en modifiant le fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/nginx/site-confs/default.conf du serveur nginx (il suffit d’ajouter l’extension mjs pour le javascript) :

include mime.types;
types {
        text/javascript js mjs;
        application/wasm wasm;
      }

Pour la seconde erreur, c’était un peu plus compliqué. Mon fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php était configuré comme ceci concernant les " trusted_proxies" :

'trusted_proxies' =>
  array (
    0 => 'swag',
  ),

Depuis la console de l’instance Docker de Nextcloud, je pouvais voir son adresse IP et celle du proxy swag/nginx comme ceci :

root@0e47f46ce787:/# ip address
158: eth0@if159:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:1a:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.26.0.3/16 brd 172.26.255.255 scope global eth0
       valid_lft forever preferred_lft forever
root@0e47f46ce787:/#
root@0e47f46ce787:/# ping swag
PING swag (172.26.0.4): 56 data bytes 64 bytes from 172.26.0.4: seq=0 ttl=64 time=1.020 ms

Et dans la console Docker Swag, je pouvais aussi vérifier son adresse :

root@8077149332c5:/# ip addr
160: eth0@if161:  mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:1a:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.26.0.4/16 brd 172.26.255.255 scope global eth0
       valid_lft forever preferred_lft forever

Ce qui me permettait d’utiliser la notation CIDR suivante pour que Nextcloud soit content pour la déclaration de ses “trusted_proxies” :

'trusted_proxies' =>
  array (
    0 => '127.26.0.0/16',
  ),

Voilà, je suis désormais à jour côté serveur Nextcloud, et je n’ai plus aucune erreur critique (en rouge). Une bonne chose de faite finalement.

Il reste bien quelques messages, mais non critiques, comme de me signaler que j’utilise une version 32 bits de PHP et que je ferais mieux de passer à une version 64 bits ! Information dont je suis bien conscient, mais mon odroid-hc2 fonctionnant parfaitement, je le garderai tant que ce sera le cas ou que je me retrouverai coincé (j’ai déjà vu que mes containers Docker n’étaient plus disponibles, voir cet article).

Erreur 404

Mais hélas, il m’est toujours impossible de me connecter à partir du client Ampache, et toujours avec la même erreur. Je peux toutefois raisonnablement penser que côté Nextcloud, tout est bon.

Première solution

Je finis par trouver un ticket ouvert sur le Github de Music qui correspond à mon message d’erreur : Ampache api with nextcloud served by nginx gets 404 when following nextclou admin docs.

Apparemment, quand Nextcloud est utilisé avec nginx (pas de problème avec Apache), il ne manipule pas correctement les fichiers avec une extension .php, renvoyant l’erreur 404. Bon, je n’ai pas tout maîtrisé ici, mais la directive try_files pose problème. en la modifiant comme ci-dessous, je peux effectivement enfin me connecter avec le client Ampache.

--- nextcloud-old.conf  2021-05-05 01:02:35.871870022 +0200
+++ nextcloud.conf      2021-05-05 01:03:11.491904219 +0200
@@ -113,7 +113,7 @@
         fastcgi_split_path_info ^(.+?\.php)(/.*)$;
         set $path_info $fastcgi_path_info;

-        try_files $fastcgi_script_name =404;
+        try_files $fastcgi_script_name /index.php$fastcgi_script_name?$args;

         include fastcgi_params;
         fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Dans ma configuration, le fichier de configuration en question, celui de nginx, est /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/nginx/site-confs/default.conf. Il est préconfiguré pour être utilisé avec Nextcloud, puisque j’utilise une solution “clef en main” fournie par Linuxserver.io avec les 3 containers Docker requis : Nextcloud, Mariadb et Swag (Swag intègre nginx + fail2ban + Letsencrypt).

Sauf que la modifier de cette façon peut avoir un impact sur le fonctionnement global de Nextcloud. Et sur les conseils du dev Ampache, j’ai ajouté une nouvelle " location" dans le fichier de configuration de Nextcloud pour traiter spécifiquement les fichiers concernant ampache et de laisser le reste du code tel quel :

location ~ ^/apps/music/ampache/server/.*\.php$ {
     fastcgi_split_path_info ^(.+?\.php)(/.*)$;
     set $path_info $fastcgi_path_info;

     try_files $fastcgi_script_name /index.php$fastcgi_script_name?$args;

     include fastcgi_params;
     fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
     fastcgi_param PATH_INFO $path_info;
        fastcgi_param HTTPS on;

        fastcgi_param modHeadersAvailable true;         # Avoid sending the security headers twice
        fastcgi_param front_controller_active true;     # Enable pretty urls
        fastcgi_pass php-handler;

        fastcgi_intercept_errors on;
        fastcgi_request_buffering off;
    }

Le problème semble donc réglé ! :cool: Reste à signaler le problème à qui de droit.

La documentation Nextcloud

Pour faire les choses bien, et comme conseillé par un dev de Music, le meilleur endroit pour déclarer ce problème, c’est la doc de Nextcloud. En effet, cette dernière donne les infos pour configurer le serveur nginx sur cette page. Je crée donc un ticket ici pour signaler le problème et suggérer d’ajouter ce cas de figure dans la section Tips and tricks.

Quelques jours plus tard, une personne me répond qu’effectivement, l’API Ampache (exposée par l’application Music) possède des routes qui intègrent des fichiers .php. et que nginx gère cela différemment qu’Apache. Il me propose une autre solution, plus simple et qui évite de créer une “location” spécifique. En se basant sur ce document, on ajoute une règle qui devrait être présente pour bien gérer les fichiers .php de l’API Ampache.

La personne m’en propose une modifiée pour Ampache, mais ce sera finalement la ligne de rewrite de la documentation qui va se révéler la bonne. Elle est indiquée comme “required for legacy”, mais n’était pas présente dans le fichier que j’utilisais, et qui venait des containers nextcloud+mariadb+swag proposés ici.

    # Ensure this block, which passes PHP files to the PHP process, is above the blocks
    # which handle static assets (as seen below). If this block is not declared first,
    # then Nginx will encounter an infinite rewriting loop when it prepends `/index.php`
    # to the URI, resulting in a HTTP 500 error response.
    location ~ \.php(?:$|/) {
	    # Pascal - added for Nextcloud Music and Ampache client PHP (routes handling)
	    # Required for legacy support
	rewrite ^/(?!index|remote|public|cron|core\/ajax\/update|status|ocs\/v[12]|updater\/.+|ocs-provider\/.+|.+\/richdocumentscode(_arm64)?\/proxy) /index.php$request_uri;
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        set $path_info $fastcgi_path_info;

	try_files $fastcgi_script_name =404;

Cette fois tout est bon ? Euh… un autre problème va apparaître.

Pas de pochettes affichées

Dans la plupart des cas de ma bibliothèque musicale, chaque dossier correspond à un album, et contient en plus des morceaux un fichier image cover.jpg. représentant la pochette de l’album. C’est assez standard et fonctionne généralement sans problème particulier.

Si la connexion fonctionnait désormais :cool:, je n’ai pas les pochettes dans le cient Ampache, alors que je les ai dans le navigateur :

Sur ce coup là, je n’ai pas été très bon, car le problème venait de ma config, et j’aurais pu/du le trouver tout seul. J’ai d’abord sollicité le dev de Music, qui m’a vite répondu en m’expliquant comment cela fonctionnait et comment je pouvais tester. Par exemple, en utilisant une URL de ce type :

https://your_server_url/apps/music/ampache/server/json.server.php?action=stats&auth=5577f70e9eed2ba5d14a45dc5aac4328&limit=40&username=pascal&type=album&filter=random&offset=0

(en utilisant un token auth valide), je devais avoir une réponse avec une autre URL pour la clef art., qu’il me suffisait alors de tester : si j’obtenais la pochette, alors tout était bon côté Nextcloud Music.

Pour obtenir un token valide, il me suffisait de me connecter avec Ampache tout en affichant les logs de nginx. Exemple :

root@odroidhc2# cd /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/log/nginx#
root@odroidhc2# tail -f access.log
...
192.168.1.126 - - [30/Jul/2024:17:01:12 +0200] "GET /apps/music/ampache/server/json.server.php?action=stats&auth=d41a91089dcxxxxxxxxxxxx&limit=40&username=pascal&type=album&filter=newest&offset=0 HTTP/1.1" 200 3298 "-" "PowerAmpache2-1.00-62-fdroid"
...

Il me suffisait alors d’utiliser auth=d41a91089dcxxxxxxxxxxxx dans l’URL indiquée par le dev de Music pour pouvoir la tester. Et j’obtenais bien une autre URL “art” :

Et l’URL m’affichait bien la pochette ! Voilà, je laisse cette info ici car cela peut servir pour tester le fonctionnement de Nextcloud Music.

En fait le problème venait tout bêtement de ma config réseau. Lorsque j’avais mis en place mes containers Nextcloud-Mariadb-Swag, pour des conflits de ports entre Nextcloud et Swag, j’avais du rediriger le port 443 vers le 444 entre la box et le proxy :

Ce qui m’obligeait, quand j’étais à la maison, à définir le port 444 à la fin de l’URL pour accéder à mes services, et qui compliquait inutilement les choses. J’avais fait ça, je crois, parce que dans ma stack Nextcloud, je définissais le port 443, et que je faisais de même dans la stack Swag, j’avais alors un conflit de port au démarrage des containers et cela ne fonctionnait pas.

---
version: "2.1"
services:
  nextcloud:
...
    ports:
      - 443:443
...
  swag:
...
    ports:
      - 443:443
...

En fait la solution était toute simple : ne rien spécifier pour Nextcloud (supprimer la déclaration “ports”), le port https par défaut étant 443 et dès lors tout démarrait sans erreur et fonctionnait sur toute la chaîne sur le port 443 (j’ai bien sûr modifié le routeur de la box et aussi le fichier de configuration Nextcloud : /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php :

  'trusted_domains' =>
  array (
    0 => '192.168.1.30:443',
    1 => 'nextcloud.xxx.pled.fr',
  ),

Et me voilà de retour à une configuration plus standard et moins problématique.

Dès lors, Power Ampache 2 affichait bien mes pochettes (si tant est qu’elles étaient fournies par mes fichiers audio), et tout fonctionnait à merveille : je pouvais enfin “streamer” ma propre musique en allant me promener ! :cool:

Playlists

Reste à gérer mes playlists ! Comme je l’expliquais plus haut, elles viennent de Rhythmbox sur mon PC, et sont chacune dans un dossier spécifique qui contient tous les titres (pas de playlist dynamique réunissant X titres provenant de Y dossiers. Je n’utilise donc pas de fichier de type m3u par défaut. Même les playlists de Rhythmbox créées au fil des écoutes et contenant donc des chemins absolus vers différents dossiers, j’ai fini par les transformer en dossier “playlist” : cela duplique les-dits morceaux, mais cela simplifie largement le passage des playlists vers Volumio : en effet il est très facile via l’interface web de Volumio de sélectionner un dossier et de choisir “Ajouter à la playlist” puis d’en créer une nouvelle. De cette façon, j’ai pu recréer très facilement mes playlists de Rhythmbox.

Or, l’API Ampache, comme me l’a confirmé le développeur, ne propose pas de vue par dossier. Elle propose par contre les Playlists que l’on crée à partir de NC Music. Heureusement, NC Music permet non seulement de créer des Playlists, mais propose aussi une vue “Dossier” : il suffit donc de créer une nouvelle playlist, puis de passer en vue “Dossier”, et de faire un “glisser-déposer” du nom du dossier sur celui de la playlist, et le tour est joué ! :cool:

Par contre, si l’on souhaite avoir les pochettes dans cette configuration, il va falloir intégrer chacune d’entre elles dans le fichier .mp3 ou .ogg s’il ne la contient pas déjà. Dans ce cas, je l’ajoute avec Puddletag (mais ce ne sont pas éditeurs de tags qui manquent) :

Conclusion

Voilà, cela n’ a pas été de tout repos, mais finalement c’est assez simple, hormis les deux problèmes rencontrés :

l’un était du à l’absence d’une directive de rewrite dans le fichier de configuration du proxy serveur, pourtant marquée comme “required for legacy”. Un problème sans doute lié à la configuration par défaut proposée par le container Swag. Celui-là n’était pas simple à résoudre.
Le deuxième, celui des pochettes était du à ma configuration et j’aurais du y penser tout de suite. En fait, je testais tout à partir de mon LAN, ayant remis à plus tard son utilisation depuis l’extérieur en attendant que tout fonctionne : en l’utilisant hors de la maison, j’aurais vu les pochettes arriver, et j’aurais rapidement fait le lien ! Finalement, cela m’a forcé à corriger ce problème de config avec le port 443 et les deux containers pointant dessus, ce qui est une bonne chose, cela m’avait déjà posé des contraintes avec d’autres applications (Joplin).

En dehors de ces deux points, il m’a fallu mettre à jour mon instance Nextcloud, afin de bénéficier de Music 2.0.0. L’occasion de vérifier que la mise à jour via leur interface est plutôt fiable et robuste (mais un problème peut toujours survenir !). Tout est parfaitement détaillé sur cette page (bravo à la qualité de la documentation Nextcloud).

Enfin, pour rappel, voilà les tickets Github que j’ai créé soit pour demander de l’aide, soit pour signaler ce que je croyais être un bug, ou encore pour signaler qu’une mise à jour de la doc était nécessaire :

Trust Anchor - Ampache : https://github.com/ampache/ampache/issues/3973
No cover - NC Music : https://github.com/owncloud/music/issues/1156
No cover - Power Ampache : https://github.com/icefields/Power-Ampache-2/issues/13
NC Music documentation : https://github.com/nextcloud/documentation/issues/11951

Et encore merci à tous ces devs qui m’ont aidé à investiguer ce problème, ils ont tous été vraiment super !

Homepage, pour un beau tableau de bord (dashboard)

Sat, 08 Jun 2024 15:33:21 +0000

C’est sur une discussion reddit que j’ai vu une belle image de “dashboard”, et renseignements pris, il s’agissait de Homepage. Cela m’a paru sympa, et pratique pour avoir une vue globale des différents services/applications qui tournent sur mon réseau local et/ou sur mon hébergeur.

Disponible en container Docker (mais aussi pour Unraid ou Kubernetes), Homepage est facile à installer. Il suffit ensuite d’y déclarer ses services, avec pas mal de choses bien pensées qui facilitent leur supervision : que ce soit un container Docker, ou une application pour laquelle un widget est disponible (une centaine d’applications sont listées). Si aucune de ces deux conditions ne sont réunies, il sera toujours possible d’afficher un simple lien et la disponibilité du service.

On peut aussi y ajouter de simples liens vers des sites de son choix via le fichier bookmarks.yalm, une barre de recherche pointant sur le moteur de son choix, ou encore les ressources de la machine (cpu, mémoire, disk). Bref, de quoi se configurer un beau tableau de bord !

Une fois installé et configuré, cela peut donner un truc comme ça :

Voyons ça de plus près…

Installation

À noter tout de même l’avertissement de sécurité :

Homepage n’inclut pas de couche d’authentification, mais permet via ses widgets d’accéder à des informations personnelles. Il est donc recommandé de ne pas l’exposer sans être protégé par un proxy incluant authentification, SSL, etc.. ou derrière un VPN. En ce qui me concerne, rien ne sera exposé, je prévois de ne l’utiliser qu’en local.

J’ai choisi l’installation en mode Docker, via un container. La documentation est ici.

J’en ai profité pour utiliser l’interface d’OMV 7 pour créer le fichier compose. Il suffit d’aller dans Services - Fichiers, puis de créer le fichier en question :

Le contenu du fichier est comme suit, en ayant créé le dossier homepage dans AppData auparavant, comme indiqué :

---
# https://github.com/benphelps/homepage
services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    ports:
      - 3000:3000
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/homepage:/app/config # Make sure your local config directory exists
      - /var/run/docker.sock:/var/run/docker.sock # (optional) For docker integrations
    restart: unless-stopped

Important: la ligne concernant docker.sock va permettre d’accéder directement aux containers lors de la configuration des services de type docker.

Il ne reste plus qu’à cliquer sur le bouton “Up” dans l’interface d’OMV. Le service est désormais accessible à l’adresse d’OMV sur le port 3000 (ou celui de votre choix défini ci-dessus).

Configuration

La documentation se trouve ici. C’est assez simple et bien expliqué. On déclare et configure les services dans un fichier services.yaml, les liens dans un fichier bookmarks.yalm, les réglages généraux sont dans un fichier settings.yaml, etc… Tous ces fichiers se trouvent dans /srv/dev-disk-by-label-DATA/AppData/homepage (selon fichier compose ci-dessus).

# pwd
/srv/dev-disk-by-label-DATA/AppData/homepage
# ls
bookmarks.yaml  custom.js    kubernetes.yaml  services.yaml       settings.yaml
custom.css      docker.yaml  logs             services.yaml.good  widgets.yaml

Il y a beaucoup de possibilités, il suffit de parcourir toutes les options et d’appliquer les exemples fournis. Ou de chercher en cas de besoin spécifique.

Les Widgets

Le plus intéressant, ce sont donc les widgets disponibles pour une centaine de services (dans mon cas OMV, Portainer, Plex, Nextcloud, qBittorrent, Pihole), souvent à travers un “web service” ou une API. Exemple pour Nextcloud :

NOTE: pour afficher ces champs par défaut (sans avoir à cliquer sur le service), ajouter showStats: true dans le fichier settings.yaml (sinon le définir au niveau de chaque service). Par défaut, tous les champs disponibles seront affichés, sinon on les définit avec la propriété fields.

Docker socket

D’autres informations seront renvoyées par l’accès au container via la socket Docker.

Nextcloud

On obtient donc ceci :

Et voilà la définition complète pour mon serveur Nextcloud dans le fichiers services.yaml :

    - Nextcloud:
        icon: nextcloud.png
        href: https://nextcloud.xxxxx.yyyy.fr/
        description: Serveur Nextcloud
        server: my-docker
        container: nextcloud2023
        widget:
          type: nextcloud
          url: https://nextcloud.xxxxx.yyyy.fr/
          key: SZzC2-sFH3Q-jY2Eg-AaFMk-zzzzz

Pour générer la clef (key) ou le “NC-Token”, il faut aller dans l’interface Nextcloud, Paramètres personnels - Sécurité, puis en bas de la page cliquer sur “Créer un nouveau mot de passe d’application”. Après s’être identifié, un token vous est proposé qu’il faudra copier car une fois cliqué sur Terminé, il ne sera plus jamais affiché.

Il faut ensuite le définir au niveau système ; pour ce faire, j’accède au mode console du container grâce à Dockge :

Puis je tape la commande suivante :

root@0e47f46ce787:/# occ config:app:set serverinfo token --value vvvvv-wwwww-xxxxx-yyyyy-zzzzz
Config value token for app serverinfo set to vvvvv-wwwww-xxxxx-yyyyy-zzzzz
root@0e47f46ce787:/#

Et voilà, le container Nextcloud est configuré ! Je vous laisse découvrir la liste des widgets disponibles et leur syntaxe sur la page de documentation. Il y a aussi des widgets de type “info” capables d’afficher les ressources système ou les infos météo, ou ajouter une barre de recherche…

Portainer

Pour Portainer, il faudra faire deux choses :

Identifier l’environnement : via l’interface, aller dans environnement, puis le sélectionner (“local” par défaut) et observer l’URL du navigateur. Dans mon cas, c’était http://192.168.1.30:9000/#!/endpoints/2, l’ID à utiliser est donc 2.

I va aussi falloir générer une clef. Toujours dans l’interface de Portainer, cliquer en haut à droite sur “my account”, puis dans “Access tokens” choisir “Add Access token”. Une fois le token affiché, on le copie et on l’ajoute au service défini dans services.yaml. Qui est comme suit :

    - Portainer:
        icon: portainer.png
        href: http://192.168.1.30:9000/
        description: Portainer, gestion de container Docker
        server: my-docker
        container: portainer
        widget:
          type: portainer
          url: http://192.168.1.30:9000
          env: 2
          key: ptr_accesskeyaccesskeyaccesskeyaccesskey

Ping et statusStyle

On peut aussi vérifier la disponibilité d’un service non docker avec une fonction de ping (OMV, Pihole, Volumio) et statusStyle pour le format d’affichage. Exemple avec Pihole :

    - Pihole:
        icon: pi-hole.png
        href: http://192.168.1.17:8080/admin
        description: Pihole, bloqueur de pubs et DHCP Serveur
        ping: http://192.168.1.17:8080
        statusStyle: "dot"
        widget:
          type: pihole
          url: http://192.168.1.17:8080/
          #version: 6 # required if running v6 or higher, defaults to 5
          key: yourpiholeapikey # optional

Après avoir mis à jour mon Pihole à la dernière version soit la 5.18.2 (juin 2024), j’ai du renseigner l’API key, sinon je n’obtenais pas les valeurs.
On la trouve facilement via l’interface de Pihole, dans Settings-API, bouton “Show API token”.

La version 6 n’est pour l’instant disponible qu’en status “beta”.

Les icônes

Autre truc sympa : les icônes sont automatiquement retrouvées depuis Dashboard Icons, il ne suffit plus dès lors qu’à un indiquer le nom du fichier comme nextcloud.png, et Homepage se débrouille du reste. Les autres options (material design, local, etc…) sont détaillées ici.

Pour utiliser des icônes locales, il faut monter un nouveau volume /app/public/icons dans le fichier compose.yaml (et créer le dossier correspondant) :

volumes:
      - /srv/dev-disk-by-label-DATA/AppData/homepage/icons:/app/public/icons

et référencer les icônes ainsi dans le fichier services.yaml : icon: /icons/myicon.png

Conclusion

C’est vraiment très pratique de pouvoir tout avoir sur une page, de visualiser si les services sont bien Up, de pouvoir accéder d’un click au service de son choix pour un besoin quelconque.

Pour ma part, j’ai viré la barre de recherche présente par défaut, laissé les infos système en haut de page, et ajouté mes containers, ainsi qu’OMV, Pihole et Dockge. Dommage que ce dernier ne fasse pas partie de la liste des 100 services pour lesquels un widget a été prévu, je n’ai donc que les infos fournies par la socket Docker. Enfin j’ai ajouté des liens vers les services qui tournent sur mon hébergeur.

Dockge - Gestion des containers Docker

Mon, 03 Jun 2024 07:39:49 +0000

Je suis tombé sur cet outil un peu par hasard, et comme je n’étais pas satisfait des possibilités offertes par les interfaces de OMV7 ou de Portainer, j’ai testé (et adopté) Dockge.

Dockge est un gestionnaire de stack Docker, orienté Docker Compose (fichier compose.yaml). En gros, cela permet de configurer plusieurs containers dans un seul fichier, comme j’ai du le faire pour Nextcloud (qui utilise Nextcloud, une base de données Mariadb et un serveur proxy Swag, voir cet article).

Quand on utilise des containers simples (une application pour un container), ce n’est pas forcément utile d’utiliser Docker Compose, un simple script avec une commande docker run suffit, comme je l’ai fait pour mes autres services (plex, qbittorrent). Mais rien ne l’empêche non plus.

Et du coup, j’ai tout passé sous Dockge, car son interface est à la fois simple et complète : on peut arrêter, redémarrer, voir les logs, accéder au shell, éditer le fichier compose.yaml, et même (last but not least) effectuer une mise à jour ! :cool:

Voilà comment je l’ai installé et configuré.

Installation

L’installation est simplissime. On se connecte sur la machine (mon odroid-hc2 en l’occurence) où tournent les containers docker, et on suit les étapes : Création des répertoires pour nos stacks et celle de Dockge, téléchargement du fichier pour le container Dockge, et démarrage :

$ su
# mkdir -p /opt/stacks /opt/dockge
# cd /opt/dockge
#
# curl https://raw.githubusercontent.com/louislam/dockge/master/compose.yaml --output compose.yaml
#
# docker compose up -d

Voilà, l’application Dockge tourne sur http://localhost:5001. Difficile de faire plus simple.

Importer ou créer les containers existants

Pour Nextcloud, ayant déjà utilisé une stack (et donc un fichier compose), il a suffit d’arrêter l’application (i.e. le container, via Portainer par exemple, puisque l’interface d’OMV ne permet qu’un redémarrage), puis “d’importer” le fichier dans Dockge :

Pour cela, aller dans Portainer - Stack, sélectionner Nextcloud, aller dans l’onglet Editor, et copier le contenu dans un fichier que l’on appellera compose.yaml. Sur la machine, on crée alors un dossier pour le service, et on y copie le fichier que l’on aura transféré auparavant sur la machine :

$ su
# mkdir /opt/stacks/nextcloud
# cp /home/pascal/compose.yaml /opt/stacks/netxcloud/compose.yaml

Il suffit alors de recharger la page de Dockge pour voir le service Nextcloud apparaître, il ne reste plus qu’à le démarrer.

Pour mes deux autres services, je n’avais pas utilisé de stack, mais un simple script utilisant docker run. J’ai donc du créer un fichier compose.yaml pour chacun, et cela m’a permis de découvrir deux choses.

Plex

Pour Plex, j’ai arrêté l’application via Portainer, créé le fichier compose.yaml comme indiqué sur la documentation, puis copié dans /opt/stacks/plex. En démarrant Plex, j’ai vu ce message concernant la mise à jour qui m’a intrigué :

Comme quoi une interface bien pensée peut être utile ! En allant voir sur le site du container, j’ai alors vu que l’architecture armv7l (x32) de mon bon vieux odroid-hc2 n’était plus supportée :

Après quelques recherches, la décision sur linuxserver.io de ne plus supporter cette architecture a été clairement annoncé dès mai 2022. Et de fait, le support est terminé depuis juillet 2023.

Ce qui veut dire que l’odroid-hc2 acheté il y a quatre ans va devenir compliqué à mettre à jour. C’est de ma faute, j’avais oublié de vérifier ce point en l’achetant, les architectures 32 bits sont obsolètes, les constructeurs devraient les avoir abandonnées depuis longtemps.

Bref, tant que tout fonctionne, je vais faire durer la situation tant que possible. Mais je peux déjà engager une réflexion sur mon prochain NAS, ce sera peut-être un miniPC avec par exemple un processeur Intel N100 qui offre avec le Quick Sync un meilleur décodage vidéo, chose importante pour Plex, et un point faible que j’ai observé avec l’odroid-hc2. Voir cette page intéressante pour choisir une plateforme Intel. Ces infos viennent d’une discussion à ce propos sur reddit la semaine dernière (premier sujet).

Qbittorrent

Pour Qbittorrent, ça a été un peu différent. J’avais déjà eu du mal à trouver un container alliant qbittorrent et openvpn pour mon architecture (voir cet article) : j’ai un compte Mullvad et souhaite utiliser OpenVPN pour m’y connecter.

Le site est ici, et comme le mentionne Chris, il propose bien une version multi-architecture. Hélas, il ne propose que la commande docker run pour créer le container.

Et je n’avais pas réussi à l’époque à créer un fichier compose valide dans Portainer, avec une erreur au démarrage " Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)" probablement due à l’option " --priviledged -d" utilisée avec docker run que je n’arrivais pas à définir dans le fichier compose.

J’ai recréé un fichier compose à partir de mes notes de l’époque, et tenté de le faire fonctionner avec Dockge. Après quelques tentatives et modifications, j’ai finalement réussi à en créer un de valide :

version: "2"
services:
  qbittorrent-openvpn:
    image: chrisjohnson00/qbittorrent-openvpn:latest
    container_name: qb-openvpn
    privileged: true
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
    volumes:
      - /srv/dev-disk-by-label-DATA/Download:/downloads
      - /srv/dev-disk-by-label-DATA/AppData/Qbittorrent:/config
    environment:
      - VPN_ENABLED=yes
      - LAN_NETWORK=192.168.1.0/24
      - NAME_SERVERS=8.8.8.8,8.8.4.4
      - VPN_USERNAME=xxxxxxx
      - VPN_PASSWORD=yyyyyyy
      - PUID=997
      - PGID=100
      - WEBUI_PORT_ENV=8080
      - INCOMING_PORT_ENV=8999
    ports:
      - 8080:8080
      - 8999:8999
      - 8999:8999/udp
    restart: unless-stopped

Et cerise sur le gâteau, au premier démarrage, le container est allé chercher le dernière version automatiquement ! Ce qui m’a permis de tester avec succès cette fonctionnalité extrêmement pratique.

Voilà, j’ai une interface pour les containers Docker qui semble complète. Elle s’appuie sur Docker, il faut donc que Docker tourne bien sûr ! Mais pour le reste, elle répond bien aux besoins que l’on peut avoir, de façon simple et efficace.

Mise à jour openmediavault v5 vers v7

Tue, 19 Mar 2024 17:50:46 +0000

Le temps passe vite en informatique, et la durée de vie des produits ou du matériel encore plus.

J’avais acheté mon Odroid-HC2 et installé OMV V5 en 2020. Quatre ans plus tard, si tout fonctionne encore, je recevais quotidiennement des mails m’informant que la mise à jour système avait échouée :

CRON-APT RUN [/etc/cron-apt/config]: Tue Mar  5 07:05:30 CET 2024
CRON-APT SLEEP: 2353, Tue Mar  5 07:44:43 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get  update -o quiet=2
E: The repository 'http://apt.armbian.com buster Release' does not have a Release file.

En regardant tout ça de plus près, je me suis rendu compte que plus rien n’était supporté : ni le matériel, ni l’OS, pas plus que la version d’OpenMediaVault ! Il était temps de faire quelque chose…

Obsolescence

Je vois que le dépot armbian pour Buster (soit Debian 10) n’existe effectivement plus. Une petite vérification côté Debian me montre que la version Buster ne sera plus supporté le 20 juin 2024. Les équipes d’ armbian ont donc juste un peu d’avance, sans doute parce que leurs ressources sont limitées.

Rien d’alarmant, je pourrais rester en l’état (tant que ça marche…), mais ce n’est jamais une très bonne solution, je fais donc un peu de recherches complémentaires. Et je m’aperçois qu’OMV5 est également passé en E nd O f L ife depuis juin 2022.

Côté matériel, ce n’est pas mieux : ma carte Odroid-HC2 est elle aussi passée en “Obsoleted Product”, et il n’y a plus d’images de fournies pour Debian v11 ou même v12… La page armbian n’affiche même plus de modèles Odroid pour une architecture armhf ! Je vous le dis, le temps passe vite et en 4 ans, plus rien n’est supporté ! :eek:

Ma seule option est alors de faire une mise à jour d’OMV5 vers OMV6 pour passer à Debian 11.

Suppression des mails

Mais dans un premier temps, comme cela me fatiguait de recevoir un mail d’erreur tous les matins, j’ai commencé par mettre en commentaire le lien pointant sur le dépôt en question dans le fichier /etc/apt/sources.list.d/armbian.list :

$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop

Cela a fonctionné, mais j’ai alors reçu un autre mail quotidien concernant le dépôt de plugins :

CRON-APT RUN [/etc/cron-apt/config]: Sun Mar 17 07:37:59 CET 2024
CRON-APT SLEEP: 1502, Sun Mar 17 08:03:01 CET 2024
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get  update -o quiet=2
E: The repository 'https://dl.bintray.com/openmediavault-plugin-developers/usul buster Release' does not have a Release file.

Et donc même façon de résoudre le problème, je commente la ligne dans /etc/apt/sources.list.d/omvextras.list :

$ cat /etc/apt/sources.list.d/omvextras.list
# deb https://dl.bintray.com/openmediavault-plugin-developers/usul buster main

Mise à jour OMV6

Bon, je savais que tout cela devait être temporaire, et je me décide pour faire une mise à jour d’OMV5 vers OMV6.

Prudent, je commence par faire une image de ma carte microSD avec Clonezilla histoire de pouvoir revenir en arrière si la mise à jour plante, car je ne souhaite pas me retrouver bloqué sans serveur Plex, Nextcloud ou Qbittorrent…

Puis je lance la commande suivante pour m’assurer que tout est à jour :

$ sudo omv-upgrade

Huit paquets sont d’ailleurs mis à jour, parfait. J’enchaîne avec la véritable commande de mise à jour vers OMV6 et Debian 11. En fait les deux sont liés, chaque version d’OMV est associée à une version de Debian, et le script de mise à jour en tient compte bien sûr.

$ sudo omv-release-upgrade

La fenêtre suivante s’affiche :

Je valide, et la mise à jour démarre. Cela prend du temps, mais à la fin le système redémarre et je découvre la nouvelle interface d’OMV6, dont un écran de connexion inspiré de Matrix du plus bel effet :

Sauf que je m’aperçois que tout ce qui concerne les plugins a été totalement revu et profondément modifié. Et de ce fait, je n’ai aucun plugin d’installé, et bien sûr aucun de mes conteneurs Docker ne fonctionne.

Je commence à regarder tout ça, à chercher un tuto sur internet, et puis je me dis que dans ces conditions, autant en profiter pour passer à OMV7. Il sera toujours temps de refaire la configuration des plugins ensuite, et j’aurai une version très récente d’Openmediavault, puisque cette version date du 03 mars 2024.

Aussitôt dit aussitôt fait, un coup de omv-upgrade suivi d’un omv-release-upgrade et me voilà en OMV7 sous Debian 12 Bookworm. :cool:

Configuration

Je me retrouve donc au même point qu’avec OMV6 : aucun plugin d’installé. Il faut commencer par installer les OMV Extras en téléchargeant un script comme indiqué sur cette page :

$ sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | bash

Pour ma part, j’ai du d’abord télécharger le fichier, puis l’exécuter, le “pipe” sur bash ne fonctionnait pas. Donc cette commande :

$ sudo wget https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install

Puis je renomme le fichier en installomvextra.sh et lance le script, qui extrait un fichier openmediavault-omvextrasorg_latest_all7.deb puis procède à l’installation.

Voilà, nos plugins sont désormais disponibles, et pour Docker, il faut installer openmediavault-compose dans Système-Extensions :

À ce stade, j’ai un beau menu dans Services-Compose qui me remplit d’espoir : Docker a l’air beaucoup mieux intégré à l’interface d’OMV, on y retrouve directement les containers par exemple, mais pas que :

Mais quand je vais dans Conteneur, si je vois bien mes conteneurs (c’est déjà ça), il sont tous à l’arrêt et refusent de démarrer. Il faut d’abord aller dans Shared Folders, vérifier que tout est correct et corriger ce qui ne l’est pas.

Puis aller dans Compose - Paramètres vérifier les deux entrées suivantes qui correspondent aux données des containers créés (Compose Files), et à l’emplacement de Docker (j’avais déplacé Docker sur le disque externe du NAS, voir cet article).

Une fois tout ceci vérifié, j’essaie à nouveau de démarrer un container, et nouvel échec ! Le message d’erreur n’est pas évident, si ce n’est que le container ne peut être démarré, et un beau " function not implemented" :

Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart  25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown

OMV\ExecException: Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; docker restart  25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc 2>&1': Error response from daemon: Cannot restart container 25dcc66efa478d729cc7a600f85cd6813632d504e82cd63902f0f21a86f1a7dc: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown in /usr/share/openmediavault/engined/rpc/compose.inc:1080
Stack trace:
#0 /usr/share/php/openmediavault/rpc/serviceabstract.inc(622): OMVRpcServiceCompose->{closure}()
#1 /usr/share/openmediavault/engined/rpc/compose.inc(1068): OMV\Rpc\ServiceAbstract->execBgProc()
#2 [internal function]: OMVRpcServiceCompose->doContainerCommand()
#3 /usr/share/php/openmediavault/rpc/serviceabstract.inc(122): call_user_func_array()
#4 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
#5 /usr/sbin/omv-engined(535): OMV\Rpc\Rpc::call()
#6 {main}

Le Kernel

Je fais alors une recherche sur internet, et je dois dire que je suis assez chanceux, car je tombe immédiatement sur cette page, qui indique que le problème vient d’une version de kernel trop ancienne.

Je vérifie sur ma machine et effectivement, mon kernel ne semble pas à niveau :

$ uname -a
Linux odroidhc2 4.14.222-odroidxu4 #1 SMP PREEMPT Mon Nov 22 12:13:27 UTC 2021 armv7l GNU/Linux
$
$ sudo docker info
...
Kernel Version: 4.14.222-odroidxu4
...
$

Mon premier réflexe est d’aller voir le fichier que j’avais modifié manuellement pour éviter le premier mail : il est toujours en l’état avec le ligne pour Buster commentée, j’y ajoute la ligne qui correspond à ma nouvelle version de Debian :

$ cat /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com buster main buster-utils buster-desktop
deb http://apt.armbian.com bookworm main bookworm-utils bookworm-desktop
$

Puis je lance une mise à jour, et je vois que 3 paquets vont être mis à jour : armbian-config armbian-firmware base-files. Mais cela ne change pas la version du kernel, et ne résout pas mon problème.

Pour identifier le kernel à installer, la commande suivante permet de les afficher :

$ sudo apt-cache search linux-image | grep odroid
linux-image-current-odroidxu4 - Armbian Linux current kernel image 6.1.79-current-odroidxu4
linux-image-edge-odroidxu4 - Armbian Linux edge kernel image 6.1.77-edge-odroidxu4
linux-image-legacy-odroidxu4 - Linux kernel, version 4.14.222-odroidxu4

Et j’ai déjà vu lors de l’installation de la première image que ma carte odroid-hc2 utilise la même image que celle d’un odroid-xu4 : voir cet article sur le changement du motd ! :wink: . À priori, il faudrait prendre le “current”. Mais bon j’ai quand même quelques interrogations, je n’ai jamais fait cette opération, et évidemment il n’y a pas le droit à l’erreur…

Mais internet va me fournir une solution alternative, avec un outil armbian dédié pour configurer les cartes ARM, et qu’il suffit d’installer :

$ sudo apt-get install armbian-config

Il ne reste plus qu’à le lancer en mode sudo, puis de choisir System, et enfin de sélectionner Switch to other kernels :

Il ne reste plus qu’à laisser l’outil récupérer les versions disponibles, et choisir parmi celles qu’il vous propose : et l’outil me propose bien la même version de kernel que la commande apt, cela me rassure. Je valide, et le nouveau kernel est installé avant que le système ne redémarre :

Après le redémarrage, je vérifie et cette fois mon kernel est passé en version 6 :

$ uname -a
Linux odroidhc2 6.1.79-current-odroidxu4 #3 SMP PREEMPT Thu Feb  8 13:10:24 UTC 2024 armv7l GNU/Linux

Voici venu le moment décisif : je retourne dans Services - Compose - Conteneurs pour démarrer un container Docker, et YES ! il démarre sans aucun problème… :razz:

Conclusion

La mise à jour d’OMV s’est tout de même très bien passée, puisque j’ai quand même fait un saut de 2 versions majeures où la gestion des plugins a été complètement revues et modifiée, tout en incluant une mise à jour de l’OS (Debian 10 à Debian 12).

Ce n’était donc pas une mince affaire, et finalement, je n’ai eu que quelques paramètres à vérifier côté purement OMV. Pour la version de Kernel, c’était un peu plus compliqué à priori, mais l’utilitaire fourni par armbian a parfaitement rempli sa fonction et résolu mon problème en quelques minutes.

Voilà, il me reste à découvrir un peu mieux cette nouvelle version d’OMV. À priori, je n’aurai sans doute plus besoin de la page Portainer pour gérer mes conteneurs, tout semble gérable à partir de l’interface d’OMV7. Et je suis normalement tranquille pour quelques années de support ! :cool:

OMV : Mise à jour des containers Nextcloud et Plex

Sun, 12 Mar 2023 17:49:30 +0000

Voilà un moment que je cherchais comment mettre à jour proprement mon instance Docker de Nextcloud. En fait l’info était bien disponible, bien que peu détaillée, sur la page du container, mais je me mélangeais un peu les pinceaux entre l’image, le container, et l’application elle-même.

Voilà ce qui est indiqué dans la documentation fournie par Linuxserver.io, ce n’est pas hyper clair, et la section “Updating Info” pour chaque container n’est vraiment ni détaillée ni très explicite :

La plupart de nos images sont statiques, versionnées, et nécessitent une mise à jour de l’image et une recréation du conteneur pour mettre à jour l’application qu’elles contiennent. À quelques exceptions près (par exemple, nextcloud, plex), nous ne recommandons ni ne prenons en charge la mise à jour des applications à l’intérieur du conteneur.

Sur les forums Docker, on déconseille également l’utilisation de Portainer, l’interface fournie par défaut dans OpenMediaVault pour gérer ses images et containers Docker. En particulier pour des problèmes de gestion de version des applications justement.

Donc pour la création d’un nouveau container, rien ne vaut une bonne vieille commande docker run, et tant qu’à faire autant la mettre dans un script pour pouvoir la réutiliser facilement. Pour Plex, cela suffira à utiliser la dernière version de l’application au sein de ce nouveau container. Pour Nextcloud, on procédera de la même manière pour mettre à jour le container (si nécessaire), sinon on passera par l’interface de Nextcloud pour faire les mises à jour, cela fonctionne très bien.

Enfin, je parlerai vite fait de la mise à jour d’OMV lui-même à la fin de l’article.

Allons-y…

Plex

Commençons par le plus simple… J’ai commencé par vouloir faire la mise à jour à partir de Portainer : mais j’avais beau recréer une nouvelle image puis un nouveau container, ce n’était jamais la bonne version de binaire qui était exécutée quand je vérifais les logs.

Après plusieurs essais infructueux, j’ai fini par poser des questions sur un forum Discourse consacré à Docker. On m’a alors fortement déconseillé l’utilisation de Portainer typiquement pour les problèmes que j’avais observés. On me recommandait d’utiliser les commandes docker, directement, afin d’éviter tout problème.

J’ai donc fini par faire un script pour recréer un nouveau container (plex2023) comme si c’était la première création, tout en gardant les mêmes emplacements pour mes dossiers médias bien entendu. Ça donne ceci dans mon cas :

docker run -d --name=plex2023 --net=host -e PUID=997 -e PGID=100 -e VERSION=docker -v /srv/dev-disk-by-label-DATA/AppData/Plex:/config -v /srv/dev-disk-by-label-DATA/OMV-DATA/Series:/Series -v /srv/dev-disk-by-label-DATA/OMV-DATA/Films:/Films -v /srv/dev-disk-by-label-DATA/OMV-DATA/Docus:/Docus lscr.io/linuxserver/plex:latest

Voilà, c’est tout simple. Il suffit d’arrêter l’ancien container Plex et de lancer celui-ci, et c’est la dernière version de Plex qui tourne. Une fois que l’on a vérifié que tout fonctionne correctement, il ne reste plus qu’à effacer l’ancien container.

Nextcloud

Mise à jour majeure

Pour passer d’une version majeure à une autre, ou cas de problème lors d’une mise à jour via l’interface comme ci-dessus, il peut être aussi simple de recréer de nouveaux containers à partir de nouvelles images.

On commence par arrêter les 3 containers (nextcloud-mariadb-swag), puis télécharger les dernières versions des images Docker. Là aussi, autant passer passer par le mode commande de Docker, c’est aussi simple et plus clair :

$ sudo docker image pull linuxserver/nextcloud:latest
$ sudo docker image pull linuxserver/mariadb:latest
$ sudo docker image pull linuxserver/swag:latest

Les nouvelles images vont apparaître dans Portainer, ce sont celles-ci qui seront utilisées pour créer les containers. Pour cela, je vais utiliser Portainer et les “stacks” qui sont bien pratiques pour tout créer en une seule fois. J’ai juste changé le nom des containers pour me repérer (en ajoutant “2023” à la fin), et gardé les mêmes chemins des volumes (config, data…). Pour les détails de la config, voir le premier article sur la création du container Nextcloud.

---
version: "2.1"
services:
  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud2023
    environment:
      - PUID=997
      - PGID=100
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config:/config
      - /srv/dev-disk-by-label-DATA/AppData/Nextcloud/data:/data
    ports:
      - 443:443
    depends_on:
      - mariadb
    restart: unless-stopped
  mariadb:
    image: linuxserver/mariadb
    container_name: nextclouddb2023
    environment:
      - PUID=997
      - PGID=100
      - MYSQL_ROOT_PASSWORD=keepsecret
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Nextclouddb:/config
    ports:
      - 3306:3306
    restart: unless-stopped
  swag:
    image: linuxserver/swag
    container_name: swag2023
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=997
      - PGID=100
      - TZ=Europe/Paris
      - URL=xxx.pled.fr
      - SUBDOMAINS=nextcloud
      - VALIDATION=http
      - EMAIL=yyy@zzz
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/swag:/config
    ports:
      - 444:443
      - 81:80
    restart: unless-stopped

Penser tout de même à vérifier sur les pages de linuxserver (ici pour nextcloud) pour chaque container si les paramètres à utiliser n’ont pas changé.

Une fois les containers créés, il n’y a plus qu’à les lancer. Mais en procédant ainsi, Nextcloud n’est pas mis à jour, je suis toujours en version 23 (comme pour Plex plus haut donc). Pourtant quand je regarde mon image Docker, c’est bien la v25 (qui est censée fournir Nextcloud 25) :

$ sudo docker inspect -f '{{ index .Config.Labels "build_version" }}' nextcloud2023
[sudo] password for pascal:
Linuxserver.io version:- 25.0.2-ls216 Build-date:- 2023-01-08T09:28:17-06:00

Ce n’est donc pas suffisant, même si c’est toujours utile de mettre à jour le container. J’ai fini par tomber sur cette page, qui donne la bonne solution (et même 2 manières de procéder, j’ai choisi la seconde puisqu’il est mentionné que c’est la meilleure). Et tout a parfaitement fonctionné.

Info

J’ai depuis effectué plusieurs mises à jour de Nextcloud en passant tout simplement par l’interface de Nextcloud sans modifier quoique ce soit auparavant. Il suffit d’aller dans “Paramètres d’administration” dans le menu en haut à droite, puis de suivre les indications.

L’opération prend plus ou moins de temps, mais cela a l’air assez bien fait (y compris un backup) et je n’ai rencontré aucun problème en procédant de cette manière.

Au pire, on relance la page en cas de time-out réseau ou quand une étape échoue : le script va reprendre au bon endroit comme un grand.

C’est donc vraiment une manip très simple et il est désormais facile de rester à jour en terme de version de Nextcloud.

Je laisse ci-dessous la méthode indiquée via une connexion ssh sur la machine, cela peut toujours servir. On peut aussi directement exécuter les comandes occ upgrade à partir de la console que propose Portainer pour le container Nextcloud.

Je lance donc la première commande une fois connecté en ssh à mon NAS OMV : à noter que c’est bien l’utilisateur abc qu’il faut utiliser ! J’ai d’abord cru à un exemple et remplacé par admin ou mon nom d’utilisateur nextcloud, mais non, il faut garder la commande telle quelle.

Répondre “yes” pour l’update, puis “no” pour l’upgrade d’ occ. Garder le mode maintenance actif si c’est demandé.

$ sudo docker exec -it nextcloud2023 sudo -u abc php /config/www/nextcloud/occ upgrade
Nextcloud or one of the apps require upgrade - only a limited number of commands are available
You may use your browser or the occ upgrade command to do the upgrade
Setting log level to debug

Updating database schema
Updated database
Updating  ...
Updated  to 1.12.0
Updating  ...
Updated  to 1.12.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 1.19.0
Updating  ...
Updated  to 2.16.0
Updating  ...
Updated  to 1.7.0
Updating  ...
Fix broken values of calendar objects
 Done
    0/0 [->--------------------------]   0%
Clean up old calendar subscriptions from deleted users that were not cleaned-up
 Done
    0/0 [----->----------------------]   0%
Updated  to 1.22.0
Updating  ...
Updated  to 1.16.2
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 1.17.0
Updating  ...
Updated  to 2.6.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 2.13.0
Updating  ...
Updated  to 1.13.0
Updating  ...
Updated  to 2.12.1
Updating  ...
Updated  to 1.15.0
Updating  ...
Migrate old user config
 Done
    1/1 [============================] 100%
Updated  to 1.10.0
Updating  ...
Updated  to 7.4.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 2.5.0
Updating  ...
Updated  to 1.3.0
Updating  ...
Updated  to 2.9.0
Updating  ...
Updated  to 1.6.0
Updating  ...
Updated  to 1.8.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 1.3.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 1.6.0
Updating  ...
Updated  to 1.7.0
Updating  ...
Updated  to 1.12.0
Updating  ...
Updated  to 3.5.1
Updating  ...
Updated  to 1.13.0
Updating  ...
Updated  to 1.14.0
Updating  ...
Updated  to 1.4.0
Updating  ...
Updated  to 1.8.0
Starting code integrity check...
Finished code integrity check
Update successful
Maintenance mode is kept active
Resetting log level

Tout cela prend un peu de temps, mais la commande s’exécute sans erreur. Puis on lance la deuxième commande pour mettre à jour occ (le nom vient à l’origine de o wn c loud c onsole) :

$ docker exec -it nextcloud sudo -u abc php /config/www/nextcloud/occ upgrade

Enfin, on désactive le mode maintenance :

$ sudo docker exec -it nextcloud2023 sudo -u abc php /config/www/nextcloud/occ maintenance:mode --off

Et voilà : j’ai enfin mis à jour mon container Nextcloud ! Il ne reste plus qu’à aller sur la page web pour vérifer tout ça.

Mise à jour mineure

Plus tard, pour une mise à jour mineure, j’ai utilisé l’interface de Nextcloud, il s’agissait de passer de la v25.0.2 à la v25.0.12. Et tout s’est passé sans souci. Il y a deux étapes, il faut patienter un peu, mais globalement c’est parfait .

Info

Comme indiqué plus haut dans l’article, que ce soit pour une mise à jour mineure ou majeure, c’est la meilleure et la plus simple façon de procéder.

OMV

Pour OMV, la première chose à faire est d’aller dans le Gestionnaire de mises à jour et de les appliquer. Il y a peut-être un paquet openmediavault de proposé parmi toutes les mises à jour disponibles. En fait c’est l’équivalent d’un sudo apt update ; sudo apt upgrade en ligne de commande.

Je l’ai fait récemment, et je suis passé en 5.6.26-1 :

$ sudo apt policy openmediavault
[sudo] password for pascal:
openmediavault:
  Installed: 5.6.26-1
  Candidate: 5.6.26-1
  Version table:
 *** 5.6.26-1 500
        500 http://packages.openmediavault.org/public usul/main armhf Packages
        500 https://openmediavault.github.io/packages usul/main armhf Packages
        100 /var/lib/dpkg/status

Il y a aussi la commande omv-upgrade, qui fait exactement la même chose, comme l’indique la documentation.

En l’état, je suis donc en OMV v5 avec un système avec les toutes dernières mises à jour de cette version. Comment faire pour passer en OMV v6 ? Ce sera la commande omv-release-upgrade, et la documentation indique ceci :

omv-release-upgrade

Il s’agit d’un script qui n’est inclus que dans les dernières versions d’openmediavault avant de passer à la version majeure suivante, par exemple de 5.6.x à 6.x. Cette commande migre le système vers la version majeure suivante d’openmediavault (qui inclut généralement une mise à jour de la distribution Debian).

Personnellement, je ne l’ai pas encore fait, puisque tout fonctionne comme je le souhaite avec la v5. Je verrai cela plus tard. D’autant que OMV 6 est basé sur Bebian 11 (Bullseye), le script effectuera en même temps la mise à jour du système puisque je suis en Debian 10 Buster :

Ce n’est donc pas une “minor update”, mais bien une “major upgrade” ! Il faut donc préparer sérieusement ce genre de mise à jour avant de se lancer ! On trouve des conseils sur cette page du forum OMV. Les pré-requis sont indiqués ici.

Conclusion

Je suis plutôt content, car ça faisait un bout de temps que je voulais mettre à jour mon Nextcloud sans trouver la bonne méthode. Avec celle décrite ici, c’est nickel.

J’ai pu aussi voir les limites de Portainer, car j’ai passé du temps et fait pas mal d’essais infructueux pour essayer d’upgrader Plex. Finalement le mode commande de Docker est très puissant, assez simple à utiliser, la documentation bien faite, alors autant l’utiliser parce qu’au on est sûr de ce que l’on fait… et ça marche !

OpenMediaVault : Installation de Nextcloud version 23

Thu, 10 Feb 2022 17:48:21 +0000

Suite au changement de HD sur mon NAS, j’ai été amené à réinstaller mes containers Docker. L’occasion d’en apprendre un peu sur les sauvegardes d’images que je faisais et comment les restaurer.

Pour Nextcloud, j’ai finalement décidé d’en profiter pour installer la dernière version disponible, et d’oublier l’idée d’une restauration. J’étais en v21.0.4, et c’est actuellement la v23.0.0 qui est disponible sur linuxserver.io. Allons-y pour une installation toute neuve, mais en gardant mon fichier config.php, spécifique à mon réseau.

Tout n’a pas été simple, loin de là. J’ai pu constater que l’installation avait pas mal changé depuis la première installation (v20), et que la restauration de mon dossier de configuration devait se faire plus tard, sinon l’installation bloquait ! J’ai aussi noté quelques trucs utiles en cas de problème sur les logs et l’accès à la Base de Données. Pour finir, j’ai aussi eu une erreur de type “mise à jour” ! :mad:

Revoyons un peu tout ça…

Fichier CAN_INSTALL

J’ai tout d’abord repris ma “stack” de l’installation précédente, celle qui inclut nextcloud/mariadb/swag (voir cet article). J’ai juste modifié le nom des images qui avait changé dans l’exemple fournit par linuxsserver.io/nextcloud : on passait de “linuxserver/xxx” à “lscr.io/linuxserver/xxx” pour chaque composant.

J’avais aussi remarqué que pour MariaDB, il y avait trois paramètres supplémentaires : MYSQL_DATABASE, MYSQL_USER et MYSQL_PASSWORD. Mais je ne les ai pas ajoutés, ce qui m’amènera à une erreur (voir plus bas) : il est donc préférable de les ajouter à la stack de base (l’utilisateur de la base à renseigner est le nom de l’administrateur nextcloud). Bref, j’aurais tout aussi bien fait de reprendre la nouvelle stack proposée, et d’y modifier mes paramètres, que de faire l’inverse…

Pour la suite de cet article, le container MariaDB s’appelle nextclouddb ( container_name dans la stack). C’est aussi le nom que je donne à la base de données lors du setup de Nextcloud.

J’ai donc déployé la nouvelle stack (avec nouvelle version des softs, au moins pour Nextcloud). Puis j’ai arrêté le container Nextcloud et recopié tout le dossier “config” de ma version précédente défini dans la stack : " /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config:/config".

Mais en relançant Nextcloud, j’ai eu un beau message sur la page du navigateur (dommage, je n’ai pas fait de capture), me disant grosso-modo:

Il semble que vous essayez de réinstaller votre Nextcloud. Cependant le fichier CAN_INSTALL est manquant dans votre répertoire de configuration. Veuillez créer le fichier CAN_INSTALL dans votre répertoire de configuration pour continuer.

Je me suis dit que j’étais sur la bonne voie, il ne restait qu’à créer un fichier CAN_INSTALL vide dans le répertoire de config. Hélas, j’ai eu beau créer ce fichier dans /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config, impossible de finir l’installation qui restait bloquée sur cette page d’erreur.

Après quelques recherches sur le web, il semble que ce message soit un “faux ami”, et n’ait en fait rien à voir avec la vraie source de l’erreur, qui serait plutôt lié à la base de donnée pas encore accessible.

Le fichier config.php

J’ai alors redéployé ma stack, mais cette fois sans recopier mon dossier config, me disant que finalement, je pouvais repartir d’une installation propre et recréer ce dont j’avais besoin facilement (je n’utilise Nextcloud que pour le partage de dossiers).

Mais je voulais tout de même réutiliser mon fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/www/nextcloud/config/config.php (voir [la première installation](http://le fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/www/nextcloud/config/config.php :)) pour correspondre à mon environnement réseau (les “trusted_domains” notamment, ce fichier n’est pas évident à configurer).

Et c’est là que je me suis rendu compte que le fichier config.php n’existait pas encore. Je le créais donc, mais c’était quand même inattendu !? Du coup, la page Nextcloud affichait une belle erreur “Internal Server error”.

Message peu parlant, et rien trouvé dans les logs !

J’ai fini par comprendre que je ne devais pas créer ce fichier config.php à ce stade (contrairement à la v20). Dès le déploiement de la stack, sans modifier quoique ce soit, la page de Nextcloud était disponible pour y fournir les informations de connexion habituelles : compte admin, infos base de données, avant de cliquer sur le bouton “Terminer l’installation”.

Ce n’est qu’une fois que l’on a fournit ces infos et cliqué sur le bouton “Terminer…” que l’installation se termine et que le fichier config.php est téléchargé, comme beaucoup d’autres fichiers d’ailleurs. Ce n’était pas le cas avec la v20, la procédure d’installation a vraiment changé depuis cette version, et la copie de fichiers semble se faire désormais en deux étapes.

Les Logs

Avant de continuer, un petit mot sur les logs. Le premier endroit à aller voir est celui du container. Soit via Portainer, soit en mode commande (nextcloud étant le nom du container) :

sudo docker logs -f nextcloud

Si l’on ne trouve rien à ce niveau (attendre parfois quelques minutes, j’ai observé des messages qui arrivaient avec un certain délai), il faut alors se tourner vers les logs Nextcloud.

Le fichier à consulter est celui-ci (dans ma config) : /srv/dev-disk-by-label-DATA/AppData/Nextcloud/data/nextcloud.log.

On peut modifier le niveau de log en allant éditer le fichier config.php mentionné plus haut. Le paramètre ’loglevel’ est à 2 par défaut, on peut éventuellement le passer à DEBUG pour avoir le maximum d’informations (source).

Base de données

Une fois l’installation terminée, je peux enfin y copier mon fichier config.php en lieu et place de celui fournit par défaut.

Je ne sais plus trop à quel moment j’ai encore une erreur liée à la base de donnée. C’est en fait lié aux trois paramètres supplémentaires que je n’ai pas indiqué dans la stack : MYSQL_DATABASE, MYSQL_USER et MYSQL_PASSWORD. Là aussi, c’est nouveau par rapport à la v20. Et comme je ne les ai pas déclarés, Nextcloud se retrouve incapable d’accéder à la Base de Données avec l’utilisateur “pascal”. Cette fois, j’ai un message clair dans le log du container Nextcloud :

Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[HY000] [1045] Access denied for user 'pascal'@'172.21.0.1' (using password: YES) in /config/www/nextcloud/lib/private/DB/Connection.php:87

Heureusement, la solution est assez facile pour résoudre ce problème, à savoir créer la BdD, l’utilisateur pascal et lui accorder les droits. On peut accéder à l’interface MySQL soit via la console de Portainer, soit dans un terminal avec la commande suivante :

$ pascal@odroidhc2:~$ sudo docker exec -it nextclouddb bash
[sudo] password for pascal:
root@cdd5100474d7:/#
root@cdd5100474d7:/# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 42838
Server version: 10.5.13-MariaDB-log MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Si l’on choisit la console Portainer du container MariaDB (appelé ici nextclouddb), on ne tape que la commande mysql bien sûr. Une fois que l’on a le prompt MariaDB on exécute les commandes suivantes :

MariaDB [(none)]> CREATE USER 'pascal' IDENTIFIED BY 'password';
MariaDB [(none)]> CREATE DATABASE IF NOT EXISTS nextclouddb;
GRANT ALL PRIVILEGES ON nextclouddb.* TO 'pascal' IDENTIFIED BY 'password';
FLUSH PRIVILEGES;
exit

Voilà, avec ces changements, l’installation de Nextcloud peut enfin se terminer correctement.

Mise à jour

Cette fois, la page d’accueil de Nextcloud s’ouvre enfin : je crois alors en avoir fini avec cette installation, mais un message m’informe qu’une mise à jour va avoir lieu… Pourquoi pas, je valide, et un message d’erreur apparaît alors :

Cette fois, j’ai tout de suite le bon réflexe : je vais voir le fameux fichier config.php que j’ai recopié de l’ancienne version (pour ma configuration réseau). Et il y a bien une ligne : 'version' => '21.0.4.1', (soit mon ancienne version Nextcloud) que je transforme tout de suite en 'version' => '23.0.0.0',.

Je rafraîchis la page et la mise à jour s’effectue alors sans problème :

Et voilà, mon nouveau Nextcloud est enfin opérationnel !! :cool:

Info

Il m’est également arrivé après une mise à jour mineure (29.0.3 ver 29.0.11) de me retrouver avec une message m’informant que le serveur est en mode de maintenance, alors que la mise à jour a l’air de s’être bien passée.
Là aussi, il faut aller dans le fichier config.php et passer le paramètre 'maintenance' => false, puis de rafraîchir la page.

Conclusion

Cela n’a pas été sans mal, mais je suis finalement assez satisfait : j’ai appris quelques nouveaux trucs utiles : la phase d’installation en deux temps, aller voir les logs, accéder à la Base de Données… Ça peut servir dans l’avenir !

Et j’ai aussi vu que pour l’utilisation que j’en fais (partage de dossiers), une réinstallation n’est pas un gros souci. Je n’utilise aucune APP, mes contacts et calendriers sont sauvegardés d’une autre manière, etc… Recréer les dossiers de partage, et y recopier les fichiers (qui sont synchronisés sur le PC) n’est pas un problème et ne prend pas tant de temps que ça.

Je rappelle tout de même que l’on peut à priori mettre à jour son container Nextcloud assez facilement, voir cet article. J’avoue que je l’avais un peu oublié quand je me suis lancé dans ma restauration, j’aurais sans doute pu m’en inspirer et me simplifier la vie ! :neutral:

Nouveau HD pour mon NAS OpenMediaVault

Fri, 04 Feb 2022 18:06:50 +0000

Comme je commençais à recevoir des mails m’informant que mon disque externe (DATA) était occupé à 85%, je me suis dit qu’il était temps de le remplacer par un plus grand.

Lors de l’installation d’OMV sur mon ODROID-HC2, j’avais utilisé un vieux HD de 1 To que j’avais en stock. Il était temps de doubler la taille : pour une cinquantaine d’euros, j’ai donc acheté un HD 3,5" - Seagate BarraCuda 2 To sur Amazon (je sais, c’est mal).

Restait à effectuer le remplacement, et ça n’a pas été aussi simple que je l’aurais souhaité : entre le hard-reset du PC pendant la création d’une image Clonezilla, le crash de la SDcard qui contient l’OS du NAS OMV, les copies inutiles, les errements avec Docker, j’ai eu droit à un bel échantillon de la loi des emm.. maximum ! (également appelée loi de Murphy) :eek:

Tout est désormais reparti, j’ai pu finalement tout restaurer même Nextcloud, mais pour ce dernier je ferais un article dédié.

Dans cet article, je me limiterai au changement du HD. Finalement, j’aurais tout aussi bien pu le brancher directement et y restaurer mes sauvegardes rsync, j’aurais gagné du temps ! Mais comme souvent, j’aurais au moins appris des choses qui me seront utiles la prochaine fois !

Concernant la restauration des images Docker, j’ai mis à jour l’article OpenMediaVault : Sauvegarde & Restauration des containers Docker avec explications et exemple pas-à-pas.

Clonezilla

J’ai donc commencé par vouloir faire une image du disque de 1To avec Clonezilla, que j’aurais restaurée sur le nouveau. Du simple et efficace, à la restauration sur le nouveau HD, je devais juste passer en mode expert, et cocher l’option “-k1” pour étendre la partition à la nouvelle taille du disque. J’étais confiant ! :cool:

Une fois résolu le problème de trouver de la place de libre sur mes disques pour y écrire une image de presque 1To (!), branché le HD à l’arrache à la place de mon lecteur de DVD sur le PC, démarré sur la clef USB Clonezilla, et lancé la création de l’image, tout allait encore bien… Et comme il y en avait pour des heures de copie, je suis donc sorti prendre l’air. Au retour, le PC avait redémarré et affichait le premier écran de Clonezilla. Je ne sais pas ce qu’il s’est passé, mais un bon gros “hard-reset” comme ça, ça ne sent pas bon, et mieux valait abandonner toute de suite que de relancer une tentative, vu la durée de l’opération. Bref, il était temps de passer au plan B.

Rsync

Puisque la solution Clonezilla avait échoué, je décide d’utiliser l’outil rsync. Je lance donc la commande :

rsync -av /media/pascal/DATA /New2GO/ODROID-EXT-HD

/media/pascal/DATA est le point de montage de mon HD 1To connecté au PC.
/New2GO/ODROID-EXT-HD est le dossier que j’ai créé sur un disque local pour la sauvegarde.

Et là, deuxième problème : au bout d’un moment la copie semble s’arrêter sur un fichier, plus rien ne se passe, et aucun message d’erreur ! le système répond au ping, mais pas à une connexion SSH… Le diagnostique sera rapide : la SDcard de l’ODROID qui sert de disque système à OpenMediaVault vient de lâcher ! :mad: Bon c’est le problème avec ces cartes (voir cet article) : ça meurt d’un coup, et c’est sans espoir.

Heureusement, j’avais une sauvegarde (une image clonezilla faite il y a un an, après avoir déplacé Docker sur le HD, donc à priori fonctionnelle puisque je n’ai pas fait de modifications particulières côté OMV depuis. Je redémarre donc sur cette carte, et ma foi tout se passe bien. :cool:

J’aurai juste un petit problème de mise à jour automatique, car le lendemain je recevais un mail avec ce genre d’erreur :

CRON-APT RUN [/etc/cron-apt/config]: Fri Jan 28 17:22:59 CET 2022
CRON-APT SLEEP: 155, Fri Jan 28 17:25:34 CET 2022
CRON-APT ACTION: 0-update
CRON-APT LINE: /usr/bin/apt-get  update -o quiet=2
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
E: Repository 'http://security.debian.org buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
E: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'stable-updates' to 'oldstable-updates'

Bon, ce sera vite réglé avec cette commande :

sudo apt update --allow-releaseinfo-change

Revenons donc à rsync et à la copie de mon HD de 1 To. Puisque ma médiathèque Plex est déjà sauvegardée par un script hebdomadaire, je décide de l’exclure de la commande, ça me fera gagner 500 Go de fichiers à sauvegarder ! La syntaxe rsync est assez simple, il suffit de savoir que le dossier que l’on donne à l’option --exclude est le chemin relatif à la source donnée plus loin. Une fois ceci compris, le tape donc :

rsync -av --exlcude OMV-DATA /media/pascal/DATA /New2GO/ODROID-EXT-HD

OMV-DATA est donc un sous-répertoire de /media/pascal/DATA qui contient ma médiathèque Plex.

Voilà, la sauvegarde rsync s’effectue alors sans problème, je remarque au passage que j’aurais pu vider la corbeille de Nextcloud car je vois passer quelques gros fichiers sauvegardés inutilement.

Je branche alors le nouveau HD 2To sur le PC et procède à l’opération inverse pour y copier tous les dossiers/fichiers précédemment sauvegardés, et voilà ! Normalement, je suis prêt à redémarrer OMV avec le nouveau HD de 2 To de connecté sur mon ODROID-HC2 contenant tout ce qu’il faut. C’est du moins ce que je croyais…

OpenMediaVault

Je redémarre donc OMV, et là, déception : si mon nouveau disque est bien détecté dans le menu Stockage/Disque, je dois le recréer dans Stockage/Système de fichiers, et ce faisant je perds toutes les données que j’y avais copié ! :mad:

Toute ma copie précédente n’a donc servi à rien : Je vais devoir encore y recopier tous les fichiers ! Ce n’est pas un gros problème (c’est juste un peu long), et je le saurai pour la prochaine fois ! Bonne chose, les “Dossiers Partagés” d’OMV sont toujours présents, il faut donc bien garder le même libellé “DATA” pour éviter d’avoir à les recréer :

Bon, ça avance quand même. Côté PC, j’ajoute dans /etc/rsync.conf un libellé [oms-root-rsync] qui pointe sur le rsync fait plus haut sur /New2GO/ODROID-EXT-HD, afin d’y avoir accès à partir du NAS (voir ici). Je redémarre bien sûr le service rsync après cette modif :

sudo systemctl restart rsync

Je me connecte ensuite en SSH sur le NAS, et je lance la copie de fichiers (troisième tentative !) en espérant que ce soit la bonne ! :neutral:

cd /srv/dev-disk-by-label-DATA/
sudo rsync -av rsync@192.168.1.20::omv-root-rsync .

Cette fois la copie arrive à son terme, je peux enchaîner avec la médiathèque de Plex une fois le dossier OMV-DATA recréé :

cd /srv/dev-disk-by-label-DATA/
sudo mkdir OMV-DATA
sudo chown -R admin OMV-DATA
cd OMV-DATA
sudo rsync -av rsync@192.168.1.20::omv-docus-rsync .
sudo rsync -av rsync@192.168.1.20::omv-films-rsync .
sudo rsync -av rsync@192.168.1.20::omv-series-rsync .

Conclusion

Voilà mon disque est enfin restauré. Finalement, j’aurais pu brancher le nouveau HD dès sa réception, et y restaurer mes sauvegardes rsync ! Car c’est finalement ce que j’ai fini par faire, et cela a bien fonctionné. Peut-être le clone avec Clonezilla aurait pu permettre le remplacement transparent du HD, mais je ne le saurais pas…

Reste à m’occuper des containers Docker, la partie que je pensais la plus complexe au départ. En fait il s’agissait surtout de comprendre Docker, ce qu’est une image, un container, etc… Tout est expliqué dans cet article, où j’ai ajouté une partie “Restauration”.

Nextcloud : mise à jour du container et limite de taille de fichiers à 1Go et 2 Go

Mon, 23 Aug 2021 13:30:33 +0000

J’ai eu un problème avec Nextcloud sur le NAS OMV, à savoir que les fichiers de plus de 1GB que je partageais échouaient systématiquement au téléchargement. :oops:

Je me suis dit que la première chose à faire, c’était de mettre à jour Nextcloud à la dernière version (vieux réflexe de support). Comme je ne m’étais pas encore penché sur la façon de mettre à jour mes containers docker, c’était l’occasion. Je vais ainsi passer Nextcloud de la version 20.0.5 à la 20.0.12, puis à la 21.0.4.

Cela ne suffira pas à régler le problème d’origine, je me suis alors attaqué au problème de taille de fichiers partagés. Et je suis tombé sur deux limites à traiter : 1Go et 2Go. La première est due aux paramètres du proxy (swag), la seconde à l’architecture 32 bits de mon NAS.

Voyons voir tout cela…

Mise à jour du Container Plex

J’ai mis à jour récemment (27/12/22) le container Plex, et j’indique ici la méthode, même si je n’ai pas pris les screenshots au bon moment !) :

Dans l’onglet Image de Portainer, on télécharge la dernière version :

Une nouvelle image apparaît en bas dans la liste, avec une date récente. Elle est marquée “unused”.

On passe maintenant dans l’onglet Containers de Portainer, on arrête l’image plex actuelle, et on clique sur le nom du container. On renomme alors de “plex” à “plex.save” (cliquer sur le petit crayon) :

Puis on clique sur le bouton “Duplicate/Edit”, et :

On remet le nom “plex” d’origine.
On désactive “Always pull the image”.
On clique sur “Deploy the container”.

Et voilà ! le nouveau container est démarré, avec la dernière version de l’image ! Après avoir vérifié que tout fonctionne comme attendu, on peut supprimer l’ancien container (plex.save) et l’ancienne image.

Simple et efficace.

Mise à jour des images docker (à vérifier)

Tant que j’y suis, je vais mettre à jour toute la stack : nextcloud, mariadb, et swag.

Comme j’utilise une image Docker, je suis d’abord allé voir sur la page du container linuxserver/nextcloud ce qu’ils disaient à ce propos : Nextcloud fait partie des rares applications que l’on peut mettre à jour via l’interface graphique (tant mieux) à condition d’avoir vérifié que l’on utilise la dernière image docker disponible.

Pour ce faire, Docker sur OpenMediaVault est fourni avec Portainer comme interface de gestion des containers. Il faut donc aller sur la page Portainer, puis choisir “Images” dans la partie gauche, entrer le nom de votre image docker, puis cliquer sur “Pull the image”. Voilà l’exemple pour linuxserver/swag :

Et on fait la même chose pour linuxserver/nextcloud et linuxserver/mariadb. Une fois ceci fait, on observe en bas de la fenêtre que les images <latest> sont bien les dernières téléchargées, et que mes anciennes images (datant de janvier dernier) sont tagguées en <none>.

Elles sont encore marquées “Unused”, c’est normal. Il va falloir maintenant redémarrer les containers. Comme je les avais installés en créant une “Stack” (on installe les 3 containers d’un coup, et cela permet d’indiquer la dépendance de Nextcloud vis-à-vis de mariadb), il faut cliquer sur “Stack” dans la partie gauche de la fenêtre, cliquer sur “nextcloud” (le nom de ma stack), puis sur “Stop this stack” :

Il suffit alors de redémarrer la Stack, et les versions <latest> que l’on vient de télécharger vont être automatiquement utilisées. On se retrouve donc avec les anciennes versions marquées “Unused” :

Il est recommandé par la suite de les effacer, cela prend de la place sur le disque pour rien. Mais attendez tout de même de vérifier que les nouvelles fonctionnent correctement ! ;)

Voilà, j’ai récupéré et mis en service les dernières versions des images docker fournies par Linuxserver pour swag, nextcloud et mariadb. Concernant Nextcloud, je peux donc passer à la mise à jour via l’interface graphique.

Mise à jour de Nextcloud

C’est très simple, il suffit d’aller sur la page d’administration (https://your.nextcloud.fr/settings/admin/overview), puis de suivre les instructions. Là, on me propose de passer de la v20.0.5 à la 20.0.12, soit une upgrade mineure. Bon, pourquoi pas ? Après toute une série de vérifications, de téléchargement de la nouvelle version, etc… l’assistant vous propose de continuer avec le “web based updater” :

On valide, et l’on retrouve les habituelles instructions de sauvegarde avant de lancer pour de bon la mise à jour de Nextcloud :

Une fois cette “mini” mise à jour terminée, je retourne sur la page d’administration, et là je vois qu’une nouvelle mise à jour m’est proposée : celle vers la v21.0.4 ! Cette fois, c’est beaucoup plus intéressant, je vais passer de la v20 à la v21 :

La mise à jour s’effectue sans souci particulier, et après quelques minutes, j’ai ma nouvelle version Nextcloud qui tourne et est opérationnelle.

Sauf qu’après un test rapide, mon problème de téléchargement de gros fichiers est toujours présent. Il va falloir investiguer pour de bon !

Le problème de téléchargement

Le problème était donc le suivant : je créais sous Nextcloud un lien public pour partager un fichier avec des amis, et lorsque le fichier faisait plus de 1Go, le téléchargement échouait systématiquement. En investiguant, je suis donc tombé sur deux limites : 1Go et 2Go.

Limite 2Go

Je commence par regarder les logs Nextcloud, et je vois ce genre de message :

Si j’en crois ce message, le problème se situe quand le fichier dépasse 2Go… Quelques recherches sur le net m’apportent vite la réponse : mon serveur (un odroidhc2) a un processeur armv7l, soit une architecture 32 bits :

pascal@odroidhc2:~$ sudo lshw
odroidhc2
    description: ARMv7 Processor rev 3 (v7l)
    product: Hardkernel Odroid XU4
    width: 32 bits
    capabilities: smp

Or la version PHP utilisée par Nextcloud ne gère pas les fichiers de cette taille ! On trouve d’ailleurs cette information dans la doc :

Cette histoire de 32 bits ne m’avait pas tracassé à l’achat, mais là, je me rends compte qu’il est préférable d’avoir une architecture x64 de nos jours ! :( Le pire, c’est que cela pourrait être facilement corrigé, il y a longtemps que cette limite a été dépassée au niveau OS, mais il semble que les efforts de développement de Nextcloud préfèrent se porter ailleurs, et donc ce problème ne sera à priori pas corrigé.

Bon, je retiens qu’il vaut mieux éviter le 32 bits désormais, ça commence à être un peu trop vieux !

Ceci dit, cela ne m’affecte que si j’utilise l’upload par la page web, ou par l’adresse WebDav, lorsque je veux copier mon fichier dans Nextcloud. J’ai alors copié le fichier en ligne de commande sur la machine pour contourner le problème. J’ai créé un dossier “Public” dans Nextcloud, et dans mon cas le répertoire physique est /srv/dev-disk-by-label-DATA/AppData/Nextcloud/data/pascal/files/Public.

Saut qu’en copiant le fichier de cette manière, Nextcloud ne l’indexe pas, et il n’apparaît donc pas dans l’interface, pas moyen donc de le partager ! Là encore, il y a une solution : Via Portainer, on se connecte en mode console, et on lance l’indexation avec la commande suivante : occ files:scan pascal (pascal étant le nom de l’utilisateur nextcloud) :

L’opération est plutôt longue, plus de 20 minutes dans mon cas… Mais une fois terminée, on voit apparaître notre fichier de plus de 2Go dans le dossier Nextcloud, et l’on peut enfin créer le lien de partage :

En procédant de cette manière, on contourne la limitation de 2Go qui en fait ne concerne que la phase “d’upload” du fichier vers Nextcloud. La phase “Download” fonctionnera très bien, quand il s’agira de “récupérer” le fichier.

Limite de 1Go

Mais avant que cela fonctionne, il reste une autre limite à régler, car les téléchargements échouent à 1Go, et cette fois sans aucun message d’erreur.

Mon premier souci a été de reproduire le problème : en effet, sur mon réseau local, le téléchargement s’effectuait sans souci. Comme j’ai un abonnement VPN, j’ai activé celui-ci sur le PC, et cette fois j’ai pu reproduire l’erreur :

En surveillant de près la progression, c’était bien dès que le téléchargement en cours atteignait la taille de 1 Go que ce dernier s’arrêtait et s’affichait en “Échec” dans Firefox. Mais je n’avais aucun log, aucune autre information (enfin je n’ai rien trouvé en tout cas).

Tout de même, comme cela fonctionnait sur le réseau local, je pouvais orienter mes recherches du côté du serveur proxy, à savoir le container swag.

Un petit essai avec wget en ligne de commande me confirmait le problème : pour ce faire, il faut d’abord récupérer le lien direct dans Nextcloud en affichant la page du lien partagé, puis cliquer sur les trois petits points :

Puis dans un terminal, utiliser wget avec l’option –no-check-certificate suivi du lien direct fourni par Nextcloud :

wget --no-check-certificate https://Lien.direct.de.Netxcloud

En procédant de la sorte, j’ai pu voir que wget affichait “connection closed”, puis “retrying”, et arrivait ensuite à finir le téléchargement en reprenant le téléchargement à l’endroit où il s’était arrêté (désolé, je n’ai pas fait de capture d’écran). Mais cela renforçait la piste du proxy et le problème de la connexion https qui est fermée, sans doute pour un problème de taille…

Après moultes recherches sur le net, je suis tombé sur cette page, très intéressante, et qui fournit beaucoup d’infos sur les problèmes de performance liés à Nextcloud. Concernant les téléchargements qui échouent à 1GB, ils indiquent 4 paramètres à ajouter au “ssl server block in your Nginx configuration for Nextcloud” :

proxy_buffering off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
fastcgi_max_temp_file_size 0;

Restait à trouver le fichier correspondant pour swag ! Rappel : lors de l’installation du container, j’ai défini le volume suivant :

/srv/dev-disk-by-label-DATA/AppData/swag:/config

Le fichier que je cherche est finalement :

/srv/dev-disk-by-label-DATA/AppData/swag/nginx/ssl.conf

Les deux premiers paramètres sont déjà présents, je n’ai donc ajouté que les deux derniers. Et d’après la page, c’est fastcgi_max_temp_file_size qui par défaut limite la taille des fichiers à 1GB. En le mettant à 0, on supprime la limite.

Voilà, je redémarre le proxy, et je relance le download, et cette fois le téléchargement s’effectue jusqu’au bout sans souci :

Je teste avec un fichier de plus de 2 Go, cela fonctionne également !

Conclusion

Toute cette affaire m’a appris à mettre à jour mes containers, et c’est plutôt facile. Bonne nouvelle, je suis pour l’instant très satisfait de l’utilisation de Docker.

Cette limite de 1 Go par défaut pour la taille de fichiers est surprenante, je me demande bien pourquoi le paramètre n’est pas ajusté en conséquence ? Par contre, ce n’est pas un problème Nextcloud, mais du Proxy que l’on utilise… Ici, c’est Swag, un container fournissant un web serveur nginx avec php7, fail2ban (pour les intrusions), et Let’s Encrypt (pour les certificats) : plutôt pratique quand même ! ;)

Enfin, l’architecture 32 bits, qui commence à être abandonnée par les éditeurs (Ubuntu par exemple), est à éviter de nos jours. Ici, c’est un bug connu qui ne sera pas corrigé. Si j’avais su, j’en aurai tenu compte lors de l’achat de mon NAS, mais je retiens la leçon.

OpenMediaVault : Sauvegarde & Restauration des containers Docker

Fri, 14 May 2021 16:12:29 +0000

Lors de mon article sur l’organisation de mes sauvegardes sur mon NAS OpenMediaVault, il me manquait la bonne façon de sauvegarder les containers Docker.

Je sauvegardais avec rsync le répertoire où se trouve Docker, il y avait des milliers de fichiers, et je ne pense pas que j’aurais pu faire grand chose de cette sauvegarde en cas de problème ! :(

J’ai donc cherché du côté de Docker, et sans surprise Docker propose sa propre solution pour la sauvegarde des containers. Les principales commandes sont expliquées sur ce schéma :

L’idée est donc de créer une image de chaque container (commande COMMIT), puis de les sauvegarder au format .tar (commande SAVE). On voit sur l’image les commandes LOAD et RUN qu’il faudra utiliser dans l’autre sens pour la restauration.

Info

Suite à un crash disque, j’ai été amené à restaurer ces images Docker, et comprendre qu’ils ne contiennent en fait que les binaires permettant de créer des containers à l’identique (même version), compatibles avec nos fichiers de configuration existants.

J’ajoute donc une partie “Restauration” à cet article (avec explications et exemple pas-à-pas), qui ainsi sera plus complet.

Ensuite, il fallait que je copie ces fichiers .tar sur mon PC à l’aide de rsync, puisque j’ai déjà un serveur rsync qui tourne sur ce dernier. Il ne restait plus qu’à faire un peu de ménage avec ces images et fichiers créés sur le NAS ou sur le PC pour avoir quelque chose de propre.

J’ai donc préparé un script qui fait tout ça, que j’ai ensuite ajouté en tâche crontab au système. Ainsi mes containers sont sauvegardés chaque semaine.

Voyons voir un peu tout cela en détail. On aura ainsi un script automatique pour la sauvegarde de images, puis comment les restaurer et recréer les containers docker à partir de ceux-ci.

Dans l’explication ci-dessous, je ne traite que d’un seul container comme exemple (Nextcloud), il suffit d’appliquer les mêmes actions pour chaque container utilisé sur votre serveur que vous souhaitez sauvegarder.

Nous avons d’abord besoin d’identifier le nom de l’image de notre container. Pour cela, on va utiliser la commande docker images et noter le REPOSITORY soit linuxserver/nextcloud ci-dessous :

pascal@odroidhc2:~$ sudo docker images
REPOSITORY                           TAG       IMAGE ID       CREATED        SIZE
linuxserver/nextcloud                latest    70e33dd606b8   3 months ago   330MB

Dans le cas où le REPOSITORY est vide (ça m’est arrivé après une restauration je pense), taper sudo docker ps et noter le NAME (soit nextcloud ici) :

pascal@odroidhc2:~$ sudo docker ps
CONTAINER ID   IMAGE          ...       NAMES
d1ae35bfa2f1   ad54fea6e081   ...       nextcloud

Script - première partie

Dans un premier temps, on va définir quelques variables qui nous seront utiles dans le script : d’abord un répertoire où créer les fichiers image (disque externe du NAS OMV), ainsi qu’une variable pour ajouter un “time-tamp” aux fichiers que l’on va créer ; puis le nom de l’image (le REPOSITORY noté ci-dessus), qui nous permettra d’aller chercher le container ID, et enfin le nom de l’image.

# init des variables
backup_dir="/srv/dev-disk-by-label-DATA/Docker-Containers-Backup/"
now=$(date +%d-%m-%Y-%H-%M-%S)
nextcloud_imgname="linuxserver/nextcloud"
nextcloud_imgid=$(docker ps -a -f "ancestor=$nextcloud_imgname" -q -l)
bck_nextcloud_imgname=backup_nextcloud

Si on utilise le NAME, alors nextcloud_imgname="nextcloud" et on remplace ancestor par name :

# init des variables
backup_dir="/srv/dev-disk-by-label-DATA/Docker-Containers-Backup/"
now=$(date +%d-%m-%Y-%H-%M-%S)
nextcloud_imgname="nextcloud"
nextcloud_imgid=$(docker ps -a -f "name=$nextcloud_imgname" -q -l)
bck_nextcloud_imgname=backup_nextcloud

Une fois ceci fait, on peut créer une image du container :

# Création de l'image
docker commit -p "$nextcloud_imgid" "$bck_nextcloud_imgname"

Puis on copie cette image au format .tar dans un dossier du NAS défini plus haut :

# Sauvegarde de l'image sur le disque externe du NAS
docker save -o  "$backup_dir""$bck_nextcloud_imgname"_"$now".tar "$bck_nextcloud_imgname"

Puis on compresse l’archive :

# Compression des archives
gzip "$backup_dir"*.tar

Il ne reste plus qu’à envoyer l’archive sur le PC, où tourne un serveur rsync.

Serveur SSH sur PC

Pour éviter d’avoir à entrer un mot de passe lorsque le script arrive à cette étape, il m’a fallu activer le serveur SSH sur le PC :

pascal@SH87R:~$ sudo apt install openssh-server

Pour en limiter l’accès, j’ai modifié le fichier /etc/deny.hosts du PC en y ajoutant la ligne suivante (l’adresse IP étant celle du NAS):

pascal@SH87R:~$ sshd: ALL EXCEPT 192.168.1.30

Et je redémarre le service sshd dans la foulée :

pascal@SH87R:~$ sudo systemctl restart sshd

Côté NAS, il faut maintenant générer la clef pour permettre le login automatique (taper Entrée pour toutes les questions) :

pascal@odroidhc2:~$ ssh-keygen

Puis on copie la clef sur le PC avec l’utilisateur rsync (l’adresse IP est cette fois celle du PC) :

pascal@odroidhc2:~$ ssh-copy-id -i /home/pascal/.ssh/id_rsa.pub rsync@192.168.1.20

Voilà, la commande rsync que l’on va utiliser dans le script pourra désormais se logguer sans avoir à saisir de mot de passe.

Script - deuxième partie

Retour au script donc, où il s’agit de copier le(s) fichier(s) images compressés vers le PC :

# Copie des images compressées vers le PC
rsync -a --delete "$backup_dir" rsync@192.168.1.20::omv-containers-rsync/

NOTES

il ne faut pas utiliser de “wildcards” comme le caractère “*” dans la commande rsync si l’on veut que l’option --delete fonctionne !
J’utilise cette option --delete afin d’effacer de la destination (sur le PC donc) les fichiers qui ne sont pas présents sur la source. L’idée est de ne garder qu’une seule version des containers, chaque nouvelle sauvegarde effacera la sauvegarde précédente. Il doit être possible d’améliorer le script pour établir un système plus sophistiqué de sauvegardes, mais pour l’instant cela me convient tel quel.
Pour la syntaxe de type rsync@adresse_IP::nom_module utilisée, voir l’article des sauvegardes.

Il ne reste plus qu’à faire le ménage sur le NAS, à savoir effacer le fichier archive (désormais copié sur le PC) mais aussi effacé l’image docker que l’on peut voir sur une commande docker images :

pascal@odroidhc2:~$ sudo docker images
REPOSITORY                           TAG       IMAGE ID       CREATED          SIZE
backup_nextcloud                     latest    73e18450d11a   4 seconds ago   331MB
linuxserver/nextcloud                latest    70e33dd606b8   3 months ago     330MB

On efface donc fichier et image docker en ajoutant ces lignes au script :

# Nettoyage des fichiers et images
docker rmi "$bck_nextcloud_imgname"
rm "$backup_dir"*.gz

Et voilà, notre script est prêt. Il ne reste plus qu’à l’ajouter au crontab du compte root, afin qu’il ait les droits d’exécuter les commandes docker. On exécute donc sudo crontab -e pour ajouter la tâche, et voici ce que ça donne pour une exécution tous les dimanches à 13h30 :

sudo crontab -l
# m h  dom mon dow   command
30 13 * * 0 /home/pascal/docker-container-backup.sh

Voilà ce que donne le script avec les trois containers nécessaires à Nextcloud (Nextcloud, Mariadb et Swag) :

cat docker-container-backup.sh
#!/bin/bash
##########################################################
# Script de backup des containers Docker.
##########################################################

# init des variables
backup_dir="/srv/dev-disk-by-label-DATA/Docker-Containers-Backup/"
now=$(date +%d-%m-%Y-%H-%M-%S)

nextcloud_imgname="linuxserver/nextcloud"
nextcloud_imgid=$(docker ps -a -f "ancestor=$nextcloud_imgname" -q -l)
bck_nextcloud_imgname=backup_nextcloud

swag_imgname="linuxserver/swag"
swag_imgid=$(docker ps -a -f "ancestor=$swag_imgname" -q -l)
bck_swag_imgname=backup_swag

mariadb_imgname="linuxserver/mariadb"
mariadb_imgid=$(docker ps -a -f "ancestor=$mariadb_imgname" -q -l)
bck_mariadb_imgname=backup_mariadb

# Création des images
docker commit -p "$nextcloud_imgid" "$bck_nextcloud_imgname"
docker commit -p "$swag_imgid" "$bck_swag_imgname"
docker commit -p "$mariadb_imgid" "$bck_mariadb_imgname"

# Sauvegarde des images sur le disque externe du NAS backup_dir
docker save -o  "$backup_dir""$bck_nextcloud_imgname"_"$now".tar "$bck_nextcloud_imgname"
docker save -o  "$backup_dir""$bck_swag_imgname"_"$now".tar "$bck_swag_imgname"
docker save -o  "$backup_dir""$bck_mariadb_imgname"_"$now".tar "$bck_mariadb_imgname"

# Compression des archives
gzip "$backup_dir"*.tar

# Copie des images compressées vers le PC
rsync -a --delete "$backup_dir" rsync@192.168.1.20::omv-containers-rsync/

# Nettoyage des images
docker rmi "$bck_nextcloud_imgname"
docker rmi "$bck_swag_imgname"
docker rmi "$bck_mariadb_imgname"

# Nettoyage des fichiers
rm "$backup_dir"*.gz

#Fin du script

Et voilà mes sauvegardes sur le PC :

Je peux désormais dormir tranquille ! :cool:

Problème rencontré

Suite à un plantage du NAS qui ne répondait plus, et que j’ai donc du redémarrer en débranchant/rebranchant l’alimentation, tout est bien reparti, mais tous mes containers avaient pour REPOSITORY un simple “none” :

$ sudo docker images
REPOSITORY            TAG       IMAGE ID       CREATED        SIZE
<none>                latest    70e33dd606b8   7 months ago   240MB

Ce qui empêchait le script de backup de fonctionner ; c’est comme ça que je me suis rendu compte du problème d’ailleurs, puisque sinon tout fonctionnait !

J’ai pu les renommer avec leur ancien nom avec la commande docker tag :

$ sudo docker tag 70e33dd606b8 linuxserver/nextcloud
$ sudo docker images
REPOSITORY            TAG       IMAGE ID       CREATED        SIZE
<none>                latest    70e33dd606b8   7 months ago   240MB
linuserver/nextcloud  latest    70e33dd606b8   7 months ago   240MB

Cette commande crée en fait un nouveau tag (un alias en fait) pointant sur la même image (70e33dd606b8), il faut donc ensuite utiliser la commande docker rmi pour supprimer le tag inutile :

$ sudo docker rmi mauvais/tag:latest

Je n’ai pas vraiment analysé ce qui c’était passé lors de ce plantage. Apparemment, OMV a bien redémarré mais a créé un nouveau container pour portainer :

Bon, je n’ai pas creusé plus loin, mais cela explique sans doute le problème de tag… L’essentiel est que tout ait redémarré sans autre problème. Je peux effacer le container “unused”.

Restauration des images

Comme je le disais plus haut, suite à un crash disque, j’ai été amené à restaurer ces images : il y a quelques trucs à comprendre avant de se lancer.

Principes

Ces images Docker ne sont en fait que les binaires de votre container. Puisque l’on conserve (ou que l’on restaure) toute la config des containers dans les sous-dossiers /srv/dev-disk-by-label-DATA/AppData, il est important de recréer le container avec le même binaire.

Typiquement, si l’on utilisait une version plus récente, il est possible que des changements aient été apportés : nouveaux paramètres, fichier config modifiés, arborescence, etc… On s’exposerait alors à une incompatibilité, et donc à un dysfonctionnement. D’où l’intérêt de restaurer ces images, puis de lancer le container à partir de cette image : on garde ainsi le même “couple” binaire & config, et on s’assure de tout pouvoir retrouver à l’identique.

Tout cela paraît très logique et très simple, mais il vaut mieux le savoir avant de se lancer !

Mise en œuvre

Prenons le container Plex comme exemple. On commence donc par récupérer le fichier backup préparé comme indiqué plus haut sur le NAS, puis on le décompresse :

sudo gunzip backup_plex_16-05-2021-13-30-01.tar.gz

On obtient alors un fichier .tar, qu’il suffit de charger, soit en mode commande :

sudo docker load -i backup_plex_16-05-2021-13-30-01.tar
f7d9c37ee65c: Loading layer  416.8kB/416.8kB
Loaded image: backup_plex:latest

On vérifie qu’il est bien présent :

sudo docker images
REPOSITORY                           TAG       IMAGE ID       CREATED       SIZE
backup_plex                          latest    fdb5ba792f9e   3 days ago    272MB

À ce stade, l’image est chargée, et on peut la voir dans Portainer/Images, mais en status “unused” :

On peut bien sûr changer le nom du repository. Comme expliqué plus haut, il suffit de créer un nouvel alias puis de supprimer l’ancien :

sudo docker tag backup_plex:latest plex:latest
sudo docker images
REPOSITORY                           TAG       IMAGE ID       CREATED        SIZE
backup_plex                          latest    fdb5ba792f9e   4 days ago     272MB
plex                               latest    fdb5ba792f9e   4 days ago     272MB
sudo docker rmi backup_plex:latest
sudo docker images
REPOSITORY                           TAG       IMAGE ID       CREATED        SIZE
plex                               latest    fdb5ba792f9e   4 days ago     272MB

Mais restons avec backup_plex pour la suite de cet exemple, ce sera plus clair.

Avant de recréer le container, on vérifie que l’on a toujours les fichiers de config et de media de notre serveur Plex, que l’on a défini lors de la création du container dans la section “Volumes” d’OMV :

   volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Plex:/config
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Series:/Series
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Films:/Films
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Docus:/Docus

On peut alors recréer le container : soit par la commande docker run, soit avec l’outil docker-compose (source). Autant alors le faire en mode docker-compose via Portainer, c’est plus simple que la commande docker run à laquelle il faudrait passer plein d’options.

Et comme j’ai précieusement conservé mes “stacks” d’origine, rien de plus facile que de recréer le container, en faisant attention toutefois à donner le nom de l’image que l’on vient de créer :

On clique sur le bouton “Deploy the Stack” de Portainer, et le container est alors créé puis lancé. On peut vérifier que l’on a bien utilisé notre image avec la commande suivante :

sudo docker container ls
CONTAINER ID   IMAGE          COMMAND     CREATED      STATUS               PORTS      NAMES
7504da49ff62   fdb5ba792f9e   "/init"     39 seconds ago      Up 37 seconds                   plex

L’identifiant de l’image pour ce container est bien le même : fdb5ba792f9e… Et voilà, l’instance Plex tourne, et l’on retrouve tout de suite toute la médiathèque à l’adresse http://192.168.1.X:32400/web/index.html.

Conclusion

Si la partie “backup” a été assez facile à mettre au point, la partie “restore” à été plus laborieuse, puisque je n’avais pas vraiment compris ce que contenaient ces images.

En fait je mélangeais allègrement les concepts d’images et de containers. Or une image n’est que la partie binaire (version X du soft Y au format Docker). À partir de cette image, on crée un container qui aura ses fichiers de configuration etc…

Voilà l’utilité de ces sauvegardes d’images Docker : s’assurer de garder les mêmes binaires à disposition, afin de conserver leur compatibilité avec mes fichiers de configuration.

C’est ainsi que l’on retrouve son container “à l’identique”. :cool:

Openmediavault : Organisation des sauvegardes

Thu, 11 Feb 2021 18:07:55 +0000

Après voir mis en place mon serveur OMV, installé Plex, Nextcloud et qBittorrent-OpenVPN, il était temps de penser à la sauvegarde !

J’ai abandonné la baie Synology avec son RAID 1 (2 disques en miroir), et je n’ai plus qu’un seul disque sur mon magnifique Odroid-hc2 ! Et même si le RAID n’est une solution de sauvegarde, je ne sauvegardais que mes données avec la baie Synology.

Il s’agit maintenant de tout sauvegarder, alors voilà comment je me suis organisé :

pour les données, j’ai mis en place des jobs Rsync, ce que OMV permet de faire très facilement. La cible de sauvegarde se trouve sur le PC, sur lequel tourne un daemon Rsync.
pour les containers Docker, après un premier essai avec Rsync (non concluant, voir plus bas), j’ai fait un article dédié.
pour le disque système d’OMV, après avoir essayé sans succès des scripts utilisant la commande dd, je me suis rabattu sur Clonezilla pour sauvegarder une image de la carte microSD qui sert de disque système au odroid-hc2.

Voyons tout cela en détail…

Le serveur Rsync sur le PC

On commence par installer un serveur Rsync sur le PC, où seront sauvegardées mes données d’OMV. J’ai déjà décrit en détail cette procédure dans un article au temps de la baie Synology, je me limite donc à l’essentiel ici :

Il faut d’abord autoriser le service rsync à se lancer en éditant le fichier /etc/default/rsync pour y modifier la ligne suivante comme suit : RSYNC_ENABLE=true.

Il faut ensuite créer un fichier de configuration /etc/rsyncd.conf pour y définir principalement le ou les différent(s) dossier(s) sur le PC qui seront utilisés pour chaque tâche de sauvegarde, qui est identifiée par un nom de module entre crochets :

pascal$ cat /etc/rsyncd.conf
uid = rsync
gid = rsync
max connections = 2
log file = /var/log/rsyncd.log
timeout = 300

[omv-films-rsync]
   path = /Disk1/OMV-FILMS
   comment = Sauvegarde fichiers Films de Plex sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

[omv-docus-rsync]
   path = /Disk2/OMV-DOCUS
   comment = Sauvegarde fichiers Docus de Plex sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

[omv-AppData-rsync]
   path = /Disk2/OMV-AppData
   comment = Sauvegarde fichiers AppData sur le NAS OMV
   read only = false
   hosts allow = 192.168.1.30
   hosts deny = *

On commence par définir l’utilisateur, puis pour chaque dossier un ‘module’ (par ex. [omv-rsync-films]) où l’on définit le chemin, l’adresse IP autorisée, etc…

Dans mon cas, c’est l’utilisateur rsync, et je place les films de mon serveur Plex dans un dossier sur Disk1, et vu la taille, je mets le reste sur Disk2, à savoir les documentaires de Plex, ainsi que toute la partie Docker d’OMV (docker + les fichiers de configuration des containers, voir l’article Déplacement de Docker).

Enfin, il faut créer l’utilisateur rsync, lui donner un mot de passe, puis les droits sur les dossiers utilisés :

sudo useradd rsync
sudo passwd rsync
sudo groupadd rsync
sudo gpasswd -a rsync rsync
sudo chown -R rsync:rsync /Disk1/Odroid-OMV
sudo chmod -R 775 /Disk1/Odroid-OMV

Voilà pour la partie côté PC (destination de la sauvegarde).

Les jobs Rsync côté OMV

Grâce à OMV, cette partie est vraiment très facile. On se place donc dans la section “Services-Rsync”, et l’on crée un ‘job’ pour chaque tâche que l’on souhaite définir :

Info

J’ai depuis cet article supprimé la sauvegarde de AppData des jobs rsync, ce dossier comporte des milliers de petits fichiers, et ça ne sert pas à grand chose de le sauvegarder. À relier avec la façon de sauvegarder les containers Docker ci-dessous.

Pour chaque job, on définit donc le mode “Push”, puis on sélectionne le ‘shared folder’ correspondant définit dans OMV. Pour la destination, la syntaxe est la suivante : nom_utilisateur@adresse_IP_distante::nom_module_rsync (donc l’adresse de mon PC et le nom du module définit dans le ficher /etc/rsyncd.conf). Enfin, on entre le mot de passe attribué au compte rsync sur le PC.

Dans les options, vous pouvez choisir d’envoyer un mail grâce au système de notifications d’OMV (si vous l’avez défini). Penser aussi à activer l’option “Recursive”. Enfin, pour tester le fonctionnement, on peut activer l’option “Trail run” pour simuler une sauvegarde (à désactiver ensuite bien entendu).

Docker

Info

14 mai 2021 : Depuis, un nouvel article explique la bonne façon de sauvegarder ses containers Docker. Lire : OpenMediaVault : Sauvegarde des containers Docker

Le disque système

Sur l’odroid-hc2, le disque système est une carte microSD (comme sur les raspberry), et le disque contient raspbian ainsi qu’Openmediavault. Il est donc primordial d’avoir une sauvegarde de ce disque, la durée de vie d’un carte microSD n’étant pas éternelle, loin s’en faut.

C’est d’ailleurs pour cela que l’on évite d’écrire dessus, l’idée étant de travailler le plus possible en mémoire. C’est aussi pour cette raison que j’ai déplacé Docker sur le HD.

L’outil Disques de Gnome

C’est finalement cette solution qui est la plus simple et la plus efficace. Je laisse plus bas les autres options que j’ai testé (notamment CloneZilla, qui reste une référence), mais franchement l’outil de Gnome se révèle parfait.

J’arrête mon NAS, récupère la sd-card, et l’insère dans le PC. Je lance l’outil Disques de Gnome, et je fais tout simplement une image de la carte :

Simple et efficace. Pour la restauration, on choisit l’option “Restaurer…” et c’est tout.

La commande dd

J’avais d’abord testé des scripts utilisant la commande linux dd ( d ata d ump), qui permet de copier des fichiers, des partitions, ou un disque entier, tout en contrôlant la taille des blocks. C’est l’outil historique en ligne de commande pour cloner rapidement un disque dans le monde Linux.

L’idée était d’utiliser le port USB de l’odroid-hc2 pour y insérer une carte microSD, puis de créer une tâche planifiée (cron) pour automatiser la copie du disque système, disons chaque semaine. Sur le papier, c’était top : une fois mis en place, rien de particulier à faire, et on a toujours une sauvegarde récente du disque système récente toute prête.

Sauf qu’en essayant d’utiliser la sauvegarde, j’avais des messages d’erreur du genre “Failed to connect to socket: Connection refused” ou “address already in use”.

Le problème est classique : on sauvegarde un système en cours de fonctionnement, certains fichiers sont ouverts, et comme avec Linux tout est fichier, et les sockets aussi ! :(

Fin de la tentative.

Clonezilla + KVM

Pour faire un backup propre, mieux vaut le faire système éteint. Je me suis donc tourné vers Clonezilla, la star des clones de disques dans l’open source.

J’ai donc fait un shutdown d’OMV, et extrait la carte microSD de l’odroid-hc2. Avec l’idée d’utiliser le PC pour faire cette copie de disque-système sur une deuxième carte microSD de la même taille.

Mais je n’avais pas envie de redémarrer le PC sur une clef USB où j’avais flashé Clonezilla. Je me suis donc dirigé vers l’utilisation d’une machine virtuelle KVM, puisque c’est ce type de VM que j’utilise sur le PC. Et cela s’est révélé hyper simple et efficace, même s’il ne faut pas se tromper dans ce que l’on fait.

On lance donc n’importe quelle console de VM, puisque l’on va démarrer sur un port USB, on passe en vue “Afficher les détails”, puis on clique sur ajouter un matériel. Il s’agit maintenant de sélectionner trois périphériques USB :

la clef où se trouve CLonezilla
la clef où se trouve la carte microSD d’OMV (via un adaptateur)
enfin, un disque USB qui servira à stocker l’image que l’on va faire (pour la sauvegarde).

Dans l’exemple ci-dessous, je vais sélectionner l’Alcor Micro (Clonezilla), Sandisk (OMV) et LaCie (sauvegarde).

Puis on va dans “Options de démarrage”, et on sélectionne le périphérique USB où se trouve Clonezilla. Il ne reste plus qu’à démarrer la VM :

Inutile de s’embêter avec les réglages clavier, on n’utilisera que les touches tabulations, flèches haut/bas, et Entrée… Ensuite, au premier écran, on choisit “disque/partition vers/depuis image”.

Puis monter un périphérique local, où l’on choisira le disque USB que l’on a sélectionné précédemment :

Si le disque en question est partitionné comme c’est mon cas, on choisit une partition :

Il faudra ensuite choisir un dossier où sera effectuée la sauvegarde, et lui donner un nom (un nom par défaut est proposé, on peut le modifier). Laissez le défaut à priori. Reste à sélectionner le disque à sauvegarder :

Reste à choisir les dernières options : format de l’image, vérification de la sauvegarde, etc… Confirmez votre choix (deux fois), puis la sauvegarde démarre. Cela prend un certain temps (on sauvegarde 15 Go tout de même), surtout si vous avez demandé une vérification (recommandé). Quand tout est terminé, vous propose d’arrêter le système. Faire Entrée et choisir ‘poweroff’. La VM va alors s’éteindre.

Voilà, la carte microSD (le disque système d’OMV), est maintenant sauvegardé sur un disque du PC.

Pour la restauration vers une autre carte microSD, la procédure est très similaire, sauf que vous choisirez de l’image du disque dur comme source, et la carte microSD comme destination. Je m’épargne la série de capture d’écrans ! ;)

Info

Pour ceux que l’interface de Clonezilla rebute, je viens de voir passer une information sur Rescuezilla, compatible avec Clonezilla (même s’il n’offre pas toutes les options du mode Expert de ce dernier), mais avec une interface beaucoup plus sympathique et facile d’accès.

Stratégie

Une fois cette sauvegarde terminée, j’ai utilisé cette nouvelle carte microSD pour redémarrer mon système OMV, afin de m’assurer que l’image était totalement fonctionnelle. Et je procède ainsi à chaque sauvegarde.

J’avais déjà fait une première sauvegarde de ce type avant de déplacer Docker et d’installer un container qBittorrent. J’ai donc procédé à une nouvelle sauvegarde de mon disque système, et j’ai redémarré avec ma nouvelle sauvegarde.

Et donc à chaque modification importante du système, je procéderai de la sorte. En faisant tourner les cartes microSD à chaque fois, non seulement je fais une sauvegarde, mais je valide la restauration.

Car comme on dit en informatique, le “Disaster” c’est toujours très facile à réussir, le “Recovery” beaucoup moins ! :cool:

Openmediavault : déplacement de Docker

Thu, 28 Jan 2021 08:40:44 +0000

Alors que je commençais à réfléchir à la stratégie de sauvegarde de mon NAS (Openmediavault sur Odroid-hc2, 1 seul HD), j’ai du faire face à la problématique Docker.

Comme chaque soft (Plex, Nextcloud, qBittorrent) tourne dans un container, il est important de sauvegarder ceux-ci, et pas seulement les données qu’ils contiennent.

De plus, les containers Docker étant par défaut installés sur le disque système, soit une carte microSD dans mon cas, où il est préférable d’écrire le moins possible, cette configuration n’est pas optimale.

Je suis alors tombé sur cette vidéo : Why and how to move your Docker folder qui explique comment déplacer Docker, et je l’ai donc mis cela en pratique aujourd’hui, après plusieurs jours de réflexion. Car j’avais un peu peur de “casser” ma config, qu’un des containers Docker ne redémarre pas : j’avais pas mal galéré à installer Nextcloud, je ne voulais retomber dans les mêmes problèmes.

Mais finalement tout s’est globalement bien passé, à part un problème de droits sur mes dossiers Nextcloud justement. J’ai réglé le problème grâce aux sauvegardes que j’avais fait avant de me lancer (solution de facilité).

Voyons tout ça…

Docker

Par défaut, Docker est donc installé dans /var/lib/docker, comme on peut le voir dans Openmediavault/OMV-Extras :

Pour le déplacer, il suffit de modifier ce chemin, et de cliquer sur le bouton Save :

Je déplace donc Docker sur mon HD, dans le dossier /srv/dev-disk-by-label-DATA/AppData déjà utilisé par tous les containers Docker pour y stocker leurs fichiers de configuration. C’est pratique, je pourrais ainsi tout sauvegarder d’un coup : les containers et leur configuration.

Après quelques instants, Docker est redémarré, mais tous les containers ont disparu, y compris Portainer, qu’il va falloir réinstaller, c’est l’affaire d’un click. Jusque là, tout est vraiment simple.

Containers

La bonne nouvelle, c’est que l’on va pouvoir recréer ses containers sans perdre leur configuration ou les fichiers de données. Il va suffire de faire pointer les variables d’environnement correspondantes (les ‘volumes’) sur les mêmes dossiers que lors de la première création du container.

Pour Plex et Nextcloud, je suis passé par les Stacks, j’avais sauvegardé leurs configurations dans ce format, tout a donc été très simple : dans Portainer, sélectionner Stacks et cliquer sur le bouton Add stack :

Il suffit ensuite de coller le contenu que j’avais sauvegardé, mais que l’on peut retrouver sur la page du projet. L’important est de bien mettre les mêmes valeurs pour les différents volumes où sont nos fichiers :

---
version: "2"
services:
  plex:
    image : ghcr.io/linuxserver/plex
    container_name : plex
    network_mode: host
    environment:
      - PUID=997
      - PGID=100
      - VERSION=Docker
      - UMASK_SET=022
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Plex:/config
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Series:/Series
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Films:/Films
      - /srv/dev-disk-by-label-DATA/OMV-DATA/Docus:/Docus
    restart: unless-stopped

Et voilà ! En quelques minutes (les softs vont être téléchargés à nouveau), mon instance Plex est de nouveau disponible, et toutes les données conservées (par exemple les films Vus/Non Vus).

Pour qBittorent-OpenVPN, comme il y avait des paramètres non supportées par Portainer, j’avais le script utilisé pour l’installation, il a donc suffit de le relancer :

Templates

Il y a aussi la solution des “Templates” pour recréer rapidement ses containers. Par défaut, ceux proposés dans Portainer sont assez restreints, mais on peut modifier la liste proposée en la remplaçant par une autre plus adaptée à l’utilisateur standard. Il suffit d’aller dans Settings, et de remplacer le lien existant :

https://raw.githubusercontent.com/portainer/templates/master/templates-2.0.json

Par celui-ci, récupéré sur le page du projet Github selfhosted_templates :

https://raw.githubusercontent.com/SelfhostedPro/selfhosted_templates/portainer-2.0/Template/template.json

Puis cliquer sur “Save settings”. La liste des templates désormais proposée est alors beaucoup plus étoffée, on y retrouve Plex, Nextcloud, Pihole, Mariadb, etc…

L’idée est de s’en servir comme une base, et de l’éditer pour modifier certaines variables pour l’adapter à notre environnement personnel, et dans ce cas précis, faire pointer les variables de type ‘Volumes’ ou ‘Config’ au même endroit que précédemment.

Nextcloud

Nextcloud a été le plus compliqué, comme je m’y attendais, heureusement j’avais dupliqué mes données avant de me lancer.

J’avais le fichier “Stack” de l’installation, celui qui installe en même temps Nextcloud, Mariadb et Swag (voir l’installation de Nextcloud). Je l’ai donc lancé et là, première erreur :

Au moins le message est clair, et en vérifiant, il y avait une erreur dans mon fichier ‘docker-compose’, sans doute suite à un des premiers essais que j’avais fait en voulant l’installer : j’avais le port défini en 444:443 pour le container nextcloud au lieu de 443:443. Une fois corrigé, les trois containers nextcloud/mariadb/swag sont créés et démarrés sans problème.

Ensuite, je reçois un premier message de mon client Nextcloud sur le PC m’informant qu’il y a une erreur avec le certificat. En effet, en recréant mon instance Nextcloud, un nouveau certificat a été créé, il va donc falloir le valider pour chaque client se connectant à l’instance : le client Nextcloud sur le smartphone ou sur le PC, mais aussi dans Firefox pour accéder à la WebUI.

Première surprise : je retombe sur la page d’initialisation de Nextcloud, où il faut définir un administrateur, la base de données, etc… :

C’est finalement logique, puisque c’est une nouvelle instance de Nextcloud… Mais quand j’entre ‘pascal’ pour le compte administrateur, il refuse et me dit que le nom d’utilisateur est déjà pris. OK, c’est vrai (et tant mieux, ça veut dire que mon compte existe toujours, et c’est bien ce que je voulais), je crée donc un utilisateur ‘admin’ pour terminer l’installation.

Du coup, j’ai même droit à une mise à jour… So far so good !

Je me reconnecte en tant que ‘pascal’, retrouve mes dossiers, et je crois alors que “tout est bien qui finit bien”. Hélas, un peu plus tard, je me rends compte que je n’ai pas les droits d’écriture sur mes dossiers ! C’est une photo prise sur le smartphone qui me le signale car le téléchargement échoue. Et c’est confirmé via l’interface web, impossible d’ajouter le moindre fichier à mes dossiers Nextcloud.

J’ai fait quelques recherches rapides sur internet, ça m’a paru vite assez compliqué à dépanner, Nextcloud est apparemment bien sécurisé, et j’ai vite opté pour la solution la plus simple : tout effacer, recréer les répertoires, et y recopier les fichiers précédemment sauvegardés.

Bon, ce n’est pas très glorieux, mais l’opération a été assez rapide, et je n’avais pas envie de me plonger dans les permissions et autres ACLs de Nextcloud ! :shock: Ça peut vite devenir une belle prise de tête !

Conclusion

C’est une bonne chose d’avoir fait cette modification, et pour l’essentiel, tout s’est bien passé.

Non seulement mon disque système microSD ne sera plus sollicité par Docker, mais la sauvegarde sera beaucoup plus simple, puisque le répertoire AppData est déjà partagé par Openmediavault, et une simple tâche avec Rsync fera parfaitement l’affaire.

Ce sera l’objet du prochain article, qui traitera de la stratégie de sauvegarde. C’est important, car en quittant Synology pour ce système Odroid-hc2, je n’ai plus de RAID (un seul HD) et il ne s’agit pas de perdre toute cette belle configuration ! ;)

Openmediavault : installation de Qbittorrent avec OpenVPN

Thu, 21 Jan 2021 11:06:16 +0000

Après avoir installé Nextcloud et Plex, le dernier truc important à installer était un client qBittorrent pour l’utiliser avec une connexion OpenVPN.

Après avoir regardé quelques vidéos, des containers Docker existent, combinant à la fois le client qBittorrent et la connexion OpenVPN, tout semblait parfait.

Hélas, après une première tentative, je me rendais compte que ce qui était proposé ne l’était pas pour une architecture armv7l de mon odroid-hc2 . :(

Heureusement, la situation s’est vite débloquée, grâce à la souplesse de l’Open source.

J’avais répéré la solution MarkusMcNugen/docker-qBittorrentvpn sur dockerhub., hélas uniquement disponible sur une base Debian (Ubuntu 18.04). À tout hasard, je postais sur le projet Github correspondant un petit commentaire sur une issue déjà existante concernant le support ARM7 :

Deux jours plus tard, je recevais un mail d’un certain chrisjohnson00 me proposant de tester son container, un fork compilé en mode “multi-architecture”. 8-)

J’essayais tout d’abord avec Portainer, mais le démarrage échouait avec ce message : Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)

Après quelques recherches, il semble que certains paramètres nécessaires pour ce container ne peuvent être passés via Portainer. Je faisais donc un nouvel essai en utilisant la ligne de commande docker comme suit :

docker run --privileged -d \
		-v /your/download/path/:/downloads \
		-v /your/config/path/:/config  \
		-e "VPN_ENABLED=yes"  \
		-e "LAN_NETWORK=192.168.1.0/24"  \
		-e "NAME_SERVERS=8.8.8.8,8.8.4.4"  \
		-e "VPN_USERNAME=nom_utilisateur_VPN"  \
		-e "VPN_PASSWORD=mot_de_passe"  \
		-e "PUID=XXX"  \
		-e "PGID=XXX"  \
		-e "INCOMING_PORT_ENV=8999"  \
		-p 8080:8080  \
		-p 8999:8999  \
		-p 8999:8999/udp  \
		--sysctl net.ipv6.conf.all.disable_ipv6=0  \
		--name qbittorrent-openvpn  \
		chrisjohnson00/qbittorrent-openvpn:latest

Notes :

On renseigne bien sûr VPN_USERNAME et VPN_PASSWORD avec ceux de votre fournisseur.
La valeur de LAN_NETWORK dépend bien sûr de votre réseau local.
la valeur de PUID et PGID dépend de l’utilisateur qui lance le container.
La commande “privileged -d” est celle que l’on ne peut passer avec Portainer.
Le paramètre “–sysctl net.ipv6.conf.all.disable_ipv6=0” est à priori nécessaire pour MULLVAD, mon fournisseur VPN. Et même chose, impossible avec Portainer.
Pour changer le port de la WebUI de qBittorrent, il faut par exemple changer “-p 8080:8080” en “-p 9090:8080”.

Dernière remarque : lors du premier démarrage, un message d’erreur nous signale que le fichier .ovpn est manquant (VPN_ENABLED=yes). Il faut alors récupérer ce fichier auprès du fournisseur VPN, et le copier dans le répertoire /your/config/path/Qbittorrent/openvpn existant (créé lors du premier démarrage).

Le container démarre enfin, il ne reste plus qu’à se logguer via l’interface à partir de votre navigateur (utilisateur: admin / mot de passe : adminadmin) :

Et voilà, c’était quelque chose que je voulais faire depuis longtemps, et que je pouvais faire avec la baie Synology (en tout cas, je n’avais pas trouvé comment installer un client openvpn standard, celui de Synology n’étant pas à jour (et modifié il me semble). Typiquement le genre de problème que l’on a avec les solutions “propriétaires”.

Il ne me reste qu’à modifier mon container Plex pour y ajouter une nouvelle bibliothèque pointant sur le répertoire de “download” défini pour qBittorrent, et je peux retrouver directement le contenu multimedia téléchargé sur la TV ! :cool:

Enfin, pour en faciliter l’usage dans Firefox, on peut installer l’extension Add Link to qBittorrent WebUI. Il suffira de lui indiquer l’adresse du serveur :

On retrouve ensuite le menu contextuel avec un click droit sur un lien torrent :

Voilà, j’ai à peu près tout ce dont j’avais besoin pour mon NAS Openmediavault.

Il va falloir maintenant penser aux solutions de sauvegarde, ce serait dommage de perdre tout ça : ce sera l’objet d’un prochain article.

Problème au redémarrage

J’ai eu depuis un problème après un redémarrage du container (via Portainer), ou un redémarrage d’OMV : plus moyen d’accéder via l’interface de qBittorrent (WebUI) alors que le container est bien affiché comme démarré. Il me fallait effacer puis recréer le container pour que cela fonctionne à nouveau… :(

En comparant les logs, voilà ce que l’on voyait sur un redémarrage correct :

sudo docker logs -f qbittorrent-openvpn
...
Adding 100 group
groupadd: GID '100' already exists
Adding 997 user
2021-02-06 09:37:44.489980 [warn] UMASK not defined (via -e UMASK), defaulting to '002'
2021-02-06 09:37:44.571608 [info] Starting qBittorrent daemon...
Log file /config/qBittorrent/data/logs/qbittorrent-daemon.log doesn't exist. Creating it...
Logfile created. Logging to /config/qBittorrent/data/logs/qbittorrent-daemon.log
2021-02-06 09:37:45.685073 [info] qBittorrent PID: 189
2021-02-06 09:37:45.710933 [info] Started qBittorrent daemon successfully...

On voit le PID du process qBittorrent, et le message de confirmation…

Et maintenant les logs quand il est impossible de se connecter à la WebUI de qBittorrent :

sudo docker logs -f qbittorrent-openvpn
...
Adding 100 group
groupadd: GID '100' already exists
Adding 997 user
useradd: user 'qbittorent' already exists
2021-02-06 10:21:20.548073 [warn] UMASK not defined (via -e UMASK), defaulting to '002'
2021-02-06 10:21:20.644612 [info] Starting qBittorrent daemon...
Logging to /config/qBittorrent/data/logs/qbittorrent-daemon.log.
start-stop-daemon: matching on world-writable pidfile /var/run/qbittorrent-nox.pid is insecure
2021-02-06 10:21:21.768415 [info] qBittorrent PID:

Le log s’arrête à cet endroit, manifestement le process n’est pas créé. La ligne précédente en donne la raison : il y a un fichier /var/run/qbittorrent-nox.pid qui provoque un problème de sécurité et empêche le lancement du process… Je n’en sais pas plus pour l’instant.

Toujours est-il qu’il suffit de se logguer via la console du container qbittorrent-openvpn (via portainer), et d’effacer le fichier en question :

On remarque d’ailleurs que le PID du fichier est égal au PID du process lancé -2 (198-2=187).

Et voilà, le container peut être redémarré proprement, le process est bien lancé, et l’interface WebUI à nouveau accessible.

On peut aussi effacer ce fichier en ligne de commande. On recherche d’abord le container ID de Nextcloud (commande docker ls), puis on lance un terminal à l’intérieur du container (commande docker exec). Il ne reste alors plus qu’à aller supprimer le fichier souhaité :

Il ne reste plus qu’à relancer le container :

sudo docker restart qbittorrent-openvpn

Voir cette page pour plus d’exemples de commandes docker : on peut même tout enchaîner en une seule commande :

sudo docker exec 6a54133fa769 bash -c "cd /var/run ; ls ; rm qbittorrent-nox.pid"

De là à préparer un script pour automatiser tout ça, y compris le redémarrage du container, il n’y a qu’un pas ! :cool:

Pihole comme DHCP serveur avec la box Orange

Thu, 14 Jan 2021 13:28:43 +0000

J’ai finalement décidé d’utiliser mon serveur Pihole comme serveur DHCP. Il sera donc en charge d’attribuer les adresses IP sur mon réseau local, et se définira en même temps comme serveur DNS. De cette façon, tous les appareils du réseau bénéficieront du filtre anti-pubs de Pihole.

Je précise tout de suite que je suis en IPv4 pour la box comme pour mon LAN, et que IPv6 est désactivé sur la box (voir le commentaire d’Eliastik à ce sujet).

On verra en fin d’article que cela apporte pas mal d’informations sur ce qui se passe sur mon réseau local, j’ai fait des découvertes. :-o

Il aurait été plus simple de définir le serveur DNS au niveau de la box, mais Orange ne permet pas de changer ceux-ci, pour des raisons de VOIP apparemment. Autre problème avec cette box, le décodeur TV d’Orange doit obtenir son adresse de la box (un VLAN est créé semble-t-il), sinon plus de TV ! Ce sont d’ailleurs les deux gros reproches que l’on faire à Orange au niveau de sa box ! :(

Ce dernier problème m’a fait longuement fait hésiter à faire la manip, et puis finalement je me suis décidé à franchir le pas, car parfois le DNS IPv6 de la box (attribué lors de la requête DHCP) prenait le pas sur le DNS IPv4 (définit manuellement sur le PC pour pointer sur Pihole, voir cet article) sans que je sache vraiment pourquoi.

Il était temps de reprendre le contrôle…

Le décodeur TV

Avant d’activer le serveur DHCP de Pihole, il va d’abord falloir s’organiser pour que le décodeur d’Orange obtienne toujours son adresse IP de la box Orange.

Pour cela, on va faire deux choses : limiter au minimum le champ d’adresses disponibles sur la box, puis ajouter l’adresse MAC du décodeur dans la liste des adresses rejetées par le serveur Pihole.

Sur la box, il suffit d’aller dans l’interface de gestion, Configuration avancée, onglet DHCP, et de définir le “scope” comme suit (c’est un exemple) :

Redémarrer la box puis le décodeur, et vérifier que la TV fonctionne. Sur cette même page, récupérer l’adresse MAC du décodeur :

Reste à exclure cette adresse du serveur Pihole. De ce que j’ai lu, Pihole utilise un fork de dnsmasq, on peut donc à priori utiliser ses fonctionnalités. J’ai donc créé un fichier 04-bypass.conf dans /etc/dnsmasqd comme suit :

C’est d’ailleurs ce qui est indiqué dans le fichier 01-pihole.conf créé pendant l’installation :

FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.

ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE.

ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE WITHIN /etc/dnsmasq.d/yourname.conf

Le serveur

On peut maintenant activer le serveur DHCP de Pihole (dans Settings), en s’assurant d’affecter un ‘range’ d’adresses différentes de celle de la box Orange, et en définissant cette dernière comme routeur :

Avant de redémarrer le serveur Pihole, il reste une chose importante à faire, c’est de lui assigner une adresse IP fixe. C’est normalement fait lors de l’installation de Pihole, et je ne sais pas trop où cette information est stockée.

J’ai toutefois procédé comme indiqué sur Raspbian, en renseignant le fichier /etc/dhcpcd.conf. On trouve le nom des interfaces en faisant un ip link, puis on définit ce que l’on souhaite :

interface eth0
static ip_address=192.168.1.18/24
static routers=192.168.1.1
static domain_name_servers=208.67.222.222 208.67.220.220
interface wlan0
static ip_address=192.168.1.17/24
static routers=192.168.1.1
static domain_name_servers=208.67.222.222 208.67.220.220

J’ai donc deux interfaces actives : eth0 pour ethernet, et wlan0 pour le wifi. Les deux serveurs DNS définis sont ceux d’OpendDNS. Au passage, le fichier pour le mot de passe wifi est /etc/wpa_supplicant/wpa_supplicant.conf.

À ce stade, on peut redémarrer le serveur Pihole, et dans la foulée redémarrer le décodeur TV pour vérifier qu’il obtient toujours son adresse de la box, et que la TV fonctionne.

À toutes fins utiles, le service pihole s’appelle pihole-FTL, on peut donc le contrôler avec les commandes suivantes (avec “disable” on l’empêche de redémarrer au boot de la machine) :

$ sudo systemctl status pihole-FTL
$ sudo systemctl stop pihole-FTL
$ sudo systemctl start pihole-FTL
$ sudo systemctl disable pihole-FTL
$ sudo systemctl enable pihole-FTL

Si tout se passe bien, on peut passer au reste des appareils sur le réseau, à savoir mon PC desktop, un PC portable, mon smartphone BQ Aquaris, la TV, etc… Vérifier que tout se passe bien, et éventuellement assigner des baux fixes à chaque appareil :

Sur le PC, on peut vérifier en allant voir le fichier /var/lib/dhcp/dhclient.leases :

On peut aussi forcer le renouvellement de notre adresse IP, ici sur mon portable, avec la commande dhclient -d -nw wlp2s0 (après avoir identifié le nom de l’interface wifi) :

Voilà, tout fonctionne comme attendu. Désormais, tous les appareils sur le réseau bénéficient de Pihole comme bloqueur de pub, c’est plutôt sympa :

On voit que mon serveur odroidhc2 est plutôt bavard : c’est normal, puisque j’ai installé dessus un serveur Nextcloud, et qu’il est accessible depuis internet via un proxy (voir l’installation de Nextcloud sur Openmediavault). Il s’agit en l’occurence de requêtes DNS déjà en cache.

Plus intéressant, on voit que le smartphone est celui qui est qui a le plus de requêtes bloquées !

Pourtant, j’utilise LineageOS, je n’ai aucune appli Google d’installées… Et à y regarder de plus près, un bon nombre de ces requêtes sont bloquées par Pihole ! Un peu inquiétant sur notre vie privée tout ça, je n’ose imaginer ce que fait un smartphone avec tous les services Google d’installés !

Mais il y a encore plus surprenant : Pihole offre des statistiques très intéressantes, et en allant dans “Long-term data - Top Lists”, je vois que la TV Samsung est également très active :

La “Smart TV” est effectivement très smart… un peu trop à mon goût. ;) Du coup, après quelques recherches pour comprendre ce qui se passe, je trouve une “Ad List” spécialement conçue pour filtrer les accès de ces Smart TVs. Voici le lien :

https://raw.githubusercontent.com/Perflyst/PiHoleBlocklist/master/SmartTV.txt

à ajouter dans “Group Management - Adlists” de Pihole, suivi d’un pihole -g pour mettre à jour la liste utilisée par Pihole.

Reste à vérifier que la TV fonctionne toujours correctement avec cette liste active. Je n’ai aucun besoin d’un accès internet sur celle-ci (il n’y a que Plex que j’utilise en local comme media serveur), ce sera donc très bien de lui couper le sifflet.

Voilà, ce changement de serveur DHCP est finalement très bénéfique : non seulement Pihole filtre les publicités, mais il fournit aussi beaucoup d’informations sur ce qui se passe sur votre réseau personnel ! :cool:

Openmediavault - Plex : Dépannage

Thu, 31 Dec 2020 18:10:38 +0000

Hier, j’ai voulu ajouter un nouveau dossier à mon instance docker Plex sur mon serveur Openmediavault . Pour ce faire, il fallait modifier le container docker puisque les dossiers (‘Volumes’ dans la terminologie docker) sont définis à ce moment là.

Mauvaise idée, parce je n’ai jamais pu faire refonctionner l’instance de Plex modifiée ; non seulement l’interface web m’indiquait ce message peu rassurant : “Un problème a été détecté dans un composant au cœur du serveur multimédia Plex”, mais le process ‘Plex Media Server’ prenait 100% de CPU. J’ai fini par arrêter le container.

J’en suis resté là, il était déjà tard, et ce matin, je me suis attaqué au problème, bien décidé à le résoudre… Ça n’a pas été évident, mais j’ai appris quelques trucs que je vais noter et partager ici, comme comment supprimer complètement Plex Media Server, où aller voir les logs, et finalement comment j’ai fini par obtenir la solution.

Au passage, j’ai même installé Emby, un autre media server, car je pensais que je n’allais pas m’en sortir. Voyons tout cela…

Les logs

Je commence par aller voir les logs de docker, histoire de vérifier que le container a bien démarré :

sudo docker logs -f plex

Mais ils ne donnent que peu d’info dans ce cas là. Dommage, car finalement, comme vous le verrez, il s’agissait d’un problème de dépendance de docker sur une librairie comportant un “bug”… :(

Il faut donc aller voir ceux de Plex : ils se trouvent dans le répertoire déclaré pour la configuration lors de la création du container (volume ‘/config’). Voilà ce que ça donnait chez moi pour le log principal :

pascal@odroidhc2:~$ grep ERROR /srv/dev-disk-by-label-DATA/AppData/Plex/Library/Application\ Support/Plex\ Media\ Server/Logs/Plex\ Media\ Server.log
Jan 01, 1970 00:01:28.000 [0xb29ff430] ERROR - Error issuing curl_easy_perform(handle): 28
Jan 01, 1970 00:01:28.000 [0xb29ff430] ERROR - Error parsing content.
Jan 01, 1970 00:01:28.000 [0xb29ff430] ERROR - Error parsing XML: Error parsing file.
Jan 01, 1970 00:01:28.000 [0xb05fc430] ERROR - [Time] Failed to convert '1970-01-01 00:00:01' to epoch.
Jan 01, 1970 00:01:28.000 [0xb05fc430] ERROR - [Time] Failed to convert '1970-01-01 00:00:01' to epoch.
Jan 01, 1970 00:01:28.000 [0xb05fc430] ERROR - Error issuing curl_easy_perform(handle): 28
Jan 01, 1970 00:01:28.000 [0xb05fc430] ERROR - Error parsing content.
Jan 01, 1970 00:01:28.000 [0xb05fc430] ERROR - Exception caught while updating system agent list: Error parsing file
Jan 01, 1970 00:01:28.000 [0xacffe430] ERROR - Error issuing curl_easy_perform(handle): 28
Jan 01, 1970 00:01:28.000 [0xa85fe430] ERROR - [Time] Failed to convert '1970-01-01 00:00:01' to epoch.
Jan 01, 1970 00:01:28.000 [0xacffe430] ERROR - Error issuing curl_easy_perform(handle): 28

On voit que manifestement ça boucle… Après quelques recherches sur le net, le message “Error issuing curl_easy_perform” est connu et sans impact. L’autre message qui aurait du attirer mon attention est celui à propos de l’échec de conversion de la date du 01/01/1970 : ça pue le bug système, genre celui de l’an 2000 !!

Nettoyer Plex

Mais je me suis obstiné à réinstaller Plex encore et encore, en essayant de nettoyer complètement le système auparavant, persuadé que le problème venait de Plex. Il faut bien sûr supprimer le container via l’interface de Portainer, mais ce n’est pas suffisant.

Il faut aussi aller supprimer le dossier/volume de configuration cité précédemment, notamment si l’on veut effacer la base de donnée utilisée par Plex. Ce n’est pas fait par défaut pour simplifier la création d’un nouveau container, et ne pas avoir à réindexer tous vos fichiers media ! À faire vraiment quand on veut repartir de zéro donc…

pascal@odroidhc2:~$ sudo find /srv/dev-disk-by-label-DATA/AppData/Plex -name "*.db"
/srv/dev-disk-by-label-DATA/AppData/Plex/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.blobs.db
/srv/dev-disk-by-label-DATA/AppData/Plex/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db
pascal@odroidhc2:~$ sudo rm -rf /srv/dev-disk-by-label-DATA/AppData/Plex/Library

À force de faire du ménage à la main dans le système, je me suis retrouvé dans l’impossibilité de démarrer un container Plex que je venais de créé ! :( J’avais le message suivant : unable to exec /usr/lib/plexmediaserver…

Là, je ne sais plus trop comment je m’en suis sorti : via Portainer, j’ai vérifié que plus rien de Plex n’apparaissait (y compris dans les images), puis je suis allé dans l’interface d’OMV - Gestionnaire de mises à jour, mis le système à jour, puis dans OMV-Extras - Mises à jour j’ai lancé un “apt clean”. Et puis j’ai redémarré, et créé un nouveau container qui cette fois a pu démarrer, mais toujours avec le même problème.

Emby

À ce stade, je me suis dit qu’il était temps de chercher une alternative à Plex. J’ai vite trouvé Emby, avec un container disponible pour OMV. Restait à voir s’il y avait un client pour ma TV Samsung de 2015. C’était bien le cas, même s’il a fallu l’installer manuellement (non disponible par défaut dans le catalogue de Samsung).

Il faut aller sur cette page, récupérer le fichier tizen.zip, l’extraire sur une clef USB, puis allumer la TV avec la clef connectée : l’installation se fait automatiquement.

L’installation du container sur OMV est classique, j’ai suivi cette video de TDL, mais je commence à bien connaître la création de container, et on peut se débrouiller tout seul en allant sur hub.docker.com, en cherchant Emby, et en suivant les indications (env, volumes, etc…) pour créer le container. C’est assez classique, avec principalement la définition des “share” pour les différentes bibliothèques de media que l’on veut renseigner.

Attention toutefois à l’architecture : elle ne sera pas détectée automatiquement, et il faut bien spécifier celle de votre machine… Dans mon cas, j’ai une architecture 32 bits (armv7l est un processeur 32 bits, et ARMv8 est 64 bits) et l’OS est un Debian Buster :

pascal@odroidhc2:~$ sudo uname -m
armv7l
pascal@odroidhc2:~$ sudo lsb_release -d
Description:	Debian GNU/Linux 10 (buster)

Je dois donc renseigner comme ceci l’image lors de la création du container :

Pour connecter la TV au serveur, il faudra (comme pour Plex), se créer un compte sur le site d’Emby, et rentrer le PIN code affiché sur la TV.

J’ai testé vite fait, ça “fait le taf”, mais c’est moins évolué que Plex, on est plus proche d’un serveur DLNA de base : la recherche d’affiches pour les séries par exemple n’a pas fonctionné quand Plex fonctionne à merveille de ce côté. Je le garde toutefois comme serveur de rechange (container arrêté), au cas où.

Je me suis ensuite remis à la recherche d’une solution pour Plex…

La solution

Je me suis alors dit qu’il fallait que je trouve un moyen d’installer une version plus ancienne du container Plex (j’avais installé la version précédente qui fonctionnait vers mi-Novembre). Je suis donc allé sur le site dockerhub, sur la page de linuxserver/plex. Deux nouvelles versions étaient sorties depuis mi-novembre.

Ne trouvant rien sur une façon de lancer une version précédente, je suis alors allé sur le forum Dicord (qui m’avait déjà bien aidé pour l’installation de Nextcloud et mes problèmes de NAT hairpinning), et j’ai décrit mon problème, terminant en disant “J’ai l’impression qu’il y a un problème avec cette version…”. J’ai très vite eu une réponse me renvoyant sur cette FAQ et confirmant le bug :

Comme l’explique la FAQ, il y a un problème avec une dépendance de docker, un bug dans une librairie… qui semble se produire sur les systèmes 32 bits de Debian Buster. Bingo, ça correspond bien à mon OS ! 8-)

La façon la plus pérenne de résoudre le problème est alors de déclarer le dépot “backport” pour Debian/Buster. C’est d’ailleurs exactement à cela que servent les dépots “backport” : on y trouve des versions corrigées de certaines mises à jour, quand un problème a été identifié.

Voilà donc les instructions à passer, où l’on déclare le backport (avec les clefs de sécurité), puis on met le système à jour, et enfin on demande l’installation de la librairie fautive, à savoir libseccomp2 :

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
 echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
 sudo apt update
 sudo apt install -t buster-backports libseccomp2

Et voilà, le tour est joué, je n’ai plus qu’à réinstaller mon container Plex et tout va se passer comme un charme ! :-D

Conclusion

J’ai commis l’erreur de me focaliser sur Plex, persuadé que l’erreur venait de là. Alors qu’il s’agissait d’un problème avec le container docker, et dès que j’ai cherché dans cette direction, la solution est venue rapidement.

La communauté LinuxServer.io sur Discord est vraiment d’une grande aide. Le lien Discord sur la page de linuxserver/plex est un lien d’invitation pour rejoindre le groupe :

On peut y accéder via le navigateur, ou installer ensuite une application dédiée. Discord permet de créer des salons entre groupes, et d’y faire du chat, de l’audio ou encore de la vidéo, partager son écran, etc…

Discord vient du monde des jeux, est privatif, et gratuit pour ses fonctionnalités de base. Il a été utilisé en France par des établissements universitaires et scolaires lors de la crise du Covid, pour pallier les difficultés techniques des espaces officiels…

Openmediavault : Installation de Nextcloud

Tue, 01 Dec 2020 17:14:36 +0000

Étape importante pour mon nouveau NAS : installer Nextcloud avec un accès externe sécurisé afin de pouvoir y accéder hors de la maison. Pour info, il s’agit de la version 20 de Nextcloud.

Car en plus de fichiers classiques dont un Cloud offre la disponibilité, il y a une autre fonctionnalité que j’apprécie énormément : le téléchargement automatique des photos prises sur le smartphone, chose rendue possible par l’application cliente Nextcloud.

L’accès par internet était donc primordial. J’ai eu plus de mal que prévu, et pas forcément sur l’installation en elle-même (avec Docker et ses containers c’est plutôt bien fait), mais j’ai du faire face à des problèmes de réseau (NAT, DNS…) et le plus dur a été finalement de bien identifier les problèmes, puis de leur trouver une solution.

Mais bon, aujourd’hui tout fonctionne, et je vais pouvoir me débarrasser de mon NAS Synology, et ce sera sans aucun regret, je suis plutôt épaté par Openmediavault et par tout ce qu’il propose.

Je vais donc installer le triptyque Nextcloud-MariaDB-Swag. SWAG ( S ecure W eb A pplication G ateway, qui s’appelait précédemment letsencrypt), inclut un webserver, un reverse-proxy, un client certbot pour la génération de certificats SSL, et enfin fail2ban pour prévenir les intrusions. Plutôt complet donc !

Pour cela, il faut définir un nom de domaine ; comme j’ai un domaine avec ce blog (pled.fr), et que mon hébergeur permet de se créer des enregistrements, j’ai procédé de cette manière.

Hélas, une fois l’installation terminée, il m’était impossible d’accéder à la page web de Nextcloud. D’où venait le problème : configuration ? NAT ? DNS ? J’ai pas mal galéré avant de trouver la solution.

Il s’agissait en fait d’un problème de NAT hairpinning : on ne peut pas communiquer entre deux machines sur le même réseau interne en utilisant les adresses externes. On verra comment régler ce problème.

Bref, voyons un peu tout cela de plus près, et comment tout a fini par tomber en marche… :cool:

Préparation

Voilà ce que donne le schéma général : le reverse proxy et nextcloud tournent sur la même machine, mais cette vue permet de voir la redirection des ports 443 et 80 :

Première chose à faire : on passe l’interface d’administration d’OMV sur le port 8080 afin de libérer le port 80 :

Ensuite, une des premières questions à se poser est celle-ci : ma box dispose-t-elle d’une IP fixe ? Car les enregistrements DNS que l’on va créer vont pointer sur cette adresse, c’est donc très important.

Adresse IP

Orange à priori ne fournit pas d’adresse IP fixe aux particuliers ! Mais heureusement j’ai trouvé cette information :

Orange ne fournit pas d’adresse fixe pour ses contrats grand public. Mais :

Les liaisons Fibre et VDSL ont des adresses “presque fixe”. Elles ne changent que rarement.

Les liaisons ADSL (en voie de disparition) ont des adresses dynamiques.

L’utilisateur ne peut pas forcer une IP strictement fixe.

L’utilisateur peut forcer un changement d’IP depuis son espace client ou l’interface d’administration de sa box (forcer un redémarrage par logiciel)

De plus ce n’est pas nécessaire, même pour atteindre une machine ayant une fonction de “serveur” : disque NAS, caméra, imprimante, serveur web, etc… Il suffit de passer par l’utilisation d’un DNS dynamique.

Dans mon cas, étant en VDSL, je peux considérer que mon adresse IP ne changera que très rarement. Je peux donc me baser sur celle-ci pour définir mon domaine DNS.

Je ne souhaite pas utiliser de DNS dynamique : beaucoup de vidéos d’installation de Nextcloud sur OMV utilisent cette méthode (avec le service duckdns par exemple). Mais comme mon hébergeur me permet de créer mon propre sous-domaine, je voulais vraiment utiliser cette solution, c’est plus propre.

DNS

D’après ce que j’ai pu lire, il faut donc créer deux enregistrements: un enregistrement A qui pointe vers l’adresse IP de la box, puis un enregistrement CNAME qui pointe vers ce “A record” (qui est en fait un simple alias). Alors voilà ce que cela donne dans mon cas :

TypeNomPointe versAxxx.pled.fr1.2.3.4TypeNomAlias deCNAMEnextcloud.xxx.pled.frxxx.pled.fr

On peut vérifier facilement que la résolution du nom en adresse fonctionne avec la commande nslookup par exemple.

pascal$ nslookup nextcloud.xxx.pled.fr
Server:		127.0.0.53
Address:	127.0.0.53#53

Non-authoritative answer:
nextcloud.xxx.pled.fr	canonical name = xxx.pled.fr.
Name:	xxx.pled.fr
Address: 1.2.3.4

Box orange

On va ouvrir les ports 443 et 80 en les redirigeant vers eux-mêmes, soit 443 et 80. Il suffit d’aller sur la box, “Configuration réseau”, puis “Configuration avancée”, et enfin choisir l’onglet NAT/PAT. Ensuite, sélectionner les deux services concernés, et les faire pointer sur le périphérique où tourne Openmediavault :

Voilà, tout est prêt, on peut maintenant installer Nextcloud.

Nextcloud - Mariadb - Swag

La première méthode que j’ai essayé est normalement la plus simple, à savoir utiliser “Stacks”, qui permet de tout installer en une seule fois.

Tout est expliqué sur cette vidéo de Techno Dad Life. Concernant la configuration et les paramètres, On trouve pas mal d’explications et d’exemples de configuration sur cette page, ou encore celle-ci.

Comme j’ai rencontré des problèmes de NAT, j’ai fini par tout installer container par container, mais la méthode “Stacks” est beaucoup plus simple et plus rapide ! C’est donc celle-là que je vais décrire.

Dans Portainer, le gestionnaire Docker d’Openmediavault (voir l’article sur Plex si nécessaire), on clique sur Stacks à gauche, puis sur le bouton “Add stack”. Il ne reste plus qu’à coller le contenu suivant qui définit les 3 containers que l’on souhaite installer.

---
version: "2"
services:
  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud
    environment:
      - PUID=997
      - PGID=100
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config:/config
      - /srv/dev-disk-by-label-DATA/Nextcloud/data:/data
    depends_on:
      - mariadb
    restart: unless-stopped
  mariadb:
    image: linuxserver/mariadb
    container_name: nextclouddb
    environment:
      - PUID=997
      - PGID=100
      - MYSQL_ROOT_PASSWORD=password
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/Nextclouddb:/config
    restart: unless-stopped
  swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=997
      - PGID=100
      - TZ=Europe/Paris
      - URL=xxx.pled.fr
      - SUBDOMAINS=nextcloud
      - VALIDATION=http
      - EMAIL=xxx@yyy.zz
    volumes:
      - /srv/dev-disk-by-label-DATA/AppData/swag:/config
    ports:
      - 443:443
      - 80:80
      - 81:81
    restart: unless-stopped

Quelques remarques sur ce contenu :

J’ai volontairement retiré le définition du port 443 pour le container Nextcloud, car il rentrait en conflit au démarrage avec la définition du même port dans Swag. Comme le port SSL par défaut est 443, Nextcloud fonctionne parfaitement sans avoir à définir le port.
Le PUID et le PGID du compte admin sont à identifier sur votre serveur, comme lors de l’installation de PLEX. Vous pouvez éventuellement créer un compte spécifique “nextcloud” pour cette installation, à vous de voir.
Le port 81 n’est pas nécessaire à ce stade, mais je vais l’utiliser pour “Swag Dashboard”, un “mod” qui permet d’afficher les stats de Swag (voir cet article).
Pour le chemin d’accès aux volumes, j’ai d’abord créé via l’interface d’OMV les dossiers partagés AppData (utilisé pour la configuration des containers), et un répertoire Nextcloud qui sera utilisé par les utilisateurs de Nextcloud. Je peux ainsi accéder facilement à ce dernier avec un partage NFS (ou autre) si je le souhaite.

Ensuite, il faut se connecter en SSH pour créer les sous-dossiers “Nextcloud”, “Nextclouddb” et “swag” qui sont utilisés pour les dossiers “config” des applis, et les faire appartenir au compte admin (le compte utilisé par OMV).

pascal@odroidhc2:~$ cd /srv/dev-disk-by-label-DATA/AppData
pascal@odroidhc2:/srv/dev-disk-by-label-DATA/AppData$ sudo mkdir Nextcloud Nextclouddb swag
pascal@odroidhc2:/srv/dev-disk-by-label-DATA/AppData$ sudo chown -R admin Nextcloud Nextclouddb swag
pascal@odroidhc2:/srv/dev-disk-by-label-DATA/AppData$ ls -l
total 12
drwxrwsrwx+  9 admin users 4096 Nov 22 18:23 Nextcloud
drwxrwsrwx+  4 admin users 4096 Nov 23 14:59 Nextclouddb
drwxrwsrwx+ 12 admin users 4096 Nov 23 19:00 swag

En ce qui concerne les noms de domaine, j’ai donc utilisé mon enregistrement de type A pour le paramètre URL, et le sous-domaine “nextcloud” du CNAME pour le paramètre SUBDOMAINS. La validation est elle de type http.
Concernant le port pour swag, j’ai bien mappé le port 443 (ce que je vais recevoir du router de la box) vers le port 443 (celui sur lequel écoute l’instance Nextcloud).

Voilà, il ne reste plus qu’à cliquer sur “Deploy the stack” pour que tout s’exécute et s’installe. Cela prend un peu de temps, puisque les logiciels vont être téléchargés, puis installés et configurés.

Ce n’est pas complètement terminé, il reste à finaliser l’installation en modifiant quelques fichiers de configuration.

Swag : comme je souhaite utiliser un sous-domaine (nextcloud.xxx.pled.fr) et non pas un sous-dossier (xxx.pled.fr/nextcloud) pour accéder au serveur, il va falloir “activer” le fichier d’exemple :

cd /srv/dev-disk-by-label-DATA/AppData/swag/nginx/proxy-confs
cp nextcloud.subdomain.conf.sample nextcloud.subdomain.conf
sudo chown -R admin nextcloud.subdomain.conf

Info

Avec une version plus récente de Nextcloud (v23 par exemple), modifier le fichier config.php comme indiqué ci-dessous est à faire APRÈS avoir passé la page d’installation dans le navigateur, ce qui permet de finir l’installation, et télécharger tous les fichiers nécessaires. Avant, le fichier n’est pas encore présent.

Nextcloud : il faut éditer et modifier/ajouter quelques paramètres dans le fichier /srv/dev-disk-by-label-DATA/AppData/Nextcloud/config/www/nextcloud/config/config.php : vérifiez que ceux listés ci-dessous existent et adaptez-les à votre configuration.

Pour une bonne définition du réseau pour l’entrée trusted_proxies, il est recommandé d’utiliser la notation CIDR (voir cet article). Grâce à Portainer, on peut voir le réseau utilisé par Nextcloud et/ou Swag :

On indique donc ce réseau en notation CIDR pour que Nextcloud soit content (sinon, laisser ‘swag’) :

  'trusted_proxies' =>
  array (
    0 => '17Z.20.0.0/16',
  ),
  'trusted_domains' =>
  array (
    0 => '192.168.1.30:443',
    1 => 'nextcloud.xxx.pled.fr',
  ),
  'overwrite.cli.url' => 'https://nextcloud.xxx.pled.fr',
  'overwritehost' => 'nextcloud.xxx.pled.fr',
  'overwriteprotocol' => 'https',

il faut vérifier que tout démarre bien. Il faut se connecter en SSH sur la machine, et entre les commandes suivantes :

sudo docker restart swag
sudo docker restart nextcloud
sudo docker logs -f swag
sudo docker logs -f nextcloud

Pour swag, vérifier que vous voyez bien les messages suivants : " Congratulations! Your certificate and chain have been saved at…". Pour swag et nextcloud, vous devez voir " [services.d] starting services" suivi de " [services.d] done" en fin de log. Si ces deux messages s’affichent, c’est plutôt bon signe.

Du côté de l’interface de Portainer, on doit voir les containers démarrés et actifs :

Voilà, on doit maintenant pouvoir afficher la page de première connexion de Nextcloud. C’est là que j’ai eu des problèmes avec mon histoire de NAT. J’y reviens tout de suite, mais terminons rapidement l’installation de Nextcloud :

Sur l’écran qui s’affiche ci-dessous, il suffit de remplir les champs correctement. J’ai également décoché l’installation des “applications recommandées”, je n’installerai que ce dont j’ai besoin au fur et à mesure.

Créer un compte admin (choisissez le nom que vous voulez, c’est celui qui aura les droits d’administration) et lui donner un mot de passe.
Pour la base de données, laisser “/data” pour le dossier de la DB, choisir MySQL/MariaDB, le “Database user” est “root”, le “Database password” est celui que l’on a mis dans le fichier de configuration “Stack” ( MYSQL_ROOT_PASSWORD), idem pour le nom de la base de donnée ( nextclouddb), et enfin on remplace localhost par " mariadb" (le nom du container en tant que nom DNS).
Comme indiqué juste en-dessous de “mariadb”, on peut aussi préciser le numéro de port. Dans mon cas, comme j’ai fait l’installation container par container, j’avais défini un port pour mariadb (3306, le port par défaut), j’ai donc remplacé" “localhost” par mon adresse IP locale suivie du numéro de port (soit 192.168.1.30:3306). Ce n’était sans doute pas nécessaire, puisque ce sont finalement les valeurs par défaut, mais cela permet de comprendre ce que l’on fait !

Voilà, cliquer sur les quelques écrans de présentation qui suivent, et Nextcloud est installé et prêt à fonctionner !

NAT hairpinning

Revenons donc au problème qui m’a occupé bien des heures. Non pas qu’il soit compliqué à résoudre, mais j’ai mis un certain temps à comprendre ce qui se passait.

Donc lorsque je voulais afficher la page https://nextcloud.xxx.pled.fr pour finaliser l’installation de Nextcloud, je partais en timeout :

J’avais tout vérifié : les ports ouverts avec nmap, les noms de domaine avec nslookup, tout semblait correct. J’ai fini par réinstaller tous les containers un par un, pour chaque fois arriver au même résultat. Et puis j’ai eu l’idée de prendre mon smartphone, de couper le wifi, et de tester l’URL de Nextcloud en passant donc par le réseau GSM : et là, ça marchait !! :razz:

Restait à comprendre le problème, et là c’est un type sur Discord (en bas de la page de Swag setup, il y a une invitation pour rejoindre le groupe) avec qui j’avais vérifié ma config swag quand je pensais que c’était peut-être la cause du problème, qui m’a parlé de ce désormais fameux “NAT hairpinning” !

Alors qu’est-ce qui se passe ? quand on envoie un message TCP sur le réseau, il y a une adresse destination et une adresse source : quand je suis sur mon PC, l’adresse source est donc mon adresse locale (192.168.x.y). Le message par vers la destination (le nom DNS du serveur Nextcloud), soit une fois le nom DNS résolu en adresse IP, l’adresse de ma box. Et la box, voyant un message TCP arriver de l’extérieur avec une adresse source ET destination locale… eh bien bloque tout simplement ce message le message : c’est apparemment une limitation du protocole NAT. Voilà ce qu’explique la page wikipedia sur le sujet :

le hairpinning décrit une communication entre deux machines placées derrière le même routeur NAT qui utilisent l’adresse IP de leurs points de sorties pour communiquer. Tous les mécanismes de NAT ne supportent pas cette configuration de communication.

Et donc soit vous avez un router évolué qui permet de définir une règle pour éviter ce problème (ce qui n’est pas le cas du router de box Orange), soit le plus simple est d’utiliser un serveur DNS local.

Or il se trouve que j’ai installé il y a peu un serveur Pihole sur mon Raspberry. J’avais fait ça pour le fun (ou presque), mais finalement cela va m’être très utile, puisque Pihole fait office de serveur DNS. Il me suffit alors de définir deux entrées pour mes deux enregistrements DNS :

Et voilà ! Après un rechargement de la page, Nextcloud s’affiche enfin correctement dans le PC et je peux finaliser l’installation ! :cool:

Pour être complet, j’ai bien entendu eu le même problème avec le smartphone et l’application android Nextcloud. Sauf que là, quand j’ai voulu passer ma connexion wifi en mode “statique” (au lieu de DHCP) afin de définir mon propre DNS, cela ne fonctionnait toujours pas. Je n’ai pas creusé plus que ça, j’ai installé Blokada, ajouté mon propre DNS avec mon serveur Pihole en primaire, et celui de Google en secondaire, pour quand je suis en extérieur. Ça a l’air de bien fonctionner comme ça.

Conclusion

Cette installation n’aura pas été facile. Elle aurait pu l’être sans ce problème de NAT, qui m’a bien pris la tête. Comme toujours, à force de réinstaller, de tester, regarder les logs de docker, j’ai appris plein de choses (comme des commandes ‘docker’). C’est donc bénéfique globalement.

Et maintenant, j’ai un Nextcloud dernière version qui tourne sur une machine suffisamment puissante. Contrairement à ma baie Synology qui manque singulièrement de puissance CPU, et sur laquelle installer Nextcloud est une plaie.

C’est d’ailleurs la raison principale de ce changement de NAS : passer sur un système open-source, afin d’avoir un choix plus vaste de logiciels.

Il me reste maintenant à penser à la sauvegarde de tout ça (car je n’ai plus de RAID sur mon Odroid-HC2 !). Et puis ce sera le tour d’un client Open VPN, chose que je ne pouvais tout simplement pas installer sur la baie Synology.

Openmediavault - Installation de PLEX server

Wed, 11 Nov 2020 17:34:56 +0000

Suite de l’installation d’Openmediavault : cette fois, il s’agit d’installer PLEX Media Server, solution bien pratique pour diffuser le contenu media (films, séries, documentaires) du NAS vers la TV Samsung, qui intègre un client Plex.

Pour ce faire, on va utiliser Docker et Portainer, qui simplifie l’installation. Il va tout de même y avoir quelques valeurs à saisir correctement, mais rien de très compliqué non plus, et tout a fonctionné du premier coup, c’est bien là l’essentiel.

J’ai en fait suivi une vidéo (en anglais) pour cette installation. Je la retranscris ici en mode texte avec les captures d’écran nécessaires, et en français. Il y a un petit changement par rapport à la vidéo concernant le répertoire de configuration de Plex, qu’il n’est plus nécessaire de créer car il est géré par l’installation. La version Plex d’installée est la 1.20.4.3517 .

C’est parti…

Dossiers partagés

Avant d’installer Plex, on va d’abord créer des dossiers partagés. Pendant l’installation d’OMV, j’avais partagé tout mon disque DATA (OMV-DATA), de manière à pouvoir y accéder depuis mon PC.

Je vais donc créer des sous-répertoires à ce dossier partagé, pour l’utilisation de Plex :

J’ai donc créé les trois dossiers dont j’ai besoin : Films, Series et Docus. Lors de la création de ceux-ci, j’ai ajouté un chemin relatif pour créer des sous-répertoires par rapport à OMV-DATA (qui est celui que je partage en NFS), et j’ai accordé à tous ces dossiers les droits Lecture/Ecriture :

Passons maintenant à l’installation du container Plex.

Docker et Portainer

Info

Au sujet de Docker, si vous l’installez, il peut être utile de le déplacer hors du disque système, si ce dernier est sur une carte microSD comme c’est mon cas avec mon odroid-hc2 (et tous les SBC comme les Raspberry & Co). Et mieux vaut le faire dès le départ, c’est plus simple.

Voir cet article : Openmediavault : déplacement de Docker.

Pour installer ces deux-là, rien de plus simple : on va dans OMV-Extras (qui ont été précédemment installés par le script d’installation), et on installe les deux programmes :

Ensuite, on ouvre Portainer (bouton à droite de l’installation de Portainer), qui s’ouvre dans un nouvel onglet, et on saisit un mot de passe. Puis on choisit “Local” pour la gestion de l’environnement Docker, et on se connecte. On clique sur la petite baleine bleue, et on arrive sur notre “Dashboard”. Il y a déjà un Container qui tourne, c’est Portainer (qui est donc lui-même un container dans Docker).

Plex

On clique sur Container, puis sur le bouton " + Add container". Là, il va falloir aller chercher l’adresse du Container Plex. On ouvre alors un nouvel onglet dans notre navigateur, et on rentre l’adresse hub.docker.com et on cherche “linuxserver/plex” :

On arrive sur alors sur la page de Linuxserver.io (qui fournit des containers) pour PLEX :

C’est à partir des informations de cette page qu’il va falloir saisir les paramètres de configuration pour notre futur container Plex. C’est la partie la plus fastidieuse, mais finalement assez simple. Sur cette page descriptive du container Plex, on trouve donc un peu plus bas les infos suivantes :

Ce sont toutes ces informations qu’il va falloir saisir en créant notre container Plex (sauf PLEX_CLAIM) afin de pouvoir ensuite la démarrer. Une dernière chose à faire, c’est de noter l’UID et le GID pour le compte admin de notre propre NAS. On se loggue donc en SSH sur le serveur, et on tape la commande suivante :

pascal@odroidhc2:~$ id admin
uid=997(admin) gid=100(users) groups=100(users),996(openmediavault-admin)
pascal@odroidhc2:~$

Retour dans l’onglet “New container” ouvert précédemment, on commence par lui donner un nom et indiquer le chemin de l’image ci-dessus :

Puis en bas de la page, on clique sur “Env”, et sur “+ add environment variable” plusieurs fois pour ajouter nos variables (en appliquant bien nos propres valeurs pour UID et GID) :

Même chose pour Network où l’on choisit “host” dans la liste :

Pour les Volumes, il va falloir définir chaque répertoire avec le chemin absolu (voir plus haut), en ayant coché “Bind” auparavant :

Info

Dans la vidéo, un dossier Config est créé et destiné aux fichiers de configurations de Plex. Cela ne sert plus à rien, le container va créer son propre répertoire “config”. On peut le retrouver en éditant le container créé et en allant voir les Volumes : chez moi, le dossier est créé dans /var/lib/docker/volumes/ec75ef70e88d3dbfed36925d274292439931f9ff77c88dde055abb9bbf41ae6b/_data. Ça peut servir pour aller voir les logs de Plex en cas de souci…

Et enfin , on modifie le mode “Restart” comme indiqué en mode “Unless stopped” :

Voilà, tout est configuré, il ne reste plus qu’à cliquer sur le bouton " Deploy the container". Votre instance Plex est désormais installée et opérationnelle !

Il ne reste plus qu’à copier des vidéos dans vos dossiers partagés (dans mon cas, via le partage NFS que j’ai mis en place pendant l’installation d’OMV. Puis de lancer l’interface de Plex pour la première fois en ouvrant l’adresse suivante : http://192.168.1.X:32400/web/index.html

Il faudra un peu la configurer, choisir les dossiers Media, etc… Rien de très compliqué, et ce n’est pas l’objet de cet article.

Enfin, sur la TV, je me suis déconnecté de mon instance existante (sur la baie Synology), puis reconnecté avec l’adresse mail du nouveau compte Plex que j’ai créé pour cette occasion. Le “Plex client” de la TV vous demande alors de rentrer un code :

Il suffit alors de taper l’adresse indiquée http://plex.tv/link et de saisir le code pour que le client de la TV se synchronise avec le nouveau serveur.

Et voilà, le nouveau serveur PLEX est prêt ! Reste à recopier ma vidéothèque qui est toujours sur la baie Synology et aussi à automatiser une solution de backup avec Rsync vers mon PC local, puisque sur ce nouveau NAS, je n’ai pas de RAID. Ce sera l’objet d’un prochain article.

ODROID-HC2 - Installation d'Openmediavault

Sun, 08 Nov 2020 16:22:40 +0000

Ça faisait longtemps que je voulais remplacer ma baie Synology par un système ouvert, à savoir openmediavault, " The open network attached storage solution". Restait à savoir sur quel matériel faire tourner ce serveur, l’objectif étant aussi de minimiser le budget : ces baies propriétaires comme Synology, Qnas, restent tout de même assez chères, quand on y ajoute le prix des disques durs.

Il y a bien les NAS Kobol qui m’avaient tapés dans l’œil, projet open-source proposant des baies physiques (open hardware) sur lesquelles on peut faire tourner Armbian ou Syncloud, Openmediavault ou encore Nextcould. Mais là en plus du prix (300$ + le port), le produit est indisponible depuis plusieurs mois.

Après avoir d’abord pensé à utiliser le populaire Raspberry 4, j’ai finalement opté pour un Odroid-HC2. D’abord parce qu’il dispose d’un contrôleur SATA, un vrai contrôleur disque, ce qui préférable à la solution USB d’un Raspberry. Ensuite parce que le processeur est nettement plus puissant.

Enfin parce que j’aime bien la conception : le fait de pouvoir insérer un disque dur 3"½ dans le rail, permet avec une coque de n’avoir au final un seul boîtier, contrairement à un Raspberry où l’on se retrouve forcément avec un disque externe. C’est tout de même plus pratique.

Évidemment, je fais le choix d’un disque unique, pas de baie RAID comme dans les NAS du marché. Mais avec un backup via le réseau sur mon PC où j’ai de la place en stockage, ce sera parfait. C’est le principe KISS ! (Keep It Simple, Stupid). :cool:

Voyons voir la mise en œuvre et l’installation d’Openmediavault, la première étape de mon future NAS. Il s’agit de la version 5.5.15-1. Car j’ai ensuite l’intention d’installer OpenVPN, un serveur NextCloud, PLEX media server, et sans doute un logiciel de torrent. Ce sera l’objet d’autres articles.

Hardware

Info

OCT 2021 : À l’époque je n’ai pas fait attention à l’architecture (32 bits ou 64 bits). Ce NAS est en x32 (processeur armv7l) et de nos jours il est tout de même préférable d’utiliser une architecture x64 (il y a des problèmes de limitation en x32, voir cet article). Donc même si je suis content de ce NAS, si c’était à refaire, je ne le choisirais pas.

Comme j’avais un HD 3"½ en stock de 1To, c’était l’occasion de l’utiliser. Pour info, le HC2 permet d’utiliser ce type de disque, quand le HC1 n’autorise que les disques de 2"½. Il ne restait plus qu’à commander le matériel.

Pour ce faire, je suis allé sur le site odroid.fr, qui permet de payer en euros, et d’inclure la TVA dans le prix, ce qui évite les mauvaises surprises à la douane (tout est envoyé d’Angleterre je crois). Bref, alimentation, carte SD 8 Go, coque et port compris, j’en ai eu pour un peu moins de 100 € (97,95 €).

L’assemblage est on ne peut plus simple (voir photo), il ne reste plus qu’à installer openmediavault.

Installation d’OMV

Le premier problème est de trouver la bonne image OS à récupérer. Le lien des images OMV toutes prêtes vous renvoient vers un document expliquant qu’il faut utiliser maintenant une autre méthode, le nombre de SBD ( S ingle B oard C omputer) ne cessant de croître, et qu’il est impossible de fournir une image toute prête pour chaque modèle de SBC.

On arrive donc sur cette page du forum OMV, où il faut choisir Installing OMV5 on Armbian Buster. Buster est la version recommandée pour OMV sur ce genre de carte. Ce dernier lien affiche la documentation intitulée “Getting Started with OMV Addendum A: Installing OMV5 On Armbian SBC’s”. Commencer par la télécharger localement comme il est demandé, afin de l’ouvrir avec votre lecteur de PDF préféré (d’ailleurs les hyperliens de la doc ne fonctionnaient pas avec l’affichage du PDF dans Firefox !).

Dans “Supported Devices”, il faut cliquer sur le lien Armbian Download Page. Sur la page qui s’affiche, on trouve finalement notre modèle :

On clique sur l’image, et on arrive enfin sur la page recherchée. Ici, il faut choisir Buster qui offre une meilleure compatibilité avec OMV :

Il ne reste qu’à suivre les instructions, à savoir dézipper le fichier avec 7-Zip (extension .xz). Sur Ubuntu, il suffit de passer la commande suivante pour installer 7-Zip :

sudo apt install p7zip-full

Puis pour extraire l’archive :

7z e Armbian_20.08.1_Odroidxu4_buster_legacy_4.14.195.img.xz

On récupère alors un fichier .img qu’il va falloir flasher sur la carte microSD avec Balena Etcher, dont l’utilisation est vraiment simplissime :

Voilà, tout est prêt pour le premier démarrage : insérer la carte microSD dans l’Odroid, assurez-vous d’avoir bien raccordé le boîtier au réseau (c’est requis pour l’installation), puis brancher l’alimentation. Les trois LEDs doivent s’allumer (une rouge, une verte et une bleue qui doit se mettre à clignoter quand le réseau est activé).

Le temps de se faire un café, et l’on va pouvoir se connecter en SSH sur la machine. Pour trouver l’adresse IP, vous pouvez aller sur votre Box et regarder les adresses allouées (DHCP). Un nouveau client a du apparaître. Sinon, sous Linux, on peut faire un nmap tout simple (à adapter à votre réseau) :

pascal$ sudo nmap -sn 192.168.1.0/24
...
Nmap scan report for 192.168.1.30
Host is up (0.00088s latency).
MAC Address: 00:1E:06:37:0D:45 (Wibrain)
...

Pour info, Wibrain est le nom de la boîte qui est devenue ensuite Hardkernel qui fabrique les Odroid… Voilà, j’ai mon adresse, et je vais même aller dans l’interface de la Box pour lui assigner cette adresse, afin qu’elle ne change pas, c’est plus simple comme ça (Baux DHCP statiques). Puis on se connecte en SSH sur le serveur avec le compte admin (le mot de passe par défaut est 1234) :

ssh admin@192.168.1.30

La première chose demandée est de changer le mot de passe, normal. On crée ensuite un autre compte (avec la permission sudo) à utiliser de préférence à root. Ensuite, il s’agit de mettre le système à jour, suivi d’un redémarrage :

sudo apt update
sudo apt upgrade
reboot

On attend le redémarrage, puis on se reconnecte (avec le nouveau mot de passe. J’en profite pour fignoler et changer le nom de la machine puisque par défaut c’est “odroidxu4” :

sudo hostnamectl set-hostname odroidhc2

Puis on lance l’installation d’openmediavault proprement dit, à l’aide d’un script qui va tout configurer :

wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

J’ai du taper la touche “Entrée” pour que l’on me demande mon mot de passe, sinon il ne se passait rien ! L’installation peut prendre jusqu’à 30 minutes selon la doc… Avec le HC2, ça a pris à peine une dizaine de minutes. Le système va redémarrer tout seul à la fin de l’installation.

Toujours bon à savoir, la doc précise que Network Manager a été retiré des machines SBC qui tournent OVM pour la raison suivante : incompatibilité avec Portainer et Docker (Portainer facilite l’utilisation de Docker).

Et on passe enfin en mode graphique : dans votre navigateur préféré, taper l’adresse de la machine, et identifiez vous avec le compte “admin” et le mot de passe “openmediavault” :

Configuration

Il va maintenant falloir suivre l a doc d’installation d’OVM 5 (Getting started with Openmediavault 5) que l’on va également télécharger en local. Puis on l’ouvre en allant directement au chapitre “Initial Configuration”.

On va suivre la documentation pour régler certains paramètres : entre autres changer le mot de passe, et plus globalement passer en revue les sections qui nous intéressent dans le menu de gauche. Si l’anglais de la doc vous rebute, il y a des vidéos qui expliquent tout ça dont certaines en français, comme celle-ci par exemple.

On va en fait régler la config de base, monter le disque, etc… À noter dans “Paramètres généraux”, la Déconnexion automatique est réglée à 5mn, c’est pas mal de la passer à 1 jour, sinon c’est plutôt gênant (enfin, c’est selon vos préoccupations de sécurité !). En profiter pour changer le mot de passe par défaut dans l’onglet d’à côté.

Côté Plugins, j’installe openmediavault-resetperms 5.0, qui est bien pratique pour visualiser quels plugins utilisent quels dossiers partagés (vu dans une vidéo).

Dans “Disques”, on sélectionne notre HD et on l’efface. Puis dans “Système de fichiers” on crée et on formate le disque avec un label DATA (par exemple). Puis on le monte. Enfin, on va dans “Dossiers partagés” et on partage ce disque en donnant les droits de Lecture/Écriture à tout le monde (avec le nom OMV-DATA par exemple). Etc… À la fin, j’ai ceci :

J’ai pour ma part opté pour un partage NFS sur tout le disque DATA (soit tout le HD SATA, la carte microSD étant réservée au système), plus adapté à mon PC Ubuntu que SMB. Dans la partie NFS, je l’active, puis crée un partage en indiquant l’adresse IP de mon PC, et en accordant les droits Lecture/Écriture :

Voilà, je peux monter ce partage à partir de mon PC Ubuntu. Le mount via /etc/fstab fonctionne parfaitement, et c’est doute la façon la plus simple de procéder :

Problème NFS avec Nautilus

À noter qu’à partir de Nautilus, le partage était bien vu dans “Autres emplacements”, mais l’accès refusé :

En fait, il s’agit d’un problème de port utilisé. Si je regarde les journaux systèmes côté OMV, je vois ceci :

Il s’agit d’un problème de sécurité, par défaut un serveur NFS n’accepte que les ports inférieurs à 1024. Il faut donc ajouter une option appelée “insecure” pour qu’il accepte des ports plus élevés. On la voit dans les options du partage :

Mais alors, ça devrait fonctionner ? En fait, non, parce que Nautilus utilise les “pseudos filesystem” de NFSv4, ce qui n’est pas le cas du mount dans /etc/fstab.

Pour résoudre lce problème, il faut se connecter en ssh sur le serveur OMV, éditer le fichier /etc/exports, et ajouter l’option “insecure” aux lignes sous la partie # NFSv4 - pseudo filesystem root :

$ cat /etc/exports
# This file is auto-generated by openmediavault (https://www.openmediavault.org)
# WARNING: Do not edit this file, your changes will get lost.

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
/export/OMV-DATA 192.168.1.20(fsid=d725df26-36b0-4925-b9ca-3c65fa1b7572,rw,subtree_check,insecure)

# NFSv4 - pseudo filesystem root
/export 192.168.1.20(ro,fsid=0,root_squash,no_subtree_check,hide,insecure)

Si l’option était bien indiquée pour le premier lien (correspondant à l’interface graphique d’OMV), j’ai du rajouter l’option pour la partie sous NVFv4. Il ne reste plus qu’à redémarrer le service NFS :

$ sudo systemctl restart nfs-kernel-server

Et voilà, je peux accéder directement au partage via Nautilus si je le souhaite :

Ce premier partage me servira à copier les fichiers facilement à partir de mon desktop Ubuntu sur le NAS OMV.

Conclusion

À ce stade, je remarque que l’interface d’OMV est une interface d’admin pure et dure, à aucun endroit je ne peux créer un fichier de test, histoire de tester mon partage NFS. Il me faut soit le faire à partir du client Ubuntu, soit connecté en SSH sur l’Odroid-hc2, en allant dans le répertoire /exports/OMV-DATA.

J’apprends aussi (à mes dépends) que OMV fonctionne avec une base de données et qu’il vaut mieux éviter de faire des changements en se connectant directement sur la machine hôte, par exemple pour effacer un répertoire partagé. C’est ce que j’ai fait, et là, le répertoire était toujours affiché dans OMV, impossible de l’effacer. J’ai fini par tout réinstaller !

Ce n’est pas interdit pour certaines commandes (comme le redémarrage d’un service ci-dessus), mais il faut savoir ce que l’on fait. En fait, tout ce qui touche la configuration d’OMV doit être dans la database, et des modifs directes sur le système casseront ce mécanisme.

Voilà, ce sera tout pour cette première étape. La suivante, ce sera d’installer PLEX server, et pour cela utiliser Docker. C’est bien, j’ai déjà entendu parlé de Docker sans jamais l’utiliser. Ce sera l’occasion de rentrer dans ce monde de “containers” (conteneurs logiciels en français) qui permettent entre autres de simplifier l’installation.

Ce sera pour le prochain épisode.

Info

Au sujet de Docker, si vous l’installez, il peut être utile de le déplacer hors du disque système, si ce dernier est sur une carte microSD comme c’est mon cas.

Voir cet article : Openmediavault : déplacement de Docker

Indexation Baie Synology : Installation de SynoIndex Watcher

Fri, 22 May 2020 10:01:39 +0000

Troisième article et troisième solution pour l’indexation des fichiers sur la baie Synology ! En effet, si l’on passe par NFS pour y copier nos fichiers multimédia, les fichiers ne sont pas indexés automatiquement, et certaines applications risquent de ne pas les voir… Ce qui peut être gênant.

La dernière solution que j’avais documentée, à savoir Synology-mediamon, pose problème à son tour : le process ne se lance pas au démarrage (bug), et de plus crash régulièrement, sans doute à cause d’un problème de caractère dans le nom du fichier indexé… Ce script n’a pas l’air d’être suivi, et n’a pas bougé depuis 4 ans, on ne peut plus vraiment compter sur lui.

J’ai donc regardé à nouveau la situation de ce côté, et de site en site je suis tombé sur un nouveau script appelé Synoindex Watcher, qui a l’air plus récent et semble maintenu.

L’installation est facile, on peut même générer un fichier de configuration si l’on a des besoins spécifiques, ça m’a donc l’air pas mal du tout ! Voilà les infos pour l’installer, sinon tout est expliqué et documenté (en anglais) sur la page du projet github.

Les caractéristiques du script sont répertoriées comme suit :

Léger : pas besoin d’installer de packages Synology supplémentaires. On verra qu’il faut tout de même installer pip.
Intelligent : Ne s’exécute que si un fichier a été ajouté/supprimé/renommé.
Compatible avec Python 2 comme Python 3 (version minimum testée 2.7).

Installation

Pour l’installation, il faut se connecter en SSH à la baie Synology. Il est recommandé d’utiliser pip pour l’installation. Pip n’est pas installé par défaut, mais il s’installe avec la commande suivante :

$ wget https://bootstrap.pypa.io/get-pip.py -qO - | sudo python

Ce qui donne à l’écran :

Info

Vous remarquerez l’avertissement concernant la version de Python 2.7 qui ne sera plus supportée par pip en janvier 2021. C’est un problème Synology, car sur ma machine, les deux versions de Python (2.7 et 3) sont installées : mais si je tape python --version dans un terminal, j’obtiens la version 2.7 en réponse.

Il semble que ce soit parce que beaucoup de scripts système Synology dépendent encore de la version 2.7… Il y aura toujours moyen de contourner ce problème, il y a des pistes sur cette page, mais inutile de s’en préoccuper pour l’instant (on va pouvoir installer Synoindex Watcher, donc tout va bien). Synology devrait logiquement mettre à jour son système pour ne dépendre que de Python 3 ? Wait & See…

L’installation du module Synoindex Watcher se fait alors par cette commande :

$ sudo python -m pip install --upgrade synoindexwatcher

NOTE : Cette même commande peut être utilisée pour mettre à jour le script si une nouvelle version est disponible.

Par défaut, les dossiers suivants sont surveillés : /volume1/music, /volume1/photo et /volume1/video. Cela peut être modifié soit en ajoutant des arguments à la ligne de commande, soit en créant un fichier de configuration (voir plus bas). Voilà, il ne reste plus qu’à lancer le script pour vérifier son fonctionnement.

pascal@DiskStation:~$ python -m synoindexwatcher
2020-05-22 10:18:53,487 INFO Adding watch for path: /volume1/music
2020-05-22 10:18:54,624 INFO Adding watch for path: /volume1/photo
2020-05-22 10:18:54,642 INFO Adding watch for path: /volume1/video
2020-05-22 10:18:55,561 INFO Waiting for media file changes...

Ici, on voit que le script démarre bien (c’est déjà ça!), active le monitoring des fichiers indexés, mais ce serait mieux de tester si l’indexation fonctionne comme attendu. On va le faire en ajoutant le mode DEBUG :

pascal@DiskStation:~$ python -m synoindexwatcher --loglevel=DEBUG
...
2020-05-22 10:16:06,258 INFO Waiting for media file changes...
2020-05-22 10:16:28,212 DEBUG Calling 'synoindex -d /volume1/video/Films/Docu1.mkv'
2020-05-22 10:16:28,339 DEBUG Calling 'synoindex -a /volume1/video/Docus/Docu1.mkv'

Une fois le mode DEBUG lancé (très verbeux), on voit bien que j’ai effacé (-d) le fichier Docu1.mkv du répertoire “Films” et que je l’ai ajouté (-a) au répertoire “Docus”. Tout fonctionne donc à merveille.

Il y a pas mal d’options disponibles indiquées sur la page du projet. Je ne vais pas les détailler ici, celles par défaut me conviennent, les trois répertoires par défaut (music, photo, video) sont bien monitorés.

À noter tout de même que l’on peut générer un fichier de configuration de manière à faciliter la configuration que l’on souhaite. Cela se fait par la commande suivante :

$ python -m synoindexwatcher --generate-config | sudo tee /usr/local/etc/synoindexwatcher.conf

On obtient donc un fichier synoindexwatcher.conf qu’il suffira d’éditer pour configurer aux petits oignons notre configuration. Il faudra néanmoins le préciser au démarrage du script par l’option suivante :

$ python -m synoindexwatcher --config=/usr/local/etc/synoindexwatcher.conf

Reste à automatiser le démarrage. Cela se fait très facilement par les deux commandes suivantes :

$ python -m synoindexwatcher --generate-init | sudo tee /usr/local/etc/rc.d/S99synoindexwatcher.sh
$ sudo chmod a+x /usr/local/etc/rc.d/S99synoindexwatcher.sh

NOTE : Si vous avez créé un fichier de configuration particulier, il faudra modifier ce script pour y ajouter le paramètre --config et le chemin d’accès au fichier de configuration.

Voilà, tout doit fonctionner. J’ai testé un redémarrage de la baie Synology, le script est bien lancé au redémarrage. 8-)

Il y a un message d’erreur connu, pas vraiment lié au script d’ailleurs, mais plutôt à une limitation système de Synology :

OSError: [Errno 28] No space left on device

Si vous obtenez ce message, cela ne signifie pas qu’il n’y a plus de place sur le périphérique, mais qu’il n’y a pas assez de “inode-watchers” pour surveiller vos fichiers media.

Pour le corriger temporairement, taper ceci en étant root ::

# echo 204800 > /proc/sys/fs/inotify/max_user_watches

Mais cela ne règle le problème que jusqu’au prochain reboot. Pour corriger définitivement le problème, il faut ajouter la ligne fs.inotify.max_user_watches = 204800 au fichier /etc/sysctl.conf.

Voilà, les premières impressions sont bonnes, ça fonctionne nettement mieux que la solution précédente, pourvu que cela dure ! ;-)

Nextcloud sur NAS Synology : mise à jour version 13 à 14

Thu, 28 Feb 2019 18:17:42 +0000

Hier, je me suis décidé à passer mon instance NextCloud de la version 13 à la version 14. Mon instance NextCloud tourne sur la baie Synology (voir cet article pour l’installation).

En effet, j’avais des soucis lors du transfert de photos du smartphone vers NextCloud qui échouaient de manière aléatoire et avec un “error unknown” dans les logs côté smartphone… Problème pas forcément lié, mais j’ai préféré commencer par installer une version plus récente avant d’investiguer plus loin côté smartphone.

La mise à jour automatique proposée via l’interface web de Nextcloud échouant avec un message “Extracting : Can’t handle Zip file. Error code is : 28”(problème sans doute du à la version Zip utilisée par le serveur PHP de Synology), j’ai du y aller à la mano, et même si ce que j’ai fait n’est pas nickel, cela a finit par fonctionner. Alors voilà un petit retour, si ça peut aider…

Je me suis ensuite reporté sur une page du forum d’aide nextcloud décrivant l’opération manuelle d’une mise à jour sur Synology, mais la première commande occ ( o wn c loud c onsole, un script php) pour passer le serveur en mode maintenance échouait :

sudo -u http php70 occ maintenance:mode --on
An unhandled exception has been thrown:
Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: could not find driver in /volume1/web/nextcloud/lib/private/DB/Connection.php:64

Peut-être un problème d’extension PHP sur la baie Synology ? :-(

Bref, je recommence alors en suivant les instructions indiquées par NextCloud sur la page “Update manually”. On verra que par la suite je suis retombé sur la même erreur avec occ, mais que la mise à jour a tout de même pu se terminer via la page web. J’ai aussi du installer deux extensions php supplémentaires : intl et iconv.

Allez hop, on commence par télécharger la dernière version de NextCloud. En l’occurrence, j’ai préféré télécharger le version 14 car les mises à jour (upgrade) en sautant une version majeure ne sont pas supportées ( Skipping major releases is not supported). J’ai donc récupéré ici le fichier nextcloud-14.0.7.zip que j’ai ensuite copié sur la baie Synology en utilisant le “File Station” de DSM.

Ensuite il faut se logguer en ssh sur la baie Synology, passer root, se déplacer au bon endroit, puis recopier le fichier nextcloud récupéré précédemment dans le répertoire courant :

sudo su
cd /volume1/web
cp /volume1/homes/pascal/nextcloud-14.0.7.zip .

J’ai ensuite passé le serveur en mode maintenance manuellement. Pas sûr d’ailleurs que cette étape soit réellement nécessaire, cela empêche les accès pendant la phase de mise à jour, alors si vous êtes seul à utiliser votre serveur…). Néanmoins, il suffit d’éditer le fichier config.php dans le répertoire config, et de passer le paramètre ‘maintenance’ à ’true’ avec l’aide de vi, l’éditeurdont il est utile de connaître les bases…

cd nextcloud/config
vi config.php

Sauvegarde

Comme il faut tout de même essayer de faire les choses bien, on fait une sauvegarde des fichiers au cas où :

rsync -avx nextcloud/ nextcloud-dirbck_`date +"%Y%m%d`/

Pour la base de données, la commande ‘mysqldump’ ne fonctionnant pas (problème Synology certainement), je suis passé par phpMyAdmin de DSM pour faire une sauvegarde de la base de données nextcloud.

On peut maintenant passer à la mise à jour proprement dit. Nous allons d’abord renommer le répertoire nextcloud existant, puis dézipper le fichier de la version 14 (ce qui crée un nouveau répertoire nextcloud), et enfin copier l’ancien fichier config.php à la place du nouveau :

cd /volume1/web
mv nextcloud nextcloud-old
7z x nextcloud-14.0.7.zip .
cp ./nextcloud-old/config/config.php ./nextcloud/config/config.php

Il n’y a rien à faire pour les data, puisque le répertoire est placé dans /volume1/homes/pascal/NextCloud (voir installation). Et je n’utilise pas d’application “3rd party”. Reste à appliquer les permissions comme lors de l’installation. Le script est toujours là, il suffit donc de le lancer (toujours en tant que root !) :

./nextcloud-permissions.sh

Jusque là tout s’est bien passé. Mais il faut maintenant lancer la commande d’upgrade, et celle-ci va échouer comme attendu (même problème que pour passer en mode maintenance) :

sudo -u http php70 occ upgrade
An unhandled exception has been thrown:
Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: could not find driver in /volume1/web/nextcloud/lib/private/DB/Connection.php:64

Ce serait bien sûr sympa de trouver la solution à ce message d’erreur, mais je n’ai pas fait de recherches sur ce point. J’ai repassé le serveur en ‘maintenance’ => false, puis je me suis contenté de recharger la page web de mon instance Nextcloud, et là miracle, l’upgrade a commencé à s’exécuter :

Puis j’ai eu une erreur heureusement sans conséquence :

Lancement de la vérification d’intégrité du code Une erreur est survenue. Veuillez recharger la page.

J’ai rechargé la page, et tout s’est bien passé. Je suis tout de même allé voir dans les Paramètres - Journalisation, et j’ai vu un message récurrent à propos d’une extension php intl manquante. D’ailleurs, le lendemain, en passant par l’application Nextcloud d’Ubuntu, j’ai vu un autre problème similaire avec l’extension iconv. Je suis donc allé via DSM, ouvert Web Station, et ajouté ces deux extensions :

Et voilà… Mon instance Nextcloud est désormais opérationnelle et en version 14.0.7.

Peut-être les problèmes PHP rencontrés sont dus à des extensions manquantes ? J’ai également noté que j’ai encore la version 5.6 d’installée, même si c’est la version 7 qui est déclarée par défaut… Le fait que l’upgrade se soit lancée via l’interface web me fait penser que l’environnement via la connexion SSH ne doit pas être correct. À voir, pour la prochaine mise à jour !! j’attends un peu pour la version 15, rien ne presse.

NAS Synology : installation de NextCloud sur DSM 6

Mon, 18 Jun 2018 14:33:01 +0000

On entend souvent parler de la solution NextCloud quand il s’agit d’héberger soi-même ses données personnelles, en se libérant ainsi des vilains GAFAM qui veulent tout savoir de nous…

J’avais plus particulièrement en tête un système de prises de Notes que je puisse synchroniser entre mon smartphone et le PC, la synchro se faisant automatiquement par NextCloud. Il s’agit de Joplin, qui fera l’objet d’un article un peu plus tard.

Étant possesseur d’une baie Synology, je me suis rendu compte que je pouvais effectivement installer un serveur NextCloud sur mon NAS ! Cela n’a rien de très compliqué, mais il y a des paquets à installer et à configurer scrupuleusement avant de pouvoir lancer son NextCloud.

Les infos de cet article viennent de cet article (en anglais). Il est très bien fait, mais comme je n’ai pas trouvé d’équivalent en français, j’y vais de mon billet, en ajoutant quelques petites notes prises pendant ma propre installation.

C’est parti !

Packages

Commençons par installer les paquets requis à partir du centre de paquets :

Web station
HTTP Server 2.4
PHP 7.0
Phpmyadmin
MariaDB 10

Configuration

MariaDB

Pour finir l’installation de MariaDB, il faut mettre un mot de passe (laissé vide par l’installation). Il faut donc lancer MariaDB, choisir “Changer le mot de passe MariaDB”, laisser le premier champ vide, et choisir un bon mot de passe.

Webstation

Lancer Webstation, puis sélectionner Apache HTTP Server 2.4 et PHP 7.0 :

Dans ma configuration, je n’active pas de “Virtual Host”, je vais au plus simple. Si c’est votre cas, renseigner les paramètres demandés (nom de l’hôte, le port, le répertoire racine du document), et sélectionner les mêmes versions d’Apache et PHP. Retenir surtout l’emplacement du répertoire racine pour la suite.

Extensions PHP

Il va maintenant falloir indiquer l’emplacement où seront stockés vos fichiers personnels (le dossier pour vos données NextCloud). Pour ma part, ce sera dans /volume1/homes/pascal/NextCloud : j’ai donc créé ce dossier précédemment. Il va aussi falloir activer les extensions PHP nécessaires au fonctionnement de NextCloud, à savoir :

bz2
curl
gd
mysqli
openssl
pdo_mysql
zip

L’auteur de l’article précise qu’il ne sait plus vraiment lesquelles sont vraiment nécessaires, mais au moins avec celles-ci, on est certain que tout fonctionne.

Info

Après une mise à jour à la version 14 (voir cet article), j’ai eu besoin d’activer deux autres extensions, alors autant les activer dès maintenant : intl et iconv.

Paramètres PHP

Il y a également des paramètres PHP à modifier : sélectionner l’onglet “Cœur” est modifier si nécessaire les paramètres suivants :

mysql.default_port=3307 (port par default pour MariaDB 10)
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Voilà, les paramètres de la “Web station” sont prêts pour que NextCloud fonctionne. Il ne reste plus qu’à installer NextCloud proprement dit.

NextCloud

Télécharger NexCloud à partir de cette page. Vous allez récupérer un fichier nextcloud-XX.Y.Z.zip qu’il va falloir copier sur votre NAS Synology, à la racine de votre “Web station”, soit dans /volume1/web.

L’ayant téléchargé sur le PC, et comme il m’était impossible avec le “File Station” de Synology d’aller dans le dossier /volume1/web :-(, voilà comment j’ai procédé :

Je suis allé dans /volume1/homes/pascal/NextCloud, puis j’ai fait “Charger” et suis allé chercher le zip de NextCloud sur mon PC. Ensuite, je me suis connecté en SSH sur la baie Synology (il faut avoir activé SSH sur le NAS auparavant bien sûr, dans “Terminal & SNMP” sélectionner “Activer le service SSH”, sur le port de votre choix, 2158 dans mon cas), et tapé la commande suivante pour extraire le zip au bon endroit grâce à 7z, l’outil installé par défaut par Synology :

pascal@pascal-SH87R:~$ ssh admin@192.168.1.14 -p 2158
admin@DiskStation:~$ 7z x /volume1/homes/pascal/NextCloud/nextcloud-13.0.4.zip -o/volume1/web

Modifier les permissions

Reste à modifier les permissions par défaut. Nous allons pour cela utiliser un script : créer le fichier nextcloud-permissions.sh comme ci-dessous sur votre PC en adaptant les chemins des dossiers à votre configuration, puis copier-le sur le NAS comme précédemment :

#!/bin/bash
chown -R http:http /volume1/web/nextcloud/
chown -R http:http /volume1/web/nextcloud/apps/
chown -R http:http /volume1/web/nextcloud/config/
chown -R http:http /volume1/web/nextcloud/themes/
chown -R http:http /volume1/homes/pascal/NextCloud/
chown http:http /volume1/web/nextcloud/.htaccess
find /volume1/web/nextcloud/ -type f -print0 | xargs -0 chmod 777
find /volume1/web/nextcloud/ -type d -print0 | xargs -0 chmod 777
find /volume1/homes/pascal/NextCloud/ -type d -print0 | xargs -0 chmod 777
chmod 777 /volume1/web/nextcloud/.htaccess

Je l’ai déplacé ensuite dans /volume1/web. Connecté en SSH, il ne reste plus qu’à exécuter le script, et vérifier qu’il n’y pas d’erreur. Si nécessaire, donner les droits d’exécution au script :

admin@DiskStation:~$ cd /volume1/web
admin@DiskStation:/volume1/web$ sudo chmod +x nextcloud-permissions.sh
admin@DiskStation:/volume1/web$ sudo ./nextcloud-permissions.sh

Voilà, c’est terminé pour l’installation de NextCloud, il ne reste plus qu’à accéder à notre nouveau serveur.

Dernière étape

Pour que votre serveur NextCloud soit accessible par l’internet, vérifier d’abord que vous avez bien mis en place le service “Quickconnect” de Synology qui vous permet de vous connecter avec une adresse du style myservicename.synology.me (à moins que vous ayez votre propre nom de domaine).

Aller dans le Panneau de configuration, puis “Accès externe”, onglet DDNS et créer une entrée en choisissant Synology comme fournisseur de service :

Une fois ceci fait (si vous avez un routeur/une box, penser à ouvrir le port 80), il ne reste plus qu’à accéder à la page de NextCloud :

Il faut bien remplir cette première page, avec un utilisateur créé sur le NAS, le chemin d’accès à vos données () soit /volume1/homes/pascal/NextCloud dans mon cas), et enfin l’utilisateur ‘root’ pour MariaDB avec le mot de passe que l’on a changé tout à l’heure… Puis cliquer sur “Finish setup”.

En ce qui me concerne, j’ai eu deux erreur 504 (il s’agit d’un Gateway time-out), mais au troisième rechargement, la page finale de NextCloud s’est enfin affichée :

Et voilà, j’ai mon instance NextCloud qui tourne ! :-D Reste à l’utiliser, la première chose sera un système de prise de notes comme je le disais en début d’article. Ce sera l’objet d’un futur billet.

Il y a aussi plein d’autres choses que l’on peut faire, comme synchroniser ses contacts, ou son agenda… Pour cela, j’ai d’autres solutions (un serveur Baikal sur le serveur du blog), mais il y a aussi les photos du smartphone par exemple, et plein d’autres choses à faire avec ce bel outil.

Indexation baie Synology : installation de Synology-mediamon

Tue, 01 May 2018 16:30:03 +0000

L’indexation automatique d’une baie Synology n’est pas optimale, et pose souvent problème quand on passe par NFS pour copier les fichiers (par exemple). J’avais écrit l’année dernière un article pour installer le paquet “Media Indexer” de Francis Besset.

Hélas, depuis le passage en DSM 6, cela ne marchait plus vraiment : je retrouvais souvent le service arrêté. Et en allant aux nouvelles, le paquet a été retiré, et manifestement il ne faut pas compter sur une nouvelle version.

Je me suis donc tourné vers une autre solution appelée synology-mediamon. L’installation n’a rien de compliquée, mais elle se passe en mode “ligne de commande”. Je fais donc ce petit tuto en français, n’en ayant pas trouvé d’autres.

Tout ceci ne concerne bien entendu que les répertoires définis pour le “Indexing Service” dans le Control Panel :

La première chose à faire est d’installer Python 3 s’il n’a pas été installé précédemment. Rien de plus simple, aller dans le Package Center, sélectionner “Community” dans la partie gauche, et donc installer Python 3. Vous verrez peut-être qu’une autre version de Python est installée (la v2) : peu importe, installer Python 3 à côté.

Info

La solution présentée ci-dessous ne fonctionne plus (pb démarrage automatique, plantages fréquents), et de plus n’est plus maintenue.
Voir désormais ce nouvel article pour une autre solution, Synoindex Watcher.

Il va d’abord falloir récupérer le fichier zip de la page github de synology-mediamon. Cliquer sur “Clone or Download” à droite, puis sur “Download ZIP”. En plus du readme, il y a deux fichiers qu’il va falloir copier dans /volume1/homes/admin/ : mediamon.py et S99mediamon.sh. On peut utiliser le File station de Synology pour ce faire :

Passons maintenant à la partie “ligne de commande”. Il va falloir activer SSH pour pouvoir se connecter à la baie Synology : aller dans le Control Panel, sélectionner “Terminal et SNMP” dans la partie gauche, cocher SSH et lui attribuer un numéro de port :

Il ne reste plus qu’à se connecter à partir d’un terminal (l’adresse IP de la baie est indiquée dans le Control Panel -> Info Center -> onglet Network). Dans mon cas, cela donne ceci :

ssh admin@192.168.1.14 -p 2158

Taper ensuite la commande suivante pour être l’utilisateur root (il faudra retaper le mot de passe) :

sudo su

On installe ensuite pyinotify :

python3 -m ensurepip
python3 -m pip install pyinotify

Pour vérifier que pyinotify fonctionne, taper :

python3 -m pyinotify -v /tmp

Vous devez alors voir des choses comme ceci défiler (taper Ctrl-c pour arrêter) :

Pour que synology-mediamon démarre automatiquement, Il faut maintenant copier S99mediamon.sh dans le répertoire /usr/local/etc/rc.d/, puis lui accorder les permissions 0755 :

cp /volume1/homes/admin/S99mediamon.sh /usr/local/etc/rc.d/
chmod 755 /usr/local/etc/rc.d/S99mediamon.sh

Il ne reste plus qu’à redémarrer votre baie Synology pour vérifier que le service démarre bien automatiquement. Sinon, taper la commande suivante :

/usr/local/etc/rc.d/S99mediamon.sh start

Pour vérifier que tout fonctionne, ajouter des fichiers (via NFS tant qu’à faire) dans l’un des répertoires /volume1/photo, /volume1/music, ou /volume1/video, et vérifier le fichier de log de mediamon. On doit voir défiler des “synoindex -a” pour chaque fichier ajouté (pour chaque inode j’ai l’impression !) :

Voilà, ça a l’air de bien fonctionner, pas de problème depuis que je l’ai installé.

Le développeur note que si vous avez un très grand nombre de fichiers multimédias, le message d’erreur “No space on device” peut survenir. Cela ne signifie pas qu’il n’y a plus d’espace disque, mais que l’on a atteint la limite du nombre de fichiers surveillés. Il est possible d’augmenter cette limite en tapant la commande suivante (en tant que root) :

echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p

Bonne indexation !

DS Video sur Samsung Smart TV

Thu, 20 Jul 2017 18:01:59 +0000

Pour regarder les films ou les Séries stockées sur ma baie Synology, je passais par un changement de sources, passant de “HDMI1” à “Synology DiskStation Réseau”, soit une manière tout à fait classique. Avec comme limitation une interface assez basique, dossier par dossier, même si je pouvais tout de même afficher les affiches des films en choisissant “Video Station” sur le premier écran :

Mais il y avait beaucoup mieux : : installer une application appelée DS Video sur la TV Samsung, et accéder ainsi à une interface beaucoup plus plaisante et offrant plus d’options.

Voilà quelques informations que j’ai noté, car l’installation n’est pas vraiment triviale…

Info

Depuis cet article, qui commence à dater un peu, je suis passé à PLEX, une solution beaucoup plus évoluée et maintenue (contrairement à DS Video). On l’installe sur le NAS Synology (partie serveur), et sur la TV Samsung (PLEX fait partie des applications disponibles sur la TV, partie cliente).

Avant, je passais donc par le bouton SOURCE de la télécommande, pour choisir la baie Synology :

Côté config, c’est standard: la TV est connectée en WIFI, et la baie est connectée à la box par un câble ethernet. J’ai attribué une adresse IP fixe à chacun des appareils, cela simplifie les choses (ce sera même nécessaire dans ce cas pour que la TV puisse se connecter à la baie Synology à chaque lancement de l’application DS Video).

En choisissant “Video Station” sur le premier écran proposé, on arrive à ce genre d’écran pour choisir son film : il n’y a pas vraiment d’options, c’est assez basique, mais cela fonctionne.

DS Video

On va donc installer une application sur la TV Samsung, qui saura se connecter à la baie Synology avec une interface beaucoup évoluée, offrant par exemple la possibilité de reprise sur une lecture interrompue…

L’installation est un peu inattendue, puisqu’il faut, une fois dans le Smart Hub, se connecter avec un compte “develop”… Tout est détaillé sur cette page au titre tout aussi inattendu : Que devrais-je savoir à propos de DS video for Samsung Smart TV ? (utile par exemple pour savoir quels modèles de TV sont supportées).

La procédure n’est pas vraiemnt triviale, et les menus ont semble-t-il changés. Dans mon cas (modèle TV LED SAMSUNG UE40JU6000 4K UHD achetée en 2015), j’ai fait les actions suivantes :

Touche Smart Hub de la télécommande
Sélection des applis “Recommandées” en bas à gauche
Sélection de “Mes applications”
Tout en haut à droite, sélectionner compte
Cliquer sur le +, et choisissez “Connexion”
Entrer “develop” comme ID, laisser “mot de passe” vide. Cocher “Me connecter automatiquement” si ce n’est pas fait.
La page “Mes Applications” s’affiche alors, et dans la section “Le plus populaire”, vous devez voir l’application DS Video s’afficher, qu’il suffit de sélectionner pour l’installer.

Toujours est-il que vous retrouvez désormais une application DS Video dans le Smart Hub, avec laquelle vous allez pouvoir vous connecter à votre baie Synology. Attention, il faudra fournir l’adresse IP de la baie (donc autant lui assigner une adresse fixe sur la box !), ainsi qu’un nom d’utilisateur et un mot de passe. Ces informations seront mémorisées et donc à ne saisir qu’une seule fois.

Et voilà, vous pouvez maintenant accéder au contenu multimédia de votre NAS Synology à partir d’une application installée sur votre TV Samsung. Il suffit d’appuyer sur le bouton Smart Hub de la télécommande, puis de choisir l’application DS Video :

Utiliser les flèches pour choisir le contenu, comme Séries, Films, etc… :

L’interface est conviviale, offre beaucoup plus d’options et est beaucoup agréable à utiliser : affichage des informations (affiche, acteurs, résumé,etc… si votre bibliothèque video est bien gérée bien sûr !), reprise sur dernier arrêt, navigation rapide, etc… Bref, ce que doit proposer une application de ce genre.

Tout n’est pas parfait pour autant : pour les séries, pas toujours facile de s’y retrouver parmi les épisodes (selon le nommage des fichiers, vous ne voyez que le début du nom de fichier), et la vue par dossier semble bugée, elle affiche et mélange le contenu de plusieurs dossiers, par exemple de plusieurs saisons alors que l’on a choisi le dossier Saison2. Mais bon, c’est déjà beaucoup mieux que le simple DLNA.

Voilà, il suffisait surtout de savoir que cette application existait !

Synology : indexation multimedia et NFS

Wed, 28 Jun 2017 17:11:30 +0000

Comme expliqué dans l’article Mapper le répertoire d’un NAS Synology sur Ubuntu, je copie directement les fichiers multimédia vers le NAS Synology depuis le PC (via le protocole NFS). Et un problème pas vraiment sympa est apparu : les fichiers copiés de cette façon ne sont pas indexés automatiquement, et donc quand le veux les visionner sur la TV (via DLNA), je ne les vois pas !

Il faut aller dans l’interface de DSM, aller dans le Panneau de configuration, sélectionner Service d’indexation sur la gauche, puis cliquer sur le bouton Ré-indexation. Opération à répéter à chaque fois que vous aller copier des fichiers de cette manière sur le NAS Synology ! :evil:

En cherchant un peu dans la base de connaissance de Synology, c’est confirmé :

Il faudrait donc le faire manuellement… C’est quand même assez lamentable ! D’autant qu’il n’y a aucun moyen d’automatiser le lancement de l’indexation de manière récurrente, en tout cas je n’ai rien trouvé pour le faire dans le panneau de configuration. On se demande ce que font les développeurs de DSM, ce genre d’option serait vraiment la bienvenue, et ce n’est pourtant pas difficile d’en deviner le besoin.

Info

Cet article n’est plus d’actualité depuis DSM 6, le package de Francis Besset mentionné ci-dessous n’est d’ailleurs plus disponible. Voir ce nouvel article : Indexation baie Synology : installation de Synology-mediamon.

Heureusement, il y a la communauté, et un certain Francis Besset, qui a développé le package qui pallie ce manque (voir cette page).

Il faut d’abord ajouter une nouvelle source de paquet “http://synology.francis-besset.com/" dans le Centre de paquets :

Il faut ensuite installer le nouveau paquet “Media installer” qui apparaît dans la liste. Valider les deux premières fenêtres (cryptage et licence), puis la fenêtre ci-dessous apparaît : par défaut, les répertoires proposés doivent suffire (video, audio et photo), sinon ajouter le ou les votre(s) dans le champ Watch directories proposé, séparés par “:” s’il y en a plusieurs :

Une fois ceci fait, le paquet Media Indexer (ainsi que inotity-tools, une librairie C et un ensemble de commandes permettant d’utiliser facilement inotify) apparaissent dans le Centre de paquets (et en cours d’exécution !) :

Et voilà, les nouveaux fichiers copiés vont maintenant être indexés immédiatement et copiés dans la base de données utilisée par DLNA pour des raisons de performance (si vous aviez copiés des fichiers auparavant, il faut passer par la case Ré-indexation).

Mapper le répertoire d'un NAS Synology sur Ubuntu

Thu, 22 Jun 2017 17:05:27 +0000

Ça fait longtemps que j’aurais du faire ça, histoire de faciliter la copie de fichier entre les deux machines. Je m’en tenais à l’interface de DSM pour copier les fichiers du PC vers la baie Synology, mais c’est plus simple de tout faire directement à partir de Nautilus, l’explorateur de fichiers d’Ubuntu.

Comme je n’ai pas trouvé la solution tout de suite (et particulièrement les options de fstab), voilà les étapes à suivre (l’article qui m’a apporté la réponse est ici, mais en anglais).

Nous allons utiliser le protocole NFS (Network File System) pour ce faire, qu’il va falloir installer/activer des deux côtés : le PC Ubuntu sera le client, et la baie Synology sera le serveur. Il faudra ensuite définir un dossier de partage sur la baie, et automatiser le montage de ce répertoire côté PC. Rien de très compliqué donc, mais il est facile de se tromper !

Allons-y !

Sur la baie Synology

D’abord activer NFS via le panneau de configuration -> Service de fichiers, cocher la case puis cliquer sur “Appliquer” :

Puis aller dans “Dossier partagés” : le dossier que je veux partager est le dossier video, et il est déjà présent, pas besoin de le créer (sinon faites-le). Cliquer sur Modifier, puis sélectionner l’onglet Autorisations NFS, et paramétrer comme suit (192.168.1.11 est l’adresse de mon PC) :

“Mapper le root sur Admin” permettra de pouvoir monter automatiquement le répertoire au démarrage du PC. Cela simplifie énormément la configuration.

Sur le PC Ubuntu

Il faut d’abord installer le package client de NFS, qui n’est pas installé par défaut :

sudo apt install nfs-common

Il faut ensuite créer un répertoire qui servira de point de montage. Le plus simple est d’aller dans son home, dans mon cas ce sera /home/pascal/DS214/video.

Il ne reste plus qu’à modifier le fichier /etc/fstab :

sudo vi /etc/fstab

Vous pouvez aussi utiliser gedit si vous préférez… Puis ajouter les deux lignes suivantes :

# NAS SYNOLOGY
192.168.1.14:/volume1/video /home/pascal/DS214/video nfs rw,hard,intr,nolock 0 0

L’adresse IP 192.168.1.14 est celle de la baie Synology, et le chemin est indiqué dans la fenêtre des Autorisations NFS du dossier :

Et voilà, le tour est joué. Pour le vérifier, taper la commande suivante (qui va relire le fichier fstab et monter ce qui ne l’est pas) :

sudo mount -a

Et voilà, dans Nautilus, le contenu du répertoire tant attendu apparaît maintenant :

Voir aussi cet article : Synology : indexation multimedia et NFS.

Sauvegarder les données de son NAS Synology vers Ubuntu 16.04 avec Hyper Backup et Rsync

Thu, 28 Jul 2016 16:20:34 +0000

Même si la baie Synology que j’utilise contient deux disques en miroir, ce qui réduit fortement le risque de perte de données, ce n’est pas une raison pour ne pas sauvegarder les données de celle-ci.

Synology fournit un logiciel, Hyper Backup, qui permet de faire une sauvegarde vers un serveur rsync distant. Mon PC tournant sous Ubuntu, il peut devenir un serveur rsync facilement. Il ne reste plus qu’à mettre tout cela en œuvre.

Dans le cas présent, je vais sauvegarder des données qui sont déjà sur mon PC, et que je synchronise sur la baie Synology avec « Cloud Station». En fait, elles sont déjà sauvegardées avec Déjà-Dup… Il s’agit donc plus ici de tester la solution (et vérifier que cela fonctionne, restauration comprise).

La limitation de ce type de solution est que le PC doit être allumé pour que la sauvegarde fonctionne… Mais bon, cela vaut le coup de tester, trop de sauvegarde ne tue pas la sauvegarde ! :-)

Configuration de rsync sur le PC

Il faut d’abord configurer rsync, et le déclarer en tant que service. Un service est simplement un programme capable de s’exécuter au démarrage du PC, sans intervention manuelle. Rsync en fait partie sur les système Linux, c’est assez facile à mettre en œuvre.

D’abord, autorisons le service rsync à se lancer :

sudo vi /etc/default/rsync

Si vous n’aimez pas vi, vous pouvez utiliser un éditeur graphique comme gedit :

sudo gedit /etc/default/rsync

Puis modifier la ligne suivante :

RSYNC_ENABLE=true

Il faut maintenant créer le fichier de configuration :

sudo vi /etc/rsyncd.conf

Voici le contenu que j’y ai ajouté, à adapter selon votre cas :

uid = rsync
gid = rsync
max connections = 2
log file = /var/log/rsyncd.log
timeout = 300

[share_rsync]
   path = /Ebackup/Baie-Synology
   comment = Sauvegarde fichiers Baie Synology
   read only = false
   hosts allow = 192.168.0.11
   hosts deny = *

Explications :

Le service rsync va utiliser un compte rsync, qui sera autorisé à utiliser le module share_rsync, qui pointe sur le répertoire /Ebackup/Baie-Synology (avec les droits d’écriture), et uniquement pour la machine avec l’adresse IP 192.168.0.11 (soit l’adresse de la baie Synology).

L’adresse IP de mon PC est bien entendu celle de mon réseau local, à qui j’ai assigné une adresse fixe via l’interface de la freebox :

Il faut donc d’abord créer l’utilisateur rsync (et lui donner un mot de passe), puis lui donner les droits nécessaires sur le répertoire en question :

sudo useradd rsync
sudo passwd rsync
sudo groupadd rsync
sudo gpasswd -a rsync rsync
sudo chown -R rsync:rsync /Ebackup/Baie-Synology
sudo chmod -R 775 /Ebackup/Baie-Synology

Il ne reste plus qu’à démarrer le service (de manière interactive) :

sudo /etc/init.d/rsync start

Voyons maintenant l’état du service :

sudo systemctl status rsync

On voit que le service est démarré mais en état “disable”, c’est-à-dire qu’il n’est pas en démarrage automatique :

Validons le service au démarrage du PC avec la commande suivante :

sudo systemctl enable rsync

Et regardons maintenant l"état :

Pour contrôler les services, voilà les commandes les plus utiles :

systemctl status SERVICE
systemctl start SERVICE
systemctl restart SERVICE
systemctl stop SERVICE
systemctl enable SERVICE
systemctl disable SERVICE

Pare-feu

Côté PC, il reste à ouvrir le port 873 utilisé par rsync. Comme je suis sur mon réseau local (et que sur le routeur de la freebox ce port est fermé), je vais faire une règle simple, à l’aide de GUFW, l’outil de configuration fournit sur Ubuntu :

Voilà, tout est près côté PC, il est temps de se tourner vers la baie Synology.

Hyper Backup

Ce logiciel est installé par défaut par Synology. Il suffit donc de le lancer à partir du menu principal. Puis cliquer sur le “+” en bas à gauche, et sélectionner “Tâche de sauvegarde de données”. Sélectionner le mode “Serveur rsync distant” :

Dans le fenêtre suivante, il va falloir saisir :

Type de serveur : serveur compatible rsync
Nom ou adresse IP du serveur : <l’adresse IP de votre PC> (voir plus haut)
Chiffrement du transfert : je laisse “éteint”, pas de chiffrement nécessaire.
Port : 873 (le port par défaut pour le service rsync, et pour lequel nous avons créé une règle sur la pare-feu)
Nom utilisateur : rsync (l’utilisateur que l’on a créé précédemment sur le PC)
Mot de passe : le mot de passe définit pour l’utilisateur rsync lors de sa création

À ce stade, cliquer sur la petite flèche pour le champ de “Module de sauvegarde”. Hyper Backup va se connecter au service rsync de votre PC, et doit retrouver tout seul le module [share_rsync] déclaré :

À ce stade, j’ai d’abord eu un message d’erreur “Échec de l’opération. Reconnectez-vous à DSM et réessayer” :

Après quelques recherches sur le net, ce message d’erreur est vraiment générique et ne vous aide pas vraiment ! Seule la première phrase compte… Quelque chose n’a pas fonctionné, c’est tout ce que ‘on peut en conclure.

En fait, j’avais créé un répertoire /Ebackup/BaieSynology sur le disque dur au lieu de /Ebackup/Baie-Synology (comme déclaré dans le fichier /etc/rsyncd.conf).

Une fois ceci corrigé, on arrive à l’écran suivant :

Il ne reste plus qu’à cliquer sur Suivant, et à sélectionner le répertoire que l’on veut sauvegarder :

L’écran suivant vous propose de sauvegarder également des applications Synology, je ne coche rien. Sur le suivant, je change le nom de la tâche, et assigne une heure où le PC est souvent allumé :

Reste à définir les paramètres de la sauvegarde. À chacun de voir, j’ai choisi d’activer la rotation des sauvegardes, d’activer l’option “Smart Recycle”, et un nombre de versions qui me permet de revenir un an en arrière :

Voilà, c’est terminé, l’assistant vous demande si vous désirez effectuer une sauvegarde maintenant, je valide, puis quelques instants plus tard (en fonction de la taille de la sauvegarde), j’obtiens l’écran suivant, m’informant que la sauvegarde a bien été effectuée :

Il est possible de vérifier l’intégrité de la sauvegarde :

Testons maintenant la restauration ! Car dans les scénarios “disaster-recovery”, le “disaster” est toujours facile à mettre en place ! ;-) Il faut toujours tester la partie “recovery” pour être certain d’avoir tout validé.

Comme je l’ai dit au début de l’article, ces données sont déjà sauvegardées sur le PC, je ne risque donc rien à effacer un répertoire de mon “home” sur la baie Synology. J’efface donc le répertoire “APKs”.

Ceci fait, je relance Hyper Backup, clique sur la petite horloge en bas à gauche, et sélectionne “Data”. Puis je sélectionne la dernière sauvegarde :

Et coche le dossier que je souhaite restaurer :

Je valide, et la restauration démarre :

Et voilà, une fois l’opération terminée, mon répertoire “APKs” a bien été restauré sur la Baie Synology.

Pour conclure, mis à part le message d’erreur du à une erreur de ma part, tout s’est fait très facilement. Voilà donc une solution facile à mettre en place, si on stocke sur la baie Synology des fichiers que l’on n’a pas ailleurs. En prime, on a appris à mettre en place le service rsync sur le PC ! ;-)

NAS Synology : notification par SMS via Free Mobile

Fri, 19 Feb 2016 15:19:46 +0000

Free Mobile propose un système de notification par SMS, et il est possible de l’utiliser pour recevoir les messages d’un NAS Synology. Exemple des messages reçus :

Il s’agit des messages signalant un changement d’état, une mise à jour nécessaire, etc… Par défaut, Synology nous prévient par mail (ce qui peut se révéler suffisant), mais je suis tombé sur cet article qui explique comment recevoir ces messages par SMS et ça m’a intéressé. Comme il y a quelques erreurs dans l’article en question (les captures d’écran ne correspondent pas toujours avec ce qui est expliqué), j’ai décidé de faire cet article.

Il faut bien entendu avoir au préalable activé l’option de notification par SMS sur le site http://mobile.free.fr. Se connecter sur le site, puis aller dans “Gérer mon compte - Mes options”. Activer la notification par SMS, et noter la clé d’identification au service qui vous est fournie :

Dans DSM, l’interface de management de votre NAS Synology, aller dans le Panneau de configuration, puis choisir Notifications, et enfin l’onglet SMS. Cocher alors la case “Notifications par SMS”, et cliquer sur le bouton “Ajouter un fournisseur de service SMS”. Dans la fenêtre qui s’ouvre, donner un nom pour le fournisseur, et saisir la chaîne suivante :

Cliquer sur Suivant, et définir le type de données pour chaque champ :

Cliquer sur Appliquer. Il ne reste plus qu’à saisir les identifiants Free Mobile :

Le nom d’utilisateur est votre identifiant pour se connecter à votre espace abonné sur le site de Free Mobile.
Le mot de passe est la clé d’identification au service que vous avez noté précédemment.
Et bien sûr votre numéro de téléphone (en numérotation internationale, donc sans le 0 initial).

Et voilà, cliquer sur le bouton “Envoyer un message SMS de test” pour vérifier que tout fonctionne, ce qui doit être le cas.

À noter un petit bug tout de même : les messages de notification par SMS sont en anglais, alors que les messages par mail sont bien en français… Le réglage se trouve dans le Panneau de configuration - Options Régionales - onglet Langue, et il n’y a qu’un réglage pour les deux modes, donc bug ! :

Disk Station DS214 Synology - Installation

Mon, 18 Jan 2016 18:59:02 +0000

Je me suis récemment offert une Disk Station DS214 de Synology, histoire de faire un premier pas dans l’auto-hébergement…

Dans cet article, je vais décrire l’installation de la baie, et mon premier essai d’utilisation, à savoir la Station Audio à partir de mon smartphone, histoire de pouvoir écouter ma musique lorsque je suis loin de chez moi.

Autant le dire tout de suite, cela a été d’une simplicité enfantine. Je m’attendais à rencontrer quelques soucis, mais non, c’est vraiment très bien conçu et l’installation est quasi transparente.

Il y a bien deux ou trois actions à prendre par la suite, notamment pour la configuration de l’accès externe (et donc le routeur de la freebox ainsi que la redirection de ports), mais là aussi, Synology s’occupe de tout. Le QuickConnect ID est tout simplement bluffant de simplicité.

Le boîtier est relativement petit, et a trouvé facilement sa place sous le bureau, près de la Freebox server à laquelle il faudra le connecter par un câble réseau.

Mais la première chose à faire est d’installer les disques durs dans le boîtier Synology. J’ai choisi deux disques de 1 To chacun, qui fonctionneront en RAID 1, c’est-à-dire en “miroir” : chaque disque est l’image de l’autre, et en cas de panne sur un disque, le système continue de fonctionner comme si de rien n’était. Synology a son propre système appelé SHR ( S ynology H ybrid R AID), et il va s’occuper de tout configurer pour vous.

Première bonne surprise, même pas besoin de tournevis pour fixer les disques durs : une languette plastique permet de les fixer très simplement, il suffit de suivre le petit schéma livré avec le boîtier :

Il ne reste plus qu’à tout refermer, et brancher la baie électriquement, la connecter avec le câble réseau fourni sur la Freebox Server, et enfin la démarrer.

À ce stade, je suis allé dans l’administration de la freebox (http://mafreebox.freebox.fr), et j’ai assigné une adresse IP fixe à la Disk Station (192.168.0.11 ici), histoire de simplifier les choses :

Il ne reste plus qu’à se connecter à la Disk Station en utilisant le navigateur internet via l’adresse IP assignée précédemment et en précisant le port 5000 : http://192.168.0.11:5000. Une page de bienvenue s’affiche, listant quelques informations :

L’écran suivant vous demande de confirmer l’installation de DSM, le D isk S tation M anager, soit l’interface web qui vous permettra d’administrer la baie Synology. Choisir l’installation via internet, afin d’obtenir la dernière version :

L’écran suivant vous demande de saisir un mot de passe pour le compte admin, créé par défaut. Vous aurez tout le loisir de créer d’autres comptes par la suite, mais celui-ci est obligatoire. Puis l’installation démarre, et dure une bonne dizaine de minutes :

L’étape suivante est importante, puisque l’on va configurer QuickConnect, qui permettra d’accéder à votre Disk Station de n’importe où, et ceci de manière très simple ! Renseignez votre adresse mail, choisissez un mot de passe, et enfin le QuickConnect ID, qui peut contenir de lettres des chiffres et des tirets :

Et voilà, une URL toute simple est générée pour vous connecter à distance sur votre Disk Station :

Il faut également enregistrer un compte Synology sur leur site : https://account.synology.com/fr-fr, en s’identifiant avec l’adresse mail et le mot de passe indiqué lors de la configuration de QuickConnect.

Comme l’installation est bien pensée, on vous propose ensuite d’installer les paquets Synology recommandés :

Ensuite DSM vous propose une rapide visite guidée pour la prise en main de l’interface (qui est assez intuitive).

Terminé ? pas tout à fait, car DSM va se mettre à jour à la toute dernière version, et donc il faudra patienter encore une dizaine de minutes :

Premiers pas

OK, tout est maintenant installé, qu’est-ce que je fais ?

D’abord, je vais aller voir comment la Disk Station s’en sort avec la Freebox (qui fait office de routeur) : Dans le panneau de configuration, je sélectionne Accès Externe, et je clique sur le bouton Configuration du routeur. Quelques secondes plus tard, j’ai le message suivant :

Je valide, et Ô miracle (technologique), la configuration a été faite automatiquement :

Puis un petit test de sécurité, ça ne peut pas faire de mal, disponible via le “conseiller de sécurité”, à partir du menu principal :

Ensuite, puisque je dispose maintenant d’une Audio Station, j’ai bien envie de l’essayer, et de tester par la même occasion l’accès via internet…

Il me faut donc dans un premier temps copier des fichiers de ma bibliothèque musicale. Le plus simple est alors d’utiliser l’explorateur de fichiers du PC, la Disk Station apparaissant dans le voisinage réseau. il suffit de les copier dans le répertoire Music.

Maintenant je prends mon smartphone, et installe l’application DS Audio de Synology. Je coupe le wifi pour être sûr de passer par le réseau téléphonique, histoire de vérifier que cela marchera de n’importe où.

Puis je lance DS Audio et tente une connexion en utilisant le QuickConnect ID généré précédemment, le nom d’utilisateur (j’ai créé un compte “pascal” entre-temps), et le mot de passe. C’est là que l’on voit tout l’intérêt du QuickConnect ID…

Je vois d’ailleurs qu’il y a une option HTTPS, je vais regarder ça de plus près, apparemment Synology fournit des certificats pour votre Disk Station, c’est plutôt intéressant. Et voilà, mes fichiers musicaux sont là, disponible en écoute, et à priori, le streaming marche plutôt bien.

Les fichiers lus par DS Audio seront stockés localement sur le smartphone. Il peut donc être utile d’aller dans les paramètres et modifier le chemin de stockage afin que ces fichiers soient stockées sur la carte SD et pas dans la mémoire interne. Si on ne peut pas choisir le répertoire de son choix, on peut toutefois sélectionner la carte SD : /storage/sdcard1 dans mon cas, et le reste du chemin est forcé par l’application.

Une dernière chose avant de terminer cet article : à force de copier puis d’effacer des fichiers audio (car le tag ne me convenait pas), je me suis retrouvé dans la situation où des fichiers n’apparaissaient plus dans DS Audio, alors qu’ils étaient bien présents et visibles via le File Station (le gestionnaire de fichiers) de DSM.

Le problème a été réglé en allant dans Indexation Multimedia du Panneau de Configuration de DSM, et en lançant une ré-indexation :

Voilà, ce sera tout pour cette première prise en main de la Disk Station Synology.

Franchement, j’ai été très agréablement surpris par la simplicité d’installation (et notamment l’absence de configuration du routeur). Il y a encore beaucoup de choses à découvrir et à faire avec ce bel objet technologique, ce sera l’occasion d’autres articles.