Mic13710

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.

Pour le format, vous avez raison. Le boîtier a en fait deux fonctions distinctes. S'il est utilisé en extension d'un NAS QNAP, alors le format est seulement le EXT4. Par contre, s'il est utilisé en disque externe, alors il est possible d'utiliser d'autres formats. Dans ce cas, il vous faut choisir un format compatible avec votre MAC. Je m'étais arrêté à la fonction extension.

Je ne suis pas utilisateur de QNAP, aussi mon avis n'est pas forcément le plus juste en ce qui concerne cet équipement. Pour votre configuration, je recommanderais d'utiliser QNAP External RAID Manager plutôt que les boutons hardware à l'arrière du boîtier. Avantages du logiciel : Interface claire pour surveiller l'état des disques (santé, température, erreurs) Notifications en cas de problème Plus de flexibilité pour gérer et modifier la configuration Possibilité de voir les informations SMART des disques Mise à jour du firmware plus facile Concernant l'utilisation mixte : Si vous configurez le RAID via les boutons hardware, vous pourrez peut-être utiliser QNAP External RAID Manager pour consulter les informations sur l'état des disques car il serait logique que le logiciel puisse lire la configuration existante même si elle a été faite en hardware. A titre personnel, je choisirais la solution logicielle car en cas de panne du NAS avec un raid hardware, les disques seront plus difficiles à lire en dehors du NAS car il manquera la partie hardware pour contrôler le RAID. En version logicielle, le soft de gestion mdadm est disponible sur la plupart des versions linux en téléchargement, sauf si QNAP utilise un soft propriétaire ce que je ne sais pas, auquel cas il faudra rechercher ce soft. Ce n'est pas vous qui décidez, c'est le NAS et sauf erreur chez QNAP c'est du ext4. Pas de BTRFS. Ca n'a aucune importance que vous ayez derrière un MAC ou un PC, c'est uniquement le format du fichier qui est important pour que votre MAC ou PC puisse le lire, pas la gestion de son stockage.

Sans aller jusque là, vous pouvez le faire via Putty. Vous le téléchargez ici : https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html Vous le lancez, host name : IP du NAS Vous rentrez vos identifiants administrateur. Au prompt vous rentrez sudo -iVous êtes en root (ce que vous ne pouvez pas faire avec winscp) Vous passez les commandes suivantes : rm -rf '/volume1/@synologydrive' rm -rf '/volume2/@synologydrive' rm -rf '/volume3/@synologydrive'

Le nom d'hôte c'est l'ip du NAS (192.168.x.y)

Le certificat est valable 90 jours mais le renouvellement est lancé automatiquement à partir du 60 ème jour. Sans plus d'informations, je ne vois pas à quoi correspondent les deux lignes que vous donnez. Pour la durée maximum d'un certificat, il est prévu d'en réduire la validité pour passer à 47 jours en 2029. Voici le planning : Ce qui signifie que les validités des certificats Let's Encrypt seront réduites en 2029.

Le NAS ne va qu'une fois par semaine vérifier si DSM est à jour selon le planning mis en place dans les options de mise à jour.

Pas d'affolement. Ce qui se passe est tout à fait normal. Les updates ne sont pas des versions complètes mais des patchs. Donc, lors d'une réinstallation, la seule version installable sur le NAS est la version de base. C'est exactement ce qu'il s'est passé. Par la suite, selon les paramétrages, DSM va chercher si de nouvelles versions ou des updates existent et les propose au téléchargement. Mais rien ne t'empêche de faire une installation manuelle en chargeant le .pat sur le site.

Je pense que le fichier .dss est migrable d'un NAS à un autre. Cependant, il ne faut pas exclure quelques réajustements mais je pense que le fond ne sera pas impacté. Après, rien ne t'interdit de faire des captures d'écran des différentes page de DSM pour t'assurer de ne rien oublier et pouvoir le cas échéant retrouver ce que tu avais fait sur l'ancien NAS. La migration doit être possible mais il y a un gros mais, la partition système a été fortement augmentée (de 2.2 à 7.9) depuis la version 7 si j'ai bonne mémoire, ce qui rend obligatoire une réinstallation complète pour ne pas se retrouver à devoir le faire plus tard par manque de place pour le système. Tu me surprends ! Dois-je te rappeler nos échanges avec Fravadona il y a quelques années concernant ces fameuses partitions et sur le fonctionnement du SHR ? Il n'y a à la base que 3 partitions lors de la construction du groupe. Mais si des disques ont été remplacés par de plus gros alors oui, une ou plusieurs (s'il y a eu plusieurs augmentations) autres partitions sont rajoutées au groupe pour créer de nouveaux RAID, 1 ou 5. C'est en cela que le SHR est un RAID hybride puisqu'il combine à la fois des RAID1 et RAID5 au sein d'un même groupe, chaque RAID ayant sa propre partition. Mais tout ça tu le sais déjà 😉

Normalement, le simple fait de supprimer complètement l'application devrait aussi supprimer le dossier caché. Mais ce n'est pas toujours le cas. Il faut alors se connecter au NAS en ssh et dans chaque volume (vous en avez 3, le quatrième étant déjà vidé), il faut supprimer le dossier @synologydrive Vous devez pour cela activer ssh dans DSM. Vous passez ensuite sur un terminal (Putty) ou si vous avez windows, vous installez winscp qui sera beaucoup plus facile si vous ne maitrisez pas les lignes de commande. Connexion en tant qu'administrateur avec vos identifiants d'administrateur de DSM.

Optez plutôt pour un Backups BX https://www.se.com/fr/fr/product-range/61883-onduleur-backups/?parent-subcategory-id=8010&N=brand%3Dse%26country-code%3DFR%26language-code%3Dfr%26ats_rated_power_in_va%5B%5D%3D950%25C2%25A0VA%26ats_rated_power_in_va%5B%5D%3D750%25C2%25A0VA&selected-node-id=27590290410#products On trouve le 750VA vers 100€, le 950VA vers 120€-130€