Узел MAAS не может разрешить собственное имя хоста

Я развернул сервер региона / стойки MAAS, основной интерфейс которого подключается к WAN, а другой подключается к коммутатору с помощью iptables в качестве моего MAAS-vlan с настройкой DHCP.

У меня есть обнаружил, что не могу получить информацию о хранении с обеих моих двух машин (с различным оборудованием), после нескольких часов обработки я обнаружил, что разрешение имен имеет некоторую ошибку, и узлы не смогли решить свое собственное имя хоста при вводе в эксплуатацию, что также сделало процесс ввода в эксплуатацию длится долго, так как он ждет имя - разрешение на большую часть времени. (это предположение, но после того, как я успешно выполнил вход в поле, ping golden-moose займет около 10 секунд, а затем выбросит ошибку «неизвестного хоста»)

вывод ввода в эксплуатацию 00-maas-07-block-devices.err:

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

Я использую MAAS версии 2.1.1 + bzr5544-0ubuntu1 (16.04.1) и не знаю, как отладить эту проблему, пожалуйста, помогите, спасибо.

Служба DNS, похоже, (! d5)

UPDATE

Я обновил MAAS до 2.1.3 и эту же проблему. После входа в узел ввода в эксплуатацию (по параметру «Разрешить доступ к SSH и запретить запуск машины») я обнаружил, что узел смог пинговать имена хостов ТОЛЬКО с «.maas» APPENDED. Это означает, что имя домена неправильно установлено.

$ hostname -f
hostname: Name or service not known

$ domainname
(none)

Правила iptables работают нормально. Следующие команды все печатают разумные выходы (с ненулевым количеством пакетов)

$ 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

Используя инструмент tcpdump, я проследил узел DNS-запросы.

Типичные запросы узла хоста узла sudo выглядят следующим образом (дважды):

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)

Хотя я заметил бит [bad udp cksum], я позже проверил, что это не влияет на результат узла.

Вызов с чистым млекопитающим с узла ввода в эксплуатацию приведет к журналу:

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)

Этот вызов приводит к действию dig вывод из узла.

Final Update & amp; Заключение

Хотя проблема с именем хоста действительно была там, проблема привела к отсутствию конфигурации хранилища, было нечто совершенно другое.

После нескольких часов проверки и множества советов от @mpontillo, я наконец, сделали ввод в эксплуатацию. Неожиданным было 2 из 3 вариантов ввода в эксплуатацию, то есть «Сохранить конфигурацию сети» и «Сохранять конфигурацию хранилища». Я проверял эти два раза каждый раз, так как я думал, что они должны «сохранить» информацию из узлов. Конфигурация хранилища была прочитана правильно после тех, которые не были проверены.

1
задан 24 January 2017 в 13:40

1 ответ

Во время ввода в эксплуатацию, resolv.conf имеет только сервер имен.

При вводе в эксплуатацию машине сообщается его DNSDOMAIN, но, похоже, что домен не попадает в / etc / resolv.conf

Я написал Bug 1658750 для этой проблемы.

Для ясности, sudo, неспособное разрешить имя, приводит только к напечатанному предупреждающему сообщению: он ничего не делает и sudo делает то, что вы ему сказали. (Он пытается получить имя хоста, чтобы он мог сравнивать его с любыми правилами, запрещенными хостом в sudoers, которых нет.)

3
ответ дан 23 May 2018 в 02:17
  • 1
    Интересно; хорошая находка. В этом случае мне любопытно, почему больше людей не замечают эту проблему. (Например, он отлично работал в моих тестах, и я помогал другим в подобных ситуациях, когда этого не происходит). – mpontillo 23 January 2017 в 22:16

Другие вопросы по тегам:

Похожие вопросы: