Fenrir

petite précision pour ceux qui voudraient utiliser haproxy avec une adresse commençant par www, il y a une association qui prend tout ce qui commence par www dans la conf par défaut de haproxy.

​

comme la fonction MP du forum ne semble plus marcher, je prends le risque de poser la question ici : --effacé--

tu peux le faire via filestation dans l'interface du syno mais ça devrait aussi marcher via un partage réseau (vérifie les droits)

normalement pas de soucis, tu as l'option progress donc tu aurai vu quelque chose dans la console. rsync prend toujours un peu de temps à démarrer tu as l'option --dry-run pour tester tes commandes

1- http://www.supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://www.supertruc.com:5080 --> rien => là il y a un soucis, probablement une interaction avec la conf par défaut http://supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://supertruc.com:5080 --> j'arrive sur le DSM => c'est le backend par défaut prend la main 2- http://www.supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://www.supertruc.com:5080 --> rien => là il y a un soucis, probablement une interaction avec la conf par défaut http://supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://supertruc.com:5080 --> j'arrive sur le DSM => c'est le backend par défaut prend la main 3- http://www.supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://www.supertruc.com:5081 --> site de l'utilisateur => ok http://supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://supertruc.com:5081 --> rien => il y a quelque chose dans le backend web ? 4- http://www.supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://www.supertruc.com:5081 --> site de l'utilisateur => ok http://supertruc.com --> rien => normal, haproxy n'écoute pas sur le port "80 http://supertruc.com:5081 --> rien => il y a quelque chose dans le backend web ? -------------------------------------------------------- Ce que tu demande n'a rien de compliqué en partant de zéro, c'est même très simple. Par contre je n'ai pas pris le temps de regarder ce qui était fait dans la conf par défaut, c'est pour ça que je suis partie d'une conf vierge. De plus je ne sais pas ce qui est fait (ou n'est pas fait) niveau redirection de ports, mais c'est probablement la raison des "rien" sur le port Frontend Name: super Binds: :5081 Backend par défaut: dsm Options: option http-server-close,option forwardfor Backend Name: super Servers: super localhost:80 check Options: reqrep ^([^\ :]*)\ /(.*) \1\ /~super/\2 Associations Frontend: super Backend: super Condition: if { hdr(Host) -i www.supertruc.com }

​c'est plus fiable (keepalive, checksum, ...) et plus puissant (copie de fichiers, logs, ...), mais c'est aussi une meilleur habitude

test avec : http://192.168.1.37:32400/manage

je n'ai pas le soucis, à tout hasard, essaye de purger le cache de ton navigateur, c'est recommandé après les mises à jours

C'est normal si tu as utilisé de la dernière configuration que tu as posté Test avec ce que j'ai fourni, sans rien changer sauf ce qui est en rouge Frontend Name: nom_du_frontend Binds: :5081 Options: option http-server-close,option forwardfor Backend Name: nom_du_backend Servers: nom_du_site localhost:80 check Options: reqrep ^([^\ :]*)\ /(.*) \1\ /~fenrir/\2 Associations Frontend: nom_du_frontend Backend: nom_du_backend Condition: if { hdr_beg(Host) -i www. } ou Condition: if { hdr(Host) -i www.supertruc.com } l'adresse http://www.supertruc.com:5081/ (avec le numéro de port) doit afficher la même chose que http://ip.privée.du.nas/~super/ si ce n'est pas le cas, tu as omis une info ou raté un truc

