CoolRaoul

L'option "DSM Mobile" de DS Finder lance en fait l'interface Web en mode mobile, c'est *strictement* équivalent (suffit de tester pour s'en convaincre) Et dans les deux cas il est en effet également possible de forcer l'interface "desktop" Mais on conviendra que sur smartphone niveau ergonomie cette dernière est pas confortable. D'ailleurs pour faire l'upgrade du paquet je suis finalement passé par mon navigateur PC, quand-même plus pratique.

La dernière fois c'était "Synocli File Tools", Cette fois c'est "Synocli Network Tools" Mise à jour impossible via DS Mobile. Et ce message dans les notifications : Unable to install "/volume2/@tmp/@synopkg/@download/synocli-net/@SYNOPKG_DOWNLOAD_synocli-net". Ce paquet est publié par un éditeur inconnu. ("publié par un éditeur inconnu." . A quoi je serai tenté de répondre : "en effet, et alors?") Je vais tenter une mise à jour via l'interface Web (en espérant qu'ils ne faille pas systématiquement rebooter pour mettre à jour les paquets tiers) Ça a fonctionné. (Il m'a fallu valider un demande de confirmation avec une clause de non responsabilité). Conclusion : il semble qu'il soit désormais impossible de mettre à jour les paquets "communauté" à partir de DSM Mobile. Ne me semble pas que c'était le cas avant. Je me trompe?

Ci joint un script ("my_sendmail") perl (qui nécessite bien entendu l'installation du paquet correspondant) que j'utilise pour envoyer des mails en ligne de commande. Son mode utilisation est en tête du code. my_sendmail Et si tu préfère quelque chose de plus propre, il y a ça (pas testé) : https://github.com/zehm/sendEmail

La syntaxe "${1:-<valeur_défaut>} permettait de mettre un défaut sauf si spécifié explicitement en $1 En en effet, ça dépend si le fichier est directement copié/généré dans le dossier ou juste déplacé Après le "do" ajouter: [[ $1 == *.epub ]] || continue Quelqu'un va bien te trouver ça,

Tout à fait

A mon avis, le plus light (en termes de ressources en particulier) est de le faire via un script shell. Le pre-requis est d'installer ce package "inotify-tools": Ensuite lancer en tache de fond un script basé sur ce modèle : #!/bin/bash PATH=/bin:/usr/bin:/usr/local/bin WATCHED_DIR=${1:-/var/tmp/watched_dir} # répertoire que j'ai utilisé pour tester # inotifywait --recursive \ --quiet \ --event close_write \ --format "%w%f" \ --monitor $WATCHED_DIR | while read newfile do echo >&2 "received: $newfile" # ici ajouter la commande pour envoyer le fichier "$newfile" par email done Pour la commande email je pense qu'un autre membre du forum saura proposer une façon de faire. En ce qui concerne le lancement automatique du script, je préconise, après l'avoir testé à la main, de le faire au boot, via le gestionnaire de taches (task manager) de cette façon :

apres reboot ca me dit "update available" Je vais tenter Bon ca s'est débloqué, fausse alerte

Je m'aperçois dans le package center que ce paquet reste bloqué sur "updating..." Je n'ai pas la moindre idée pour me sortir de cette situation. Si quelqu'un à une idée miracle.

Je peux confirmer en connaissance de cause

Ca doit poser problème pour le renouvellement auto de(s) certifcat(s) let's encrypt non?

Mais qui a suggéré de se connecter en http? On a simplement dit que laisser le port non chiffré ouvert était sans danger du moment qu'on ne l'utilise pas, rien de plus. (et donc, bien sur, que de ce fait c'est inutile de l'ouvrir à l'extérieur on est d'accord la dessus) Cela dit, je répète, aucun danger à le laisser ouvert: vu qu'on ne l'utilise pas il n'y aura rien à capturer puisque aucun traffic.

Sur le port en clair ça sera les pseudo et pass que le "hacker" utilise lors de ses essais pour tenter de se connecter, quelle importance? Je suis d'accord que fermer le port non SSL est légitime, mais simplement parce que ça ne sert à rien de le laisser ouvert, pas pour raison de sécurité.

Il ne pourra rien faire de plus via le port 5000 que via le port 5001. Juste que le traffic entre le "hacker" et le NAS ne sera pas chiffré, pas de protection supplémentaire pour autant. Mais bien entendu, pas la peine de l'ouvrir à l'extérieur non plus, le port SSL suffit.

Pour forcer l'acces en HTTPS à l'interface d'administration (5000/5001) il y ceci aussi: Toute tentative de connexion sur le port 5000 est automatiquement reroutée sur le port SSL. Sinon il ne faut pas oublier que laisser l'acces HTTP ouvert n'est potentiellement risqué que pour les éventueles utilisateurs externes qui l'utilisent pour se connecter. Ca ne rend pas le NAS plus vulnérable, qu'il écoute activement sur ce port n'est pas un risque "en soi".

Le futur spammeur qui teste la réactivité des modos en mode furtif je dirai.

WTF?

Oui d'autres l'ont signalé aussi: https://www.reddit.com/r/synology/comments/p2booi/dsm7_automatic_configuration_backup_failing/

Pareil:

Pareil, et j'en ai parlé (avec la solution) un peu plus haut (en oubliant de spécifier que c'était sur un 213J aussi mais c'est dans ma signature)

Pour tester c'est trop tard par contre: https://dev.freebox.fr/bugs/task/35342 Ouverte par Marios Makassikis (mmakassikis) - 03/08/2021 UPDATE 04/08 14h35 Les inscriptions sont closes. A quelques minutes pres 😕

Ah oui c'est exact, j'avais mal interprété la phrase "le paquet est mis à disposition par Synology" dans l'article

Pour info ça ne fonctionnait pas pour moi. J'ai désinstallé le paquet officiel, remplacé par celui téléchargé ici: https://github.com/tailscale/tailscale-synology/releases et là plus de pb.

Apparemment ca vient juste de sortir: J'ai trouvé l'info ici: https://www.cachem.fr/synology-tailscale-wireguard-vpn/

Un coup de synoindex en ligne de commande devrait pouvoir régler ça: https://www.nas-forum.com/forum/topic/58011-r%C3%A9solu-re-indexation-automatique/?do=findComment&comment=1319338283

Apparemment c'est le même lsof "light" qu'on trouve dans BusyBox