несколько марионеточных ведущих устройств настраивают материально-технические ресурсы использования
Действительно имейте очень внимательный взгляд на затраты/объем/квоты - и посмотрите, можно ли получить точные меры текущего использования - часто, стандартные арендные договоры будут иметь квоту страниц - но как только Вы пробегаетесь через это, Вы начинаете обвиняться смешные суммы за каждую страницу.
Как только я это сделал, я смог раскомментировать
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 *