Correcoes diversas

diff --git a/nodo.mdwn b/nodo.mdwn
index fa49180c3fb00097b2ebd24ed8dbbadd4bcbc8f5..04950d86fdf928798744a24645cfb9a1e6a8017a 100644 (file)
--- a/nodo.mdwn
+++ b/nodo.mdwn
@@ -12,28 +12,30 @@ Neste exemplo, assumiremos os seguites parâmetros:
 
     new=novo-host                         # hostname do novo nodo
     hydra=nome-do-grupo                   # nome da hydra
-    domain="`hydra $hydra config domain`" # dominio do projeto
+    domain="example.org"                  # dominio do projeto
 
 Ainda:
 
-* `admin@box$`: indica prompt da máquina do/a administrador.
-* `root@nodo$`: indica o prompt do novo nodo.
-* `root@master$`: indica o prompt do master.
+* `admin@box$`: indica shell da máquina do/a administrador.
+* `root@nodo$`: indica o shell do novo nodo.
+* `root@master$`: indica o shell do master.
+
+Certifique-se de configurar os parâmetros acima em cada um dos shells mencionados.
 
 Configuração de DNS
 -------------------
 
 O primeiro passo é criar uma entrade de DNS para o novo nodo. Use uma das
 seguintes configurações na interface de atualização de DNS, substituindo
-`$new`, `$ip` ou `example.org` pelos valores apropriados.
+`$node`, `$ip` ou `example.org` pelos valores apropriados.
 
 No caso de um registro `A`:
 
-    $new 3600 IN A $ip
+    $node 3600 IN A $ip
 
 No caso de um `CNAME`:
 
-    $new 3600 IN CNAME example.org.
+    $node 3600 IN CNAME example.org.
 
 Provisionamento
 ---------------
@@ -51,16 +53,16 @@ Definição do nodo
 
 Definição básica do nodo:
 
-    admin@box$ hydra $hydra newnode $new # cria definicoes minimas para o nodo
+    admin@box$ hydra $hydra newnode $node # cria definicoes minimas para o nodo
     admin@box$ hydra $hydra newkeys      # criar as chaves necessarias para o nodo
 
-Após esses comandos, é preciso editar o arquivo `puppet/hiera/production/domain/$domain/$new.$domain.yaml`
+Após esses comandos, é preciso editar o arquivo `puppet/hiera/production/domain/$domain/$node.$domain.yaml`
 e ajustar configurações básicas de chaves, senhas, etc.
 
 Em seguida, submeta as mudanças para o repositório:
 
     admin@box$ cd `hydra $hydra folder`
-    admin@box$ git commit -a -m "Adicionando nodo $new"
+    admin@box$ git commit -a -m "Adicionando nodo $node"
 
 Configurando o puppet
 ---------------------
@@ -76,11 +78,11 @@ Lembre-se de iniciar o `puppet agent` pela primeira vez através de um comando d
 No caso de uma porta fora do padrão, use o parâmetro `--masterport`. Em seguida, verifique se
 os fingerprints dos certificados (master e nodo) coincidem. No master:
 
-    root@master$ puppet cert list --digest sha1 | grep camada.projeto.org
+    root@master$ puppet cert list --digest sha1 | grep $node.$domain
 
 Caso os fingerprints batam, basta liberar o novo nodo a partir do host em que roda o master como o comando
 
-    root@master$ puppet cert sign camada.projeto.org
+    root@master$ puppet cert sign $node.$domain
 
 Assista as mudanças nos arquivos de log (`/var/log/daemon.log` ou `/var/log/syslog`):
 
@@ -93,14 +95,14 @@ Deploy da Hydra Suite
 
 Faça o deploy da hidra suite no novo nodo:
 
-    admin@box$ hydra $projeto deploy camada.projeto.org
+    admin@box$ hydra $hydra deploy $node.$domain
 
 Chaves de backup
 ----------------
 
 Envie a chave OpenPGP gerada para backups no novo nodo:
 
-    admin@box$ hydra $projeto import-key camada.projeto.org
+    admin@box$ hydra $hydra import-key $node.$domain
 
 Fingerprints e Monkeysphere
 ---------------------------
@@ -115,4 +117,4 @@ Opcionalmente, proceda com a [configuração das chaves de serviço do monkeysph
 Inscrição em lista de mensagens
 -------------------------------
 
-Caso o alias de email para `root` esteja configurado para o endereço de uma lista de discussão privada de email (o que permite um grupo de administradores/as monitorarem mensagens de sistema), certifique-se de configurar os endereços de `root@camada.projeto.org` e demais endereços como assinantes da lista no modo `no mail` (sem recebimento). Assim, eles poderão enviar mensagens mas não receberão nenhuma mensagem da lista.
+Caso o alias de email para `root` esteja configurado para o endereço de uma lista de discussão privada de email (o que permite um grupo de administradores/as monitorarem mensagens de sistema), certifique-se de configurar os endereços de `root@$node.$domain` e demais endereços como assinantes da lista no modo `no mail` (sem recebimento). Assim, eles poderão enviar mensagens mas não receberão nenhuma mensagem da lista.