Mic13710

@graynon, bienvenue dans la communauté Les perfos à carte, j'ai connu ça aussi il y a ..... un certain temps. Marseille, j'y suis né, y ai vécu 20 ans (à Mazargues, pas loin de chez @Jeff777), puis Toulouse où j'ai fait mes études (c'est là que j'ai connu très brièvement les cartes perforées) pour revenir très vite dans la région. J'habite maintenant Fuveau (d'où mon pseudo) depuis 40 ans.

@graynon pour les présentations, c'est ici : https://www.nas-forum.com/forum/forum/16-présentation/

Lorsqu'il n'y avait pas le hook de déploiement, le script était effectivement loin d'être parfait. Raison pour laquelle je l'ai utilisé et modifié dans le temps pour mes besoins personnels. Il fonctionnait pas mal mais je n'avais pas trouvé de solution autre que de redémarrer le NAS à la fin du script pour que toutes les maj se fassent correctement. Le seul problème c'est que la sauvegarde des snapshots ne redémarrait pas. Il fallait le redémarrer à la mano. La misère. Le hook à l'air de bien fonctionner, aussi j'espère que cette version est aboutie et permette enfin de faire le renouvellement et le déploiement de manière automatique sans devoir passer par un script additionnel pour corriger les dysfonctionnements. La réponse fin décembre.

Par par acme.sh, mais par le script de renouvellement. Copie du script au niveau du déploiement : Le_DeployHook='synology_dsm,' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='localhost' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='moncompte' SAVED_SYNO_Password='monmdp' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='Le nom de mon certificat' La première ligne est assez claire il me semble.

Pas sûr. C'était vrai avant, et j'avais d'ailleurs fait un script pour pallier les dysfonctionnements que j'avais remarqué lors des renouvellements, mais depuis, il y a eu l'apparition du deploy-hook qui simplifie la tâche et me semble faire correctement le boulot. A voir si c'est bien le cas lors du prochain renouvellement.

L'installation en ssh sur le 214 de mon ami s'est faite sans problème. J'ai utilisé la même API que pour son NAS du bureau ce qui m'a évité de devoir faire la double manip indiquée ici : https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api en rajoutant simplement un export_OVH_CK='consumer key' avant la création du certificat. La séquence est donc la suivante : cd ~ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz tar xvf master.tar.gz cd acme.sh-master/ ./acme.sh --install --nocron --home /usr/local/share/acme.sh --accountemail "email@gmailcom" source ~/.profile cd /usr/local/share/acme.sh export OVH_AK="your application key" export OVH_AS="your application secret" export OVH_CK="your consumer key" acme.sh --issue --keylength 4096 -d mydomain.com -d *.mydomain.com --dns dns_ovh export SYNO_Username='Admin_Username' export SYNO_Password='Admin_Password!123' export SYNO_Certificate="Le nom de mon certificat dans DSM" ./acme.sh --deploy --home . -d mydomain --deploy-hook synology_dsm La méthode est donc similaire à celle sous Docker et au final, le fichier de conf est pratiquement identique pour les deux. Par contre, je n'ai pas eu d'enregistrement TXT restant dans la zone après l'opération. A croire que c'est la méthode via docker qui pose problème. Et pour la mise à jour auto, j'ai mis en place une tâche qui lance le processus une fois par semaine : /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/ Sur Docker, cette opération est réalisée tous les jours à 0h00. Je ne sais pas si on peut changer ça pour qu'elle soit lancée qu'une fois par semaine aussi.

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.