Trochę dziś siedziałem nad rekonfiguracją wewnętrznej sieci wirtualnej w laptopie – mam sporo wirtualek, więc używanie wpisów w /etc/hosts już nie wystarczało. DNSmasq mógłby rozwiązać problem, jednak osobiście wolę BINDa – zainstalowałem więc, zchrootowałem, skonfigurowałem jako caching-name server i dodałem obsługę strefy ‘local’ (jako, że używam adresów z taką właśnie końcówką: git.local, dev1.local etc). Miałem jeszcze trochę zabawy z konfiguracją NetworkManagera (Fedora 17), który to nadpisuje /etc/resolv.conf – początkowo chciałem temu plikowi nadać atrybut immutable (chattr +i) tak żeby się NM odczepił, ale to mało koszerne – przypuszczam, że developerzy NM nie brali pod uwagę takiego podejścia użytkownika, więc wpadłbym w bliżej niekreślony wyjątek. Dodałem więc wpisy:
|
1 2 3 |
DNS1=127.0.0.1 DNS2=8.8.8.8 DNS3=8.8.4.4 |
Do /etc/sysconfig/network-scripts/ifcfg-Auto_WLANname i zaczęło to śmigać – po restarcie połączenia /etc/resolv.conf zawierał to co chciałem. Podobnie rozwiązałem problem resolvowania w trakcie połączenia z VPNem.
No i gdy zaczynałem w końcu pracę, okazało się, że nie mogę się podłączyć do VMki:
|
1 2 |
[docent@docent-toshiba ~]$ ssh_git ssh: Could not resolve hostname git.local: Name or service not known |
Dziwna przypadłość. A proszę co tu mamy:
|
1 2 3 4 5 6 |
[docent@docent-toshiba ~]$ cat /etc/resolv.conf # Generated by NetworkManager search local nameserver 127.0.0.1 nameserver 8.8.8.8 nameserver 8.8.4.4 |
No to wtf z tym DNSem?
|
1 2 |
[docent@docent-toshiba ~]$ dig +short git.local 192.168.122.14 |
Teraz więc spory WTF – DNS lokalny działa poprawnie. Hmmm.. Zacząłem podejrzewać, że mój system nagle stwierdził, że domeny ‘local’ to on nie będzie resolwował za pomocą owego lokalnego DNSa. Aby to potwierdzić w ruch poszedł tcpdump: “tcpdump -n port 53″ – w międzyczasie próbując pingować adres ‘git.local’ – i zupełnie nic tcpdump nie wypluł. Skoro więc ping nie chciał resolvować za pomocą DNSa to za pomocą czego? Oczywistą oczywistością jest /etc/hosts ale co więcej? Tym razem strace:
|
1 2 3 4 5 6 |
[docent@docent-toshiba ~]$ strace -e poll,select,connect,recvfrom,sendto ping git.local connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(3, {sa_family=AF_FILE, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) connect(3, {sa_family=AF_FILE, sun_path="/var/run/avahi-daemon/socket"}, 110) = 0 ping: unknown host git.local +++ exited with 2 +++ |
No i jasne – mamy tu nscd (którego u mnie na laptopie brak), a później Avahi – hmm.. a gdzie DNS? No to rzućmy okiem na /etc/nsswitch.conf:
|
1 |
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname |
No i sprawy stają się jasne – żeby się nie rozpisywać odsyłam tutaj: http://avahi.org/wiki/AvahiAndUnicastDotLocal
Rozwiązanie? Są dwa. Albo zmieniamy wpis w /etc/nsswitch.conf na taki jak poniżej (czyli po prostu przestajemy polegać na resolvowaniu adresacji via avahi – jak tego nie używamy to dobre rozwiązanie):
|
1 |
hosts: files dns myhostname |
A drugie to rekonfiguracja Avahi tak jak opisano w powyższym linku:
|
1 2 3 |
#/etc/avahi/avahi-daemon.conf [server] domain-name=.alocal |
Po czym wykonujemy restart usługi i czyszczenie cache przeglądarek.