Audio

Bonjour @Superthx et @aurelp J'ai refait un tour sur mes ennuis dans DSM et SRM avec le script modifié par @aurelp . Après essais j'ai compris que j'avais déjà le problème avec le script original de @Superthx mis en place en octobre 2025. Les "erreurs" observées dans les logs n'en étaient pas mais simplement le traitement des IPs invalides et des doublons. En fait je me retrouvais parfois avec une "Liste des blocages" vide que ce soit sur DSM ou SRM et je ne comprenais pas pourquoi. C'était dû à la date d'expiration du blocage (basiquement 2h + 1mn dans le script dont la variable Freq est réglée à1) alors que je ne relançait le script que toutes les 12 heures. Fatalement selon l'heure à laquelle je consultais la Liste de blocages je pouvais tomber sur une liste vide (expiration du blocage de toutes les IPs en attente de relance du script). En réglant Freq=12, c'est rentré dans l'ordre. Merci à tous les 2 et à tous les contributeurs initiaux depuis le début de ce sujet et à ceux qui ont pris du temps par la suite pour peaufiner ce scripts dont @PPJP et @bruno78 . Cordialement Audio

Bonjour @aurelp Merci pour ta réponse. J'ai testé le script sans aucune modification dans la version que tu as postée le 11 avril 2026, celle avec l'ajout des listes Firehol etc. C'est cette version qui après quelques jours d'exécution (2 fois par jour) a généré le log très long et le message de DSM disant que la liste des IP bannies étaient trop longue. Je suis alors revenu à la version précédente du script de @Superthx qui fonctionne très bien à la fois sous DSM et SRM. Toutefois en parcourant de nouveau ce sujet du forum j'ai effectué une vérification de DSM sur la sécurité et le blocage automatique: la case à cocher "Activer l'expiration des blocages" n'était pas cochée. Je l'ai cochée et j'ai mis 30 jours pour le délai de déblocage. Je vais refaire un essai avec ta version du script 11 avril 2026 sous DSM.

Bonjour et merci à @aurelp pour sa nouvelle version de autoblocksynology.sh J'utilisais depuis octobre 2025 le script autoblocksynlogy.sh avec juste les sources https://lists.blocklist.de/lists/all.txt et https://feodotracker.abuse.ch/downloads/ipblocklist_aggressive.txt à la fois sur SRM (routeur RT 2600AC) et DSM (NAS DS 920+). J'ai donc essayé la nouvelle version ajoutant d'autres sources dont Firehol. J'ai juste remplacé à la fois sur SRM et DSM le fichier script autoblocksynology.sh en ayant soin de redonner les droits sur le fichier (chmod 755). Ca n'a jamais fonctionné sur SRM mais ça marchait sur DSM pendant plusieurs jours jusqu'à ce que mon NAS m'envoie un petit message disant que la liste des IPs bloquées était trop longue. En fait je ne sais pas combien DSM accepte d'IPs bloquées au maximum. A côté de ce message d'avertissement le log de la dernière cession du script autoblocksynology.sh donnait: ######################### Le planificateur de tâches a terminé une tâche planifiée. Tâche : IP_BLOCK Heure de début : Wed, 22 Apr 2026 04:00:01 +0200 Heure d'arrêt : Wed, 22 Apr 2026 04:02:09 +0200 État actuel : 0 (Normal) Sortie/erreur standard : Demarrage du script autoblocksynology.sh v0.1.0: Wed Apr 22 04:00:01 CEST 2026 0 IP téléchargée sur filtreperso.txt 22768 IP téléchargées sur https://lists.blocklist.de/lists/all.txt 7607 IP téléchargées sur https://feodotracker.abuse.ch/downloads/ipblocklist_aggressive.txt 7 IP téléchargées sur https://rules.emergingthreats.net/blockrules/compromised-ips.txt 15029 IP téléchargées sur https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level2.netset 14346 IP téléchargées sur https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level3.netset BASH=/bin/sh BASHOPTS=cmdhist:complete_fullquote:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=([0]="313" [1]="357" [2]="0") BASH_SOURCE=([0]="/volume1/Scripts/autoblocksynology.sh" [1]="/volume1/Scripts/autoblocksynology.sh" [2]="/volume1/Scripts/autoblocksynology.sh") BASH_VERSINFO=([0]="4" [1]="4" [2]="23" [3]="1" [4]="release" [5]="x86_64-pc-linux-gnu") BASH_VERSION='4.4.23(1)-release' Choix_Blocklist_de=all Choix_Emergingthreats=compromised-ips Choix_Feodotracker=ipblocklist_aggressive Choix_Firehol_lev2=firehol_level2.netset Choix_Firehol_lev3=firehol_level3.netset DIRSTACK=() EUID=0 FUNCNAME=([0]="maj_ipstd" [1]="insertion_nouvelles_ip" [2]="main") File_Ano=anoip.txt Filtre_Perso=filtreperso.txt Freq=1 GROUPS=() HOME=/root HOSTNAME=NOMDUNAS HOSTTYPE=x86_64 IFS=' ' LOGNAME=root Liste_Url='https://lists.blocklist.de/lists/ https://feodotracker.abuse.ch/downloads/ https://rules.emergingthreats.net/blockrules/ https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/' MACHTYPE=x86_64-pc-linux-gnu MAILTO= OLDPWD=/root OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin PIPESTATUS=([0]="1") POSIXLY_CORRECT=y PPID=8451 PS4='+ ' PWD=/volume1/Scripts SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments:posix SHLVL=3 TERM=dumb Trace_Ano=1 TypeShell=bash UID=0 USER=root Version=v0.1.0 _= absent=::::: block_off=1776830461 blocks= chx=firehol_level3.netset db=/etc/synoautoblock.db dirtmp=/tmp/autoblock_synology fil=https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/firehol_level3.netset host=raw.githubusercontent.com info=1 ip='<html>' ip6='<html>' ipstd= marge=60 nb=14346 nb_ip=54331 nb_new=59757 nb_old=59757 newip='1.0.164.165 # [......] [Je vous épargne la liste des 54324 IPs] au total de 1.0.164.165 à 99.92.204.98 99.92.204.98 <body> <center><h1>504 Gateway Time-out</h1></center> <head><title>504 Gateway Time-out</title></head> <html>' pwd_init=/root rempl=:0:0:0:0:0 sep=:::: start=1776823201 tmp1=/tmp/autoblock_synology/temp1 url=https://raw.githubusercontent.com/firehol/blocklist-ipsets/master/ /tmp/autoblock_synology/temp1:54331: INSERT failed: UNIQUE constraint failed: Tmp.IP 54331 IP ont été traitées 1 IP ont vu leur blocage prolongé 54332 nouvelles IP ont été ajoutées 54336 IP seront bloquées suite à cette mise à jour Fin du script exécuté en 2mn 8s ################################ Je ne suis pas assez compétent pour comprendre l'ensemble de ce log et je suis revenu à la version précédente du script qui continue à tourner sans pb sur DSM et SRM. J'aimerais cependant savoir si d'autres utilisateurs ont rencontré les mêmes problèmes sur SRM et DSM avec le script modifié de @aurelp . Cordialement Audio

Pour finir j'ai mis à jour manuellement mes 2 autres NAS DS 920+ et sans mauvaise surprise.

Bonjour @mick45000 D'après le log [Mon Dec 29 21:44:30 CET 2025] Failed to authenticate, no such account or incorrect password] ce que tu as mis comme nom d'utilisateur et de pwd n'est pas connu du NAS. Ne pas laisser "utilisateur" et "mdp", il faut mettre le nom et le pwd d'un compte qui soit administrateur du NAS. Cordialement Audio

Bonjour, Pour ma part seul 1 de mes 3 DS 920+ a été mis à jour automatiquement. Tout fonctionne bien après le nettoyage des anciens paquets PHP. J'attends pour la mise à jour des 2 NAS restant. Peut-être procéderais-je en manuel pour l'un des 2. J'espère que je n'aurais pas de mauvaises surprises lorsqu'il faudra changer des disques durs! Bonne journée

Bonjour, Je relance ce sujet car j'ai eu des déboires assez similaires à ceux que @grizzli06 a expérimenté avec une VM Linux sous VMM, en particulier la touche Alt gr inopérante (voir son sujet dédié https://www.nas-forum.com/forum/topic/77944-virtual-machine-manager-touche-alt-gr-inopérante/ du 13 octobre 2023). J'ai installé une distribution Debian 13 Trixie sur VMM et je dois dire que la connexion à cette VM c'est pas le top avec noVNC dès lors qu'on veut utiliser une URL, dans mon cas debian.ndd.tld, en passant par un proxy. Il est clair que ça ne fonctionne pas. Il faut connecter d'abord VMM sur son port dédié renseigné dans le proxy (obtenu dans Portail de connexion > Applications) puis presser le bouton connexion sur la vm dans VMM. Pas très pratique! Heureusement j'ai découvert une solution bien documentée permettant de se connecter directement depuis Windows 11 par son application Bureau à Distance moyennant l'installation du paquet xRDP dans Debian. https://www.it-connect.fr/comment-se-connecter-en-rdp-a-debian-10-avec-xrdp/ C'est facile à mettre en place et à configurer que ce soit côté Debian ou Windows. Et la touche Alt gr fonctionne tout de suite 😄 Bonne journée à tous Audio

Bonjour @Mic13710 et @CMDC Vous avez raison tous les 2, le container est effectivement effacé puis recréé. Je pensais au script acme.sh lui-même et pas au script d'Eisteinium dans le planificateur de tâches de DSM. De mon côté la tâche de vérification/mise à jour d'acme.sh est depuis toujours programmée qu'une fois par semaine (réminiscence du temps où j'utilisais la méthode acme.sh en direct). Ayant installé Watchtower pour d'autres applis sous Docker (1 run par semaine), je pourrais peut être lui confier la mise à jour de neilpang/acme.sh, comme indiqué par Einsteinium dans le fichier Docker Compose. Cordialement

Bonjour @CMDC, Je ne pense pas que le container ACME soit "détruit et recréé" tous les jours. D'après le log acme.sh.log c'est un test sur la date de renouvellement qui est fait tous les jours. Si on a pas dépassé la date "Next renewal time is: YYYY-MM-DDTHH:MM:SS" alors le process de renouvellement n'est pas enclenché. Maintenant on peut toujours se dire que ce n'est pas la peine de faire cette vérification quotidiennement. Depuis que j'ai opté pour la méthode sous Docker au lieu de celle sous acme.sh il y a plus de 2 ans, je n'ai plus de soucis de renouvellement. Une fois par semaine j'ai la tache automatique qui regarde si il y a ou non une nouvelle image neilpang/acme.sh et l'installe s'il y a lieu. Cordialement Audio

Merci @PiwiLAbruti pour l'adresse de ce site de test. C'est effectivement détaillé. Toutefois le site de test ne vérifie pas pas le reverse DNS à partir de l'adresse IP du serveur mail. Le test ne porte que sur SPF, DMARC et DKIM.

Bonjour @Mic13710 Je suis aussi chez OVH, j'ai eu un renouvellement ACME le 29 juin et le log acme.shog est tout à fait normal. Bonne journée