Марионеточная ошибка HTTP 400 С Настройкой среды

Я реконфигурировал свою марионетку (v3.6.2) сервер (RHEL 7.1) в поддержку сред как показано ниже.

/etc/puppet
           puppet.conf
           auth.conf
           environments
                       Project_A
                                modules
                                manifests/site.pp
                                environment.conf
                       Project_B
                                modules
                                manifests/site.pp
                                environment.conf

environment.conf файлы состоят из

modulepath=/etc/puppet/environments/$environment/modules
manifest=/etc/puppet/environments/$environment/manifests/site.pp

site.pp файл для каждой среды состоит из

include 'nodes.pp'
include 'selinux.pp'
include 'check_mode.pp'
$puppetserver=<SERVER>
Package {
        allow_virtual=>true,
}

на агенте, когда я выполняю команду

puppet agent --no-daemonize --trace --debug --noop --verbose

Я получаю ошибку

Ошибка: не Мог получить каталог от удаленного сервера: Ошибка 400 на сервере: не Мог найти узлы класса для <'СЕРВЕРА'> на <'СЕРВЕРЕ'>

в /var/log/puppet/masterhttp.log я получаю ошибку

[09.09.2015 15:43:12] <'IP'> - [2015/09/09:15:43:12 AEST] "POST/Project_A/catalog / <'SERVER'> HTTP/1.1 400 21

Каждый агент имеет ту же конфигурацию как тогда, когда у марионетки была единая среда с добавлением 'среды = 'PROJECT_A'

Если я изменяюсь, nodes.pp в site.pp от включают для импорта импорта 'nodes.pp' ошибочные изменения в

Ошибка: не Мог получить каталог от удаленного сервера: Ошибка 400 на сервере: не Мог найти класс selinux.pp для <'СЕРВЕРА'> на <'СЕРВЕРЕ'>

Эта та же структура работает правильно, когда марионетка была настроена для единой среды. Под единой средой все было настроено как таковое:

/etc/puppet
           puppet.conf
           auth.conf
           environments
           modules
           manifests/site.pp

Я подозреваю, что я, возможно, должен изменить свой auth.conf файл, но в замешательстве относительно того, какие изменения требуются. В настоящее время файл является конфигурацией по умолчанию.

Я попытался добавить

path /environments
allow *

без радости

и добавили к fileserver.conf

path /etc/puppet/environments 
allow *

снова без радости.

для записи основной puppet.conf файл

[main]
      logdir = /var/log/puppet
      rundir = /var/run/puppet
      ssldir = $vardir/ssl
      always_cache_features = true
      server = <'PUPPET SERVER'>
      environmentpath = $confdir/environments

[master]
      ca = true
      dns_alt_names = <'SAN DNS ENTRIES'>
      certname = <'PUPPET MASTER'>
      ssl_client_header = SSL_CLIENT_S_DN
      ssl_client_verify_header = SSL_CLIENT_VERIFY
      environment = master
[agent]
      classfile = $vardir/classes.txt
      localconfig = $vardir/localconfig
      environment = Project_A

Агенты используют тот же конфигурационный файл без [ведущее устройство]

Может любой видеть, где я сделал ошибку в своей конфигурации.

ОБНОВЛЕНИЕ: Я запустил puppetmaster в режиме отладки, и от агента пытался соединиться с сервером. В выводе отладки это - то, что заставило меня подозревать, что это - auth.conf

