Eu tenho uma configuração do MAAS que é executada como uma VM no VmWare Workstation e seu DNS interno funciona perfeitamente com as máquinas que ele implantou (pode ser virtual ou físico, com o juju como um controlador). Estou agora no processo de migrar minha configuração do Vmware Workstation para VMware ESXi, e tenho alguns problemas com o DNS interno do MAAS, que não funcionam mais quando rodando no ESXi. Se eu fizer um nslookup para resolver o nome do host da máquina B da máquina A (ambos implementados pelo MAAS), tenho sistematicamente um erro "NXDOMAIN".
Um nmap do MAAS vm, realizado a partir de uma máquina implementada pelo MAAS, me dá isto:
Nmap scan report for maas.maas (192.168.2.2)
Host is up (0.000092s latency).
Not shown: 993 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
3128/tcp open squid-http
3260/tcp open iscsi
7911/tcp open unknown
8000/tcp open http-alt
Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
Portanto, meu serviço dns é executado corretamente e é acessível.
Aqui está minha configuração do resolv.conf em todas as máquinas implementadas pelo MAAS:
nameserver 192.168.2.2
search maas
Eu tenho mais; o comando "dig maas" é bem sucedido:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> maas
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40481
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;maas. IN A
;; ANSWER SECTION:
maas. 30 IN A 192.168.2.2
;; AUTHORITY SECTION:
maas. 30 IN NS maas.
;; Query time: 0 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed May 09 09:27:14 UTC 2018
;; MSG SIZE rcvd: 63
MAS "dig gpux1" não me responda (gpux1 é uma máquina implementada com juju):
; <<>> DiG 9.10.3-P4-Ubuntu <<>> gpux1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 63702
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;gpux1. IN A
;; AUTHORITY SECTION:
. 8654 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018050900 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 192.168.2.2#53(192.168.2.2)
;; WHEN: Wed May 09 09:32:46 UTC 2018
;; MSG SIZE rcvd: 109
É como se o gpux1 fosse desconhecido pelo MAAS dns (bind9). Mas quando eu verifico os arquivos de configuração bind9, eu tenho isto:
"zone.2.168.192.in-addr.arpa" arquivo de configuração:
$TTL 30
@ IN SOA maas. nobody.example.com. (
0000000049 ; serial
600 ; Refresh
1800 ; Retry
604800 ; Expire
30 ; NXTTL
)
@ 30 IN NS maas.
$GENERATE 191-254 $.2.168.192.in-addr.arpa. IN PTR 192-168-2-$.maas.
22 30 IN PTR k8s-juju-controller.maas.
23 30 IN PTR k8s-master.maas.
2 30 IN PTR maas.maas.
24 30 IN PTR k8s-easyrsa.maas.
26 30 IN PTR gpux2.maas.
25 30 IN PTR gpux1.maas.
arquivo de configuração "zone.maas":
$TTL 30
@ IN SOA maas. nobody.example.com. (
0000000049 ; serial
600 ; Refresh
1800 ; Retry
604800 ; Expire
30 ; NXTTL
)
@ 30 IN NS maas.
$GENERATE 191-254 192-168-2-$ IN A 192.168.2.$
k8s-easyrsa 30 IN A 192.168.2.24
gpux1 30 IN A 192.168.2.25
k8s-master 30 IN A 192.168.2.23
virbr0.maas 30 IN A 192.168.122.1
k8s-juju-controller 30 IN A 192.168.2.22
maas 30 IN A 192.168.2.2
gpux2 30 IN A 192.168.2.26
@ 30 IN A 192.168.2.2
Então, tudo parece bem, mas não está funcionando! Estou totalmente preso a essa situação, esse bug é muito chato.