CoolRaoul

Tu pourrais m'en déposer un exemplaire quelque part de ton fichier "XML créé par MC2XML", parce que vu toutes les options du bouzin, avant que je tombe exactement dans le meme cas que toi ....

Je regarderai ça si je trouve un moment

Pas vraiment d'accord sur ce point: le PATH, tel qu'il est modifié dans "/etc/profile" et/ou dans "~/.profile" pour le setup d'optware ne s'applique qu'aux shells interactifs, autrement dit uniquement à ceux lancés dans une session ssh et/ou telnet. Tous les autres process, lancés aux boot du NAS ou indirectement par les scripts de démarrage des packages n'héritent pas du PATH modifié ainsi. Voila pourquoi je ne suis pas d'accord sur le coté "très lié au systeme". C'est un peu comme si on disait qu'installer Cygwin sous une machine Windows à des impacts a cause d'une forte adhérence entre Cygwin et le système windows et justifie de perdre le support Microsoft. Un NAS sous DSM où optware est installé peut éventuellement, après avoir démarré, avoir des process liés a optware qui tournent (si on les a ajoutés au scripts de startup) mais *aucun* des process natifs DSM ne peut être affecté par la présence de "/opt", que ce soit sous forme de "mount -bind" ou de lien symbolique.

Euh ... pour le coté "tres ouvert" mon expérience me rend un peu moins enthousiaste que toi, voir mon post ici:

Suite a un crash de mon Syno (des choses étranges apparaissant dans /etc, ) j'ai ouvert un ticket de support. D'apres le log qu'on ma demandé d'envoyer, ils ont pu constater, d'après la liste des process, que j'avais une compilation en cours de module perl pour optware. Réponse reçue: "We do not officially support 3rd-party software and it is violating the warranty policy. We don't officially supported it, so we are unable to ensure its compatibility with the DS and DSM update, not to say it is likely to cause DS to behave abnormally." Doit on conclure qu'installer quoi que se soit de non explicitement supporté directement par Synology (et j'imagine que les packages synocommunity risquent de faire partie du lot) fait perdre la garantie ?

sur le m

Reçu aujourd'hui, l'exemplaire que j'avais trouvé d'occase moitié prix sur amazon. La vendeuse devait désespérer de trouver preneur vu le contenu totalement négatif du seul et unique commentaire sur la fiche produit. (totalement injustifié si vous voulez mon avis) Comme neuf dans sa boite d'origine, marche parfaitement. Content je suis [95392.650000] usb 1-1.2: new high speed USB device using orion-ehci and address 3 [95392.770000] usb 1-1.2: configuration #1 chosen from 1 choice [95395.710000] dvb-usb: found a 'Pinnacle PCTV 73e' in cold state, will try to load a firmware [95395.720000] usb 1-1.2: firmware: requesting dvb-usb-dib0700-1.20.fw [95395.810000] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' [95396.070000] dib0700: firmware started successfully. [95396.590000] dvb-usb: found a 'Pinnacle PCTV 73e' in warm state. [95396.590000] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [95396.610000] DVB: registering new adapter (Pinnacle PCTV 73e) [95396.860000] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... [95397.090000] DiB0070: successfully identified [95397.100000] dvb-usb: Pinnacle PCTV 73e successfully initialized and connected. [95397.110000] usbcore: registered new interface driver dvb_usb_dib0700

Non, ce comportement ("Failed None") est tout a fait normal. Tu peux baisser la verbosité avec la clause "LogLevel" dans sshd_config si tu veux: http://www.openbsd.o...ery=sshd_config:

J'ai rencontré le même problème avec Google Music: des pistes ayant le même tag "album" et le même tag "artist" sont considérés comme faisant partie d'albums différents si le tag "Album Artist" n'est pas identique. En fait, je crois comprendre que le tag "Artist" peux être différent dans un album suivant les morceaux (cas des compilations par exemple), par contre le tag "Album Artist" doit être unique (la coutume est de donner au tag "Album Artist" la valeur "Various Artists" dans cette situation ) J'ai peur que tu ne recoupe pas à l’édition de tags (je laisse d'autres te répondre pour te proposer des logiciels pour ça).

Ah oui, j'airais pu tester de mon coté quand même .. C'est une approche classique quand on veux résoudre un problème faisant potentiellement intervenir plusieurs composants (machines, boitiers, cartes, etc...) : toujours commencer si possible par limiter le périmètre au maximum, comme ici en restant sur une seule machine. Et ca donne des résultats, la plupart du temps En tout cas ton problème est résolu n'est-ce pas?

Oh! j'ai oublié de spécifier la clé a utiliser dans la commande de connexion de test! Faut faire: ssh -i~/ssh/test root@localhost au lieu de ssh root@localhost[/code]

J'ai une possible solution: [*]demande au support Synology de se connecter en ssh plut

D'abord essayer de mettre PermitRootLogin yes dans le fichier sshd_config sinon y ajouter LogLevel DEBUG[/code] recommencer la tentative de connexion et regarder dans /var/log/messages si on trouve des indications sur la cause (relancer sshd a chaque modif) Tu peux faire un test de connexion par clé avec une clé privée de test provisoire: en étant connecté root en telnet sur le syno, faire [code] cd ~/.ssh ssh-keygen -f test -t rsa -P "" cat test.pub >> authorized_keys ssh root@localhost [/code] Que ca marche justement, histoire de ne pas perdre du temps sur certaines pistes. On sait maintenant que le problème est uniquement sur le compte root. La par contre, cela va s'avérer bien plus ennuyeux si tu ne trouves pas de solution (pas trouvé de mon coté), ça va remplir la log a vitesse Grand V J'ai bien cherché par google sur cette erreur mais ce que je trouve semble indiquer qu'il faudrait recompiler openssh an modifiant une option... pas top.

En effet, essaie avec un compte non root et saisit le mot de passe lorsque le système le demande: ssh <username>@localhost pour confirmer que le login est possible

Bon, apres ces frayeurs, reprenons... Comprend pas ce que tu veux dire par la.. maintenant que le tu n'utilises plus le sshd de syno, on peut déja oublier ce problème-là Aucune importance, a la limite tu fait un "killall sshd" la commande suivante devrait résoudre le probleme ssh-keygen -t ecdsa -C '' -N '' -f /opt/etc/openssh/ssh_host_ecdsa_key[/code] Er bien quels sont les problemes restants alors?

Je le crois pas: il est de retour et rien n'est cassé! fserv login: root Password: BusyBox v1.16.1 (2012-08-30 00:05:10 CST) built-in shell (ash) Enter 'help' for a list of built-in commands. root@fserv> uptime 16:20:06 up 5 min, load average: 0.71, 1.17, 0.58

telnet, sans acces a /etc/passwd, c'est pas gagné... J'ai lancé un "/sbin/reboot" et on verra l'étendue des dégats ce soir a la maison ....

je ne vais plus pouvoir t'aider pour le moment, cf mon message précédent

Merde!!! j'ai voulu installer ssh optware pour t'aider et voila le résultat juste apres le "ipkg install" root@fserv> ls -l / | grep etc ls: cannot access /etc: No such file or directory d????????? ? ? ? ? ? etc drwxr-xr-x 15 0 0 4096 2012-09-04 10:59 etc.defaults

et donc qu'est ce qui ne marche pas? que se passe-t-il, lorsque, connecté au syno, tu tapes et/ou .

ce que je veux savoir est quel sshd est en cours d'exécution fait plutot: ps -ef |grep sshd[/CODE]