summaryrefslogtreecommitdiff
path: root/puppet/master.md
diff options
context:
space:
mode:
authorSilvio Rhatto <rhatto@riseup.net>2018-05-22 19:21:28 -0300
committerSilvio Rhatto <rhatto@riseup.net>2018-05-22 19:21:28 -0300
commitc3a95d163bb7ea1b2e3e5e152c15347b316dde82 (patch)
tree818e6ff54ebb64d45c54cd8e43f7836b18b6c469 /puppet/master.md
parenta58cb394fd8b3dd67e21d996b0cf36d6dfc2cd87 (diff)
downloadpadrao-c3a95d163bb7ea1b2e3e5e152c15347b316dde82.tar.gz
padrao-c3a95d163bb7ea1b2e3e5e152c15347b316dde82.tar.bz2
Cleanup old stuff
Diffstat (limited to 'puppet/master.md')
-rw-r--r--puppet/master.md74
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.