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

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

Кукольный Файловый Сервер

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

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

# скопировать удаленный файл в / etc / sudoers
файл {"/ etc / sudoers":
    режим => 440,
    владелец => корень,
    группа => корень,
    source => "Puppet: /// modules / имя_модуля / sudoers"
}

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

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

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

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

Файлы модуля обслуживания

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

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

• То есть, если модуль с именем 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

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

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

путь является единственным обязательным параметром, но поскольку конфигурация безопасности по умолчанию запрещает любой доступ, точка монтирования без директив 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 , В этом случае лучше всего ограничить доступ на основе имени хоста. Кроме того, машинам, действующим как обратный прокси-сервер (обычно 127.0.0.0/8), необходимо разрешить доступ к соответствующим точкам монтирования.

приоритет

Более конкретные операторы deny и allow имеют приоритет перед менее конкретными операторами; то есть оператор 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 *.