Точно так же, как и с DNS, существуют модули puppet, предназначенные для управления fierwall. Исходя из соображения, зачем использовать сторонние обёртки, когда iptables сам по себе крут и админ должен знать его на Ять, я не буду использовать эти модули.

Что будем делать:

• Удалим firewalld, поставим классический iptables-service.
• Создадим файл с конфигурацией фаервола, в стиле /etc/sysconfig/iptables.
• На клиенте запустим скрипт, который применит правила fierwall.

На puppet сервере, создадим файл с конфигурацией firewall для машины с dns:
# cd /var/puppet/centos7-2.test.local/etc/
# mkdir sysconfig
# vim sysconfig/iptables
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state —state NEW -m tcp —dport 22 -j ACCEPT
-A INPUT -p udp -m state —state NEW -m udp —dport 53 -j ACCEPT
-A INPUT -p tcp -m state —state NEW -m tcp —dport 53 -j ACCEPT
COMMIT

В файле site.pp добавляем новый класс.
class minimal-iptables {
# Удаляем firewalld
package { ‘firewalld’:
ensure => absent,
  before => Package[‘iptables-services‘]
}
# Перед удалением firewalld останавливаем соответствующий
# сервис и делаем ему disable.
service { ‘firewalld’:
name => «firewalld»,
enable => false,
ensure => stopped,
before => Package[‘firewalld’]
}
# Устанавливаем iptables-services
package { ‘iptables-services’ :
ensure => installed
}
service { ‘iptables’:
  enable => true,
ensure => running,
  require => Package[«iptables-services»]
 }
# Определяем файл, в котором будем описывать
# правила firewall
file { ‘/etc/sysconfig/iptables’:
ensure => file,
mode => ‘0600’,
owner => ‘root’,
# Для каждой машины предполагается свой файл
source => «puppet:///configs/$fqdn/etc/sysconfig/iptables»,
require => Package[«iptables-services»]
}
# Описываем программу, которая будет выполняться
# на машине для поднятия правил fierwall
exec { ‘firewall’:
# «Подписываемся» на файл
subscribe => File[«/etc/sysconfig/iptables»],
# Устанавливаем правила фаервола из файла.
command => «/usr/bin/cat /etc/sysconfig/iptables | /usr/sbin/iptables-restore «,
# Говорим, что программа будет выполняться
# только если файл, на который мы подписаны,
# изменился.
refreshonly => true
}
}

Вносим изменения в node.
node ‘centos7-2.test.local’ {
include ‘baselinux’
include ‘minimal-iptables’
include ‘dns’
}

Проверяем файл манифеста.
# puppet parser validate /etc/puppet/manifests/site.pp

У данного способа есть недостаток — при исполнении скрипта будут рваться сессии. Это можно обойти, используя вместо файла /etc/sysconfig/iptables самописанный скрипт.

