CoolRaoul

Me semble que c'est bon, je vais essayer de t'envoyer le log en MP pour vérifier Au passage, deux petites requetes d'évolution: génération du log facultative choix du chemin du fichier log

Le fait que les dossier avec point soient masqués est tout à fait indépendant du NAS et/ou du protocole utilisé: c'est la commande "ls" qui les masque (sauf si tu utilises le switch "-a") Tu pourra constater , en faisant un "ls -a" dans un dossier Syno monté NFS sur ton Ubuntu, que tes dossiers "cachés" redeviennent bien visibles. Plus précisément, cacher les dossier commençant par "." n'est pas intrinsèque aux systèmes Unix, c'est juste une convention que certains outils/commandes (comme "ls") ont adopté et pas d'autres (comme filestation, ou "mc" <aka midnight commander>).

Sur cette fiche les tags genre sont bien en français ("Animation | Action | Crime | Drame | Science-Fiction") et pourtant je récupere les mot clés anglais

Je vais encore faire le pinailleur de base mais il y a toujours le genre en anglais ("comedy","drama" au lieu de "comedie", "drame" etc..). Et c'est d'autant plus étonnant que l'url vers la fiche IMDB est bien celle de la fiche fr ou les tags "genre" sont en français.

Je n'ai rien mis en commentaire: je me suis tenu au tuto dans le 1er post de ce thread

Pareil pour moi (ouf j'avais peur d'être le seul!) , j'ai suivi le tuto scrupuleusement (pas utilisé CFE mais bon ...) et j'ai les synopsys *et* les genres en anglais Comment est-ce possible que ça marche pour certains et pas pour d'autres?

Oups! Je n'avait pas fait gaffe que tu utilisais la methode "hybride" (sshd DSM et sftp serveur optware) Dans ce cas, il me semble bien que le sshd DSM soit sérieusement "customisé" par Synology et, par exemple, qu'il ne tienne pas compte de certaines clauses de sshd-config (telles que "Subsystem sftp") En regardant le contenu du script de startup sftp ("/usr/syno/etc/rc.d/S99sftpd.sh") on trouve des choses bizarres telles que : ${SSHDUtils} --register ${ReferKeySFTP} ${ReferProcSFTP} ce qui se traduit une fois les variables remplacées par: /usr/syno/bin/synosshdutils --register sftpd internal-sftp[/code] et donc on retrouve, comme par hasard, les lignes de config en question M'étonnerait pas que le ssh DSM lise une partie de sa confguration ailleurs que dans /etc/ssh/sshd-config.

en effet mais si il y en a plusieurs tu n'aura pas de message d'erreur, sshd va prendre en compte soit la première soit la dernière (me souviens plus) Dans le cas du ssh optware, ajoute la ligne suivante Loglevel Debug[/code] au fichier de config et regarde dans /var/log/messages. Sinon connectes-toi en telnet et relance le serveur ssh a la main

Suis chez moi aujourd'hui, tout en local donc. Mais on peut se passer de sftp, reste toujours "scp" apres tout.

en root non plus: me fait jeter

Absent mais de toutes façons Il est requis uniquement dans le cas de la config: Subsystem sftp /usr/libexec/sftp-server pas dans le cas suivant (celui que j'ai utilisé): Subsystem sftp internal-sftp[/code]

Semble plus marcher en 4.1: l'authentification se passe normalement (on se fait jeter avec le message ad hoc si mauvais mot de passe) mais immédiatement apres on se prend un "Connection closed" et voici la la log : Sep 3 17:24:51 sshd[1991]: Accepted password for clampin from 127.0.0.1 port 55746 ssh2 Sep 3 17:24:51 sshd[1991]: pam_unix(sshd:session): session opened for user clampin by (uid=0) Sep 3 17:24:51 sshd[2192]: subsystem request for sftp by user clampin Sep 3 17:24:51 sshd[2192]: Received disconnect from 127.0.0.1: 11: disconnected by user Sep 3 17:24:51 sshd[1991]: pam_unix(sshd:session): session closed for user clampin

Le service sftp disponible depuis en 4.1, contrairement au ssh, s'applique a tous les comptes. Par contre il ne laisse voir que les partages autorisés pour l'utilisateur (comme dans le cas du service ftp). Il ne donne par exemple pas acces à "/" et le compte "root" n'est pas autorisé (mais admin oui) C'est donc un sftp a la sauce synology (qui par exemple gère la corbeille si on l'a activée)

Intéressant tout ça! Et ca supporte le tunneling ssh ce bidule ? **edit** Plus précisément: Je veux parler du tunneling tcp a travers ssh **re-edit** Apres lecture de la doc, le tunneling ne serait possible qu'entre le syno et le serveur distant (qui peut être le syno lui meme bien entendu), donc pas tres utile à priori. Mais j'attend la suite avec impatience cela dit

Je ne serai pas aussi catégorique: de mon taf, étant derrière un proxy, je ne peux utiliser que les ports et 443 pour me connecter à mon Syno. J'ai donc installé shellinabox sur un port dédié (en écoute sur loopback uniquement) et je m'y connecte grace a une config reverse proxy. (avec une url du style http://monsyno/shellinabox) Cela n'est possible que parce shellinabox s'appuie exclusivement sur http ce qui le rend de fait accessible mème derrière un proxy d'entreprise. Cela dit faudra que je teste ce Gateone, j'ai du louper l'annonce (j'en été resté à l'annonce qu' ). ***EDIT*** Tu es sur pour le "longtemps" ? Le truc le plus proche que j'ai trouvé sur le site est "SSLH" qui est en "private beta" mais pas trouvé de trace de Gateone

Je dois avoir loupé un truc ou mal compris le principe car j'ai l'impression que l'option "-p" ne marche pas pour moi et que ça parcourt tous les dossiers a chaque fois: Exemple: root@fserv> /site/bin/run index_updater.py -a -p /volume1/music/podcasts -v 2 INFO - These directories will be checked: INFO - - '/volume1/music/podcasts' INFO - Start INFO - Media server enabled: START INFO - Configuration read : {'photo': {'path': '/volume1/photo', 'index_mime': {'image': True, 'audio': False, 'video': False}}, 'video': {'path': '/volume1/video', 'index_mime': {'image': False, 'audio': False, 'video': True}}, 'music': {'path': '/volume1/music', 'index_mime': {'image': False, 'audio': True, 'video': False}}, 'homes': {'index_mime': {'image': False, 'audio': False, 'video': False}, 'path': '/volume1/homes'}} INFO - *-* Working on share [photo] whose path is '/volume1/photo' INFO - [photo] is to be indexed INFO - *-* Working on share [video] whose path is '/volume1/video' INFO - [video] is to be indexed INFO - *-* Working on share [music] whose path is '/volume1/music' INFO - [music] is to be indexed INFO - *-* Working on share [homes] whose path is '/volume1/homes' INFO - [homes] is NOT to be indexed INFO - End

Tu trouvera un tutorial ici:

Je viens de découvrir que shellinabox (ainsi que webconsole) avait fait son apparition le centre de paquets: La source est: http://packages.missilehugger.com/

Et si on souhaite laisser DSM se charger des téléchargement tout en utilisant le serveur US (franchement plus véloce en effet) à la place du serveur EU, ajouter la ligne suivante à /etc/hosts sur le syno: 209.221.132.4 ukdl.synology.com[/CODE] (revient à "tromper" DSM en associant l’adresse IP du serveur US au nom du serveur UK)

Je me permet de déterrer ce vieux sujet car je bute sur un problème proche. Comment fait-on pour donner un FQDN au syno étant donné que le champ "Nom de Serveur" dans panneau de configuration->Réseau refuse le caractère "." ?

C'est réservé a des archivages et semble assez "low cost" (voir les tarifs sur la page): http://aws.amazon.com/fr/glacier/ Etant donné que Sunology à développé une interface avec amazon S3 on peut peut-être espérer une intégration de ce nouveau service à DSM qui sait ..

Noté, merci!

Je ne sais pas si c'est depuis longtemps, mais je viens de m'apercevoir que l'affichage des pages du forum met un temps fou à se terminer lorsque je me connecte derrière le proxy de mon taff. Dans la ligne de statut, chrome me dit "en attente de nasforum.dscloud.me". En effet, je retrouve bien dans le source des pages des références à des urls de ce type: "http://nasforum.dscloud.me:4000" Il se trouve que, comme la plupart des proxys d'entreprise, celui qu'on utilise n’autorise que les ports et 443. Je voulais juste le signaler au webmaster, au cas ou il aurait une méthode n'utilisant uniquement les ports standards.

Pour r

Mais peut être une alternative interessante étant donné que ce dernier s'appuie sur http