PPJP

J'ai tenté de suivre vos conseils. J'ai du supprimer le premier conteneur suite à un conflit. Avec le nouveau pihole j'ai systématiquement la réponse suivante à nslookup sur pihole: ;; connection timed out; no servers could be reached La manip ayant été faite rapidement, j'ai pu commettre des erreurs. Dès que j'aurais un peu de temps, je referais la manip plus sérieusement. Je vous ferais un retour à ce moment.

192.168.1.4 est l'ip du second Nas (212j) sur lequel est installé un second serveur dns renvoie bien les infos pour Google.fr Est-ce vraiment utile? (Il n'y a aucun problème avec les ip externes) La seule anomalie est la réponse de IPWAN pour les adresses internes Bien noté. je frais les corrections. Ce que je ne comprends vraiment pas, c'est par quel chemin l'IPWAN remonte à la place des IPLAN Exemple: user@DS218:~$ sudo docker exec -it pihole nslookup 212j.ndd.tld 192.168.1.192 Server: 192.168.1.192 Address: 192.168.1.192#53 Name: xxx.ndd.tld Address: 192.168.1.4 user@DS218:~$ nslookup 212j.ndd.tld 192.168.1.225 Server: 192.168.1.225 Address: 192.168.1.225#53 Non-authoritative answer: 212j.ndd.tld canonical name = ndd.tld. Name: ndd.tld Address: IPWAN

Le docker-compose: version: '2.1' services: pihole: image: pihole/pihole container_name: pihole hostname: pihole labels: - "com.centurylinklabs.watchtower.enable=true" networks: macvlan0: ipv4_address: 192.168.1.225 environment: - ADMIN_EMAIL=xxxxxxx@ndd2.tld - TZ=Europe/Paris - DNS1=192.168.1.192 - DNS2=192.168.1.4 - DNSSEC=false - DNS_BOGUS_PRIV=true - DNS_FQDN_REQUIRED=true - DNSMASQ_LISTENING=local - INTERFACE=eth0 - REV_SERVER=true - REV_SERVER_TARGET=192.168.1.1 - REV_SERVER_CIDR=192.168.1.0/24 - REV_SERVER_DOMAIN=ndd.tld - TEMPERATUREUNIT=C - WEBUIBOXEDLAYOUT=boxed - ServerIP=192.168.1.225 - VIRTUAL_HOST=ph.ndd.tld - WEBPASSWORD=prgkqùrùekgg volumes: - /volume1/docker/pihole/etc-pihole:/etc/pihole/ - /volume1/docker/pihole/etc-dnsmasq.d:/etc/dnsmasq.d/ dns: - 127.0.0.1 restart: unless-stopped networks: macvlan0: external: true Pour être complet, je joins les infos pour les réseaux docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --ip-range=192.168.1.224/28 \ --gateway=192.168.1.1 \ -o parent=eth0 \ macvlan0 ip link add mac0 link eth0 type macvlan mode bridge ip addr add 192.168.1.192/32 dev mac0 ip link set dev mac0 address 02:00:00:00:00:10 ip link set mac0 up ip route add 192.168.1.224/28 dev mac0

docker exec -it pihole cat /etc/resolv.conf: nameserver 127.0.0.11 options ndots:0 docker exec -it pihole nslookup local.ndd.tld: Server: 127.0.0.11 Address: 127.0.0.11#53 Non-authoritative answer: xxx.nom_domaine.tld canonical name = nom_domaine.tld. Name: nom_domaine.tld Address: IPWAN

Sur mon site local: Oui Sur le site distant le routeur est une box où il est impossible de changer l'adresse de serveurs Dns. Ces adresses sont fixées dans les paramètres des cartes réseaux des clients. Actuellement, dans l'attente de la résolution de l'anomalie, pihole n'est plus utilisé et c'est l'IP du serveur DNS du 218+ renseignée. Comme indiqué je teste les réponses directement avec nslookup. Edit: Plus précisément: nslookup xxx.ndd.tld Ip serveur dns du nas retourne IP LAN correcte nslookup xxx.ndd.tld Ip pihole retourne IP WAN PiHole avec Ip serveur dns du nas en upstream

