Mic13710

Avec un disque d'un NAS monobaie, un simple lecteur ext4 pour windows fait l'affaire. Celui-ci par exemple : https://www.diskinternals.com/linux-reader/

Sauf pour quelques applications particulières qui nécessitent d'avoir le btrfs, il n'y a pas de rapport entre les paquets que vous souhaitez installer et l'organisation des disques. C'est à vous de décider si vous souhaitez avoir de la continuité de service en sécurisant vos données, ou bien si vous voulez le maximum de stockage en optant pour des groupes séparés, en gardant à l'esprit que la perte d'un disque avec ce choix sera la perte de ses données et nécessitera sa réinstallation. Quel que soit le choix, vous devez prévoir la sauvegarde régulière de vos données sur un support externe.

Je n'en sais rien, je n'ai pas de RT. Perso je ne fais pas de déploiement. Chaque NAS gère son propre certificat.

Pas en totalité. Quand vous détruisez un groupe, vous supprimez uniquement la partition des données. Les partitions Système et Swap ne sont pas touchées. Lorsque vous créez un groupe, vous choisissez les disques qui vont constituer le groupe. Les partitions données seront assemblées pour constituer le groupe. Le formatage interviendra lors de la création du volume en fonction du système de fichier choisi (ext4 ou BTRFS). S'il y a plusieurs volumes sur le groupe (groupe à volumes multiples), les deux systèmes peuvent très bien cohabiter, cad qu'on peut avoir des volumes en ext4 et d'autres en btrfs. Ca se voit que le NAS de la mairie n'est pas le votre. Vous vous la jouez kamikaze ! Non, il faut démarrer avec au moins un disque pour pouvoir initialiser le NAS et installer DSM. Je ne saurais trop vous recommander de d'abord commencer par tester les disques avant leur exploitation. Voyez le tuto de @firlin pour le test badblocks.

Décochez la vérification en 2 étapes dans le menu utilisateur, onglet Avancé. Ca ne devrait pas supprimer les doubles authentifications en place mais vous laisse le choix de l'appliquer ou pas pour tel ou tel compte. Mais vous pouvez tout à fait garder la double authentification en utilisant un SYNO_DID dans vos paramètres. Voir ceci pour la mise en place : https://github.com/acmesh-official/acme.sh/wiki/deployhooks#20-deploy-the-cert-into-synology-dsm

Alors vous avez mal compris. On peut tout à fait supprimer la double authentification pour un compte. Une fois connecté sur le compte, aller dans le profil en haut à droite, puis Perso pour désactiver la double authentification. Tâche en exécution unique veut bien dire ce que ça veut dire : une seule fois.

Je ne comprends pas la question. Cependant, il y a une erreur de compréhension entre groupe et volume. Non, vous ne séparez pas le volume en deux. Vous scindez votre groupe existant en deux groupes distincts. Pour cela, il va d'abord falloir supprimer le volume puis le groupe. Vous pourrez ensuite créer un nouveau groupe en sélectionnant les disques qui en feront partie (ceux du NAS je suppose) et vous pourrez créer un (ou plusieurs) nouveau(x) volume(s) sur ce groupe. Vous faite de même avec les disques de l'extension. Pour faire une analogie avec Windows bien que le fonctionnement soit différent, un groupe c'est le disque physique de votre PC, un volume ce sont le ou les partitions que vous y mettez.

Bonjour Favettes13b, soyez le bienvenu dans la communauté

https://www.cambier.org/2015/04/22/migrer-dun-mode-shr-avec-protection-de-donnees-a-un-mode-shr-sans-protection-de-donnees/ Non officiel et donc à vos risques et périls

Non, uniquement les fichiers qui auront été modifiés. Comme je l'ai déjà dit, il est préférable de faire la première sauvegarde en local pour éviter que ça prenne des jours. Les suivantes ne sont que des mises à jour et s'il n'y a pas eu trop de modifs ni de déplacement de dossiers, ça va assez vite (tout dépend bien entendu de la vitesse du lien)

