Mic13710

Je ne vois pas ce que vous pouvez faire au niveau de DSM. Il faudrait passer en ssh pour réparer le volume. Je crois me souvenir qu'il y a déjà eu cette opération décrite quelque part sur le forum, mais je ne me rappelle plus où. Le mieux dans votre cas, surtout si vous n'êtes pas familier du mode terminal, c'est de contacter le support via DSM pour qu'ils interviennent sur votre groupe.

J'ai suivi les conseils de @.Shad.. Après avoir créé un enregistrement A sur ndd.net pointant vers l'adresse d'OVH et un CNAME *.ndd.net, je viens de mettre en place un certificat qui couvre tout le domaine. Pas de problème pour la création, mais là aussi, le TXT n'est pas supprimé dans la zone. J'ai suivi l'état de la zone pendant la création et comme je l'avais vu dans les logs précédents, il y a 2 enregistrements TXT qui sont créés pendant le processus. Un à bien été détruit mais l'autre non. Ce qui tendrait à indiquer que le DELETE fonctionne, mais qu'il y a un truc qui ne passe pas. Je vais m'occuper de l'autre NAS qui est un 214+, ce qui m'oblige à passer par un script dans DSM (pas de Docker sur ce modèle)

Tu as probablement raison. Je referai un nouvelle API un peu plus tard. Pour le moment, je vais me pencher sur les certificats pour les deux domaines dont j'ai parlé dans ce sujet.

Effectivement, il y a une erreur plus loin, ce qui explique qu'il ne soit pas supprimé. Par contre, difficile d'en comprendre la raison. La lecture de ces logs est un peu difficile. Non, c'est bien un enregistrement créé par acme.sh (il a le même texte que dans le log), et je n'avais pas d'enregistrement TXT avant de faire la création via acme. OK pour le delete manuel, je peux faire ça. Mais je ne vais pas le faire après chaque renouvellement. Il faut donc que je sois sûr que la présence d'un enregistrement TXT n'interdit pas la création (ou sa maj) d'un nouveau texte au prochain renouvellement.

Liste des disques 4To compatibles avec votre NAS : https://www.synology.com/fr-fr/compatibility?search_by=products&model=DS210%2B&category=hdds_no_ssd_trim&filter_size=4TB&p=1 Pour info, la liste complète s'étend jusqu'à 8To

Merci à tous les deux. Parce que c'est le cas actuellement avec des CNAME en dur dans la zone. Je souhaitais simplement partir sur la même base. Ce qui m'ennuyait c'est que je n'ai pas d'enregistrement A pour ndd.net. Je n'avais pas pensé le faire pointer vers OVH. Tu viens de me donner la solution. Je vais faire un certificat commun aux deux NAS sur le ndd.net. Puisque le TXT est en principe supprimé, je ferai le même processus pour chaque NAS afin qu'ils soient totalement indépendants l'un de l'autre. Pour ces fameux enregistrements TXT, je les vois bien actuellement apparaitre dans la zone pour chaque CNAME lorsque je crée un certificat selon la méthode en place, puis disparaître ensuite. Par contre, j'en ai créé 2 avec Wildcard via Docker pour mes propres domaines suivant le tuto d' @Einsteinium l'un sur OVH et l'autre sur Gandi et j'ai toujours les TXT dans leur zone respective. Pourtant, l'API sur OVH a été créée suivant le tuto avec les bons token à savoir : 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/* Il y a bien le DELETE. Pour Gandi, la chose est plus simple puisqu'il n'y a qu'une seule API et que je ne sais pas ce qu'elle permet, ou pas. Quel serait le risque si je tente de recréer un nouvel enregistrement TXT alors qu'il en existe un ? Au pire, il corrige la donnée de l'existant non ? J'ai bien ce log et la suite : Removing txt: O94fVTKz4yIdHQRl7xZddjc4C7u3fI3jm5Kcb1DGW-o for domain: _acme-challenge.mondomaine mais en réalité, l'enregistrement est toujours présent dans la zone.

