марионеточный основной API REST возвращается 403 при выполнении при пассажирских работах, когда ведущее устройство работает из командной строки
не мой, но это - самое творческое использование nagios, о котором я когда-либо слышал. Слава этому парню!
Я сравнил его с другой настройкой, которая была у нас на nginx; похоже, проблема была связана со свойствами
ssl_client_header = SSL_CLIENT_S_D
ssl_client_verify_header = SSL_CLIENT_VERIFY
, присутствующими в файле puppet.conf мастера. Комментируя их оттуда и оставляя для них конфигурацию, как в Nginx, проблема была решена.
Комментируя их оттуда и оставляя для них конфигурацию, как в Nginx, проблема была решена. Комментируя их оттуда и оставляя для них конфигурацию, как в Nginx, проблема была решена. Ваша стойка config.ru принадлежит пользователю / группе puppet: puppet? Из документации Puppet Labs:
Что бы вы ни делали, убедитесь, что ваш файл config.ru принадлежит пользователю puppet! Passenger установит идентификатор для этого пользователя. http://projects.puppetlabs.com/projects/1/wiki/using_passenger
Также убедитесь, что / etc / puppet и / var / lib / puppet также принадлежат марионетка: также марионетка.
Этот симптом возникнет, если вы привыкли использовать Puppet под Nginx / Passenger и обновились до пассажира 5.0+. Я нашел решение здесь .
Пассажир 5.0 заменил "пассажиру_set_cgi_param" на "пассажир_set_header", который, если вы зашли так далеко, вы уже догадались. Однако вы могли упустить то, что "пассажиру_set_header" автоматически добавляет HTTP_ к значению, поэтому вам нужно удалить его из строк HTTP_X_CLIENT_S_DN и HTTP_X_CLIENT_VERIFY.
Прежде всего я бы проверил, каков статус марионеточного мастера - это может быть либо конфигурация selinux, либо порт 8140 слушает «httpd».
Попробуйте проверить вывод netstat -anpl | grep 8140
На мастере марионеток попробуйте запустить sudo puppet master --verbose --no-daemonize
Если мастер марионеток запускается без каких-либо ошибок, вам, возможно, придется сосредоточиться на марионеточном агенте.