маріонетка: примусовий перезапуск служби після зміни файлу конфігурації

21

як я можу гарантувати, що якщо нова версія конфігураційного файлу буде завантажена через маріонетку з головного сховища на один з керованих серверів, буде відновлена відповідна послуга.

типовий сценарій - скажімо, існує новий munin або apache config. ляльковий клієнт виявляє його, перезаписує локальні файли ... і ... - як переконатися, що послуга перезапущена / перезавантажена?

дуже дякую!

puppet configuration-management

— pQd
джерело

23

Альтернатива сповіщення - підписатися:

file { "/etc/sshd_config":
    source => "....",
}

service { sshd:
    ensure => running,
    subscribe => File["/etc/sshd_config"],
}

Різниця полягає в тому, що відносини описані з іншого кінця. Наприклад, ви можете змусити apache підписатися на /etc/apache/httpd.conf, але ви зробите файл vhost, щоб сповістити apache, оскільки ваш клас apache не буде знати про кожен ваш vhost.

Аналогічна ситуація з подвійним завершенням стосується вимагати і раніше. Це лише питання, яке має більше сенсу в конкретній ситуації.

Як згадував Чад, якщо ви виявляєте, що лялька постійно намагається запустити свою послугу, вам потрібно додати параметр шаблону, який буде регулярно виражатися з переліком процесів. За замовчуванням лялька зробить зупинку і почне перезапускати послугу. Якщо ви додасте "hasrestart => true", то для повторного запуску послуги вона використовуватиме команду, вказану в параметрі "restart".

— Девід Пашлі
джерело

22

здається, я щось знайшов:

file { "/etc/sshd_config":
    source => "....",
    notify => Service[sshd]
}

service { sshd:
    ensure => running
}

ми побачимо, як це буде працювати. у будь-якому випадку ваші думки з цього приводу вітаються.

— pQd
джерело

1

Так. Подробиці ви можете знайти у

— Довідці про тип лялечки у

1

О, і залежно від вашої ОС, можливо, вам доведеться грати з параметрами hasstatus, hasrestart та / або шаблоном типу послуги.

— Чад Хунейкутт

2

(Я знаю, що це дуже старе питання, але я просто подумав, що поставив би два центи із (на мій погляд) набагато простішим способом зробити це)

Сміливо також використовуйте позначення стрілок:

file { "/etc/sshd_config":
  source => "....",
} ~>
service { sshd:
  ensure => running
}

або

File['/etc/sshd_config'] ~> Service['sshd']

— Етан Брауер
джерело

у вашому першому прикладі вам не потрібен варіант сповіщення, якщо ви використовуєте стрілку

— c4f4t0r

На жаль Я просто скопіював і забув це вийняти.

— Етан Брауер

1

Це працює для Solaris 10 :)

class sun_cron_root {
    file { "/var/spool/cron/crontabs/root" :
            source => "puppet:///files/cron/sun/sun_cron_root"
            }

    service {
            "cron":
            provider => "smf",
            ensure => running,
            enable => true,
            hasrestart => true,
            subscribe => File["/var/spool/cron/crontabs/root"]
            }

}

— CMag
джерело

0

Існує кілька еквівалентних позначень:

Повідомте :

file { '/etc/sshd_config':
    notify => Service[sshd],
}

service { sshd:
    ensure => running
}

Підписатися :

file { '/etc/sshd_config':
   ...
}

service { sshd:
    ensure => running,
    subscribe => File['/etc/sshd_config'],
}

Позначення стрілки :

File['/etc/sshd_config'] ~> Service['sshd']

Пов'язування декларацій

file { '/etc/sshd_config':
   ...
}
~> service { sshd:
    ensure => running,
}

Якщо ви хочете запустити reloadзамість restart, відрегулюйте службову декларацію:

service { sshd:
    ensure => running,
    restart => 'pkill -HUP sshd', # if service support such reload
}

— Томбарт
джерело