Назад | Перейти на главную страницу

Ошибка марионетки: неопределенный метод 'захватов'

Я разместил этот вопрос на сайте networkengineering SE, но было определено, что он не по теме .... мля.

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

Я установил марионетку на сетевом узле нашей команды (виртуальная машина Ubuntu 12.04 LTS) и настроил одно устройство в моем ~ user / .puppet / device.conf, которое выглядит примерно так ....

[XX-core01.XXX.local]
        type cisco
        url ssh://user:reallygoodpassword@XX-core01.XXX.local/

Я запустил марионеточное устройство --verbose и выдал сертификат. Но как только я это сделал, у меня возникла ошибка, о которой я не могу найти никакой информации.

info: starting applying configuration to XX-core01.XXX.local at ssh://user:reallygoodpassword@XX-core01.XXX.local/
info: Creating a new SSL key for XX-core01.XXX.local
info: Caching certificate for ca
info: Creating a new SSL certificate request for XX-core01.XXX.local
info: Certificate Request fingerprint (md5): 18:B8:55:F9:A0:F6:8E:A3:F5:53:59:87:4C:00:48:23
info: Caching certificate for XX-core01.XXX.local
info: Caching certificate_revocation_list for ca
err: Could not retrieve local facts: undefined method `captures' for nil:NilClass

Может кто-то указать мне верное направление? Кроме того, можно ли с помощью марионетки «ходить» по устройству? Мне было бы интересно узнать, какие параметры доступны для настройки на разных моих устройствах.

Спасибо!

Похоже, что это facter не удалось сообщить факты puppet. Что, вероятно, происходит, так это то, что плагин facter не может получить объект, но все равно работает с результатом (который nil) и пытается вызвать captures метод.

Попробуйте бежать facter --trace --debug --puppet (который запускает facter с включенными плагинами марионеток) и посмотрите, не сработает ли это тоже.

Если это сузит кругозор простым обращением к facter --trace --debug который не сработает, если это базовый плагин facter, но будет работать, если это был плагин марионетки.

После этого вы знаете, где искать. Связанный с марионеткой фактер, вероятно, в /var/lib/puppet/lib/facter/ в то время как основной материал находится в /usr/share/ruby/vendor_ruby/facter/. Убедитесь, что вы также посмотрели /etc/facts.d/ и возможно ~/facts.d/.

Затем вам нужно будет выяснить, какой факт создает проблему, и исправить ее (но, возможно, мы сможем помочь, когда мы на этом этапе).