Привет: Я пытаюсь настроить Puppet на Ubuntu, и, как ни странно, я никогда не могу сгенерировать сертификат, потому что мой сервер никогда не показывает никаких ожидающих запросов на сертификат.
Другими словами, на сервере я запускаю puppetmasterd, а на клиенте я могу подключиться к серверу, но клиент продолжает печатать
notice: Did not receive certificate
warning: peer certificate won't be verified in this SSL session
и все же сервер никогда не видит запрос
mrisher@lab2$ puppetca --list
[nothing shows up]
mrisher@lab2$ puppetca --sign clientname.domain.com
clientname.domain.com
err: Could not call sign: Could not find certificate request for clientname.domain.com
Изменить: было предположение, что происходит автоподпись, но, похоже, это не так. Здесь нет autosign.conf файл, и когда я запускаю puppetmasterd --no-daemonize -d -v Я получаю следующий вывод: info: Не удалось найти сертификат для clientname.domain.com каждый раз, когда клиент сообщает уведомление: не получил сертификат
Я проверил сертификаты на сервере, похоже, их нет:
mrisher@lab2:~$ puppetca --list --all
mrisher@lab2:~$ sudo puppetca --list --all
+ lab2.domain.com // this is the server (master)
mrisher@lab2:~$ sudo puppetca --list
[blank line]
mrisher@lab2:~$
Примечание: это в основном запускает установку по умолчанию из Ubuntu, если это дает какие-то подсказки.
Спасибо за любую помощь.
РЕДАКТИРОВАТЬ Похоже, это произошло из-за непоследовательного запуска puppetd как разные пользователи. По причинам, которые я не совсем понимаю для демона, puppet хранит некоторые из своих настроек, включая сертификаты, в ~ / .puppet, а не в центральном каталоге, например /var/lib/puppet, поэтому важно, тестируете ли вы себя или sudo.
Это действительно то поведение, которое вы увидите, если включено автоподписание. Вы можете посмотреть содержимое /etc/puppet/autosign.conf чтобы точно узнать, для каких доменов это включено. Например, предположим, что этот файл содержит следующее:
*.example.com
192.168.0.0/24
Это будет означать, что любые сертификаты, поступающие от имени хоста в дереве example.com или из блока адресов 192.168.0.0/24, будут подписаны puppetca без какого-либо вмешательства администратора.
Вы можете просмотреть все сертификатов, подписанных или нет, с помощью команды
/usr/sbin/puppetca --list --all
Ваш запрос сертификата когда-либо попадал на сервер? (Используйте значение puppetmasterd --configprint ssldir где я написал $ssldir Вот)
Под $ssldir/ca там должна быть такая структура каталогов:
private/
requests/
serial
signed/
И под requests, если запрос вашего клиента действительно сработал, вы должны увидеть файл с именем clientname.domain.com.pem. Если он есть и нуждается в подписи, вы можете указать на него puppetca, указав puppetca --ssldir=/path/to/ssldir --sign clientname.domain.com; если его НЕТ, загрузка CSR клиента могла молча потерпеть неудачу. Простое (и безопасное) решение - использовать puppetca --generate clientname.domain.com на вашем puppetmaster, чтобы создать пару ключей и подписанный сертификат для клиентов. Простой и небезопасный обходной путь - включить автоподписывание для вашего домена, добавив '* .domain.com' в autosign.conf на Puppetmaster $confdir.
Попробуйте исключить несоответствие сертификата хозяина марионеток.
На узле агента:
$ sudo puppetd --configprint server
О мастере:
$ sudo puppetca --print lab2.domain.com
... и ищите эти строки в выводе:
...
Subject: CN={A hostname}
...
X509v3 Subject Alternative Name:
DNS:{a hostname}, DNS:{another hostname}, {etc.}
Если имя хоста, которое агент использует для связи с мастером ЯВЛЯЕТСЯ допустимое имя хоста для мастера, но НЕ в полях «общее имя субъекта» (certname) или «альтернативное имя субъекта» (certdnsnames) в сертификате SSL мастера вы попадете в мир боли.
(Если это окажется проблемой, либо измените puppet.conf на агенте, чтобы он указывал на рабочее имя сертификата или имя сертификата для мастера марионетки, либо остановите мастер марионетки, отредактируйте файл puppet.conf, чтобы получить нужные имя сертификата и имена сертификатов , сдуйте его ssldir (puppetmaster --configprint ssldir) и перезапустите мастер.)
Я хотел вмешаться, чтобы объяснить то, что я обнаружил: допустим, это было на полпути (когда клиент мог связаться с марионеточным мастером, но теперь запросы сертификатов больше не отображаются). В моем случае это было на полпути, но тогда я не мог даже SSH от клиента к марионеточному мастеру. Странный. В этом случае мне пришлось пройти через те же каталоги ssl (см. Выше) на клиентском сайте, чтобы удалить сертификаты клиента и мастера марионетки, а также очистить файлы ca для мастера марионетки. На марионеточном мастере мне пришлось выполнить зеркальное действие, удалив следы сертификата клиента из всех каталогов, И список клиентов в файле /var/lib/puppet/ssl/ca/inventory.txt.
После этого и перезагрузки обоих я мог увидеть запрос. Проблема заключалась в том, что у мастера марионеток когда-то был действующий список сертификатов для клиента в файле inventory.txt в каталоге / var / lib / puppet / ssl / ca, но я вычистил или удалил фактический сертификат. Мой системный журнал на марионеточном хозяине показал: «Сертификат для хоста не найден ...», что означает, что он знал, что один из них находится в инвентаре, но фактический сертификат был в метафорическом «обратном порядке» или просто отсутствовал.
Итак, удалите старые сертификаты для CA и puppet-master на стороне клиента. Затем удалите сертификат и список сертификатов в inventory.txt, и это должно сработать.