CoolRaoul

Il est tres courant que les proxys d'entreprise n'autorisent que les connexions vers les port et 443 (parfois 8080) Si c'est le cas, le 5000 doit être bloqué et ne te reste alors que la solution ou

Dernières nouvelles du front: initialement, (juste apres l'update 4.2 donc) mon ntp.conf s'est retrouvé avec le contenu suivant server 127.127.1.0 prefer Une fois activée l'option service ntp, il s'est retrouvé ainsi: server 0.fr.pool.ntp.org minpoll 6 maxpoll 10 iburst prefer Et et redésactivant à nouveau l'option, alors qu'on pouvait imaginer se retrouver dans l'état initial, voila le résultat: server 0.fr.pool.ntp.org minpoll 6 maxpoll 10 iburst prefer restrict default noquery notrust nomodify restrict -6 default noquery notrust nomodify restrict 127.0.0.1 restrict -6 ::1 restrict 0.fr.pool.ntp.org

En effet DSM n'utilise plus la crontab pour la synchro NTP. En outre, après avoir forcé une synchro manuelle, j'ai observé que l'offset était de 236 secondes (pres de 4 minutes), un peu beaucoup à mon avis. En activant la (nouvelle) fonction *serveur* NTP dans DSM, le ntp.conf est mis a jour avec une référence au serveur spécifié dans l'interface et le démon ntpd du syno se met alors en mode synchro NTP "au fil de l'eau". J'ai donc un peu l'impression que si la fonction *serveur* NTP n'est pas activé, les fonctions de synchro en tant que *client* ne sont pas actives. A surveiller.

Si par "toujours d'actualité" tu veux dire est-ce que ça fonctionne à l'identique, la réponse est oui (juste désactiver l'option "SSLCipherSuite HIGH:MEDIUM", qui a pour résultat de faire ramer à mort les connexions ssl, voir ) Ensuite, je confirme que synology.me permet d'utiliser autant de sous domaine que voulu, sans rien a déclarer (ssdomaine1.mondomaine.synology.me, ssdomaine2.mondomaine.synology.me, etc ...)

C'est de notoriété publique cette qualité déplorable du support AFP sur Syno? (suis pas tres au courant, n'utilisant pas de Mac)Aurais-tu des sources? Sinon, tu pourrais vérifier si AFP ne se serait pas amélioré en 4.2, vu ceci: http://www.pcinpact.com/news/76584-synology-dsm-4-2-beta-augmentation-performances-et-support-dairplay.htm **EDIT**etant donné que Synology a annoncé que les performances SMB étaient améliorées avec la 4.2, si tu rencontre une baisse, il faut que tu ouvre un ticket de support, ce n'est pas normal

Quel intérêt de faire du SMB sur Mac ?

Pourquoi pas, j'aimerai bien comprendre ce qui coince: je viens de faire deux tests successifs, avec la meme source EPG, avec le perl DSM et le perl optware et je ne reproduis pas l'erreur. Tiens moi au courant PS: pour l'acces au NAS je n'aurais pas besoin d'un compte root, un compte utilisateur lambda sera suffisant.

les commandes de base a connaitre pour utiliser le debugger: pour lancer le script en mode debug: perl -d <chemin du script> <parametres> ensuite: examiner une variable: x <variable> point d'arret: b <No de ligne ou nom de fonction> pas a pas: n continuer c ca devrait suffirt pour un début

Toutes les conversion de temps du format chaine de EPG vers le format interne sont faites par ma fonction "str2time". Si tu maitrise perl, sous debugger, en mettant un breakpoint dans cette dernière, tu peux peut-être voir d'ou viens l'erreur.

Tu as l'erreur sur toutes les emissions ou uniquement dans la partie que tu as extraite?

Dans mes bras !!!

Pourquoi avoir fait ça puisque avoir désactivé les logs du serveur multimédia avait *déja* résolu ton probléme? **EDIT** oups, confondu avec Spider02

Ca serait intéressant de savoir si le même problème est constaté par les utilisateurs de haproxy

Ok, c'est la même que sur ARM alors Merci mais, vu que ton problème n'est pas résolu, les remerciements ne sont pas tout a fait mérités

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