CoolRaoul

Alors te voila bien seul, vu que ce site mystère (seule source bootstrap optware pour les architecture quoriq) n'a même pas de forum d'entraide. En tout cas, tant qu'a utiliser un perl 5.8.X, autant rester au perl DSM 4.2 (normalement 5.8.6) alors. L'ennui est que je ne pourrait pas facilement reproduire ta configuration. Peux-tu juste [simple curiosité] m'indiquer la version de ton perl DSM (commande "/usr/bin/perl --version"), histoire de vérifier si on a la même?

Bizarre cette référence à 5.8.8, le perl optware est en version 5.10.10 pour moi: serv> ipkg list perl perl - 5.10.0-6 - Practical Extraction and Report Language. Successfully terminated.

Tout m'a l'air OK, (a part les habituels warnings unicode du au perl natif DSM) comprend pas ce qui peut coincer

J'ai eu la meme idée que toi avec bien entendu le même résultat... Le probleme semble bien lié a la combinaison SSL/reverse proxy (je n'ai pas la possibilité de tester en SSL direct pour le moment)

Non, peut-etre rédémarrer videostation, je ne me souviens pas que quiconque ait signalé ce problème. Faudrait donner les paramétrés utilisés pour exécuter le script, et un copier/coller de ce qu'il affiche pourrait être utile aussi

Apres avoir activé l'error log apache, il se remplit de messages de ce genre lors de connexions ssl [Thu Mar 07 08:46:51 2013] [error] [client nnn.ppp.qqq.rrrr] Re-negotiation handshake failed: Not accepted by cli ent!?, referer: https://<mon_domaine.com>/webman/index.cgi Si ça donne une idée a quelqu'un ... Je pense que c'est lié au reverse proxy

Il semble que tu sois passé, pour récupérer le script, par un copier/coller dans un editeur windows qui modifie le terminateur de ligne. Je te conseille de le récupérer directement sur le NAS par une commande wget: wget -O xml2epg.pl http://tiny.cc/xml2epg-latest

ben si même la connexion telnet est impossible à partir du réseau local, le reset peut se tenter. faut espérer que ce ne soit pas plus grave

parfait, tout est redevenu normal.

Un collegue sur DS211 (pas "+" mais pas "J" non plus) n'a rien constaté.

Ah oui, etonnant dans ce casFaudrait pouvoir faire un inventaire de qui est touché et qui ne l'est pas

Quel modèle ?Un collegue ne semble pas avoir le problème sur son DS212, sur mon DS210J c'est franchement catastrophique

par "rien" tu veux dire meme pas le prompt "username" ?

J'ai aussi constaté cela, uniquement en HTTPS. C'est pas limité a DSM, shellinabox rame a mort en https aussi On dirait que le moteur de cryptage matériel n'est pas utilisé par SSL en 4.2

pourquoi?

C'est par ça qu'il aurait fallu commencer, donc oui! Et si ça ne marche toujours pas, activer temporairement telnet sur le syno S1 et essayer de se connecter en telnet ("putty -telnet", ou simplement avec la commande telnet) avec le PC connecté de la même manière.

As-tu un moyen de t'assurer que le démon sshd de s1 est bien actif et est a l'écoute sur le port 15632 ? Un moyen d'avoir un acces *direct* à S1 (sur place, étant connecté au mème lan) ?

(Pas bien compris les différences de fond entre les deux derniers tests: si la connexion S2 -> S1 sort en timeout ça le fera quelle que soit la façon dont on est arrivé sur S2, directement ou en faisant un aller/retour) Cela dit, il serait intéressant de savoir si tu parviens à te connecter sur S1 à partir d'une *autre* équipement que S2. As-tu fait ce test?

Tu est bien connecté "root" ? (je viens de vérifier, je suis en 4.2 et aucun problème sur le chmod)

Ok dans ce cas, ça revient au même alors, mais ça n'explique pas ce qui s'est passé sur le serveur dhcp du routeur pour allouer ainsi une adresse différente.

Quel rapport avec les NAS Synology? **EDIT** Grilled!

De toutes façons, avec un erreur de type "timeout" ça ne peux pas être un probleme de clé

Non, dans ce cas le probleme est ailleurs

je pensais au firewall intégré au Syno

Il y aurait peut être une piste (un peu tordue je reconnais) mais, attention, je n'ai pas testé. Bien que l'interface DSM permet de mettre des quotas uniquement au niveau de l'utilisateur, la commande "setquota" (/sbin/setquota) supporte les quotas de groupes (cf setquota --help) Par conséquent, en créant un groupe dédié à cet usage, il devrait être possible, en forcant le groupe pour les dossiers/fichiers créés dans le dossier (chgrp le groupe le_dossier ; chmod g+rxxs le_dossier), en limitant l’accès au dossier aux membres du groupe (chmod "o=" le_dossier) et en ajoutant au groupe les utilisateurs autorisés à accéder au dossier, de positionner un quota sur le groupe (avec la commande setquota) et aboutir à l'effet souhaité. Mais je le répète, ce ne sont que des hypothèses à tester!