Là pour le coup, je ne suis pas d'accord avec toi. Le wildcard peut s'appliquer à un "sous-domaine". Je n'ai d'ailleurs eu aucun problème pour créer mes deux enregistrements. L'essentiel c'est que le caractère '*' soit situé à gauche du nom de domaine. Pour reprendre Fenrir, un sous domaine n'existe pas. donc ndd.net est un domaine, sub1.ndd.net est aussi un domaine. Je n'ai pas de wildcard sur ndd.net car je n'utilise pas directement ce nom de domaine, mais même si j'en mettais un, ce n'est pas pour autant qu'il pourrait couvrir les requêtes sur sub1.ndd.net puisqu'il existe un enregistrement A sur ce dernier qui peut-être résolu. De même qu'il en existe un sur sub2.ndd.net. La priorité c'est d'abord les enregistrements existants, et si la requête ne peut pas aboutir, alors c'est le wildcard qui intervient. En l’occurrence, mes wildcard se trouvent sur les domaine sub1.ndd.net et sub2.ndd.net qui sont parfaitement résolus. D'ailleurs, lorsque je demande sur https://www.whatsmydns.net par exemple si toto.sub1.ndd.net ou xxx.sub1.ndd.net existent, il n'y a aucun problème : ces adresses sont bien dirigées vers l'IP publique du NAS 1. Idem, pour mon sub2.ndd.net où les requêtes sont bien redirigées vers l'IP publique du NAS 2. Par contre, ce même site est incapable de résoudre ndd.net car je n'ai pas d'enregistrement dans ma zone pour cette url. Le souci vient de acme.sh qui ne prend pas le bon site pour la création du TXT, ce qui bloque le processus de création du certificat. On pourrait faire le parallèle avec les adresses synology.me qui ont des wildcards en pagaille puisque les adresses sont de la forme 'cequ'onveut.synology.me' et le wildcard correspondant étant '*.cequ'onveut.synology.me' Pas sûr que l'enregistrement TXT soit supprimé après validation. Pour mes propres domaines chez OVH et Gandi, les TXT qui ont été créés sont toujours dans mes zones. Mais il est possible qu'ils soient recréés à chaque renouvellement.

@.Shad. Ce point a été mainte fois abordé avec @rodo37. Il n'est pas possible de limiter l'accès à un seul forum. Quant à passer par une validation d'un premier message serait contre productif et très fastidieux pour les modos. Je pense aussi qu'obliger à passer par une présentation avant de pouvoir poster risque d'en rebuter plus d'un. On demande de le faire pour une question de courtoisie et pour mieux cerner le demandeur, mais on ne peut en aucun cas contraindre.

@PiwiLAbruti Déterrage pour signaler une exhumation qui rentre dans le record book :

Vous pouvez créer une tâche planifiée pour le vidage des corbeilles. C'est très simple à faire. Vous allez dans le planificateur de tâche, vous cliquez sur Créer, Tâche planifiée, Corbeille. Le reste est à adapter à vos besoins.

