.Shad.

CX explorateur de fichiers est un super utilitaire et permet le montage via Samba : https://play.google.com/store/apps/details?id=com.cxinventor.file.explorer

Non juste le premier post, normalement ça suffit. 😉

Autre manque, la possibilité d'ajouter une tabulation à la mise en forme, fonction qui était disponible dans l'ancien éditeur de texte. Je trouve que l'éditeur de texte a beaucoup perdu en qualité, contrairement à d'autres fonctions qui ont facilité l'utilisation du forum.

Les autres solutions sont la haute disponibilité, mais seulement pour certains NAS et ceux-ci doivent être identiques (modèle + version de DSM). Ou alors en passant par Docker Swarm, qui permet la haute disponibilité, il faut la même version de Docker sur les deux NAS. Mais si ton site Wordpress est accessible via proxy inversé, comment gères-tu le changement de redirection quand tu bascules sur le NAS2 si le NAS1 est inaccessible ?

Les MIB ne sont pas forcément nécessaires, ils permettent d'organiser les OID. Si la Livebox est "pollable" via SNMP, les informations sont tout aussi accessibles, mais c'est bien plus fastidieux d'identifier chaque valeur. 😉

Cette image couvre surtout un ensemble d'applications, pas seulement le proxy inversé : renouvellement automatique des certificats, hébergement de sites web, fail2ban, authentification deux facteurs, etc... Et surtout étendre ces fonctionnalités à toutes tes applications, pas seulement Synology. Maintenant la prise en main est plus complexe surtout pour la partie fail2ban et authentification deux facteurs. Deux aspects que je n'aborde pas dans le tutoriel. J'essaierai d'ici peu de décrire leur mise en place. Au départ je ne m'en servais que pour la partie création et renouvellement de certificats et proxy inversé, après avoir testé HAProxy sur pfSense, très bon logiciel mais surdimensionné par rapport à mon besoin. Depuis j'ai testé authelia (2FA) et je trouve cette image vraiment très bien pensée et réalisée, tout s'imbrique parfaitement. Je devrais pouvoir écrire un petit guide maintenant que j'ai un peu pratiqué ces aspects-là.

Oui enfin cette fois il y a quand même quelque chose à se mettre sous la dent contrairement aux dernières fois. 😄

👌 Je profite pour dire que j'ai corrigé une erreur signalée par @Jeff777 dans le script, vous pouvez soit re-télécharger le script soit modifier la ligne 207 : sed 's/${SERIAL}/\t${INCR_SERIAL}/' ${ZONE} > ${ZONE_TEMP} devient : sed "s/${SERIAL}/\t${INCR_SERIAL}/" ${ZONE} > ${ZONE_TEMP} (on remplace les quotes simples ' par des guillemets ")

La règle TOUS TOUS REFUSER du pare-feu doit arriver à la toute fin, car la résolution se fait séquentiellement. Dès que ça arrive à cette règle, ce qui suit ne compte plus. Et le port 1194 c'est pour OpenVPN, or tu ne t'en sers pas si j'ai bien compris.

Il n'a trouvé aucun dépôt privé auquel se connecter dans le fichier config.json Si tu n'en as pas ajouté, rien de plus normal. Plus d'informations ici : https://github.com/containrrr/watchtower/blob/master/docs/private-registries.md

Qu'on me corrige si je me trompe ( @jacaj ), mais FRX c'est disques CMR et FAX SMR, et tu as tout intérêt à utiliser des CMR.

Concrètement je ne vois pas d'intérêt de mettre à jour aussi souvent pour un particulier. Uniquement dans un environnement de développement en équipe. Et ces gens-là créent généralement leur propre dépôt auto-hébergé ou sur GitLab, et ne sont donc pas soumis aux restrictions (ou alors utilisent la version payante de Docker). Je trouve le cron bien plus adapté. 😉

Synchronisation et sauvegarde ce n'est pas la même chose, pour la sauvegarde tu as Active Backup for Business si tu as un NAS modèle "+", sinon pour la synchronisation tu connais déjà c'est Drive. Je ne vois pas de solution pour faire ceci en mode session fermée. Et je ne comprends rien à ta dernière phrase.