Notice: Starting Pppet master version 3.6.2
Debug: Routes Registered
Debug: Route /^\/v2\.0/
Debug: Route /.*/
Debug: Evaluating match for Route /^\/v2\.0/
Debug: Did not match path ("/Project_A/node/<SERVER A>")
Debug: Evaluating match for Route /.*/
Info: access[^/catalog/([^/]+)$]: allowing 'method' find
Info: access[^/catalog/([^/]+)$]: allowing $1 access
Info: access[^/node/([^/]+)$]: allowing 'method' find
Info: access[^/node/([^/]+)$]: allowing $1 access
Info: access[/certificate_revocation_list/ca]: allowing 'method' find
Info: access[/certificate_revocation_list/ca]: allowing * access
Info: access[/^/report/([^/]+)$]: allowing 'method' save
Info: access[/^/report/([^/]+)$]: allowing $1 access
Info: access[/file]: allowing * access
Info: access[/certificate/ca]: adding authentication any
Info: access[/certificate/ca]: adding 'method' find
Info: access[/certificate/ca]: adding * access
Info: access[/certificate/]: adding authentication any
Info: access[/certificate/]: adding 'method' find
Info: access[/certificate/]: adding * access
Info: access[/certificate_request]: adding authentication any
Info: access[/certificate_request]: adding 'method' find
Info: access[/certificate_request]: adding 'method' save
Info: access[/certificate_request]: adding * access
Info: access[/v2.0/environments]: adding 'method' find
Info: access[/v2.0/environments]: adding * access
Info: access[/]: adding authentication any
Info: Inserting dfault '/status' (auth true) ACL
Info: Caching node for <SERVER A>
Debug: Failed to load library 'msgpack' for feature 'msgpack'
Debug: Puppet::Network::Format [msgpack]: feature msgpack is missing
Debug: node supports formats: pson b64_zlib_yaml yaml raw
Debug: Routes Register:
Debug: Routes /^\/v2\.0/
Debug: Route /.*/
Debug: Evaluating match for Route /^\/v2\.0/
Debug: Did not match path ("/Project_A/file_metadatas/plugins")
Debug: Evaluating match for Route /.*/

ОБНОВЛЕНИЕ:
У меня есть вид полученных эта работа.
После перечитывания puppetlabs документов о средах это указывает, что должна быть среда, названная производством. Я таким образом создал

/etc/puppet/environments/production
                              | modules
                              | manifests
                              | environment.conf

Это настроено то же как другие среды, хотя у директоров в настоящее время нет файлов в них.

Агент остается тем же.

Теперь, когда я выполняю агент, он работает без ошибок. Единственная вещь состоит в том, что это собирает информацию от марионеточного корня/etc/puppet/modules и/etc/puppet/manifests и в то время как выполнения агента ничего не делают, если хост не определяется в/etc/puppet/manifests/site.pp.

В puppetmaster отладка произвела все ссылки на хост, определяются как Project_A и существует запись в журнале

Уведомление: Скомпилированный каталог для <'SERVER_A'> в среде Project_A за 0,00 секунды

От агента

Notice: /Stage/[main]/ntp::Config/File[/etc/ntp.conf]/content: content changed '{md5}<md5sum>' to '{md5}<md5sum>'
Info: /Stage/[main]/ntp::Config/File[/etc/ntp.conf]: Scheduling refresh of Service{ntpd}

Так, таким образом.

Клиент распознается как принадлежащий среде 'Project_A' на ведущем устройстве. Несмотря на то, чтобы быть настроенным для использования пути/etc/puppet/environments/$environment/{modules|manifests/site.pp} в файле 'Project_A' environment.conf.
На самом деле использует/etc/puppet/{modules|manifests/site.pp}

1
задан 10 September 2015 в 09:11
2 ответа

Спасибо всем, кто ответил.

Это было решено.

При реализации сред применяется следующее

  • Требуется производственная среда по умолчанию (согласно документам)
  • , даже если она может быть сконфигурирована в марионетке. conf при тестировании через командную строку включают "--server <'SERVER'> и --environment <'ENVIRONMENT'>"
  • Очистите кэш, расположенный в /var/opt/lib/puppet/client_data/catalog/<'SERVER NAME'>.json

Всю дорогу я наблюдал странное поведение, которое исчезло при удалении кэша.

.
0
ответ дан 4 December 2019 в 07:11

Вы проверили права доступа к каталогу. Веб-сервер может не иметь доступа к каталогам.

0
ответ дан 4 December 2019 в 07:11

Теги

Похожие вопросы