Узел МААСА, не могущий разрешить свое собственное имя хоста

Я развернул регион/стоечный сервер МААСА с основными подключениями интерфейса eth к WAN, и другой соединяется с переключателем при помощи iptables как мой VLAN Мааса с настроенным DHCP.

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

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

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

Услуга DNS, кажется, работает хорошо, узлы смогли разрешить и внешние хосты и .maas домен.

ОБНОВЛЕНИЕ

Я обновил МААС к 2.1.3, и та же проблема. После вхождения в узел ввода в действие (опцией "Allow SSH access and prevent machine from powering off"), я нашел, что узел смог проверить с помощью ping-запросов имена хостов ТОЛЬКО С ДОБАВЛЕННЫМ ".maas". Что означает, что доменное имя не было правильно установлено.

$ 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)

ОБНОВЛЕНИЕ - дамп DNS

Используя 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] бит, я проверил позже, что он не влиял на результат узла.

Вырыть вызов с чистым-mammal.maas от узла ввода в действие привел бы к журналу:

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)

Это допустимые результаты вызова роет вывод от узла.

Заключительное Обновление и Заключение

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

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

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

2 ответа

Во-первых, я рекомендую обновить к МААСУ 2.1.3, который доступен в xenial-updates, и попробуйте ввод в действие снова. Это исключит любые известные проблемы.

Взгляды об этой проблеме, эти Connection timed out сообщение - то, что волнует меня больше всего. Это означает, что Вы не получаете ответ от сервера DNS, таким образом, я думаю, что этой проблемой, очень вероятно, будет проблема возможности соединения DNS. Для решения этого мы, возможно, должны были бы видеть вывод следующих команд на размещенном двойным образом сервере МААСА:

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

, Если бы правила брандмауэра выглядят хорошими, я затем диагностировал бы путем ввода в действие узла с Allow SSH access and prevent machine from powering off опция. Затем SSH в и использование dig $(hostname -f), чтобы проверить, что можно разрешить хост от самого узла ввода в действие. Вы могли попробовать host $(hostname) также, который протестирует это, путь поиска работает хорошо.

Затем я проверил бы /etc/bind/maas/named.conf.maas на сервере МААСА, чтобы гарантировать, что сеть, от которой Вы пытаетесь достигнуть МААСА, находится в списке надежных сетей. (МААС должен автоматически обновить этот ACL.)

Наконец, проверьте системный журнал на сервере МААСА, чтобы удостовериться, что все смотрит хорошо, такой как grep named /var/log/syslog.

Несколько связанный ошибка № 1087183 , который говорит о том, что стандартная установка Ubuntu добавляет строку с именем хоста к /etc/hosts, но в МААСЕ, который вызвал проблемы, таким образом, МААС должен полагаться на DNS.

1
ответ дан 3 December 2019 в 06:55

При вводе в действие resolv.conf имеет только сервер имен. Когда мы развертываемся, это имеет полный поисковый список, с названием машины сначала, конечно.

При вводе в действие, машине говорят ее DNSDOMAIN, но кажется, что домен не входит в/etc/resolv.conf

, который я зарегистрировал Ошибка 1658750 для этой проблемы.

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

3
ответ дан 3 December 2019 в 06:55

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

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