Salut à tous, Je m'occupe des NAS d'un ami. L'un est chez lui, l'autre est dans son entreprise. N'ayant qu'un seul ndd hébergé chez OVH, j'ai créé des "sous-domaines" qui pointent chacun vers l'un des NAS. Pas de wildcard, mais des domaines bien définis à coup de CNAME dans la zone. Tout ça fonctionne très bien et le renouvellement de chaque certificat se fait sans problème. Je souhaite maintenant passer par des certificats wildcard sur les deux sites. J'ai donc créé deux enregistrements CNAME : *.sub1.ndd.net et *.sub2.ndd.net J'ai les API correspondantes pour sub1.ndd.net et sub2.ndd.net Mais lorsque je tente de créer un certificat avec acme.sh, le processus bloque parce qu'il n'arrive pas a créer l'enregistrement TXT. En analysant les logs, il s'avère qu'acme.sh n'identifie pas correctement le nom de domaine qu'il considère comme étant 'net'. Voici un extrait du log avec mes commentaires : [Sat Oct 31 18:13:12 UTC 2020] _sub_domain='_acme-challenge.sub1.ndd' (devrait-être '_acme-challenge' seulement) [Sat Oct 31 18:13:12 UTC 2020] _domain='net' (devrait-être 'sub1.ndd.net') [Sat Oct 31 18:13:12 UTC 2020] Adding record [Sat Oct 31 18:13:12 UTC 2020] domain/zone/net/record (devrait-être domain/zone/sub1.ndd.net/record) [Sat Oct 31 18:13:12 UTC 2020] GET [Sat Oct 31 18:13:12 UTC 2020] url='https://eu.api.ovh.com/1.0/auth/time' [Sat Oct 31 18:13:12 UTC 2020] timeout=30 [Sat Oct 31 18:13:12 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g --connect-timeout 30' [Sat Oct 31 18:13:12 UTC 2020] ret='0' [Sat Oct 31 18:13:12 UTC 2020] _ovh_p='[hidden](please add '--output-insecure' to see this value)' [Sat Oct 31 18:13:12 UTC 2020] data='{"fieldType":"TXT","subDomain":"_acme-challenge.sub1.ndd","target":"7HpvWs7RaFcx6wQ0k3Nd5TP2-SSKiVYUZMlSrS_ZnRA","ttl":60}' (devrait-être 'acme-challenge' seulement) [Sat Oct 31 18:13:12 UTC 2020] POST [Sat Oct 31 18:13:12 UTC 2020] _post_url='https://eu.api.ovh.com/1.0/domain/zone/net/record' (devrait-être 'https://eu.api.ovh.com/1.0/domain/zone/sub1.ndd.net/record') [Sat Oct 31 18:13:12 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Sat Oct 31 18:13:13 UTC 2020] _ret='0' [Sat Oct 31 18:13:13 UTC 2020] Add txt record error. [Sat Oct 31 18:13:13 UTC 2020] Error add txt for domain:_acme-challenge.sub1.ndd.net [Sat Oct 31 18:13:13 UTC 2020] _on_issue_err Du coup, il n'est pas possible d'obtenir un certificat wildcard pour chaque NAS. Je pense que le souci vient de acme.sh Pour contourner la chose, je me dis que plutôt que de faire un certificat par sous-domaine, il est aussi possible de faire un certificat sur ndd.net tout en conservant les deux wildcard. La création du certificat serait alors de la forme : acme.sh --issue --keylength 4096 -d 'ndd.net' -d 'sub1.ndd.net' -d '*.sub1.ndd.net' -d 'sub2.ndd.net' -d '*.sub2.ndd.net' --dns dns_ovh Je pourrais alors obtenir un certificat que je pourrais importer du NAS1 vers le NAS2, mais je voudrais que les processus restent indépendants. Dans ce cas, il faudrait que j'utilise le même processus de création sur l'autre NAS, mais alors, que devient l'enregistrement TXT du premier NAS, et surtout comment pourra se faire le renouvellement si l'enregistrement n'est plus le même ? Si vous avez des idées, je suis preneur.

Effectivement, votre disque est plein. Il faudrait commencer par vider les corbeilles si elles sont activées. Plusieurs paquets peuvent être à l'origine du remplissage. Le plus gourmand d'entre eux c'est Drive (anciennement CloudStation). Vous avez aussi Download Station qui peut engendrer du remplissage. Si vous avez Drive, il y a certainement eu des fichiers ajoutés puis supprimés. Ces fichiers sont malgré tout toujours présents dans Drive et occupent de la place. Si ce sont des films, cette espace peut devenir très important.

Des captures, ça veut dire des captures. Il nous faut aussi Volume, Groupe de stockage et HDD

???? Il nous faut des captures d'écran de votre gestionnaire de stockage si vous voulez qu'on comprenne.

Je viens de faire le certificat pour mon ndd chez Gandi. L'obtention de la clé API est assez simple, encore faut-il trouver comment. Une fois connecté sur le compte, on clique en haut à droite pour aller dans les paramètres du compte. On clique sur "Gérer les Apps autorisées", Onglet "Sécurité". On génère une clé API qu'on sauvegarde pour l'utiliser dans : export GANDI_LIVEDNS_KEY="fdmlfsdklmfdkmqsdfk" C'est la seule clé dont on a besoin. Et pour créer le certificat : acme.sh --issue --keylength 4096 --dns dns_gandi_livedns -d mondomaine -d *.mondomaine Dans un premier temps, j'ai essayé d'utiliser le même conteneur que pour OVH, mais après la création du certificat, l'opération n'est pas allée jusqu'au bout. J'avais bien un dossier du nom de mon domaine dans le dossier Acme mais il était incomplet. Je l'ai supprimé pour ne pas être embêté pour la suite. J'ai créé un autre conteneur afin de séparer le traitement des deux ndd. J'ai toutefois utilisé le même json, pour ne pas avoir 2 instances acme qui tournent séparément. Ceci a eu pour but de recréer un autre dossier comme précédemment, mais cette fois, la génération du domaine s'est bien déroulée. Pour la suite, j'ai fait comme précédemment à savoir que je ne suis pas passé en ssh mais j'ai simplement utilisé le certificat pour en créer un nouveau directement dans DSM avec la clé et le certificat intermédiaire. La partie mise à jour automatique dans DSM a été faite de la même manière que pour le certificat précédent. Hormis l'obtention de la clé, la mise en oeuvre est encore plus courte que pour OVH car il n'y a qu'une valeur à indiquer pour l'API ai lieu de 3. J'ai du mettre moins de 10mn pour l'opération sur Docker. Reste plus qu'à surveiller le bon renouvellement et la mise à jour auto des deux certificats.

Il n'y a rien d'anormal dans votre groupe. Il y a bien la capacité totale, soit pour un SHR de 3x2 + 2x12 = 18To (1 disque de sécurisation), ce qui donne en réalité 16,4To

firlin vous a expliqué qu'il n'était pas possible de supprimer des disques d'un raid ou shr. On peut toujours augmenter le nombre de disques, mais pas le diminuer. Vous avez 4 disques, votre SHR ne peut fonctionner qu'avec ces 4 disques.

Si vous voulez qu'on comprenne, il faudrait commencer par nous donner les vues de votre gestionnaire de stockage.

C'est bon pour le tuto jusqu'au bout avec un ndd chez OVH 😀 Au final, entre la création du certificat et le rajout de son renouvellement, il ne faut pas plus de 10 mn pour tout mettre en place. Je vais maintenant me lancer dans mon ndd chez Gandi. Je ne connais pas encore leur API.

Je suis d'accord, mais ce n'est pas le nom du domaine qu'il faut mettre. C'est sa description qui est en fait le nom du certificat tel que le connait DSM.

Bon, j'ai trouvé d'où vient l'erreur. Comme je ne veux renouveler qu'un seul certificat, je l'ai indiqué dans le script. Mais en fait, il ne faut pas indiquer le nom de domaine mais uniquement sa description dans DSM. A supposer que ma description soit "Mon certificat à moi", la ligne export SYNO_Certificate doit être égale = "Mon certificat à moi" J'ai fait cette modif et le certificat s'est renouvelé sans problème. A voir lors du prochain renouvellement si c'est OK. Voici le log : [Fri Oct 30 14:25:42 UTC 2020] Running cmd: deploy [Fri Oct 30 14:25:42 UTC 2020] Using config home:/acme.sh [Fri Oct 30 14:25:42 UTC 2020] default_acme_server [Fri Oct 30 14:25:42 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Fri Oct 30 14:25:42 UTC 2020] DOMAIN_PATH='/acme.sh/mondomaine' [Fri Oct 30 14:25:42 UTC 2020] _deployApi='/root/.acme.sh/deploy/synology_dsm.sh' [Fri Oct 30 14:25:42 UTC 2020] _cdomain='mondomaine' [Fri Oct 30 14:25:42 UTC 2020] SYNO_Certificate='Mon certificat à moi' [Fri Oct 30 14:25:42 UTC 2020] _base_url='http://172.17.0.1:5000' [Fri Oct 30 14:25:42 UTC 2020] Logging into 172.17.0.1:5000 [Fri Oct 30 14:25:42 UTC 2020] GET [Fri Oct 30 14:25:42 UTC 2020] url='http://172.17.0.1:5000/webman/login.cgi?username=nomutilisateur&passwd=monmdp&enable_syno_token=yes&device_id=' [Fri Oct 30 14:25:42 UTC 2020] timeout= [Fri Oct 30 14:25:42 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 14:25:44 UTC 2020] ret='0' [Fri Oct 30 14:25:44 UTC 2020] token='xxxxxxxxxxxx' [Fri Oct 30 14:25:44 UTC 2020] Getting certificates in Synology DSM [Fri Oct 30 14:25:44 UTC 2020] POST [Fri Oct 30 14:25:44 UTC 2020] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Fri Oct 30 14:25:44 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 14:25:44 UTC 2020] _ret='0' [Fri Oct 30 14:25:44 UTC 2020] Generate form POST request [Fri Oct 30 14:25:44 UTC 2020] Upload certificate to the Synology DSM [Fri Oct 30 14:25:44 UTC 2020] POST [Fri Oct 30 14:25:44 UTC 2020] _post_url='http://172.17.0.1:5000/webapi/entry.cgi?api=SYNO.Core.Certificate&method=import&version=1&SynoToken=xxxxxxxxxxxxx' [Fri Oct 30 14:25:44 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 14:26:50 UTC 2020] _ret='0' [Fri Oct 30 14:26:50 UTC 2020] http services were restarted [Fri Oct 30 14:26:50 UTC 2020] [1;32mSuccess[0m Edit : Je viens de vérifier mes certificats dans /usr/local/etc/certificate et je confirme que les maj se sont faites sans problème. Ca devrait donc être OK pour le renouvellement dans deux mois.

Merci à tous les deux. Il y a un mieux. Le script se connecte bien avec le hostname mais il ne trouve pas le certificat. [Fri Oct 30 13:58:28 UTC 2020] Logging into 172.17.0.1:5000 [Fri Oct 30 13:58:29 UTC 2020] GET [Fri Oct 30 13:58:29 UTC 2020] url='http://172.17.0.1:5000/webman/login.cgi?username=monutilisateur&passwd=monmotdepasse&enable_syno_token=yes&device_id=' [Fri Oct 30 13:58:29 UTC 2020] timeout= [Fri Oct 30 13:58:29 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 13:58:30 UTC 2020] ret='0' [Fri Oct 30 13:58:30 UTC 2020] token='xxxxxxxxxxxxx' [Fri Oct 30 13:58:30 UTC 2020] Getting certificates in Synology DSM [Fri Oct 30 13:58:30 UTC 2020] POST [Fri Oct 30 13:58:30 UTC 2020] _post_url='http://172.17.0.1:5000/webapi/entry.cgi' [Fri Oct 30 13:58:30 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 13:58:31 UTC 2020] _ret='0' [Fri Oct 30 13:58:31 UTC 2020] Unable to find certificate: mondomaine and $SYNO_Create is not set [Fri Oct 30 13:58:31 UTC 2020] Error deploy for domain:mondomaine [Fri Oct 30 13:58:31 UTC 2020] Deploy error.

C'est pas gagné. Tout d'abord il y a une erreur dans le tuto : il faut supprimer le "./" dans : ./acme.sh --deploy --home . -d "mydomain.com" --deploy-hook synology_dsm sinon il y a le message "access denied to acme.sh". acme.sh est dans la racine du dossier acme, on ne va pas le chercher plus loin. Ensuite, j'ai créé un compte admin en accès réduit et sans double authentification pour le renouvellement du certificat. Le process se lance mais ne peut aboutir car il n'arrive pas à se connecter au localhost:5000 [Fri Oct 30 10:40:20 UTC 2020] url='http://localhost:5000/webman/login.cgi?username=monusername&passwd=monmdp&enable_syno_token=yes&device_id=' [Fri Oct 30 10:40:20 UTC 2020] timeout= [Fri Oct 30 10:40:21 UTC 2020] _CURL='curl -L --silent --dump-header /acme.sh/http.header -g ' [Fri Oct 30 10:40:21 UTC 2020] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 7 [Fri Oct 30 10:40:21 UTC 2020] ret='7' [Fri Oct 30 10:40:21 UTC 2020] token [Fri Oct 30 10:40:21 UTC 2020] Unable to authenticate to localhost:5000 using http. [Fri Oct 30 10:40:21 UTC 2020] Check your username and password. [Fri Oct 30 10:40:21 UTC 2020] Error deploy for domain:mondomaine [Fri Oct 30 10:40:21 UTC 2020] Deploy error. Je ne pense pas qu'il y ait un pb avec l'utilisateur qui a les droits admin.

J'ai suivi le tuto et j'ai rencontré un problème pour accéder au terminal. La faute à la connexion à Docker via un ndd. En utilisant l'IP, pas de problème. Pour pouvoir utiliser un ndd, il faut paramétrer dans le reverse proxy le websocket du dit ndd. Merci @Einsteinium pour l'astuce. Une fois ce problème réglé, la création du certificat n'a pas pris plus de 5mn. Je n'ai pas fait l'installation via ssh comme indiqué mais j'ai simplement importé le certificat dans dsm. Reste à faire l'automatisation de l'installation.

Bonjour, Tout d'abord, il est d'usage sur ce forum de passer par la section des présentations avant de poster. Certains y sont sensibles et ça permet de mieux vous connaître. Il n'est pas trop tard. Ensuite, la multiplication des messages n'est pas autorisée car elle sème la confusion. Je supprime votre message précédent et je déplace celui-ci dans la rubrique appropriée. Enfin, votre question relève d'un problème de réglage des droits. Je vous invite à consulter et à mettre en pratique les tutos mis à disposition sur le site, et surtout le plus important, celui qui concerne la sécurisation de nos NAS.