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!

puppet configuration-management

— pQd
source

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.

— David Pashley
source

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.

— pQd
source

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']

— Ethan Brouwer
source

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"]
            }

}

— CMag
source

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
}

— Tombart
source