PPJP

Donc problème résolu. Bonne soirée.

Bonsoir, Heureux pour vous que vous ayez trouvé l'origine du problème. Mais il serait judicieux de revoir le paramétrage de votre NAS au niveau sécurité. Montre que non seulement syncback a réussi à se connecter au NAS mais de plus avec les droits root!

Bonjour, Une idée au hasard: Une sauvegarde (rsync par exemple) oubliée sur le serveur?

Bonjour, juste quelques pistes de recherche; USB Copy (je ne connais pas car je ne l'utilise pas) Volume sauvegardé et combien de versions? A quoi sert robocopy.exe???

Bonjour, Je vais vous donner mon avis, mais ce n’est que mon avis. Sur un NAS à 4 ou 5 baies, je conseille de rester sur le SHR1(raid 5) car la perte de capacité de stockage me semble prohibitive pour un SHR2 ou un disque en spare. Au dessus de 5 disque le SHR2 peut être envisagé mais dépend de l’utilisation du NAS. Le point principal est de savoir si la continuité de service est importante : Par exemple si le NAS héberge votre serveur DNS, votre messagerie, est la destination de sauvegardes externes… , le SHR2 est un plus. Il est également plus rapide de changer des disques plutôt que de reprendre une installation à partir de 0 et de rapatrier les données sauvegardées. Les disques peuvent tomber en panne lors d’absences prolongées (congés par exemple). En résumé vous êtes le seul à savoir quelle est la meilleure configuration pour votre NAS. En complément: A l'utilisation la différence de vitesse raid 5/ raid 6 n'est pas sensible

Heureux pour vous que le problème ait trouvé sa solution. Il arrive à tout le monde de faire ce genre d'erreur.

Bonjour, J’ai découvert ce fil lors d’une visite rapide sur le forum. Je vais donc apporter quelques infos pour aider au debug. Version installée 1.31. Connexion OK ( avec reverse proxy (port443) et password avec caractères spéciaux) Interception des liens OK. Les liens de téléchargement ne parviennent pas à downloadstation. Par contre le téléchargement local fonctionne. Si l’on clique sur l’Icône des téléchargements l’adresse se termine par /download.

Le lien parle bien de 2 volumes (quelques extraits ci-dessous) : Monte l'autre disque dans ton nas et crée un nouveau volumes. (gestionnaire de stockage \ volumes \ créer ) Mieux vaut créer un deuxième volume. C'est en tout cas la seule méthode possible pour étendre votre stockage sans perdre les données existantes et sans changer de disque. Vous pouvez tout simplement déplacer certains dossiers partagés du volume 1 vers le volume 2. C'est très simple à faire. Il suffit d'aller dans les dossiers partagés et de changer le volume de stockage. Le NAS fera le transfert du dossier et de son contenu du volume 1 vers le 2. Pour répondre à vos questions sans entrer dans les détails : Groupes de stockage : c’est l’organisation des disques :Basic, Raid, SHR... Volume : C’est l’organisation des données sur ces groupes de stockage ; 1 ou plusieurs volumes sur un groupe de stockage. Pour votre besoin, il faut 2 groupes de stockage correspondant aux disques 1 et 2 (en basic) avec un volume sur chacun (sur la totalité du disque) Donc volume1 sur disque 1 (premier groupe de stockage) volume2 sur disque 2 (second groupe de stockage) Vous n’avez pas à gérer directement les volumes mais les dossiers partagés. Vous affectez ces derniers au volume 1 ou au volume 2 et DSM se charge de stocker les données sur le volume correspondant. (Il n"est pas possible d'avoir des fichiers des dossiers partagés avec le même nom sur différents volumes) Pour votre besoin le dossier TM affecté au volume 1, les dossiers film et musique au volume 2. Donc les sauvegardes TM envoyées vers le dossier TM et les nouveaux films vers le dossier film.

Bonjour, Les nouveaux membres sont invités à se présenter dans la section prévue à cet effet. Concernant votre question, vous avez mal cherché sur le forum car ce sujet a déjà été souvent traité. Par exemple:

Bonsoir, Pour info, la LB2 (la seule que je connaisse) attribue des adresses hors DHCP sans problème.

Bonsoir, Comme promis script corrigé pour éviter les redémarrages multiples de packages. Et cette fois ci je n'ai pas oublié de remettre les 85 jours! Bonne soirée JP majcertif.sh

Désolé, mais le tutoiement n’est pas naturel pour moi , mais j’y veillerai à l’avenir. D’un examen rapide du log il apparaît que : les redémarrages multiples de paquet ne sont pas résolus comme je le pensais, 2 pour MailPlus-Server (postfix et dovecot) 6 pour WebStation (6 vhost) la replanification est fixée à 2 jours (modif que j’ai faite pour test et oublié de corriger) Chez moi, phpMyAdmin et Apache sont en cours d’exécution et sont toujours actifs après le renouvellement ! Moments n’est pas installé. Ce que je te propose pour la suite : tu modifies le script pour replanifier aux environ de 85 jours(ligne 45 du script) je corrige de mon coté le pb des redémarrages multiples et t’envoie un script corrigé assez rapidement. Puis je n’interviens plus sur ce fil. Je continue cependant à chercher l’origine de l’arrêt de certains paquets chez toi. Si jamais j’y arrivais (probabilité faible) je reviendrai poster ici la solution. Bonne soirée PS : m’autorises-tu à, éventuellement, te contacter par MP si j’ai besoin d’infos sur ta config ? Bonne soirée JP

Bonsoir, Bienvenue dans cette communauté. Il me semble normal d’être 'pommé' quand l'on est sur Mac! (Désolé c'était trop tentant!) Bonne soirée

Bonsoir Yann, Je vous joins un nouveau script, car je me suis aperçu que le précédent n’était pas fiable. Je me servais des dates de fichiers de clef privée pour faire le tri des certificats. Or ces dates peuvent être modifiées lors de certaines opérations (restauration de config, nouvelle importation du certificat…) Ce nouveau script est complètement différent mais doit donner des résultats identiques au précédent ( avec certainement les mêmes inconvénients). Il évite cependant les relances multiples de paquets (vu sur votre dernier log). J’ai lancé, chez moi, apache, il n’est pas arrêté comme chez vous! J’ai beau fouiller dans le DSM, je ne trouve aucune piste sur l’origine de l’arrêt de certains paquets. Bonne soirée. Merci à @Jojo (BE) pour ces encouragements, c’est beau l’optimisme ! PS: pour lecteurs autres que Yann, Ce script n’est pas utilisable en l’état ! majcertif.sh

Bonjour, Une question bête mais sait-on jamais. Passez vous par le reverse proxy?

Bonjour, Tous les certificats existants se trouvent dans : /usr/syno/etc/certificate/system/_archive. Un dossier par certificat, Ceci étant un script faisant une simple copie des fichiers du certificat du Nas1 dans le Nas2 sera loin d’être suffisant pour importer le dit certificat. La meilleure méthode reste celle indiquée par @pluton212+ . D’autant qu’il y a presque un mois pour faire cette importation. Le renouvellement du certificat du Nas1 se fera aux alentours de 60~62 jours. Le certificat sur le Nas2 restera valable jusqu’aux 90 jours. PS; Si vous passez par un reverse proxy vous pouvez faire la redirection vers le Nas2 en http. Dans cette configuration pas besoin de certificat sur le Nas2

Hello Yann, Merci de ce retour. Je vais regarder ce log de plus près et attendre ton retour sur ton prochain renouvellement qui hélas aura certainement les mêmes anomalies. Mais comme je te l’avais annoncé dès le début, je n’utilise pratiquement jamais le shell (ce doit être mon 3eme ou 4eme script) dont je ne connais que peu de choses. Comme mes connaissances de linux sont également faibles (et DSM c’est encore pire), je pense qu’on approche de mon niveau d’incompétence. Je ne sais pas si l’on va finalement aboutir.

Bonsoir Yann, Il y avait bien une date qui posait problème et comme par hasard c’est celle dont je me servais comme référence dans mon script. Mais maintenant, après passage de mon script, TOUTES les dates sont incorrectes !!! Voilà ce qui arrive quand on lance des scripts écrit par un amateur ! Je te joins une nouvelle version qui va (devrait) rétablir une situation correcte. Je suis revenu à mes cp au lieu des cat (espérons que Fenrir ne passera pas ici !) car c’est la seule solution que je connaisse qui permet de conserver la date d’un fichier lors de sa copie), Fichier à lancer avec les mêmes prérequis que précédemment. PS : acme te retourne-t’il toujours ces lignes : [Tue Jul 24 01:43:05 CEST 2018] Installing cert to:/usr/syno/etc/certificate/system/default/cert.pem [Tue Jul 24 01:43:05 CEST 2018] Installing key to:/usr/syno/etc/certificate/system/default/privkey.pem [Tue Jul 24 01:43:05 CEST 2018] Installing full chain to:/usr/syno/etc/certificate/system/default/fullchain.pem [Tue Jul 24 01:43:05 CEST 2018] Run reload cmd: /usr/syno/sbin/synoservicectl --reload nginx Elles n’existent toujours pas chez moi. si c’est le cas, je corrigerai le script de renouvellement pour prendre en compte plus proprement les 2 variantes Bonne soirée uniformiserdateclefprivee.sh

Le mini script annoncé. Prérequis; avoir mis le certificat Let's Encrypt comme certificat par défaut et configuré pour la totalité des services. A lancer (SSH ou planificateur de taches) par: bash chemin_du_script > chemin_d'un_fichier_log 2>&1 Merci de me montrer ce fichier log après avoir masqué le nom de ton certificat qui figurera sur de multiples reprises. En espérant que le pb était bien là. (je suis assez peu optimiste!) uniformiserdateclefprivee.sh

Bonsoir Yann, Je ne suis pas aussi assidu que toi sur ce forum, j’ai donc raté ton dernier message. Mon certificat vient également de se renouveler et toujours pas le même pb que toi sur le navigateur. Avec Firefox : J’ai peut être une piste car j’ai vu que chez toi il y avait peu de mise à jour des reverses proxy et des paquets. Cela pourrait venir d’écarts de dates sur les fichiers de clef privé (en particulier s’il y a eu plusieurs importations manuelles du certificat). Dès que possible je vais t’envoyer un mini script qui uniformisera ces dates. On verra au renouvellement suivant si cela apporte quelque chose. J’en profite pour te joindre une nouvelle version du script. Pas de changement sur le fonctionnel mais rajout du quelques tests initiaux : Vérification que acme est bien installé Vérification qu’un certificat a bien déjà été créé et quelques modifs sur le log. majcertif.sh

Bonjour, Quelques petites remarques Attention aux retours de lignes qui sont différents selon l'OS (windows, mac, linux) Par exemple sous windows , l'utilisation de notepad++ est souhaitable (après l'avoir paramétrer pour les retours de ligne Unix). Le shell par défaut de nos nas est le bash (depuis DSM6 sauf erreur de ma part)

Sans doute un service non redémarré alors qu'il aurait du? Je suppose qu'avec une entrée manuelle des certificats, cela fonctionnera également correctement.

C'est loin le 11 octobre! Peut-être aurons nous eu l(idée de chercher au bon endroit d'ici là.

Je n'ai vraiment pas d'idées à ce propos. D'autant plus que tu dis que cela fonctionne en navigation privée. Je chercherai si je trouve une piste (sans grand espoir d'aboutir)

Alors attendons ton prochain renouvellement.