CoolRaoul

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]

Quel est le sshd qui tourne sur ta machine, celui d'optware ou celui natif DSM ?

Je pencherait plutôt, comme je le disais dans à penser que la raison est que la nouvelle version de sshd intégrée dans DSM4.1 ne prend plus en compte toutes les clauses de "/etc/ssh/sshd_config", et en particulier "Subsystem sftp" (depuis que Syno a intégré son propre client sftp)

Pas forcément: je met ce genre de chose dans "/usr/local/etc/profile", qui n'est pas touché (comme tout ce qui est sous /usr/local) en cas de mise a jour DSM Suffit d'ajouter ". /usr/local/etc/profile" dans /etc/profile en cas d'update. Et cela peut même être fait automatiquement par un script de startup dans "/usr/local/etc/rc.d" (pas touché donc) , qui ferait un truc du genre de grep -q "/usr/local/etc/profile" /etc/profile || echo ". /usr/local/etc/profile" >> /etc/profile[/CODE]

Oui mais cela va avoir l'inconvénient de masquer toutes les commandes optware pour lesquelles un équivalent DSM existe, et il peut y en avoir un paquet comme on peut le constater avec la commande ci dessous: ls /bin /usr/bin /sbin /usr/sbin | sed -e 's-^.*/--' |xargs which |grep /opt [/CODE] C'est pourquoi je préfère l'approche au coup par coup par alias.

C'est correct, et pour que ce soit la commande "uptime" de DSM qui soit utilisée à la place de celle d'optware ajoute la ligne suivante dans ton .profile: alias uptime=/usr/bin/uptime[/CODE]

Depuis quelques temps il apparait un chiffre en rouge dans le lien "shoutbox" Qui saurait-dire ce qu'il signifie? Je pensais que c'était le nombre de nouveaux messages mais apparemment non