puppet: Neustart des Dienstes erzwingen, nachdem die Konfigurationsdatei geändert wurde

21

Wie kann ich sicherstellen, dass der relevante Dienst neu gestartet wird, wenn eine neue Version der Konfigurationsdatei über Puppet vom Master-Repository auf einen der verwalteten Server heruntergeladen wird?

typisches Szenario - Angenommen, es gibt eine neue Munin- oder Apache-Konfiguration. Puppet Client entdeckt es, überschreibt lokale Dateien ... und ... - wie kann sichergestellt werden, dass der Dienst neu gestartet / neu geladen wird?

Vielen Dank!

puppet configuration-management

— pQd
quelle

23

Eine Alternative zur Benachrichtigung ist das Abonnieren von:

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

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

Der Unterschied besteht darin, dass die Beziehung vom anderen Ende her beschrieben wird. Beispielsweise können Sie Apache veranlassen, /etc/apache/httpd.conf zu abonnieren, aber Sie möchten, dass eine vhost-Datei Apache benachrichtigt, da Ihre Apache-Klasse nicht über jeden vhost informiert ist, den Sie haben.

Eine ähnliche Situation mit zwei Enden gilt für require und before. Es ist nur eine Frage, die in der jeweiligen Situation sinnvoller ist.

Wie Chad bereits erwähnt hat, müssen Sie, wenn Marionetten ständig versuchen, Ihren Dienst zu starten, einen Musterparameter hinzufügen, der ein regulärer Ausdruck für die Liste der Prozesse ist. Standardmäßig stoppt und startet Puppet einen Dienst neu. Wenn Sie "hasrestart => true" hinzufügen, wird der Dienst mit dem im Parameter "restart" angegebenen Befehl neu gestartet.

— David Pashley
quelle

22

Es scheint, als hätte ich etwas gefunden:

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

service { sshd:
    ensure => running
}

Mal sehen, wie das geht. Wie auch immer, Ihre Gedanken zu diesem Thema sind willkommen.

— pQd
quelle

1

Ja. Sie finden die Details in der Puppet Type Reference unter "Metaparameters" ( reductivelabs.com/trac/puppet/wiki/TypeReference#metaparameters )

— Chad Huneycutt,

1

Oh, und abhängig von Ihrem Betriebssystem müssen Sie möglicherweise mit den Parametern hasstatus, hasrestart und / oder pattern des Diensttyps spielen.

— Chad Huneycutt

2

(Ich weiß, dass dies eine super alte Frage ist, aber ich dachte nur, ich würde meine zwei Cent mit einem (meiner Meinung nach) viel einfacheren Weg einsetzen)

Sie können auch die Pfeilnotation verwenden:

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

oder

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

— Ethan Brouwer
quelle

In Ihrem ersten Beispiel benötigen Sie keine Benachrichtigungsoption, wenn Sie den Pfeil verwenden

— c4f4t0r

Hoppla. Ich habe nur kopiert und vergessen, das herauszunehmen.

— Ethan Brouwer

1

Dies funktioniert für 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
quelle

0

Es gibt mehrere äquivalente Notationen:

Benachrichtigen :

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

service { sshd:
    ensure => running
}

Abonnieren :

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

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

Pfeilnotation :

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

Verkettung von Deklarationen

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

Wenn Sie reloadstatt auslösen möchten restart, passen Sie die Service-Deklaration an:

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

— Tombart
quelle