.Shad.

Non, tu n'as pas de data supplémentaire ajoutable à ton plan. Non, pas possible à ma connaissance. Cela dit : En RAID 1 tu réduis fortement les chances d'occurence de ce scénario. C'est plutôt une panne du NAS ou un vol qui pourrait engendrer un tel scénario. Supposons que ça arrive, soit tu utilises Drive et là tu peux continuer à travailler localement, si tu fais de la synchro à la demande tu peux récupérer avec Hyper Backup Explorer les données depuis C2 Si pour une raison X tu ne remets pas rapidement en production ton NAS, tu peux très bien sauvegarder les données sur lesquels tu travailles avec un programme comme Cobian Backup par exemple, un excellent logiciel sous Windows. Données que tu pourras mettre à jour sur le NAS lorsqu'il sera de nouveau opérationnel. N'hésite pas à te présenter dans la section adéquate du forum, c'est l'occasion d'en savoir un peu plus sur ton niveau d'informatique/réseau, donc d'adapter nos réponses en conséquences, et de partager avec nous ce que tu fais avec ton NAS.

Non, c'est juste que c'est le premier rempart, si la version avait été une version autorisée par ton serveur, ça aurait buté sur l'authentification.

https://www.home-assistant.io/integrations/http/ Je pense que tu dois ajouter dans le yaml de ta config les paramètres use_x_forwarded_for à yes et dans trusted_proxies ajouter l'IP locale du NAS.

192.168.0.113 c'est bien l'IP de la VM et pas du NAS ?

Ça ne change rien pour le proxy inversé, VM ou NAS directement, tu mets juste l'adresse de la VM pour le service vers lequel tu rediriges.

@PiwiLAbruti Un billet intéressant également : https://vanderwijk.info/posts/resolving_synology_dsm_insufficient_system_capacity_for_update/ Et une réponse officielle de Synology concernant le fichier space-preserve sur le forum emby : https://emby.media/community/index.php?/topic/106330-dsm-71-beta-compatibility/#comment-1137089 Le fichier peut être supprimé (mais ce n'est pas recommandé) et est regénéré à chaque redémarrage du NAS. A mon avis, ce fichier ayant été introduit avec la 7.1, ils ont mal calibré la taille de ce fichier et rendent les derniers upgrades impossible. Nouvelle version mineure en approche je sens 😄

@PiwiLAbruti Pour faciliter la recherche des fichiers prenant de la place, je conseille l'installation de ce paquet SynoCommunity : https://synocommunity.com/package/synocli-disk Et utiliser en SSH (root) la commande : ncdu -x --exclude /volumeX La navigation est dynamique et beaucoup plus facile 😉 J'ai aussi ce fichier :

Tjs en 7.1 pour ma part : /dev/md0 2.3G 1.7G 475M 79% / Pas sûr que ça passe !

Courage fuyons !

Sinon tu attends, car la 7.2 ça a l'air d'être un sacré bourbier :

Je crois que je vais rester en 7.1 a minima quelques semaines encore. 😄

Seul root et les utilisateurs faisant partie du groupe administrateurs peuvent se connecter en SSH. Il y a moyen de contourner cette restriction, mais à ma connaissance ça ne survit pas à une montée de version majeure, ou montée de version touchant au serveur SSH. Ceci étant dit : Normalement un fichier authorized_keys c'est 600, seul l'utilisateur est sensé y avoir avoir, et 700 pour le dossiers .ssh en amont. Ta clé publique est bien présente dans le fichier authorized_keys ? Pour te connecter en root, c'est dans /root/.ssh/ que doit se trouver le fichier authorized_keys. Pour un utilisateur admin, dans son dossier /volume1/homes/<admin_user>/.ssh Je n'ai jamais eu de problème pour me connecter avec une clé sur 3 NAS différents que j'ai eus.

