Я пытаюсь настроить виртуальную машину Ubuntu с установленной марионеткой, чтобы я мог локально протестировать нашу производственную настройку. У меня проблемы с тем, чтобы кукловод и марионетка разговаривали друг с другом. Позвольте мне провести вас через мои шаги. (Серверный hostname - полное доменное имя в формате "web1.xxx.xxx.net").
Итак, во-первых, я очищаю все файлы pem (кроме, конечно, CA pems) из /etc/puppet/ssl каталог, чтобы я мог начать все сначала. puppetca --list не возвращает результатов.
Затем я бегу puppetd --test для создания CSR для кукловода. puppetca --list теперь включает мое имя хоста ("web1.xxx.xxx.net").
Тогда я бегу puppetca --sign web1.xxx.xxx.net. Сейчас puppetca --list снова пусто - пока все работает нормально.
Наконец я бегу puppetd --test очередной раз. Получаю следующий результат:
err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Листинг содержимого /etc/puppet/ssl каталог показывает файлы PEM с правильным именем сервера, которое соответствует моему hostname. У кого-нибудь есть идеи, как решить эту проблему?
Ошибка связана с тем, что клиент по умолчанию подключается к серверу с именем «марионетка», но представленный сертификат не имеет «марионетки» ни в качестве субъекта, ни в качестве атрибута SubjectAltName.
Чтобы исправить это, вы можете (выберите один):
вместо инициализации сертификата мастера марионеток, запустив puppetd, инициализируйте его, запустив puppetmasterd - это приведет к тому, что имя субъекта сертификата будет включать "марионетку".
вместо того, чтобы оставлять все на волю случая, вы можете использовать puppetca --generate --certdnsnames puppet:puppet.mydomain.com web1.xx.xx.xx.net - опция certdnsnames указывает список SubjectAltNames, которые будут включены в сертификат; он должен иметь список разделенных двоеточиями любое имя что клиент будет использовать для связи с сервером.
вместо того, чтобы просто бежать puppetd --test на клиенте запустите puppetd --test --server=web1.xx.xx.xx.net Таким образом, имя сервера, к которому подключается клиент, фактически существует в сертификате, представленном сервером.
Прочтите отличную запись в блоге masterzen для дальнейшего устранения неполадок: Объяснение Puppet SSL
Вы проверяли файл журнала Puppetmaster? Я обнаружил ту же проблему и обнаружил, что сервер регистрирует информацию о сертификате:
[2012-02-28 16:21:09] INFO
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: CN=ca
Validity
Not Before: Feb 26 16:32:46 2012 GMT
Not After : Feb 24 16:32:46 2017 GMT
Subject: CN=ubuntu.localdomain
Поле «Тема» показывает, что CN - это «ubuntu.localdomain», поэтому я выполнил марионетку, выполнив:
puppetd -t --server=ubuntu.localdomain --fqdn=myfqdn
Надеюсь это поможет :-)
В дополнение к тому, что ответил По, я просто хотел бы подчеркнуть, что вы можете проверить сертификат puppetmasters, используя:
openssl x509 -text -in /var/lib/puppet/ssl/certs/<hostname_of_puppet_master>
Затем убедитесь, что вы используете то же имя хоста, когда от клиента:
puppetd --server <hostname_of_puppet_master> <etc>
Оба сервера могут разрешать друг друга? Я предполагаю, что, поскольку вы используете виртуальную машину, вам может не хватать разрешения имени. Если вы не используете DNS, чтобы серверы разрешали друг друга, вам необходимо добавить записи в свой /etc/hosts файл на обоих серверах.
Puppet требует, чтобы имена хостов разрешались в правильные IP-адреса, без этого вы получите указанную вами ошибку. После этого вам может потребоваться воссоздать сертификаты. Обе машины должны иметь возможность пинговать каждую по имени хоста.
Еще одна вещь, о которой следует быть осторожным с виртуальными машинами, - это синхронизация времени на серверах. Если вы этого не сделаете, скорее всего, сертификаты будут недействительными.