Classement

Ce tutoriel nécessite DSM 6.2.4 ou une version ultérieure. Son but est de permettre à des clients macOS de se connecter à SSH sans avoir à fournir de mot de passe, que ce soit au niveau d'un compte administrateur ou du compte root. Ce tutoriel a été rédigé à partir de la contribution de référence du regretté unPixel : Et à partir d'une documentation émanant de Synology : Comment puis-je me connecter à DSM avec des paires de clés RSA via SSH ? Le tutoriel de unPixel est plutôt orienté PC et fait appel à des outils comme PuTTY, Pageant ou WinSCP totalement inconnus du monde Mac. Dans ce dernier on n'utilise qu'un seul outil, le Terminal. Il y a bien une partie consacrée aux environnements Mac et Linux ajoutée par @Fenrir mais toutes mes tentatives pour l'appliquer ont été vaines, du moins sous macOS Ventura. unPixel lui-même disait avec humour qu'il n'appliquait pas ce tutoriel sur son Mac et utilisait la bonne vieille méthode du mot de passe. C'est sans doute qu'il y avait quelque part un problème de mise en œuvre. Il est vrai qu'Apple, dont la dernière chimère est de de vouloir créer un système théoriquement inviolable, ne cesse de durcir de façon drastique les mesures de sécurité concernant macOS ce qui explique à mon avis les problèmes rencontrés qui sont des problèmes de droits. Bref, vous l'aurez compris, ce tutoriel est né d'une frustration. Pourquoi ça marche sur PC et pas sur Mac ? 😀 J'ai refondu la documentation de Synology et j'ai dû faire appel à leur support technique après avoir constaté qu'on ne pouvait pas l'appliquer en l'état. Le support a accepté d'ouvrir un ticket et a proposé des modifications qui se sont avérées déterminantes. Merci à eux. Facilité du tutoriel : FACILE si l'on maîtrise un peu l'interface en ligne de commande Durée : 20 minutes environ INTRODUCTION L’authentification par clés SSH (Secure Shell) fonctionne en utilisant une clé publique sur le NAS et une clé privée sur l'ordinateur local. La clé publique peut être placée sur n’importe quel serveur distant auquel on souhaite accéder. C'est d'ailleurs ce que nous ferons par la suite. La clé privée reste sur le Mac et n'est jamais communiquée à quiconque : lors du lancement de la session SSH le NAS envoie une requête à l'ordinateur local et c'est lui qui, en confrontant la clé publique transmise par le NAS et la clé privée qu'il détient, accepte ou pas l'ouverture de session. Le NAS ne voit qu'une chose, la réponse de l'ordinateur local et c'est oui ou non. Dans ce dernier cas l'ouverture de session est bien entendu refusée. Comme l'a dit @.Shad. que je me permets de citer « En gros la clé publique c'est ta réservation au restaurant, et la clé privée c'est le fait de prouver ton identité. ». SSH utilise des algorithmes de cryptage puissants pour sécuriser la communication entre le client et le serveur. Il garantit que les données transmises sur le réseau ne peuvent pas être interceptées ou modifiées par des entités malveillantes. Remarque : la mise en œuvre du tutoriel implique de faire des allers-retours constants entre le Mac (via l'application Terminal) et DSM. Suivez bien les instructions qui sont données car elles vous indiquent où vous vous trouvez et ne vous perdez pas ! N'hésitez pas à m'indiquer les difficultés que vous aurez pu rencontrer afin que j'améliore le tutoriel. De toute façon, si vous rencontrez des problèmes qui vous obligent à tout recommencer, la marche à suivre est décrite en fin de document. N'hésitez pas à m'en faire part là encore. Il est vivement recommandé pour des raisons de sécurité de changer le port par défaut de SSH dans le panneau "Terminal & SNMP" du Panneau de configuration. À chaque fois que vous verrez une commande "ssh ... -p XX" par la suite, remplacez XX par le port que vous avez spécifié. ATTENTION : N'ouvrez pas ce port sur votre box Internet car il doit être utilisé en local pour des raisons de sécurité une fois de plus. Si vous devez absolument vous connecter à SSH sur le NAS hors du réseau local utilisez un VPN. LANCEZ L'APPLICATION TERMINAL SUR LE MAC Inutile de la télécharger, elle est présente sur tous les Mac. Dans tout ce qui suit vous devrez remplacer "username" par par votre nom d'utilisateur sur le NAS et sur le Mac. Ils peuvent être différents (c'est le cas chez moi). Il faut faire attention au contexte dans ce cas afin d'appliquer la bonne substitution : Terminal Mac --> usernameX, SSH --> usernameY. GÉNÉRATION DES CLÉS On génère une paire de clés SSH à partir du Terminal du Mac avec la commande ssh-keygen en spécifiant l’algorithme de chiffrement désiré. J'ai retenu ed25519 qui est le plus sûr à ce jour : ssh-keygen -t ed25519 Vous êtes invité à saisir le chemin d'accès au dossier qui contiendra la clé publique et la clé privée. Laissez l’emplacement par défaut, à savoir : /Users/username/.ssh/id_ed25519 en appuyant sur Entrée. Vous êtes invité à saisir une phrase de passe (passphrase) pour la clé privée CE QUI EST VIVEMENT RECOMMANDÉ VOIRE INDISPENSABLE. Vous pouvez cependant l'ignorer en appuyant deux fois sur la touche Entrée si vous ne souhaitez pas saisir de passphrase à chaque fois que vous utilisez la clé. @Fenrir recommande, je cite « de protéger la clef avec un super mot de passe » et « de renouveler la clef de temps en temps (1 fois par an c'est largement suffisant) en pensant bien à supprimer la clef publique de l'ancienne ». La clé publique (id_ed25519.pub) et la clé privée (id_ed25519) ont été crées sur le Mac dans le dossier choisi plus haut. Il est possible de stocker la passphrase dans le Trousseau d'accès du Mac en utilisant ssh-agent mais je me méfie de cette solution que je n'ai d'ailleurs pas retenue pour deux raisons au moins : La passphrase dans le Trousseau n'est pas identique à la passphrase fournie à l'origine ce qui peut poser problème. De plus la passphrase peut être tronquée par rapport à l'original ce qui n'est pas normal et pose des problèmes de sécurité. C'est bien beau de définir une passphrase de 25 caractères s'il elle est finalement tronquée à 10 caractères dans le Trousseau... Je reproche au Trousseau d'accès d'être dépendant de la session utilisateur puisqu'il est débloqué automatiquement à l'ouverture de la session. Suite à un vol où le cambrioleur a physiquement accès à la machine, il est difficile d'être certain que le mot de passe de session ne sera pas décrypté. Dans tous les cas de figure il est nécessaire pour se connecter à SSH de connaître la passphrase, il ne faut pas faciliter la tâche des intrus en la stockant quelque part sauf dans des coffres sécurisé comme Vaultwarden ou 1Password qui ont leur propre mot de passe et ne sont pas débloqués automatiquement à l'ouverture de session. Vous devrez par la suite copier la clé publique (id_ed25519.pub) dans le dossier home de votre compte administrateur sur le NAS en utilisant File Station. Cette clé se trouve actuellement dans un dossier masqué sur le Mac (.ssh est masqué car précédé d'un point). C'est pourquoi ce dossier n'apparaîtra pas dans la fenêtre de File Station. Pour contourner le problème, le plus simple est d'utiliser le terminal. Il faut se positionner dans le dossier .ssh sur le Mac : cd ~/.ssh puis copier la clé à la racine de son home sur le Mac : cp id_ed25519.pub ~/id_ed25519.pub ENREGISTREMENT DE LA CLÉ PUBLIQUE DANS VOTRE COMPTE ADMINISTRATEUR SUR LE NAS Connectez-vous à DSM avec votre compte administrateur. Accédez à File Station. Dans votre dossier home créez un sous-dossier nommé .ssh (n'oubliez pas le point au début de .ssh). Transférez la clé publique id_ed25519.pub (qui est désormais visible) dans le dossier .ssh en utilisant l'onglet "Charger" de File Station comme illustré ci-dessous (lionel est mon dossier home). Il faut ensuite accéder au dossier home sur le Mac avec le Terminal et supprimer la clé qui s'y trouve afin de faire le ménage (on l'avait déplacé là afin qu'elle soit visible). cd ~/ rm id_ed25519.pub CONNEXION SSH ADMINISTRATEUR AVEC LA PAIRE DE CLÉS Connectez-vous à SSH avec votre compte administrateur sur le NAS. Un message d'avertissement apparaît : The authenticity of host '[192.168.1.2]:22 ([192.168.1.2]:22)' can't be established. ED25519 key fingerprint is SHA256:4nLwr4EVpCwt/jjH9kIEXDUaILvWhVXCzbDCzJv4z66. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? Ce message apparaît lors de la première connexion SSH ce qui est normal. Répondez simplement 'yes'. Warning: Permanently added '[192.168.1.2]:22' (ED25519) to the list of known hosts. Après, vous pouvez être déconnecté auquel cas vous aurez le message : Connection closed by 192.168.1.2 port 22 Il vous faut vous reconnecter dans ce cas. Si vous avez le message : username@192.168.1.2's password: On vous demande simplement votre mot de passe à la suite de quoi vous serez déconnecté de toute façon ! Pour des raisons qui m'échappent, les deux cas se sont produits lors des tests que j'ai réalisés. Pour faire simple dans tous les cas de figure reconnectez-vous ! Accédez au dossier .ssh précédemment créé sur le NAS : cd ~/.ssh Ajoutez la clé publique à un fichier, authorized_keys qui sera créé à cette occasion : cat id_ed25519.pub >> authorized_keys Le dossier .ssh sur le NAS contient désormais deux fichiers : authorized_keys et la clé publique id_ed25519.pub. Se positionner dans son home sur le NAS cd ~/ Puis taper les instructions suivantes où 711 donne les droits en lecture et en écriture au seul propriétaire (vous) et le droit d'exécution à tout le monde : chmod 711 .ssh chmod 711 .ssh/authorized_keys chown -R username .ssh/ Où username est votre nom d'administrateur sur le NAS. Ceci afin d'être sûr que les droits sur ces dossiers sont conformes aux règles. Ces instructions sont très importantes. La première partie du tutoriel est terminée. Vous pouvez maintenant vous connecter à SSH à l'aide de votre compte administrateur sans avoir à saisir un mot de passe. Mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés (ce qui, je le rappelle, est vivement recommandé). Par exemple : ssh username@192.168.1.1 -p XX Enter passphrase for key '/Users/username/.ssh/id_ed25519':_ CONNEXION SSH ROOT AVEC LA PAIRE DE CLÉS Sur le NAS, se connecter à SSH en tant que root à partir de votre compte administrateur en tapant "sudo -i". Soyez conscients qu'en tant que root vous avez tous les droits sur le NAS et qu'une erreur sur une commande peut provoquer des dommages irrémédiables. En cas de doute, il est préférable de copier les commandes du tutoriel et de les coller dans la session SSH. Exécutez la commande mkdir /root/.ssh afin de créer le dossier .ssh s'il n'existe pas. Il peut avoir été créé auparavant si des clés d'administrateurs autres que vous ont été consignées. Vous aurez dans ce cas le message d'erreur : mkdir: cannot create directory ‘/root/.ssh’: File exists qui est sans gravité. Accédez à votre propre dossier .ssh sur le NAS qui se trouve dans votre dossier home : cd /volume1/homes/username/.ssh où volume1 est le volume dans lequel se trouve le fichier id_ed25519.pub et username votre nom d'utilisateur sur le NAS. On crée le fichier authorized_keys de root s'il n'existe pas et on ajoute la clé publique id_ed25519.pub. cat id_ed25519.pub >> /root/.ssh/authorized_keys Entrez la commande chmod 700 -R /root/.ssh afin d'être certain que tout ce qui se trouve dans le dossier .ssh n'est accessible qu'au compte root et ceci est très important (700 donne l'exclusivité de tous les droits à root). ON REDÉMARRE LE SERVICE SSH POUR QUE LES CHANGEMENTS SOIENT PRIS EN COMPTE DSM6 : synoservicectl --reload sshd DSM7 : systemctl restart sshd Vous pouvez maintenant vous connecter en tant que root sans avoir à saisir de mot de passe mais la passphrase sera demandée si vous l'avez renseignée lors de la génération des clés comme indiqué plus haut. Par exemple : ssh root@192.168.1.1 -p XX Le tutoriel est terminé. MODIFIER LA PASSPHRASE Lancer le Terminal sur le Mac et taper : ssh-keygen -p -f ~/.ssh/id_ed25519 On demande l'ancienne phrase de passe puis la nouvelle. Il faut parfois relancer le service SSH pour que le changement soit pris en compte. Le plus simple est d'essayer de se connecter en tant que root avec la nouvelle passphrase et, si elle est refusée, de saisir l'ancienne. Les changements n'ont pas été pris en compte dans ce cas et il faut utiliser la commande de redémarrage du service SSH indiquée ci-dessus (celle-ci nécessite les droits root). EN CAS D'ERREUR LORS DE LA MISE EN ŒUVRE DU TUTORIEL QUI VOUS OBLIGE A TOUT RECOMMENCER NB : Ces instructions ne s'appliquent que si vous êtes le seul administrateur du NAS ou si vous avez créé une session SSH avec paire de clés pour la première fois. Si un historique préexiste n'hésitez pas à me contacter. Connectez-vous à SSH en tant que root sur le NAS et supprimez son dossier .ssh : rm -R .ssh Connectez-vous à SSH avec votre compte administrateur sur le NAS et supprimez le dossier .ssh qui se trouve dans votre dossier home : rm -R .ssh Lancez l'application Terminal et supprimez le dossier .ssh qui se trouve dans votre dossier home sur le MAC : rm -R .ssh VOUS AUREZ COMPRIS QUE CES ACTIONS SONT IRRÉVERSIBLES ! CRÉATION D'UN FICHIER DE CONFIGURATION SUR LE MAC Un fichier de configuration permet de définir des profils par défaut (hosts) en renseignant l'adresse IP du serveur, le nom d'utilisateur sur le serveur, le port utilisé par SSH et le chemin d'accès à la clé privée. Ainsi au lieu de taper ssh username@192.168.1.1 -p XX pour initier une session SSH, il suffit de taper ssh username Il est possible de créer dans le fichier de config plusieurs hosts avec des adresses IP différentes ce qui permet de se connecter à des serveurs distincts. Ne créez un fichier de config qu'après de la mise en œuvre complète du tutoriel lorsque vous serez sûr que tout fonctionne. # point d'entrée : tapez ssh server_1 pour vous connecter Host server_1 HostName 192.168.1.1 # nom d'utilisateur sur le serveur User username Port XXX # Chemin d'accès à la clé privée IdentityFile ~/.ssh/id_ed25519 Host nas HostName ndd.fr User cyberfr Port XXX IdentityFile ~/.ssh/id_ed25519 Host root HostName 192.168.1.2 User root Port XXX IdentityFile ~/.ssh/id_ed25519 Le fichier de configuration doit être placé sous le nom "config" (sans extension) dans le dossier .ssh de votre home où résident déjà les clés publiques et privées id_ed25519 et id_ed25519.pub. Le plus simple est de le rédiger dans un traitement de texte (TextEdit ou BBEdit) puis de le déplacer au bon endroit. Il vaut mieux respecter le canevas des exemples donnés ci-dessus et ne pas utiliser de tabulations (je n'ai pas essayé donc je ne sais pas si elles sont acceptées 😀).

Bon, le [TUTO] Se connecter à SSH avec une paire de clé sur Mac est réapparu 😀

En complément de ce que dit @.Shad., tu peux confier la clé à un gestionnaire de clés intégré mais le problème est que le volume est monté automatiquement lors du démarrage de DSM. C'est pourquoi je préfère monter le volume lorsque j'en ai besoin. J'ai signalé il y a quelque temps qu'un container démarrait lorsque j'allumais le NAS alors qu'il était réglé sur "--restart never" qui est la valeur par défaut, valeur que je vois dans les propriétés du container. Mon problème venait justement du fait que ce container est associé à un volume crypté et que si ce dernier n'est pas monté, cela provoque bien entendu une erreur. C'est donc un bug de DSM et j'ai été obligé pour le contourner d'écrire un script pour arrêter manuellement le container. Suite à ce bug que j'ai signalé au support, "--restart never" s'est transformé en "--restart unless-stopped" dans Container Manager.

Refonte du tutoriel prévue pour Pâques je pense, j'ai revu le compose et l'architecture pour faire quelque chose de beaucoup plus simple. La nouvelle version sera plus directe, et à l'image de mon récent tutoriel de sécurisation pour DSM 7, j'intégrerai des balises spoilers pour ceux qui veulent plus de détails et remarques.

Salut, Je ne pense pas car il avait toujours le statut "démarré depuis 45 jours" alors que les autres avaient bien sûr +/- 1 minute. Finalement, j'ai redémarré le NAS qui... n'a pas redémarré. Ensuite un shutdown comme un bourrin avec le bouton Power. Finalement, après une petite suée ;-), il a redémarré et... Flaresolverr aussi ! Ouf. Georges

Welcome 🙂

Bienvenue parmi nous !

Bonjour et bienvenue sur le forum @Cindy Sauvage ! Belle machine que ce DS 423. N'hésite pas à poser des questions si nécessaire.

Bonjour et bienvenue sur le forum @Will31 !

Je réponds à mon post car j'ai enfin trouvé mon erreur!! Comme souvent c'était une simple erreur et je cherchais compliqué... J'ai tout désinstallé et réinstallé. J'ai procédé par étape en vérifiant que mon raspberry envoi bien une donnée $_POST avec la librairie resquests. import requests url = 'http://monsite.com/mon_fichier_qui_gere_l_insertion_BDD.php' myobj = {'temperature':'46.4', 'humidite': '55.4'} # Utilisez des points au lieu de virgules pour les décimales x = requests.post(url, data=myobj) print(x.text) J'ai affiché cette valeur sur la page web. <?php // ici on récupère la variable passée en $_POST ou en $_GET echo $_POST [ 'temperature' ] ; echo $_POST [ 'humidite' ] ; print_r($_GET); print_r($_POST); ?> Une fois cela fait, l'erreur ne pouvait-être que côté serveur. En me disant ça j'ai compris que même si l'information vient d'un raspberry, elle est traité en "localhost" par le serveur. Donc il ne faut pas mettre autre chose que "localhost" dans le nom de l'host lors de la connexion à la BDD... Même l'adresse IP publique du serveur ne fonctionne pas pour info. Voila voila...

@CyberFr, j'abonde dans le sens de @.Shad.. Ce n'est parce qu'un tuto n'a pas de réponse qu'il n'est pas lu ou qu'il n'a pas été mis en pratique par certains, membres ou pas. Et dans le cas présent, il aurait été au moins utile @MilesTEG1.

@CyberFr C'est très dommageable, parfois certains tutos mettent du temps à trouver leur public, d'autres ne le trouvent jamais. Pourtant je ne vois pas pourquoi priver la communauté d'un travail qui m'a pris du temps, ici 0 réponse 1900 vues 😄 :

Bon j'ai finalement récupérer l'accès internet, j'ai fait une mise a jour manuel mais cela n'a rien changé, j'ai remis mes paramètre DNS en DHCP puis passer la date et heure en manuel et après plusieurs tentative de sycro avec les serveur time cela a fini par fonctioner et la connexion est revenue. Je ne sais pas réellement si c'est la maj qui a régler le problème, je vais remettre toute ma config réseau comme je l'avais avant en espérant que je n'ai pas de nouveau problème 🙂

OK, mais comme tu me le fais justement remarquer dans les infos Donc, Je vais pas tenter le diable, on va suivre les conseils de M Syno😉, bien que connecté pour recevoir les mises à jour, il me sert uniquement de sauvegarde horaire/journalière perso et je n'ai pas envie de me retrouver dans la situation de mon 210 qui faisait semblant de fonctionner alors qu'il se vérolait pour cause de carte mère endommagée. Merci pour ta réponse.

Ou pour l'update 6 😅

Non, pas nécessaire. Oui, mais commence par utiliser le port par défaut 1194 en UDP. Si ça fonctionne tu pourras essayer de changer. ??? Non tu laisses faire tu ajoutes un 6 après proto udp donc proto udp6

Aucun des deux. Le système le plus sûr pour protéger les données est la sauvegarde. btrfs t'apportera plus de souplesse pour les snapshots (si utilisés). Il n'y a pas de contrôleur RAID sur les NAS Synology, c'est juste du RAID logiciel. Prends le temps de t'informer sur le RAID : https://fr.m.wikipedia.org/wiki/RAID_(informatique) Le plus important dans tes choix est de savoir quel système de sauvegarde tu vas utiliser.

Comme ça, le jour où ton NAS se prend un cryptolocker, tous les fichiers du disques 1 et leurs sauvegardes sur le disque 2 sont cryptés 😅 Utilise un disque USB externe pour faire les sauvegardes, et déconnecte-le du NAS entre les sauvegardes.

ça ne fonctionne que si tu fais du DHCPv6. Normalement il faut mettre son préfixe à cet endroit mais en SLAAC tu ne peux pas le rentrer. En tout cas chez moi cette cette case n'est pas cochée et je me connecte en IPV6 sur Openvpn.

Bienvenue @maximax88

Bienvenue parmi nous, projet super sympa, au plaisir de pouvoir t'aider.

Bonsoir, Je ne savais pas qu'il y avait des FAI qui ne faisait que l'IPV6 publique. Je ne suis pas certain de pouvoir t'aider mais ce qui m'étonne c'est que ton test IPV6 montre une IPV4 et je ne pense pas qu'il affiche ton IPV4 privée. Sinon personnellement j'essaierai ceci : 1 / utilise le port UDP 1194 pour Openvpn (autorise ce port dans ton pare feu) 2/sur le nas tu décoches le serveur DNS, c'est celui du DHCP qui sera utilisé (configuré dans ta box) et au dessus tu renseignes l'IPV6 privée de ta box. 3/Une fois la config exportée tu la renseignes avec : remote "MonIPV4publique" 1194 remote "MonIPV6publique" 1194 et proto udp proto udp6 Si ça ne marche pas avec l'IPV4 indiquée par le test IPV6 tu attends plusieurs minutes et le VPN basculera tout seul vers l'IPV6. Si c'est le cas tu ne garderas que l'IPV6. Je ne te garantie pas que ça fonctionnera mais ça vaut la peine d'essayer. Bonne chance

@skelton Pas de problème, vous pouvez créer un nouveau groupe et un nouveau volume sur votre disque de 4To. A charge ensuite de créer de nouveaux dossiers partagés sur ce nouveau volume, ou de déplacer des dossiers existants du volume 1 vers le volume 2.

Votre disque est bien là, et votre stockage total est réparti sur 2 volumes de 7To chacun. Vous ne pouvez pas voir les disques dans File Station. Seulement les dossiers partagés. C'est à vous à répartir vos dossiers partagés sur les volumes à partir du panneau de configuration.

RESOLUE excellent merci pour tous sa marche et sa va vite... Meme plus le temps d'attendre... 😄

Bonjour @Darkangel, on peut mettre 16Go de Ram sur un DS918+ d'après certain site, exemple https://www.cachem.fr/16go-ram-synology-ds918/

Bonjour à tous, Nous allons voir dans ce tutoriel comment mettre en place rapidement un certificat Let's Encrypt avec la méthode acme.sh en utilisant l'api Ovh en Docker, si vous êtes rapide, en 10 minutes c'est en place. Pourquoi en docker ? Car je suis contre la pollution du DSM, des corruptions par update, mais aussi par simplicité et rapidité. 1) On commence par la création de clé d'api chez ovh : https://api.ovh.com/createToken/?GET=/domain/zone/mydomain.com/*&POST=/domain/zone/mydomain.com/*&PUT=/domain/zone/mydomain.com/*&GET=/domain/zone/mydomain.com&DELETE=/domain/zone/mydomain.com/record/* On remplit donc le formulaire, pour "Validity" (1) on choisit "Unlimited", pour "Rights" (2) on remplace dans les champs "mydomain.com" par le vôtre et dans "Restricted IPs" (3), on rajoute son IP afin qu'en cas de vol des clés, elles ne puissent être exploitées et votre domaine détourné. (NB : Si vous n'avez pas une IP fixe, on passe ce dernier point) On garde les clés retournées en résultat sous la main pour la suite. 2) Passons maintenant au docker : A) On commence par la création d'un dossier "Acme" dans le dossier docker. B) La création du fichier de config : On crée avec l'éditeur de texte du DSM (Codage UTF-8) le fichier "account.conf" à la racine de notre dossier "Acme" contenant : LOG_FILE="/acme.sh/acme.sh.log" LOG_LEVEL=1 AUTO_UPGRADE='1' #NO_TIMESTAMP=1 USER_PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' SAVED_OVH_AK='XXXXXXX' SAVED_OVH_AS='XXXXXXX' SAVED_OVH_CK='XXXXXXX' DEFAULT_ACME_SERVER='https://acme-v02.api.letsencrypt.org/directory' On remplace dedans le contenu des 3 variables "SAVED_OVH_**" par nos clés obtenues précédemment par OVH. C) La création du docker : On va mettre un petit peu de code pour la création du docker et son actualisation journalière via le gestionnaire de tâche... Panneau de configuration / Planificateur de tâches / Créer / Tâche planifiée / Script défini par l'utilisateur Utilisateur : Root On programme pour une exécution par jour la nuit (5h c'est bien) Exécuter la commande : docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemon On exécute manuellement la tâche une première fois pour la création du docker. C Bis) Le docker-compose.yml : version: "2.1" services: acme: cpu_shares: 10 mem_limit: 128M container_name: Acme network_mode: bridge labels: - com.centurylinklabs.watchtower.enable=true volumes: - /volume1/docker/Acme:/acme.sh:rw restart: unless-stopped image: neilpang/acme.sh:latest command: daemon D) Création du certificat : Avec le planificateur de tâche en exécution unique (cf point 2C) ou en ssh (root) en remplaçant "mydomain.com" : docker exec Acme sh -c "acme.sh --issue --keylength 4096 -d 'mydomain.com' -d '*.mydomain.com' --dns dns_ovh" Il n'y a rien à détailler pour expliquer cette commande, le keylenght peut être, on double la valeur par défaut qui est aujourd'hui considérée comme faible à 2048. /!\ Renouvellement automatique du certificat sans action de votre part 3) Installation des certificats : A) Importation manuel : Vos certificats seront disponibles directement dans filestation "docker/Acme/votredomaine" et ce qui nous intéresse dedans : Certificat : mydomain.com.cer Clé privée : mydomain.com.key Certificat intermédiaire : ca.cer On va maintenant faire leur import manuellement, dans "Panneau de configuration/Sécurité/Certificat". En cas d'import manuel, vous pouvez activer la notification mail, mais cette action se réalise toujours 1 mois avant expiration : https://github.com/acmesh-official/acme.sh/wiki/notify B) Déploiement automatique : NB : Faire un premier déploiement manuel avant le déploiement automatique, afin de bien le mettre par défaut et supprimer celui de synology par défaut. 1) Création d'un compte que l'on rajoutera dans le groupe admin, on lui mettra aucun acces à tous les dossiers et refuser à toutes les applications, on active pas la double authentification qui sera inutile. 2) On ré édite notre fichier "account.conf" créé au point 2B, on y rajoute : SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='nom utilisateur' SAVED_SYNO_Password='le password' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='description du certificat mise dans le DSM' 3) Ensuite une fois les modifications faites, avec le planificateur de tâche en exécution unique (Cf point 2C) ou en ssh (root) : docker exec Acme sh -c "acme.sh --deploy -d 'mydomain.com' --deploy-hook synology_dsm" Guide officiel : https://github.com/acmesh-official/acme.sh/wiki/Synology-NAS-Guide Pour d'autres API que ovh : https://github.com/acmesh-official/acme.sh/wiki/dnsapi 😉

Bonjour, Je viens de prendre un compte premium 1fichier. Je viens d'installer le fichier host sur mon ds223 avec clé api et ça marche impec 😊. Je poste donc pour dire merci Mathieu et longue vie à ton appli.

Bonjour @Thibab, Oui ABB permet de sauvegarder tout un volume (mais pas un seul dossier). Par contre tu peux restaurer le volume, un dossier ou un fichier. Pour limiter la sauvegarde à un dossier c'est possible avec le client Drive sur PC : avec Tâche de sauvegarde. Effectivement certain dossiers système n'apparaissent pas mais paut-être une piste : on peut accéder à User et en rendant visible App Data on a accès aux paramètres perso des applications.

Salut, Alors les détails : J'ai paramétré la sécurité du Nas : (anti-brut force, double authentification, et deux trois réglages) Pour l'accès j'ai activé Quickconnect, j'ai fait une redirection dyndns avec un domain.synolgy.me et changer les port par defaut de dsm Cela fonctionne bien je peux accéder à dsm depuis l'exterieur avec domain.synology.me ou avec une redirection dns sur un nom de domain perso. DSM et les outils audio station, synology contacts, note station, synology calendar pas de problème, je fais des partages entre utilisateurs c'est assez intuitif Mias dès que j'installe Plex ou une appli doker comme vaultwarden j'ai beau m'accompagner des tutos, (les étapes semble logiques), impossible d'accéder à ces briques : la page repond pas PUNAISE : En revérifiant dans sécurité j'avais activé ou c'était par défaut le firewall, ba forcement avec une règle ca marche mieux !! Désolé: les gens vérifié le firewall, dans les paramétrages - sécurité

Le fichier host ne gère aucun téléchargement, la seul chose qu'il fait c'est fournir une url de téléchargement à l'application DL Station. Si il y a un problème c'est entre DL Station et les serveurs de 1fichier Si ça te dit on peut debuger en MP. Si tu n'a pas de fichier perso sur ton compte tu peux me donner ta clé d'API en message privé pour que je fasse des essayé, tu en génereras une nouvelle une fois que nous aurrons trouvé. On peut sa caller une scéance de debug par discord aussi si nécéssaire.

Tu peux : - soit définir un host manuel sur ton PC (si Windows), il faut éditer le fichier C:\Windows\System32\drivers\etc\hosts et ajouter une ligne : 192.168.1.52 xxxxxx.synology.me Bien entendu, tu dois adapter l'IP du NAS et le DDNS à ton cas. - soit mettre en place une zone DNS locale, mais c'est un sujet plus complexe :

@Steph Bollo merci de ne pas intervenir dans une discussion sans prendre le soin de lire les réponses et en comprendre le contexte. Par ailleurs, je vous invite à ouvrir un sujet dédié à votre problème. @Darkangel Les disques sont bien extractibles à chaud.

Il faut désactiver le disque défectueux dans le gestionnaire de stockage avant de le retirer.

Pour ma part, j'ai effectué aujourd'hui la réinitialisation en configuration usine de mon RS422+. J'avais une grosse sauvegarde Hyper Backup de 1.5 To de données "importantes", tout a été restauré sans erreur (sauf le service d'application Synology, mais ça n'a pas eu l'air d'avoir la moindre incidence car le service tourne normalement). Pour les données dispensables, elles étaient stockées sur des disques externes, en format brut, là ça copie... c'est long 😄 Première chose que j'ai vérifiée, la taille de la partition, c'est ok de ce côté-là, 7.9Go, je devrais être tranquille de ce côté-là. Et j'ai profité de la réinitilisation pour chiffrer mon volume. Ah, mes tâches récurrentes de tests SMART avaient disparu, alors que j'avais coché la restauration de la configuration du planificateur de tâches, étrange.

et on s'y prend comment pour modifier les autorisations d'un compte dans MySQL ? (j(utilise phpMyAdmin pour l'administration) Evidemment puisque mon instance FreshRSS hébergée en direct sur le NAS fonctionne Ah je vais tester ça de suite je n'ai utilisé que des connexion locale jusqu'ici **** EDIT **** Ah non c'était déjà coché. A la réflexion le socket était en écoute sinon je ne pouvais pas me connecter même en localhost. La preuve : ~> sudo lsof -i :3307 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME mariadbd 18603 mysql 26u IPv4 131189062 0t0 TCP *:3307 (LISTEN) Et j'ai bien pensé à ajouter une règle dans le firewall pour autoriser les connexions entrantes en provenance de l'IP du container Docker

Bonsoir, Ayant formaté les disques de mon Syno pour gagner une partition root de 8Go au lieu des 2 pauvres giga, j'ai du refaire mes conteneurs, dont ACME. Et à l'étape 3B, j'ai une erreur : 20:08:56 - Script pour paramétrer le déploiement automatique des certificats sur le Syno. 20:08:56 - Exécution de la commande... [Mon Mar 25 19:08:56 UTC 2024] Logging into 172.20.0.1:19810 [Mon Mar 25 19:08:57 UTC 2024] Getting certificates in Synology DSM [Mon Mar 25 19:08:57 UTC 2024] Unable to find certificate: mon-ndd.ovh - Certificat Wildcard Lets Encrypt & $SYNO_Create is not set [Mon Mar 25 19:08:57 UTC 2024] Error deploy for domain:mon-ndd.ovh [Mon Mar 25 19:08:57 UTC 2024] Deploy error. 20:08:57 - Script de création du certificat wildcard terminé En regardant les réponses du sujet, je me suis dit que ça devait être un problème de nom de certificat. Et oui, le nom de la variable SYNO_Certificate doit être identique au nom mis dans DSM, sinon on a l'erreur précédente. Bref, tout fonctionne bien maintenant 😉 Pour le peu que je vais me servir du certificat de mon .ovh dans DSM 😅

À chaque fois que j'ai contacté le support Synology pour signaler un bug dans DSM ça a été la même chanson. Monsieur, c'est à vous de faire les tests, Monsieur, mettez le NAS à disposition de nos équipes, Monsieur, envoyez-nous vos journaux, etc. Je ne trouve pas normal, et d'ailleurs je l'ai signalé, que suite à la découverte d'un bug, ce soit au client de faire le boulot.

Je viens de faire le contrôle chez moi, et j'ai un md0 à 2,3 Go, donc je pense que pour toi c'est bon

Désolé d'avoir contrarié Lelolol !! voilà c'est fait

@MilesTEG1, sisi je garde le macvlan, pas le choix sur DSM, mais j'intégre SWAG aussi dans un bridge personnalisé dans lequel se trouve Authelia, ainsi rien à changer dans les fichiers de configuration d'authelia, on peut continuer à utiliser le nom de conteneur.

Epilogue... Tout d'abord merci @firlin pour l'aide apportée. Mais de 1) oui j'étais pressé, et de 2) je tenais à rester le plus loin possible du support Synology, car c'est grâce à leurs "bons conseils" que mes dernières opérations (principalement la migration de mon DS920+ vers un DS923+) ont failli tourner au désastre. Je me suis donc lancé dans la reconstruction totale, méthodique et manuelle de mon DS923+, sans importer le moindre paramètre du DS920+. Et là, question taux de transfert, je n'ai pas été déçu: on est à 500Mb/s minimum entre PC et NAS, avec des pointes à plus de 1Gb/s alors que mes valeurs MTU sont encore à 1500... ça promet ! J'étais ravi, et évidemment restaurer mes données à cette vitesse n'a été qu'une formalité. J'ai finalisé ma configuration en réinstallant Tailscale et en relançant un backup distant. Je sauvegarde mes données sur un site externe, sur un DS218Play qui est derrière un routeur 5G. Mon opérateur ne me permettant pas de faire du port forwarding, j'utilise Tailscale pour contourner le problème. Et ça marche plutôt bien ! Tailscale est installé sur le DS218Play qui reçoit le backup, sur mon PC (pour administrer le DS218Play distant), et donc pour terminer, sur le DS923+ pour lui permettre de communiquer avec la cible du backup. Mais deux jours plus tard, j'ai failli m'étrangler lorsqu'en voulant relancer une copie du PC vers NAS, j'ai constaté que mon débit maximum en copie était retombé à 140Mb/s... Qu'est-ce qui avait changé entre temps ? Rien, à par Tailscale... Et là instantanément je me suis rappelé que 140Mb/s devait plus ou moins être le débit maximum lorsque l'on passe à travers les serveurs Tailscale, mais en ne comprenant pas comment la présence de Tailscale pouvait être en mesure d'impacter une copie locale entre un PC et le NAS ? Et pourtant cela semble bien être le cas, lorsque Tailscale est installé sur les deux machines source/cible. Tailscale semble littéralement prendre ma copie locale "en otage", et cela se complique encore avec un problème qui relève manifestement du DNS... Tout ça pour dire que: Copie du PC vers \\DS923\Video ==> débit maximum de 140Mb/s Copie des mêmes données du PC vers \\[IP.DE.MON.NAS]\Video ==> débit maximum de 1000Mb/s CQFD. J'ai simplement adapté mes mappings pour résoudre le problème (en utilisant l'IP du NAS plutôt que son nom DNS).

@MilesTEG1 Si Portainer central est installé sur A, et que tu te connectes à B via Portainer agent, les données sont stockées sur B. Portainer n'est qu'une interface plus évoluée de Container Manager. Ce que tu pourrais rencontrer par contre ce sont des stacks orphelines lors de la restoration, si Portainer n'arrive pas à refaire lui-même le lien avec un dépôt Git.

Petite MAJ 🙂 J'ai lancé les sauvegardes temporaires, ça prend du temps 😅 Cependant, je n'ai pas eu d'erreurs sur les sauvegardes à destination de l'Asustor, seules les sauvegardes à destination du cloud K-Drive me font une erreur de partition système : Je ne comprends pas trop pourquoi... Ça m'a l'air assez aléatoire en prime, car parfois je n'ai pas d'erreurs... Bref, j'ai coupeécertains services comme Synology Photos, et Surveillance Station, pour éviter les données de dernières minutes à sauvegarder. Faudra que je fasse pareil avec Container Manager, pour faire la sauvegarde des conteneurs. J'ai aussi remarqué que quand Vitual Machine Manager est installé, avec donc Open vSwitch activé, la sauvgegarde de la configuration du Syno ne contient pas tout : Dès lors que Open vSwitch est désactivé, tout est bien sauvegardé. Pour ne pas être embêté, la semaine dernière j'ai déplacé le reverse proxy SWAG sur un NUC, et aussi Vaultwarden. Il va me falloir faire de même pour ma deuxième instance de Adguard Home. Ainsi je n'aurais plus besoin de macvlan sur le NAS, et ça m'ôtera un problème potentiel après. J'ai aussi sorti le disque 3 du NAS, celui qui contient les sauvegardes des instances proxmox, et aussi celui qui potentiellement à une partition système de 8Go. Voilà voilà @+ quand j'aurais d'avantage de nouvelles

Je viens de regarder ton lien et ce que je lis me fait dire que ça ne peut en aucun cas venir des disques. Il est absolument impossible que 6 disques tombent en panne simultanément sans qu'il y ait une cause externe. Problème de NAS ? d'alimentation (surtension) ? C'est beaucoup plus probable. Tu ne devrais pas trop t'inquiéter pour tes disques.

Merci pour votre aide. Finalement j'ai essayé de télécharger et mettre à jour à nouveau la dernière version DSM 7.1.1-42962 update 6 ..... SURPRISE !! tout s'est bien déroulé avec mises à jour des paquets et tout semble refonctionner maintenant ... ouf !! Merci encore et bon courage à vous

Si ej me trompe pas tu as un DS723+ donc les chariot de ceux-ci sont compatible avec un SSD. En effet sur les chariot tu as 4 trous pour fixer les SSD dessus, à vérifier mais cela doit fonctionner

Bonjour à tous Je viens de m'inscrire sur le forum. En fait, ça fait quelques années déjà que je le parcours, mais j'ai décidé de m'inscrire car j'ai une question (j'ai déjà créé un post). Donc voilà, j'ai la quarantaine, je vis dans le sud de la France. J'ai un Synology DS118 depuis 6 ans, avec un HDD WD 6 To, et je vais avoir un DS224+ dans très peu de temps. Mon métier ne conserne pas le milieu de l'informatique, mais c'est un domaine qui me plait et j'adore apprendre plein de trucs/bidouiller. Actuellement, je me sers de mon NAS principalement pour du stockage de données perso et pour PLEX. Je vais bientôt me lancer dans Docker et Home Assistant. Au plaisir de vous lire.

En voici un archive.zip

@Vista1967 En temps normal j'essaie de lancer les images de mon côté, mais je ne le fais pas avec des conteneurs qui demandent des privilèges élevés et pour des images aussi peu répandues. Si tu cherches un soft qui permet de faire du boot network PXE sous Docker, regarde du côté de netbootxyz par Linuxserver : https://docs.linuxserver.io/images/docker-netbootxyz/ Beaucoup mieux documenté et pour l'avoir installé chez moi ça fonctionne très bien.