mettre en place mon propre serveur DNS [Réglé]
J'ai suivi le tuto, mais je rencontre quelques difficultés
Système et matériels / Réseau Internet Wi-Fi
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
Reprise du message précédent
Bonjour
Après modification de unbound.conf, il faut redémarrer le service unbound en root par
Code BASH :
systemctl restart unbound
Ton fichier /etc/resolv.conf est étrange. Il ne devrait pas y avoir tous ces dns alternatifs et 127.0.0.1 aurait dû être ajouté automatiquement suite à la modification par drakconnect / net_applet.
do-not-query-localhost:no est une fonction de déboggage. Je ne l’ai pas essayée mais cela doit être à yes en production.
Avais-tu modifié manuellement /etc/resolv.conf avant l’installation de unbound ?
Le fait que network soit en erreur est aussi étrange. Bien que cela fonctionne sans pour zatox et je suspecte que, pour lui, c’est antérieur à l’installation de unbound.
Est-ce que tu as essayé d’installer NetworkManager à un moment ?
Pour essayer de comprendre, est-ce possible que tu postes une copie d’écran de la configuration ethernet de net_applet ?
Désolé pour toutes ces questions mais ta configuration est étrange et j’essaye de comprendre. De multiples installations de unbound sous Mageia ont été faites et sont fonctionnelles. Donc, il y a quelque chose de spécifique chez toi.
A+
Edit: test additionnel que je vais ajouter au tuto pour connaitre le DNS utilisé dans les requêtes.
Si tu exécutes :
Code BASH :
dig mageia.orgest-ce que vers la fin du résultat tu vois
;; SERVER: 127.0.0.1#53(127.0.0.1)
ce qui est normal avec unbound
ou est-ce que tu vois
;; SERVER: 192.168.1.254#53(192.168.1.254)
qui indique que c'est le DNS de ton FAI via la box qui est utilisé.
Édité par squid-f Le 13/07/2021 à 09h23
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
joel :
zatox :
désolé de poser cette question mais des fois les trucs les plus simples sont ceux que l'on peut oublier.
Non, tu as raison de poser la question. C'est bien le genre d'erreur que j'aurai pu faire...
désolé de poser cette question mais des fois les trucs les plus simples sont ceux que l'on peut oublier.
Non, tu as raison de poser la question. C'est bien le genre d'erreur que j'aurai pu faire...
moi aussi c'est pour ça que je l'ai posée ...Concernant le fichier /etc/unbound/unbound.conf j'ai fait un copier/coller de ce qui est indiqué dans le tutoriel. J'ai regardé les différents paramètres, je ne sais pas si j'ai eu raison, mais je n'en ai modifié aucun.
Ensuite, pour info, je suis en vacances et j'ai monté unbound sur mon PC portable (bien qu'étant en vacances
), ça marche très bien, network est actif ainsi qu'unbound. Par contre avant de partir j'ai monté unbound sur mon PC de bureau, à priori ça marche, unbound est actif mais pour une raison encore inconnue, network ne marche pas et je n'arrive pas à le lancer.squid-f est au courant puique j'ai ouvert un post à ce sujet et il m'a aidé à tenter de résoudre ou de comprendre ce problème. Pour le moment le problème n'est pas résolu j'attends d'être rentré. Bon malheureusement mon discours ne fait pas avancer ton problème désolé ...
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
@joel, en complément de mon post précédent, je viens de m'apercevoir qu'une mise à jour récente de glibc aurait réinitialisé le fichier /etc/resolv.conf avec les paramètres de la box, en ignorant les modifications faites par net_applet.
En faisant la nouvelle mise à jour du jour (noyau principalement), le fichier /etc/resolv.conf est revenu dans l'ordre.
C'est étrange, les autres machines pour lesquelles j'ai basculé sous NetworkManager n'ont pas eu le souci.
Je vais probablement ouvrir un rapport de bug là-dessus.
Cela pourrait expliquer les bizarreries (à mon sens) que je trouve dans ton /etc/resolv.conf. J'ai l'impression que tu as entré des DNS alternatifs dans l'interface de ta BBOX et c'est ce qu'on retrouve dans ton /etc/resolv.conf
As-tu bien ajouté des DNS dans l'interface de ta BBOX ?
Donc, avant les manipulations que je te suggère dans mon post précédent, je ferais la mise à jour par CCM puis redémarrerais la machine.
Ensuite, si toujours le même souci, tu peux te lancer dans les tests de mon précédent post.
A+
joel Membre non connecté
zatox :
squid-f est au courant puique j'ai ouvert un post à ce sujet et il m'a aidé à tenter de résoudre ou de comprendre ce problème.
squid-f est au courant puique j'ai ouvert un post à ce sujet et il m'a aidé à tenter de résoudre ou de comprendre ce problème.
Oui, j'avais vu, et c'est suite à cela que j'ai voulu installer unbound...
Bon, là, suite au dernier message de squid-f, je suis en train de mettre à jour le système... Je reviens après le redémarrage...
joel Membre non connecté
Bon, je reprends la réponse que j'avais commencée à rédiger...
squid-f :
Après modification de unbound.conf, il faut redémarrer le service unbound en root par
systemctl restart unbound
Après modification de unbound.conf, il faut redémarrer le service unbound en root par
systemctl restart unbound
Ah ? OK, je viens donc de le faire... mais le problème reste entier....
squid-f :
Ton fichier /etc/resolv.conf est étrange. Il ne devrait pas y avoir tous ces dns alternatifs et 127.0.0.1 aurait dû être ajouté automatiquement suite à la modification par drakconnect / net_applet.
Avais-tu modifié manuellement /etc/resolv.conf avant l’installation de unbound ?
Avais-tu modifié manuellement /etc/resolv.conf avant l’installation de unbound ?
Oui, il y a quelques temps, j'avais ajouté les dns de FDN.
squid-f :
do-not-query-localhost:no est une fonction de déboggage. Je ne l’ai pas essayée mais cela doit être à yes en production.
OK, mais dans ce cas, ne faudrait-il pas décommenter les lignes précédentes, puisque /etc/unbound/unbound.conf, dis :
" # if yes, the above default do-not-query-address entries are present.
# if no, localhost can be queried (for testing and debugging)."
Traduction deepl
" # si oui, les entrées par défaut do-not-query-address ci-dessus sont présentes.
# si non, localhost peut être interrogé (pour les tests et le débogage)."
squid-f :
Le fait que network soit en erreur est aussi étrange. Bien que cela fonctionne sans pour zatox et je suspecte que, pour lui, c’est antérieur à l’installation de unbound.
Est-ce que tu as essayé d’installer NetworkManager à un moment ?
Est-ce que tu as essayé d’installer NetworkManager à un moment ?
Non
squid-f :
Pour essayer de comprendre, est-ce possible que tu postes une copie d’écran de la configuration ethernet de net_applet ?
squid-f :
test additionnel que je vais ajouter au tuto pour connaitre le DNS utilisé dans les requêtes.
Si tu exécutes :
dig mageia.org
est-ce que vers la fin du résultat tu vois
;; SERVER: 127.0.0.1#53(127.0.0.1)
ce qui est normal avec unbound
Si tu exécutes :
dig mageia.org
est-ce que vers la fin du résultat tu vois
;; SERVER: 127.0.0.1#53(127.0.0.1)
ce qui est normal avec unbound
Oui, après mise à jour et redémarrage...
squid-f :
Re-
@joel, en complément de mon post précédent, je viens de m'apercevoir qu'une mise à jour récente de glibc aurait réinitialisé le fichier /etc/resolv.conf avec les paramètres de la box, en ignorant les modifications faites par net_applet.
En faisant la nouvelle mise à jour du jour (noyau principalement), le fichier /etc/resolv.conf est revenu dans l'ordre.
C'est étrange, les autres machines pour lesquelles j'ai basculé sous NetworkManager n'ont pas eu le souci.
Je vais probablement ouvrir un rapport de bug là-dessus.
Cela pourrait expliquer les bizarreries (à mon sens) que je trouve dans ton /etc/resolv.conf. J'ai l'impression que tu as entré des DNS alternatifs dans l'interface de ta BBOX et c'est ce qu'on retrouve dans ton /etc/resolv.conf
@joel, en complément de mon post précédent, je viens de m'apercevoir qu'une mise à jour récente de glibc aurait réinitialisé le fichier /etc/resolv.conf avec les paramètres de la box, en ignorant les modifications faites par net_applet.
En faisant la nouvelle mise à jour du jour (noyau principalement), le fichier /etc/resolv.conf est revenu dans l'ordre.
C'est étrange, les autres machines pour lesquelles j'ai basculé sous NetworkManager n'ont pas eu le souci.
Je vais probablement ouvrir un rapport de bug là-dessus.
Cela pourrait expliquer les bizarreries (à mon sens) que je trouve dans ton /etc/resolv.conf. J'ai l'impression que tu as entré des DNS alternatifs dans l'interface de ta BBOX et c'est ce qu'on retrouve dans ton /etc/resolv.conf
Effectivement, après mise à jour et redémarrage, resolv.conf a été corrigé automatiquement :
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search lan
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search lan
et je peux à présent accéder à l'interface de la BBOX.
Par contre, https://en.internet.nl/ n'est toujours pas content :
squid-f :
As-tu bien ajouté des DNS dans l'interface de ta BBOX ?
Non, je n'ai rien touché dans l'interface de la BBOX...
Édité par joel Le 13/07/2021 à 14h40
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
Bon, cela progresse.
Si je résume :
* Tu utilises bien unbound comme resolver DNS. Les DNS alternatifs dans /etc/resolv.conf venaient d'une modification manuelle et non de la box donc. C'est revenu dans l'ordre.
* Tu as accès à ta box.
* Tu dois avoir accès à internet puisque tu peux faire le test de en.internet.nl.
* Par contre, DNSSEC fait encore la mauvaise tête.
Confirmes-tu tout cela?
Quand tu déplis le bloc de DNSSEC validation en cliquant sur la flèche qui pointe vers le bas, quel est le DNS provider qui apparaît ?
Pourrais-tu poster le résultat de :
Code BASH :
ls -al /etc/unbound
Pour être certain de ce qui se passe, pourrais-tu poster le résultat de :
Code BASH :
systemctl status unbound
et pour aider zatox
, que donne :Code BASH :
systemctl status network
Je viens de voir que la version de unbound a évolué depuis mon tuto.
Il faudrait modifier do-ipv6=no par :
# Prefer ipv4 upstream servers, even if ipv6 is available.
prefer-ip4: yes
do-tcp: yes
# Detach from the terminal, run in background, "yes" or "no".
# Set the value to "no" when unbound runs as systemd service.
do-daemonize: no
prefer-ip4: yes
do-tcp: yes
# Detach from the terminal, run in background, "yes" or "no".
# Set the value to "no" when unbound runs as systemd service.
do-daemonize: no
Je ne pense pas que cela soit le problème car cela fonctionne pour zatox avec le tuto d'origine. Mais, c'est ce que j'ai maintenant pour mes machines.
Redémarrer unbound après modification de /etc/unbound.conf par, en root :
Code BASH :
systemctl restart unbound
puis vérifier par
Code BASH :
systemctl status unbound
Pour do-not-query-localhost:no, les lignes précédentes qui sont commentées sont en fait les valeurs par défaut ; pas besoin de les décommenter donc quand do-not-query-localhost:yes. C'est de l'information.
A+
joel Membre non connecté
squid-f :
Re-
Bon, cela progresse.
Si je résume :
* Tu utilises bien unbound comme resolver DNS. Les DNS alternatifs dans /etc/resolv.conf venaient d'une modification manuelle et non de la box donc. C'est revenu dans l'ordre.
* Tu as accès à ta box.
* Tu dois avoir accès à internet puisque tu peux faire le test de en.internet.nl.
* Par contre, DNSSEC fait encore la mauvaise tête.
Confirmes-tu tout cela?
Bon, cela progresse.
Si je résume :
* Tu utilises bien unbound comme resolver DNS. Les DNS alternatifs dans /etc/resolv.conf venaient d'une modification manuelle et non de la box donc. C'est revenu dans l'ordre.
* Tu as accès à ta box.
* Tu dois avoir accès à internet puisque tu peux faire le test de en.internet.nl.
* Par contre, DNSSEC fait encore la mauvaise tête.
Confirmes-tu tout cela?
Je confirme, sauf que, ce matin, https://en.internet.nl/ me dit
"Domain signature validation (DNSSEC)
Well done! Domain signatures (DNSSEC) are validated for you. Therefore you are protected against false translation from signed domain names into rogue IP addresses. "
Sujet résolu, donc...
Je réponds néanmoins à tes autres questions :
squid-f :
Quand tu déplis le bloc de DNSSEC validation en cliquant sur la flèche qui pointe vers le bas, quel est le DNS provider qui apparaît ?
"Technical details:
DNS provider
GITOYEN-MAIN-AS The main Autonomous System of Gitoyen Paris, France."
squid-f :
Pourrais-tu poster le résultat de :
Code BASH :
ls -al /etc/unbound
Code BASH :
$ ls -al /etc/unbound total 28 drwxr-xr-x 2 unbound root 4096 juil. 13 20:05 ./ drwxr-xr-x 183 root root 12288 juil. 14 07:38 ../ -rw-r--r-- 1 root root 3312 juil. 12 13:30 root.hints -rw-r--r-- 1 unbound unbound 758 juil. 13 20:05 root.key -rw-r--r-- 1 root root 1729 juil. 13 06:54 unbound.conf
squid-f :
Pour être certain de ce qui se passe, pourrais-tu poster le résultat de :
Code BASH :
systemctl status unbound
Code BASH :
$ systemctl status unbound
● unbound.service - Unbound DNS Resolver
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Tue 2021-07-13 13:45:09 CEST; 18h ago
Main PID: 3829 (unbound)
Tasks: 1 (limit: 28643)
Memory: 8.3M
CPU: 2.035s
CGroup: /system.slice/unbound.service
└─3829 /usr/sbin/unbound -c /etc/unbound/unbound.conf
juil. 13 13:45:09 localhost.localdomain systemd[1]: Started Unbound DNS Resolver.
juil. 13 13:45:09 localhost.localdomain unbound[3829]: [3829:0] notice: init module 0: validator
juil. 13 13:45:09 localhost.localdomain unbound[3829]: [3829:0] notice: init module 1: iterator
juil. 13 13:45:09 localhost.localdomain unbound[3829]: [3829:0] info: start of service (unbound 1.13.0).
juil. 13 13:45:09 localhost.localdomain unbound[3829]: [3829:0] info: generate keytag query _ta-4f66. NULL IN
juil. 13 20:05:24 localhost.localdomain unbound[3829]: [3829:0] info: generate keytag query _ta-4f66. NULL IN
squid-f :
et pour aider zatox , que donne :
Je viens de voir que la version de unbound a évolué depuis mon tuto.
Il faudrait modifier do-ipv6=no par :
, que donne :Code BASH :
systemctl status network
Je viens de voir que la version de unbound a évolué depuis mon tuto.
Il faudrait modifier do-ipv6=no par :
# Prefer ipv4 upstream servers, even if ipv6 is available.
prefer-ip4: yes
do-tcp: yes
# Detach from the terminal, run in background, "yes" or "no".
# Set the value to "no" when unbound runs as systemd service.
do-daemonize: no
prefer-ip4: yes
do-tcp: yes
# Detach from the terminal, run in background, "yes" or "no".
# Set the value to "no" when unbound runs as systemd service.
do-daemonize: no
OK, j'ai fait les modifs...
squid-f :
Je ne pense pas que cela soit le problème car cela fonctionne pour zatox avec le tuto d'origine. Mais, c'est ce que j'ai maintenant pour mes machines.
Redémarrer unbound après modification de /etc/unbound.conf par, en root :
puis vérifier par
Redémarrer unbound après modification de /etc/unbound.conf par, en root :
Code BASH :
systemctl restart unbound
puis vérifier par
Code BASH :
systemctl status unbound
Réponse un peu différente :
Code BASH :
$ systemctl status unbound
● unbound.service - Unbound DNS Resolver
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2021-07-14 08:06:03 CEST; 14min ago
Main PID: 334887 (unbound)
Tasks: 1 (limit: 28643)
Memory: 6.2M
CPU: 161ms
CGroup: /system.slice/unbound.service
└─334887 /usr/sbin/unbound -c /etc/unbound/unbound.conf
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 8.000000 16.000000 170
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 16.000000 32.000000 229
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 32.000000 64.000000 290
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 64.000000 128.000000 406
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 128.000000 256.000000 287
juil. 14 08:06:03 localhost.localdomain unbound[3829]: [3829:0] info: 256.000000 512.000000 11
juil. 14 08:06:03 localhost.localdomain unbound[334887]: [334887:0] notice: init module 0: validator
juil. 14 08:06:03 localhost.localdomain unbound[334887]: [334887:0] notice: init module 1: iterator
juil. 14 08:06:03 localhost.localdomain unbound[334887]: [334887:0] info: start of service (unbound 1.13.0).
juil. 14 08:06:03 localhost.localdomain unbound[334887]: [334887:0] info: generate keytag query _ta-4f66. NULL INsquid-f :
Pour do-not-query-localhost:no, les lignes précédentes qui sont commentées sont en fait les valeurs par défaut ; pas besoin de les décommenter donc quand do-not-query-localhost:yes. C'est de l'information.
OK.
Merci beaucoup pour toutes ces explications, squid-f.
Et merci aussi à zatox pour son aide...
zatox Membre non connecté
-
- Voir le profil du membre zatox
- Inscrit le : 27/09/2011
- Groupes :
squid-f :
et pour aider zatox , que donne :
systemctl status network
, que donne :systemctl status network
oui sur mon portable:Caché :
systemctl status network
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated)
Active: active (running) since Wed 2021-07-14 07:59:42 CEST; 58min ago
Docs: man:systemd-sysv-generator(8)
Process: 926 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)
Tasks: 4 (limit: 4545)
Memory: 5.1M
CPU: 1.191s
CGroup: /system.slice/network.service
├─1111 /sbin/ifplugd -I -b -i enp5s0
├─1176 /usr/sbin/wpa_supplicant -B -i wlo1 -c /etc/wpa_supplicant.conf -D wext
├─1178 /sbin/ifplugd -I -b -i wlo1
└─1299 dhclient -1 -q -lf /var/lib/dhclient/dhclient--wlo1.lease -pf /var/run/dhclient>
Warning: some journal files were not opened due to insufficient permissions.
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated)
Active: active (running) since Wed 2021-07-14 07:59:42 CEST; 58min ago
Docs: man:systemd-sysv-generator(8)
Process: 926 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)
Tasks: 4 (limit: 4545)
Memory: 5.1M
CPU: 1.191s
CGroup: /system.slice/network.service
├─1111 /sbin/ifplugd -I -b -i enp5s0
├─1176 /usr/sbin/wpa_supplicant -B -i wlo1 -c /etc/wpa_supplicant.conf -D wext
├─1178 /sbin/ifplugd -I -b -i wlo1
└─1299 dhclient -1 -q -lf /var/lib/dhclient/dhclient--wlo1.lease -pf /var/run/dhclient>
Warning: some journal files were not opened due to insufficient permissions.
Bonne journée.
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
En fait, c’est à Joël que je demandais si network est actif ou pas
Content que cela tourne.
Peut-être une question de cache du navigateur qui faisait que la page de résultats de DNSSEC n’était pas actualisée ?
Tous les tests sont bons.
Je te conseille de vérifier de temps à autre que le dns reste 127.0.0.1 dans le net_applet.
Personnellement, je suis passé à NetworkManger qui est plus stable.
A+
joel Membre non connecté
squid-f :
En fait, c’est à Joël que je demandais si network est actif ou pas
En fait, c’est à Joël que je demandais si network est actif ou pas
Ah ? J'avais pas compris...
$ systemctl status network
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated)
Active: failed (Result: exit-code) since Tue 2021-07-13 13:45:09 CEST; 1 day 3h ago
Docs: man:systemd-sysv-generator(8)
Process: 2829 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
CPU: 4.441s
juil. 14 07:06:00 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat detected.
juil. 14 16:52:00 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat lost.
juil. 14 16:52:01 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat detected.
juil. 14 17:09:38 localhost.localdomain postfix/postfix-script[371425]: refreshing the Postfix mail system
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interv>
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPOFFER of 192.168.1.54 from 192.168.1.254
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPREQUEST for 192.168.1.54 on enp2s0 to 255.255.255.25>
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPACK of 192.168.1.54 from 192.168.1.254
juil. 14 17:09:38 localhost.localdomain postfix/postfix-script[371522]: refreshing the Postfix mail system
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: bound to 192.168.1.54 -- renewal in 37934 seconds.
● network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network; generated)
Active: failed (Result: exit-code) since Tue 2021-07-13 13:45:09 CEST; 1 day 3h ago
Docs: man:systemd-sysv-generator(8)
Process: 2829 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE)
CPU: 4.441s
juil. 14 07:06:00 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat detected.
juil. 14 16:52:00 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat lost.
juil. 14 16:52:01 localhost.localdomain ifplugd(enp2s0)[3113]: Link beat detected.
juil. 14 17:09:38 localhost.localdomain postfix/postfix-script[371425]: refreshing the Postfix mail system
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPDISCOVER on enp2s0 to 255.255.255.255 port 67 interv>
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPOFFER of 192.168.1.54 from 192.168.1.254
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPREQUEST for 192.168.1.54 on enp2s0 to 255.255.255.25>
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: DHCPACK of 192.168.1.54 from 192.168.1.254
juil. 14 17:09:38 localhost.localdomain postfix/postfix-script[371522]: refreshing the Postfix mail system
juil. 14 17:09:38 localhost.localdomain dhclient[3176]: bound to 192.168.1.54 -- renewal in 37934 seconds.
C'est quoi, ce "Active: failed" ?
squid-f :
Content que cela tourne.
Peut-être une question de cache du navigateur qui faisait que la page de résultats de DNSSEC n’était pas actualisée ?
Peut-être une question de cache du navigateur qui faisait que la page de résultats de DNSSEC n’était pas actualisée ?
Ça doit être un truc comme ça...
squid-f :
Tous les tests sont bons.
Je te conseille de vérifier de temps à autre que le dns reste 127.0.0.1 dans le net_applet.
Je te conseille de vérifier de temps à autre que le dns reste 127.0.0.1 dans le net_applet.
OK, il faudra que j'y pense...
squid-f :
Personnellement, je suis passé à NetworkManger qui est plus stable.
Tu fais ça comment ? urpmi networkmanager ? C'est suffisant ?
nic80 Membre non connecté
-
- Voir le profil du membre nic80
- Inscrit le : 06/08/2018
- Groupes :
-
Modérateur
joel Membre non connecté
Et, au fait, je te remercie aussi pour ton aide, en rapport avec la question initiale.
nic80 :
Par contre, ce serait pas mal si la page wiki expliquait l'intérêt de passer à Networkmanager...
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
As-tu le service ModemManager qui tourne ?
Pour l’utilité de NetworkManager, c’est un grand débat.
Perso, je trouve qu’il est plus intuitif et direct pour l’affichage des réseaux wifi disponibles.
Il est aussi plus facile pour le paramétrage de IPv6.
Je le trouve aussi plus stable par rapport au paramètrage spécifique du DNS et bien intégré avec les paramètres KDE.
A+
joel Membre non connecté
squid-f :
Ça, c’est « marrant ». Comme pour zatox avec une de ses machines, tu as network qui tombe.
As-tu le service ModemManager qui tourne ?
As-tu le service ModemManager qui tourne ?
Non. Il sert à quoi ?
Est-ce qu'il faut l'activer au démarrage ?
squid-f :
Pour l’utilité de NetworkManager, c’est un grand débat.
Perso, je trouve qu’il est plus intuitif et direct pour l’affichage des réseaux wifi disponibles.
Perso, je trouve qu’il est plus intuitif et direct pour l’affichage des réseaux wifi disponibles.
Comme il n'y a pas la wifi sur ma machine...
squid-f :
Il est aussi plus facile pour le paramétrage de IPv6.
Je le trouve aussi plus stable par rapport au paramètrage spécifique du DNS et bien intégré avec les paramètres KDE.
Je le trouve aussi plus stable par rapport au paramètrage spécifique du DNS et bien intégré avec les paramètres KDE.
C'est surprenant, parce que, si je comprends bien l'introduction de https://wiki.mageia.org/en/Changer_pour_Networkmanager-fr, c'est un outil Gnome, alors que net_applet est un outil mageia, dont le bureau par défaut est KDE...
squid-f Membre non connecté
-
- Voir le profil du membre squid-f
- Inscrit le : 03/04/2016
- Groupes :
-
Membre d'Honneur
Non, pas besoin d’activer ModemManager. C’est juste qu’il est actif pour zatox alors que ce n’est pas la configuration par défaut.
Je me demandais donc si cela pouvait être lié.
Pour networkmanager, je ne sais pas si c’est un outil Gnome à la base mais il est utilisé par KDE aussi et il y a une extension qui intègre son paramétrage directement dans les paramètres système de KDE. Je l’ai vu aussi dans toutes les distributions KDE que j’ai testées à ce jour.
L’avantage de drakconnect de Mageia est qu’il s’intègre dans le Centre de Contrôle de Mageia, qui est un outil puissant et qui fait partie de la philosophie de Mageia.
J’ai des machines qui sont restées avec cette configuration par défaut et cela ne pose pas de soucis par rapport aux besoins des utilisateurs.
J’ai une préférence personnelle pour networkmanager et cela reste personnel pour les raisons évoquées. Je ne souhaite pas ouvrir un débat sur le sujet.
A+
joel Membre non connecté
OK, merci beaucoup pour toutes ces explications, et pour ton aide.
Je garde donc drakconnect...
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie