CoolRaoul

Si ça peut être utile, il existe une commande de manipulation et de listage des acl: "synoacltool" (dans "/usr/syno/bin/") L'invoquer avec l'argument "-h" pour avoir l'aide

Ah oui, tu as raison. Je ne m'étais pas aperçu (et je découvre avec toi) que l'option ACLs sur les nouveaux dossiers partagés n'était pas une simple option par défaut mais en réalité la seule possible. "Convertir en windows ACL" ne s'applique qu'aux dossiers créés sans ACL avant DSM 5 (ou 5.1 à vétifier)

Ce n'est en effet pas réversible. Une fois qu'un dossier partagé à été migré où créé pour utiliser les ACLs c'est définitif.

Le comportement que tu constates est du a l'utilisation des ACLs pour le partage. Ça prend le pas sur les droits traditionnels Unix ("UGO"). Me semble que l'utilisation des ACLs, bien que toujours optionnelle, est devenu le défaut pour tous les nouveau répertoires partagés depuis DSM5

Sans trop connaitre python, la condition "if not sys.stdin.isatty():" montre bien un comportement différent de ce script si l'entrée standard est un terminal (ce qui est le cas en interactif) ou pas (cas du cron) Et justement; dans le cas ou stdin n'est pas un terminal il boucle sur un "for line in sys.stdin.readlines():" qui va se terminer immédiatement puisque l'entrée est "/dev/null"

**EDIT** et (sans doute) <HS> Je vois dans le script un: cd /usr/syno/bin/check/ qui m’inquiète peu. Il n'y a pas de répertoire "check" dans "/usr/syno/bin" sous DSM. Mettre des outils perso dans des répertoires systèmes non prévus à cet effet est un peu casse-gueule. Déjà à la moindre update DSM pas trop mineure, ce dossier "check" sera purement et simplement effacé. Le seul dossier système à peu prés préservé lors des mise à jour de firmware est "/usr/local" (et tout ce qui est en dessous). Mieux vaut travailler là (ou dans un dossier partagé; /volume<n>/...) La ça devient du chinois pour mois, attendons un spécialiste

La 3eme ligne du log montre bien que le script python "send_nrdp.py" est bien invoqué Qu'il n'ait aucune action apparente est donc un problème lié à ce dernier et pas au shell (doit y avoir une différence de contexte cron VS interactif qui en change le comportement) Faudrait mieux connaitre ce que fait ce send_nrdp.py et comment en rendre l'exécution plus "verbeuse" Problème: python, je suis croyant mais pas (encore) pratiquant (suis de la vielle école: perl). Faudra attendre qu'un spécialiste passe par là.

