Mic13710

Pas toujours. Ca dépend du modèle de NAS. Sur un 713+ par exemple, c'est une 1220.

Inutile de tourner autour du pot. C'est sûr à 99.99999% que c'est la pile. Et de toute manière, au bout de 5 ans, il est préférable de la changer, surtout si vous la sollicitez comme vous le faite en coupant l'alimentation secteur ce qui la passe inévitablement en mode décharge.

Il existe effectivement sur certains UPS une protection surtension pour le réseau RJ45. Cette protection est généralement prévue pour un réseau 10/100 ce qui parait un peu dépassé à l'heure du Gb. Si c'est du 10/100, soit vous ne vous en servez pas, soit vous ne l'utilisez pas. Bref, vous l'oubliez.

Il vaut mieux surtout poster des vues du gestionnaire de stockage pour bien comprendre de quoi il s'agit. Et puis, un petit passage par la section des présentations est très apprécié sur ce forum.

Quand je parle de locales, ce sont les sauvegardes physiquement sur le NAS. Pas sur un disque externe. Après je ne peux pas confirmer si un disque externe peut être lu par HBV. Je n'utilise pas ce type de support sur mes NAS.

HPV sert uniquement à visualiser les sauvegardes locales, pas celles distantes. C'est utile lorsqu'on fait des sauvegardes entre NAS. Il est bien évident que la lecture/historique/restauration d'un hbk distant se fait directement dans Hyperbackup.

Pour drive, il n'est pas utile de passer par le reverse proxy. Pour l'ID vous renseignez simplement le ndd seul, vous passez par le https et le chiffrage et vous donnez les identifiants de l'utilisateur. Il faut bien évidemment que le 6690 soit dirigé vers le NAS et qu'il soit autorisé dans le parefeu. Lorsque le client va se connecter, il va chercher l'IP renvoyée par le ndd et il va s'adresser au port 6690. Le reverse proxy ne sert strictement à rien si ce n'est à compliquer l'url de destination.

Photo est une application spécifique qui ne fonctionne pas via le reverse proxy, sauf à faire la translation dans un .htaccess par exemple. Pour photo station, c'est ndd/photo exemples c'est quoi ? quelle page de connexion ? Vous voulez dire par exemple qu'avec https://audio.ndd vous arrivez bien sur audio station ? Si sur cette page les identifiants ne fonctionnent pas c'est que l'utilisateur n'a pas les droit sur l'application. En bref, si vous atteignez l'application mais que vous ne pouvez pas l'ouvrir, c'est que votre zone DNS et le reverse proxy fonctionnent correctement. La suite n'est qu'une affaire de droits.

Il NE PEUT PAS y avoir 2 enregistrements A pour un même domaine qui pointent vers deux IP différentes. Il y a un enregistrement de trop. Il faut supprimer le premier. Si votre box est en IPV6, vous pouvez conserver l'enregistrement AAAA, à condition bien entendu que l'adresse IP corresponde bien à votre IPV6 publique. Vous pouvez supprimer cet enregistrement si vous n'avez pas d'IPV6. Et l'autre AAAA pointe t'il vers la même IPV6 que le premier enregistrement ? Si votre site est hébergé chez vous, vous pouvez remplacer votre enregistrement A www par un CNAME. Sinon, l'IP doit pointer vers votre site. Là aussi, il ne peut pas y avoir 2 enregistrements A pour le même domaine (www) avec 2 IP différentes.

Le plus gros souci de l'extension d'un groupe vers l'unité externe n'est pas au niveau du câble de liaison qui est vissé aux châssis de part et d'autre. Il est extrêmement rare qu'un câble de cette nature se sectionne, à moins qu'il soit sollicité mécaniquement au point de créer des ruptures internes. Le plus gros problème vient du fait que chaque unité a sa propre alimentation. Dans cette configuration, la perte accidentelle de l'alimentation de l'extension (câble débranché par erreur ou panne du bloc d'alimentation) peut entrainer de gros dégâts dans le groupe pouvant même aller jusqu'à sa perte. Autre argument contre l'extension d'un groupe, c'est l'augmentation exponentielle des risques de perte du groupe lors de réparation suite à une perte de parité ou à un remplacement de disque, et pire encore, un risque accru que le groupe soit perdu lors du processus d'augmentation du stockage par ajout de disque. Plus il y a de disques, plus ils sont gros, plus les risques augmentent. Il faut alors envisager de passer au RAID6 (ou SHR2) afin d'avoir deux disques de perte. Si extension il y a, il est de loin préférable d'y construire un groupe séparé du NAS principal.

HPV sert à lire le contenu et voir l'historique des sauvegardes sur le NAS. Sans lui, les fichiers hbk sont illisibles.

Bonjour SpaceLord13, soyez le bienvenu dans la communauté. 500Go, hum, ça risque d'arriver très vite à saturation. Va probablement falloir songer passer à plus gros.

