CoolRaoul

Attention ce n'est pas un fichier mais un répertoire qui contient des scripts. J'en ai expliqué le principe aujourd'hui même ici: tout à fait Tous les scripts de /usr/local/etc/rc.d qui respectent les règles de nommage que j'ai indiquées dans mon autre post sont exécutés dans l'ordre alphabétique de leurs noms (sauf en cas de crash quand même!) C'est l'intéret de "/usr/local": tout ce qui est situé en desous de ce dossier est sauvegardé lors des updates DSM

Faut dire que la commande "shutdown" il me semble bien qu'elle n'existait pas avant DSM 5 : Il n'y avait que la commande poweroff dont je n'ai jamais été certain qu'elle fasse vraiment un arrêt "propre" (attente que chaque package se termine par exemple) C'est pourquoi que j'ai toujours préféré l'autre approche. En outre mettre tes taches d’arrêt dans un ou plusieurs scripts dans "/usr/local/etc/rc.d", fera qu'elles seront également exécutée lors d'un arret initialisé via le GUI ou même via le bouton "power" de façade. Ça peut être utile et pratique.

Je faisais référence au script qui éteint le PI Pour éteindre le syno de façon planifiée je conseillerai plutôt la méthode "native": panneau de conf DSM -> matériel et alimentation -> planif alim

faut mettre le script dans le répertoire "/usr/local/etc/rc.d" son nom doit avoir pour suffixe ".sh" son mode doit être 755 tester le premier argument ($1). Au shutdown ce dernier vaudra "stop" ("start" lors du boot). (dans un "case $1 in ..." par exemple) Par contre le shell "bash" n'est pas disponible sur syno, utiliser "ash" (ligne shebang à utiliser: "#!/bin/ash") à la place.

Les étapes 5 à 7 peuvent se résumer à éditer directement ~root/.ssh/authorized_keys sur le PI et copier/coller dans l'éditeur le contenu du fichier .pub (une simple ligne, attention à sa longueur)

Pas sur qu'il y ait exactement ce que tu cherches mais ça vaut le coup d'aller voir: http://www.synology.com/fr-fr/support/develop_tool

