Mic13710

Pour ton adresse nas.ndd.ovh, c'est soit le fichier .htaccess qui fait la conversion vers https, soit c'est le cache de ton navigateur qui récupère la dernière adresse correspondante. Si tu as vidé ton cache et en l'absence de fichier de conversion, il est normal qu'une url qui ne précise pas le protocole prenne http par défaut. Si le ping est lancé à partir du WAN, c'est normal d'avoir l'IP publique comme résultat. Si le ping est lancé côté LAN et à condition bien entendu que ton serveur DNS local ainsi que le reverse proxy soient paramétrés correctement, c'est l'IP du NAS qui doit être retournée. Si ce n'est pas le cas, c'est que tu as un problème de résolution.

La double authentification c'est très bien, à condition que l'horloge du NAS soit synchronisée et d'avoir les bons outils pour la gérer sereinement (gestionnaire de mot de passe, applis OTP et clé sauvegardée). Si les conditions sont réunis, il ne faut pas hésiter à s'en servir. Mais en principe, sauf si l'accès n'est pas sécurisé, il ne faut pas l'appliquer sur des comptes utilisateurs sinon ça devient vite ingérable. Sur des comptes administrateurs directs (j'entends par là les comptes qui servent à l'administration du NAS), c'est un point sécuritaire qu'il ne faut pas négliger.

Peut-être qu'un petit bonjour serait une bonne entrée en matière pour un premier message sur ce forum. Bref. Je n'utilise pas Secure Sign In. Pour recevoir un email, il faut qu'une adresse mail soit paramétrée dans le service de notification et que vous ayez reçu un mail d'essai pour confirmer que les envois fonctionne. Si vous n'avez plus accès au NAS, le seul moyen c'est de faire un reset mode 1 pour réinitialiser le compte admin. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t1

Que les disques ne soient pas dans la liste peut être la cause. Un NAS est assez capricieux et il y a des incompatibilités avec certains disques, hdd ou ssd. Ce n'est pas parce que les vôtres ont fonctionné un jour qu'ils fonctionneront toujours. Et vous ne pourrez jamais savoir s'ils sont compatibles car Synology ne mettra plus à jour la liste actuelle pour un NAS vieux de 10 ans. Regardez toutefois si vos disques sont acceptés sur des NAS plus récents. Ce n'est pas une garantie, mais ça pourrait donner une idée d'une possible compatibilité avec votre modèle si c'est le cas pour d'autres NAS de la marque. Si votre groupe est en RAID1 ou SHR avec protection des données, pas besoin de sauvegarde pour remplacer des disques. Du moins pour l'opération car une sauvegarde est indispensable en cas de problème, tant en fonctionnement que lors des travaux ponctuels sur le groupe. Bref, tout le temps. Il suffit de remplacer les disques l'un après l'autre, réparation du groupe qui reconstruit le RAID et le groupe augmente une fois le deuxième disque associé au groupe.

Les noms d'hôtes acceptés dans le reverse proxy ne sont que des noms pleins. Vous ne pouvez pas indiquer un service ou un port dans l'url. ndd/photo n'est pas accepté. ndd:port non plus. Le but du reverse proxy c'est de diriger un ndd vers un service. Pour photo station, c'est effectivement avec un ndd/photo qu'on peut joindre l'application. Il n'y a pas besoin de reverse proxy pour ça puisque l'url conduit directement au service. Je sais qu'il y a une astuce pour y parvenir avec un ndd dédié (photo.ndd) et le reverse proxy mais comme ce n'est plus d'actualité avec DSM7.x et Synology Photo, je n'ai plus le souvenir de la manière de procéder. Peut-être avec un .htaccess mais pas sûr.

Tu n'aurais pas une règle du parefeu qui bloque les us ?

Un groupe de stockage n'est pas dégradé avec un secteur endommagé. Le disque a certainement géré le problème en attribuant un secteur de réserve. Si le groupe est dégradé, le gestionnaire devrait vous proposer de le réparer. Si ça fonctionne avec les hdd, de toute évidence ce sont les ssd qui ont un problème. Est-ce qu'ils sont dans la liste des disques approuvés pour votre NAS (dont on ne connait pas le modèle) ? Si l'intérêt pour vous de monter des ssd est de gagner en vitesse, avec un réseau Gb vous pouvez oublier les gains en performance, ils sont quasi nuls. Ce sera le réseau qui coincera. En plus, indépendamment du prix, les ssd ont une fiabilité moindre par rapport aux hdd.

