[GLIBC] Pb connexion internet suite à MAJ (demande info)

[Amethyste]

Bonjour

Suite à une mise une mise à jour ce matin, j'ai un bug qui ressemble furieusement à celui-ci
http://forums.archlinux.fr/topic9208.html
Je suis donc repassé de la glibc 2.15-7 à 2.15-6 et tout semble être redevenu à la normale.

Je voudrais simplement que quelqu'un d'autre me confirme le retour du bug avant d'ouvrir un rapport. Merci d'avance

[onyx67]

Salut,
J'ai le même soucis depuis quelques jours:
- lorsque j'ouvre une page firefox je suis obligé de recharger pour afficher la page (aléatoire)
- je dois procéder à un "envoyer/recevoir" pour télécharger mes couriels avec évolution
- applet météo à recharger manuellement
- lors d'une mise à jour avec yaourt -Syua, il me renvoie "can't resolve hostname, faut que je m'y prenne à 2 fois pour que ça marche.
J'ai lu le topic de ton lien et éssayé de rétrogradé à la version antérieur de glibc, mais bizarrement elle est absente du cache pacman (je ne fais jamais de Pacman -Scc.
Je tente avec:

Code : Tout sélectionner

pacman -U http://arm.konnichi.com/core/os/x86_64/glibc-2.15-6-x86_64.pkg.tar.xz

mais pacman me retourne qu'il ne trouve pas le paquet (impossible de trouver ou lire le paquet)
Faut-il que je mette dans la liste des miroir?

Code : Tout sélectionner

Server = http://arm.konnichi.com/2010/05/01/$repo/os/$arch/

Puis effectué pacman -Syy avant d'installer?

[oloꟼ]

Oui c'est bien le même souci. C'est parce que les serveurs de noms (DNS) que vous utilisez sont, je cite, « merdiques ». Le seul moyen de résoudre ce problème est de faire un, je cite, « patch/coutournement merdique » sur la glibc.

Sauvez un développeur, changez de DNS !

Trouver de bons DNS c'est pas très dur, il suffit de connaitre le nom des bons fournisseurs d'accès
Ceux qui sont gérés par des passionnés ! Un indice : http://wiki.auto-hebergement.fr/fournis ... il_des_fai

[FoolEcho]

C'est parce que les serveurs de noms (DNS) que vous utilisez sont, je cite, « merdiques ».

«Il» se reconnaîtra (je m'en rappelle pour avoir vu passer le sujet ).

[benjarobin]

@onyx67 Le problème ne vient pas de GLIBC mais de ton serveur de DNS qui est de mauvaise qualité. Il faut installer et configurer BIND en tant que cache DNS pour contourner le problème.

Edit : Grillé... Sinon tu peux utiliser/configurer BIND ce sera même plus rapide qu'un bon DNS

[onyx67]

@benjarobin: comment procéder pour utiliser/configurer BIND; j'ai bien chercher sur le wiki, mais il est en anglais (maîtrise que très moyennement!) ou à la limite, disposes-tu d'un tuto en français?

[benjarobin]

Si tu n'es pas pressé je pourrais essayer de te répondre/détailler ce soir, voir lundi car je suis assez occupé

[onyx67]

Si tu n'es pas pressé je pourrais essayer de te répondre/détailler ce soir, voir lundi car je suis assez occupé

OK pas de soucis, merci

[Amethyste]

Perso, j'ai simplement suivi le chapitre 1 du wiki anglais :
- Déjà installer BIND

- Editer le fichier /etc/named.conf et rajouter dans la section "option"

Code : Tout sélectionner

listen-on { 127.0.0.1; };

De mémoire, en fait il n'y a qu'une ligne à décommenter, bref

- Dans /etc/rc.conf ajouter le daemon "named"

Code : Tout sélectionner

DAEMONS=(.. named ..)

- Editer /etc/resolv.conf

Code : Tout sélectionner

nameserver 127.0.0.1

cependant, il se peut que le resolv.conf soit auto généré au démarrage, écrasant ainsi la config. Perso, j'ai rajouté à la fin du fichier /etc/dhcpd.conf la ligne suivante

Code : Tout sélectionner

nohook resolv.conf

mais oloꟼ a proposé une autre solution dans le topic cousin que je n'ai pas encore essayé

Cela a suffit pour moi pour résoudre le problème

[benjarobin]

Personnellement voici ma configuration : cat /etc/named.conf

Code : Tout sélectionner

options {
        directory "/var/named";
        pid-file "/var/run/named/named.pid";
        auth-nxdomain yes;
        datasize default;
        listen-on-v6 { none; };
        listen-on { 127.0.0.1; };

        allow-query { 127.0.0.1; };
        allow-recursion { 127.0.0.1; };
        allow-transfer { none; };
        allow-update { none; };
        # DNS locale permettant un accès plus rapide que de faire une résolution complète
        forwarders { 192.168.0.254; 8.8.8.8; };

        version none;
        hostname none;
        server-id none;
};

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-transfer { any; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "127.0.0.zone";
        allow-transfer { any; };
};

zone "." IN {
        type hint;
        file "root.hint";
};

logging {
         channel xfer-log {
             file "/var/log/named.log";
             print-category yes;
             print-severity yes;
             print-time yes;
             severity info;
        };
        category xfer-in { xfer-log; };
        category xfer-out { xfer-log; };
        category notify { xfer-log; };
};

De plus je ne lance pas named directement, j'utilise https://wiki.archlinux.org/index.php/BIND_%28chroot%29

[onyx67]

Merci beaucoup à tous les deux. Je vais travailler çà ce WE et ferai un retour quand au résultat.

[onyx67]

@benjarobin: j'ai tenté la config que tu as proposé (et celle de BIND-chroot du lien) mais cela n'a pas fonctionné bien qu'ayant méticuleusement respecté le wiki. En revanche la congif d'Amethyste fonctionne très bien...
A ce stade je me pose la question sur les éventuelles failles de sécurité avec BIND. Qu'en est-il au juste? L'installation d'un pare-feu (iptables?)devient-elle indispensable?
Encore merci pour toute votre aide.

[benjarobin]

J'avais un peu adapter le wiki aussi
L'installation d'iptables n'est pas forcément indispensable, BIND n'a pas plus de droit qu'un autre processus réseau ou écoutant un port. Ici on n'écoute que 127.0.0.1, donc normalement personne d'autre que ton PC peux utiliser BIND. Le chroot n'est qu'une sécurité supplémentaire

[onyx67]

merci