Juste une petite précision sur une phrase qui pourrait être insuffisamment claire: Il s'agit bien d'ajouter le *contenu* du fichier ".pub" généré sur le syno au "~root/.ssh/authorized_keys" du PI (ce dernier étant à créer si il n'existe pas déjà.) . Et l'ascii art qui s'affiche lors de la génération peut être oublié.

Pour la localisation du script de shutdown dans "/usr/local/etc/rc.d" c'est nécessaire dans la mesure ou on souhaite qu'il soit exécuté *automatiquement* lors de l’arrêt du Syno. Je ne vois pas comment tu peux faire autrement. Mais, on va essayer traiter un seul problème à la fois si tu veux bien. Je viens de refaire la manip et j'ai bien deux fichiers dont le ".pub": fserv> ls ~/.ssh/pi* /root/.ssh/pi-shutdown /root/.ssh/pi-shutdown.pubcomprend pas que ca ne marche pas chez toi avec la même version de DSM Tu me confirme qu'a la suite de la commande "ssh-keygen" tu n'as que le 1er fichier (sans suffixe .pub) dans le répertoire ".ssh" ? PS: j'ai bien précisé dans chaque cas si les commandes sont à faire ou les fichiers à modifier soit sur le syno soit sur le PI.

Vue que ma suggestion d'utiliser "shutdown" à été recalée pour la raison "coupe XBMC brutalement", m'étonnerait que tu ais plus de succès avec ta proposition d'employer la commande init.

Suffit de mettre dans le dossier à protéger un fichier nommé ".htaccess" avec le contenu suivant: order deny,allow deny from all Allow from 192.168.0.0/24 "192.168.0.0/24" est une adresse de réseau et est a adapter en fonction du ce qui est utilisé par ton réseau local. Ca autorisera les connexions à partir de ce dernier uniquement.

pas besoin de mapper, suffit de créer un raccourci sur le bureau (ou ailleurs)

Normalement, même si Windows ne "voit" pas un partage réseau (le protocole de browsing, hérité de Lan Manager, est hélas particulièrement peu performant. Ça fait longtemps qu'on ne l'utilise plus en entreprise par exemple) il est toujours possible d'accéder aux dossiers partagés en utilisant directement une syntaxe de chemins de type UNC: ("nom_ou_ip_du_NAS" ou "nom_ou_ip_du_NASnom_de_partage") Ca ne fait pas l'affaire?

(surprenant qu'une commande d'arret XMBC arrete également Linux, mais tu dois mieux connaitre cette machine que moi) Sinon, vu l'absence de remarques sur le reste de mon post, on peut conclure que les réponses conviennent? **EDIT** Suis allé parcourir le wiki de XMBC Et j'ai bien l'impression que la bonne commande est plus "XBMC.powerdown" que "XBMC.quit".

Plusieurs choses: Je n'ai pas manipulé de Raspberry mais je serais surpris que ce soit une commande dans le style de 'xbmc-send --action="XBMC.Quit" 'qui fasse un shutdown du bidule ("shutdown -h now" me semblerait plus approprié) Le switch "-c" de la commande "ssh" sert à forcer le type de cryptage utilisé lors de la session et requiert un argument. La présence de ce switch dans ta commande est fort probablement une erreur de ta part. une fois trouvée la bonne commande et l'avoir incluse dans un script de shutdown (je suppose que tu as prévu de faire ça dans "/usr/local/etc/rc.d") penser à insérer un délai pour laisser le temps au PI de s'arréter effectivement. pour ne pas avoir à saisir de mot de passe faut passer par une authentification par clé: génération d'une paire de clé privée/publique dédiée au shutdown du PU, sans passphrase, sur le syno (commande "ssh-keygen -f <chemin_fichiee_clé>"). Pour le chemin, ~root/.ssh est l'endroit approprié (par sécurité il est requis que seul root ait accès à ce répertoire en écriture mais autant verrouiller la lecture aussi). La commande ressemblerai alors à: ssh-keygen -f ~/.ssh/pi-shutdown ajouter la clé publique générée ci dessus (contenue dans ~/.ssh/pi-shutdown.pub) dans le fichier ~root/.ssh/authorized_keys du PI (on peux même forcer ici la commande "shutdown" en préfixant la ligne avec "command=/bin/shutdown -h now" comme expliqué ici) donner le chemin de la clé privée en argument de la commande ssh sur le syno (ssh -i ~/.ssh/pi-shutdown) Remarque complémentaire: un NAS est optimisé pour rester en fonction 24/24. Le redémarrer une fois par jour n'est pas optimal pour la durée de vie des composants (et surtout des disques).

Et alors bonjour le trou de sécurité! En faisant ça, *toutes* les commandes liées à busybox vont s'exécuter avec les privileges root. Etant tombé sur ce "conseil" dans le forum US j'avais déjà failli tomber de ma chaise en le lisant (ici: http://forum.synology.com/enu/viewtopic.php?f=90&t=49585#p200510)

Le sujet XPenology risque d'être un peu sensible sur ce forum "semi officiel" (car référencé sur le site constructeur) Beaucoup font une confusion, s'appuyant sur la présence d'une majorité de code sous GPL dans DSM et en déduisent que l'intégralité de DSM est libre. Mais ce n'est pas vraiment le cas. Si on lit bien le contenu de la licence d'utilisation des logiciels fournis par Synology pour ses matériels: (http://www.synology.com/fr-fr/company/terms_conditions#tabs_terms_EULA), Il est simplement indiqué que le logiciel *comporte* des composants GPL mais en aucune manière que l'intégralité du logiciel est dans ce cas. En outre, l'utilisation du logiciel sur un autre matériel que celui de la marque Syno ne me semble pas autorisé: "Synology vous octroie une licence personnelle limitée, non exclusive et non transférable pour installer, exécuter et utiliser une copie du Logiciel sur le Produit seulement dans le cadre de votre autorisation d'utiliser le Produit." NB: pour être honnête je dois avouer avoir utilisé personnellement ce "repackaging" de DSM, mais uniquement sur une machine virtuelle et exclusivement à titre de tests. Le cas de l'utilisation sur un matériel tiers comme machine principale me semble déjà plus discutable.

Pas besoin de modo pour ça, ça peut-se faire en "self service" (sur ses propres sujets): et eventuellement reposter la question dans la bonne section

C'est pourtant le *contraire* que je soutiens: on constate que c'est mieux *maintenant*, sur les gammes TV Sony récentes (quasiment tous les formats sont supportés par mon modèle 2013) que dans le passé (écrire "*acheter* une TV de ce prix" laisse penser que le contexte est l'achat d'une TV *neuve*, modèle 2014 donc) Bon, allez, je préfère me désabonner du fil. Apparemment tu tiens à avoir absolument le dernier mot, je te laisse bien volontiers cette satisfaction, inutile de me prendre le chou la dessus.

Sans soute mais le message auquel je répondais sonnait quand même plutôt comme un conseil à ceux qui étaient en phase de réflexion sur un achat *à venir* d'un téléviseur et qui, dans ce contexte, pouvaient hésiter entre Sony, LG et Samsung.

Le problème ne se pose pas avec les gammes Sony récentes (>= 2013 et peut-être 2012) et on peut trouver des modèles intéressants dans la gamme 2014 (exemple: http://www.lesnumeriques.com/tv-televiseur/sony-kdl-50w805-kdl-50w805b-p19373/test.html)

Je ne sais pas si tu as remarqué mais le thème de cette section ("modifications matériel") s'applique aux modifications/réparations sur les modèles de la gamme Synology (à laquelle l'essentiel du site est consacré d'ailleurs). Et là tu débarques comme un cheveu sur la soupe, sans même passer par la case "présentation", demandant de l'aide sur un problème pointu sur une plate-forme exotique que bien peu doivent connaitre Si tu veux mon avis, autant aller poser ta question sur doctissimo: ne serais pas surpris que l'espoir d'y trouver une réponse soient quasiment du même ordre

(NB: on remarquera que chaque fois que je donne une info je donne la source ...) Une dernière et j’arrête (en attendant une éventuelle réponse sur homecinema) http://forums.whirlpool.net.au/archive/1435499 La suite de la discussion indique bien que les problèmes de compatibilités sont liés au support des *codecs* et pas du *container* PS: ça me désole de me voir ainsi incapable de me faire comprendre, alors qu'il ne s'agit que de logique de base. En effet, pour contredire une affirmation: "les TV de la gamme EX500 ne supportent pas les container .avi" ) un *unique* cas/témoignage est suffisant. Là j'en suis déja à *3*. Inversement, n'être pas parvenu jusqu'ici à lire des .avi sur son exemplaire n'est pas une condition suffisante pour en déduire que ça ne marche *jamais* Personne pour sentir la faille dans le raisonnement? De mon coté je crois que je vais laisser tomber, grosse fatigue là

http://www.lcd-compare.com/televiseur-SONKDL40EX500-SONY-KDL-40EX500.htm Qu'ajouter de plus? On va peut-être attendre la réponse sur le forum homecinema si ça ne dérange personne.. **EDIT** Ce qui ne semble effectivement pas supporté ce sont les DIVX via le réseau (DLNA donc, mais ok en USB) Donc bien entendu, des divx en container .avi ne seront pas lus: A

Mais, dans ce que tu écris, à aucun moment je ne conteste les faits: ce n'est que la conclusion que tu en tire que je pense probablement erronée. Rien n'interdit que ton témoignage et l'autre soient compatibles: lui qui nous dit que 90% des "*.avi" sont lu par son téléviseur et toi de ton coté qui constate qu'aucun ne passe: suffit d'imaginer que tous les .avi que tu as donné à lire à ton Sony utilisaient des codecs videos qu'il ne supporte pas, alors que le membre du forum HomeCinema utilise d'autre codecs compatibles. En déduisant une généralité d'une expérience personnelle on prend le risque de faire une erreur de logique. La conclusion sur le non support du *container* n'est pas justifiée par les faits décrits.

Si la copie des fichiers est faite pas d'autre moyens que les outils Synology natifs (acces dossiers partagés windows/mac/nfs, filestation, dsfile, ftp ...) , le service d'indexation ne sera pas ou courant qu'il y a nouveau du contenu à réindexer (ou désindexer pour les fichiers supprimés) Dans ce cas faudra utiliser la commande en ligne "synoindex" pour forcer la réindexation des fichiers ou dossiers impactés. **EDIT** Voir ici: