CoolRaoul

Non est ce n'est pas faute de l'avoir répété sur le forum Le VPN est prévu pour relier de façon sécurisée deux sites de *confiance* à distance via un lien public. (et pas pour télécharger du warez sans se faire choper par hadopi ) Synology part du principe que le site à l'autre bout du tunnel VPN est une extension du LAN local (ce qui est l'approche "pro" du concept de VPN) et pas besoin de firewall dans ce cas. Voir ce que j'avais écrit sur le sujet il y a peu:

J'ai préféré m'en tenir qu besoin exprimé qui était de "transferer les dessins d'une machine à une autre".

Vu que tous les appareils ont accès au NAS en direct, la bonne approche est de créer sur le NAS un dossier partagé destiné à cet usage (appelons le "partage") et d'utiliser ce dossier pour les échanges entres machines (sous MacOS en utilisant les dossiers partagés et sous IOS DSFile) Pas besoin de CloudStation pour cela.

Dans la partie "privileges", s'assurer que le deux comptes personnels créés sont autorisés (cochés) Dans "partage", cocher les partages que l'on souhaite rendre synchronisables (attention à se limiter aux partages que l'on souhaite vraiment synchroniser). Par défaut chaque utilisateur dispose déjà d'un dossier synchronisé privé, le sous -répertorie "CloudStation" de son partage "home". Dans la partie "paramètres" choisir le volume ou sera stocké l'historique et en combien de version (ce qui peut prendre beaucoup d'espace suivant la volumétrie des dossiers synchronisés) Mais faudrait commencer par définir ce que vous souhaitez faire avec. Par exemple, imac et macbook ont acces directement au fichiers du NAS en partage réseau, peut-être pas besoin de synchro ici. Pour les appareils IOS (je peux me tromper, ne je suis pas spécialiste Apple) ils doivent déjà avoir acces directement aux fichiers multimedia du NAS par d'autres mécanismes. Dans tous les cas il faut bien comprendre que cloudstation est destiné a maintenir une *copie* synchronisée de certains dossier partagés du NAS sur chacun de vos équipements. Est-ce bien cela l'objectif?

Il n'est pas nécessaire (ni conseillé) d'utiliser un compte spécifique pour Cloudstation. Chaque utilisateur exécute sa propre instance de client Cloudstation sur son/ses mac et/ou sur son mobile et s'y connecte avec son compte personnel. Chacune de ces instances peut avoir sa configuration spécifique: on n'a pas forcément besoin de synchroniser les mêmes dossiers sur téléphone et sur ordinateur, ne serait-ce que pour des questions de volumétrie. Home est un dossier privé pour chaque utilisateur Homes est un "meta dossier" qui contient chacun des homes individuels. Normalement on peut l'ignorer.

J'ai 1 compte pour mon iMac (appel

Non, il demande juste de spécifier l’adresse du serveur IMAP à utiliser mais n'impose pas de l'installer en local sur le NAS (on parle bien du roundcube de synocommunity hein?)

Inutile c'est confirmé, j'ai bien vérifié Faut se dire que ceux qui voudront utiliser déclarer des virtualhosts tout en utilisant le reverse proxy seront forcément capable de le faire à la main en se paluchant le fichier de conf et devront éviter l'interface DSM pour ça. Restait un truc qui me tracassait: dans de plus anciennes versions de DSM, toute modification manuelle de ces fichiers (qui n'étaient pas au même endroit mais assuraient la même fonction) avait pour effet de faire planter la sauvegarde de configurations (et j'avais sué pour trouver le lien de cause à effet) La j'ai vérifié: apparemment ce n'est plus le cas. Donc, sous réserve des précautions indiquée plus haut, on va pouvoir basculer vers cette approche. Va falloir que j'ajoute un correctif au premier post du fil .

J'ai bien entendu un peu décortiqué les fichiers de conf et leur diverses intrications (et Il n'y a pas de https.conf) La fichier maître est "/etc/httpd/conf/httpd.conf" qui est construit dynamiquement au démarrage du service httpd-user à partir d'autres fichiers qui sont concaténés et inclus encore d'autres (lignes "include") La partie serveur SSL est déclaré par conf/extra/httpd-ssl.conf (lui aussi construit dynamiquement et qui fait partie des fichiers inclus). Ce que je ne m'explique pas c'est pourquoi il faut que les déclarations de vhost SSL soit faites *avant* l'include de ce dernier pour que ça marche, d'autant plus que DUMP_VHOST m'indique dans les deux cas que c'est bon. (et en plus ça marchait avant)

