.Shad.

Tu as utilisé un fichier compose ? Je vais essayer de l'installer du week-end sur le NAS voir si ça fonctionne.

C'est uniquement pour le paquet Synology. 😉

Bonjour, Mauvaise surprise hier en mettant à jour MariaDB 10 de la version 10.3.37-1077 vers 10.11.2-1303. J'ai perdu des données au passage, la migration ayant pris un temps dingue (3h environ), alors que mes base de données sont pas spécialement volumineuses. J'ai restauré l'ancienne version via une sauvegarde Hyperbackup de la veille, tout est revenu à la normale. De plus, il semblerait que des problèmes de performances aient été identifiés : MariaDB 10.11x Slow performance over WAN | Synology Community Le support Synology est conscient du problème et travaille à le résoudre. Comme le rappelle Synology avant la mise à jour, pensez à faire une sauvegarde via Hyperbackup de MariaDB avant toute upgrade de paquets importants.

Ok donc c'est vraiment un comportement non désiré, tu as bien fait de leur remonter l'info.

@thepopol777 Est-ce que tu as bien fait la redirection de port pour le port 6690 en TCP sur chacune des box vers les NAS respectifs ? Car la connection refused c'est typiquement une redirection non fait et/ou un pare-feu mal réglé. Assure-toi que dans le pare-feu de chaque NAS le port TCP 6690 est ouvert au monde entier le temps d'un test, et que les redirections sont correctement faites, puis tu vas sur https://www.yougetsignal.com/tools/open-ports/ et tu testes depuis chaque NAS si l'ouverture du port est ok :

@Doonet Salut, tu peux regarder ce tutoriel que j'ai rédigé il y a déjà quelques temps, il doit être toujours valable, si tu rencontres des problèmes n'hésite pas à intervenir dessus. Il y a peut-être quelques adaptations avec DSM 7 mais rien de majeur.

Bienvenue parmi nous ! 🙂

Difficile à dire, peut-être interpeler @maxou56 qui a une meilleure connaissance que moi de Virtual Machine Manager.

@firlin Il existe bien des attaques de type ping flood : Attaque DDoS de type Ping (ICMP) flood | Cloudflare Maintenant, les chances que tu sois pris pour cible... ? Est-ce que ce réglage ne désactive pas également le ping en IPv6 ? qui lui participe à la bonne marche du transfert de données contrairement à l'IPv4.

Je n'ai malheureusement pas moyen de reproduire ton cas en l'état. Quelles données perds-tu à ne pas restaurer les métadonnées (dossier commençant par @) ?

Non, tu dois aller dans Conteneur -> Créer et choisir la bonne image. Non pas besoin. Seule la doc de ton image peut te le dire : apparemment c'est dans /homebridge https://github.com/homebridge/docker-homebridge Je ne comprends pas. "Port local" c'est le port sur lequel tu vas mapper le port interne du conteneur sur ton NAS pour te le rendre accessible si ton conteneur est sur un réseau bridge. Si tu ne le spécifies pas, ton conteneur restera inaccessible. La documentation, dont j'ai donné le lien ci-dessus, recommande toutefois d'utiliser le réseau host, donc que homebridge soit directement exposé sur le NAS, comme si c'était une application native de DSM, ça se règle lors de la création de ton conteneur dans Paramètres avancés -> Réseau. Il faut juste s'assurer en amont que le port de Homebridge n'est pas déjà utilisé par le NAS mais a priori le port 8581 est suffisamment exotique pour ne pas être occupé. Ces étapes sont reprises à cette page https://github.com/homebridge/docker-homebridge/wiki/Homebridge-on-Synology-DSM-6-with-Docker Ca reste tout à fait valable pour DSM 7+

