diff options
author | Silvio Rhatto <rhatto@riseup.net> | 2018-05-22 19:21:28 -0300 |
---|---|---|
committer | Silvio Rhatto <rhatto@riseup.net> | 2018-05-22 19:21:28 -0300 |
commit | c3a95d163bb7ea1b2e3e5e152c15347b316dde82 (patch) | |
tree | 818e6ff54ebb64d45c54cd8e43f7836b18b6c469 /puppet | |
parent | a58cb394fd8b3dd67e21d996b0cf36d6dfc2cd87 (diff) | |
download | padrao-c3a95d163bb7ea1b2e3e5e152c15347b316dde82.tar.gz padrao-c3a95d163bb7ea1b2e3e5e152c15347b316dde82.tar.bz2 |
Cleanup old stuff
Diffstat (limited to 'puppet')
-rw-r--r-- | puppet/master.md | 74 |
1 files changed, 0 insertions, 74 deletions
diff --git a/puppet/master.md b/puppet/master.md deleted file mode 100644 index 1a44775..0000000 --- a/puppet/master.md +++ /dev/null @@ -1,74 +0,0 @@ -Configurando um master -====================== - -Procedimento para configurar um novo master e eventualmente assumi-lo como o -master principal da rede. - -Deploy do nodo --------------- - -* Assumiremos `$old` como o hostname do master antigo. -* Nós usaremos o master `$old` para configurar o master `$node`. -* Assim, siga as [instruções para adicionar um nodo](/nodo), levando em conta: - * Inicialmente, a configuração do nodo com `nodo::role::master::main: false`. - * Se o nodo for assumir o papel de um master principal, use `nodo::role::master::main: true` - após a aplicação do primeiro catálogo. - -Mudança de porta ----------------- - -Em alguns casos -- dependendo de onde o novo master for hospedado --, pode ser necessário -usar uma porta fora do padrão para o `puppetmaster`. - -No caso de mudança de portas do puppetmaster, comunicar essa mudança aos nodos -via `puppet::daemon::port` e aguardar aplicação de catálogo de todos os nodos. - -Mudança do DNS --------------- - -Esta etapa consiste em fazer a atualização do DNS, para que os nodos acessando `puppet.$domain` -caiam direto no novo master. Use a seguinte configuração na interface de atualização de DNS, -substituindo `$node.$domain` pelo domínio do novo master (o ponto final é importante): - - admin 3600 IN CNAME $node.$domain. - munin 3600 IN CNAME $node.$domain. - nagios 3600 IN CNAME $node.$domain. - puppet 3600 IN CNAME $node.$domain. - -As próximas etapas podem ser executadas enquanto o DNS é propagado. - -Importação da chave de backups ------------------------------- - -Para importar a chave privada do nodo `$old` no nodo `$node`, use - - admin@box$ HOST=$old hydra $hydra import-key $node - -Restore dos backups -------------------- - -Assumindo que o backup criptografado já esteja disponível em `$node:/var/backups/remote/$old.$domain`: - - root@master$ hydractl backup-restore-master $old - -Após o restore, o nodo deverá estar pronto para assumir o papel de master. - -Atualize seu ~/.ssh/config --------------------------- - -Exemplo de configuração pessoal, substituindo as variáveis de acordo: - - Host admin.$domain - HostName $node.$domain - Port $porta - -Assim, independentemente qual seja o nodo master atual, ele sempre estará acessível pelo alias `admin.$domain`, -evitando mudanças desnecessárias e tediosas em referências de inúmeros repositórios. - -Possíveis problemas -------------------- - -As seguintes mensagens de erro podem aparecer no novo master depois de sua ativação: - -* "You cannot collect without storeconfigs being set": o problema tende a desaparecer conforme os exported resources forem sendo definidos. -* [Collected resources with a puppet master fail on Ruby 1.9.x](http://projects.puppetlabs.com/issues/10963): basta aplicar o patch manualmente. |