Mic13710

@KeizerSauze ok, mais alors pourquoi venir nous parler de la 7.2 dans un sujet qui concerne la 7.3 (voir le titre) ?

Quel est le rapport avec le problème posé ?

Bien sûr que oui ! https://www.synology.com/fr-fr/support/download/DS916+?version=7.3#system

Vous êtes sûr ? La mise à jour vers 7.3 pour ce modèle est manuelle.

@salinois , la dernière visite de @hpsmartyz remonte à 2022. Je doute qu'il vienne vous répondre.

Je ne pense pas qu'il y ait de conflit à partir du moment où vous utilisez des ports différents pour chaque VPN sur le NAS et que les équipements connectés via Wireguard ne le sont pas via tailscale. Mais pourquoi ne pas tout simplement utiliser tailscale partout ? C'est basé sur Wireguard et ça éviterait de faire tourner deux VPN sur les NAS.

Il y a un souci de compréhension dans votre demande. Quand vous écrivez : Cela veut dire que vos disques sont en RAID1 ou SHR avec protection des données, ce qui n'est pas le cas. Maintenant, vous avez 2 volumes et si je comprends bien vous voulez avoir un seul volume sur 2 disques en ajoutant leurs capacités. Ce que vous voulez peut se faire à l'aide de deux montages : JBOD ou RAID0. Si vous voulez ce type de montage, il va falloir détruire les deux groupes existants (ce qui bien entendu détruira les données) pour reconstruire un groupe JBOD ou RAID0. Sinon, vous pouvez conserver le montage actuel sur deux volumes mais il va falloir réorganiser vos dossiers partagés en transférant des dossiers du volume 1 vers le volume 2. Cette opération est très simple à réaliser. Vous allez dans le menu Dossier Partagé, vous sélectionnez le dossier que vous voulez déplacer, bouton Modifier, vous changer l'emplacement pour le volume 2 et vous sauvegardez. DSM va alors transférer le dossier et son contenu vers le volume 2. Vous renouvelez l'opération pour chaque dossier que vous voulez déplacer de sorte à équilibrer vos données sur les deux volumes. Je vous recommande cette dernière solution qui sera beaucoup plus sécurisante pour vos données. En effet, alors que sur un groupe JBOD ou RAID0 la perte d'un disque se traduit par la perte de toutes les données, la même perte d'un disque sur un système à deux volumes sur deux groupes ne fait perdre que les données du volume contenu dans le disque. L'autre disque et ses données sont préservés. Ceci étant posé, à vous de décider ce que vous souhaitez faire. Sans oublier un point essentiel : quel que soit le montage que vous adopterez, il est vital de mettre en place une sauvegarde périodique des données, au moins les plus importantes, pour faire face aux risques de pertes ou de corruption de données. C'est d'autant plus important avec le JBOD ou RAID0 où la perte est totale en cas de panne d'un disque.

Bonjour, Ce forum est dédié aux NAS. Il n'a pas vocation à répondre sur des problèmes relevant des réseaux et d'une manière générale sur les équipements sans lien avec les NAS. Je vous conseille de vous orienter vers un forum plus généraliste où vous aurez plus de chance de trouver des réponses.

Autrement dit pourquoi faire simple quand on peut faire compliqué. Si les deux NAS sont sur le même réseau, inutile de placer un intermédiaire pour faire ce qui peut être fait en direct. Vous donnez l'IP privée du NAS de destination sans chiffrage (à moins que vous n'ayez aucune confiance dans les utilisateurs de votre propre réseau) et c'est tout. Là aussi, c'est étrange. Comment se fait la connexion si vous utilisez wireguard de chez vous vers votre travail alors que les serveurs wireguard sont sur vos NAS ? Ou je n'ai rien compris, ce qui est possible, ou alors il faudra je pense revoir votre système de VPN.

Bonjour @Pat45 , soyez le bienvenu sur ce forum. Pour votre information, Présentation veut bien dire ce que ça veut dire. Pour les questions, il faut les poser dans les sections dédiées à cet usage. Je verrouille donc ce sujet, à charge pour vous de renouveler votre demande.

Je vais te donner une méthode mais chut, tu le dis à personne, d'accord ? 😁 Tu changes l'extension du fichier en .tar Bon après, tu vois beaucoup de choses mais le seul fichier vraiment intéressant à mon sens est le _Syno_ConfBkp.db pour lequel je te laisse chercher comment le lire...

