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

21

¿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!

puppet configuration-management

— pQd
fuente

23

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.

— David Pashley
fuente

22

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.

— pQd
fuente

1

Sí. Puede encontrar los detalles en la Referencia del tipo de títere en "Metaparameters" ( reductivelabs.com/trac/puppet/wiki/TypeReference#metaparameters )

— Chad Huneycutt el

1

Ah, y dependiendo de su sistema operativo, es posible que tenga que jugar con los parámetros hasstatus, hasrestart y / o pattern del tipo de servicio.

— Chad Huneycutt

2

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

— Ethan Brouwer
fuente

en su primer ejemplo, no necesita la opción de notificación si usa la flecha

— c4f4t0r

Ups Simplemente copié y olvidé sacar eso.

— Ethan Brouwer

1

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

}

— CMag
fuente

0

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
}

— Tombart
fuente