Il semblerait que ce soit cette url qui n'a pas fonctionné. C'est un JSON qui permet de récupérer les liens pour les api et dérouler la suite du script. Tu as ensuite accumulé les time out, le script n'a pas pu aller plus loin et s'est arrêté après plusieurs tentatives. Le site était peut-être indisponible au moment de ta demande. Attends demain pour voir si ça a évolué.

Est-ce que ça fonctionne avec les HDD ? Si oui, ce sont les ssd qui ont un problème, sinon, c'est le NAS qui a un pet' au casque. Vous pouvez faire un test de la carte mère : https://kb.synology.com/fr-fr/DSM/tutorial/Why_am_I_unable_to_install_my_Synology_NAS_and_why_is_my_power_LED_is_flashing_constantly

Je ne suis pas utilisateur de quickconnect mais il me semble que tout peut se faire sans ouverture de port, y compris les sauvegardes. Il faut seulement que les NAS distants soient des synology qui ont chacun leur propre ID quickconnect. Si ce n'est pas le cas ou que vous souhaitez utiliser les ports, voici la liste synology avec les protocoles : https://kb.synology.com/fr-fr/DSM/tutorial/What_network_ports_are_used_by_Synology_services

Les deux HDD sont aussi impactés ? Etrange. Avez-vous essayé un reset mode 2 qui permet la réinstallation de DSM ? https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7#t2 Pour le formatage, il n'y a rien de particulier à faire. Un simple formatage rapide sur un PC suffit, le but étant de détruire la partition système (la première) pour que DSM parte sur une nouvelle installation. Si vous voulez un formatage plus profond, vous trouverez facilement des outils sous linux en interfaces graphiques et/ou en lignes de commandes. Gparted par exemple devrait répondre à votre besoin.

Que tout ceci me semble compliqué ! Je ne comprends pas ce que vient faire l'upnp là dedans ni à quoi servent ces redirections côté LAN. Si vous utilisez uniquement quickconnect, vous n'avez pas besoin d'ouverture et de redirection de ports. Je pense qu'il suffit de rétablir la connexion de quickconnect et c'est tout. Néanmoins, la freebox pro comporte certaines lacunes en matière de paramétrage contrairement à la révolution et il se peut qu'il faille creuser un peu plus et vous orienter vers une configuration plus classique qui sera de toute manière bien meilleure que quickconnect.

Si je comprends bien, les deux ssd ont fonctionné dans le NAS (votre premier message). Si ça ne fonctionne plus maintenant après avoir remis les disques dans le NAS, ce n'est pas de l'incompatibilité mais seulement un problème de disque. Pour le vérifier, ne montez qu'un seul disque et faite une installation de DSM. Si ça fonctionne avec un disque et pas avec l'autre, vous aurez trouvé le coupable.

MariaDB est bien dans /var/packages/MariaDB10/ Pour la suite, je ne peux guère vous aider je n'utilise pas.

Pour la vérification de la date, c'est la date d'expiration qui est recherchée dans la fonction certificat_check() avec openssl x509 -checkend $(( (90 - RENEWAL_CYCLE) * 86400 ))Vu comment c'est construit, checkend va lire la fin de validité du certificat (en secondes) et s'il reste moins que le renewal_cycle, un nouveau certificat est demandé. Avec le certificat actuel sur 90 jours, le renewal_cycle à 61 donne en réalité un certificat renouvelé tous les 29 jours. Donc, tu as déjà un script qui tient compte de la nouvelle donne. Néanmoins, la validité du certificat LE va diminuer ces prochains mois et ça va coincer dans le bocal. Il va falloir corriger le script pour qu'il couvre les validités réduites. Edit : Désolé, j'ai mal interprété checkend. 90 = durée standard d’un certificat Let's Encrypt (pour le moment) RENEWAL_CYCLE=61 Donc : 90 - 61 = 29 jours => Le script vérifie que le certificat est encore valide dans 29 jours. C'est toujours sur une durée de 60 jours avant renouvellement. Donc, c'est bien ce que je disais, il faut passer RENEWAL_CYCLE à 31 pour que le renouvellement intervienne après 30 jours. Ceci n'est que temporaire car le problème va se poser à nouveau lorsque la durée de validité du certificat va diminuer. Cette manière de gérer la durée du certificat sur une durée fixe de 90 jours est extrêmement bizarre de toute façon. Aussi, pourquoi ne pas laisser acme.sh gérer les validités ou plus simplement utiliser les infos de ndd.conf qui donne Le_NextRenewTime et Le_NextRenewTimeStr qui sont directement écrit par acme.sh ? J'aurais bien un correctif à te proposer mais ce n'est pas le lieu pour le faire (hors sujet)