Мне удалось настроить несколько мастеров марионеток с одним мастером марионеток, действующим в качестве центра сертификации, и клиенты могут получать сертификат от этого сервера центра сертификации, но использовать назначенного им мастера марионеток для получения своих манифестов. См. Этот вопрос для получения дополнительной информации. несколько мастеров кукол. Однако мне нужно было сделать несколько вещей, чтобы это работало правильно и возникла ошибка, к которой я доберусь.
Прежде всего, чтобы заставить инвентарь работать для марионеточного клиента (ПК), подключенного к назначенному марионеточному мастеру (PM), мне пришлось скопировать сертификаты CA на PM1 в каталог ca PM2. Я выполнил эту команду:
scp root@puppet-master1.test.net:/var/lib/puppet/ssl/ca/ca_cr*.pem root@puppet-master2.test.net:/var/lib/puppet/ssl/ca/.
Как только я это сделал, я смог раскомментировать SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFile раздел моего VH-файла rack.conf на PM2. Как только я это сделал, инвентаризация начала работать. Это звучит приемлемо?
Во-вторых, в файле puppet.conf я устанавливаю назначенный PM-сервер для клиента, например server = puppet-master2.test.net. Если нет лучшего способа, он будет работать в моей производственной установке. Таким образом, ПК1 будет разговаривать с PM1, а ПК2 будет разговаривать с PM2. Вот где у меня ошибка. Когда ПК2 сначала запрашивает сертификат у ЦС на PM1, он появляется, а затем я подписываю сертификат в ЦС на PM1. Когда я затем выполняю марионеточный агент --test на ПК2 (у которого есть server = puppet-master2.test.net в puppet.conf), я получаю следующую ошибку:
Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Error 403 on SERVER: Forbidden request: puppet-master2.test.net(10.1.1.161) access to /certificate_revocation_list/ca [find] at :112
Однако, если я изменю файл puppet.conf ПК2 и укажу server = PM1 и повторно запустите puppet agent --test, я не получу никаких ошибок. Затем я могу вернуть изменения в файле puppet.conf обратно на server = PM2, и все, кажется, работает нормально.
Нужно ли мне настраивать какой-то ProxyPassMatch на PM2 для запросов от клиентов к / certificate_revocation_list / * и перенаправлять их на PM1? Или как исправить эту ошибку?
Ура, Оли
Как только я это сделал, я смог раскомментировать
SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFileраздел моего VH-файла rack.conf на PM2. Как только я это сделал, инвентаризация начала работать. Это звучит приемлемо?
В этом нет необходимости - список отзыва и корневой сертификат уже должны быть на вторичном главном сервере. Попробуйте эти расположения файлов на PM2:
SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile /var/lib/puppet/ssl/certs/ca.pem
SSLCARevocationFile /var/lib/puppet/ssl/crl.pem
Во-вторых, в файле puppet.conf я устанавливаю назначенный сервер PM для клиента, например server = puppet-master2.test.net. Если нет лучшего способа, он будет работать в моей производственной установке.
На какой марионеточной версии вы находитесь? Функция записи SRV 3.0 является отличным решением этой проблемы, позволяя вам предоставить клиентам набор мастеров, из которых они могут выбирать, с весом и приоритетами.
Нужно ли мне настраивать какой-то ProxyPassMatch на PM2 для запросов от клиентов к / certificate_revocation_list / * и перенаправлять их на PM1? Или как исправить эту ошибку?
Это плохой вариант по умолчанию auth.conf - проксируемое соединение не аутентифицируется, и по умолчанию используется принудительная аутентификация для CRL (который не чувствителен). Добавьте это в свой auth.conf на PM1:
path /certificate_revocation_list
auth any
method find
allow *