Je ne suis pas vraiment pas sûr de trouver une solution 🙂 et je ne sais pas quand surtout, s'il n'y a pas d'autres inconvénients à juste avoir un écran blanc dans le panneau de configuration ce n'est pas spécialement gênant. Peut-être aller voir sur les forums de celui-dont-on-ne-prononce-pas-le-nom, ils sont généralement bien plus calés que nous sur ces sujets. 😄

C'est sexy ça, je ne connaissais pas, je vais installer ça. 🙂

Hello, je n'ai pas trop réagi jusque-là car je vais essayer de voir ce qu'il en retourne plus avant, et investiguer un peu sur le script de montage d'interface. La solution évoquée par @Jeff777 ayant aussi ses problèmes (plus d'affichage dans Panneau de configuration -> Centre d'infos -> Réseau), je préfère être prudent avant de changer quoi que ce soit. 😉

Est-ce que l'IP attribuée est toujours dans le réseau bridge de VMM ? Est-ce que la VM et ton NAS sont sur le même réseau ?

Est-ce que le problème ne se manifeste que sur une machine ou tu arrives à le reproduire ?

@loli71 Sur le NAS où j'ai fait le test il n'y avait pas d'interface virtuelle, il y en a même jamais eu, et j'avais le problème, le problème a disparu quand j'ai créé le réseau via DSM.

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

Ok, je ne dénigrais pas ta proposition. Si tu penses que c'est fiable et viable dans le temps, why not, je ne suis pas encore concerné par l'obsolescence, même si ça a l'air de se rapprocher à marche forcée pour la série 18 au vu des dernières annonces. Je n'ai jamais dit que tu avais la place, pour ma part j'ai un disque externe qui traine, je pense que je vais télécharger les plus anciennes versions jusqu'à le remplir.

Oui, pour le côté théorique un reverse proxy TCP peut aussi le faire, mais c'est de l'ordre de l'anecdote. Parce que 6690 ou 443, ça reste le même niveau de sécurité, chiffrement TLS et possibilité de limiter la surface d'exposition. Mon port 6690 est ouvert à l'extérieur depuis 5 ans, je n'ai jamais eu le moindre souci.

@Mic13710 Rien ne garantit que le site sera toujours disponible, de plus hier soir il était hyper lent. Apparemment la bande passante est limitée à dessein, de ce que j'ai pu lire à droite à gauche. Certaines personnes ici ont plusieurs dizaines de To disponibles, je pense qu'il serait sage que quelques membres actifs du forum aient les fichiers sous le coude. On peut espérer que Synology remette ces fichiers à disposition mais je n'y crois pas vraiment.

Du nouveau, quelqu'un a fait un backup datant de fin janvier des fichiers présents sur le site de Synology, je ne sais pas trop comment jouer avec ces extensions CDX, mais je pense qu'il faut bondir dessus. J'ai une connexion un peu asthmatique pour autant de données, si des volontaires fibrés et avec 2 To de libres veulent s'en charger : https://archive.org/download/synology-grab-2023-01

Hello @firlin Je ne vois pas trop ce qu'un proxy inversé vient faire entre deux NAS utilisant Sharesync. Sharesync établit un pont sécurisé sur le port 6690 pour le transfert des données entre les NAS. Ca signifie : - Chaque box doit rediriger les requêtes sur son port TCP 6690 vers leur NAS respectif. - Chaque NAS doit autoriser l'accès au port TCP 6690 depuis l'IP distante (si IP source fixe, sinon ouvrir au pays concerné). - Tu te connectes à l'autre NAS via chaque nom de domaine : ndd1.fr:6690 ndd2.fr:6690 Là où un proxy inversé peut intervenir c'est pour se connecter à l'interface Drive de chacun des NAS, mais je ne pense pas que ce soit ce à quoi tu pensais.

Si ça ne devait pas marcher, n'importe quel petit raspberry 3B+ ou 4 feront largement l'affaire pour faire tourner Docker.