Oui c'est probable. Ca peut aussi être lié au pare-feu du NAS, ou les deux à la fois. Je me rends compte que j'ai lu ton poste en diagonale. En effet, le cas précis que tu évoques ne sera pas possible, il faut prendre l'opération dans l'autre sens si tu veux que ça marche : un fichier ajouté dans TO_NAS2 va être synchronisé sur FROM_NAS1 par Drive Sharesync, la synchronisation étant unidirectionnelle NAS 1 -> NAS 2, si je supprime un fichier dans NAS 1 il disparaît dans NAS 2, en revanche si je le supprime dans NAS 2 il reste présent sur NAS 1. Une fois un fichier synchronisé, tu peux le déplacer du dossier FROM_NAS1 vers un autre dossier. Ca peut être fait manuellement ou via un script qui scanne le répertoire FROM_NAS1 à intervalle régulier. Et tu peux de la même manière par exemple vider le contenu du dossier TO_NAS2 sur NAS 1 sur base d'un intervalle régulier en utilisant le planificateur de tâches de DSM. Concernant ta dernière question, de façon générale il n'est pas recommandé d'exposer publiquement les ports NFS ou SMB. Ce sont des protocoles qui ne sont pas destinés à être utilisés à distance, notamment en terme de performance de transfert à distance, de reprise des téléchargements en cas de coupure, ou tout simplement dans la sphère sécuritaire, ces protocoles étant sensibles au brute-forcing. Si Drive Sharesync devait ne pas répondre à ton besoin, l'utilisation de SSH fera l'affaire au moyen des commandes scp et sftp, mais ça nécessite de mettre les mains dans les cambouis. A ta place j'essaierais d'abord de voir ce qu'il est possible de faire avec Drive Sharesync.

Le plus simple est d'utiliser Synology Drive Sharesync, il synchronise des dossiers partagés entre plusieurs NAS. Et tu peux choisir le sens de la synchro. Synology Drive ShareSync | Synology Drive Server - Synology Centre de connaissances Si tu utilises une connexion distante directe (= pas de QuickConnect), il faudra faire de la redirection du port 6690 en TCP sur la box "distante" vers le NAS2. Même chose côté "1" si NAS1 peut recevoir des données en plus de les transmettre.

1. Tu sauvegardes les données de ton conteneur, en plusieurs fois si besoin. 2. Tu supprimes le conteneur, tu supprimes l'ancienne image, et tu reconstruis le conteneur tel que tu l'as fait la première fois, sur base de la nouvelle image.

@StéphanH Si tu utilises un projet compose dans Container Manager, il suffit d'indiquer la nouvelle image dans la directive "image". Si en revanche tu crées ton conteneur sans passer par un projet, il te faut recréer un conteneur à l'identique en se basant toutefois sur l'image maintenue, càd homebridge/homebridge et pas oznu/homebridge

Bienvenue parmi nous @zebulon60

En jouant sur le pare-feu tu pourrais oui, mais pour peu que ton conteneur SWAG ou Docker déconnerait, tu perdrais l'accès à ton NAS. Je n'y vois pas un grand intérêt à titre personnel.

Bienvenue parmi nous, c'est bien l'usage principal d'un NAS, jusque-là aucun problème 🙂, n'hésite pas à créer un fil dédié pour en discuter plus avant.

Bienvenue tu es au bon endroit !

@CyberFr Je vais essayer de tourner les explications de mes collègues différemment. C'est quoi un code TOTP ? C'est une clé qui, une fois entrée dans un logiciel d'authentification 2 facteurs (quelque soit la plateforme : PC, Android, iOS, Extension de navigateur, etc...) permet de générer un code à 6 chiffres, qui se renouvelle. On peut utiliser cette clé sur autant d'applications et périphériques qu'on veut. Le code généré sera le même et variera au même moment. Il est donc prudent d'avoir a minima deux sources d'authentification 2FA, dans mon cas j'utilise Aegis sur mon smartphone, et je l'ai aussi dans Bitwarden. Avantage de Bitwarden, c'est que même si le serveur est down, j'ai accès au cache du coffre depuis mes différents périphériques. Le code TOTP défini par DSM lorsqu'un utilisateur applique la 2FA à son compte n'est affiché qu'une seule fois. Il est donc important de : L'écrire manuellement sur papier et de le conserver en lieu sûr, sans indiquer ce que c'est, moi je le garde dans mon portefeuille. Configurer cet accès sur deux périphériques a minima. Secure Signin est une version intégrée à DSM, absolument pas obligatoire et plus contraignante selon moi, comme tu as pu le constater. J'ajouterai que les remarques de @Mic13710 sont pertinentes dans le sens où le plus important est d'avoir des credentials robustes conjointement avec les blocages correctement configurés sur le NAS. Le reste est intéressant mais dispensable.

