CoolRaoul

De plus bon nombre de paquets viennent de voir simultanément arriver une mise à jour en ligne. Si tout le monde se précipite pour les télécharger ça peut ajouter à la charge des serveurs de téléchargement.

Et puis c'est une volumétrie minime. Alors... C'est dans l'onglet "Applications"

(Ah moins qu'on ne parle pas de la même chose) l'option est toujours disponible pourtant chez moi (elle est juste devenue obligatoire pour chaque job de sauvegarde): Si tu veux faire un job de sauvegarde dédié à la sauvegarde de configuration, suffit de ne rien sélectionner dans les onglets "Dossiers" et "Application" de sa définition.

Re-test ce matin derrière le proxy: le problème à disparu! Flemme de chercher à comprendre

C'est le cas mais le problème vient juste d’apparaître alors que le proxy je l'ai depuis toujours. En outre, le test avec Firefox je l'ai fait derrière le même proxy.

Testé à la maison, aucun problème même après avoir mis Chrome à jour Le problème est isolé donc, c'est déjà ça.

Yep, pas d'amélioration. Mais je ne suis pas chez moi là, faudra que je teste ce soir à domicile.

Je viens de m'apercevoir (ça m'était déja arrivé dans le passé) que mon interface DSM présente pleins de dysfonctionnements lorsque j'y suis connecté via le navigateur Chrome: certains éléments d'interface plus cliquables zones sensibles décalées plus de menus contextuels dans filestation (on se retrouve les menus "standard" du navigateur et je n'ai peut-être pas tout découvert Aucun problème avec Firefox par contre. Je ne sais pas si c'est suite à la dernière mise à jour de DSM ou celle de Chrome (l'update de ma version date de ce matin: 41.0.2272.76 m (64-bit)) D'autres ont-ils rencontré se genre de difficulté? Si oui, y aurait-il un volontaire pour ouvrir un ticket au support Syno (car pour ma part je me fais en général jeter à cause d'un point de montage "/opt" dont la détection a pour résultat de me voir demander de faire un reset usine de mon NAS si je veux aller plus avant)

Winscp supporte (comme son nom l'indique) le protocole "SCP", qui, avec DSM, permet d'accéder à *tous* les file system (y compris "/" donc) Attention d'être très prudent: une erreur de manip est vite arrivée. Filezilla utilise SFTP, et sous DSM, ce dernier ne permet d'accéder qu'aux répertoires partagés.

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: