CoolRaoul

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.

Pas moyen d'attendre d'être sur place pour faire le transfert?

J'ai du mal a comprendre comment l'activation locale du service FTP (un serveur donc) peut servir a récupérer des fichiers disponibles sur un serveur distant. C'est un client qui est nécessaire ici. Ne pas confondre: Filezilla est un logiciel *client* qui tourne sous Windows.

Quels ports a ouvrir? Tu exécute le wget coté source et il va se connecter en http ou ftp sur le serveur distant (celui qui contient les photos) pour les récupérer en local. Faudra bien de toute façon que le serveur distant soit acessible, quelle que soit la méthode choisie pour le transfert.

Si tu n'as pas d'allergie particulière contre la ligne de commande, je te suggère de regarder du coté de "wget" (dispo en natif sous DSM, même pas besoin d'installer optware: /usr/syno/bin/wget)

je l'avais C'est bien ce que j'avais fait (suis en version 1.1-2199 de timebackup) EDIT: dans la doute j'ai tenté une désinstallation/réinstallation, ça plante pareil.

Premier problème rencontré depuis la mise a jour: impossible de créer manuellement (via l'interface web) des versions time backup. Ça me donne: Par contre les sauvegardes timebackups programmées continuent de fonctionner ainsi que l'exécution en ligne de commande comme ceci: /usr/syno/bin/timebkp create_version --task=essai --name=t1[/CODE]