Trouvé une approche qui permet de n'avoir à modifier uniquement "httpd.conf-user" Il suffit de mettre la ligne "include" qui pointe sur les fichiers de conf perso non pas à la fin de ce dernier mais juste avant le bloc : <IfDefine SSL> .. </IfDefine> (par contre je ne saurais pas expliquer pourquoi ça marche seulement ainsi)

Un truc a savoir: "httpd-ssl-vhost.conf-user" est *écrasé* des qu'on modifie/ajoute/supprime une déclarations d’Hôte Virtuel dans le panneau de conf DSM (et même si ce n'est pas un virtualhost SSL) C'est un comportement de ce genre qui m'avait fait chercher une alternative et finalement trouver "/etc/httpd/conf/httpd.conf-user" En remettant ma config initiale, mes déclarations de vhosts apparaissent pourtant bien avec la commande: httpd -DSSL -DSPDY -DHAVE_PHP -t -D DUMP_VHOSTS Je ne comprend pas ce qui coince avec mon approche.

Effectivement ca marche: j'ai réparti mes conf ssl et non ssl dans deux répertoires: "/usr/local/etc/httpd/conf-ssl.d" et "/usr/local/etc/httpd/conf.d" ajouté la ligne : include /usr/local/etc/httpd/conf-ssl.d/*.conf dans "/etc/httpd/sites-enabled-user/httpd-ssl-vhost.conf-user". Et ça fonctionne. Je vais nettoyer les lignes inutiles de la conf tant que j'y suis alors. Mais faut que je creuse tout ça pour comprendre ce qui a changé Merci du tuyau

J'ai trouvé ce fichier dans un sous dossier: "/etc/httpd/sites-enabled-user/", j'imagine que c'est bien celui-la? Je m'en vais tester tout ça..

Non, ici ça supprime *tous* les fichiers du dossier *cible* qui ne sont pas présent dans le répertoire source. Le résultat est qu'à l'arrivée le contenu de "/local/dir" est strictement identique à "/remote/dir". (rien en moins mais rien en plus) verbose c'est pour avoir plus de messages d'information durant la copie.

Peut-être en passant par PhotoStation (soit rendre public les dossiers à partager, soit crééer un compte "famille" avec droit de lecture sur les dossiers spécifiques). Mais je ne me souviens plus du tout comment fonctionne la version de Photostation compatible avec ta version de DSM.

Le partage de dossiers n'est possible que depuis DSM5

Je me souviens soudain qu'il Il y a un package python pre-requis à installer (celui de synocommunity)

Nullement, aucune différence Mon routeur est une Freebox, il n'existe aucun moyen de configurer son firewall. Pas le choix si je veux faire de réglages fins donc.

Oui, demander dans ce fil: L'auteur du package le suit (il a posté pas plus tard qu'hier)

Faut peut-être s'assurer que l'option "delete" correspond bien au comportement souhaité dans le cas présent.

C'est une blague? C'est la *premiere* réponse que trouve google: Oui, dans ta section Tutorials du forum, sujet Non, mais lis d'abord le tuto et tu comprendras que c'est inutile (haproxy écoute sur d'autre ports et sert de "passe-plat" à Apache (ou autre services)

Essaie alors de voir du coté du package roundcube de SynoCommunity **EDIT** Je viens de tester, m'a l'air peut-être un peu réduit en fonctinalités (pas multi serveurs par exemple, a moins que je n'ai pas trouvé)

Pourquoi être allé chercher un autre tuto alors qu'il y en un sur ce forum. (dans la section tutos) Et justement, si tu étais aller lire le fil de ce dernier, tu aurais constaté que j'ai indiqué hier que depuis la dernière mise à jour DSM la partie SSL ne fonctionnait plus et n'avais pas trouvé de solution pour le moment. Moi même j'ai du me résoudre à migrer vers haproxy.

De mon coté j'essayais juste de faire passer le message (peut-être de façon pas tres diplomatique, j'en conviens) que je connais déjà tout ça. D'une part je confirme que seuls les ports et 443 sont ouverts dans le proxy et qu'en outre, la possibilité de faire un tunnel est désactivée encore moins la possibilité de faire une connexion TCP directe avec l'extérieur, quel que soit le port. Et surtout, mon besoin est juste de pouvoir ponctuellement me connecter à mon NAS en cas de besoin, pas d'outrepasser les restrictions imposées pour surfer (ce que je me garderai bien de tenter de faire)

C'est gentil mais je ne suis pas un noob Et je sais ce qui passe et ce qui passe pas dans mon proxy