oui, mais laisse aussi le syno tester le disque (c'est assez long) je pense que oui, mais je n'ai pas de références à donner oui probablement oui (sauf si tu es déjà en ext4) oui jamais testé le 4To En complément, pour tes données les plus importantes, tu peux aussi les sauvegarder sur un autre nas (d'un ami par exemple) et/ou sur une plateforme en ligne, il y a tout ce qu'il faut dans le syno pour ça

si ça marche depuis ton lan sans toucher à ton fichier hosts, c'est probablement que ton routeur gère le loopback pour la redirection, oui ou non, ça dépend des services que tu veux rendre accessible sur le port "80". j'ai utilisé le port 5081 pour être certain de ne pas avoir d'interaction avec la conf par défaut et donc pouvoir tester tranquillement. si tu souhaite utiliser les redirections de la conf par défaut, 2 solutions : tu ajoute les règles dont tu as besoin dans la conf en 5081 et tu forward le port "80 vers le port 5081 (donc rien vers 5080) ou tu ajoute tes règles à la conf par défaut et tu forward le port "80 vers le port 5080 (donc rien vers 5081)

pour les utilisateurs situés en dehors de ton réseau, ça devrait être bon, mais pas pour ceux situés dans ton réseau (sauf si ta box fait du loopback) Pour faire simple : modifie le fichier hosts de ton ordi (/etc/hosts ou c:\windows\system32\drivers\etc\hosts) en ajoutant ces 2 lignes : ip.privée.du.nas supertruc.com ip.privée.du.nas www.supertruc.com

je n'ai pas de box NC, donc je ne sais pas ce qu'elle sait ou ne sait pas faire, mais si elle gère l'upnp, videostation devrait faire l'affaire, sinon une simple chromecast (ou équivalent), c'est moins cher (35€) et plus simple à mettre en place si les vidéos sont dans un format compatible

essaye avec l'application synology assistant : https://www.synology.com/en-global/support/download/DS415+

if { hdr_beg(Host) -i supertruc.com. } <=> si le nom de machine commence par supertruc.com donc www.supertruc.com ne correspond pas à tout hasard, tu as bien modifié ton dns (ou le fichier hosts de ton poste) pour que supertruc.com et/ou www.supertruc.com pointe(nt) sur ton nas ?

http://tonnas/~tonlogin correspond au dossier \\tonnas\tonlogin\www de ton nas pour Apache, le serveur web qui écoute sur le port http (80) de ton nas, c'est automatique dans le frontend, "use_backend nom_du_backend if { hdr_beg(Host) -i user. }" indique d'utiliser le backend [nom_du_backend] si le nom de domaine commence par user. (avec le . ) Donc http://user.truc:5081/, http://user.www.truc.com:5081/ et http://user.truc.com:5081/ seront pris en compte. Dans ta conf, tu n'as aucun backend nommé user (nom_du_backend dans mon exemple). De plus, le port est important, haproxy n'écoute pas sur le port http (80) mais sur le port 5080, en local tu dois donc faire tes tests en précisant le port. Tu pourras le masquer après en faisant de la redirection de port. Enfin, je te recommande de créer ton propre frontend pour ne pas avoir d'interactions avec la conf par défaut (dit autrement, utilise exactement mon exemple, il fonctionne). nom_du_frontend, nom_du_backend et nom_du_site sont simplement des noms d'objets dans la configuration Tous les proxy (inverse ou non) fonctionnent de la même manière : ils écoutent sur un port (5081 dans mon exemple) ils lisent les demandes des clients : par exemple une demande de page web http://fenrir.mon.domain:5081/dossier/test.php ils appliquent éventuellement des règles de transformation : ajout de l'entête "HTTP_X_FORWARDED_FOR" par exemple, réécriture de "/" en "/~fenrir/", ... ils test des conditions pour choisir le backend à utiliser : si le nom de domaine commence par user alors va là, sinon va ici ils envoient la requête transformée au(x) backend : donne moi http://localhost/~fenrir/dossier/test.php ils modifient éventuellement la réponse ils enregistre éventuellement le résultat en cache ils envoient la réponse modifiée au client

commence par faire un backup des données importantes de ton nas vérifie/change les droits avec filestation en admin, si ça ne veut pas, essaye en SSH (login root, mot de passe du compte admin) ls -la /volume1/partage/dossier/* chmod a+rw fichier vérifie aussi qu'il n'y ait pas d'erreur sur les disques

Il est presque certain que le soucis vienne de la box (quoiqu'en dise les opérateurs, leurs box sont souvent des boitiers bas de gamme, qui ne respectent pas les normes et sont blindées de bugs). reset => perte de conf ou de conf+données (selon le reset) oui (cf plus bas) tu peux le tenter, c'est surement le plus facile, par contre le retour en arrière n'est pas possible (sauf bidouilles) remplacer la box ou ajouter un routeur entre la box et ton réseau me semble moins radical et plus simple Pour le point 2 (classé par ordre de facilité) : ta box distribue bien des IP local ? (10.* ou 172.16-31.* ou 192.168.*) => si oui passe à la suite, si non ton problème est là essaye sans ton PC, c'est peut être lui qui a un problème désactive l'IPv6 sur la box et tous tes équipements coupe/désactive/supprime tous les logiciels de p2p, les box n'ont souvent pas assez de mémoire essaye avec un autre switch, voir sans (si tu as des ports sur ta box, utilise les) change tes câbles analyse les trames échangées (tcpdump/wireshark) au moment du plantage Le plus simple est de commencer par le point 3 (update du dsm), attention, DSM a radicalement changé (en bien je trouve) entre les version 4 et 5

Il faut que tu modifie l'url envoyé par haproxy à apache : Frontend Name: test Binds: :5081 Default Backend: web Options: option http-server-close,option forwardfor Backend Name: fenrir Servers: fenrir localhost:80 check Options: reqrep ^([^\ :]*)\ /(.*) \1\ /~fenrir/\2 Associations Frontend: test Backend: fenrir Condition: if { hdr_beg(Host) -i toto. } http://toto.mondomaine.org:5081/ affiche la même chose que http://monnas/~fenrir/ http://toto.mondomaine.org:5081/test/ affiche la même chose que http://monnas/~fenrir/test/ Je ne connais pas haproxy (habituellement je fais ce genre de chose avec nginx, varnish ou du F5), il y a surement d'autres choses à faire, par exemple http://toto.mondomaine.org:5081/test (sans / de fin) qui ne fonctionne pas (c'est la faute d'apache), ça devrait être faisable d'après la doc : Example: send redirects for request for articles without a '/'. acl missing_slash path_reg ^/article/[^/]*$ redirect code 301 prefix / drop-query append-slash if missing_slash Je te recommande de vérifier le fichier de configuration généré par l'interface ps | grep haproxy => /usr/local/haproxy/var/haproxy.cfg

​Oui, j'ai choisi un port non utilisé pour partir d'un "profil" vierge ​Ajoute une expression régulière dans site3 pour rediriger la racine (/) vers /~login

j'ai fait un petit test vite fait avec le paquet haproxy du syno : Pour le test j'ai créé 3 dossiers (user1, user2 et user3) dans le partage web, mais ça devrait fonctionner de la même manière avec les ~login http://<any>/site1/ => http://localhost:80/user1/ http://<any>/site2/ => http://localhost:80/user2/ http://<domain>/user3/ => http://localhost:80/user3/ La conf suivante devrait de donner les bases : frontend test bind :5081 option http-server-close option forwardfor acl url_tag1 path_beg /site1 acl url_tag2 path_beg /site2 use_backend site1 { if url_tag1 } use_backend site2 { if url_tag2 } use_backend site3 { if hdr(Host) -i tondomain.org } default_backend web backend site1 reqirep ^([^\ :]*)\ /site1/(.*) \1\ /user1/\2 server site1 localhost:80 check backend site2 reqirep ^([^\ :]*)\ /site2/(.*) \1\ /user2/\2 server site2 localhost:80 check backend site3 server site3 localhost:80 check (la regexp est à affiner, elle ne match pas les url sans le / de fin) Après tu peux combiner mes exemples.

Je viens de faire le test à l'instant, la date de création du fichier change, ce qui est normal de mon point de vue, même si je comprends que ça puisse te poser des problèmes. installation du paquet CloudStation installation du client CloudStation (version Windows) choix du dossier à synchroniser suppression de toutes les exceptions (fichiers/dossiers préfixés par un "." et filtres de fichiers) dans les règles de synchronisation déplacement d'un fichier dont la date de création/modification est 03/12/2014 à 00:23 dans le dossier CloudStation de mon PC vérification sur le nas : la date de modification est toujours 03/12/2014 à 00:23, la date de création est celle de la synchro (maintenant) renommage du fichier en "_IMG_1111 .CR2" (j'ai copié collé ton nom) vérification sur le nas, le fichier a bien été renommé Je n'ai jamais vérifié ça avec DropBox, mais si la date de création ne change pour l'utilisateur, c'est qu'ils (dropbox) l’altèrent après la synchronisation (en passant c'est une mauvaise pratique car ça peut empêcher les logiciels de sauvegarde de fonctionner correctement). Mais d'après ce que je trouve sur le forum dropbox, les dates de création changent aussi. A noter qu'il existe plusieurs méthodes pour corriger les dates de création d'un fichier (rsync, touch -t, ...), mais ça ne répond probablement pas à ton besoin. Tu as aussi la possibilité d'utiliser d'autres logiciels "dropbox like" dans ton synology (owncloud par exemple) qui répondront peut être mieux à tes besoins, par contre je pense que la date de création du fichier subira le même sors. En espérant que cette déception ne soit que partie remise, je t'invite à regarder les autres possibilités de ton syno.

je ne vais pas pouvoir répondre en détail (fatigué), mais une solution à votre problème est d'utiliser un reverse proxy (nginx/haproxy/varnish/squid/apache/... ). Il y a de nombreux posts sur ce sujet dans le forum. On peut faire autrement, mais c'est souvent le plus simple.

Pour QuickConnect, vous pouvez directement créer un compte ici : https://myds.synology.com/support/register.php Évitez de mettre le mot de passe de votre messagerie (un site = 1 mot de passe) Pour le SHR vs raid SHR est simplement le terme employé par Synology pour indiquer qu'ils font du LVM (https://fr.wikipedia.org/wiki/Gestion_par_volumes_logiques#Concepts) sur du raid. Mais en dessous ça reste du raid, c'est juste une "couche intermédiaire" entre le raid et le système de fichier. Pour voir si le raid est actif, 2 manières : via l'interface web, dans le gestionnaire de stockage en ssh avec la commande suivante : cat /proc/mdstat