CoolRaoul

complété et corrigé (mauvaise branche du "if" pour VPN actif): #!/bin/ash PATH=/bin:/usr/bin:/sbin:/usr/sbin if ifconfig | grep -q "^tun0" ; then echo >&2 "VPN UP" else echo >&2 "VPN Down" ta_commande_ici fi

*Toujours* spécifier le PATH dans un script, sous peine de dépendre du contenu de cette variable au moment de l'appel, chose qu'on ne maîtrise pas toujours (en cron/gestionnaire de taches par exemple). Si tu ne fait pas ça, suivant le contexte de son exécution il y a des chances qu'il ne parvienne pas à localiser "ifconfig" (qui est dans /usr/bin) et d'afficherle message d'erreur: ifconfig: not found Nullement: la déclaration de PATH *dans* le script sert au shell à localiser les commandes que contient ce dernier et pas à localiser le script lui même (que tu peux toujours invoquer en spécifiant son chemin complet)

Ca dépend de l'application! Par exemple, depuis DSM5, synoservicecfg (/usr/syno/sbin/synoservicecfg) est utilisé pour la majorité des service natifs. "synoservicecfg --list" pour en afficher la liste. Ensuite chaque appli est différentes Pour les packages c'est souvent "/var/packages/<nom_du_package>/scripts/start-stop-status" à invoquer avec le parametre "stop" ou "start"

C'est quand même surprenant ce comportement (si il est avéré, faudrait savoir exactement sur quoi s'appuie l'affirmation "on ne peut plus télécharger des mises à jour": quel est le message d'erreur et où apparaît-il?). Le firewall filtre uniquement les connexions *entrantes* alors que le téléchargement de mises à jour s'appuie sur des connexions *sortantes* et n'a aucune raison d'être impacté par les règles de filtrage. Je ne suis pas sur que de mettre un grand nombre de règles de type "refuser" soit la bonne approche. A mon avis, mieux vaut configurer le firewall pour tout bloquer par défaut, comme cela: et de n'ajouter que des règles de type "accepter".

Si la box gérait le loopback, toute connexion a partir du LAN vers l'IP externe serait automatiquement redirigée (et de façon transparente) sur le NAS. Vu que ce qui est décrit montre que ce n'est pas le cas, la conclusion est que le loopback n'est pas géré. Autrement dit: A: "box gere le loobback" B: "connexion LAN vers IP externe fonctionne" Sachant que: A => B Vu que l'on constate ¬B on conclue ¬A

En effet les détails donnés montrent que le loopback n'est pas implémenté par le routeur. Mais, vu que la connexion VPN marche de l'extérieur ("j'arrive à me connecter au VPN via ma tablette sous Android") , et c'est justement ce qu'on demande, que le "ping" ne marche pas sur l'IP externe quand on est sur le LAN, en quoi serait-ce un problème (et surtout vis à vis du fonctionnement du serveur VPN)?

Et quel est le problème exactement? (je ne vois rien d'anormal dans le comportement décrit).

Le script pourrait ressembler à ceci: #!/bin/ash PATH=/bin:/usr/bin:/sbin:/usr/sbin if ifconfig | grep -q "^tun0" ; then <ta commande ici> fi Par contre je suis tres perplexe sur la commande sudo service transmission-daemon start|stop D'une part il n'y pas de sudo sur DSM, et dans tous les cas autant exécuter directement le script sous le compte "root" Ensuite je ne sais pas ce qu'est ce "transmission" mais ça m'étonnerait fort que son arrêt/démarrage se fasse par la commande "service" (cette dernière n'existant pas non plus sous DSM). Tu es bien sur de la fiabilité des sources de tes informations? Petite remarque HS en passant: il me semble deviner que tu utilise le client VPN, non pas pour sécuriser des transferts inter site, mais pour des raison d'"anonymité". Au cas ou tu l'ignorerai sache que le firewall DSM ne gère pas l'interface VPN et que par conséquent, une fois la connexion établie, ton appareil se retrouve "a poil" sur internet: tous ses ports deviennent accessible (même si ils sont filtrés sur ta box). Attention à bien le sécuriser et surtout d'observer régulièrement le moindre comportement suspect. Il n'y a pas de bash sur DSM

Tiens, au contraire, alors que je le désactive pour NAS-Forum, je ne le fais pas pour FreeNews: à partir du moment ou Free intègre en oeuvre un adblocker sur les freebox et que Freenews n'y voit rien à redire (comme tout ce qui vient de Free en général) je trouve tout à fait cohérent de mon coté de ne pas mettre FreeNews en whitelist adblock.

Filestation sait "monter" un dossier partagé distant pour peu qu'il supporte le protocole CIFS. Ça se fait par le menu "outils->monter le dossier distant". Par contre je ne suis pas sur que le transfert continuera bien en tache de fond, une fois le navigateur utilisé pour se connecter à filestation fermé (ce qui t'obligerait à laisser quand même le PC allumé). A tester donc