Oui @Jeff777, mais rien n'empêche d'avoir un certificat par NAS, ni d'avoir deux reverse proxy actifs. Par exemple, j'ai activé les serveurs DNS sur chaque NAS avec chacun sa zone privée. Chaque NAS a son propre reverse proxy (pas de master/slave). Les NAS sont respectivement serveurs DNS primaire et secondaire au niveau du DHCP de sorte que mes requêtes locales sont traitées prioritairement par le NAS primaire, par le NAS secondaire si le primaire est indisponible. Il me faut bien dans ce cas un certificat par NAS. Bien entendu, ce type d'arrangement n'est possible qu'en local. Pour trouver la même redondance sur le WAN, il faut appliquer ton principe.

Est-ce que par hasard, le HSTS serait activé, ou ne l'a pas été précédemment ?

Le certificat ne s'applique QUE sur l'adresse de la demande. Si vous paramétrez comme ci-dessus, en tapant l'adresse https://rasp.mondomaine.fr dans votre navigateur, le certificat va s'appliquer pour cette adresse. Ce que vous en faite ensuite dans le reverse proxy n’intéresse plus le certificat. Ainsi, vous pouvez avoir un lien sécurisé sur le WAN entre votre PC et le NAS qui vous met en relation via le reverse proxy avec votre Rasp au travers d'un lien non sécurisé avec le NAS. Dans cette configuration, pas besoin d'un certificat sur le Rasp.

Oui.... et non. Un wildcard ne fonctionne que sur un niveau de domaine. Ce sera OK pour nas1.mondomaine.fr, ça ne le sera pas pour toto.nas1.mondomaine.fr Il faut aussi créer des wildcard dans la zone DNS pour *.nas1.mondomaine.fr et *.nas2.mondomaine.fr pour que les domaines de chaque NAS soient couverts par le certificat. On peut très bien créer un certificat par NAS qui couvre tous les domaines avec comme domaine mondomaine.fr et autres noms : *.mondomaine.fr, *.nas1.mondomaine.fr, *.nas2.mondomaine.fr On peut aussi personnaliser chaque certificat pour chaque NAS en ne précisant que le wildcard du NAS. Pour le Raspberry, soit on importe le certificat commun, soit on passe par le reverse proxy avec un transfert d'une adresse du type https://rasp.mondomaine.fr:443 vers http://IP du Rasp:80

Chez moi aussi ça fonctionne très bien. Je ne me connecte au NAS en local via Firefox qu'en http.

Pourquoi utiliser le 5001 alors que le reverse proxy permet toutes les fantaisies ? Essaye avec http, nasserveur718, port 80 et ça devrait marcher

Si vous avez effectivement remplacé un fichier par un autre, alors le fichier de départ n'existe plus. Par contre sa miniature (celle que vous visionnez) existe toujours. Pour lancer l'indexation c'est dans le service d'indexation de DSM, bouton Ré-indexation.

Si le nom n'a pas changé, l'index n'a pas changé. Relancer l'indexation.

C'est le forum qui le fait automatiquement en fonction de la taille de la citation. Ceci étant dit, il est TRES TRES RAREMENT nécessaire de citer toute une réponse. C'est une mauvaise habitude qu'il faut combattre car cela rempli inutilement le sujet sans aucun apport pour la compréhension. On peut très bien ne sélectionner que la partie importante de la dite réponse. En faisant cela, une balise "citer la sélection" apparait et on valide pour que cette partie soit incluse dans votre réponse. Plus direct, plus efficace. Et pour interpeler un intervenant, on commence par taper un @, suivi des premières lettres de son pseudo. Une liste apparait et s'affine jusqu'à trouver le pseudo rechercher. On valide pour qu'apparaisse son nom dans votre réponse. Comme ceci : @Sebas7

Et en français, ça donne quoi ? Spoiler, késako ? Bouton révélation, késako ?

En l'absence de Quickconnect, les liens partagés créés dans file station prennent leurs url en fonction des paramètres indiqués dans les options avancées. Perso, dans ces paramètres j'ai indiqué file.ndd.tld avec les ports 80 et 443. file.ndd.tld est dirigé vers file station dans le reverse proxy. Le lien généré et le QR code correspondant dépendent du mode de connexion au NAS au moment de la création. Si la connexion est en http, le lien généré sera en http. Avec une connexion en https, le lien sera en https. Je n'ai toujours pas compris pourquoi DSM ne laisse pas le choix du mode de connexion pour les liens partagés autres que ceux générés avec Quickconnect (gofile). Comme je l'ai écrit, il y a vraiment matière à amélioration à ce niveau. Malheureusement, les choses n'évoluent pas depuis des années et c'est bien regrettable.

Dans DSM, Matériel et alimentation, onglet Général Contrôle du bip. Mais si tout est normal, il ne devrait pas y avoir de bip durant le test badblocks.

De mon côté, je suis toujours avec la version 1 sur 2 NAS sous DSM 6 et ça fonctionne très bien. Je suis toujours en version 1 car je ne comprends pas trop le pourquoi de la suppression/réinstallation systématique journalière d'acme dans la tâche planifiée. La mise à jour existe dans le script lui-même où elle n'est faite que si nécessaire, à condition bien évidemment de valider AUTO_UPGRADE='1' dans account.conf. Alors pourquoi le faire de manière journalière ?