Как скопировать файл всем клиентам, использующим Puppet?

Файловый сервер Puppet

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

Главный сервис Puppet включает в себя файловый сервер для передачи статических файлов. Если объявление файлового ресурса содержит URI puppet: в своем атрибуте источника, узлы будут извлекать этот файл с файлового сервера мастера:

# copy a remote file to /etc/sudoers
file { "/etc/sudoers":
    mode => 440,
    owner => root,
    group => root,
    source => "puppet:///modules/module_name/sudoers"
}

Все URI файлового сервера марионеток имеют следующую структуру:

puppet://{server hostname (optional)}/{mount point}/{remainder of path}

Если имя хоста сервера опущено (т. Е. puppet:///{mount point}/{path}; обратите внимание на тройную косую черту), URI разрешается на тот сервер, который оценивающий узел считает своим ведущим. Поскольку это делает код манифеста более переносимым и пригодным для повторного использования, имена хостов следует по возможности опускать.

Остальная часть марионетки: URI отображается на файловую систему сервера одним из двух способов, в зависимости от того, предоставлены ли файлы с помощью module или предоставлены с помощью custom mount point.

Файлы обслуживающих модулей

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

• Интерпретировать следующий сегмент пути как имя модуля…
• ... найти этот модуль в модульном пути сервера (как описано здесь в разделе «Поиск модуля» ...
• ... и разрешить оставшуюся часть пути, начинающегося в каталоге files / directory этого модуля.

• То есть если модуль с именем test_module установлен в каталоге /etc/puppet/modules центрального сервера, следующая марионетка: URI ...

  puppet:///modules/test_module/testfile.txt
  

  ... преобразуется в следующий абсолютный путь:

  /etc/puppet/modules/test_module/files/testfile.txt
  

  Если бы test_module был установлен в /usr/share/puppet/modules, тот же URI вместо этого разрешил бы:

  /usr/share/puppet/modules/test_module/files/testfile.txt
  

Хотя для использования точки монтирования модулей не требуется никакой дополнительной конфигурации, некоторые элементы управления доступом можно указать в конфигурации файлового сервера, добавив блок конфигурации [modules], см. Безопасность.

Обслуживание файлов из пользовательских точек монтирования

Puppet также может обслуживать файлы из произвольные точки монтирования, указанные в конфигурации файлового сервера сервера (см. ниже). При обслуживании файлов из пользовательской точки монтирования Puppet не выполняет дополнительную абстракцию URI, используемую при монтировании модулей, и разрешает путь, следующий за именем монтирования, в виде простой структуры каталогов.

Конфигурация файлового сервера

Расположение по умолчанию для данных конфигурации файлового сервера: /etc/puppet/fileserver.conf; это можно изменить, передав флаг --fsconfig хозяину марионеток.

Формат файла fileserver.conf почти такой же, как и в rsync, и примерно напоминает файл INI:

[mount_point]
    path /path/to/files
    allow *.domain.com
    deny *.wireless.domain.com

В настоящее время для данной точки монтирования можно указать следующие параметры:

• Путь к местоположению монтирования на диске
• Любое количество разрешающих директив
• Любое количество запрещающих директив

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

Путь может содержать любой или все из %h, %H и %d, которые динамически заменяются именем хоста клиента, его полным доменным именем и его доменным именем, соответственно. Все они взяты из SSL-сертификата клиента (поэтому будьте осторожны, если у вас есть несоответствия имени хоста / сертификата). Это полезно при создании модулей, в которых файлы для каждого клиента хранятся совершенно отдельно, например, для приватных ключей хоста ssh. Например, при конфигурации

[private]
   path /data/private/%h
   allow *

запрос файла /private/file.txt от клиента client1.example.com будет искать файл /data/private/client1/file.txt, а тот же запрос из client2.example.com попытается получить файл /data/private/client2/file.txt на файловом сервере.

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

Безопасность

Защита файлового сервера Puppet состоит из разрешения и запрета доступа (с различными уровнями специфичности) для каждой точки монтирования. Группы узлов могут быть идентифицированы для разрешения или отказа тремя способами: по IP-адресу, по имени или по одному глобальному подстановочному знаку (*). Пользовательские точки монтирования по умолчанию запрещают весь доступ.

Помимо пользовательских точек монтирования, есть две специальные точки монтирования, которыми можно управлять с помощью fileserver.conf: modules и plugins. Ни в одной из этих точек монтирования не должна быть указана опция пути. Поведение точки монтирования модулей описано выше в разделе «Обслуживание файлов из пользовательских точек монтирования». Монтирование плагинов - это не точка монтирования, а скорее ловушка, позволяющая файлу fileserver.conf указать, каким узлам разрешено синхронизировать плагины из Puppet Master. Обе эти точки монтирования существуют по умолчанию, и обе по умолчанию разрешают весь доступ; если для одного из этих специальных монтирований установлены какие-либо разрешающие или запрещающие директивы, его параметры безопасности будут вести себя как параметры обычного монтирования (т. е. по умолчанию будет отказано в любом доступе). Обратите внимание, что это единственные точки монтирования, для которых deny * не является избыточным.

Если узлы не подключаются напрямую к файловому серверу Puppet, например, используя обратный прокси-сервер и Mongrel (см. раздел Использование Mongrel), тогда файловый сервер будет видеть все подключения как с IP-адреса прокси-сервера, а не узла Puppet Agent. В этом случае лучше всего ограничить доступ на основе имени хоста. Кроме того, машинам, действующим как обратный прокси-сервер (обычно 127.0.0.0/8), нужно будет разрешить доступ к соответствующим точкам монтирования.

Приоритет

Более конкретные заявления об отказе и разрешении имеют приоритет над менее конкретными заявлениями; то есть оператор allow для node.domain.com позволил бы ему подключиться, несмотря на оператор deny для * .domain.com. На данном уровне специфичности операторы deny имеют приоритет над операторами allow.

Непредсказуемое поведение может возникнуть в результате смешивания директив IP-адреса с директивами имени хоста и имени домена, поэтому старайтесь избегать этого. (В настоящее время, если IP-адрес node.domain.com - 192.168.1.80, а fileserver.conf содержит allow 192.168.1.80 и deny node.domain.com, директива allow на основе IP будет фактически иметь приоритет. Это поведение может быть изменено в будущее и на него не следует полагаться.)

Имена хостов

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

[export]
    path /export
    allow host.domain1.com
    allow *.domain2.com
    deny badhost.domain2.com

IP-адреса

IP-адрес можно указывать аналогично именам хостов, используя либо полные IP-адреса, либо адреса с подстановочными символами. Вы также можете использовать нотацию в стиле CIDR:

[export]
    path /export
    allow 127.0.0.1
    allow 192.168.0.*
    allow 192.168.1.0/24

Глобальное разрешение

Указание одного подстановочного знака позволит любому узлу получить доступ к точке монтирования:

[export]
    path /export
    allow *

Обратите внимание, что поведение по умолчанию для пользовательских точек монтирования эквивалентно deny *.