Mai aussi ai mis le site en white list et pourtant la bannière est bien la ce matin. Ca me le faisait parfois du boulot, mais la-bas on a un proxy filtrant donc je mettais ca sur le compte de ce dernier. La je suis à mon domicile. Par contre j'ai flash désactivé On ne va pas nous obliger à installer flash, non? J'ai aussi la désactivation des cookies tiers, mais faudrait pas trop pousser non plus

En effet: je confirme que la V5 gère le loopback (sait pas pour la V4)

Il est probablement nécessaire de modéliser au préalable ce que signifie ce "en même temps" dans les faits. Il n'est pas certain que les utilisateurs connectés passent leur temps a faire du transfert de données à plein régime mais restent simplement connectés avec une activité modérée, ce qui peut changer la donne (et alors le facteur dimensionnant sera plus la mémoire que le débit réseau).

Depuis la dernière update de DSM, Synology a (enfin) intégré le support de la localisation pour les commandes en mode terminal. Plus besoin de fserv> locale -a C cs_CZ.utf8 da_DK.utf8 de_DE.utf8 en_US.utf8 es_ES.utf8 fr_FR.utf8 hu_HU.utf8 it_IT.utf8 ja_JP.utf8 ko_KR.utf8 nb_NO.utf8 nl_NL.utf8 pl_PL.utf8 POSIX pt_BR.utf8 pt_PT.utf8 ru_RU.utf8 sv_SE.utf8 tr_TR.utf8 zh_CN.utf8 zh_TW.utf8

C'est tout a fait exact mais je me suis volontairement limité au "find" du busybox intégré à DSM qui ne supporte pas cette fonctionnalité: fserv> find . -type f -exec ls -ld {} "+" find: -exec CMD must end by ';'

"find -exec "va "forker" un sous process "rm" pour *chaque* fichier trouvé. Avec la redirection vers "xargs <commande>", ce dernier (xargs) sait créer un minimum de process en invoquant la commande avec plusieurs noms de fichiers en arguments (en tenant comte de la longueur maximum de commande sur le système hote). au lieu d'avoir généré les process: rm <fichier-1> rm <fichier-2> ... rm <fichier-N> (N process donc) on va avoir idéalement: rm <fichier1> <fichier2> ... <fichierN> Un seul process tant que longeur totale des noms des N fichiers n'est pas trop importante, sinon deux, etc ... Bon, je conviens que ça peut être de la sodomisation de diptères mais, j'aime bien chercher la petite bête pour optimiser.

Oui, si on lui ajoute l'option "-r" (récursif). "rmdir" n'efface que les répertoires *vides*.

Bon, si il s'agit de montrer sa science, alors allons-y ... (pas taper hein, j'ai juste du temps à perdre ce soir!) "find ... -exec" n'est pas toujours très optimal si les fichiers trouvés sont nombreux. Je proposerai plutôt: find . -deph -name "FILE-TO-FIND" -print0 | xargs -0 rm -rf "-depth" pour éviter des erreurs dans le cas de répertoires imbriqués qui matchent tous deux la condition (en fait ça marche quand même sans c'est plus propre ainsi) le "-print0" pour find et le "-0" de xargs c'est au cas ou certains fichiers ont des espaces dans leurs noms.

Suffit de cliquer sur la loupe

Utiliser la fonction de recherche avancée de filestation avec comme emplacement tous les sous dossiers: de "photo" et type de fichier "tous les dossiers" ensuite sélectionner tous les items de la liste (clic sur le premier et shift-clic sur le dernier) puis "action->supprimer"

Je me suis lancé aussi et pas de problème non plus. Si tu n'est pas admin sur ton PC de boulot, y installer cloudstation risque déjà d'être sportif..

Exactement (au performances prés quand même).

Dès que le tunnel VPN est établi entre l'appareil Androïd et le NAS, on peut aussi accéder à ce dernier en utilisant son IP interne (habituellement en 198.168.N.P). De plus les acces utilisant cette IP ne sont pas filtrés le firewall du NAS et les ports n'auront pas besoin d'être redirigés dans la box. Ainsi, on peut se contenter d'ouvrir uniquement le (les) port(s) du protocole VPN dans le routeur et malgrès tout accéder avec son smartphone à tous les services du NAS (y compris SMB)

en effet **EDIT** petite astuce en prime, tel quel le script va *toujours* écrire dans le log. Si tu veux que la sortie continue à aller à l'écran lorsque tu l'exécute "à la main" remplace: exec >> /tmp/ftp_mirror.log 2>&1 par [ -t 0 ] || exec >> /tmp/ftp_mirror.log 2>&1 Le test préalable ("-t 0") à pour effet que la redirection ("exec >>") soit effectuée *uniquement* lorsque l'entrée standard n'est pas un terminal (ce qui est justement le cas en cron mais pas en ligne de commande).

en mettant la ligne "exec" que j'ai donnée dans le script (en début)