From 99eb59e02948c77c27d68e31cc7765ddd547c3be Mon Sep 17 00:00:00 2001
From: Silvio Rhatto <rhatto@riseup.net>
Date: Fri, 20 Mar 2015 11:26:16 -0300
Subject: Sobre novos puppetmasters

---
 puppet.mdwn        |  5 ++++
 puppet/master.mdwn | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 79 insertions(+)
 create mode 100644 puppet/master.mdwn

diff --git a/puppet.mdwn b/puppet.mdwn
index 4cb5df0..67a672d 100644
--- a/puppet.mdwn
+++ b/puppet.mdwn
@@ -209,3 +209,8 @@ Refer
 -----------
 
 * [Puppet no Riseup](https://we.riseup.net/riseup+tech/puppet). 
+
+Adicionando mais masters
+========================
+
+[Como adicionar mais puppetmasters](master).
diff --git a/puppet/master.mdwn b/puppet/master.mdwn
new file mode 100644
index 0000000..1a44775
--- /dev/null
+++ b/puppet/master.mdwn
@@ -0,0 +1,74 @@
+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.
-- 
cgit v1.2.3