Bonjour, Je ne parviens pas à faire fonctionner correctement sur un site distant la chaine pihole serveur DNS local. Les tests par nslookup donnent les résultats suivants: - interrogations du serveur DNS renvoient les IP LAN - interrogations de piHole (serveur DNS en upstream) renvoient les IP WAN L'installation et le paramétrage sur ce site distant (sur 218+ en DSM6) sont identiques à ce qui existe sur mon site local (sur 1815+ en DSM6 lors de l'installation, en DSM7 depuis) qui lui fonctionne correctement depuis de nombreux mois. Les mêmes docker-compose et scripts de création réseaux ont été utilisés ( après adaptation des noms de domaines et IP LAN internes). Une piste de recherche pour situer l'anomalie serait la bienvenue! Merci

Bonjour, Python 2 utilise pip, Python 3 utilise pip3. Si pip3 est absent, il suffit de l'installer. curl -k https://bootstrap.pypa.io/get-pip.py | python3

Bonjour @shad J’ai testé pihole en docker macvlan et vous fait un petit retour d’expérience. L’installation par docker-compose se relançait dans une boucle infinie. Le log indiquait une erreur dans le fichier pihole,conf mais l’examen de la ligne incriminée ne montrait pas d’anomalie évidente. J’ai trouvé l’origine de l’anomalie au niveau du conditionnal forwarding qui n’accepte que des LAN en /8, /16, /24 ou /32 alors que mon Lan était en /25. Vous jugerez s’il est nécessaire d’inclure cette précision dans votre tutoriel car la quasi totalité des membres du forum semble utiliser des réseaux en 192.168.X.0/24. Bonne journée

Bonjour, Je repassais justement sur ce forum pour voir si la dernière version du script avait été validée sur SRM. Ci-joint le script modifié selon votre demande. Le site en question proposant 4 listes, la possibilité de choisir celle(s) à prendre en compte est prévue. Comme d'habitude le script a été validé pour DSM mais pas pour SRM. PS: je n'ai pas pris le temps de vérifier à quoi correspondait ces adresses " bizarres"

Le script semble faire correctement son travail sur SRM. Il ne semble y avoir qu'une commande non reconnue sur SRM, mais n'affectant que l'affichage des infos de téléchargement.Bonjour, @Diabolomagic La base de donnée synoautoblock.db fait partie de SRM et ne peut être déplacée. dirtmp indique le répertoire contenant des fichiers temp utilisés durant l’exécution du script, Ce répertoire est donc vide en final. Un déplacement sur la carte SD est possible mais nécessitera la modification de quelques lignes de code. Je suis surpris du ralentissement du routeur que vous signalez car la taille de base de données est toujours du même ordre de grandeur que précédemment. Dans votre exemple 26614 + éventuellement des IP bloquées suite à des tentatives d'intrusion et des IP en liste blanche. Vous pouvez lancer, pour test, ce script avec le paramètre "raz" ce qui supprimera les IP bloquées non définitivement (conserve les IP en liste blanche) Je ne peux malheureusement pas tester ces ralentissements car je n'ai pas de SRM. @supertex Constatez vous également des ralentissement du routeur? en PJ: Une nouvelle version du script (testée sur DSM) susceptible de corriger les anomalies d'affichage des infos de téléchargement sur SRM. autoblocksynology.sh

Bonjour, @bruno78 Je viens de consulter votre dernière version du script, et j'ai 2 observations très mineures La ligne echo "" >> $tmp1 (ligne148 du script joint) n'aurait pas dû être supprimée. Elle rajoute le retour à la ligne manquant après la dernière Ip dans la liste téléchargée. Sans elle cette dernière IP n'est pas prise en compte. J'ai téléchargé les 3 listes de feodotracker.abuse.ch et un rapide examen montre que ipblocklist_recommended.txt n'est qu'un extrait de ipblocklist.txt qui n'est elle même qu'un extrait de ipblocklist_aggressive.txt. Il suffit donc de télécharger une seule liste suivant la sévérité de filtrage souhaité. Lors de consultation du script, j'ai vu quelques améliorations possibles - augmentation de la vitesse d"exécution du script - compactage du code - rajout en infos finales du nombre d"IP provenant du fichier filtreperso.txt Je n'utilise pas ce script, donc je n'ai pas fait de don sur le site de mariushosting.com et en conséquence je ne peux y accéder. Je ne peux donc pas adapter le script pour ce site. Une solution palliative serait envisageable: -téléchargement manuel des fichiers mariushosting.com et les mettre dans un répertoire donné (celui du script par exemple) - corriger le script pour leur prise en compte (comme filtreperso.txt) @Superthx J’ai l'impression que vous présentez les premiers symptômes du bégaiement😆 Bonne soirée à tous.

Bonjour, Repassant sur ce forum après quelques mois d'absence, je constate qu'il y a eu du déterrage sur ce fil. Je vais tenter d'apporter quelques explications complémentaires sur ce script. Ne l'ayant pas conservé chez moi je me réfère a celui joint à mon post du 5 janvier 2000. Ce script a été architecturé de manière à pouvoir être facilement modifié et comporte pour cela un chapitre PARAMETRAGE( lignes 19 à 45) pour @Diabolomagic La liste des sites à traiter figure à la ligne 28 Pour supprimer le traitement du site mariushosting il vous suffit de la corriger: Liste_Url="https://lists.blocklist.de/lists/ \ https://mariushosting.com/wp-content/uploads/2018/07/deny-ip-list.txt" devient Liste_Url="https://lists.blocklist.de/lists/" Accessoirement vous pouvez également supprimer les lignes devenues inutiles de la ligne 134: mariushosting.com) à la ligne 161: ;; pour @bruno78 Si le site de mariushosting est maintenant protégé par un mot de passe (et un nom d'utilisateur?), l'utilisation de ce script est toujours possible. Il suffit de passer ces données au wget de la ligne 140 par les options --http-passwd=mot-de-passe (et --http-user=utilisateur)

Bonsoir Votre DNS serveur fonctionne correctement.

@kroumi La troisième ligne de votre zone DNS est une entrée de type A, elle ne renvoie pas vers vous mais vers OVH. C'est donc normal que cela ne fonctionne pas. Supprimez cette ligne. C'est la suivante,où je suppose que vous avez indiqué votre IP fixe, qui sera alors prise en compte.

Bonjour, Dans la zone DNS chez OVH, il y a deux entrées de type A! Ne conserver que celle qui pointe vers l'IP fixe

Bonjour @shad Bien vu. Je me connecte toujours à SSH sous le compte root. C'est pour cela que je n'ai pas eu le réflexe de l'indiquer. Donc si connecté en root : python3 -m pip install numpy==1.18.3 Si autre compte: sudo python3 -m pip install numpy==1.18.3 J’espère que votre précision a suffi à dépanner @Aurel42160 Car je ne passe que très irrégulièrement sur ce forum. Bonne soirée.

Bonjour, Utilisez cette commande : python3 -m pip install numpy==1.18.3

Bonjour, python --version retourne la version de python 2. Pour avoir la version de python3 la commande est tout simplement: python3 --version Vous pouvez installer d'autres modules en passant par pip.

@oracle7 Je vais également essayer de répondre point à vos remarques Tout d'abord, je tiens à que je n'utilise pas acme et que je ne l'ai que rapidement consulté lorsque je suis intervenu sur le tuto de unPixel. Le seul problème à l'époque était le non redémarrage de quelques paquets, car je n'avais pas pris le temps de creuser aussi profondément que ne l'a fait @bruno78 (bravo) sur les dépendances. Le but de mes suggestions était simplement de simplifier d'une part les opérations pour les utilisateurs du tuto et d'autre part de simplifier drastiquement le script de renouvellement. J'ai bien compris le message et n'interviendrai plus sur ce fil. Réponses valables si pas de changements de ACME depuis mon intervention sur le tuto de unPixel. Non, , étant positionné dans /usr/local/share/acme.sh un wget installe directement tous les fichiers nécessaires dans ce dossier Non mais dans /usr/local/share/acme.sh Cette info est transmise par l'option --dns xxx de la commande de création du certificat Le script de renouvellement peut parfaitement vérifier l"ancienneté du certificat et décider s'il faut lancer le renouvellement (il le fait) La commande de renouvellement utilisant l’option --dns ne nécessite pas l'ouverture de ports Enfin concernant le script Il est obligé d''aller récupérer toutes les personnalisations faites lors de la création initiale! Quel est l’intérêt de conserver l'ancien certificat (durée de vie limitée) et d'en créer un nouveau ? Ce qui entraine de mémoriser les data de l'ancien fichier INFO pour de les transférer dans le nouveau. Le transfert des fichiers créés par ACME et renommés, ainsi que le redémarrage des packagses et services tels que réalisés par le script actuel seraient suffisants. La liste des certificats dans DSM va grossir ! @bruno78 Il n'en était question que lors de la création initiale du certificat le script actuel s'en chargeant lors du renouvellement. Fin de mon intervention sur ce fil. Cordialement

Bonjour, Très beau travail de @oracle7 et @bruno78 Mais je vais me permettre de donner mon humble avis, sans intention blesser qui que ce soit. Je trouve ce tuto trop compliqué, ce qui entraine des anomalies comme celle rencontré par @Audio (certainement variable CERT_HOME non définie lors de la création initiale du certificat) . Pourquoi ne pas avoir procédé ainsi: Installation acme: Création du dossier acme Après s'y être positionné, installation par un simple wget (ou curl) On laisse tous les paramétrages par défaut Création initiale d'un certificat: On ne renseigne les variables d'environnement que pour les clé API On lance uniquement la commande de création du certificat (pas d'utilisation de deploy) On crée le certificat depuis DSM avec les nouveaux fichiers obtenus de ACME. On configure les services pour ce certificat. Renouvellement: Le script après les test initiaux se contente de Lancer la même commande que lors de la création Copier ( et renommer ) les nouveaux fichiers obtenus de ACME dans les packages et services concernés Relancer les packages et services concernés Enfin je trouve dommage que le script de renouvellement soit en python 2.7. Python 2 est obsolète et n'est plus maintenu. Si un jour DSM7 sort, il est très probable que seul python 3 y subsistera, rendant ce script inutilisable.

Le redémarrage des services n’est pas nécessaire, Je ne suis même pas certain que ce soit utile pour tous les packages avec (IsPgg = True) Tout simplement parce que le dossier où acme met les fichiers du certificat ne porte pas le même nom selon que c’est une clé RSA ou EDSA. La rajout de quelques lignes de code sera suffisant pour remédier au problème. Mais je ne pourrai faire de tests que la semaine prochaine (quota LE). Si un utilisateur éprouve le besoin de changer de type de clé de chiffrement, n’est-il pas plus simple de changer un paramètre de ce script et de le relancer avec le paramètre 0 que de relancer la création d’un certificat en suivant votre tuto qui est un processus assez lourd (je reconnais ne n’avoir lu qu’en diagonale), Ce serait faisable,mais il faudrait rajouter d’autres paramètres comme l’API DNS à utiliser. Et il resterait le problème des clés d’accès à cet API Elles sont différentes selon les API ( nombre, noms, longueurs …) et ces API sont nombreuses !! Comme je n’utilise pas acme je n’ai jamais pris le temps de vraiment de détailler son fonctionnement. Je ne sais pas exactement quelles sont infos que l’on peut trouver dans le fichier account.conf. Si c’est simple dans le cas d’un certificat unique, qu’en est-il dans le cas de l’existence de plusieurs certificats (chez un ou plusieurs registrars) ? L’objectif d’un script ‘généraliste’ me semble trop ambitieux. Ce qui me semble envisageable, c’est un script limité à un certificat LE unique dont le DNS est soit chez OVH, soit chez Gandi. Oui. Vous pouvez vérifier dans la crontab que vous n'avez pas de lignes correspondantes (je ne pense pas). Il n’est pas utile de redémarrer AudioStation, Surtout le temps d’exécution du script va sérieusement augmenter. PS: Ces clés sont uilisées pour permettre l’accès à l’API. Les valeurs TXT inscrites dans le DNS sont différentes à chaque exécution par LE, ce ne sont pas les clés API .