Tu n'as pas joué en SSH avec le fichier sshd_config ? Essaie d'utiliser Telnet au lieu de SSH, par contre pour corriger le problème il faudrait connaître la cause, ça n'a pas l'air d'être ton cas. En dernier recours, suivre la procédure officielle : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_reset_my_Synology_NAS Je pense que dans ton cas un reset mode 1 ne changera rien et il faudra passer par une réinstallation de DSM.

Les serveurs sont probablement américains, d'où le fait de réaliser le test sur des ports dont on autorise toutes les sources. Si tu as limité à la France c'est normal que ça ne fonctionne pas.

Pour compléter la réponse de @Lelolo : C'est 100 pulls par jour maximum pour la version community (gratuite) de Docker. Alors avec un intervalle de 300s tu y arrives vite.

Salut belle présentation, et tu as déjà pris tes renseignements c'est bien, on ne part pas d'une feuille blanche. 🙂 Tu n'auras aucun mal à te servir de ton NAS à l'étranger, essaie peut-être de te renseigner auprès des FAI locaux voir ce qu'ils autorisent ou non, typiquement : - Possibilité d'avoir une IP fixe (Free fait office de quasi exception en francophonie) - Possibilité d'ouvrir les ports 80 et 443 Autant l'IP fixe n'est pas fondamentale en soi (mais c'est un plus), autant le non-blocage de ports est primordial. Si tu pars en Belgique n'hésite pas, j'y réside depuis 10 ans bientôt je peux te renseigner. 🙂

À mon avis tu peux passer par l'installation manuelle via le centre de paquets. Mais je ne saurais pas te dire quel paquet utiliser par contre.

@Jeff777 Il va mettre à jour ton conteneur. Si il y a des ajouts par rapport à la version de base (python3 je crois ?) et s'il n'y a pas de volume monté comprenant l'ensemble des fichiers dont python3 a besoin pour fonctionner, il se peut qu'il disparaisse à la màj. Si c'est effectivement le cas, la solution la plus propre me semble d'utiliser cette fonctionnalité de watchtower : https://containrrr.dev/watchtower/lifecycle-hooks/ Tu crées un script qui va télécharger python3, l'installer, et faire tout ce qu'il y y a besoin de faire, le rendre exécutable et le mettre dans le dossier telegraf de ton NAS. Dans le compose, tu montes ce script à la racine du conteneur : ... volumes: - chemin/vers/script.sh:/script.sh ... labels: - "com.centurylinklabs.watchtower.lifecycle.post-update=/script.sh" ... Si je comprends bien le fonctionnement, une fois le conteneur telegraf recréé, il va exécuter ce script, à toi de faire en sorte que le script remette ton conteneur en état de fonctionnement.

Pour bien comprendre, 10.8.0.6 c'est l'IP VPN du client (le DS918+) et 10.8.0.5 l'IP VPN du serveur (le 213j) ? C'est déjà étrange que son IP soit en .5 s'il s'agit du serveur ? De plus dans ta capture d'écran HyperBackup, l'IP cible c'est celle du DS918+ (si j'ai bien suivi), ça risque pas de marcher. Essaie déjà avec 10.8.0.5 à la place. Ou .1 si ça ne donne rien. Je ne vois pas pourquoi ton serveur est en .5 honnêtement.

Bienvenue parmi nous 🙂

Clairement un Raspberry Pi sera plus indiqué.

Hello, pas à ma connaissance. Je crois que @oracle7 avait fait des recherches à ce sujet, mais aux dernières nouvelles ça n'avait rien donné.

Si tu as réglé sur une mise à jour par scheduling, la tentative de mise à jour ne se produira qu'à la date réglée. Si tu veux tester que ça marche tu peux utiliser interval à la place de scheduling.

Le chargement de fichier .env est une fonctionnalité de docker-compose, pas de Docker. Or Portainer n'utilise pas docker-compose mais la commande docker stack, qui est une fonctionnalité de Docker. Donc pour moi c'est logique. Si tu veux déployer watchtower avec Portainer, il faut soit supprimer le fichier env et intégrer les variables dans le fichier compose, ou mieux, utiliser la fonctionnalité docker secret. Exemple de comment se servir de docker secret : https://www.authelia.com/docs/configuration/secrets.html J'ai déjà essayé d'utiliser Portainer pour créer les conteneurs, j'avais même essayé d'y définir des variables d'environnement, problème : elles ne s'enregistraient pas. Du coup je reste avec docker-compose, qui me convient très bien.