je suis en train de galérer sur mon réseau local pour faire fonctionner en
harmonie ma passerelle connectée par adsl avec mes postes clients. Ça ne
fonctionne jamais dans son entier :(
- obelix : pécé 2.4.22-xfs (ou winXP mais pas encore testé) |
Debian
192.168.0.10 |
- idefix : pécé win98
192.168.0.20
eth0 sur falbala a une adresse pour pouvoir "attaquer" l'outil de
diagnostic interne du modem en 192.168.1.1
J'utilise (j'essaie) dnsmasq pour assurer les attributions ip via dhcp
(samba est installé et dnsmasq configuré pour servir la résolution wins) et
le dns pour les postes clients.
Ah oui aussi je suis abonné chez dyndns pour le domaine seki.homelinux.net
(j'utilise ddclient avec succès).
Le dhcp fonctionne, y compris pour windows.
Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les adresses
internes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!) qui
sont vus comme des alias (?) à l'adresse publique de ppp0, et ensuite ça
cafouille sur un «sendto opération non permise» qui sent le problème
iptables (?)
Suivant les essais, elle arrive à résoudre les noms de clients locaux mais
alors les clients n'ont plus de dns externe.
Jusqu'à ce que je commence à gérer des postes clients, la connexion adsl
pppoe s'effectuait automatiquement au démarrage ou via pon/poff. La config
a été faite très simplement avec pppoeconf : login/password, recherche dur
fournisseur et ajout automatique des dns dans /etc/resolv.conf
Le fichier /etc/network/interfaces était simpliste (sans les parties "test")
,----
| # The loopback interface
| auto lo
| iface lo inet loopback
| # dns-nameservers 127.0.0.1
| # dns-domain seki.homelinux.net
| # dns-search 127.0.0.1
|
| # connexion vers modem ADSL
| auto eth0
| iface eth0 inet static
| address 192.168.1.5
| netmask 255.255.255.0
| # dns-search tele2.fr
|
| # connexion vers switch
| auto eth1
| iface eth1 inet static
| address 192.168.0.1
| netmask 255.255.255.0
| # dns-nameservers 127.0.0.1
| # dns-domain seki.homelinux.net
`----
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que la
passerelle ne parvenait pas à résoudre les noms locaux et après essais en
rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf le problème
semblé réglé.
MAIS : avec la directive usepeerdns du paramétrage pppoe, à chaque
reconnexion, le fichier est recréé pour contenir les dns tele2 et mon
nameserver local est perdu...
Je pourrais certes "patcher" le script /etc/ppp/ip-up.d/0000userpeerdns
pour ajouter le nameserver manquant mais ça ne me paraît pas très «propre».
Sur ce un correspondant de la liste Debian-french-user me conseille
resolvconf pour gérer les modifications dynamiques de /etc/resolv.conf ce
qui m'a amené à divers tests dans /etc/network/interfaces (commentaires
avec les paramètres dns-domain, dns-search et dns-nameservers avec le s).
Au final j'ai la modif suivante de /etc/network/interfaces :
,----
| # The loopback interface
| auto lo
| iface lo inet loopback
| dns-nameservers 127.0.0.1
| dns-domain seki.homelinux.net
| dns-search 127.0.0.1
|
| # connexion vers modem ADSL
| auto eth0
| iface eth0 inet static
| address 192.168.1.5
| netmask 255.255.255.0
| dns-search tele2.fr
|
| (le reste est identique)
`----
Qui me permet d'avoir le dns ok sur les clients (interne et externe) et la
passerelle (externe uniquement).
Mais si je tente par exemple un ping obelix, voilà le résultat :
,----
| falbala:~# ping obelix
| PING seki.homelinux.net (213.103.9.213): 56 data bytes
| ping: sendto: Operation not permitted
| ping: wrote seki.homelinux.net 64 chars, ret=-1
| ... en boucle
`----
Le nom n'est pas résolu correctement, quand à l'erreur sendto, ça ressemble
à un problème netfilter consécutif au premier (alors que ping www.google.fr
fonctionne normalement).
Voilà (ouf) c'est un peu long, mais j'espère avoir été clair.
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement ma
résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script standard.
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça marche) mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques : - désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up qui modifient /etc/resolv.conf - ejection de l'outil resolvconf - modification de /etc/resolv.conf pour n'avoir que le nameserver local - modification de /etc/hosts pour ajouter les ip des postes locaux - modification de /etc/dnsmasq.conf pour utiliser les ip de hosts pour l'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il ne sert plus les noms fournis par les dns du fai aux clients (ping ou dig google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et mes ennuis ne seront plus que des souvenirs :)
Sébastien Kirche
Bonsoir,
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça marche)
mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques :
- désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up qui
modifient /etc/resolv.conf
- ejection de l'outil resolvconf
- modification de /etc/resolv.conf pour n'avoir que le nameserver local
- modification de /etc/hosts pour ajouter les ip des postes locaux
- modification de /etc/dnsmasq.conf pour utiliser les ip de hosts pour
l'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il ne
sert plus les noms fournis par les dns du fai aux clients (ping ou dig
google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers
le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça
il veut bien.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est
pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et mes
ennuis ne seront plus que des souvenirs :)
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça marche) mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques : - désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up qui modifient /etc/resolv.conf - ejection de l'outil resolvconf - modification de /etc/resolv.conf pour n'avoir que le nameserver local - modification de /etc/hosts pour ajouter les ip des postes locaux - modification de /etc/dnsmasq.conf pour utiliser les ip de hosts pour l'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il ne sert plus les noms fournis par les dns du fai aux clients (ping ou dig google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et mes ennuis ne seront plus que des souvenirs :)
Sébastien Kirche
TiChou
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça marche) mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques : - désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up quimodifient /etc/resolv.conf - ejection de l'outil resolvconf - modification de /etc/resolv.conf pour n'avoir que le nameserver local - modification de /etc/hosts pour ajouter les ip des postes locaux
Ça n'était pas utile vu que dnsmasq sait renseigner les noms de machines locales de la même manière que le fait le fichier /etc/hosts.
- modification de /etc/dnsmasq.conf pour utiliser les ip de hosts pourl'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il ne sert plus les noms fournis par les dns du fai aux clients (ping ou dig google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et mes ennuis ne seront plus que des souvenirs :)
Et tu attends quoi pour grandir alors ? :p
-- TiChou
Dans le message <news:85brksqg8w.fsf@seki.homelinux.net>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça
marche) mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques :
- désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up
quimodifient /etc/resolv.conf
- ejection de l'outil resolvconf
- modification de /etc/resolv.conf pour n'avoir que le nameserver local
- modification de /etc/hosts pour ajouter les ip des postes locaux
Ça n'était pas utile vu que dnsmasq sait renseigner les noms de machines
locales de la même manière que le fait le fichier /etc/hosts.
- modification de /etc/dnsmasq.conf pour utiliser les ip de hosts
pourl'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il
ne sert plus les noms fournis par les dns du fai aux clients (ping
ou dig google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde
vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug
?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les
options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme
ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier
mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la
varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce
n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et
mes ennuis ne seront plus que des souvenirs :)
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
Bon j'ai enfin testé cette solution et je m'en suis sorti (i.e ça marche) mais pas comme j'aurais voulu. Je comprend pas.
J'ai suivi tes conseils qui semblaient logiques : - désactivation des scripts /etc/ppp/ip-up.d/0000useperrdns et 0dns-up quimodifient /etc/resolv.conf - ejection de l'outil resolvconf - modification de /etc/resolv.conf pour n'avoir que le nameserver local - modification de /etc/hosts pour ajouter les ip des postes locaux
Ça n'était pas utile vu que dnsmasq sait renseigner les noms de machines locales de la même manière que le fait le fichier /etc/hosts.
- modification de /etc/dnsmasq.conf pour utiliser les ip de hosts pourl'attribution dhcp et utiliser /etc/ppp/resolv.conf pour les dns
Comme ça, marche pas. Le dhcp roule sans problèmes, mais côté dns, il ne sert plus les noms fournis par les dns du fai aux clients (ping ou dig google.fr depuis obelix ne marche pas) ni pour lui même.
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
Mais bon... Quand je serais grand j'aurais mon domaine en ip fixe et mes ennuis ne seront plus que des souvenirs :)
Et tu attends quoi pour grandir alors ? :p
-- TiChou
Sebastien Kirche
On 13 mai 2004, wrote:
[...]
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
[...]
JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!!
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à la place du resolv.conf. Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je remarque qu'il précise dans le syslog «using nameserver xxx» pour chaque paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres et réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ? «Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq (dixit top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root. Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Sébastien Kirche
On 13 mai 2004, gro.uohcit@uohcit wrote:
[...]
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde
vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug
?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les
options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et
comme ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier
mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la
varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce
n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
[...]
JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!!
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à la
place du resolv.conf.
Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je remarque
qu'il précise dans le syslog «using nameserver xxx» pour chaque paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres et
réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ?
«Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq (dixit
top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root.
Ça y est en creusant un peu, je croyais que ça venait du lancement par init,
mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule
tout seul en "nobody".
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça
soit la meilleure solution...
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la
perfection :)
Les logs montrent bien les requêtes, mais aucune trace qu'il forwarde vers le fai lorsqu'il ne sait pas.
Comme si le paramètre resolv-file=/etc/ppp/resolv.conf était ignoré (bug ?).
Tu peux donner le contenu de ton fichier dnsmasq.conf ? Ainsi que les options et paramètres passés à dnsmasq quand il est lancé ?
Par contre j'ai ajouté les dns «à la main» dans /etc/resolv.conf et comme ça il veut bien.
Dans ce cas il vaut mieux laisser 'nameserver 127.0.0.1' dans ce fichier mais mettre les adresses des dns dans le fichier dnsmasq.conf avec la varaible 'server='.
Du coup, la fourniture des dns à la négociation ppp ne sert à rien. Ce n'est pas dynamique (je sais, ça change moins souvent que mon ip).
Ça marche donc, mais pas comme je veux :)
Oui, mais on ne vas pas s'arreter là. ;)
[...]
JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!! - JE SUIS UN ÂNE !!!
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à la place du resolv.conf. Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je remarque qu'il précise dans le syslog «using nameserver xxx» pour chaque paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres et réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ? «Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq (dixit top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root. Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Sébastien Kirche
TiChou
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à la place du resolv.conf. Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je remarque qu'il précise dans le syslog «using nameserver xxx» pour chaque paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres et réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ? «Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq (dixit top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root. Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier /etc/ppp/resolv.conf a pour groupe dip. Bref, regarde à ce niveau là et vérifie quels sont les permissions du fichier /etc/pppd/resolv.conf.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
-- TiChou
Dans le message <news:854qqkqc4p.fsf@seki.homelinux.net>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à
la place du resolv.conf.
Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je
remarque qu'il précise dans le syslog «using nameserver xxx» pour chaque
paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres
et réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ?
«Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq
(dixit top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root.
Ça y est en creusant un peu, je croyais que ça venait du lancement par
init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis
bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd
doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier
/etc/ppp/resolv.conf a pour groupe dip.
Bref, regarde à ce niveau là et vérifie quels sont les permissions du
fichier /etc/pppd/resolv.conf.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que
ça soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de
la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
Dans le message <news:, *Sebastien Kirche* tapota sur f.c.o.l.configuration :
J'ai voulu tester la solution du paramètre server=xxx dans dnsmasq.conf à la place du resolv.conf. Au (re)démarrage de dnsmasq via «/etc/init.d/dnsmasq restart» je remarque qu'il précise dans le syslog «using nameserver xxx» pour chaque paramètre.
Je ne sais pas pourquoi, une intuition m'a fait enlever ces paramètres et réutiliser resolv-file=/etc/ppp/resolv.conf pour voir.
Et je vois quoi dans le syslog ? Mmh je vous le donne Émile ? «Failed to read /etc/ppp/resolv.conf : Permission denied» :( AAARGH !
Bah oui, ce resolv.conf et /etc/ppp/ appartiennent à root, or dnsmasq (dixit top) est "nobody".
Bizarre, /usr/sbin/dnsmasq indique appartenir à root/root. Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier /etc/ppp/resolv.conf a pour groupe dip. Bref, regarde à ce niveau là et vérifie quels sont les permissions du fichier /etc/pppd/resolv.conf.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
-- TiChou
Sebastien Kirche
On 13 mai 2004, wrote:
Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier /etc/ppp/resolv.conf a pour groupe dip. Bref, regarde à ce niveau là et vérifie quels sont les permissions du fichier /etc/pppd/resolv.conf.
root/root, avec seul root autorisé à lire. J'ai changé ça en root/dip pour /etc/ppp et resolv.conf avec autorisation de lecture au groupe pour resolv.conf.
Et j'ai setgidé dnsmasq en dip.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Bon, là j'ai supprimé le user=root (beerk) du dnsmasq.conf et relancé, il arrive bien à exploiter le fichier /etc/ppp/resolv.conf
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
Chouette. Si j'était petit, bleu, et grognon je dirais : «Moi j'aime pas les à-peu-près» :)
Merci pour le soutien. Je vais bien dormir ce soir :)
Sébastien Kirche
On 13 mai 2004, gro.uohcit@uohcit wrote:
Ça y est en creusant un peu, je croyais que ça venait du lancement par
init, mais c'est documenté dans le Foutu MANuel : il démarre en root
puis bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd
doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier
/etc/ppp/resolv.conf a pour groupe dip.
Bref, regarde à ce niveau là et vérifie quels sont les permissions du
fichier /etc/pppd/resolv.conf.
root/root, avec seul root autorisé à lire.
J'ai changé ça en root/dip pour /etc/ppp et resolv.conf avec autorisation de
lecture au groupe pour resolv.conf.
Et j'ai setgidé dnsmasq en dip.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça
soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Bon, là j'ai supprimé le user=root (beerk) du dnsmasq.conf et relancé, il
arrive bien à exploiter le fichier /etc/ppp/resolv.conf
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de
la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
Chouette. Si j'était petit, bleu, et grognon je dirais : «Moi j'aime pas les
à-peu-près» :)
Ça y est en creusant un peu, je croyais que ça venait du lancement par init, mais c'est documenté dans le Foutu MANuel : il démarre en root puis bascule tout seul en "nobody".
Il est sensé se lancer sous le groupe dip s'il existe et en principe pppd doit être setgid dip. Ce qui fait que quand pppd est lancé, le fichier /etc/ppp/resolv.conf a pour groupe dip. Bref, regarde à ce niveau là et vérifie quels sont les permissions du fichier /etc/pppd/resolv.conf.
root/root, avec seul root autorisé à lire. J'ai changé ça en root/dip pour /etc/ppp et resolv.conf avec autorisation de lecture au groupe pour resolv.conf.
Et j'ai setgidé dnsmasq en dip.
Corrigé avec user=root dans dnsmasq.conf, mais je ne suis pas sûr que ça soit la meilleure solution...
Oui, ce n'est pas ce qui a de plus secure.
Bon, là j'ai supprimé le user=root (beerk) du dnsmasq.conf et relancé, il arrive bien à exploiter le fichier /etc/ppp/resolv.conf
Je sais je suis chiTUUT. Mais bon... Enfin là, on approche de la perfection :)
Alors je suis chiTUUT aussi, car je n'admets que la perfection. :p
Chouette. Si j'était petit, bleu, et grognon je dirais : «Moi j'aime pas les à-peu-près» :)