@bruno78 Le script que j'ai fourni est buggé! Je viens de m'en apercevoir car j'avais programmé une tâche pour le lancer périodiquement pour test. Il ne fonctionne pas pour les clé elliptiques. (que j'avais mis en exemple pour le paramétrage du script alors que je n'avais pas testé cette configuration!) Il ne doit donc être lancé que pour des clé RSA. Je pense le corriger rapidement, mais les test seront long (j'ai déjà épuisé mon quota pour la semaine et des tests en staging ne me semblent pas suffisants pour valider un script) Il y a de nombreuses combinaisons à tester (RSA vers RSA, EDSA vers EDSA, RSA vers EDSA, EDSA vers RSA) Désolé @oracle7 Pouvez vous me transmettre une copie de ce fichier (expurgé des données personnelles) Chez moi ce fichier ne mentionne pas de clés. Pourquoi? ce fichier peut être mis n'importe où à partir du moment où c'est un emplacement non concerné par les mise à jour DSM. Noz vat JC ☺️

Bonjour, Comme prévu, je viens de repasser sur ce forum. Le renouvellement automatique du certificat LE générique n’y figurant pas, je me suis libéré un petit créneau pour essayer de vous aider. Je n’ai pas suivi le tuto pour installer acme,sh Je me suis simplement positionné dans le dossier /usr/local/share/acme.sh installé acme par curl https://get.acme.sh | sh J’ai ensuite réalisé la création initiale du certificat : définir la clé l’API key : export GANDI_LIVEDNS_KEY="?????????????" (pour OVH cela aurait été export OVH_AK="???" et export OVH_AS="???") lancer la demande de certificat par la commande : /usr/local/share/acme.sh/acme.sh --issue -d nom_domaine.tld -d *.nom_domaine.tld --dns dns_gandi_livedns -- keylength ec-384 --home /usr/local/share/acme.sh --nocron --force (pour OVH il aurait fallu -dns dns_ovh) rajouté les deux enregistrements TXT dans la zone DNS du domaine (infos récupérés dans le message de l’étape précédente) relancer la demande de certificat par la même commande que précédemment Les fichiers de certificats créés ont ensuite été injectés par l’interface du syno. Le renouvellement automatique sera réalisé par un script lancé quotidiennement (en root) par le planificateur de tâche. Le script joint n’est qu’une ébauche et demande à être adapté et finalisé. Il doit être paramétré avant utilisation (paramétrage en début de script). Par défaut, il réalise le renouvellement tous les 84 jours. Il relance les packages concernés par ce certificat (et non arrêtés avant le renouvellement). Cela n’est pas forcément obligatoire et peut être supprimé en commentant la ligne 202 du script. Ces redémarrages avaient été introduits suite au constat de l’arrêt de certains paquets par UnPixel sur un précédent tuto, ce que je n’ai jamais constaté chez moi. PS commande à renseigner dans le planificateur de tâche : bash /volume1/script/forum/majcertificat_v04.sh (à adapter selon l’emplacement du script) ou pour avoir une trace de la dernière exécution : bash /volume1/script/forum/majcertificat_v04.sh > /volume1/script/forum/certificat/majcertificat.log 2>&1 Enfin on peut ajouter un paramètre( de 0 à 90)) si l’on veut une périodicité de renouvellement différente. Par exemple pour tester durant une courte période un renouvellement tous les 2 jours : bash /volume1/script/forum/majcertificat_v04.sh 2 > /volume1/script/forum/certificat/majcertificat.log 2>&1 Bon tests pour ceux qui aiment les risques! majcertificat_v04.sh

@bruno78 Le manuel de jq : https://stedolan.github.io/jq/manual/

@bruno78 Pour mes besoins, sur les NAS où j’interviens, je ne code presque qu’exclusivement en Python. Je n’ai pratiqué le shell que pour aider sur quelques scripts de tuto de ce forum où je suis intervenu. Je le connais donc que très mal et trouve sa lecture pénible (manque de pratique) Les fichiers json se traitent en shell avec jq. J’essaierai de passer sur ce forum de temps en temps pour voir où vous en êtes. Si vous êtes bloqués j’essaierai de vous aider. Bon courage