Renouvellement de mon deuxième domaine effectué sans problème cette nuit. Rien de suspect dans les logs et mes fichiers de conf sont tous complets. Pour résumer, je suis toujours sur la base de la première version du tuto mais je n'ai qu'une seule instance pour mes deux domaines. C'est possible uniquement si les deux registar sont différents pour des questions d'API. Pour ma part je suis chez OVH et Gandi. Je pense aussi qu'il ne faut pas avoir une simultanéité des renouvellements sans quoi le script acme.sh risque de buguer. Juste un petit problème détecté dans DSM : le domaine par défaut qui était le domaine 1 a basculé sur le domaine 2. C'est un peu ennuyeux mais vite corrigé. Je vais suivre ça lors du prochain renouvellement dans 2 mois.

Pas particulièrement. Pour ma part j'utilise un D-Link DGS‑1008P qui alimente ma borne et mes caméras

Pas forcément. Ce sera alors 2 wifi indépendants. Si votre switch a une sortie POE 802.3af/A PoE24V Passive PoE avec suffisamment de puissance pour alimenter l'AP (6.5W pour le Lite, 9W pour le PRO), ça doit fonctionner.

Désolé mais je ne vois pas pour quelle raison ce n'est pas possible. Une borne wifi ubiquiti n'a rien de propriétaire. Elle ne fonctionne pas que sur du matériel ubiquiti. J'ai juste fait la réservation d'IP dans le routeur et un peu de paramétrage avec l'unifi-controller et ça roule. Si le RT n'est pas capable de reconnaitre une simple borne wifi, alors c'est encore plus bouse que ce que je pensais. Par contre, et je crois comprendre que c'est ce que tu as voulu dire, il est bien évident que le système mesh du Synology n'est pas compatible avec celui d'Ubiquiti, comme il n'est pas compatible avec les mesh d'autres marques.

Pour hyperbackup, il faut se connecter à l'adresse IP du serveur 10.2.0.0, compte administrateur et son mdp

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Comme il fallait s'y attendre, le renouvellement du deuxième certificat ne s'est pas fait. Mais je pense avoir compris pourquoi j'avais deux lancements du script. En fait, j'avais créé deux conteneurs, un par domaine, et les deux utilisaient le même account.conf. Il en résultait deux lancements automatiques simultanés et probablement que cela créait des télescopages entre les deux au niveau des acme_challenge car les logs rapportaient souvent des erreurs de lecture. Je viens de supprimer un des conteneurs et restauré le fichier de conf du domaine 2. J'ai aussi édité le fichier de conf du domaine 1 pour y rajouter les lignes qui avaient été supprimées hier après le renouvellement. Je verrai demain si le renouvellement du domaine 2 se fait.

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Au niveau des clés, tout va bien, le fichier account.conf est OK. C'est juste le fichier ndd.conf dans le répertoire du ndd dans lequel des lignes ont été effacées par rapport au fichier d'origine. Les identifiants du compte et le nom du certificat sont toujours OK. Je verrai demain si le deuxième certificat se renouvèle avec son fichier de conf modifié.

Non, ce n'est pas à cause du problème rencontré il y a quelques jours puisque le renouvellement s'est fait hier soir dans les mêmes conditions que lors de l'échec. Je pense que c'est à cause des anciens enregistrements TXT acme_challenge présents dans ma zone DNS, et encore, je n'en suis pas sûr. Ce qui est questionnable c'est pourquoi le fichier de conf a été quasiment effacé suite à l'échec du renouvellement, et pourquoi après le renouvellement du certificat les premières infos du même fichier de conf ont disparues du nouveau fichier. Je me demande d'ailleurs si le doublement des renouvellements ne serait pas dû à la présence de ces instructions dans le fichier ndd.conf de départ. Peut-être que le script utilise les infos du certificat lui-même pour lancer le renouvellement et que de les avoir aussi dans le ndd.conf lance une seconde session de renouvellement. Ce qui expliquerait aussi pourquoi ces informations ont été supprimées sur le nouveau fichier ndd.conf. D'ailleurs, il n'y a pas que cette information qui a disparue. Je viens de voir que Le_DeployHook='synology_dsm,' n'est pas dans le nouveau fichier. Pour vérifier, je vais essayer un truc. Comme le renouvellement de mon second domaine doit se faire cette nuit, je vais supprimer les premières lignes ainsi que celle du Le_DeployHook de son fichier de conf. Je verrai bien si le renouvellement et le déploiement se font quand même sans ces instructions, ce qui confirmerait que les infos sont récupérées ailleurs (peut-être du ndd.csr.conf). Si ça ne fonctionne pas, je pourrai toujours restaurer le fichier d'origine. Une fois que le renouvellement du deuxième certificat sera fait, je vais tout supprimer et reprendre complètement le tuto avec les dernières modifications. Tu ne voudrais tout de même pas que je divulgue mes paramètres sur le forum ! Si ? 😉

