marioneta: forzar el reinicio del servicio después de modificar el archivo de configuración

¿Cómo puedo asegurarme de que si se descarga una nueva versión del archivo de configuración a través de una marioneta desde el repositorio maestro a uno de los servidores administrados, se reinicie el servicio relevante?

escenario típico: digamos que hay una nueva configuración de munin o apache. Puppet Client lo descubre, sobrescribe los archivos locales ... y ... ¿cómo asegurarse de que el servicio se reinicie / vuelva a cargar?

¡muchas gracias!

Una alternativa para notificar es suscribirse:

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

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

La diferencia es que la relación se describe desde el otro extremo. Por ejemplo, puede hacer que apache se suscriba a /etc/apache/httpd.conf, pero haría que un archivo vhost notifique a apache, ya que su clase apache no sabrá acerca de cada vhost que tenga.

Una situación similar de doble extremo se aplica a require y before. Es solo una cuestión de lo que tiene más sentido en la situación particular.

Como mencionó Chad, si encuentra a Puppet constantemente intentando iniciar su servicio, entonces necesita agregar un parámetro de patrón, que es una expresión regular para aplicar en la lista de procesos. Por defecto, Puppet se detendrá y comenzará a reiniciar un servicio. Si agrega "hasrestart => true", utilizará el comando especificado en el parámetro "restart" para reiniciar el servicio.

Parece que he encontrado algo:

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

service { sshd:
    ensure => running
}

veremos cómo funcionará eso. de todos modos sus pensamientos sobre el tema son bienvenidos.

(Sé que esta es una pregunta muy antigua, pero solo pensé en poner mis dos centavos con una (en mi opinión) una forma mucho más fácil de hacerlo)

Siéntase libre de usar la notación de flecha también:

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

o

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

Esto funciona para 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"]
            }

}

Hay múltiples anotaciones equivalentes:

notificar :

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

service { sshd:
    ensure => running
}

Subscribe :

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

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

Notación de flecha :

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

Encadenamiento de declaraciones

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

Si desea activar en reloadlugar de restart, ajuste la declaración de servicio:

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