Puppet Не удалось найти зависимость

Есть ли ограничение в отношениях?

У нас есть несколько модулей Puppet, которые зависят друг от друга (или, по крайней мере, зависят от своих пакетов).

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

Проблема:

Error: Failed to apply catalog: Could not find dependency Package[shibbolethsp] for Package[httpd] at /etc/puppetlabs/code/environments/development/modules/apache/manifests/instance.pp:39

Модули:

# Module someco-httpd, init.pp
package['httpd'] {
  ...
  require => Package['openssl','shibbolethsp'] # can find openssl but NOT shibbolethsp
}

# Module someco-openssl, init.pp
package['openssl'] {
  ...
}

# Module someco-shibbolethsp, init.pp
package['shibbolethsp'] {
  ...
}

Ресурс Package[shibbolethsp] присутствует, потому что, если я удалю пакет и снова запущу марионетку, я вижу, что она будет установлена, но если я также хочу настроить Apache (который требует, чтобы Package[shibbolethsp] функционировал должным образом), Puppet не работает.

Итак, ресурс присутствует, но Puppet не может решить их должным образом, я полагаю? Такое же отношение к Package[openssl]работает как ожидалось и перезапуск Apache, если openssl обновлен до новой версии ...

Это проблема упорядочивания / многопоточности? Одни отношения работают, другие нет ...

Вы уверены, что shibbolethsp находится в ваших репозиториях пакетов? Shibboleth не является типичным пакетом, поэтому вам придется либо загрузить и установить его вручную, либо добавить содержащий его репозиторий. Кроме того, быстрый Google не показывает пакет под названием shibbolethsp. Вы уверены, что это не shibboleth или shibboleth-sp?

Jon 03.08.2018 12:41

Привет @Jon! Большое спасибо за Ваш ответ! Да, пакет ´shibbolethsp´ находится в нашем репозитории, он также будет установлен, если я удалю наш "перезапуск при обновлении зависимостей - логика" ... Пакет - это наш собственный встроенный RPM в нашем собственном репозитории YUM ... они существуют, они будут установлены, если настроены без отношения "require => bla". вся ошибка возникает во время компиляции каталога ...

Pali 03.08.2018 15:57

В этом случае вам, вероятно, просто нужно сделать пакет shibbolethsp зависимым от установки конфигурации yum.repos.d. Я предполагаю, что Puppet просто пытается выполнить их в неправильном порядке и не может найти пакет shib.

Jon 03.08.2018 16:06

Еще одна вещь - необычный синтаксис вашего ресурса. Вместо package['name'] { } используется идиома package { 'name': }. Это, вероятно, не имеет значения, но я раньше не видел этого использования и должен был проверить это в документации!

Jon 03.08.2018 16:10

Какая у вас версия puppet? Моя версия 4.10.12 даже не компилирует объявления стиля package['httpd'] :-) Вылетает с ошибкой о строковых индексах.

Jon 03.08.2018 16:55

@Jon да, вы правы насчет синтаксиса, конечно, это "package {'name':}" Я просто писал быстро и забыл о синтаксисе здесь, но вы можете быть уверены, что я использую правильный синтаксис в своем модуле :). Мы используем Puppet 4.10, который поставляется с Red Hat Satellite 6.3. ваше предположение с репозиторием yum к этому не относится, потому что ВСЕ наши пакеты происходят из одного репо yum (наше собственное репо с нашими собственными встроенными RPM). Для меня с 6 месяцами полной разработки Puppet кажется, что это 100% марионеточная ошибка или недокументированное поведение ...

Pali 04.08.2018 18:04

@Jon Наблюдаемое поведение не наблюдалось бы, если бы пакет shibbolethsp не находился в доступном репозитории пакетов. Это проблема чисто марионеточного парсера.

Matt Schuchard 06.08.2018 20:51

@Pali Не могли бы вы поделиться содержимым classes.txt внутри cachedirpuppet.com/docs/puppet/4.10/…? Это будет для узла, который применяет каталог, который вы описываете выше.

Matt Schuchard 06.08.2018 20:54

текущее содержимое: настройки puppetdev-d00 module_global_settings java

Pali 07.08.2018 08:27

@Jon см. Мой собственный ответ для решения

Pali 07.08.2018 08:34
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
10
1 240
2

Ответы 2

The resource Package[shibbolethsp] IS present because if I remove the package and run puppet again I can see that it gets installed,

Ваше наблюдение не подтверждает вывод.

