Mic13710

Bonjour bchanhkg, soyez le bienvenu dans la communauté. Euh, un DS718 de plus de 5 ans, c'est impossible : 18 représente l'année modèle 2018

Là c'est l'adresse qui est enregistrée, pas nécessairement votre IP actuelle. Pour le savoir http://www.mon-ip.com/

Les IP chez Free sont fixes, sans demande spéciale. Ce qui est plus important, c'est de vérifier dans votre interface que votre IP est bien full stack. Si ce n'est pas le cas (ce qui est le plus probable), il faut en faire la demande. Après cette opération, votre IP va changer. Il faudra aussi la changer dans votre enregistrement A chez OVH.

Si IP publique fixe, pas besoin de ddns. Il suffit de mettre un enregistrement A qui pointe sur votre IP fixe. Mais, parce qu'il y a un mais, il faut que votre IP soit full stack (si vous êtes chez free, il y a de fortes chances pour qu'elle ne le soit pas), que votre routeur dirige bien le port 443 vers le NAS et que le reverse proxy soit correctement paramétré. Ou bien si pas de reverse proxy, que les ports des applications auxquelles vous voulez avoir accès soient bien dirigés vers le NAS dans le routeur. Et il faut enfin que votre parefeu ne bloque pas le trafic.

C'est pourtant clair : votre nom de domaine ne pointe pas vers votre IP externe. Il faut revoir vos réglages de ddns pour que les changements d'IP soient pris en compte par votre domaine.

Je pense qu'il serait intéressant d'en faire un tuto. Pour le disque dégradé, une mauvaise manip dans les commandes peut-être ? Incidemment, je viens de retrouver une procédure pour résoudre le même problème d'extension de groupe. https://www.nas-forum.com/forum/topic/58702-changement-disques-pas-daugmentation/?do=findComment&comment=1319342758

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.

2 remarques : 1 - L'augmentation d'un groupe n'est possible que si le ou les volumes qu'il contient ne sont pas susceptibles de dépasser la capacité maxi par volume. Si la limite est 16To, il est bien évident que vous ne pourrez pas augmenter votre volume au delà, même si votre groupe fait 18To 2 - le "ajouter par au moins le plus gros" n'est pas exact puisque dans votre cas précis, vous avez des 4, des 6 et des 8To dans votre groupe et que dans cette configuration vous pouvez augmenter sa capacité en remplaçant un de vos 4To par un 6To (+ 2To) ou par un 8To (+ 4To). A partir du moment ou la capacité supplémentaire peut être rajoutée à un RAID existant ou à construire, tout est possible. Autre exemple : à supposer que vous ayez 3x4To + 1x8To, soit un groupe de 12To de stockage et 4To inutilisés. Si vous remplacer un 4To par un 6To, le SHR construira un RAID1 de 2x2To avec les 2To restants du 6To et 2To des 4To restants du 8To, créant ainsi un groupe de 12+2 = 14To et 2To inutilisés. Il y a bien eu augmentation, sans pour autant que le disque remplacé soit égal au plus gros.

Si vous remplacer un 4To par un autre 4To, vous n'augmentez pas mais vous réparez le SHR. Si vous le remplacez par un 6To et que votre SHR contient un 6To, alors il y aura une augmentation de volume de 2To puisque le 6To pourra être jumelé. Pour faire simple, un SHR est un RAID hybride qui combine en une seule grappe des RAID1 et des RAID5. Dans votre cas, avec un 4 4 6 8, votre SHR est constitué d'un RAID5 de 4x4To, soit 12To de stockage et d'un RAID1 de 2x2To, soit 2To de stockage. Vous avez au total 12+2 = 14To de stockage et 2To inutilisés. En remplaçant un 4To par un 6To, le RAID5 de 4x4To ne bougera pas. Par contre votre RAID1 de 2x2To sera transformé en RAID5 de 3x2To, soit 4To de stockage, ce qui donne au total 16To. Il y aura toujours 2To inutilisés. Si vous remplacez votre 4To par un 8To, votre SHR sera constitué comme ceci : Le RAID5 de 4x4To, un RAID5 de 3x2To et un RAID1 de 2x2To. Votre stockage sera alors de 12+4+2=18To

Pas tant que ça : depuis juillet. Il y en a, dont moi, qui sont en paramétrage permanent 😉

J'ajoute à cela qu'il n'est pas du tout conseillé de se connecter via un compte admin. Normalement, ce compte ne devrait même pas avoir de droit d'accès aux dossiers utilisateurs et dossiers partagés pour ne pas faire du mélange de genre : administration d'un côté, utilisation de l'autre. La logique veut que la connexion aux dossiers via un PC se fasse par un seul compte utilisateur pour lequel on a donné les droits sur les dossiers partagés auxquels il peut avoir accès.