@Patrix Merci du retour, je vais intégrer la remarque.

Généralement on n'utilise qu'un seul proxy inversé à la fois. Ce que DSM fait, SWAG peut le faire. Acme gère ton domaine principal c'est ça ? Qu'est-ce qui t'empêche de le basculer sur SWAG ? Si tu as un cas concret à présenter pour voir ce qui pose problème. Si le but est de laisser le proxy inversé sur le NAS, SWAG n'a aucun intérêt. Acme est plus indiqué. Concernant l'erreur du script, après plusieurs essais on avait remarqué que si tu écris .210/29 tu tronques certaines IP. Si tu vas sur le calculateur de jodies, tu dois indiquer ce qui est noté dans "network" : https://jodies.de/ipcalc?host=192.168.0.210&mask1=29&mask2=

Welcome !

Si tu trouves un service VPN qui permet de faire du transfert de port. Comme tu le ferais avec ton routeur vers ton NAS.

@Dino Rayn Salut, j'ai bien parcouru ton post. Concernant les permissions il faudrait que je remette en oeuvre mon tutoriel, il a été rédigé il y a maintenant un certain temps, il se peut (c'est même sûr) que des étapes aient changé. Quoiqu'il en soit il est fort probable comme tu dis que les fichiers non visibles soient des liens symboliques. Il faut que je le confirme en reproduisant mon tutoriel. Pour le réseau macvlan et l'interface virtuelle, je note que tu as mis 192.168.50.210/29 dans une des déclarations et 192.168.50.208/29 dans l'autre, même si c'est censé couvrir la même plage autant spécifier des valeurs identiques. Concernant ton fichier conf pour Portainer il me semble ok. En revanche, si ton URL portainer.ndd.tld pointe vers Webstation, c'est que : - ta résolution DNS lui dit de le faire, donc vérifier si tu as un serveur DNS local et vérifier via un nslookup vers quoi pointe cette URL - tu n'as pas de résolution locale, en ce cas il est possible que la résolution soit publique, ce qui implique vu de l'extérieur, la redirection des ports 80 et 443 ne se fait pas vers SWAG mais vers le NAS - tu as potentiellement un cache persistant dans ton navigateur, supprimer donc les cookies liés à ton NDD ou faire un test en navigation privée. Dans ton cas, portainer.ndd.tld doit pointer vers l'IP de SWAG (.211) Je serais très étonné que tu puisses rediriger un même port vers plusieurs IP, sinon comment le routeur pourrait-il faire un choix ? le problème vient sûrement de là. Il faut effectivement que ces deux ports soient redirigés vers .211 Juste un peu de contexte, même si tu dois déjà le savoir. Par défaut, la meilleure manière de fonctionner pour SWAG est d'être dans un réseau bridge personnalisé. Ce qui se fait facilement quand les ports 80 et 443 de l'hôte sont libres, ce qui n'est pas le cas avec DSM. Dans ce contexte, tous les conteneurs qui ne nécessitent pas d'autre accès que via une GUI par exemple, n'ont aucune port exposé sur le NAS, ils sont simplement adjoints au réseau bridge de SWAG. Les fichiers de SWAG sont préconfigurés pour utiliser la résolution DNS interne de Docker, qui permet de joindre une application par le nom de son conteneur. Et dans ces conditions là uniquement, les fichiers conf sont utilisables sur le champ, si tu ajoutes le mod swag-auto-reload à ton instance, ça fait même en sorte que lorsqu'un fichier .conf.sample devient .conf, nginx est automatiquement rechargé pour en tenir compte. Ca c'est quand tu utilises SWAG sur un hôte libre, ou dans une VM. Dans notre cas, tu dois effectivement personnaliser l'upstream_app et l'upstream_port, mais rien de plus. Dans tous les cas, un fichier avec une extension autre que .conf ne sera pas actif.