O nó MAAS não consegue resolver seu próprio nome de host

Question

Eu implantei um servidor de região / rack MAAS, com a interface eth principal conectada à WAN e outra conectada a um switch por usando iptables como meu MAAS-vlan com DHCP configurado.

Descobri que não consigo obter informações de armazenamento de minhas duas máquinas (com hardware diferente), depois de algumas horas de pesquisa descobri que a resolução de nomes tem algum erro e os nós não conseguiram resolver seu próprio nome de host no comissionamento, que também tornou o processo de comissionamento dolorosamente longo, já que ele está aguardando a resolução de nomes para expirar a maior parte do tempo. (isso é um palpite, mas depois que eu loguei com sucesso na caixa, ping golden-moose levaria uns 10 segundos e depois lançaria um erro "host desconhecido")

a saída de comissionamento 00-maas-07-block-devices.err diz:

sudo: unable to resolve host golden-moose: Connection timed out
sudo: unable to resolve host golden-moose: Connection timed out
sudo: unable to resolve host golden-moose: Connection timed out
sudo: unable to resolve host golden-moose: Connection timed out

Estou usando o MAAS Versão 2.1.1 + bzr5544-0ubuntu1 (16.04.1) e não sei como depurar este problema, por favor me ajude, obrigado.

O serviço DNS parece estar funcionando OK, os nós foram capazes de resolver ambos os hosts externos e o domínio .maas.

UPDATE

Atualizei o MAAS para o 2.1.3 e o mesmo problema. Depois de entrar em um nó de comissionamento (pela opção "Permitir acesso SSH e impedir que a máquina desligue"), descobri que o nó conseguiu fazer ping de nomes de host SOMENTE COM ".maas" APLICADO. O que significa que o nome de domínio não foi definido corretamente.

$ hostname -f
hostname: Name or service not known

$ domainname
(none)

As regras do iptables parecem funcionar bem. Todos os comandos a seguir imprimem saídas razoáveis (com contagens de pacotes diferentes de zero)

$ sudo iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 645K packets, 185M bytes)
Chain OUTPUT (policy ACCEPT 411K packets, 1140M bytes)

$ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 73538 packets, 11M bytes)
Chain INPUT (policy ACCEPT 62414 packets, 9009K bytes)
Chain OUTPUT (policy ACCEPT 6585 packets, 493K bytes)
Chain POSTROUTING (policy ACCEPT 360 packets, 54084 bytes)

$ sudo iptables -t filter -L -n -v
Chain INPUT (policy ACCEPT 1772K packets, 875M bytes)
Chain FORWARD (policy DROP 694 packets, 185K bytes)
Chain OUTPUT (policy ACCEPT 1033K packets, 2318M bytes)

UPDATE - DNS dump

Usando a ferramenta tcpdump, rastreei as consultas DNS do nó.

As consultas típicas de nome de host de nó por sudo são semelhantes às seguintes (duas vezes):

11:48:02.836710 IP (tos 0x0, ttl 64, id 53634, offset 0, flags [DF], proto UDP (17), length 57)
    <node-ip>.35343 > <maas-ip>.53: [udp sum ok] 8298+ A? pure-mammal. (29)
11:48:02.836750 IP (tos 0x0, ttl 64, id 53635, offset 0, flags [DF], proto UDP (17), length 57)
    <node-ip>.35343 > <maas-ip>.53: [udp sum ok] 36815+ AAAA? pure-mammal. (29)
11:48:02.836938 IP (tos 0x0, ttl 64, id 40343, offset 0, flags [none], proto UDP (17), length 132)
    <maas-ip>.53 > <node-ip>.35343: [bad udp cksum 0x71e4 -> 0x8095!] 36815 NXDomain q: AAAA? pure-mammal. 0/1/0 ns: . [2h34m56s] SOA a.root-servers.net. nstld.verisign-grs.com. 2017012101 1800 900 604800 86400 (104)
11:48:02.836945 IP (tos 0x0, ttl 64, id 40461, offset 0, flags [none], proto UDP (17), length 132)
    <maas-ip>.53 > <node-ip>.35343: [bad udp cksum 0x71e4 -> 0x0afb!] 8298 NXDomain q: A? pure-mammal. 0/1/0 ns: . [2h34m56s] SOA a.root-servers.net. nstld.verisign-grs.com. 2017012101 1800 900 604800 86400 (104)