Я долго думал, использовать ли для управления DNS сервером скрипты из PuppetForge (https://forge.puppetlabs.com/)? Или держать на puppet сервере файлы конфигурации bind и рулить удаленным сервером изменяя эти файлы.

Победил второй путь. Я прекрасно умею управлять DNS сервером при помощи его конфигурационых файлов и файлов зон. Учить дополнительную обертку, написанную сторонними компаниями, на неизвестном мне ruby… Зачем так усложнять?

Поэтому, буду использовать конфигурационные файлы и тупо копировать их на машину с DNS сервером.

Создадим директорию /var/puppet.
# mkdir /var/puppet

В которой будут директории, содержащие конфигурационные файлы для отдельных машин.
# mkdir /var/puppet/centos7-2.test.local
# cd /var/puppet/centos7-2.test.local
# mkdir etc
# mkdir -p var/named/slaves

В новой директории etc разместим файл named.conf. Возьмем стандартный файл и внесем в него некоторые изменения. Не буду приводить тут весь файл, только измененные и добавленные строки.
listen-on port 53 { any; };
listen-on-v6 port 53 { none; };
allow-query     { any; };
dnssec-enable no;
dnssec-validation no;
zone «test.local» IN {
type master;
file «test.local»;
allow-update { none; };
allow-query { any; };
allow-transfer { none; };
};
zone «200.168.192.in-addr.arpa» IN {
type master;
file «200.168.192»;
allow-update { none; };
allow-query { any; };
allow-transfer { none; };
};

В директории var/named создадим два файла описания зон
# cat var/named/test.local 
$TTL 86400 ; 1 day
test.local. IN SOA post.test.local. artur.test.local. (
2015091701 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NS centos7-2.test.local.
MX 10 post.test.local.
TXT «v=spf1 mx -all»
SPF «v=spf1 mx -all»

artur-office A 192.168.200.1
post A 192.168.200.97
centos7-2 A 192.168.200.98
centos7-1 A 192.168.200.99

# cat var/named/200.168.192 
$TTL 86400 ; 1 day
200.168.192.in-addr.arpa. IN SOA post.test.local. artur.test.local. (
2015091701 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
86400      ; minimum (1 day)
)
NS centos7-2.test.local.

99 IN PTR centos7-1.test.local.
98 IN PTR centos7-2.test.local.
97 IN PTR post.test.local.
1 IN PTR artur-office.test.local.

Проверкой синтаксиса мы должны заниматься сами. Поэтому:
# named-checkconf etc/named.conf
# named-checkzone test.local var/named/test.local 
zone test.local/IN: loaded serial 2015091701
OK
 # named-checkzone 200.168.192.in-addr.arpa var/named/200.168.192 
zone 200.168.192.in-addr.arpa/IN: loaded serial 2015091701
OK

Теперь необходимо что бы файловый сервер puppet узнал про нашу директорию с файлами.
# vim /etc/puppet/fileserver.conf
[configs]
        path /var/puppet
        allow *

Перезапустим сервер:
# systemctl restart puppetmaster

Внесем изменения в файл манифест site.pp. Сначала добавим новый класс.
class dns {
# для работы необходим пакет bind
    package { ‘bind’:
                ensure => installed
    }
    include ‘stdlib’
    # Отключим ipv6 у bind.
    # Для этого надо при запуске демона передать ему
    # параметр -4. Добавим соответствующую строку в
    # конфигурационный файл.
    file_line { ‘named_no_ipv6’:
        path => ‘/etc/sysconfig/named’,
        line => ‘OPTIONS=»-4″‘
    }
    # Конфигурационный файл демона
    file { «/etc/named.conf» :
        ensure => file,
        mode => ‘0640’,
# Путь к файлу на файловом сервере
# Я специально присвоил директории имя такое
        # же как и имя машины.
# Теперь можно пользоваться переменной $fqdn
# И если у нас появится другой DNS сервер,
        # то благодаря этой переменной
# мы спокойно разрулим кому какие конфиги
        # отдавать.
        source => «puppet:///configs/$fqdn/etc/named.conf»,
        require => Package[«bind»],
# После изменения файла сделаем reload 
        # серверу bind
        notify  => Service[«named»]
    }
    file { «/var/named» :
        path => «/var/named»,
        mode => ‘0640’,
        group => ‘named’,
        source => «puppet:///configs/$fqdn/var/named»,
# Тут у нас передается содержимое директории
        ensure => directory,
# Говорим, что бы передавались все файлы и
        # поддиректории.
# Вместо remote можно использовать true. 
        # Тогда в целевой директории будут удаляться
        # все файлы, которые отсутствуют в директории
        # шаблоне.
# Поскольку делал по быстрому, пока оставлю
        # так. Но в дальнейшем надо будет привести 
        # все в порядок.
        recurse => remote,
        sourceselect => all,
        require => Package[«bind»],
        notify  => Service[«named»]
    }
    service { ‘named’:
        enable => true,
        ensure => running,
        require => Package[«bind»]
    }
}

Ну и изменим соответствующую ноду.
node ‘centos7-2.test.local’ {
    include ‘baselinux’
    include ‘dns’
}

Пока остановимся. Останется только разрулить правила фаервола.

Поэтому, для ntpdate.service можно оставить простейший файл /etc/ntp.conf следующего содержания:
server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
server 3.centos.pool.ntp.org

Итого, нам надо удалить пакет ntp и добавить свой конфигурационный файл /etc/ntp.conf

Удалить пакет можно следующим образом:
package { ‘ntp’:
ensure => absent
}

Будет удален пакет, его конфигурационные файлы останутся на месте. Нам не надо удалять конфиги. Мы просто поменяем их содержимое.

Дальше надо будет добавить свой конфигурационный файл, убедившись, что пакет ntp не установлен, а ntpdate наоборот установлен.

Изменим класс ntpdate в файле манифеста следующим образом:
class ntpdate {
        package { ‘ntpdate’:
                ensure => installed
        }
        package { ‘ntp’:
                ensure => absent,
# Пакет, если он есть, надо удалить до того как
# будет создан файл /etc/ntp.conf
before => File[‘/etc/ntp.conf’]
        }
        # Определяем конфигурационный файл
        file { ‘/etc/ntp.conf’:
                ensure => file,
                owner  => ‘root’,
                group  => ‘root’,
                mode   => ‘0644’,
# Для создания файла необходимо наличие
# установленного пакета ntpdate
                require => Package[«ntpdate»],
                # Содержимое файла указываем прямо тут
                content => «server 0.centos.pool.ntp.org
server 1.centos.pool.ntp.org
server 2.centos.pool.ntp.org
server 3.centos.pool.ntp.org
«
        }
        service { ‘ntpdate’:
                enable => true,
                ensure => running,
                require => Package[«ntpdate»],
        }
}

Проверим конфиг на ошибки:
# puppet parser validate /etc/puppet/manifests/site.pp

В результате на клиенте:

• если установлен пакет ntp, он будет удаляться.
• будет добавлен или изменен файл /etc/ntp.conf

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

Если конфигурационные файлы большие, включаем файловый сервер puppet или ftp сервер или … Размещаем конфиги там. Но об этом в другой раз.