Retour après le renouvellement de mon premier certificat (l'autre c'est demain) Ca n'a pas été un fleuve tranquille. Tout d'abord, je n'ai rien changé par rapport au tuto d'origine, sauf le rajout de la mise à jour automatique de acme.sh pour laquelle je reviendrais plus bas. Le renouvellement était prévu le 27. La procédure s'est bien lancée mais après de multiples tentatives visibles dans les logs, le renouvellement a échoué. Le blocage venait en fait de l'impossibilité de valider les enregistrements TXT dans la zone DNS. Mais la conséquence la plus surprenante de ce blocage c'est le changement dans le fichier ndd.conf qui ne contenait plus que ça : Le_Webroot='dns_ovh' Le_Webroot='dns_ovh' Le_PreHook='' Le_RenewHook='' Le_PostHook='' Le_RenewHook='' Le_API='https://acme-v02.api.letsencrypt.org/directory' Le_Keylength='4096' Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxxxxxxxx' Toutes les infos du ndd avaient disparues ! J'ai récupéré l'ancien fichier dans mes sauvegardes pour repartir sur les mêmes bases. Je suis allé aussi sur ma zone DNS où j'ai supprimé les enregistrements TXT qui trainaient. Et oh surprise, mon certificat s'est renouvelé pendant la nuit. Il semblerait que les enregistrements TXT y soient pour quelque chose puisque c'est la seule modification que j'ai faite. Cependant, il a fallu pas moins de 735 enregistrements dans les logs pour obtenir le certificat et 26 de plus pour le déployer. Et en analysant de plus près, il semblerait que le renouvellement se soit lancé 2 fois. Pourquoi ? Peut-être un pour le ndd et un autre pour le *.ndd, mais je n'en suis pas du tout sûr. Et enfin il y a un autre changement important : le fichier ndd.conf a été modifié avec les nouvelles données de renouvellement du certificat, pas de problème avec ça, mais toutes les premières lignes du LE_domain au LE-keylength ont disparues.... Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/xxxxxxxxxxxxxxxxxxx' Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/xxxxxxxxxxxxxxxxxxxx' Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' Le_CertCreateTime='1609200232' Le_CertCreateTimeStr='Tue Dec 29 00:03:52 UTC 2020' Le_NextRenewTimeStr='Sat Feb 27 00:03:52 UTC 2021' Le_NextRenewTime='1614297832' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='172.17.0.1' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='xxxx' SAVED_SYNO_Password='xxxxxxxxxxxxxxx' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='xxxxxxxxxxxxxxx' Je me demande pourquoi ces infos ne sont pas reconduites dans le fichier. Est-ce qu'elles seront récupérées directement à partir du certificat existant lors du prochain renouvellement ? Et-ce que quelqu'un qui a eu le renouvellement automatique peut vérifier si c'est pareil sur son fichier de conf ? Enfin, concernant la mise à jour de acme.sh via le planificateur de tâche qui est apparue un temps sur le tuto, il me semble qu'elle est inutile car la vérification se fait systématiquement au lancement du script qui je suppose lance la maj s'il y a une nouvelle version. A confirmer. [Tue Dec 29 00:03:00 UTC 2020] [Tue Dec 29 00:03:00 UTC 2020] Running cmd: cronRunning cmd: cron [Tue Dec 29 00:03:00 UTC 2020] [Tue Dec 29 00:03:00 UTC 2020] Using config home:/acme.sh Using config home:/acme.sh [Tue Dec 29 00:03:00 UTC 2020] default_acme_server[Tue Dec 29 00:03:00 UTC 2020] default_acme_server [Tue Dec 29 00:03:00 UTC 2020] [Tue Dec 29 00:03:00 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:00 UTC 2020] [Tue Dec 29 00:03:00 UTC 2020] ===Starting cron=== ===Starting cron=== [Tue Dec 29 00:03:00 UTC 2020] Using config home:/acme.sh [Tue Dec 29 00:03:00 UTC 2020] Using config home:/acme.sh [Tue Dec 29 00:03:00 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:00 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:00 UTC 2020] GET [Tue Dec 29 00:03:00 UTC 2020] GET [Tue Dec 29 00:03:00 UTC 2020] url='https://api.github.com/repos/acmesh-official/acme.sh/git/refs/heads/master' [Tue Dec 29 00:03:00 UTC 2020] url='https://api.github.com/repos/acmesh-official/acme.sh/git/refs/heads/master' [Tue Dec 29 00:03:00 UTC 2020] timeout= [Tue Dec 29 00:03:00 UTC 2020] timeout= [Tue Dec 29 00:03:01 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Tue Dec 29 00:03:01 UTC 2020] _CURL='curl --silent --dump-header /acme.sh/http.header -L -g ' [Tue Dec 29 00:03:01 UTC 2020] ret='0' [Tue Dec 29 00:03:01 UTC 2020] Already uptodate! [Tue Dec 29 00:03:01 UTC 2020] Upgrade success! [Tue Dec 29 00:03:01 UTC 2020] ret='0' [Tue Dec 29 00:03:01 UTC 2020] Already uptodate! [Tue Dec 29 00:03:01 UTC 2020] Upgrade success! [Tue Dec 29 00:03:01 UTC 2020] Using config home:/acme.sh [Tue Dec 29 00:03:01 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:01 UTC 2020] Auto upgraded to: 2.8.8 [Tue Dec 29 00:03:01 UTC 2020] Using config home:/acme.sh [Tue Dec 29 00:03:01 UTC 2020] Using config home:/acme.sh [Tue Dec 29 00:03:01 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:01 UTC 2020] ACME_DIRECTORY='https://acme-v02.api.letsencrypt.org/directory' [Tue Dec 29 00:03:01 UTC 2020] _stopRenewOnError [Tue Dec 29 00:03:01 UTC 2020] Auto upgraded to: 2.8.8 [Tue Dec 29 00:03:01 UTC 2020] _set_level='2' [Tue Dec 29 00:03:01 UTC 2020] [Tue Dec 29 00:03:01 UTC 2020] di='/acme.sh/bonf.fr/'Using config home:/acme.sh Et là aussi, pourquoi les enregistrements sont doublés ? Mystère Bref, tout n'est pas encore clair pour ce qui me concerne.

