CoolRaoul

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

Corrrection appliquée : http://pastebin.com/PU2wdJPQ La modif est minime, il a suffit d'ajouter $event_name =~ s/,/ /g; apres la ligne $event_name .= " - " . $prog->{"sub-title"} if exists $prog->{"sub-title"};[/code]

Tu trouvera l'explication en observant le contenu de la variable "$PATH"

Tres simple a faire. Penses-tu que cela devrait être fait de façon systématique ou de façon optionnelle?

Bon, je vous annonce une nouvelle version du script. A cette occasion je avouer avoir perdu la foi dans le perl natif de DSM: suis tombé au cours de ma mise au point sur des bugs vraiments zarbis se manifestant par des écrasement mémoires, des regexp qui matchent un peu n'importe comment et jusqu'a des "out of memory" franchement pas rassurants. Bref j'ai basculé sur le perl d'optware qui m'a l'air bien plus stable. A part cela je me suis débarassé des modules de parsing XML et j'ai remplacé tout ça par un parsing plus rustique (sinon carrément agricole), entièrement fait à la main et à l'ancienne et qui tient dans une dizaine de lignes de code. Le tout se trouve ici: http://pastebin.com/T5BuU1HT et donc "ipkg perl" obligatoire (désolé) un simple chmod -x peut être suffisant Vérifie ce que ca donne avec le nouvelle version du script

C'est lequel qui manque exactement: 1537.epg ou 1281.epg ?

Non, on va matcher 3 fois "TF1" en fait mais c'est pas grave: DEBUG: /^TF1/ sid=1537 DEBUG: /^TF1/ sid=1281 DEBUG: /^TF1 HD/ sid=1281 Le résultat est que l'on va générer un fichier unique linké sous les deux noms "1281.epg" et "1537.epg" (puisque les programmes de TF1 et TF1HD sont les mêmes) Tu dois donc avoir ces deux fichiers dans le répertoire EPG. Il est possible de vérifier, en les listant par "ls -li", qu'ils ont le meme inode. (Bon, je me demande quand même si il ne vaudrait pas mieux générer deux fichiers séparés a cause de la ligne "service_id" : <id> qui devient de fait incorrecte dans un des cas, à voir à l'usage)

A priori ca signifie que tu n'a pas canal+ dans "/usr/syno/etc/packages/VideoStation/channels.conf" Faudra que je change l'erreur en warning et que le script ne s'arrete pas dans ce cas. En attendant tu peux déja remplacer la ligne: die "unknown channel $channel, aborting\n"; par next;[/code]

Tiens donc, je verrai ça se soir en ajoutant un peu code de debug au script pour que tu puisse mieux voir ou et pourquoi ca plante chez toi

Et voici le résultat: http://pastebin.com/dWkEuLuf Il reste très certainement quelques bugs... Le tableau "name2channels" sera à compléter pour ceux qui récupèrent les xml avec les chaines payantes et locales, Ensuite plus qu'à mettre tout ça en cron hebdo et trouver comment inhiber la génération des EPG par videostation.

en effet, j'ai vu j'y travaille...