Mic13710

Pour avoir un vrai certificat perso, il faut un nom de domaine. Ca, il faut le payer (moins de 10€/an chez ovh, pas vraiment la ruine). Quelques paramétrages et quelques heures plus tard chez OVH, le nom de domaine est actif. Après, y'a le choix entre un certificat class 1 (généralement gratuit), ou un class 2 (généralement payant). Perso, j'utilise StartSSL. Pour la mise en oeuvre, je me suis inspiré de ce blog. Pour le système "Gaëtan", je suis aussi intéressé, mais comme je viens tout juste de renouveler mon certif, ça attendra un peu.

Surtout évitez les 3To WD red. Ce sont les pires actuellement sur le marché en terme de fiabilité. Les 4To semblent plus solides.

OK. Trop balèze pour moi. Je vais continuer à renouveler mon certificat chaque année, ça me prendra globalement moins de temps.

Par curiosité, c'est quoi ta solution ?

En principe non puisque le message concerne uniquement le DSM. La partition de donnée n'est pas touchée. Et puis, comme vous avez une sauvegarde et quelle est à jour, le risque est limité..... je me trompe ? C'est tout de même étonnant que le NAS demande une mise à jour. Le disque en panne en est peut-être la cause.

Il ne faut pas confondre 2 choses : les données et le support. Si l'accès aux données est impossible, le disque va signaler au système que ce qu'il demande n'est pas disponible. Dans le cas d'un RAID, même si un disque est en panne, le système s'en fout tant qu'on lui donne ce qu'il demande. Si le support est en mode basique, les données perdues ne seront pas accessibles et le système sera alerté. Si c'est un RAID (hors RAID0 bien entendu qui est une ineptie), il faut la perte des blocs correspondants aux données recherchées pour que le système soit alerté. Le RAID gère les parités. Il va répertorier et tenter de réparer les erreurs quand il les rencontre, et s'il ne peut pas les réparer et qu'il y en a beaucoup, il va placer la grappe en mode dégradé mais ne va pas arrêter son fonctionnement pour autant. Ce n'est pas parce qu'il y a perte d'un bloc du RAID qu'il y a perte de données pour l'utilisateur. Ainsi, même avec un disque en panne soit en cours de fonctionnement, soit en cours de construction, le RAID continue ses opérations en mode dégradé et hormis l'alerte du passage dans ce mode (il faut bien alerter l'administrateur), l'utilisateur n'y voit que du feu. Donc oui, ce principe de fonctionnement peut paraître étrange, mais c'est aussi la base de la continuité de service.

Mais il n'y a rien de plus simple ! Ca fonctionne exactement comme vous le voulez. Vous pouvez travailler en et hors connexion puisque les dossiers sont synchronisés à la fois sur le client (les PC) et sur le serveur (le NAS). Si 2 utilisateurs travaillent sur le même document, il y aura forcément un conflit au moment de l'enregistrement. Ce conflit sera identifié avec le nom du PC, la date et l'heure, et l'indication conflit. Je vous suggère d'étudier un peu mieux le fonctionnement de CS.

Essayez avec http://votreipexterneouvotreddns/photo/#Albums

Ma foi, s'il s'est logé dans un des fichiers du Cloud, alors il est forcément dans le Cloud serveur. Mais dans ces conditions, il aurait aussi contaminé les autres MAC si toutefois ils sont connectés au même dossier du Cloud. Si c'est le cas, j'aurais tendance à dire qu'il n'est que sur le MAC local. Je n'y connais strictement rien aux MAC, mais il doit bien y avoir des sites spécialisés qui parlent de ce virus et qui surtout donnent des solutions pour s'en débarrasser.

C'est normal qu'il apparaisse dans "autres périphériques". Pour vous connecter, il suffit de faire un mappage ou bien de créer un ou plusieurs lecteurs réseaux qui pointent vers les dossiers du NAS, sans oublier de les activer pour chaque ouverture de session et le tour est joué.

Sympa d'avoir un autre pourvoyeur de certificat. Il me semble qu'il s'agit d'un certificat class1. Je crois effectivement qu'un petit tuto s'impose pour pouvoir l'adapter à nos nas. Pour ma part j'utilise StartSSL Free (class 1) qui est aussi gratuit.

Comme je l'ai dit, c'est un processus jusqueboutiste. Même si un disque est retiré, il continu malgré tout a redistribuer les blocs. Ceux qui ne sont pas copiés sur le disque absent seront notés avec erreur de parité. Il faut voir que le RAID continu de fonctionner pendant toute la construction. Les données sont toujours présentes tant qu'un autre disque ne tombe pas en panne. C'est le contrôle de parité qui fait que le RAID est sain ou dégradé. Dans tous les cas, il vaut mieux que le processus aille à son terme pour être sûr que le RAID soit en condition de pouvoir être réparé. Si le processus est stoppé en cours de route, les blocs seront répartis de manière anarchique (certains en mode RAID 4 disques et d'autres en RAID 3 disques). La reconstruction dans ce cas peut s'avérer complexe, voire impossible. J'espère pour galfior que son arrêt forcé n'a pas altéré une partie de ses données.

C'est pas tout à fait comme ça que ça marche. En fait, lorsqu'on lance une augmentation de volume, c'est un processus qui déplace pratiquement toutes les données présentes sur un RAID sain pour les répartir sur l'ensemble des disques. Une fois lancé, il va jusqu'au bout. Si le nouveau disque est sain, il n'y aura pas d'erreur de parité et le RAID sera déclaré sain à la fin du processus. Si par contre, le disque est défectueux soit au début, soit en cours d'opération, tout ou partie des données ne seront pas écrites et des erreurs de parité seront détectées sur ce disque. Il sera déclaré HS en fin de processus et le RAID passera en mode dégradé. Il se peut donc que rien ne soit écrit sur le disque, ce n'est qu'à la fin qu'on le sait. Dans le cas de galfior, il y a probablement eu des écritures, mais sur un disque avec des secteurs défectueux, elles ont probablement été difficiles voire impossibles. Dans votre cas, le disque est tombé en panne en cours de processus. Dans les deux cas, le résultat est le même, des blocs n'ont pas pu être écrit et pourtant le processus est allé à son terme et s'est soldé par un RAID dégradé. Dans les fait, vous vous retrouvez avec le même nombre de disques qu'au départ (disons 3), mais votre RAID est dégradé parce que les données ont été déplacées et sont maintenant réparties pour un RAID à 4 disques.

Avec 800 ou 400 secteurs défectueux, je ne m'amuserais pas à remettre ce disque dans un NAS. Vous pouvez si ça vous chante tenter un test approfondi avec le logiciel du constructeur, ou bien faire une écriture de zéro ou plus dur encore, un badblock, pour isoler les secteurs défectueux. Mais bon, généralement quand le processus de dégradation est lancé, c'est rapidement la dégringolade.

Je suis bien d'accord, et ça rejoint ce que je disais dans mon premier message. On peut faire de la config manuelle pour les caméras qui ne sont pas dans la liste, à condition que le système de com soit compatible et/ou ne soit pas propriétaire et fermé. Et il n'est pas du tout garanti de retrouver toutes les fonctionnalités. C'est beaucoup moins évident pour le serveur jeedom car là il n'y a pas à ma connaissance (je me trompe peut-être) de possibilité de configurer SS pour qu'il se connecte à des serveurs non listés.

OK pour le format, mais je ne vois pas comment l'intégrer dans SS qui ne sait gérer que des caméras ou des serveurs compatibles.

Un flux avec un jpg ? Surveillance Station peut enregistrer les flux de caméras issus d'un serveur video compatible. jeedom ne se trouve pas dans la liste. Aussi, je crains fort que ça soit un peu compliqué. Vous pouvez toujours tenter une connexion à votre serveur en paramétrant une caméra avec l'adresse IP du serveur pour voir si une communication peut-être établie, ce dont je doute. Dans le cas ou ça fonctionnerait, il faudra bien entendu attribuer une IP fixe à votre jedom dans votre routeur (et si possible dans le jeedom) pour ne pas perdre cette communication en cas de changement d'IP.

Regardez du côté de CloudStation.

Si vous cherchez des réponses, il est préférable de créer un sujet dans le forum dédié.

C'est en principe celui qui est en dessous (le plus proche de la CM). Vous pouvez vous en assurer en comparant son numéro de série avec celui affiché dans le gestionnaire de stockage.

Reprenons à zéro. Comment sont organisés vos disques : basic, raid, shr ? Qu'est que vous appelez le disque principal ? (cette notion n'existe pas dans un NAS, le système étant installé sur tous les disques). Comment espérez-vous avoir des données sur le NAS si vous avez "tout" réinstallé ? Comment votre nas était connecté au réseau ? (parce qu'à vous lire il était connecté au PC....) Comme vous dites, c'est basique mais sans ça, on ne comprend rien à votre problème

Il y a une rubrique pour chaque paquet. Pour le serveur VPN, c'est ici.

Tu as raison. Je me disais bien qu'il y avait un truc qui me choquait. J'ai eu la flemme de chercher, je savais bien que tu me corrigerais La prochaine fois, je ne ramènerai pas ma science.

Non, rien de particulier. Vos paramètres seront remis aux valeurs usine. Vous utilisez ensuite Synology Assistant pour détecter votre NAS et y accéder. Il vous suffit de rétablir vos paramètres réseau et admin et ça devrait être bon.

Présentation c'est là Reset c'est là . Faire le premier reset pour réinitialiser les réglages réseau et le mdp admin (voir les explications). En principe, les données ne sont pas affectées, mais on ne sait jamais. Comme vous avez une sauvegarde à jour, y'a pas de soucis. Je me trompe ?