Mic13710

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 ?

Est-ce que vous avez autorisé les ports 500, 1701 et 4500 dans le parefeu du 220 ?

Et si vous commenciez par consulter les liens qu'on vous donne avant de poser des questions ?

Les erreurs de système de fichier ont plusieurs origines. Le plus souvent ce sont les disques qui peuvent avoir des temps d'accès disparates qui ont une incidence sur les parités et engendrent des erreurs. Vérifiez vos disques, et surtout leur technologie SMR ou CMR. Il y a un fil de discussion à ce sujet sur le forum. Je ne saurais trop vous conseiller de faire des tests approfondis des disques car ce n'est pas parce qu'ils sont indiqués comme sains qu'ils le sont réellement. Une écriture de zéros, ou mieux un badblocks vous permettrait de vous en assurer avant de les remettre en production. Surtout les 3 disques qui posent problème. Dans ce cas (test des disques) il faudra tout réinstaller. Ce n'est pas très compliqué avec Hyperbackup. J'insiste toutefois sur le fait de ne pas globaliser les sauvegardes hyperbackup mais de les scinder en plusieurs morceaux (faire par exemple 2 fichiers pour un dossier volumineux) pour éviter d'avoir de grosses restaurations avec le risque qu'elles ne se passent pas bien. En faisant plusieurs morceaux, on limite les risques de pertes de données. Pensez aussi à tester vos sauvegardes avant de supprimer définitivement votre groupe. Pour l'organisation des fichiers je vous recommande le SHR et le btrfs.

C'est effectivement un problème de limitation de taille de volume à 16To pour un 416J. La solution serait de basculer vers un multi volume https://www.synology.com/fr-fr/knowledgebase/DSM/help/DSM/StorageManager/storage_pool_to_multiple_volume_support mais il faut que le groupe soit en SHR

Vous pouvez sauvegarder la configuration (utilisateurs, groupes etc..). C'est dans Mise à jour et restauration, menu Sauvegarde de configuration. Mais vous pouvez très bien le faire avec Hyperbackup en le déclarant dans les options. Hyperbackup que je vous conseille d'utiliser pour sauvegarder vos données sur le disque externe. Vous faite plusieurs petites sauvegardes qui seront plus faciles à restaurer plutôt qu'une grosse. Faite aussi 2 sauvegardes sur des supports différents des données les plus importantes. Inutile de formater vos disques. Il vous suffit de supprimer le ou les volumes puis le groupe dans le gestionnaire de stockage. Vous ne perdez pas ainsi votre DSM et vous pourrez reconstruire vos deux groupes.

Il faut attendre que le peuplement se fasse entièrement. La synchronisation n'est pas instantanée et peut prendre pas mal de temps selon le volume des données et la qualité de la liaison serveur/client

Oui. Dans la console d'administration, menu Dossier de l'équipe, il faut activer le répertoire data. A ce moment là, vous pouvez créer une synchronisation dans le Drive client des utilisateurs ayant les droits sur le dossier data.

Bonjour Le_Trapeziste, soyez le bienvenu dans la communauté

Avant de penser à racheter un autre NAS, il me semble plus urgent de tenter la réparation proposée dans le sujet ci-dessus. Oui, la migration des disques dans un autre NAS Synology est possible, avec certaines contraintes qui sont expliquées dans ce sujet : https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/General_Setup/How_to_migrate_between_Synology_NAS_DSM_6_0_and_later

Si le test sans les disques ne passe pas, je crains fort qu'il s'agisse malheureusement de la panne qui affecte les NAS sur base CPU C2000. Un solution consisterait à souder une résistance sur la carte mère pour tenter de palier le défaut.

Tout d'abord parce que je ne sais pas comment faire un deploy vers un NAS distant, et puis ça me permet de tester les deux méthodes 😉

Je reprends. Vous n'avez pas besoin du ddns. Mais rien ne vous empêche d'en paramétrer un si vous y tenez absolument. Dans ce cas, il faut supprimer l'enregistrement A du domaine chez OVH et créer un DynHost avec le même domaine dans le DynHost OVH. Vous n'en n'avez pas besoin si vous avez une ip fixe et que vous avez un enregistrement A qui redirige vers votre IP publique. Une fois que vous indiquez votre ndd dans un navigateur externe, la requête sera dirigée vers votre IP publique, puis sera redirigée par votre routeur en fonction des ports ouverts et des redirections que vous aurez réglées dans votre routeur et votre NAS.