Ce que vous demandez est absolument impossible, que ce soit avec un NAS, un PC ou un serveur hyper sophistiqué. Un RAID utilise un contrôleur logiciel ou matériel. Il ne peut être construit que sur une même machine ou sur des machines reliées via des bus communs (esata) à partir d'une machine maitre comme par exemple les NAS des séries acceptant des boitiers d'extension sur lesquels on peut étendre des groupes. En aucun cas, on peut gérer des disques en RAID de manière déportée. Comme le fait remarquer white.spirit, la seule solution s'en rapprochant c'est la haute disponibilité, qui n'est pas du tout à la portée de vos NAS. Et même si ça l'était, il faudrait que les deux NAS soient compatibles SHA, soient identiques : mêmes modèles, mêmes versions de DSM, mêmes disques aux mêmes emplacements, et surtout qu'ils soient sur le même sous-réseau. Il n'y a qu'un seul serveur actif, l'autre étant en stand-by, prêt à prendre le relais en cas de panne du premier. Il n'est pas possible d'assigner d'autres tâches au serveur secondaire. Il est clair que dans votre cas aucune de ces conditions n'est remplie. La meilleure solution dans votre cas, c'est ce qui a été proposé par les intervenants précédents : hyperbackup. Ce ne sera pas de l'instantané, mais au moins vous aurez la possibilité de restaurer vos données à partir de la dernière sauvegarde. Vous pouvez aussi envisager de la combiner avec une solution Drive pour les données appelées à être utilisées souvent avec le serveur de vos données chez votre copain, et inversement pour lui. Dans ce cas, les données sont actualisées au fil de l'eau en fonction de la qualité de vos connexions internet. Mais il va falloir être très vigilant sur la protection de vos données respectives.

Si c'était possible cela reviendrait à dire que n'importe qui peut utiliser office à partir de file station sans avoir de licence. Peut-être y a t'il une solution, mais je ne la connais pas. Attendre de voir si quelqu'un peut répondre à votre question. Personnellement, je n'ouvre pas de fichier à partir de file station. Je le fais à partir de l'explorateur Windows.

