CoolRaoul

Les fils parlant de compatibilité hardware, vaut toujours mieux commencer de les lire par la fin.

Non: DSM n'est ni Debian ni Ubuntu.Et même si cétait possible, me semble bien que filezilla ne sait pas fonctionner en mode commande pour rapatrier automatiquement des fichiers Oui, en utilisant wget en ligne de commande (/usr/syno/bin/wget).Si necessaire, tu devrais trouver des exemples en cherchant dans le forum, c'est presque un sujet récurrent.

Tu peux déja parcourir ce fil: "" pour récupérer des infos sur les clés TNT USB utilisables avec VideoStation

Vérifier quand même que les ports secondaires sont bien ouverts. Ici par exemple: http://www.portcheckers.com/

Pour faire du ftp, le port 21 n'est pas le seul à ouvrir dans le firewall Il faut également ouvrir la plage de ports utilisés pour le canal data en mode passif (dont les valeurs sont dans le panneau de configuration DSM, "services de fichiers" -> "FTP")

Pour avoir le choix, j'ai

Possible en php (me semble avoir vu passer des exemples sur le forum). Tr

Un VPN relie deux segments distants de réseau pour les transformer en un segment unique (bien que virtuel et réparti sur deux sites). C'est plutôt le genre de topologie ci dessous qu'on rencontre: +-Site 1-+ +------------------- Site 2 --------------------+ |[Lan 1] | <--- (VPN) ---> | [Lan 2] <--- [firewall] ---> [reste du réseau]| +========+ +-----------------------------------------------+

Non, DS Photo (en tout cas la version android, celle que je connais) n'a pas de mode "hors ligne" si c'est bien cela la question.

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