Я создаю файл auditd audit.rules на основе предоставленного пакетом файла 30-stig.rules.

Файл stig.rules находится по адресу / usr / share / doc / audit- /rules/30-stig.rules. Однако заранее трудно узнать, какая версия auditd установлена, поэтому я хотел использовать ресурс exec для копирования этого файла в стандартное место:

exec { 'Copy stig.rules to /tmp/stig.rules':
  command  => 'cp $(rpm -qf auditd | grep stig.rules) /tmp/stig.rules',
  unless   => 'cmp /tmp/stig.rules $(rpm -qf auditd | grep stig.rules)',
}

file { '/etc/audit/audit.rules':
  ensure  => file,
  content => template('auditd/audit.rules.erb'),
}

Шаблон (audit.rules.erb) содержит:

scope.function_file(['/tmp/stig.rules'])

Сначала я получил сообщение об ошибке, что шаблон не может найти /tmp/stig.rules. Поэтому я добавил:

Exec['Copy stig.rules to /tmp/stig.rules'] -> File['/etc/audit/audit.rules']

Даже после этого явного упорядочивания я получаю ту же ошибку, что /tmp/stig.rules не найден. Похоже, что во время синтаксического анализа файловый ресурс выполняет некоторую предварительную проверку еще до того, как он выполнит «exec», после которого он должен быть заказан. Кто-нибудь может объяснить такое поведение?

0
LJKims 27 Июн 2017 в 05:43
Ваши ресурсы Puppet не соответствуют вашему ожидаемому поведению и, похоже, не связаны с вашей ошибкой. Я не ожидал, что указанный вами порядок взаимоотношений решит эту проблему, и, похоже, этого не произошло.
 – 
Matt Schuchard
27 Июн 2017 в 15:44
Хорошо спасибо. Можете ли вы объяснить, почему вы считаете, что мои ресурсы «не соответствуют моему ожидаемому поведению»?
 – 
LJKims
27 Июн 2017 в 15:51
На этот файл ссылается шаблон, на который ссылается файловый ресурс. Вот почему мне странно, что он анализирует шаблон до того, как файловый ресурс должен был даже быть запущен (поскольку exec еще не запускался).
 – 
LJKims
27 Июн 2017 в 16:32
О, я пропустил эту часть. Хорошо, это все еще не имеет ничего общего с порядком ресурсов, а скорее с этим нюансом, который имеет тенденцию сбивать с толку многих новичков в Puppet: «Функции выполняются на мастере Puppet. Они не выполняются на агенте Puppet. Следовательно, у них есть доступ только к команды и данные, доступные на главном хосте Puppet ". docs.puppet.com/puppet/latest/function.html
 – 
Matt Schuchard
27 Июн 2017 в 16:46
В этом больше смысла. Таким образом, в этом случае желание использовать самый последний файл 'stig.rules', соответствующий версии пакета аудита, развернутого на клиенте (который может не соответствовать версии, развернутой на главном сервере Puppet), просто не возможный?
 – 
LJKims
27 Июн 2017 в 17:05

1 ответ

Лучший ответ

Как упоминалось в комментариях, проблема заключается в том, что функции Puppet выполняются на Puppet Master.

Обычно эта проблема решается путем создания настраиваемого факта, который возвращает аудит. версия.

Создайте файл в своем модуле с чем-то вроде:

# lib/facter/auditd_version.rb

Facter.add(:auditd_version) do
  confine :osfamily => 'RedHat'
  setcode do
    Facter::Core::Execution.exec('rpm -q --queryformat "%{VERSION}\n" audit')
  end
end

Затем вы можете указать путь к своему файлу в манифесте, используя:

$file_path = "/usr/share/doc/audit-${facts['auditd_version']}/rules/30-stig.rules"

Или (устаревший):

$file_path = "/usr/share/doc/audit-${::auditd_version}/rules/30-stig.rules"

И вы можете получить к нему доступ в шаблоне ERB, используя:

/usr/share/doc/audit-<%= @auditd_version %>/rules/30-stig.rules

Если затем вам понадобится содержимое файла правил stig внутри вашего манифеста, вы обычно переносите это содержимое в свой манифест Puppet и позволяете Puppet управлять этим файлом:

$stig_rules = template('mymodule/stig_rules.erb')
file { "/usr/share/doc/audit-${facts['auditd_version']}/rules/30-stig.rules":
  ensure  => file,
  content => $stig_rules,
}

А затем внутри вашего шаблона вы теперь можете получить доступ к этому контенту как @stig_rules.

В случае, если RPM время от времени изменяет содержимое этого файла, вам нужно будет обновить манифест Puppet - правда, это не идеально.

Другой подход - просто вернуть все содержимое файла в настраиваемом факте.

# lib/facter/stig_rules.rb

Facter.add(:stig_rules) do
  confine :osfamily => 'RedHat'
  setcode do
    Facter::Core::Execution.exec("cat \
      /usr/share/doc/audit-#{Facter.value(:auditd_version)}/stig.rules")
  end
end
0
Alex Harvey 29 Июн 2017 в 06:16
Я действительно так и сделал. Я создал настраиваемый факт, который дает версию auditd на стороне клиента. Однако, когда я пытаюсь вставить его содержимое в шаблон, мне все равно приходится использовать функцию «файл» в ERB, которая, как вы сказали, все еще выполняется на стороне сервера.
 – 
LJKims
29 Июн 2017 в 05:59
Скорее всего, сработает создание настраиваемого факта со всем контентом. Ранее я создал пользовательский факт, указывающий на файл stig.rules. Однако эта информация находится на стороне клиента, и, как вы указали, функция ERB попытается найти один и тот же файл на стороне сервера, чтобы это не сработало для всех дистрибутивов или если версия auditd различалась между клиентом и сервер.
 – 
LJKims
29 Июн 2017 в 15:48
Я думаю, вы неправильно поняли. Я считаю, что большинство людей в этой ситуации позволит Puppet управлять файлом stig.rules, скопировав все, что RPM предоставляет в модуль Puppet, а затем объявит этот файловый ресурс и его содержимое. Puppet видит, что файл, который уже существует (доставлен RPM), имеет ожидаемое содержимое, и поэтому ничего не делает. Если у вас есть разные файлы для разных ОС, вы выполняете условную логику на основе, например, $facts['osfamily']. Тем не менее, я думаю, что получение настраиваемого факта для простого возврата всего содержимого файла также должно быть нормальным.
 – 
Alex Harvey
29 Июн 2017 в 16:16