Mic13710

Je ne comprends pas. Si vous mettez seulement ndd sans spécifier de port, ça ne fonctionnera pas. Vous ne pouvez pas non plus utiliser www.ndd qui est normalement réservé pour Web Station.

Je répète ce que j'ai dit plus haut :

Oui, c'est bien ça. On peut aussi utiliser le reverse proxy pour rediriger les requêtes vers d'autres équipements sur le réseau, par exemple un Rasp. Le problème, et non des moindres, c'est que si le NAS1 tombe en panne ou est arrêté, les noms de domaines ne peuvent plus atteindre leurs cibles.

Bonjour olivier97430, soyez le bienvenu. Le Tampon lé bien meilleur !

Peut-être n'est ce pas étranger à ce qui se passe dans cet autre fil :

Amusant. Pourquoi éteindre le NAS alors qu'il est possible de retirer et monter des disques à chaud ? Et si vous l’arrêtez (ce qui est bien entendu possible) pourquoi le faire après avoir retiré le disque ? Quelle est la logique ? Sinon pour le reste c'est bon. P.S. : vous n'avez pas répondu à ma question concernant des éventuelles migrations.

Bonjour jxien, soyez le bienvenu. Belle présentation. @PiwiLAbruti, c'est bon, je contrebalance.

Activer leurs droits dans la console d'administration de drive

@louloudu77 ce que vous dites est certainement vrai mais ne fait aucun sens lorsqu'on connait le fonctionnement d'un RAID1. Si un groupe en RAID1 est dégradé c'est qu'un disque est hors service. L'autre disque est sain et il n'y a rien qui a pu modifier son status d'avant la panne. Et donc, que vous répariez un groupe avec un disque de même capacité puis que vous enleviez ce disque pour le remplacer par un disque de capacité supérieure (ce qui au passage vous fait faire 2 réparations), ou que vous répariez le groupe directement avec un disque de capacité supérieure ne change rien à la situation d'avant réparation : le disque initialement en bon état sera le même dans les deux cas. Depuis le temps que je hante ce forum, c'est bien la première fois que j'entends parler d'une double réparation sur un RAID1. Ce qui peut se produire par contre sur un RAID1, c'est une dégradation à la fois sur la partition système d'un disque et sur la partition donnée de l'autre. J'ai déjà vu ce cas quelques rares fois et là c'est la loose parce-qu'il est impossible de remplacer un des disques en panne, les deux étant en défaut. La seule issue c'est de sauvegarder et de tout réinstaller avec des disques neufs.

@Gramm les réponses qui vous ont été apportées dans votre demande précédente ne vous suffisent pas ? Par ailleurs, vous parlez de votre NAS sans nous dire de quel modèle il s'agit. Et comme vous ne vous êtes pas présenté sur ce forum, il est impossible de deviner. Or selon le modèle en question, les réponses peuvent être différentes.

@louloudu77 on peut tout à fait reconstruire un RAID avec un disque de capacité supérieure. Ce que vous proposez n'est rien de moins que de se retrouver dans la même situation qu'actuellement mais en deux étapes. Retirer un des 2To pour le remplacer par un 8To ou mettre directement un 8To, c'est kif kif la même chose pareil 😉 @eric51 Quels modèles de disques ? Est-ce qu'ils font partie des disques approuvés, et surtout, est-ce qu'il sont bien en CMR et pas en SMR ? https://www.synology.com/fr-fr/compatibility?search_by=products&model=DS218%2B&category=hdds_no_ssd_trim&filter_size=8TB&p=1&change_log_p=1 Que le NAS ne redémarre pas avec un seul disque n'est pas normal puisque le système est installé sur tous les disques. Est-ce que par hasard vos 2To n'auraient pas été migrés d'un ancien NAS ? Si oui, quel modèle ?

