puppet: wymusza restart usługi po modyfikacji pliku konfiguracyjnego

jak mogę się upewnić, że jeśli nowa wersja pliku konfiguracyjnego zostanie pobrana za pośrednictwem marionetki z głównego repozytorium na jeden z zarządzanych serwerów, uruchomiona zostanie odpowiednia usługa.

typowy scenariusz - powiedzmy, że jest nowa konfiguracja Munina lub Apache. klient kukiełkowy odkrywa go, zastępuje lokalne pliki ... i ... - jak upewnić się, że usługa zostanie ponownie uruchomiona / ponownie załadowana?

wielkie dzięki!

Alternatywą dla powiadomienia jest subskrypcja:

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

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

Różnica polega na tym, że związek jest opisany z drugiego końca. Na przykład, możesz zmusić apache do subskrybowania pliku /etc/apache/httpd.conf, ale możesz ustawić plik vhost powiadamiający apache, ponieważ twoja klasa apache nie będzie wiedziała o każdym twoim vhostie.

Podobna sytuacja podwójnego zakończenia ma zastosowanie do wcześniejszych wymagań. To tylko kwestia, która ma większy sens w konkretnej sytuacji.

Jak wspomniał Chad, jeśli marionetka ciągle próbuje uruchomić usługę, musisz dodać parametr wzorca, który jest wyrażeniem regularnym, które można zastosować do listy procesów. Domyślnie marionetka zatrzyma się i zacznie ponownie uruchamiać usługę. Jeśli dodasz „hasrestart => true”, użyje polecenia określonego w parametrze „restart”, aby zrestartować usługę.

wygląda na to, że znalazłem coś:

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

service { sshd:
    ensure => running
}

zobaczymy, jak to będzie działać. tak czy inaczej, twoje przemyślenia na ten temat są mile widziane.

(Wiem, że to bardzo stare pytanie, ale pomyślałem, że włożyłem dwa centy w (moim zdaniem) znacznie łatwiejszym sposobem, aby to zrobić)

Możesz również użyć notacji strzałek:

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

lub

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

Działa to w systemie 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"]
            }

}

Istnieje wiele równoważnych notacji:

Powiadom :

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

service { sshd:
    ensure => running
}

Subskrybuj :

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

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

Notacja ze strzałką :

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

Łańcuchowe deklaracje

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

Jeśli chcesz uruchomić reloadzamiast restart, dostosuj deklarację usługi:

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