Mic13710

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 ?

Vous pouvez avoir autant de ndd qui pointent vers la même ip que vous voulez. Le NAS accepte plusieurs certificats et peut gérer plusieurs ndd sur le reverse proxy.

Pas banal comme problème. En même temps, ça fait partie des risques assumés lorsqu'on utilise une version beta, et ça aurait pu avoir des conséquences désastreuses sur un NAS de production.

La procédure est la même que ce soit en RAID ou en SHR. La seule différence à l'usage c'est la possibilité d'augmenter le stockage d'un SHR en ne remplaçant que 2 disques, alors qu'il faut changer tous les disques sur du RAID. Il n'y a pas de passerelle RAID vers SHR. Si vous voulez passer en SHR, il va falloir reconstruire. Vous pouvez très bien montez un de vos 2 disques de 6To dans des baies restantes et créer un nouveau groupe et un nouveau volume sur lequel vous pourrez transférer vos dossiers partagés. Vous pourrez y faire une sauvegarde hyperbackup des données utilisateurs et des paramètres de vos applications. Lorsque tout est transféré, vous supprimez simplement le groupe du disque existant, vous installez votre deuxième disque de 6To et vous remontez votre groupe 1 et votre volume 1 avec ce disque et l'ancien. Vous retransférez vos dossiers partagés sur ce nouveau groupe et vous restaurez les sauvegardes Hyperbackup. Quand c'est fait, vous supprimez le groupe que vous avez créé pour y mettre vos données et vous ajoutez le disque au groupe 1 puis vous augmentez votre volume. Si vous conservez le RAID classique, il suffit de rajouter vos deux disques et de faire une augmentation du groupe en intégrant les deux disques au groupe existant, puis vous faite une augmentation de volume. Quel que soit la méthode, il faudra tout d'abord mettre toutes vos sauvegardes à jour avant de manipuler vos disques et vos données.

Un DynHost est en réalité un enregistrement A dynamique. Si vous utilisez un dynhost en titi.TOTO.ovh, il faut alors rattacher vos CNAME à ce ndd. Votre CNAME *.TOTO.ovh est attaché à TOTO.ovh qui n'a aucun enregistrement A. Il est donc normal qu'une adresse comme nas.TOTO.ovh ne puisse pas aboutir puisque cette adresse ne peut pas être résolue. Modifiez votre DynHost pour qu'il soit créé sur TOTO.ovh, faites les corrections dans votre NAS et tout rentrera dans l'ordre.

Si vous utilisez directement TOTO.ovh, il faut que votre DynHost soit créé sur TOTO.ovh. Modifiez votre saisie en supprimant titi Il faut aussi bien évidemment corriger le ddns sur le NAS.

Un petit passage par la section des présentations est appréciée sur ce forum. Pour votre problème, cliquer sur les 3 petits points à droite et sélectionner l'affichage.