PPJP
-
Compteur de contenus
393 -
Inscription
-
Dernière visite
-
Jours gagnés
5
Messages posté(e)s par PPJP
-
-
192.168.1.4 est l'ip du second Nas (212j) sur lequel est installé un second serveur dns
il y a une heure, .Shad. a dit :docker exec -it pihole nslookup www.google.fr 192.168.1.192
renvoie bien les infos pour Google.fr
il y a une heure, .Shad. a dit :e te conseille d'ajouter un 2ème serveur DNS pour Pi-hole lui même
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
il y a une heure, .Shad. a dit :il faut les remplacer par PIHOLE_DNS_
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#53Name: xxx.ndd.tld
Address: 192.168.1.4user@DS218:~$ nslookup 212j.ndd.tld 192.168.1.225
Server: 192.168.1.225
Address: 192.168.1.225#53Non-authoritative answer:
212j.ndd.tld canonical name = ndd.tld.
Name: ndd.tld
Address: IPWAN0 -
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-stoppednetworks:
macvlan0:
external: truePour ê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 \
macvlan0ip 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 mac00 -
docker exec -it pihole cat /etc/resolv.conf:
nameserver 127.0.0.11
options ndots:0docker exec -it pihole nslookup local.ndd.tld:
Server: 127.0.0.11
Address: 127.0.0.11#53Non-authoritative answer:
xxx.nom_domaine.tld canonical name = nom_domaine.tld.
Name: nom_domaine.tld
Address: IPWAN0 -
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 upstream0 -
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 WANL'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!
Merci0 -
Bonjour,
Il y a 20 heures, CoolRaoul a dit :il manque pip dans le python officiel
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
0 -
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
0 -
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"
1 -
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,Il y a 16 heures, Diabolomagic a dit :db="/etc/synoautoblock.db"
dirtmp="/tmp/autoblock_synology"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.
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.0 -
Bonjour,
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.txtJe 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)J’ai l'impression que vous présentez les premiers symptômes du bégaiement😆
Bonne soirée à tous.
1 -
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)1 -
Bonsoir
Votre DNS serveur fonctionne correctement.
1 -
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.
0 -
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
0 -
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.3J’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.0 -
Bonjour,
Utilisez cette commande : python3 -m pip install numpy==1.18.3
0 -
Bonjour,
python --version retourne la version de python 2.
Pour avoir la version de python3 la commande est tout simplement: python3 --versionVous pouvez installer d'autres modules en passant par pip.
0 -
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.Il y a 2 heures, oracle7 a dit :Maintenant si tu as d'autres suggestions d'améliorations, avec @bruno78 nous sommes preneurs dans juste mesure de nos capacités respectives. Cela doit pouvoir venir en complément des fonctions accessibles via le mode "manuel" du script. Si cela doit toucher la partie automatique, il faudra alors être très convainquant pour ne pas complexifier encore plus ...
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.
Il y a 2 heures, oracle7 a dit :C'est ce que j'ai essayé initialement mais cela ne marchait pas, le wget ne permet que de récupérer le fichier tar du script
Non, , étant positionné dans /usr/local/share/acme.sh un wget installe directement tous les fichiers nécessaires dans ce dossier
Il y a 2 heures, oracle7 a dit :Surtout pas car sinon le certificat est généré dans le répertoire "/root/.acme.sh"
Non mais dans /usr/local/share/acme.sh
Il y a 2 heures, oracle7 a dit :De plus, par défaut c'est la méthode HTTP_01 qui est utilisée et qui elle, nécessite d'ouvrir les ports 80 et 443 sur le NAS
Cette info est transmise par l'option --dns xxx de la commande de création du certificat
Il y a 2 heures, oracle7 a dit :mais là en plus, il n'y a pas besoin de getter la date de renouvellement pour ouvrir les ports 80 et 443
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 portsEnfin 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 !il y a une heure, bruno78 a dit :Mais on est bien d'accord, renouveler son certificat et ré-affecter les services à la main, 1 fois tout les 3 mois, ce n'est pas la mer à boire
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.
Cordialement0 -
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éfautCré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ésEnfin 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.0 -
Il y a 17 heures, bruno78 a dit :
Mais si je comprends bien, on ne redémarre pas les services (IsPkg=false)
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)
Il y a 12 heures, oracle7 a dit :En toute logique, j'ai du mal à comprendre en quoi un paramétrage de longueur de clé de chiffrement peut impacter ainsi le fonctionnement d'un script.
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).
Il y a 12 heures, oracle7 a dit :Pourquoi, envisager des conversions de clés (RSA vers EDSA, EDSA vers RSA) ? Cela ne me parait pas utile à moins que tu n'ai une bonne raison en magasin. Pour mémoire le choix de la clé de chiffrement est fixée initialement lors de la constitution de la commande de création du certificat. L'utilisateur devrait à mon sens, recréer un certificat s'il souhaite changer la longueur de la clé de chiffrement lorsque la date d'expiration du certificat est atteinte.
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),
Il y a 13 heures, oracle7 a dit :Aussi, je pense qu'il serait bien que le script ne soit pas modifiable pour éviter ainsi tous problèmes avec des utilisateurs non avertis. En conséquence, il serait nécessaire donc pour cela, qu'il accepte des paramètres supplémentaires qui seraient eux, définis lors de la constitution de la commande à insérer dans le planificateur de tâches et uniquement à ce moment là, et qui permettraient de prendre en compte notamment :
- le domaine de l'utilisateur : "ndd.tld"
- Le type de clé de de chiffrement (i.e. la valeur du paramètre "-- keylenght") : 2048 (défaut), 4096, ec-256, ec-394)
- le nombre de jour pour le renouvellement : mais cela tu l'as déjà pris en compte.
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.
Il y a 13 heures, oracle7 a dit :Une dernière question : peut-on purement et simplement remplacer dans le gestionnaire de tâches, l'actuelle commande de renouvellement (celle du Tuto) qui est active dans le gestionnaire de tâches, par celle que tu proposes avec l'usage du script ? N'y-a-t-il pas une manipulation autre à effectuer vis à vis du "cron" pour prendre en compte ce changement ?
Oui.
Vous pouvez vérifier dans la crontab que vous n'avez pas de lignes correspondantes (je ne pense pas).
Il y a 12 heures, bruno78 a dit :dans le doute, je redémarre tout ce qui touche au certificat
Il n’est pas utile de redémarrer AudioStation,
Il y a 12 heures, bruno78 a dit :Et dans le doute, je redémarre tout ce qui touche au certificat .... mais c'est un peu bourrin !
Surtout le temps d’exécution du script va sérieusement augmenter.
PS:
Il y a 13 heures, oracle7 a dit :Avec le Tuto, ces clés sont "exportées" une première fois pour la création du certificat. ACME.sh les inscrit alors temporairement chez OVH pour l'authentification du domaine puis les supprime de chez OVH (voir le log de création que j'ai fourni dans le Tuto). Donc ensuite, pour le renouvellement, ACME.sh a besoin de les retrouver quelque part puisque il n'y a plus d'enregistrement correspondant chez OVH (dans la zone DNS du domaine), d'où leur sauvegarde dans le fichier "account.conf"
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 .
0 -
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é
Il y a 11 heures, oracle7 a dit :Pour ton info si besoin en est, ces clés sont sauvegardées dans le fichier "account.conf" situé dans le répertoire "/usr/local/share/acme.sh". Elles sont respectivement inscrites dans ce fichier, lors de la création du certificat par ACME, à l'aide de deux variables d'environnement "SAVED_OVH_AK" et "SAVED_OVH_AS" . Il suffirait (si je puis dire) de les relire pour alimenter l'export des clés que tu fais ensuite en début de script.
Pouvez vous me transmettre une copie de ce fichier (expurgé des données personnelles)
Chez moi ce fichier ne mentionne pas de clés.
Il y a 11 heures, oracle7 a dit :Par ailleurs, je modifierai le TUTO pour recommander d'utiliser le répertoire "Volume1/Scripts" pour y stocker le présent Shell script.
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 ☺️
0 -
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!
1 -
-
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
0
[TUTO] [Docker - macvlan] Pi-Hole
dans Tutoriels
Posté(e) · Modifié par 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.