CoolRaoul

Un peu dommage de payer (même si c'est pas cher) quand il existe une solution gratuite

Apparemment on peux faire le "register" par script: http://blogger.ziesemer.com/2010/01/dyndns-update-client-shell-script.html suffirait de le mettre en cron

Tu peux peut-etre basculer la gestion DDNS du syno vers synology tout en conservant ton nom chez dyndns. Si tu a en plus une IP fixe, pas besoin d'avoir de mise a jour auto chez dyndns et tu beneficiera des deux noms (.dyndns.org et .myds.me)

J'aurai aimé trouvé un truc tout en un, comme audiostation en fait. (et c'est le titre du fil qui m'a attiré) j'ai déja testé fut un temps quelques trucs en php, mais rien qui ne m'ait vraiment enchanté.

Essaie la commande "nslookup dsm.domaine.dyndns.org" (ou n'importe quoi a la place de "dsm") si ca ne te donne pas ton ip externe, c'est que dyndns ne gère pas le "catchall" pour les sous domaines, ce qui est bien ennuyeux pour toi. Avec myds.me, une fois que l'on a enregistré son nom (monsyno.myds.me) *toutes* les requetes en <nimportequoi>.monsyno.myds.me sont résolues avec l'ip de base. On dispose donc d'un nombre de sous domaines infini.

Bien sur que je connais: j'ai posté dans ce fil! (et dans un autre auquel il fait référence) En effet, depuis la DSM 4, il fait éviter de trifouiller les fichiers /usr/syno/etc/httpd-ssl-vhost.conf-user et /usr/syno/etc/httpd-vhost.conf-user c'est pourquoi depuis je préconise de se contenter du "include" dans "/usr/syno/apache/conf/httpd.conf-user"

Etant donné que ça marche avec les nom de domaines dynamiques fourni par syno ("myds.me" par exemple). Pas de raison que ce soit différent avec dyndns. je viens de vérifier:

Savais pas, Suis étonné en plus: comment les sauvegardes rsync peuvent dépendre de conf apache ? Oh, Il s'agit d'une toute petite modif de rien du tout: ajout d'une simple ligne dans "/usr/syno/apache/conf/httpd.conf-user": include <dossier perso dans /volume1/conf.d/*.conf[/CODE] Si la MAJ écrase la modif, suffit de la rajouter.

virtualhost! (cf le tuto de PatrickH) Dans le fichier ou tu as defini le block "location" pour SIAB (ou un autre si tu veux), tu met ceci: (remplacer dans la suite "MONDOMAINE" par le nom DNS externe, par exemple: "monnasamoi.myds.me" si enregistré ainsi en dynamique chez synology) #+ # Les "loadmodules" semblent faire double emploi avec ceux de la conf SIAB # mais on s'en br^h^hfout grase au IfModule #- <IfModule !proxy_module> LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so </IfModule> NameVirtualHost *: <VirtualHost *:> ServerName webman.MONDOMAINE ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> # # SSL # NameVirtualHost *:443 <VirtualHost *:443> ServerName webman.MONDOMAINE 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 ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / https://localhost:5001/ ProxyPassReverse / https://localhost:5001/ </VirtualHost> Et voila, tu peux te connecter maintenant sur l'interface DSM avec l'url http://webman.MONDOMAINE et https://webman.MONDOMAINE en ssl. PS: en général faire comme ici des virtualhosts basés sur le nom en SSL n'est pas préconisé. Si tu veux gérer strictement le certificat de site ça va poser des problemes. Mais si l'objectif est uniquement de chiffrer le traffic c'est suffisant. Bien entendu on peut choisir ce qu'on veut comme nom de sous-domaine à la place de "webman". Il est possible de procéder de façon similaire pour filestation, downloadstation, audiostation. Cela dit, en installant haproxy je pense que l'on pourra se passer du proxy apache, ce qui rend tout cela obsolète. A suivre donc

j'ai trouvé ca : audio_output { type "httpd" name "Streaming ogg vorbis" encoder "lame" # optional, vorbis or lame port "8000" # quality "5.0" # do not define if bitrate is d$ bitrate "128" # do not define if quality is d$ format "44100:16:2" } Le serveur marche, mais apres je suis sec (je ne sais pas comment écouter la musique) Je pense que je vais rester avec audio station..

As-tu bien activé le ssl sur webstation? (panneau de configuration->services web->service http->activer https?)

Quelqu'un aurait-il de l'aspirine dans l'assistance? Déja faire un essai ...

je m’immisce ... J'avais cru comprendre ici que mpd nécessitait la présence d'une carte son et j'en ai conclus qu'il servait donc à lire de la musique en local plutot qu'à streamer. On m'aurait trompé? J'ai essayé de l'installer mais suite à: output: No "audio_output" defined in config file output: Attempt to detect audio output device output: Attempting to detect a oss audio device oss: Error opening OSS device "/dev/dsp": No such device oss: Error opening OSS device "/dev/sound/dsp": No such file or directory output: Unable to detect an audio device j'ai laissé tomber.

Commencer par ipkg update ipkg upgrade retenter le ipkg install optware-devel et si l'erreur persiste, alors sortir le rouleau-compresseur ipkg install --force-overwrite optware-devel

Je ne bénéficie pas de cette fonctionnalité : notre proxy est configuré pour supporter uniquement HTTP et FTP (et encore de façon limitée). En outre, comme je ne suis pas admin réseau à ma boite, la config du proxy ne dépend pas de moi (et même si c'était le cas nous avons des règles de sécurité qui m'empècheraient de faire tout ce que l'on veux). Cela dit, va falloir que je vérifie aussi que shellinabox fonctionne à travers notre proxy (qui n'est pas de la première jeunesse en outre) Dans ce cas, ça ne devrait pas faire de différence, le probleme est ailleurs alors. Tu as bien relancé apache au moins? Ah non pas du tout, la restriction d'ip se fait *en amont* du proxy, c'est l'ip externe qui est validée [edit] je pense a un truc d'un coup: suivant comment ta box fait les redirections de port, lorsque tu te connectes sur place en utilisant l'ip externe il est possible que ca coince. Dans le cas d'une freebox, ça fonctionne et la connexion va sembler provenir de la freebox (a prendre en compte dans le "allow from" Essaie pour voir avec l'ip *interne* du syno: https://<ip_interne>/shell

C'est que la config proxy n'est pas prise en compte: Le fichier contenant les lignes: <Location /siab> ProxyPass http://localhost:4200 Order deny,allow deny from all allow from etc ... </Location> Doit être inclus directement ou indirectement par un des fichiers de conf apache. Pour ma part, à la fin de "/usr/syno/apache/conf/httpd.conf-user" j'ai ajouté une ligne "#include" du fichier ci dessus. Suffit de relancer apache pour que cela soit pris en compte: /usr/syno/etc/rc.d/S97apache-user.sh restart

Quelle tache que je suis: je viens de m'apercevoir que j'avais laissé ssl désactivé pour mes tests! Et d'ailleurs en fait, avec le proxy on peut rester comme cela. Lorsque l'on se connecte en https avec l'url "https://<adddresse syno>/shell", le traffic entre le monde extérieur et le syno est bien crypté SSL. Ce n'est que le traffic local (sur localhost) qui est en clair donc pas vraiment de probleme. J'ai pu vérifier tout ca avec une capture de packet (tcpdump) A mon avis c'est complémentaire, par exemple avec le shell dans le navigateur je pourrais me connecter de mon taf en shell sur mon syno (sous réserve d'avoir ajouté la ligne "allow from" qui va bien), alors que le VPN est hors de question, n'étant pas admin sur mon PC pro. [edit] et en VPN difficile de faire un /usr/syno/etc/rc.d/<service>.sh restart par exemple. [edit#2] de toutes façons admin ou pas, derrière un proxy, le VPN, hein ....

Essaie d'abord de le tester en dehors de l'interface, c'est plus simple. L'inclusion dans DSM est a mon avis pas essentielle. Pouvoir l'attaquer via le port grace au proxy me semble suffisant pour commencer. [edit] si tout est bien configur

C'est pour ça que j'avais indiqué d'installer le "meta package" "optware-devel" qui contient tout les outils nécessaires pour compiler.

Directement via le desktop gnome (places->connect to server->service type=webdav) je viens de le faire sans aucun probleme. Par contre je ne connais pas ce "gigolo". Sur cette page il est question de spécificités lors de connections webdav avec authentification Peut-être regarder par la?

Tes posts précédents ne m'on pas donné l'impression d'un noob mais bon... non, le certif n'est nécessaire que lors de l'exécution donc à faire avant de lancer le démon et une seule fois "./prog" ne marcherait pas parce que le script contient le shebang "#!/bin/bash -e" alors que le bash optware est dans /opt/bin. Mais tu peux aussi le lancer avec le shell standard "sh" ("sh <prog>, je viens de vérifier) Le "enable-ssl" est automatique des que configure détecte la présence de openssl. Donc pas necessaire, car LDFLAGS et CPPFLAGS servent à ça justement. Mais assure-toi de bien avoir installé le package ipkg openssl-dev. J'ai pas vérifié mais c'est ce qui est utilisé par défaut en général De toutes manières ça ne mange pas de pain de mettre un --prefix=/usr/local explicite

C'est le proxy qui permet cela. Grace aux les lignes suivantes dans le config apache: <Location /shell> ProxyPass http://localhost:4200/ </Location> Les connexions http arrivant avec l'url http://<addresse du syno>/shell sont "proxyfiées"/"tunnellées" (quel terme utiliser ???) en sur le port 4200 local. SIAB, sous réserve qu'il ait été compilé avec le support SSL et n'ait pas été lancé avec le switch "--disable-ssl-menu", passe automatiquement de http en https, c'est pourquoi on peut laisser "http://" dans la conf ci dessus. Tu remarquera d'ailleurs que je lance SIAB avec l'argument "--localhost-only". Comme cela le démon n'écoute que sur l'ip de loopback (127.0.0.1) et on est obligé de passer par le proxy pour s'y connecter. Ceci permet de mettre des restrictions d'ip grace aux directives "allow from" d'apache au lieu de le faire via le firewall.

Bigre, alors que je n'y m'y attendais pas du tout je m’aperçois que le plein écran est supporté par shellinabox. "vi" fonctionne! en fait on dispose d'une emulation xterm, y compris la couleur!

Ben oui car la sous-fenetre shell utilise son propre flux http, indépendant de la fenetre DSM. En remplacant, dans le tuto de http://www.synology-forum.de "type":"legacy", par "type": "url",[/code] l'application étant alors lancée dans sa propre fenetre, on peut constater que l'url est "http" et pas "https"

En effet, quasiment identique, manque juste le support de SSL