@Einsteinium Non, rien changé. La seule modif c'est le passage d'acme.sh en rev 3.0.6 qui a mis un peu le foutoir chez certains. Pas le password (il n'est pas en base 64), mais le nom du certificat. Alors qu'il fonctionnait très bien jusqu'à l'avant dernier renouvellement, le script n'arrive plus à le récupérer ce qui bloque le déploiement. Voir le sujet de Kramlech dans lequel je parle de ça : J'ai eu le même problème sur 3 NAS. Je ne suis donc pas un cas isolé. Pas de problème pour ceux qui n'ont qu'un seul certificat. Pour ma part j'en ai 3 et donc le nom du certificat est primordial pour pouvoir déployer. Je m'en suis sorti en changeant la variable SAVED_SYNO_Certificate=__ACME_BASE64__START_NomDuCertificatEnB64==__ACME_BASE64__END_' en SYNO_Certificate='Nom du Certificat dans DSM' Mais je pense que c'est provisoire car après déploiement, la variable a été à nouveau enregistrée en Base 64.

Avez vous testé votre disque avant de le mettre dans le NAS ? Si ce n'est pas encore fait, commencez par lancer un test smart étendu sur le nouveau disque. S'il n'aboutit pas, il est possible que le disque soit défaillant. Il faudrait alors lui faire passer les batteries de tests constructeur avec Seatools.

Non, inutile. A partir du moment ou le déploiement a été fait par le script, tout est OK. Le problème du non déploiement a été localisé au niveau du SAVED_CERTIFICATE qui chez certains ne passe pas. J'en ai moi aussi été victime et je ne comprends toujours pas pourquoi ni comment c'est arrivé. Chez d'autres, c'est carrément tous les SAVED autres que les clés qui ont été la cause. Voir les échanges de ce fil depuis le passage à la version 3.0.6 d'acme.sh

Le déploiement c'est seulement pour attribuer le certificat aux applications en fonction des choix fait dans les paramètres dans DSM. Une fois déployé, il est valide jusqu'à expiration du certificat. Il n'y a donc pas besoin de refaire l'opération. Le déploiement est à nouveau lancé par le script qu'après l'obtention d'un nouveau certificat.

J'émets une hypothèse : sans doute parce que ceux qui achètent un 923+ n'ont pas besoin de transcodage 🤪

On parle ici d'un cas particulier. Ma réponse était en rapport avec le tuto où il n'y a pas de script à rajouter dans ACME. De toute manière, si le déploiement ne s'est pas effectué correctement lors du renouvellement à cause de ce fameux SAVED_, il y a fort à parier qu'il ne fonctionnera pas mieux à partir d'un script additionnel. Perso, je ne fais pas la mise à jour auto du Docker-compose. J'en suis resté à la version précédente. C'est un choix personnel. Ce qui ne change en rien au mode opératoire du script acme.sh qui est identique avec ou sans mise à jour du Docker-compose. acme.sh est lancé automatiquement tous les jours à 0.00. Il vérifie d'abord qu'il est à jour à la dernière version et télécharge la nouvelle version si besoin, puis il vérifie la date du certificat et si au delà des 60 jours, il lance son renouvellement et son déploiement. Nul n'est besoin de scripts supplémentaires, à condition bien entendu que le processus se soit déroulé normalement. Aussi, je ne comprends pas bien le pourquoi de tes scripts persos. De mon côté, suite au problème rencontré lors du dernier renouvellement avec le SAVED_CERTIFICATE, j'ai rajouté une tâche planifiée non activée dans DSM pour relancer le déploiement en cas de besoin.

Ce n'est pas la raison. Le déploiement se fait directement après le renouvellement du certificat. Par la suite, le script ne fait que vérifier la date de validité du certificat. S'il c'est moins de 2 mois, il termine la tâche. Il ne vérifie pas si le certificat a été déployé ou pas. J'ai moi aussi été confronté à l'histoire des SAVED sur le nom du certificat, ce qui a bloqué son déploiement et par voie de conséquence son affichage dans DSM. En supprimant le SAVED_ et en remettant le nom en dur du certificat (pas en base64) j'ai pu relancer manuellement le déploiement et tout est rentré dans l'ordre. Mais le nom du certificat a été rétabli en base64 et son SAVED_. Je surveillerai le comportement lors du prochain renouvellement. @Einsteinium cette histoire de SAVED_ se reproduit souvent et nous sommes plusieurs à avoir eu ce comportement. Ce n'est donc pas un problème isolé. Je pense qu'il faudrait rajouter une note dans le tuto en indiquant que dans certains cas le nom du certificat n'est pas pris correctement en compte par le script et qu'il faut dans ce cas réécrire cette ligne en clair et sans le SAVED_ puis relancer le déploiement pour qu'il aboutisse.

liste des 12To compatibles avec le 923 https://www.synology.com/fr-fr/compatibility?search_by=products&model=DS923%2B&category=hdds_no_ssd_trim&filter_size=12TB&p=1&change_log_p=1

Et ?

Indépendamment du fait que des sauvegardes doivent être faites, j'espère pour vous qu'elles sont périodiquement mises à jour parce que 2 disques en RAID0 c'est deux fois plus de chances de perdre ses données.

Déja commencer par poser la question dans la bonne section. Vous avez su trouver File Station, il était tout aussi simple de trouver Synology Drive dans le groupe des applications. Je déplace. Dans les paramètres du client, il faut cocher la suppression des fichiers du NAS lorsqu'ils sont supprimés localement

Dans l'interface web de Drive, il n'y a pas la possibilité de supprimer les liens. Il faut les supprimer un à un en suivant le chemin indiqué dans les propriétés du lien. Une fois sur l'emplacement, on clique sur le bouton de partage et on supprime les différents accès pour supprimer le partage.

Désolé mais je ne comprends strictement rien à votre demande. Elle concerne Synology Drive côté serveur (ce que semble indiquer votre demande) ou côté client (votre titre) ? En tout état de cause, votre demande n'a rien à faire dans la section Installation, Démarrage et Configuration. Je déplace.

Bonjour, Voici un article qui met à mal l'anonymat de certains serveurs VPN. https://www.01net.com/actualites/pire-que-tiktok-ces-vpn-populaires-peuvent-lire-vos-donnees-privees.html Et un autre : https://www.commentcamarche.net/securite/vpn/27943-confidentialite-des-vpn-des-applications-collectent-des-donnees-privees/#utm_source=MagNews&utm_medium=email&utm_campaign=Comment ca Marche High Tech_Mercredi 29/03/2023&een=82ced6dcfa7cf711312e2bee357540fa&seen=2&gbmlus=648774cf71a71ac5895017a42ab99affae8f1502ce9f6d51e29c6a29eac24d10