marionnette: force le redémarrage du service après la modification du fichier de configuration


21

comment puis-je m'assurer que si une nouvelle version du fichier de configuration est téléchargée via la marionnette du référentiel maître vers l'un des serveurs gérés, le service concerné est redémarré.

scénario typique - disons qu'il y a une nouvelle configuration munin ou apache. le client marionnette le découvre, écrase les fichiers locaux ... et ... - comment s'assurer que le service est redémarré / rechargé?

Merci beaucoup!

Réponses:


23

Une alternative pour notifier est de vous abonner:

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

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

La différence étant que la relation est décrite de l'autre côté. Par exemple, vous pouvez obliger apache à s'abonner à /etc/apache/httpd.conf, mais vous feriez un fichier vhost notifier apache, car votre classe apache ne connaîtra pas tous les vhost que vous avez.

Une situation similaire à deux extrémités s'applique pour exiger et avant. C'est juste une question qui a plus de sens dans la situation particulière.

Comme Chad l'a mentionné, si vous trouvez une marionnette essayant constamment de démarrer votre service, vous devez ajouter un paramètre de modèle, qui est une expression régulière à appliquer à la liste des processus. Par défaut, la marionnette fera un arrêt et commencera à redémarrer un service. Si vous ajoutez "hasrestart => true", il utilisera la commande spécifiée dans le paramètre "restart" pour redémarrer le service.


22

il semble que j'ai trouvé quelque chose:

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

service { sshd:
    ensure => running
}

nous verrons comment cela fonctionnera. de toute façon, vos réflexions sur le sujet sont les bienvenues.


1
Oui. Vous pouvez trouver les détails dans la référence de type de marionnette sous "Métaparamètres" ( reductivelabs.com/trac/puppet/wiki/TypeReference#metaparameters )
Chad Huneycutt

1
Oh, et selon votre système d'exploitation, vous devrez peut-être jouer avec les paramètres hasstatus, hasrestart et / ou pattern du type de service.
Chad Huneycutt

2

(Je sais que c'est une très vieille question, mais je pensais juste mettre mes deux cents avec un moyen (à mon avis) beaucoup plus facile de le faire)

N'hésitez pas à utiliser également la notation fléchée:

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

ou

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

dans votre premier exemple, vous n'avez pas besoin de l'option de notification si vous utilisez la flèche
c4f4t0r

Oops. Je viens de copier et j'ai oublié de retirer ça.
Ethan Brouwer

1

Cela fonctionne pour 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"]
            }

}

0

Il existe plusieurs notations équivalentes:

Avertissez :

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

service { sshd:
    ensure => running
}

Abonnez-vous :

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

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

Notation des flèches :

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

Enchaînement des déclarations

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

Si vous souhaitez déclencher reloadau lieu de restart, ajustez la déclaration de service:

service { sshd:
    ensure => running,
    restart => 'pkill -HUP sshd', # if service support such reload
}
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.