Je ne suis pas familier avec l'une ou l'autre application en ligne (j'utilise office avec une version installée sur mon PC), mais s'agissant de logiciels en ligne, il faut que le NAS puisse y accéder pour pouvoir les lancer. Je pense qu'il n'est pas indispensable de passer par quickconnect, mais pour pouvoir utiliser un mode de connexion différent, il faudrait que file station soit accessible de l'extérieur, soit par une ouverture de port classique, soit par un ndd et le reverse proxy. Mais encore une fois, je ne suis pas sûr que ce soit suffisant car ces logiciels peuvent avoir des exigences particulières pour pouvoir s'y connecter. Par exemple, Office va considérer qu'il s'agit d'un autre utilisateur, ce qui peut présenter un besoin de licence qu'il faudra résoudre, que ce soit avec quickconnect ou sans.

Bonjour Georges J'ai un peu de mal à comprendre le rapport entre Quickconnect et Microsoft ou Google. Pouvez-vous expliquer ce que vous souhaitez faire ?

@graynon, bienvenue dans la communauté Les perfos à carte, j'ai connu ça aussi il y a ..... un certain temps. Marseille, j'y suis né, y ai vécu 20 ans (à Mazargues, pas loin de chez @Jeff777), puis Toulouse où j'ai fait mes études (c'est là que j'ai connu très brièvement les cartes perforées) pour revenir très vite dans la région. J'habite maintenant Fuveau (d'où mon pseudo) depuis 40 ans.

@graynon pour les présentations, c'est ici : https://www.nas-forum.com/forum/forum/16-présentation/

Lorsqu'il n'y avait pas le hook de déploiement, le script était effectivement loin d'être parfait. Raison pour laquelle je l'ai utilisé et modifié dans le temps pour mes besoins personnels. Il fonctionnait pas mal mais je n'avais pas trouvé de solution autre que de redémarrer le NAS à la fin du script pour que toutes les maj se fassent correctement. Le seul problème c'est que la sauvegarde des snapshots ne redémarrait pas. Il fallait le redémarrer à la mano. La misère. Le hook à l'air de bien fonctionner, aussi j'espère que cette version est aboutie et permette enfin de faire le renouvellement et le déploiement de manière automatique sans devoir passer par un script additionnel pour corriger les dysfonctionnements. La réponse fin décembre.

Par par acme.sh, mais par le script de renouvellement. Copie du script au niveau du déploiement : Le_DeployHook='synology_dsm,' SAVED_SYNO_Scheme='http' SAVED_SYNO_Hostname='localhost' SAVED_SYNO_Port='5000' SAVED_SYNO_Username='moncompte' SAVED_SYNO_Password='monmdp' SAVED_SYNO_DID='' SAVED_SYNO_Certificate='Le nom de mon certificat' La première ligne est assez claire il me semble.

Pas sûr. C'était vrai avant, et j'avais d'ailleurs fait un script pour pallier les dysfonctionnements que j'avais remarqué lors des renouvellements, mais depuis, il y a eu l'apparition du deploy-hook qui simplifie la tâche et me semble faire correctement le boulot. A voir si c'est bien le cas lors du prochain renouvellement.

L'installation en ssh sur le 214 de mon ami s'est faite sans problème. J'ai utilisé la même API que pour son NAS du bureau ce qui m'a évité de devoir faire la double manip indiquée ici : https://github.com/acmesh-official/acme.sh/wiki/How-to-use-OVH-domain-api en rajoutant simplement un export_OVH_CK='consumer key' avant la création du certificat. La séquence est donc la suivante : cd ~ wget https://github.com/acmesh-official/acme.sh/archive/master.tar.gz tar xvf master.tar.gz cd acme.sh-master/ ./acme.sh --install --nocron --home /usr/local/share/acme.sh --accountemail "email@gmailcom" source ~/.profile cd /usr/local/share/acme.sh export OVH_AK="your application key" export OVH_AS="your application secret" export OVH_CK="your consumer key" acme.sh --issue --keylength 4096 -d mydomain.com -d *.mydomain.com --dns dns_ovh export SYNO_Username='Admin_Username' export SYNO_Password='Admin_Password!123' export SYNO_Certificate="Le nom de mon certificat dans DSM" ./acme.sh --deploy --home . -d mydomain --deploy-hook synology_dsm La méthode est donc similaire à celle sous Docker et au final, le fichier de conf est pratiquement identique pour les deux. Par contre, je n'ai pas eu d'enregistrement TXT restant dans la zone après l'opération. A croire que c'est la méthode via docker qui pose problème. Et pour la mise à jour auto, j'ai mis en place une tâche qui lance le processus une fois par semaine : /usr/local/share/acme.sh/acme.sh --cron --home /usr/local/share/acme.sh/ Sur Docker, cette opération est réalisée tous les jours à 0h00. Je ne sais pas si on peut changer ça pour qu'elle soit lancée qu'une fois par semaine aussi.

Je ne vois pas ce que vous pouvez faire au niveau de DSM. Il faudrait passer en ssh pour réparer le volume. Je crois me souvenir qu'il y a déjà eu cette opération décrite quelque part sur le forum, mais je ne me rappelle plus où. Le mieux dans votre cas, surtout si vous n'êtes pas familier du mode terminal, c'est de contacter le support via DSM pour qu'ils interviennent sur votre groupe.

J'ai suivi les conseils de @.Shad.. Après avoir créé un enregistrement A sur ndd.net pointant vers l'adresse d'OVH et un CNAME *.ndd.net, je viens de mettre en place un certificat qui couvre tout le domaine. Pas de problème pour la création, mais là aussi, le TXT n'est pas supprimé dans la zone. J'ai suivi l'état de la zone pendant la création et comme je l'avais vu dans les logs précédents, il y a 2 enregistrements TXT qui sont créés pendant le processus. Un à bien été détruit mais l'autre non. Ce qui tendrait à indiquer que le DELETE fonctionne, mais qu'il y a un truc qui ne passe pas. Je vais m'occuper de l'autre NAS qui est un 214+, ce qui m'oblige à passer par un script dans DSM (pas de Docker sur ce modèle)

Tu as probablement raison. Je referai un nouvelle API un peu plus tard. Pour le moment, je vais me pencher sur les certificats pour les deux domaines dont j'ai parlé dans ce sujet.

Effectivement, il y a une erreur plus loin, ce qui explique qu'il ne soit pas supprimé. Par contre, difficile d'en comprendre la raison. La lecture de ces logs est un peu difficile. Non, c'est bien un enregistrement créé par acme.sh (il a le même texte que dans le log), et je n'avais pas d'enregistrement TXT avant de faire la création via acme. OK pour le delete manuel, je peux faire ça. Mais je ne vais pas le faire après chaque renouvellement. Il faut donc que je sois sûr que la présence d'un enregistrement TXT n'interdit pas la création (ou sa maj) d'un nouveau texte au prochain renouvellement.