gaetan.cambier

suis un vrai boulet, je trouvait ton post sur mon gsm mais pas sur mon pc ... doit ouvrir les yeux bon, serieusement voici ce qui t'intéresse : http://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-SSH-Public-Key et rajouter la clé dans ton profil github.

chown 755 nom du fichier en ssh

http://askubuntu.com/questions/48941/is-it-possible-to-give-two-ip-addresses-for-the-same-host-name mais bon, si on préfère jouer au coup de chance pour savoir si le syno va renvoyer la 1° ip, ou la 2° (plus de chance que ce soit la 1°, il lit surement le fichier dans l'ordre), chacun ses choix en plus, sur mon nas, j'ai 4 interface, j'ai un seule ligne pour mon nas dans le fichier host, si ce n'est le localhost en plus.

Intéressant, 2 IP différente pour ton diskstation. C'est déjà pas très normal Faudrait savoir qu'elle est l'IP de ton syno et taper cette commande dans un terminal windows : nslookup Diskstation_414

Il y a eu une update depuis me semble qui corrige cela a moins qu'elle n'ait pas encore été distribuer

En ssh avec putty pour ma commande. Pour la commande du service technique syno, c'est dans une fenêtre de commande Les 2 résultats serait intéressant pour p-e comprendre

en y repensant, ca pourrait venir du fichier hosts peut-etre ce problème quelqu'un pour vérifier le contenu et qui a le bug ? DiskStation> cat /etc/hosts

v tester çà de suite déjà chez moi

Un accès en lecture seule sur le partage ne serait-il pas + simple ?

Ben, beaucoup vont être heureux

Pas sérieux ça

le PR est fait, bon, on sera resté quelque jour dessus pour une modif de 1 caractère en somme

je crois que je vais avoir plus facile pour le PR

et changer le su - par su resoud le problème ? ce serait plus simple encore alors

Peux toujours y regarder

Précision : quelqu'un en dsm 5.1 pour tester

donc, à l'écriture du fichier, dans tous les cas, la chaine suivante est ajoutée au retour de l'erreur : ←7←[r←[999;999H←[6n on se trouve donc apparemment dans le fichier direct.py à la ligne suivante (78): error = subprocess.check_output([self.start_stop_status, 'check'], stderr=subprocess.STDOUT) selon cool raoul, ca proviendrai de l'ajout de la commande resize dans le /etc.profile j'aurait bien tester quelque truc avec cette fonction, mais en 5.0, la commande est semble inconnue

une solution temporaire, c'est la commande suivante en ssh pour redemarrer : init 6 ou reboot c'est mieux pour le nas que de l'eteindre violemment

Une info est toujours utile. maintenant, soit on supprime le resize, mais c'est un peu bourrin soit on trouve comment contourner ce problème

Non pas grave, pas utile mais qu'elle soit la ou pas ne changera rien.

import re ? j'avais laissé un autre message hier avec juste la modif de : return error.decode('string_escape') ceci a été tester ? après çà, je donne ma langue au chat de toute façon

notre testeur est partis dormir probablement, je vais faire de meme

la solution la + simple si tu as un pc fixe, c'est de mettre le hdd dedans et demarrer sur un linux sur usb ou cd

bon dernière tentative si on veut bien : c'est à la meme place : original : def check(self): with open(os.devnull, 'w') as devnull: error = subprocess.check_output([self.start_stop_status, 'check'], stderr=subprocess.STDOUT) return error modification (dernière ligne) def check(self): with open(os.devnull, 'w') as devnull: error = subprocess.check_output([self.start_stop_status, 'check'], stderr=subprocess.STDOUT) return error.decode('string_escape')

j'ai p-e conpris, les espace devant les ligne ont de l'importance, j'aurait du le dire je redonne avec les espace : def check(self): with open(os.devnull, 'w') as devnull: error = subprocess.check_output([self.start_stop_status, 'check'], stderr=subprocess.STDOUT) error_escape = re.compile(r'x1b[^m]*m') return error_escape.sub('', error)