CoolRaoul

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

D'abord compiler shellinabox comme je l'ai indiqué, Je dois ajouter quelques détails complémentaires: Le package ipkg openssl-dev est requis pour le support ssl La commande "configure" doit être: LDFLAGS="-L/opt/lib" CPPFLAGS="-I/opt/include" ./configure --prefix=/site (changer le "prefixe" a sa sauce) générer un certificat ssl autosigné pour shellinabox (à faire dans le répertoire des sources) mkdir -p <prefixe>/etc/shellinabox/ bash ./make-chained-cert.sh ><prefixe>/etc/shellinabox/certificate.pem [/code] dans un fichier de conf http inclus a partir de "/usr/syno/apache/conf/httpd.conf-user" mettre [xml] <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> <Location /shell> ProxyPass http://localhost:4200/ Order deny,allow deny from all # ce qui suit est un exemple, chaqun configure la sécurité a son gout allow from 192.168.1.0/24 </Location> [/xml] lancer le démon shellinabox comme ceci: [CODE]<prefixe>/bin/shellinaboxd --localhost-only --cert <prefixe>/etc/shellinabox --background[/code] dans tout ce qui precede <prefixe> est à chaque fois à remplacer par le répertioire choisi au moment du configure rédémarrer le serveur apache-user Ceci permet déja d'accéder au shell sur le port : http://<addresse syno>/shell Pour l'intégration au menu DSM, cela fera l'objet d'un post ultérieur

Je crois que ton reve n'est pas inaccessible: (réalisé sans trucage bien entendu)

Ça sera le même problème que pour l'applet java: va forcément s'exécuter dans le contexte du navigateur. Shellinabox est un serveur http (optionnellement https) qui donne accès à distance au shell (ou toute autre commande en mode terminal) dans un navigateur.

Trouvé et testé ceci: http://phpshell.sourceforge.net/ C'est très basique, le shell s'exécute dans le contexte du compte http (nobody) J'avais vu des machins plus sophistiqués (avec une applet java ), notemment au sein de webmin. Faut chercher encore un peu [edit] et voila: http://javassh.org/space/start [edit #2] Celui-la, c'est pas tout a fait ce que tu demandes: comme l'applet java s'éxécute sur le client, faut que ce dernier ait accès au synology en ssh ou telnet. [edit #3] Trouvé! http://code.google.com/p/shellinabox/ télécharger le source (shellinabox-2.13.tar.gz a partirde http://code.google.c.../downloads/list) extraire l'archive dans un répertoire de travail: cd <rep> tar xvzf <download dir> shellinabox-2.13.tar.gz cd shellinabox-2.13 compiler (necessite le package ipkg optware-devel): ./configure --prefix=<cible> # (cible: racine ou sera installé la commande, exemple --prefix=/volume1/site/, commande dans /volume1/site/bin) make make install et ensuite <cible>/bin/shellinaboxd -s "/:LOGIN" & Ne reste plus qu'a pointer le navigateur sur http://<ip du syno>:4200 pour voir le prompt de login: fserv login: root Password: BusyBox v1.16.1 (2012-04-13 04:26:57 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. @fserv> ls tmp @fserv> Doc en ligne: http://code.google.c...hellinaboxd_man

Trouvé solution, voir

Bon, je viens de m'apercevoir qu'avec la dernière update DSM, si on applique la meme approche au serveur apache systeme ("/usr/syno/etc/rc.d/S97apache-sys.sh"), timebackup refuse de créer des versions via l'interface WEB. J'ai trouvé un compromis qui semble fonctionner dans tous les cas: en mettant uniquement les variables suivantes dans l'environnement des services lorsque je les redémarre à la main: PATH USER SHELL HOME Ce qui donne le script suivant de redémarrage de service: #! /bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin cd /tmp svcdir="/usr/syno/etc/rc.d" svcname="$1" command="$2" if [ "$svcname" = "" ] ; then echo "Usage: $0 <service> [stop|start|status|restart]" echo "Services:" ls -1 $svcdir/S[0-9][0-9]*.sh | sed -e 's@^.*/@@' -e 's/^S../ /' -e 's/\.sh$//' | sort exit 1 fi >&2 for f in $svcdir/S[0-9][0-9]$svcname.sh do env - PATH=$PATH USER=root SHELL="/bin/sh" HOME=/ $f $command done [/code]

essayer de se connecter en telnet ou ssh sur le syno vider le contenu de /etc/resolv.conf (ou le renommer en /etc/resolv.conf.bad) puis redémarrer

Il n'y a rien à faire de particulier: à partir du moment ou "bidule.synology.me" est enregistré, tous les sous-domaines possibles ("machin.bidule.synology.me", "truc.bidule.synology.me" etc ...) sont automatiquement résolus en la même IP. Te restes plus qu'a faire joujou avec les virtualhosts

Avec uniquement le port 5000, tu n'aura uniquement acces a l'interface d'admin. A la limite, si ouvrir le port ne te poses pas de probleme, apres avoir activé web station, tu peux installer une passerelle ftp en php qui devrait répondre a ton besoin: Un exemple: http://www.net2ftp.com/index.php Et une copie d'écran qui montre que l'upload de répertoire et/ou de fichiers multiples est supporté:

Et puis, si tu ne veux pas ouvrir de port tu n'aura strictement aucun acces à ton NAS et la je ne vois pas de solution a ton problème. Le message parlait de télécharger sur le NAS des fichiers situés a l'extérieur, donc j'ai raisonné sur cette base: exécuter une commande sur le NAS pour aller récupérer de fichiers distants. En plus ça se confirme comme il vient maintenant de confirmer qu'il ne voulait pas ouvrir de ports sur sa box, ca m'étonnerait qu'il accepte d'activer FTP.