Во-первых, вполне возможно, что пакет будет установлен в результате запуска Puppet, даже если в каталоге нет ресурса Package для него. Фактически, это происходит постоянно. Он управляется зависимостями, выраженными в самих пакетах, где менеджер пакетов (Yum, apt, так далее.) Определяет зависимости пакета, который он устанавливает, и организует их установку. Puppet не понимает этого.

Во-вторых, вполне возможно, что Package[shibbolethsp] будет объявлен в каталоге для одного узла, но не в каталоге для другого узла. Естественно, если вы удалите shibbolethsp с узла первого типа, Puppet переустановит его при следующем запуске. Это никоим образом не свидетельствует о том, что пакет объявлен в каталоге другого узла.

but if I also want to configure Apache (which requires Package[shibbolethsp] to function properly) Puppet fails.

Это говорит мне, что нет, вы нет объявляете Package[shibbolethsp] в каталоге затронутого узла, несмотря на ваши возражения об обратном.

So the resource is present but Puppet can't resolve them properly I guess? The same relationship to Package[openssl]works as expected and Apache restarts if openssl updated to a new version ...

Я не вижу причин думать, что эти отношения не работают так, как ожидалось должно быть, но я подозреваю, что у вас неверные ожидания.

Во-первых, отношения ресурсов и классов Puppet связаны с зависимостями порядок подачи заявки. Например. File[/etc/foo.conf] должен быть обновлен до того, как Service[foo] будет управляться потому что в противном случае служба foo не может быть переведена в правильное состояние. Это в значительной степени, хотя и не полностью, отдельно от функциональной зависимости между управляемыми компонентами.

Во-вторых, я думаю, вы предполагаете, что ваши отношения require между ресурсами Package приведут к объявлению требуемых Package в случае объявления их requirer. Это совершенно неверно. Опять же, отношения ресурсов Puppet связаны с порядком применения. Puppet не может автоматически объявлять ресурсы required, потому что он полагается на то, что вы укажете ему, какие свойства у них есть, а также потому, что это может создать серьезный риск дублирования объявлений.

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


Если вы хотите, чтобы shibboleth находился на машинах, на которых установлен Apache, вам необходимо убедиться, что объявлен соответствующий класс. У вас также может быть некоторый порядок рассмотрения приложений на уровне, отличном от пакетов - например, вам может потребоваться убедиться, что Shibboleth установлен, прежде чем вы начнете управлять Apache услуга, и, возможно, вы также захотите перезапустить службу, если когда-либо shibboleth пакет или конфигурация обновлены. Лучше всего это устроить на уровне класса, а не в объявлениях отдельных ресурсов.

Например, класс модуля httpd для модуля someco-httpd может включать что-то вроде этого:

# Nodes to which this class is applied require class ::shibbolethsp to be applied first
require '::shibbolethsp'

В отличие от метапараметра require ресурсов, который вызывает оценку именованного класса, shibbolethsp (предположительно, создает объявление Package[shibbolethsp], среди прочего), а также создает отношение порядка приложений, так что класс shibbolethsp применяется первым. И снова, порядок приложения не предназначен для установления отношения пакет / пакет, а скорее для более общего отношения класса / класса, которое охватывает зависимость httpdуслуга от наличия установленного и настроенного shibboleth.

1. Мы сами собираем пакеты RPM (все). у них нет никакой зависимости ни в одном RPM, который установил бы shibbolethsp, его может установить только Puppet 2. весь ваш ответ бесполезен для меня, потому что вы выражаете мне официальную документацию ... вся проблема, похоже, связана с заказом во время компиляции или что еще ... 3. Все это работает для OpenSSL, но не для Shibboleth SP, поэтому я понятия не имею, что вы хотите мне сказать: /

Pali 04.08.2018 18:10

@Pali, я обобщаю для вас соответствующие части официальной документации, потому что в этом отношении документация - точный. Извините, если это не то, что вы хотели услышать, но это правда. Если вы думаете, что наблюдаете другое поведение, вам следует уменьшить его до минимальный воспроизводимый пример, которое вы можете указать в своем вопросе. Скорее всего, вы сами решите проблему таким образом, но если вы этого не сделаете, мы сможем это сделать.

John Bollinger 04.08.2018 18:27

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

Pali 04.08.2018 20:34

Проблема заключается в межмодульных зависимостях. Ресурсы в других модулях находятся в другом пространстве имен, чем текущий модуль. Поэтому, если вы зависите от ресурса из другого модуля, вы должны использовать полный путь, например Other_module::Other_class_or_defined_type['bla'] или используйте require Other_module в своих init.pp, чтобы обеспечить правильный заказ!

ПРИМЕЧАНИЕ: в site.pp вы должны определять ресурсы в их правильном порядке!

Другие вопросы по теме