C'est une des raisons pour lesquels je ne donne pas une adresse fixe dans les paramètres du NAS. Je laisse ce réglage en DHCP et je fais la réservation d'IP dans le routeur. Commencez par régler les paramètres réseau pour pouvoir vous connecter au NAS à partir d'une IP réservée. Et avant de penser à vous connecter de l'extérieur, je vous conseille d'aller faire un tour dans la section des tutoriels où vous trouverez un tuto traitant de la sécurisation de nos NAS.

Désolé mais je viens encore de vérifier et il fonctionne très bien. Ce n'est rien d'autre qu'une page de l'aide du site Synology. C'est de celui-ci dont je parle : https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/StorageManager/storage_pool_to_multiple_volume_support Et celui donné par Maxou56 fonctionne aussi. Si le lien ne s'ouvre pas directement, vous pouvez toujours le copier/coller dans la barre d'adresse de votre navigateur.

Vous voulez dire que vos 415 étaient montés en haute disponibilité (SHA) ? A mon avis, une simple migration des disques n'est pas suffisante et ne permet pas la synchronisation indispensable entre les deux NAS. Il me semble que le SHA doit être construit sur les deux NAS. Je ne pourrai pas vous aider sur le sujet, mais je pense que votre problème peut être analysé par le support. Il faudrait les contacter pour savoir si la migration d'un SHA vers 2 NAS identiques mais différents du modèle source est possible.

Ca à l'air ok pour les paramétrages. Quel est votre FAI côté 220 ? Si c'est free, vérifiez que vous avez une IP full stack. Côté 115, vous utilisez bien l'adresse de votre ddns (xxxxxx.synology.me) et un nom d'utilisateur avec les droits administrateur ?