root@testpgmaster:/# puppetd --test
info: Creating a new SSL key for testpgmaster
warning: peer certificate won't be verified in this SSL session
info: Caching certificate for ca
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
info: Creating a new SSL certificate request for testpgmaster
info: Certificate Request fingerprint (md5): C9:83:59:EF:6A:B8:16:31:B6:92:5D:70:F1:67:39:4F
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
warning: peer certificate won't be verified in this SSL session
Exiting; no certificate found and waitforcert is disabled
root@testpgmaster:/#
Это нормальный вывод, и результатом, как и ожидалось, является правильное создание запроса сертификата. Проблема в том, что почти каждый раз, когда отображается предупреждение, происходит задержка около двух минут.
При выполнении той же команды с strace, в хаотическом выводе strace у меня где-то есть:
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
fcntl(6, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(6, {sa_family=AF_INET, sin_port=htons(8140), sin_addr=inet_addr("10.0.2.15")}, 16) = -1 EINPROGRESS (Operation now in progress)
...
[lots of intermediate output]
...
select(7, [6], [], [], {119, 999900}) <- The pause occurs here
AFAIU, это означает, что он блокируется, ожидая ответа от мастера марионеток.
Puppetmaster запускает пассажира на apache2, прослушивая порт 8140. Он также имеет межсетевой экран, но порт 8140 позволяет агенту. Фактически агент - это контейнер openvz, работающий внутри машины, который действует как мастер; контейнер использует NAT, а хост выполняет пересылку; определенно может быть проблема с настройкой всего этого, но проблема возникает только тогда, когда появляется сообщение «предупреждение: сертификат узла не будет проверен в этом сеансе SSL»; во всех остальных случаях все работает без проблем.
Проблема возникла, когда хозяин марионетки пытался разрешить имя клиента по его IP-адресу. Из-за неправильной конфигурации брандмауэра входящие UDP-пакеты фильтровались, что означает, что время ожидания любого DNS-запроса истекло.
Я обнаружил проблему, запустив wirehark на мастере марионетки, поскольку подозревал, что это был тайм-аут сети, и надеялся найти виновника, просмотрев несколько пакетов, которые произошли непосредственно перед паузой. Действительно, это сработало. Странно, что полный отказ DNS не вызвал никаких других проблем; Одна из причин заключается в том, что я использовал прокси-сервер apt, а это означает, что apt-get не выполнял запросы DNS.