fantoche: forçar a reinicialização do serviço após a modificação do arquivo de configuração

21

como posso garantir que, se uma nova versão do arquivo de configuração for baixada via fantoche do repositório principal para um dos servidores gerenciados, o serviço relevante seja reiniciado.

cenário típico - digamos que haja uma nova configuração munin ou apache. cliente fantoche descobre, sobrescreve arquivos locais ... e ... - como garantir que o serviço seja reiniciado / recarregado?

Muito obrigado!

puppet configuration-management

— pQd
fonte

23

Uma alternativa para notificar é se inscrever:

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

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

A diferença é que o relacionamento é descrito do outro lado. Por exemplo, você pode fazer o apache assinar o /etc/apache/httpd.conf, mas você faria um arquivo vhost notificar o apache, pois sua classe apache não saberá sobre todos os vhost que você possui.

Uma situação de extremidade dupla semelhante se aplica a requerer e antes. É apenas uma questão de que faz mais sentido na situação particular.

Como Chad mencionou, se você encontrar fantoches constantemente tentando iniciar seu serviço, precisará adicionar um parâmetro padrão, que é um regex a ser aplicado na lista de processos. Por padrão, o fantoche fará uma parada e começará a reiniciar um serviço. Se você adicionar "hasrestart => true", ele usará o comando especificado no parâmetro "restart" para reiniciar o serviço.

— David Pashley
fonte

22

parece que encontrei algo:

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

service { sshd:
    ensure => running
}

vamos ver como isso vai funcionar. de qualquer maneira, seus pensamentos sobre o assunto são bem-vindos.

— pQd
fonte

1

Sim. Você pode encontrar os detalhes no Puppet Tipo de Referência em "Metaparameters" ( reductivelabs.com/trac/puppet/wiki/TypeReference#metaparameters )

— Chad Huneycutt

1

Ah, e dependendo do seu sistema operacional, pode ser necessário jogar com os parâmetros hasstatus, hasrestart e / ou padrão do tipo de serviço.

— Chad Huneycutt 13/07/2009

2

(Eu sei que essa é uma pergunta super antiga, mas pensei em colocar meus dois centavos com uma (na minha opinião) uma maneira muito mais fácil de fazer isso)

Sinta-se à vontade para usar a notação de seta também:

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

ou

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

— Ethan Brouwer
fonte

em seu primeiro exemplo você não precisa notificar opção se você usar a seta

— c4f4t0r

Opa Eu apenas copiei e esqueci de tirar isso.

— Ethan Brouwer

1

Isso funciona para o 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
fonte

0

Existem várias notações equivalentes:

Notificar :

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

service { sshd:
    ensure => running
}

Inscreva-se :

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

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

Notação de seta :

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

Declarações de encadeamento

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

Se você deseja acionar em reloadvez de restart, ajuste a declaração de serviço:

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

— Tombart
fonte