Pas possible qu'il soit vide si, comme je l'ai conseillé, tu as bien ajouté la commande "set -x" en début du script.. (si tu pouvais à l'occasion nous montrer les 4 premières du lignes du script, histoire de se faire une idée).

Elle est bien biscornue la derniere version du script... D'abord, pourquoi s'emm*** à ajouter ">>/tmp/out.txt 2>&1" derriere *chaque* ligne alors qu'avec mon approche avec un "exec" en début,la redirection est effectuée une bonne fois pour toute? Ensuite, la variable "senddata" ne risque pas de contenir quoi que ce soit dans la mesure ou ta redirection est à l’intérieur des backquotes. Enfin, de toutes façon, c'est syntaxiquement incorrect car je ne vois pas la backquote fermante correspondant à celle suivant "sendata=" Repars plutot de la version de script de ton post #3 en y ajoutant "set -x" en début, et regarde ce que contient "/tmp/monjob.log" après exécution.

Probème connu et souvent rencontré: Il faut savoir qu'un script lancé par la crontab ou le planificateur de taches (ce qui revient au même) se retrouve avec l'environnement par défaut, car ni "/etc/profile" ni "/root/.profile" ne sont exécutés au préalable dans ce cas. Ce qui peut expliquer un comportement différent qu'en interactif ("manuellement") Plus précisément il est impératif si on désire avoir accès à des commandes situées en dehors des dossiers systèmes par défaut, d'au moins y définir le PATH et éventuellement autres variables d'environnement potentiellement requises En outre, pour ne pas être aveugle, et disposer d'une trace d'exécution je préconise que le début du script ressemble à ceci: #! /bin/ash [ -t 0 ] || exec >/tmp/monjob.log 2>&1 # "monjob" ou autre, sans importance Si le script ne semble pas fonctionner en cron, le contenu de "/tmp/monjob.log" devrait sans aucun doute donner une indication sur la cause. La condition "[ -t 0 ]" aura pour effet que la redirection error/output vers le log ne soit effective qu'en mode détaché.

On peut dire ça: les Livebox (contrairement aux Freebox) n'implémentent pas la fonctionnalité "proxy wake on lan" qui est requise pour ça.

J'essaierai plutôt ceci: /usr/syno/sbin/synoservicecfg --restart nfsd

Confirmation: Faille Ghost : Synology prépare un correctif pour son DSM Et comme je le subodorais: "le fabricant indique que « l'impact de cette vulnérabilité est minime »"

Permettez moi de le répéter de nouveau: faut savoir *relativiser*! Je vous engage à lire le paragraphe "Mitigating factors" ici: http://www.openwall.com/lists/oss-security/2015/01/27/9 La faille serait potentiellement exploitable dans tout petit nombre de cas, le groupe qui la découverte à réussi a mettre en place un démonstrateur basé sur un serveur de mail (exim) pas universellement utilisé. Le risque que les APIs incriminées soit utilisées par les outils et les packages natifs DSM est très faible (et inutile de sortir l'exemple de perl ou python, gethostbyname/gethostbyaddr bien que disponible via ces langages, ne seront invoquées qui si un script le fait explicitement) car non compatible IPV6: "The gethostbyname*() functions are obsolete; with the advent of IPv6, recent applications use getaddrinfo() instead" A lire aussi ce post de Qualys qui a découvrert la faille: "Here is a list of potential targets that we investigated (they all callgethostbyname, one way or another), but to the best of our knowledge, the buffer overflow cannot be triggered in any of them:"

Il n'y a pas raison de paniquer de trop. Cette faille est située dans le code des fonctions gethostbyname et gethostbyaddr qui ne sont pas compatibles IPV6. Sachant que tous les services DSM sont compatibles IPV6 il est relativement peu probable que ces fonctions soit effectivement employées. Mais le patch va très certainement arriver sous peu malgré tout.

Autre méthode plus simple avec Chrome si on ne veut pas s’embêter à importer un certificat dans le magasin système. Fonctionne également avec Chrome Android (et sur les autres systèmes énumérés). Note: Il faudra quand même accepter initialement la connexion "insecure" mais l'opération n'aura pas à être répétée avant un délai configurable pouvant aller jusqu'à trois mois (ce qui n'est pas la mer à boire à mon avis) Dans la barre d’adresse saisir chrome://flags/#remember-cert-error-decisions et aller modifier l'option ci dessous:

Oui c'est long (mais c'est plus le *nombre* de fichiers que leur taille cumulée qui est déterminant: 10Gb composés d'une dizaine de fichiers videos seront indexés bien plus vite que le même espace occupé par quelques milliers de mp3.) et c'est essentiellement ça qui consomme des ressources. Il y a aussi la génération des vignettes (pour les images et les videos) qui consomme également/ Les packages dont tu peux éventuellement différer l'activation (pour lisser la charge) sont VideoStation et PhotoStation. Les autres autres peuvent être activés sans impact notable à mon avis.

Faut laisser l'indexation initiale aller à son terme, ensuite ça se calmera tout seul.

Juste pour ajouter un élément au dossier: bien que chez moi "synoservicectl --stop sshd" arrète bien le daemon ssh (le port 22 est libéré), le statut du service est quand même "stop/waiting". Donc mon interprétation était fausse. A part ça, serait pas inutile de jeter un oeil au contenu de "/var/log/upstart/ssh-shell.log", ça pourrait donner une idée de ce qui coince.

Ce qui collerait bien avec le statut "stop/waiting" (waiting = en attente que toutes les connexions SSH soient effectivement fermées)

Je ne comprend pas comment mettre des IP fictives ainsi qu'un 1 au lieu d'un 0 peut rendre les choses plus simples. En outre, j'espère qu'on comprendra que s'abstenir d'indiquer que la règle iptables comportait des restrictions de ports (toujours dans un "soucis de simplification" je suppose ?) n'a pas non plus contribué à rapidement trouver la cause du problème.

Oups, bien vu: j'avais même pas tilté sur le 198.1.1.* que j'autocorrigais à la volée en 192.168.1.*!

Je ne comprend pas pourquoi la règle initiale (192.1.1.1/24 ALLOW) ne suffisait pas. Elle autorise toutes les IPs du LAN, celle de la box faisant partie du même subnet ne devrait pas être bloquée non ?

Je confirme: chez moi, avec l'antenne face à une baie vitrée en vue directe de l’émetteur, le coup du signal *effectivement* faible, franchement je le sens pas.

Plutôt qu'un problème de firewall, je pencherai sur le fait que ta box ne gère pas le loopback (rebouclage automatique en interne de "chez_moi.fr")