CoolRaoul

Avant de te fier aux bonnes critiques je te conseille d'aller te ballader sur le forum de support, voir les problèmes rencontrés par les utilisateurs. Pour ma part, j'ai été un client fidèle de cet éditeur jusqu'à la version 2011 incluse mais j'ai fini par décrocher, submergé par les bugs et dysfonctionnement tordus. Peut-être que depuis lors la situation s'est rétablie mais dans tous les cas je ne peut que te conseiller que de commencer par tester la version d'évaluation du produit (ici puis choisir le lien "essayer") Tu pourra ainsi te faire ta propre opinion en toute autonomie sans influence extérieure.

Je crois que la solution est ici: Dans le champ "nom d'hote ou IP statique" mettre le nom DNS complet

Je viens de tester la manip et le message contient deux url, une interne et une externe Voici son contenu:

Windows 8 ? (http://www.clubic.co...e-fichiers.html) Ok je sors

Acheté neuf ou d'occasion? Voila voila ... Oui: http://www.synology....id=127&lang=fre

En fait tout est normal: les erreurs "does not map to Unicode" viennent d'un bug de la version du perl DSM. On en a parlé plus haut, et il n'y a pas à s'en inquiéter. quand aux warnings 'add "defname D8 <channel.conf name>" in config file.', c'est que ces nouvelles chaines (ou noms de chaines) n'ont pas étés mises dans le xml2epg.conf d'exemple qui est j'ai déposé sur pastebin (n'existaient pas encore) Il suffit donc d'éditer /usr/local/etc/xml2epg.conf (avec vi par exemple) et d'y ajouter les deux lignes suivantes: defname D8 D8 defname D17 D17 (Normalement un editeur "utf8 aware" serait nécessaire pour cette opération, mais comme ces deux chaines ne contiennent pas de caractères accentuées, ça devrait aller avec le vi natif).

Ma seule compétence sur haproxy date du week-end ou j'ai essayé d'éplucher la doc et ou j'ai finalement abandonné, dépassé par les près de 10000 lignes de cette dernière. Donc, je me vois pas pres de trouver l'option en question

Je pense qu'il serait nécessaire d'expliquer comment mettre en place des filtres d’accès par adresse (équivalent des "allow from" sous apache) Et sinon détailler la config pour ou deux exemples types (dsm en virtualhost sur le port , le meme en https), pas à pas en partant d'une config vierge serait sympa aussi.

C'est juste que je vois sans doute les chose par mon petit bout de lorgnette: quand je comprend le bidule, je qualifie de "simple", mais quand après un week-end de lectures et de tests sans résultats concluants je ne comprend toujours que pouic, découragé, je catégorise le truc comme "compliqué". Mais on verra bien le si SPK sait rendre rendre la manip abordable pour le plus grand nombre.

HAProxy, "simple"? J'ai essayé d'en digérer la doc histoire de faire quelques tests sur une version compilée par mes soins. Un tube d'aspirine plus tard j'ai laissé tomber

Je sais pas si tu as fait gaffe mais dans mon message précédent j'ai bien dit que " pour ma part je n'utilise pas l'option de redirection auto http->https de la console DSM,"

Mais pourquoi donc personne n'écoute ma préco d'utiliser "localhost" plutôt que l’adresse IP LAN dans la config reverse proxy ? Cela dit ça n'as sans pas de lien avec ton problème, et pour ma part je n'utilise pas l'option de redirection auto http->https de la console DSM, donc je ne pense pas pouvoir pas t'aider sur ce coup

Ben, le texte du message déjà pour commencer

Je ne sais pas: ma config pour shell in a box est plus simple que la tienne et n'utilise pas un virtualhost mais un bloc "location" (je vais d'ailleurs mettre a jour mon tuto, j'ai un peu merdé sur ce point) <Location /shell> ProxyPass http://localhost:4200 # restrictions d'ip à partir d'ici # mettre tout en commentaire jusqu'a la fin du bloc </Location> # pour le monde "open bar" Order deny,allow deny from all # subnet lan local allow from 192.168.1.0/24 #autres ip externes allow from IP1 allow from IP2 etc ... </Location> ***EDIT*** Apres être allé un coup d'oeil je m’aperçois que je n'avais pas merdé du tout et bien mis cette config dans le fil du tuto () Pourquoi ne pas avoir simplement suivi mes préconisations alors?

Cela ne correspond pas a mon tuto Pat exemple, pour le virtualhost "audio.mondomaine.com", au lieu de mettre ProxyPass / http://localhost:5000/audio/ faire plutot comme cela ProxyPass / http://localhost:8800/ (Apres avoir d

Cadeau: en compl