Embora eu note [bad udp cksum] bit, verifiquei mais tarde que não estava afetando o resultado do nó.

Uma chamada de digitação com pure-mammal.maas do nó de comissionamento resultaria em log:

11:50:57.723037 IP (tos 0x0, ttl 64, id 24007, offset 0, flags [none], proto UDP (17), length 73)
    <node-ip>.53704 > <maas-ip>.53: [udp sum ok] 5376+ [1au] A? pure-mammal.maas. ar: . OPT UDPsize=4096 (45)
11:50:57.723321 IP (tos 0x0, ttl 64, id 5403, offset 0, flags [none], proto UDP (17), length 119)
    <maas-ip>.53 > <node-ip>.53704: [bad udp cksum 0x71d7 -> 0x8af0!] 5376* q: A? pure-mammal.maas. 1/1/2 pure-mammal.maas. [30s] A <node-ip> ns: maas. [30s] NS maas. ar: maas. [30s] A <maas-ip>, . OPT UDPsize=4096 (91)

Esta chamada resulta na saída de escavação válida do nó.

Atualização final & amp; Conclusão

Embora o problema do nome do host estivesse realmente lá, o problema que levou à falta de configuração de armazenamento era algo completamente diferente.

Após horas de verificação e muitos conselhos de @mpontillo, eu finalmente fiz o trabalho de comissionamento. A surpresa foi a 2 das 3 opções de comissionamento, ou seja, "Manter configuração de rede" e "Manter configuração de armazenamento". Eu verifiquei os 2 todas as vezes, como eu pensei que eram para "reter" as informações dos nós. A configuração de armazenamento foi lida corretamente depois daquelas desmarcadas.

    

Answer 1

Primeiro, recomendo que você atualize para o MAAS 2.1.3, que está disponível em xenial-updates , e tente o comissionamento novamente. Isso excluirá quaisquer problemas conhecidos.

Pensando neste problema, a mensagem Connection timed out é o que mais me preocupa. Isso significa que você não está obtendo uma resposta do servidor DNS, por isso acho que esse problema provavelmente será um problema de conectividade do DNS. Para resolver isso, talvez seja necessário ver a saída dos seguintes comandos em seu servidor MAAS de hospedagem dupla:

sudo iptables -t raw -L -n -v
sudo iptables -t nat -L -n -v
sudo iptables -t filter -L -n -v

Se as regras do firewall parecem boas, eu solucionaria então comissionando o nó com a opção Allow SSH access and prevent machine from powering off . Em seguida, digite SSH e use dig $(hostname -f) para verificar se você pode resolver o host a partir do próprio nó de comissionamento. Você também pode experimentar host $(hostname) , o que testaria se o caminho de pesquisa está funcionando bem.

Em seguida, eu verificaria /etc/bind/maas/named.conf.maas no servidor MAAS para garantir que a rede da qual você está tentando acessar o MAAS esteja na lista de redes confiáveis. (O MAAS deve atualizar automaticamente esta ACL.)

Finalmente, verifique o syslog no servidor MAAS para ter certeza de que tudo está bem, como grep named /var/log/syslog .

Algo relacionado é bug # 1087183 , que fala sobre o fato de que um padrão A instalação do Ubuntu adiciona uma linha com o nome do host a /etc/hosts , mas no MAAS isso causou problemas, então o MAAS deve confiar no DNS.

    

Answer 2

Durante o comissionamento, o resolv.conf tem apenas um servidor de nomes. Quando implantamos, ele tem uma lista de pesquisa completa, com o nome da máquina primeiro, é claro.

Durante o comissionamento, a máquina recebe o comando DNSDOMAIN, mas parece que o domínio não entra no /etc/resolv.conf

Eu arquivei o Bug 1658750 para este problema.

Para maior clareza, se o sudo não conseguir resolver o nome, os resultados serão exibidos apenas naquela mensagem de aviso: ele não faz mais nada e o sudo faz o que você mandou. (Ele está tentando obter o nome do host para que ele possa compará-lo com qualquer regra bloqueada pelo host em sudoers, dos quais não há nenhum).