Décidément vous êtes fâché avec les dates 😉 Ce n'est pas parce que la règle actuelle autorise jusqu'à 398 jours pour les certificats les plus longs que l'organisme certificateur (LE en l’occurrence) doit émettre des certificats de cette durée. Ils ont choisi 90 jours pour leurs certificats, c'est leur droit et je trouve cela très sain car plus un certificat à une durée lointaine, plus les possibilités d'usurpation d'identité augmentent. A terme, LE a choisi 45 jours de validité pour être en conformité avec les 47 jours qui seront effectifs en 2019. Les choix de LE sont ce qu'ils sont et il faut faire avec. En ce qui concerne les 60 jours (et maintenant 30 jours) pour le renouvellement, c'est le choix de l'équipe qui à créé et maintient le script acme.sh. Ca n'a strictement rien à voir avec LE. De manière conservative, ils lancent le renouvellement après 60 jours (30 jours maintenant) car le renouvellement peut demander plusieurs jours. Il arrive en effet assez souvent que le renouvellement ne se fasse pas le jour même et nécessite plusieurs lancements (1 par jour) pour se terminer. La période de 30 jours est donc là pour couvrir les échecs et aussi permettre de régler d'autres problèmes bloquants avant expiration du certificats. Lorsque la validité du certificat LE à 45 jours sera effective, avec 30 jours pour lancer le renouvellement, il restera 15 jours pour qu'il soit effectif, ce qui est court mais suffisant. Pourquoi réduire les validités des certificats, c'est précisément pour limiter les risques car avec les nouvelles technologies, cela demande beaucoup moins de temps aux hackers en tous genres pour contourner un certificat et usurper la certification d'un site donné. Ce qui était encore protecteur il y a quelques années avec 398 jours ne l'est plus aujourd'hui. En réduisant la validité, on réduit ces risques. C'est une décision mondiale qui obligera à terme les entreprises à automatiser les renouvellements de leurs certificats sinon ce serait un casse tête pour les dites entreprises s'il fallait faire un renouvellement manuel. Pourquoi le faire par étapes (398, puis 200, puis 100 et enfin 47) ? Parce que justement beaucoup d'entités ont des certificats longs. Elles font des renouvellements manuels et il est impossible de leur demander de changer leur mode de renouvellement du jour au lendemain. Il y a plusieurs processus disponibles pour automatiser les renouvellements, acme étant le plus simple à mettre en oeuvre.

Je ne comprends pas votre intérrogation. Durée de vie d'un certificat ou durée de validité, c'est la même chose. Au delà, le certificat n'est plus valide ou si vous préférez, il est mort. Si vous voyez une différence entre les deux termes, pourquoi pas, mais au final, le certificat n'est plus reconnu par aucun navigateur. Votre confusion vient plutôt de la date de renouvellement. Celle-ci doit bien évidemment être inférieure à la date de fin de vie du certificat. La validité d'un certificat LE est de 90 jours. Jusqu'à présent, le renouvellement était déclenché par le script à partir du 60eme jour ce qui laissait 30 jours pour ce renouvellement. Ca n'a pas changé chez LE puisque la validité est toujours de 90 jours pour encore quelques temps mais il semble que le script acme.sh ait raccourci le renouvellement à 30 jours après la date de création. Encore une fois, ça n'a aucune incidence sur nos utilisations. Le certificat serait renouvelé tous les 10 jours que ce serait transparent. Ensuite, que LE réduisent la durée de validité de leurs certificats de 90 à 45 jours avant la date d'échéance officielle est à leur seule discrétion. Il n'y a rien d'anormal d'anticiper si les utilisateurs ont pris leurs précautions pour faire face à ce changement. C'est fait du côté d'acme.sh, nous sommes donc parés pour des renouvellements plus fréquents.

47 jours, ce sera probablement un renouvellement tous les mois avec Let's Encrypt. Ce n'est pas pour tout de suite et de toute manière le script acme sera adapté en conséquence. Si les lignes que vous donnez proviennent de votre dernier renouvellement, il est possible que acme ait déjà intégré le renouvellement à 30 jours. Quant à pouvoir étendre la durée de validité, ce n'est pas possible. La durée indiquée est fonction du certificat obtenu auprès de LE. Vous ne pouvez pas la modifier. Vous pouvez raccourcir la période de renouvellement en modifiant le fichier .conf mais surtout pas l'allonger au dela de la validité du certificat. Peu importe finalement la durée. Si vous avez suivi le tuto et fait l'installation dans les règles, le renouvellement se fait automatiquement à partir de la date enregistrée dans le .conf. C'est donc transparent côté utilisation. Edit : Je viens de contrôler sur mon NAS et effectivement, le renouvellement est passé à 30 jours alors que le certificat est valable 90 jours. Mon dernier certificat est valable jusqu'au 27/03/2026, mais dans le .conf j'ai ceci : Le_CertCreateTimeStr='2025-12-27T21:27:43Z' Le_NextRenewTimeStr='2026-01-25T21:27:43Z' soit un renouvellement 30 jours après la date de création. Ce qui signifie que le script acme.sh a déjà anticipé une période de renouvellement plus courte.

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.