En effet, c'est un oubli de ma part que je vais m'empresser de corriger. Merci Je ne sais pas la, peut-etre que DSM sait renégocier a la volée lorsque il voit arriver une connexion SSL sur le port et pas filestation? Je ne peux pas vérifier (suis pas sur place) mais ça serait interessant de voir ce que donne en local "https:/<addresse syno>:5000" Je les ait squeezées car il s'agit en fait des valeurs par défaut, donc inutile de les laisser la. Par contre on peut, si on le souhaite, remettre le bloc et y inclure des restrictions d'acces plus strictes Je ne me suis pas vraiment attaqué a photo station etant donné que, comme il utilise le port , le besoin du reverse proxy reste limité. Mais as-tu essayé de mettre simplement un proxpass avec l'url http://localhost/photo pour voir? Strictement aucune, Et, chez moi aussi il est ailleurs (en fait plutott qu'un fichier j'utilise un répertoire et ma ligne include ressemble à "include <mon répertoire>/*.conf.d". Ca me permet de répartir la conf dans plusieurs fichiers plus "spécialisés" le seul élément à savoir est qu'a partir du moment ou il est situé quelque part sous /usr/local tu a la garantie qu'il ne sera pas effacé par un upgrade DSM

**IMPORTANT** la manip décrite est un peu modifiée avec DSM 5.0: L'emplacement du fichier httpd.conf-user à changé (dans "/etc/httpd/conf" maintenant) la commande de redémarrage apache est: /usr/syno/sbin/synoservicecfg --restart httpd-user Attention: en cas d'erreurs de syntaxe ou autre le service ne sera pas redémarré mais rien ne le signale au terminal. Il est conseillé d'aller visualiser les dernières lignes du fichier "/var/log/upstart/httpd-user.log" pour s'assurer que le restart s'est bien passé. Tout d'abord je tiens a citer le travail de PatrickH dont le tuto doit être considéré comme la base de ce qui va suivre J'en recommande chaudement la lecture préalable si vous voulez comprendre tout ce qui suit. Dans la suite il sera supposé que vous disposez de votre nom de domaine que nous appellerons "mondomaine.com" Tous les sous-domaines utilisés par la suite (<sous-domaine>.mondomaine.com donc ) devront avoir été déclarés dans votre console d'administration de nom de domaine et pointer vers votre ip externe. A noter qu'il est aussi possible d'appliquer ce qui suit dans le cas des sous-domaine DDNS fourni par Synology (du style par exemple "monnas.synology.me"). On utilisera dans ce cas des sous-domaine de niveau2 (soudomaine.monnas.synology.me) sans avoir besoin à les déclarer, c'est automatique dans ce cas. Les redirections de ports pour les connexions externe sur les ports et 443 devront aussi avoir été mises en oeuvre dans le routeur ou la box à destination de l'IP sur le réseau interne du Syno. Toutes les opérations suivantes doivent s'exécuter en étant connecté sur le Syno en ligne de commande (via ssh ou telnet) sur le compte "root" pre-requis le service web station doit être activé (panneau de config->services web->applications wev->activer web station) si on souhaite aussi se connecter en https, il que l'option panneau de config->services web->Service Http->activer la connexion HTTPS pour les services web soit activée. ajouter la ligne suivante *à la fin* de /usr/syno/apache/conf/httpd.conf-user include /usr/local/etc/http.d/revproxy.conf Attention: cette opération devra être effectuée de nouveau en cas d'upgrade firmware DSM. (mais ce sera la seule chose à faire dans ce cas, tout ce qui est décrit ci dessous sera préservé) Créer le répertoire "/usr/local/etc/http.d" mkdir -p /usr/local/etc/http.d Tous le blocs de configurations décrits dessous seront à mettre dans /usr/local/etc/http.d/revproxy.conf dans l'ordre. Première partie - chargement des modules (tous ne sont pas nécessaires mais peuvent servir pour d'autres types de configs, par exemple le module "mod_proxy_ftp" permet par exemple d’accéder de l'extérieur à un serveur ftp freebox en http. <IfModule !proxy_module> LoadModule proxy_module modules/mod_proxy.so </IfModule> <IfModule !proxy_connect_module> LoadModule proxy_connect_module modules/mod_proxy_connect.so </IfModule> <IfModule !proxy_http_module> LoadModule proxy_http_module modules/mod_proxy_http.so </IfModule> <IfModule !proxy_ftp_module> LoadModule proxy_ftp_module modules/mod_proxy_ftp.so </IfModule> Obligatoire avant la suite NameVirtualHost *: <VirtualHost *:> ServerName * DocumentRoot /var/services/web </VirtualHost> 2ème partie - acces aux sevices DSM en http Ajouter le bloc suivant. (le nom "dsm" est un exemple). Dans le cas d'un domaine DDNS fourni par synology on aura par exemple "dsm.monnas.synology.me" <VirtualHost *:> ServerName dsm.mondomaine.com ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> Cette simple config permet de se connecter sur le port a l'interface dsm, en utilisant l'url http://dsm.mondomaine.com accès direct à filestation (sous réserve que le port 7000 ait affecté a file station dans le "portail des applications" du panneau de configuration) <VirtualHost *:> ServerName filestation.mondomaine.com ProxyPass / http://localhost:7000/ ProxyPassReverse / http://localhost:7000/ </VirtualHost> Ce qui donnera acces de façon similaire a filestation en http sur le port via l'url http://filestation.mondomaine.com. On procèdera de façon similaire pour les autres services tels qu'audiostation, downloadstation, webdav, etc ... en choisissant a chaque fois un nom de sous-domaine différent et le numéro de port correspondant. 3eme partie - acces https (SSL) Cette partie du fichier de config devra être précédée de la ligne: NameVirtualHost *:443 On va ensuite ajouter des blocs "VirtualHost" pour tous les services auquel on veit pouvoir accéder en https en sur le port 443 Cas de l'acces à l'interface DSM: <VirtualHost *:443> ServerName webman.mondomaine.com SSLCipherSuite HIGH:MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key SSLEngine on SSLProxyEngine on ProxyPass / https://localhost:5001/ ProxyPassReverse / https://localhost:5001/ </VirtualHost> Pour les autres services, on déclinera cela de façon similaire à ce que l'on a fait plus haut dans le cas http, en dupliquant le bloc ci dessus, puis en éditant dans la copie les lignes des clauses ServerName, ProxyPass et ProxyPassReverse. (attention à ne pas se tromper sur les numéros de ports utilisés en mode SSL, celui par défaut de filestation est 7001 par exemple, cf le portail des applications) prise en compte des modifications Pour cela, il est nécessaire de rédémarrer le serveur apache. Utiliser la commande: /usr/syno/etc/rc.d/S97apache-user.sh restart

Ne serait pas surpris que le jour ou tu passerea en DSM 4, pour peux que tu ais completement oublié tout ça, si les sauvegardes plantent tu risque de chercher longtemps. A ta place j'en profiterai pour me mettre propre, c'est apres tout.

Oups, bien vu. Je reprend donc: le lien http://tiny.cc/xml2epg-conf est réparé et le lien http://tiny.cc/xml2epg-latest pointe donc vers la version 2.7 du script (dont le lien direct est: http://pastebin.com/raw.php?i=4MSDQLD1 )

Il est vrai que, comme le paquet Syno DHCP Server s'appuie en fait sur dnsmasq et sa foultitude d'options ça semble ouvrir des perspectives. Mais en fait les fichiers de conf (voir dans /etc/dhcpd) sont intégralement gérés par le package et toute modification manuelle est irrémédiatement écrasée lors d'une modif via le panneau de conf ou bien au rédémarrage. La solution, si on veut aller plus loin, serait à mon avis alors d'installer le package sans le lancer et de tout faire à la main (lancement et configuration)

Ah zut de zut, c'est exact, @download semble être créé sur le volume ou downloadstation est installé en fait. Comme il me semblait bien avoir vu un @download sur mon volume2 et qu'en plus, j'étais tellement persuadé que les devs Syno ne pouvaient pas être assez stupides pour pratiquer comme il semble logique (utiliser des hardlinks sur le meme volume) que j'ai même pas pris le temps de vérifier. Je reconnais que vu comme ça, cette implémentation est assez c** Par contre pour la fragmentation, ca se discute: quant on crée un fichier sur un volume pour ensuite le copier sur un autre volume il est bien clair que cela ne créée pas de fragmentation *supplémentaire* sur le volume cible par rapport au cas ou on télécharge directement sur la cible. Quant au volume source, comme le fichier est alloué d'un seul tenant (puisque on connais sa taille des le départ, (et c'est déja d'ailleurs le cas pour le fichier source au début du téléchargement), la fragmentation induite peut être limitée dans ce contexte. Ta description de la copie : lecture->ecriture->effacement des données et en partie erronée (pourquoi diable irait-on *effacer* les données?) et aussi un peu simplifiée (ne pas oublier que les données avant d'être effectivement écrites sur les disques sont mises en cache et que l'algo de flush de ce dernier utilise des techniques de réorganisations de I/O pour limiter les mouvements de têtes. Par curiosité: tu a fais comment?

Il devait y a voir un probleme de mot de passe alors. Maintenant la synchro se fera en auto sans intervention ta part.