Feat: migrate docs from Ikiwiki to MkDocs

42 files changed, 846 insertions, 1413 deletions

diff --git a/.gitignore b/.gitignore
index 47221fc..006d50c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /.ikiwiki
 /recentchanges
 /www
+site
diff --git a/Makefile b/Makefile
index adda109..dd13f69 100644
--- a/Makefile
+++ b/Makefile
@@ -1,5 +1,5 @@
 #
-#  Ikiwiki Makefile by Silvio Rhatto (rhatto at riseup.net).
+#  Makefile for Padrão Fluxo by Silvio Rhatto (rhatto at riseup.net).
 #
 #  This Makefile is free software; you can redistribute it and/or modify it
 #  under the terms of the GNU General Public License as published by the Free
@@ -15,9 +15,9 @@
 #
 
 web:
-	@ikiwiki --setup ikiwiki.yaml
+	@mkdocs build
 
 web_deploy:
-	@rsync -avz --delete www/ padrao:/var/sites/padrao/www/
+	@rsync -avz --delete site/ padrao:/var/sites/padrao/www/
 
 publish: web web_deploy
diff --git a/audit.md b/audit.md
deleted file mode 100644
index 24b9a0a..0000000
--- a/audit.md
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!toc levels=4]]
-
-Auditoria 
-=========
-
-Resetando senhas em banco de dados
-----------------------------------
-
-Considerando que as senhas se encontram na coluna `pass` da tabela `users` e que se encontram armazenadas em hashes md5, utilize o comando
-
-    update users set pass = md5('SENHA');
-
-onde `SENHA` é uma senha longa e complicada.
-
-Busca por vírus
----------------
-
-    freshclam --datadir=$datadir
-    clamscan --database=$datadir -r *
-
diff --git a/backup.md b/backup.md
deleted file mode 100644
index a14c616..0000000
--- a/backup.md
+++ /dev/null
@@ -1,10 +0,0 @@
-[[!toc levels=4]]
-
-Backup
-======
-
-* [Conceitos](concepts).
-* [Convenções](conventions).
-* [Métodos](methods).
-* [Restauração](restore).
-* [Migração de sites](migration).
diff --git a/backup/concepts.md b/backup/concepts.md
deleted file mode 100644
index 94f1b78..0000000
--- a/backup/concepts.md
+++ /dev/null
@@ -1,35 +0,0 @@
-
-[[!toc  levels=4]]
-
-Da natureza dos backups 
-=======================
-
-Um backup pode ser entendido como qualquer cópia feita para assegurar a existência de uma informação ou configuração em virtude da falta de garantia de que seu "suporte" físico consiga mantê-la.
-
-Podemos fazer uma analogia bem limitada com uma floresta com espécies endêmicas: se ocorrer uma queimada, as espécies se perdem a não ser que exista um banco de sementes intacto que permita o plantio das espécies ameaçadas.
-
-Esse exemplo da floresta é limitado porque no caso de um backup de dados digitais a informação se preserva ao transportá-la para outro suporte físico (isto é, configurar o conjunto de estados possíveis do "suporte" físico, por exemplo disco rígido, DVD, pendrive, de modo a reproduzir uma dada configuração presente anteriormente num outro suporte físico: o backup é a reprodução de um conjunto de estados de um sistema), o que não ocorre num reflorestamento.
-
-Guardar TODA informação existente em uma floresta, numa vizinhança ou mesmo na memória de um povo é uma tarefa inatingível, o que faz qualquer floresta, qualquer vizinhança ou povo insubstituíveis. Vejamos a cultura: ela se reproduz e contamina, quase sempre com mutações...
-
-Nesse sentido, backups de dados digitais são tarefas bem mais simples e possíveis, porque os temos e os conseguimos copiá-los com exatidão. Não há uma receita única para fazer um backup digital: a simples cópia de um arquivo de um suporte a outro já pode ser considerado como um backup.
-Parâmetros dos backups 
-
-Existem diversos parâmetros importantes quando se trata de um backup digital:
-
-1. Periodicidade.
-2. Incrementos.
-3. Largura de banda.
-4. Segurança e integridade dos dados. 
-
-O primeiro deles é a própria modifição realizada pelo uso dos dados. Um sítio em HTML, Wiki ou Drupal nem sempre -- imagino que no caso dos sítios aqui da vizinhana quase nunca -- se mantém estáticos, sem modificações. Por isso, um backup de um sítio há um mês não conterá as alterações de um sítio realizadas nas duas últimas semanas. O primeiro parâmetro então a periodicidade na qual os backups são realizados.
-
-O segundo parâmetro mais ou menos conseqüência do primeiro: se copiarmos um sítio de um disco para outro a cada semana, podemos atualizar o backup com as alterações realizadas num sítio mas ao mesmo tempo, caso não tenhamos cuidado, podemos também estar apagando o estado que o sítio tinha anteriormente, antes dessas últimas modificações. Em outras palavras, o segundo parâmetro de um backup, a quantidade de "incrementos" que teremos: podemos copiar um sítio para um DVD e, daqui a duas semanas, copiar novamente mas para um outro DVD. Se por um acaso precisarmos de uma informação que continha há duas semanas no sítio, basta que a resgatemos do primeiro DVD. Agora, manter esses "incrementos", isto é, um DVD para cada backup, tem um custo físico e nesse caso ecológico muito grande. É preciso então escolher um número de "incrementos" que permita que tenhamos uma boa amostragem das modificações realizadas num sítio sem que gastemos muito tempo, espaço em disco ou mídia física com tal atividade.
-
-Não entraremos em detalhes, mas um backup que queira dar conta de modificações realizadas em intervalos de duas semanas deve ser realizado pelo menos a cada semana (teorema da amostragem de [Nyquist-Shannon](http://en.wikipedia.org/wiki/Nyquist-Shannon)).
-
-O terceiro parâmetro é a largura de banda. Copiar um sítio de um lugar para outro demanda um tempo de transferência. No caso de sítios muito grandes, a cópia pode demorar tempo demais e o backup se torna mais uma dificuldade do que um benefício. Por isso, a largura de banda pode obrigar que façamos alguns truques: a compressão dos dados (arquivo .zip, tar.gz, tar.bz2, etc) e a cóipia apenas dos arquivos que foram modificados. Por exemplo, num sítio que tem vários vídeos nem todos eles precisam ser copiados a cada backup, mas sim os novos ou aqueles que foram modificados.
-
-O quarto parâmetro é a segurança e a integridade dos dados: se você possui informações sensíveis (senhas, contatos e tudo o mais que for delicado para se tornar público ou cair em mãos erradas), tome cuidado para onde vai copiar essas informações e onde as deixar armazenadas. Da mesma forma, a checagem da integridade dos arquivos verifica se estes não sofreram alterações durante o procedimento de backup.
-
-Em resumo, esses são os quatro parâmetros básicos para um backup: periodicidade, incremento, largura de banda e segurança/integridade. 
diff --git a/backup/conventions.md b/backup/conventions.md
deleted file mode 100644
index b7e85a9..0000000
--- a/backup/conventions.md
+++ /dev/null
@@ -1,40 +0,0 @@
-[[!toc  levels=4]]
-
-Convenções
-==========
-
-Esta página contém esboço para as convenções de intercâmbio de backups entre servidores. Qualquer que seja o método de backup, ele deve satisfazer as seguintes condições:
-
-1. Deve ser incremental para que vários estados diários sejam possíveis de se obter.
-2. Devem ser gerenciados pelo backupninja.
-3. Cada projeto cuida dos seus próprios backups, mesmo que estes estejam sendo enviados para o servidor de outro projeto. 
-
-Armazenamento 
--------------
-
-1. Backups hospedados em `/var/backups`, mesmo que seja symlink para outro local.
-2. Arquivos de log de backup em `/var/log/{backup,backupninja.log}`, rodando via logrotate.
-3. Backups remotos de servidores e sites em subpastas do tipo `/var/backups/remote/nome-da-camada.projeto.org/handler`.
-4. Backups locais criptografados em `/var/backups/duplicity` e sem backup da pasta `/var/backups/remote`.
-5. Máquinas enviando backups para outros locais enviam apenas o backup local criptografado. 
-
-O que incluir nos backups locais
---------------------------------
-
-Talvez a convenção mais forte para a inclusão de arquivos seja aquela na qual a inclusão de novos arquivos e pastas nos backups seja automática. Assim, a convenção adotada é a realização de backups das pastas
-
-* `/etc`
-* `/var`
-* `/home` 
-
-Para que a convenção funcione, é indispensável que conteúdos (dados) hospedados sejam armazenados apenas nestas pastas. Como a `/etc` é uma pasta reservada ao armazenamento de configurações, restam apenas `/var` e `/home` para o armazenamento de dados. Assim, a utilização de pastas do tipo `/var/svn`, `/var/www`, etc garantem a inclusão automática de todo o conteúdo hospedado nos backups.
-
-Não incluir em backups locais
------------------------------
-
-As seguintes pastas não devem ser incluídas em backups:
-
-* `/var/backups/duplicity`
-* `/var/backups/remote`
-* `/var/vservers`
-* `/vservers`
diff --git a/backup/methods.md b/backup/methods.md
deleted file mode 100644
index 1cc18aa..0000000
--- a/backup/methods.md
+++ /dev/null
@@ -1,82 +0,0 @@
-[[!toc  levels=4]]
-
-Métodos para backup remoto 
-==========================
-
-Esta página contém um estudo dos métodos de produção, transferência e armazenamento de backups, divididos nas partes:
-
-* Métodos de tranferência
-* Métodos de armazenamento 
-
-A discussão aqui não tem caráter prático mas meramente teórico, sem menção às implementações dos métodos. Para isso, veja a página [Convencoes](../conventions).
-
-Métodos de transferência
--------------------------
-
-### Método 1: rsync + hardlinks 
-
-Vantagens:
-
-* Economiza espaço
-* Simples de configurar 
-
-Desvantagens:
-
-* Precisa rodar como root nas duas máquinas/vservers para preservar permissões
-* Workarround: criar um `FILELIST.TXT` para cada vserver indicando as permissões e os proprietários dos arquivos, juntamente com um script que corrija todas essas permissões no caso de um restauro de backup. 
-
-### Método 2: tar + ssh 
-
-Esse método consiste em criar um `.tar.bz2` num pipe direto para o servidor remoto, sem escrita local em disco, isto é,
-
-    nice -n 19 tar c /mnt/backup/servidor/vservers/vservers.0/ | bzip2 | \
-    ssh servidor-remoto "cat - > servidor-vservers-0.tar.bz2"
-
-Vantagens:
-
-* o arquivo transferido preserva todas as permissões do seu conteúdo
-* no servidor remoto o arquivo fica compactado
-* rodar com um nice alto garante que esse comando não atrapalhará o funcionamento normal do sistema 
-
-Para economizar espaço na máquina remota, podemos operar com backups incrementais:
-
-    nice -n 19 tar cv /mnt/backup/servidor/vservers/vservers.0/ --listed-incremental=/var/log/backup/vservers.snar \ |
-    bzip2 | ssh servidor-remoto "cat - > servidor-vservers-`date +%w`.tar.bz2" >> /var/log/backup/servidor-remoto.log
-
-Nesse caso, uma vez por semana as seguintes operações devem ser feitas:
-
-* Mover todos os arquivos para uma pasta da "semana passada"
-* Iniciar um novo full-dump. 
-
-Desvantagem: full-dump semanal.
-
-### Método 3: GNU backup
-
-O script backup que acompanha o GNU tar pode ser usado para fazer dumps incrementais locais que depois são enviados aos servidores remotos.
-
-Desvantagem: arquivos não podem ser modificados durante a confecção do backup.
-
-### Método 4: duplicity
-
-* <http://www.nongnu.org/duplicity>
-* backups criptografados 
-
-### Método 5: rdiff-backup
-
-* <http://www.nongnu.org/rdiff-backup> 
-
-Métodos de armazenamento 
-------------------------
-
-### Método 1: vserver dedicado a backups
-
-Cada servidor possui um único vserver dedicado a puxar os backups dos outros servidores. Esse vserver não terá acesso externo e por isso é a abordagem mais segura de armazenamento.
-
-Veja uma discussão sobre isso em <https://docs.indymedia.org/view/Sysadmin/PullBackupsForParanoiacs>.
-
-### Método 2: vservers dedicados a cada servidor
-
-Cada servidor possui seu próprio vserver em cada máquina remota onde ele fizer backup. Nesse vserver os backups remotos poderão ser feitos como root sem acarretar perda de segurança para a máquina remota, o que faz essa ser a abordagem mais flexível para puxar ou receber backups remotos.
-Backups criptografados 
-
-Veja uma discussão sobre isso em <https://wiki.boum.org/TechStdOut/EncryptedBackupsForParanoiacs>.
diff --git a/docs/audit.md b/docs/audit.md
new file mode 100644
index 0000000..74a932b
--- /dev/null
+++ b/docs/audit.md
@@ -0,0 +1,16 @@
+# Auditoria 
+
+## Resetando senhas em banco de dados
+
+Considerando que as senhas se encontram na coluna `pass` da tabela `users` e
+que se encontram armazenadas em hashes md5, utilize o comando
+
+    update users set pass = md5('SENHA');
+
+onde `SENHA` é uma senha longa e complicada.
+
+## Busca por vírus
+
+    freshclam --datadir=$datadir
+    clamscan --database=$datadir -r *
+
diff --git a/docs/backup.md b/docs/backup.md
new file mode 100644
index 0000000..657262c
--- /dev/null
+++ b/docs/backup.md
@@ -0,0 +1,7 @@
+# Backup
+
+* [Conceitos](concepts).
+* [Convenções](conventions).
+* [Métodos](methods).
+* [Restauração](restore).
+* [Migração de sites](migration).
diff --git a/docs/backup/concepts.md b/docs/backup/concepts.md
new file mode 100644
index 0000000..828ffce
--- /dev/null
+++ b/docs/backup/concepts.md
@@ -0,0 +1,78 @@
+# Da natureza dos backups 
+
+Um backup pode ser entendido como qualquer cópia feita para assegurar a
+existência de uma informação ou configuração em virtude da falta de garantia de
+que seu "suporte" físico consiga mantê-la.
+
+Podemos fazer uma analogia bem limitada com uma floresta com espécies
+endêmicas: se ocorrer uma queimada, as espécies se perdem a não ser que exista
+um banco de sementes intacto que permita o plantio das espécies ameaçadas.
+
+Esse exemplo da floresta é limitado porque no caso de um backup de dados
+digitais a informação se preserva ao transportá-la para outro suporte físico
+(isto é, configurar o conjunto de estados possíveis do "suporte" físico, por
+exemplo disco rígido, DVD, pendrive, de modo a reproduzir uma dada configuração
+presente anteriormente num outro suporte físico: o backup é a reprodução de um
+conjunto de estados de um sistema), o que não ocorre num reflorestamento.
+
+Guardar TODA informação existente em uma floresta, numa vizinhança ou mesmo na
+memória de um povo é uma tarefa inatingível, o que faz qualquer floresta,
+qualquer vizinhança ou povo insubstituíveis. Vejamos a cultura: ela se reproduz
+e contamina, quase sempre com mutações...
+
+Nesse sentido, backups de dados digitais são tarefas bem mais simples e
+possíveis, porque os temos e os conseguimos copiá-los com exatidão. Não há uma
+receita única para fazer um backup digital: a simples cópia de um arquivo de um
+suporte a outro já pode ser considerado como um backup.  Parâmetros dos backups 
+
+Existem diversos parâmetros importantes quando se trata de um backup digital:
+
+1. Periodicidade.
+2. Incrementos.
+3. Largura de banda.
+4. Segurança e integridade dos dados. 
+
+O primeiro deles é a própria modifição realizada pelo uso dos dados. Um sítio
+em HTML, Wiki ou Drupal nem sempre -- imagino que no caso dos sítios aqui da
+vizinhana quase nunca -- se mantém estáticos, sem modificações. Por isso, um
+backup de um sítio há um mês não conterá as alterações de um sítio realizadas
+nas duas últimas semanas. O primeiro parâmetro então a periodicidade na qual os
+backups são realizados.
+
+O segundo parâmetro mais ou menos conseqüência do primeiro: se copiarmos um
+sítio de um disco para outro a cada semana, podemos atualizar o backup com as
+alterações realizadas num sítio mas ao mesmo tempo, caso não tenhamos cuidado,
+podemos também estar apagando o estado que o sítio tinha anteriormente, antes
+dessas últimas modificações. Em outras palavras, o segundo parâmetro de um
+backup, a quantidade de "incrementos" que teremos: podemos copiar um sítio para
+um DVD e, daqui a duas semanas, copiar novamente mas para um outro DVD. Se por
+um acaso precisarmos de uma informação que continha há duas semanas no sítio,
+basta que a resgatemos do primeiro DVD. Agora, manter esses "incrementos", isto
+é, um DVD para cada backup, tem um custo físico e nesse caso ecológico muito
+grande. É preciso então escolher um número de "incrementos" que permita que
+tenhamos uma boa amostragem das modificações realizadas num sítio sem que
+gastemos muito tempo, espaço em disco ou mídia física com tal atividade.
+
+Não entraremos em detalhes, mas um backup que queira dar conta de modificações
+realizadas em intervalos de duas semanas deve ser realizado pelo menos a cada
+semana (teorema da amostragem de
+[Nyquist-Shannon](http://en.wikipedia.org/wiki/Nyquist-Shannon)).
+
+O terceiro parâmetro é a largura de banda. Copiar um sítio de um lugar para
+outro demanda um tempo de transferência. No caso de sítios muito grandes, a
+cópia pode demorar tempo demais e o backup se torna mais uma dificuldade do que
+um benefício. Por isso, a largura de banda pode obrigar que façamos alguns
+truques: a compressão dos dados (arquivo .zip, tar.gz, tar.bz2, etc) e a cóipia
+apenas dos arquivos que foram modificados. Por exemplo, num sítio que tem
+vários vídeos nem todos eles precisam ser copiados a cada backup, mas sim os
+novos ou aqueles que foram modificados.
+
+O quarto parâmetro é a segurança e a integridade dos dados: se você possui
+informações sensíveis (senhas, contatos e tudo o mais que for delicado para se
+tornar público ou cair em mãos erradas), tome cuidado para onde vai copiar
+essas informações e onde as deixar armazenadas. Da mesma forma, a checagem da
+integridade dos arquivos verifica se estes não sofreram alterações durante o
+procedimento de backup.
+
+Em resumo, esses são os quatro parâmetros básicos para um backup:
+periodicidade, incremento, largura de banda e segurança/integridade. 
diff --git a/docs/backup/conventions.md b/docs/backup/conventions.md
new file mode 100644
index 0000000..cb5c698
--- /dev/null
+++ b/docs/backup/conventions.md
@@ -0,0 +1,50 @@
+# Convenções
+
+Esta página contém esboço para as convenções de intercâmbio de backups entre
+servidores. Qualquer que seja o método de backup, ele deve satisfazer as
+seguintes condições:
+
+1. Deve ser incremental para que vários estados diários sejam possíveis de se
+   obter.
+2. Devem ser gerenciados pelo backupninja.
+3. Cada projeto cuida dos seus próprios backups, mesmo que estes estejam sendo
+   enviados para o servidor de outro projeto.
+
+## Armazenamento
+
+1. Backups hospedados em `/var/backups`, mesmo que seja symlink para outro
+   local.
+2. Arquivos de log de backup em `/var/log/{backup,backupninja.log}`, rodando
+   via logrotate.
+3. Backups remotos de servidores e sites em subpastas do tipo
+   `/var/backups/remote/nome-da-camada.projeto.org/handler`.
+4. Backups locais criptografados em `/var/backups/duplicity` e sem backup da
+   pasta `/var/backups/remote`.
+5. Máquinas enviando backups para outros locais enviam apenas o backup local
+   criptografado.
+
+## O que incluir nos backups locais
+
+Talvez a convenção mais forte para a inclusão de arquivos seja aquela na qual a
+inclusão de novos arquivos e pastas nos backups seja automática. Assim, a
+convenção adotada é a realização de backups das pastas
+
+* `/etc`
+* `/var`
+* `/home`
+
+Para que a convenção funcione, é indispensável que conteúdos (dados) hospedados
+sejam armazenados apenas nestas pastas. Como a `/etc` é uma pasta reservada ao
+armazenamento de configurações, restam apenas `/var` e `/home` para o
+armazenamento de dados. Assim, a utilização de pastas do tipo `/var/svn`,
+`/var/www`, etc garantem a inclusão automática de todo o conteúdo hospedado nos
+backups.
+
+## Não incluir em backups locais
+
+As seguintes pastas não devem ser incluídas em backups:
+
+* `/var/backups/duplicity`
+* `/var/backups/remote`
+* `/var/vservers`
+* `/vservers`
diff --git a/docs/backup/methods.md b/docs/backup/methods.md
new file mode 100644
index 0000000..456e372
--- /dev/null
+++ b/docs/backup/methods.md
@@ -0,0 +1,95 @@
+# Métodos para backup remoto
+
+Esta página contém um estudo dos métodos de produção, transferência e
+armazenamento de backups, divididos nas partes:
+
+* Métodos de tranferência
+* Métodos de armazenamento 
+
+A discussão aqui não tem caráter prático mas meramente teórico, sem menção às
+implementações dos métodos. Para isso, veja a página
+[Convencoes](../conventions).
+
+## Métodos de transferência
+
+### Método 1: rsync + hardlinks 
+
+Vantagens:
+
+* Economiza espaço
+* Simples de configurar 
+
+Desvantagens:
+
+* Precisa rodar como root nas duas máquinas/vservers para preservar permissões
+* Workarround: criar um `FILELIST.TXT` para cada vserver indicando as
+  permissões e os proprietários dos arquivos, juntamente com um script que
+  corrija todas essas permissões no caso de um restauro de backup.
+
+### Método 2: tar + ssh
+
+Esse método consiste em criar um `.tar.bz2` num pipe direto para o servidor
+remoto, sem escrita local em disco, isto é,
+
+    nice -n 19 tar c /mnt/backup/servidor/vservers/vservers.0/ | bzip2 | \
+      ssh servidor-remoto "cat - > servidor-vservers-0.tar.bz2"
+
+Vantagens:
+
+* o arquivo transferido preserva todas as permissões do seu conteúdo
+* no servidor remoto o arquivo fica compactado
+* rodar com um nice alto garante que esse comando não atrapalhará o
+  funcionamento normal do sistema.
+
+Para economizar espaço na máquina remota, podemos operar com backups
+incrementais:
+
+    nice -n 19 tar cv /mnt/backup/servidor/vservers/vservers.0/ \
+      --listed-incremental=/var/log/backup/vservers.snar \ | bzip2 | ssh \
+      servidor-remoto "cat - > servidor-vservers-`date +%w`.tar.bz2" >> \
+      /var/log/backup/servidor-remoto.log
+
+Nesse caso, uma vez por semana as seguintes operações devem ser feitas:
+
+* Mover todos os arquivos para uma pasta da "semana passada".
+* Iniciar um novo full-dump.
+
+Desvantagem: full-dump semanal.
+
+### Método 3: GNU backup
+
+O script backup que acompanha o GNU tar pode ser usado para fazer dumps
+incrementais locais que depois são enviados aos servidores remotos.
+
+Desvantagem: arquivos não podem ser modificados durante a confecção do backup.
+
+### Método 4: duplicity
+
+* <http://www.nongnu.org/duplicity>
+* backups criptografados
+
+### Método 5: rdiff-backup
+
+* <http://www.nongnu.org/rdiff-backup>
+
+## Métodos de armazenamento
+
+### Método 1: vserver dedicado a backups
+
+Cada servidor possui um único vserver dedicado a puxar os backups dos outros
+servidores. Esse vserver não terá acesso externo e por isso é a abordagem mais
+segura de armazenamento.
+
+Veja uma discussão sobre isso em
+<https://docs.indymedia.org/view/Sysadmin/PullBackupsForParanoiacs>.
+
+### Método 2: vservers dedicados a cada servidor
+
+Cada servidor possui seu próprio vserver em cada máquina remota onde ele fizer
+backup. Nesse vserver os backups remotos poderão ser feitos como root sem
+acarretar perda de segurança para a máquina remota, o que faz essa ser a
+abordagem mais flexível para puxar ou receber backups remotos.  Backups
+criptografados.
+
+Veja uma discussão sobre isso em
+<https://wiki.boum.org/TechStdOut/EncryptedBackupsForParanoiacs>.
diff --git a/backup/migration.md b/docs/backup/migration.md
index 48bf525..49026eb 100644
--- a/backup/migration.md
+++ b/docs/backup/migration.md
@@ -1,8 +1,6 @@
-Migração de Sites
-=================
+# Migração de Sites
 
-Sites
------
+## Sites
 
 Parâmetros iniciais:
 
@@ -18,20 +16,17 @@ Montando a partir das definições do puppet:
 
     hydra sarava list-sites $ORIGIN
 
-DNS
----
+## DNS
 
 Proceda com a mudança de DNS para os sites, atualizando o repositório dns.git.
 
-Backup
-------
+## Backup
 
 Na origem:
 
     hydractl backup-sites $SITES
 
-Cópia
------
+## Cópia
 
 Na origem:
 
@@ -39,38 +34,38 @@ Na origem:
 
 A senha do usuário `backups` está no keyringer.
 
-Para agilizar, copie **temporariamente** a chave pública de de `root@$ORIGIN` para `backups@DEST:~/.ssh/authorized_keys`.
-Isso evitará a digitação excessiva da senha do usuário `backups`.
+Para agilizar, copie **temporariamente** a chave pública de de `root@$ORIGIN`
+para `backups@DEST:~/.ssh/authorized_keys`.  Isso evitará a digitação excessiva
+da senha do usuário `backups`.
 
-Git
----
+## Git
 
-Caso os repositórios `git` também estejam sendo migrados, crie uma senha temporária para
-o `gitolite` na máquina de destino e proceda com a cópia do material:
+Caso os repositórios `git` também estejam sendo migrados, crie uma senha
+temporária para o `gitolite` na máquina de destino e proceda com a cópia do
+material:
 
     su gitolite -c "rsync -avz --delete -e 'ssh -p porta-ssh' /var/git/ fqdn-destino:/var/git/"
 
-Você também precisará alterar a chave de acesso de `root@ORIGIN` para `root@DEST` na configuração
-do gitolite.
+Você também precisará alterar a chave de acesso de `root@ORIGIN` para
+`root@DEST` na configuração do gitolite.
 
-Habilitando
------------
+## Habilitando
 
-Habilite os sites pelo puppet, mudando o nome do servidor no campo `tag` de cada definição.
+Habilite os sites pelo puppet, mudando o nome do servidor no campo `tag` de
+cada definição.
 
-Verifique se existem usuários e grupos em `users::virtual` associados a esses sites, fazendo
-a alteração conforme necessário.
+Verifique se existem usuários e grupos em `users::virtual` associados a esses
+sites, fazendo a alteração conforme necessário.
 
-Aplique o catálogo no servidor de destino. Eventualmente, desabilite o puppet no servidor de
-origem com o comando
+Aplique o catálogo no servidor de destino. Eventualmente, desabilite o puppet
+no servidor de origem com o comando
 
     hydractl puppet-disable
 
 Isso evitará que os sites sejam apagados antes que tenhamos certeza que foram migrados com
 sucesso.
 
-Restore
--------
+## Restore
 
 No destino:
 
diff --git a/backup/restore.md b/docs/backup/restore.md
index 8ec0c79..3b5a2b8 100644
--- a/backup/restore.md
+++ b/docs/backup/restore.md
@@ -1,30 +1,31 @@
-[[!toc  levels=4]]
-
-Restauração de backups
-======================
+# Restauração de backups
 
 O procedimento de restore pode ser feito de várias maneiras:
 
-  1. A partir dos backups remotos de um nodo.
-  2. A partir do backup local de um nodo.
-  3. A partir do backup gerado de um site em funcionamento.
+1. A partir dos backups remotos de um nodo.
+2. A partir do backup local de um nodo.
+3. A partir do backup gerado de um site em funcionamento.
 
 O ciclo completo pode ser dividido em três partes:
 
-  1. Geração do backup.
-  2. Transferência do backup.
-  3. Restauração do backup.
+1. Geração do backup.
+2. Transferência do backup.
+3. Restauração do backup.
 
-A geração e transferência de backups já estão bem sólidas por conta do [puppet-backup](https://git.$dominio/?p=puppet-backup.git;a=summary puppet-backup). Tratemos da parte manual dos procedimentos usando a [Hydra Suite](http://git.$dominio/?p=hydra.git;a=summary).
+A geração e transferência de backups já estão bem sólidas por conta do
+[puppet-backup](https://git.$dominio/?p=puppet-backup.git;a=summary
+puppet-backup). Tratemos da parte manual dos procedimentos usando a [Hydra
+Suite](http://git.$dominio/?p=hydra.git;a=summary).
 
-Restauro a quente
-=================
+## Restauro a quente
 
 O restauro a quente ocorre quando:
 
-  * O serviço de origem se encontra online OU
-  * Queremos restaurar uma versão anterior do serviço no mesmo servidor em que ele se encontra OU
-  * Quando temos condições de realizar um backup logo antes do serviço sair do ar e migrá-lo para um nodo de destino.
+* O serviço de origem se encontra online OU.
+* Queremos restaurar uma versão anterior do serviço no mesmo servidor em que
+  ele se encontra OU.
+* Quando temos condições de realizar um backup logo antes do serviço sair do ar
+  e migrá-lo para um nodo de destino.
 
 Para fazer o backup do site em `/var/site/backups/site/$sitio`:
 
@@ -35,7 +36,8 @@ Para fazer o backup de vários sites:
     hydractl backup-sites $sitio $sitio1 $sitio2
     hydractl backup-sites # faz backup de todos os sites
 
-O `backup-sites` faz inclusive o backup do `svn.$dominio` e do `git.$dominio`, o que nestes casos significa a cópia dos repositórios:
+O `backup-sites` faz inclusive o backup do `svn.$dominio` e do `git.$dominio`,
+o que nestes casos significa a cópia dos repositórios:
 
     hydract backup-site svn
     hydract backup-site git
@@ -52,25 +54,29 @@ Para restaurar o backup copiado a partir do `$servidor`:
 
 Tal restauro de backups necessita que o site já esteja definido no nodo através das configurações do puppet.
 
-Restauro a frio
-===============
+## Restauro a frio
 
-O restauro a frio ocorre quando o serviço está offline, em geral quando há algum problema no nodo onde ele estava rodando.
+O restauro a frio ocorre quando o serviço está offline, em geral quando há
+algum problema no nodo onde ele estava rodando.
 
-Primeiramente, pode ser que queiramos copiar o backup armazenado num servidor remoto para o local onde fazermos o restauro do serviço. O ideal é que isso já seja feito automaticamente pelo sistema de backups, mas no caso de servidores novos isso ainda não teve a oportunidade de acontecer.
+Primeiramente, pode ser que queiramos copiar o backup armazenado num servidor
+remoto para o local onde fazermos o restauro do serviço. O ideal é que isso já
+seja feito automaticamente pelo sistema de backups, mas no caso de servidores
+novos isso ainda não teve a oportunidade de acontecer.
 
 Para isso, usamos o seguinte comando no nodo onde o backup se encontra:
 
     hydractl backup-copy ORIG DEST # transfere /var/backups/remote/ORIG.$domain para DEST
 
-No nodo de destino, primeiro restauraremos backups cifrados de `/var/backups/remote/ORIG.$domain/{rsync,rdiff}` para `/var/backups/remote/ORIG.$domain/restore`:
+No nodo de destino, primeiro restauraremos backups cifrados de
+`/var/backups/remote/ORIG.$domain/{rsync,rdiff}` para
+`/var/backups/remote/ORIG.$domain/restore`:
 
     hydractl backup-restore ORIG
 
 Em seguida, procedemos com o restauro de aplicações.
 
-Restauro a frio do nodo de email
---------------------------------
+### Restauro a frio do nodo de email
 
     hydractl backup-restore-mail      ORIG
     hydractl backup-restore-database  ORIG postfix
@@ -88,7 +94,6 @@ Restauro a frio do nodo de email
     hydractl backup-restore-database ORIG roundcube
     dpkg-reconfigure roundcube-core
 
-Restauro a frio de um nodo web
-------------------------------
+### Restauro a frio de um nodo web
 
     hydractl backup-restore-svn ORIG
diff --git a/bootless.md b/docs/bootless.md
index df449b2..2cca9b3 100644
--- a/bootless.md
+++ b/docs/bootless.md
@@ -1,6 +1,3 @@
-[[!toc levels=4]]
-
-Bootless
-========
+# Bootless
 
 Vide [Projeto Bootless](https://bootless.sarava.org).
diff --git a/bootstrap.md b/docs/bootstrap.md
index c02bfd2..653f517 100644
--- a/bootstrap.md
+++ b/docs/bootstrap.md
@@ -1,13 +1,10 @@
-[[!toc levels=4]]
-
-Bootstrap de uma configuração completa
-======================================
+# Bootstrap de uma configuração completa
 
 Este documento tem como objetivo descrever o **processo de bootstrap** de uma
-configuração completa de um servidor utilizando o [Padrão Saravá](/). O
+configuração completa de um servidor utilizando o [Padrão Saravá](/). O
 *processo de bootstrap* pode ser compreendido como "o processo de coordenar
-diversos processos interdepententes de forma que seja atingida uma configuração
-sistêmica estável".
+diversos processos interdepententes de forma que seja atingida uma configuração
+sistêmica estável".
 
 Para este processo, utilizaremos as seguintes ferramentas:
 
@@ -17,17 +14,15 @@ Para este processo, utilizaremos as seguintes ferramentas:
 * [puppet-bootstrap](http://git.sarava.org/?p=puppet-bootstrap.git;a=summary).
 * [hydra](http://git.sarava.org/?p=hydra.git;a=summary).
 
-Os seguintes estágios fazem parte de uma instalação padrão completa:
+Os seguintes estágios fazem parte de uma instalação padrão completa:
 
-Instalação do sistema padrão na máquina hospedeira
---------------------------------------------------
+## Instalação do sistema padrão na máquina hospedeira
 
-Documentação [aqui](/install).
+Documentação [aqui](install.md).
 
-Configuração da máquina hospedeira
-----------------------------------
+## Configuração da máquina hospedeira
 
-Configure algumas variáveis de ambiente:
+Configure algumas variáveis de ambiente:
 
     export domain="projeto.org"
     export hostname=`hostname | sed -e s/\\\\..*$//`
@@ -41,18 +36,18 @@ Configure o arquivo `/etc/hosts` (a ordem dos hostnames influencia nos resultado
     127.0.0.1 localhost
     EOF
 
-Instale o git e o puppet e clone o repositório `puppet-bootstrap`:
+Instale o git e o puppet e clone o repositório `puppet-bootstrap`:
 
     apt-get -y install git-core puppet wipe
     git clone git://git.sarava.org/puppet-bootstrap ${puppet_bootstrap_dir}
 
 Altere o arquivo `${puppet_bootstrap_dir}/manifests/config.pp` de acordo com suas necessidades.
 
-Prepare o servidor para a utilização do puppet.
+Prepare o servidor para a utilização do puppet.
 
     puppet apply -d -v ${puppet_bootstrap_dir}/manifests/stage0.pp
 
-Crie um vserver para abrigar o nó administrativo:
+Crie um vserver para abrigar o nó administrativo:
 
     puppet apply -d -v ${puppet_bootstrap_dir}/manifests/host-stage1.pp
 
@@ -60,12 +55,11 @@ Anote a fingerprint da chave ssh do vserver:
 
     vserver ${hostname}-master exec ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
 
-Configuração do nó administrativo
----------------------------------
+## Configuração do nó administrativo
 
-A partir deste momento, vamos trabalhar apenas no nó administrativo recém criado.
+A partir deste momento, vamos trabalhar apenas no nó administrativo recém criado.
 
-Copie o `puppet-bootstrap` e a configuração padrão para o vserver e limpe os rastros:
+Copie o `puppet-bootstrap` e a configuração padrão para o vserver e limpe os rastros:
 
     echo LANG=C > /var/vservers/${hostname}-master/etc/default/locale
     cp -r ${puppet_bootstrap_dir} \
@@ -81,51 +75,55 @@ Acesse o vserver e instale algumas ferramentas:
     apt-get -y upgrade
     apt-get -y install git puppet puppetmaster wipe
 
-Configure o hostname e domínio do nó administrativo:
+Configure o hostname e domínio do nó administrativo:
 
     cat > /etc/hosts <<EOF
     127.0.0.1 ${hostname}-master.${domain} ${hostname}
     127.0.0.1 localhost
     EOF
 
-Prepare o vserver para a utilização do puppet.
+Prepare o vserver para a utilização do puppet.
 
     puppet apply -d -v ${puppet_bootstrap_dir}/manifests/stage0.pp
     puppet apply -d -v ${puppet_bootstrap_dir}/manifests/admin-stage1.pp
 
-Criação de repositórios padrão
-------------------------------
+## Criação de repositórios padrão
 
-Dê acesso ao repositório administrativo do gitosis a um usuário:
+Dê acesso ao repositório administrativo do gitosis a um usuário:
 
     sudo -H -u gitosis gitosis-init < FILENAME.pub
 
-Clone o repositório administrativo do gitosis remotamente:
+Clone o repositório administrativo do gitosis remotamente:
 
     git clone ssh://gitosis@servidor.${domain}:2202/gitosis-admin
 
-Altere o arquivo `gitosis-admin/gitosis.conf` do repositório clonado e crie um repositório para a configuração do puppet e um repositório para suas chaves criptográficas:
+Altere o arquivo `gitosis-admin/gitosis.conf` do repositório clonado e crie um
+repositório para a configuração do puppet e um repositório para suas chaves
+criptográficas:
 
     [gitosis]
     daemon      = no
     gitweb      = no
     public_http = no
-    
+
     [group admin]
     writable = gitosis-admin puppet keyring
     members = usuario@maquina
 
-Empurre as mudanças para o servidor:
+Empurre as mudanças para o servidor:
 
-    git commit -a -m "Adicionando repositórios para puppet e keyring"
+    git commit -a -m "Adicionando repositórios para puppet e keyring"
     git push origin master
 
-Para adicionar um novo usuário ao gitosis, basta adicionar as chaves públicas ssh ao diretório `gitosis-admin/keydir/` com um nome de arquivo do tipo `usuario@maquina.pub`.
+Para adicionar um novo usuário ao gitosis, basta adicionar as chaves públicas
+ssh ao diretório `gitosis-admin/keydir/` com um nome de arquivo do tipo
+`usuario@maquina.pub`.
 
-Configuração do repositório puppet
-----------------------------------
+## Configuração do repositório puppet
 
-Altere as configurações padrão do puppet em `/usr/local/puppet/default-conf` de acordo com suas necessidades e incialize os repositórios em `/etc/puppet` e `/var/git/repositories/puppet`):
+Altere as configurações padrão do puppet em `/usr/local/puppet/default-conf` de
+acordo com suas necessidades e incialize os repositórios em `/etc/puppet` e
+`/var/git/repositories/puppet`):
 
     /etc/init.d/puppetmaster stop
     rm -rf /etc/puppet && mkdir /etc/puppet
@@ -139,14 +137,15 @@ Altere as configurações padrão do puppet em `/usr/local/puppet/default-conf` de
     git clone --bare /etc/puppet/ /var/git/repositories/puppet.git
     chown -R gitosis:gitosis /var/git/repositories/puppet.git
 
-Agora já podemos clonar o repositório de configurações do puppet remotamente:
+Agora já podemos clonar o repositório de configurações do puppet remotamente:
 
     git clone ssh://gitosis@${hotname}.${domain}:2202/puppet.git
 
-Configuração da hydra
----------------------
+## Configuração da hydra
 
-Esta parte da instalação gera chaves criptográficas e portanto deve ocorrer em uma máquina com um nível de segurança significativo (criptografia de disco, bootless, etc).
+Esta parte da instalação gera chaves criptográficas e portanto deve ocorrer em
+uma máquina com um nível de segurança significativo (criptografia de disco,
+bootless, etc).
 
 Instale `hydra` e `keyringer`:
 
@@ -159,7 +158,9 @@ Instale `hydra` e `keyringer`:
     sudo git clone git://git.sarava.org/keyringer /usr/local/keyringer
     sudo ln -sf /usr/local/keyringer/keyringer /usr/local/bin/keyringer
 
-Tenha certeza que possui em seu chaveiro gpg as chaves dos usuários que irão acessar o repositório de chaves. Crie um keyring para o projeto clonando o repositório configurado:
+Tenha certeza que possui em seu chaveiro gpg as chaves dos usuários que irão
+acessar o repositório de chaves. Crie um keyring para o projeto clonando o
+repositório configurado:
 
     keyringer projeto init ~/projeto/keyring
     cd ~/projeto/keyring
@@ -169,53 +170,48 @@ Tenha certeza que possui em seu chaveiro gpg as chaves dos usuários que irão ace
     git commit -m "initial commit"
     git push origin master
 
-Clone o repositório de configuração do puppet e registre uma nova hydra:
+Clone o repositório de configuração do puppet e registre uma nova hydra:
 
     puppet_dir=~/projeto/puppet
     git clone git://gitosis@servidor.${domain}:2202/puppet $puppet_dir
     hydra projeto register $puppet_dir
 
-Gere novas chaves para os nós configurados e as envie para os nós:
+Gere novas chaves para os nós configurados e as envie para os nós:
 
     hydra projeto newkeys
     hydra projeto import servidor.pub
 
 
-Partida do puppetmaster
------------------------
+## Partida do puppetmaster
 
     /etc/init.d/puppetmaster start
 
-Configuração de backups:
-------------------------
+## Configuração de backups
 
 1. Backup local criptografado:
-    1. Criação de chaves GPG.
-    2. Configuração do backup local.
+    1. Criação de chaves GPG.
+    2. Configuração do backup local.
 2. Backup remoto:
-    1. Criação de chaves SSH para armazenamento remoto de backup.
-    2. Configuração do backup remoto.
+    1. Criação de chaves SSH para armazenamento remoto de backup.
+    2. Configuração do backup remoto.
 
-Criação de outros vservers/nós
-------------------------------
+## Criação de outros vservers/nós
 
-* Nó de armazenamento ("storage") para agrupamento de backups.
+* Nó de armazenamento ("storage") para agrupamento de backups.
 * Proxy.
 * Web.
 * Test.
 
-Pedaços de código úteis para o bootstrap
-========================================
+## Pedaços de código úteis para o bootstrap
 
-Configuração de submódulos padrão
----------------------------------
+### Configuração de submódulos padrão
 
     apt-get -y install puppetmaster puppet git-core openssh-server
     cd /etc/puppet
     mkdir modules
     git init
     git add .
-    
+
     repos="`lynx -dump http://git.sarava.org/?a=project_index | awk '{ print $1 }' | grep ^puppet-`"
     for repo in $repos; do
       module="`basename $repo .git | sed -e s/^puppet-//`"
@@ -224,10 +220,9 @@ Configuração de submódulos padrão
       fi
     done
 
-No caso de bootstrap para um novo projeto, substitua as referências de `git.sarava.org` para `git.projeto.org`.
+No caso de bootstrap para um novo projeto, substitua as referências de `git.sarava.org` para `git.projeto.org`.
 
-Configurando referências remotas em massa
------------------------------------------
+### Configurando referências remotas em massa
 
     # Configuracao
     origin="sarava.org"
@@ -250,8 +245,7 @@ Configurando referências remotas em massa
       fi
     done
 
-Mudando referências em submódulos
----------------------------------
+### Mudando referências em submódulos
 
     # Configuracao
     origin="sarava.org"
@@ -269,8 +263,7 @@ Mudando referências em submódulos
       cd ..
     done
 
-Exemplo de criação em massa de módulos
---------------------------------------
+### Exemplo de criação em massa de módulos
 
     # Configuracao
     origin="sarava.org"
diff --git a/boxes.md b/docs/boxes.md
index c8c4309..dcd7550 100644
--- a/boxes.md
+++ b/docs/boxes.md
@@ -1,16 +1,11 @@
-[[!toc levels=4]]
+# Boxes
 
-Boxes
-=====
-
-Necessidade
------------
+## Necessidade
 
 * Ambiente de desenvolvimento ágil.
 * Que permita executar de forma isolada aplicações sem auditoria ou checagem de integridade.
 
-Criando uma base box
---------------------
+## Criando uma base box
 
 O procedimento básico já é detalhado aqui:
 
@@ -45,8 +40,7 @@ a máquina para ter ferramentas e configurações comuns para o seu dia dia.
 
 Por exemplo, considere a [instalação](/install) da Hydra Suite na máquina virtual.
 
-Encolhendo uma máquina virtual
-------------------------------
+## Encolhendo uma máquina virtual
 
 Procedimento genérico, dentro da máquina virtual:
 
@@ -61,8 +55,7 @@ No host (`$box` é o nome da máquina):
 
     VBoxManage modifyhd --compact /var/cache/virtualbox/$box/$box.vdi
 
-Referências
------------
+# Referências
 
 * [How to compact VirtualBox's VDI file size?](https://superuser.com/questions/529149/how-to-compact-virtualboxs-vdi-file-size).
 * [Shrinking a Dynamic VirtualBox Disk Image](http://www.thelinuxdaily.com/2010/02/shrinking-a-dynamic-virtualbox-disk-image/).
diff --git a/certs.md b/docs/certs.md
index 38fa7e6..9fc1a04 100644
--- a/certs.md
+++ b/docs/certs.md
@@ -1,15 +1,10 @@
-[[!toc levels=4]]
+# Geração e renovação de certificados
 
-Geração e renovação de certificados
-===================================
-
-Começando
----------
+## Começando
 
 Proceda com a [configuração do ambiente de trabalho administrativo](/install).
 
-Gerando novas chaves
---------------------
+## Gerando novas chaves
 
 Proceda usando o [keyringer](https://keyringer.pw):
 
@@ -25,19 +20,17 @@ Chaves também podem ser geradas em massa. No caso de certificados simples (não
       keyringer $HYDRA genpair ssl ssl/$domain $domain
     done
 
-Registrando mudancas parciais
------------------------------
+## Registrando mudancas parciais
 
     keyringer $HYDRA git commit
     keyringer $HYDRA git push
 
-Comprando um certificado
-------------------------
+## Comprando um certificado
 
-Em seguida, compre um certificado no registrar, envie a requisição de certificado (arquivo `CSR`) e proceda com a validação.
+Em seguida, compre um certificado no registrar, envie a requisição de
+certificado (arquivo `CSR`) e proceda com a validação.
 
-Após a renovação
-----------------
+## Após a renovação
 
     cat /path/to/registrar.crt >> /path/to/$DOMAIN.crt
     cat /path/to/$DOMAIN.crt    | keyringer $HYDRA encrypt ssl/$DOMAIN.crt
@@ -76,8 +69,7 @@ Copie as notificações para ser incluída em `https://$DOMAIN/certs`:
 
 Por fim, atualize os `postfix::tlspolicy_snippet` do `$DOMAIN`, caso aplicável.
 
-Instalando
-----------
+## Instalando
 
 Para instalar o certificado num nodo:
 
diff --git a/cryptocalypse.md b/docs/cryptocalypse.md
index 0ccb1b2..2e97969 100644
--- a/cryptocalypse.md
+++ b/docs/cryptocalypse.md
@@ -1,22 +1,18 @@
-Cryptocalypse!
-==============
+# Cryptocalypse!
 
 Procedimento emergencial de rotação de chaves. Ou, como sobreviver a brechas do tipo [Heartbleed](http://heartbleed.com/)!
 
-Começando
----------
+## Começando
 
 Proceda com a [configuração do ambiente de trabalho administrativo](/install).
 
-Atualizando
------------
+## Atualizando
 
 Se for possível e desejável, faça upgrade geral
 
     hydra $HYDRA mass-upgrade
 
-Gerando novas chaves SSH
-------------------------
+## Gerando novas chaves SSH
 
 Na máquina do/a administrador:
 
@@ -29,18 +25,15 @@ Para cada nodo usado no git público:
     ( cd $FOLDER/puppet     && git add . && git commit -m "Gerando chaves ssh" && git push )
     ( cd $FOLDER/git/public && git add . && git commit -m "Gerando chaves ssh" && git push )
 
-Chaves do Puppet
-----------------
+## Chaves do Puppet
 
 [Reset da infra de CA do puppet](certs/puppet).
 
-Certificados SSL
-----------------
+## Certificados SSL
 
 [Gere novos certificados SSL](certs).
 
-Chaves SSH dos ikiwikis
------------------------
+## Chaves SSH dos ikiwikis
 
     WIKIS="lista de ikiwikis"
     NODE="aziz"
@@ -53,8 +46,7 @@ Chaves SSH dos ikiwikis
     ( cd $FOLDER/puppet     && git add . && git commit -m "Gerando chaves para ikiwiki" && git push )
     ( cd $FOLDER/git/public && git add . && git commit -m "Gerando chaves para ikiwiki" && git push )
 
-Tor
----
+## Tor
 
 A parte fácil:
 
@@ -87,7 +79,6 @@ Em seguida, colete os novos hostnames e atualize os `ServerAlias` dos sites e ou
 
     hydra $HYDRA mass-web hydractl hidden-services
 
-Senhas de usuário
------------------
+## Senhas de usuário
 
 O procedimento deve variar de aplicação para aplicação. Por exemplo, para o drupal há o [Force password change](https://drupal.org/project/force_password_change).
diff --git a/domains.md b/docs/domains.md
index d48b24a..aeaea1d 100644
--- a/domains.md
+++ b/docs/domains.md
@@ -1,15 +1,10 @@
-[[!toc levels=4]]
+# Gerenciamento de domínios
 
-Gerenciamento de domínios
-=========================
-
-Começando
----------
+## Começando
 
 Proceda com a [configuração do ambiente de trabalho administrativo](/install).
 
-Checando expiração em massa
----------------------------
+## Checando expiração em massa
 
 Necessita o script [domain-check](https://git.sarava.org/?p=puppet-domain_check.git):
 
diff --git a/firewall.md b/docs/firewall.md
index a76a114..37621ea 100644
--- a/firewall.md
+++ b/docs/firewall.md
@@ -1,13 +1,12 @@
-[[!toc levels=4]]
+# Configuração do shorewall 
 
-Configuração do shorewall 
-=========================
-
-De início, instale o shorewall:
+De início, instale o shorewall:
 
     apt-get install shorewall
 
-É necessário que o iptables esteja configurado para encaminhar os pacotes de uma porta externa para os vservers. As seguinte diretiva precisa ser alterada na configuração original no arquivo `/etc/shorewall/shorewall.conf`:
+É necessário que o iptables esteja configurado para encaminhar os pacotes de
+uma porta externa para os vservers. As seguinte diretiva precisa ser alterada
+na configuração original no arquivo `/etc/shorewall/shorewall.conf`:
 
     IP_FORWARDING=Yes
 
@@ -34,7 +33,7 @@ O arquivo `/etc/shorewall/hosts` associa zonas a subredes:
     net     eth0:0.0.0.0/0
     #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE
 
-O arquivo `/etc/shorewall/policy` define as regras para tráfego de pacotes:
+O arquivo `/etc/shorewall/policy` define as regras para tráfego de pacotes:
 
     ###############################################################################
     #SOURCE         DEST            POLICY          LOG             LIMIT:BURST
@@ -47,7 +46,7 @@ O arquivo `/etc/shorewall/policy` define as regras para tráfego de pacotes:
     all             all             REJECT          info
     #LAST LINE -- DO NOT REMOVE
 
-E o arquivo `/etc/shorewall/rules` define exceções às regras gerais:
+E o arquivo `/etc/shorewall/rules` define exceções às regras gerais:
 
     ################################################################
     #ACTION         SOURCE          DEST            PROTO   DEST
@@ -57,7 +56,7 @@ E o arquivo `/etc/shorewall/rules` define exceções às regras gerais:
     HTTPS/ACCEPT    net             $FW
     #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
 
-Adicionamos máscaras NAT aos pacotes da rede interna através do `/etc/shorewall/masq`:
+Adicionamos máscaras NAT aos pacotes da rede interna através do `/etc/shorewall/masq`:
 
     ###############################################################################
     #INTERFACE              SOURCE          ADDRESS         PROTO   PORT(S) IPSEC   MARK
@@ -72,7 +71,10 @@ Finalmente podemos ligar o shorewall:
 
     /etc/init.d/shorewall start
 
-Shorewall e Puppet 
-==================
+## Shorewall e Puppet 
 
-Uma vez que um nodo [puppetmaster](../puppet) estiver rodando, o módulo [puppet-shorewall](http://git.sarava.org/?p=puppet-shorewall.git;a=summary) poderá ser utilizado para gerenciar o firewall. No entanto, se você for substituir o presente procedimento pela sua versão via puppet, certifique-se de apagar os arquivos `/etc/shorewall/{masq,policy,zones,rules,interfaces}`. 
+Uma vez que um nodo [puppetmaster](../puppet) estiver rodando, o módulo
+[puppet-shorewall](http://git.sarava.org/?p=puppet-shorewall.git;a=summary)
+poderá ser utilizado para gerenciar o firewall. No entanto, se você for
+substituir o presente procedimento pela sua versão via puppet, certifique-se de
+apagar os arquivos `/etc/shorewall/{masq,policy,zones,rules,interfaces}`. 
diff --git a/firewire.md b/docs/firewire.md
index 63ac7f4..ad80bc9 100644
--- a/firewire.md
+++ b/docs/firewire.md
@@ -1,9 +1,9 @@
-[[!toc levels=4]]
+# Firewire
 
-Firewire
-========
-
-Para evitar [dumps de memória via firewire](http://links.sarava.org/tags/firewire), [este artigo](http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation) oferece a mitigação ideal via `/etc/modprobe.d/blacklist`:
+Para evitar [dumps de memória via
+firewire](http://links.sarava.org/tags/firewire), [este
+artigo](http://www.hermann-uwe.de/blog/physical-memory-attacks-via-firewire-dma-part-1-overview-and-mitigation)
+oferece a mitigação ideal via `/etc/modprobe.d/blacklist`:
 
     # Physical memory attacks via Firewire/DMA Mitigation
     # Prevent automatic loading of the ohci1394 module.
@@ -13,11 +13,11 @@ Para evitar [dumps de memória via firewire](http://links.sarava.org/tags/firewir
     # Iff we should ever load the ohci1394 module, force the use of the 'phys_dma=0' option.
     options ohci1394 phys_dma=0
 
-Depois dessa configuração, é preciso atualizar a `initrd` de cada sistema, através do comando
+Depois dessa configuração, é preciso atualizar a `initrd` de cada sistema, através do comando
 
     update-initramfs -v -u
 
-Feito isso, o firewire pode ser desabilitado nos sistemas que estão rodando simplesmente com um
+Feito isso, o firewire pode ser desabilitado nos sistemas que estão rodando simplesmente com um
 
     rmmod ohci1394
 
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000..4c18930
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,40 @@
+# Padrão Fluxo
+
+O Padrão Fluxo é uma sistematização de configuração de servidores,
+gerenciadores de conteúdo e aplicações diversas usados pelo Grupo Fluxo. O
+padrão foi desenvolvido para:
+
+* Ter controle dos pacotes utilizados, arquivos de configuração e serviços em
+  uso.
+* Uniformidade de administração.
+* Sistema de gerenciamento de backups comum para que as máquinas de um projeto
+  possam trocar dados.
+* Que um servidor seja configurado apenas uma vez e que suas configurações
+  possam ser aproveitados para outras máquinas.
+* Que sites e serviços sejam armazenados de maneira regular para facilitar
+  atualizações e migrações.
+* Manter projetos e serviços isolados uns dos outros através de servidores
+  virtuais.
+* Tornar a instalação dos servidores facilmente replicável.
+
+### Licença
+
+O Padrão Fluxo é distribuído conforme a [GNU Affero General Public
+License](http://www.gnu.org/licenses/agpl-3.0.html):
+
+    Fluxo Pattern
+    Copyright (C) 2015      Fluxo  Group
+    Copyright (C) 2009-2015 Sarava Group
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU Affero General Public License as
+    published by the Free Software Foundation, either version 3 of the
+    License, or any later version.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU Affero General Public License for more details.
+
+    You should have received a copy of the GNU Affero General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.
diff --git a/docs/install.md b/docs/install.md
new file mode 100644
index 0000000..508649a
--- /dev/null
+++ b/docs/install.md
@@ -0,0 +1,28 @@
+# Instalação da Hydra Suite
+
+Atualmente o Padrão Saravá utiliza a [Hydra
+Suite](http://git.sarava.org/?p=hydra.git;a=summary) para fazer o
+provisionamento. Versões anteriores deste documento não o utilizam, são mais
+descritivas e talvez até mais interessantes ao público interessado nos
+pormenores do procedimento de instalação.
+
+A Hydra Suite pode ser obtida e instalada diretamente do seu repositório:
+
+    git clone --recursive git://git.sarava.org/hydra.git
+
+Verifique a [integridade do código](https://manual.sarava.org/specs/code/):
+
+    cd hydra
+    tag="`git describe --abbrev=0 --tags`"
+    git tag -v $tag && git checkout $tag
+
+Opcionalmente instale a suite no sistema:
+
+    ./hydractl install
+
+## Ambiente de trabalho administrativo
+
+    HYDRA="nome-do-grupo"
+    FOLDER="`hydra $HYDRA folder`"
+    MAIN_DOMAIN="`hydra $HYDRA config domain`"
+    DOMAIN="$MAIN_DOMAIN" # ou outro domínio
diff --git a/docs/keys.md b/docs/keys.md
new file mode 100644
index 0000000..a708afb
--- /dev/null
+++ b/docs/keys.md
@@ -0,0 +1,150 @@
+# Chaves
+
+## Repositório de chaves
+
+### Configuração
+
+A maior parte dos procedimentos a seguir depende do aplicativo
+[keyringer](http://git.fluxo.info/?p=keyringer.git;a=summary), da [Hydra
+Suite](http://git.fluxo.info/?p=hydra.git;a=summary) e de uma configuração do
+tipo
+
+Proceda então com a [configuração do ambiente de trabalho administrativo](/install).
+
+### Inicializando um repositório
+
+    # Inicializando
+    keyringer $HYDRA init $FOLDER/conf/keyring
+
+### Gerando chaves https
+
+Gerar chaves e certificados SSL auto-assinados é simples:
+
+    # Gerando chaves para https
+    keyringer $HYDRA genpair ssl-self ssl/$DOMAIN $DOMAIN
+
+Caso você queira gerar apenas a chave e a requisição de certificação (CSR), use
+
+    keyringer $HYDRA genpair ssl ssl/$DOMAIN $DOMAIN
+
+Para a chaves e requisições CaCert, use
+
+    keyringer $HYDRA genpair ssl-cacert ssl/$DOMAIN $DOMAIN
+
+### Gerando chaves para novos nodos
+
+    # Gerando chaves ssh e gpg para novos nodos
+    # A importacao das chaves gpg nos nodos deve ser feita manualmente
+    hydra $HYDRA newkeys
+
+### Submetendo mudanças
+
+    # Submetendo
+    keyringer $HYDRA git remote add origin giolite@admin.$DOMAIN:keyring.git
+    keyringer $HYDRA git push origin master
+
+### Importação de chaves GPG
+
+Importando chaves nos seus respectivos nodos:
+
+    hydra $HYDRA import-key
+
+## Chaves SSH
+
+Para gerar uma chave SSH pessoal, use um comando do tipo
+
+    ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa     -C "seu@email"
+    ssh-keygen -t ed25519     -f ~/.ssh/id_ed25519 -C "seu@email"
+
+Esse tipo de comando irá gerar uma **chave privada** em `~/.ssh/id_rsa` e uma
+respectiva **chave pública** em `~/.ssh/id_rsa.pub`. Se você já possui uma
+chave em `~/.ssh/id_rsa` e quiser mantê-la, escolha outro nome para a nova
+chave, como por exemplo `~/.ssh/id_rsa_aplicacao`.
+
+## Senhas
+
+Exemplo de geração de senhas usando o [pwgen](http://packages.debian.org/lenny/pwgen):
+
+    pwgen -s -y 25
+
+Atenção: muitos programas e configurações podem não funcionar por conta do uso
+de caracteres especiais nas senhas. Assim, recomenda-se evitar alguns
+caracteres especiais -- por exemplo delimitadores de campo -- quando for o caso
+e/ou testar a senha após a sua escolha.
+
+## Impressões digitais
+
+### Chaves SSL
+
+Chaves SSL podem ter seu fingerprint determinado através usando o [OpenSSL em
+linha de comando](http://www.madboa.com/geek/openssl), com linhas do tipo
+
+    openssl x509 -noout -in /etc/ssl/certs/cert.crt -fingerprint
+    openssl x509 -noout -in /etc/ssl/certs/cert.crt -fingerprint -md5
+
+### Chaves públicas SSH
+
+O seguinte comando retorna todas as fingerprints dos arquivos de chave pública ssh terminados em `.pub` no diretório `/etc/ssh/`:
+
+    hydractl ssh-finger
+
+Para obter um fingerprint salvo no seu `~/.ssh/known_hosts` pessoal, use
+
+    ssh-keygen -l -F  servidor.exemplo.org        -f ~/.ssh/known_hosts
+    ssh-keygen -l -F [servidor.exemplo.org]:porta -f ~/.ssh/known_hosts
+
+## Monkeysphere
+
+O [monkeysphere](http://web.monkeysphere.info) é um programa que permite a
+verificação de hosts SSH e usuários/as através da Teia de Confiabilidade do
+OpenPGP. Com ele, o gerenciamento de fingerprints fica mais fácil e evita que
+páginas como esta centralizem informações que possam se desatualizar.
+
+Além dos [usos já documentados](http://web.monkeysphere.info/doc/), o
+monkeysphere pode ser utilizado também para autenticação em sistemas que não
+possuem tal suporte:
+
+    monkeysphere gen-subkey -l 4096                      # caso voce ainda nao tenha uma chave
+    mkdir -m 700 ~/.monkeysphere
+    echo "SEU-ID" >> ~/.monkeysphere/authorized_user_ids # exemplo: "Seu Nome <seu-email@example.org>"
+    touch ~/.ssh/id_rsa_monkeysphere.pub
+    chmod 600 ~/.ssh/id_rsa_monkeysphere.pub
+    MONKEYSPHERE_AUTHORIZED_KEYS=$HOME/.ssh/id_rsa_monkeysphere.pub monkeysphere update-authorized_keys
+
+Agora, basta fornecer a chave localizada em `~/.ssh/id_rsa_monkeysphere.pub` para autenticação :)
+
+## Hashes
+
+Hashes são úteis para o armazenamento de senhas de usuário. São usados por
+exemplo no `shadow(5)`. Para gerar um hash compatível com o shadow (por exemplo
+para gestão via
+[puppet-user](http://git.fluxo.info/?p=puppet-user.git;a=summary)), utilize o
+seguinte comando disponível no pacote [whois do
+Debian](https://packages.debian.org/stable/whois):
+
+    mkpasswd -m sha-256
+
+Hashes para `htpasswd` são descritos [aqui](http://sarava.fluxo.info/Ajuda/ProtegendoConteudo).
+
+## Exportação de assinaturas locais
+
+    gpg --armor --export-options export-local-sigs --export KEYID
+
+## Forçando entrada de senhas via console no GnuPG
+
+    DISPLAY="" gpg <opcoes>
+
+## Mudando senhas de chaves
+
+    ssh-keygen -p -f ~/.ssh/id_rsa
+    gpg --edit-key <ID> edit-key passwd
+
+## Chave OpenPGP de Coletivo
+
+Vide [Chave OpenPGP de Coletivo](role).
+
+## Referências
+
+* [Using ssh-agent with ssh](http://mah.everybody.org/docs/ssh).
+* [Using Rsync and SSH ](http://troy.jdmz.net/rsync/index.html).
+* [SSH and ssh-agent](http://www.securityfocus.com/infocus/1812).
diff --git a/keys/role.md b/docs/keys/role.md
index d808715..6c29f32 100644
--- a/keys/role.md
+++ b/docs/keys/role.md
@@ -1,18 +1,14 @@
-Role key
-========
+# Role key
 
-Começando
----------
+## Começando
 
     KEY="fingerprint da chave OpenPGP"
 
-Procedimento para criar as assinaturas
---------------------------------------
+## Procedimento para criar as assinaturas
 
     GPG_AGENT_INFO="" gpg -b --armor --default-key "$KEY" -s openpgp.txt
 
-Renovação
----------
+## Renovação
 
     GPG_AGENT_INFO="" gpg --edit-key "$KEY"
     gpg --armor --export-secret-keys "$KEY" | keyringer $HYDRA encrypt $DOMAIN/contato/gpg/key.asc
diff --git a/nodo.md b/docs/nodo.md
index 5f1e289..77bbd85 100644
--- a/nodo.md
+++ b/docs/nodo.md
@@ -1,12 +1,10 @@
-[[!toc levels=4]]
+# Gestão de nodos
 
-Adicionando um nodo 
-===================
+## Adicionando um nodo 
 
 Procedimento para adicionar um novo nodo à infraestrutura.
 
-Assumindo
----------
+### Assumindo
 
 Neste exemplo, assumiremos os seguites parâmetros:
 
@@ -22,8 +20,7 @@ Ainda:
 
 Certifique-se de configurar os parâmetros acima em cada um dos shells mencionados.
 
-Configuração de DNS
--------------------
+### 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
@@ -37,10 +34,10 @@ No caso de um `CNAME`:
 
     $node 3600 IN CNAME $domain.
 
-Provisionamento
----------------
+### Provisionamento
 
-Esta consiste na criação do nodo -- máquina virtual ou servidor físico, podendo ser feita de dois modos:
+Esta consiste na criação do nodo -- máquina virtual ou servidor físico, podendo
+ser feita de dois modos:
 
 * Via puppet na própria infraestrutura da `$hydra`.
   * No caso de um servidor físico, proceda [apropriadamente](/install).
@@ -48,10 +45,10 @@ Esta consiste na criação do nodo -- máquina virtual ou servidor físico, pode
     hospedeira usando o padrão de virtualização desejado.
 * Solicitando a um coletivo hospedeiro altamente confiável.
 
-No caso de uma máquina virtual hospedada numa máquina física do grupo, considere a [faixa de alocação](allocation) de IPS.
+No caso de uma máquina virtual hospedada numa máquina física do grupo,
+considere a [faixa de alocação](allocation) de IPS.
 
-Definição do nodo
------------------
+### Definição do nodo
 
 Definição básica do nodo:
 
@@ -66,19 +63,18 @@ Em seguida, submeta as mudanças para o repositório:
     admin@box$ cd `hydra $hydra folder`/puppet
     admin@box$ git commit -a -m "Adicionando nodo $node" && git push
 
-Chaves
-------
+### Chaves
 
 Envie a chaves geradas para o novo nodo:
 
     admin@box$ hydra $hydra import-keys $node.$domain
 
-No caso de chaves para conexões TLS, envie-as juntamente com o certificado de cada domínio:
+No caso de chaves para conexões TLS, envie-as juntamente com o certificado de
+cada domínio:
 
     admin@box$ hydra $hydra import-certs $node.$domain [certs]
 
-Configurando o puppet
----------------------
+### Configurando o puppet
 
 Instale o pacote:
 
@@ -88,34 +84,38 @@ Certifique-se então que os seguintes valores correspondem a `$node.$domain`:
 
     root@nodo# facter fqdn
 
-Lembre-se de iniciar o `puppet agent` pela primeira vez através de um comando do tipo
+Lembre-se de iniciar o `puppet agent` pela primeira vez através de um comando
+do tipo
 
     root@nodo# puppet agent --server puppet.`facter domain` --pluginsync true --waitforcert 60 --test
 
-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:
+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 | grep $node.$domain
 
-Caso os fingerprints batam, basta liberar o novo nodo a partir do host em que roda o master como o comando
+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 $node.$domain
 
-Assista as mudanças nos arquivos de log (`/var/log/daemon.log` ou `/var/log/syslog`):
+Assista as mudanças nos arquivos de log (`/var/log/daemon.log` ou
+`/var/log/syslog`):
 
     root@nodo# tail -F /var/log/daemon.log /var/log/syslog
 
-Mais detalhes [aqui](http://projects.puppetlabs.com/projects/1/wiki/certificates_and_security) sobre certificados e segurança.
+Mais detalhes
+[aqui](http://projects.puppetlabs.com/projects/1/wiki/certificates_and_security)
+sobre certificados e segurança.
 
-Deploy da Hydra Suite
----------------------
+### Deploy da Hydra Suite
 
 Faça a instalação da hidra suite no novo nodo:
 
     admin@box$ hydra $hydra install $node.$domain
 
-Fingerprints e Monkeysphere
----------------------------
+### Fingerprints e Monkeysphere
 
 Verifique os fingerprints do SSH e do puppet:
 
@@ -123,15 +123,19 @@ Verifique os fingerprints do SSH e do puppet:
     root@nodo#   hydractl puppet-finger
     root@master# hydractl puppet-finger
 
-Opcionalmente, proceda com a [configuração das chaves de serviço do monkeysphere](http://web.monkeysphere.info/doc/host-keys).
+Opcionalmente, proceda com a [configuração das chaves de serviço do
+monkeysphere](http://web.monkeysphere.info/doc/host-keys).
 
-Inscrição em lista de mensagens
--------------------------------
+### 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@$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.
+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.
 
-Retirando um nodo
-=================
+## Retirando um nodo
 
 Para descomissionar um nodo, proceda na máquina administrativa:
 
@@ -152,6 +156,7 @@ Por fim:
 
 * Checar backups remoto do nodo, caso se queira recuperar algum dado no futuro!
 * Apagar entradas DNS.
-* Chaves no keyringer não precisam ser movidas necessariamente, pois podem ser úteis para acesso dos backups.
+* Chaves no keyringer não precisam ser movidas necessariamente, pois podem ser
+  úteis para acesso dos backups.
 * Limpar página de fingerprints.
 * Revogar chaves (OpenPGP, SSL), quando cabível.
diff --git a/nodo/allocation.md b/docs/nodo/allocation.md
index c6f3fe8..ff4c368 100644
--- a/nodo/allocation.md
+++ b/docs/nodo/allocation.md
@@ -1,9 +1,11 @@
-Alocação de IPs e contextos
-===========================
+# Alocação de IPs e contextos
 
-Convenção de contextos, portas e IPs externos de acordo com a classe/uso das máquinas virtuais.
+Convenção de contextos, portas e IPs externos de acordo com a classe/uso das
+máquinas virtuais.
 
-Nela, são alocados os X primeiros contextos de cada máquina física pras classes próprias, usando os números altos (faixa Y) para máquinas virtuais de terceiros.
+Nela, são alocados os `X` primeiros contextos de cada máquina física pras classes
+próprias, usando os números altos (faixa `Y`) para máquinas virtuais de
+terceiros.
 
 No caso:
 
@@ -22,14 +24,18 @@ No caso:
 Assim,
 
 * Alocamos até o contexto 40 para uso próprio.
-* Do 41 ao 99 para máquinas virtuais de terceiros, ou outros valores nessa mesma linha.
+* Do 41 ao 99 para máquinas virtuais de terceiros, ou outros valores nessa
+  mesma linha.
 
-Eventualmente, da faixa Y (41 ao 99, por exemplo) podemos alocar um numero universal por grupo hospedado. Assim,
+Eventualmente, da faixa Y (41 ao 99, por exemplo) podemos alocar um numero
+universal por grupo hospedado. Assim,
 
 * 41 seria sempre grupo X.
 * 42 grupo Y, etc.
 
 Ou seja,
 
- * Sempre que houvesse uma máquina virtual do grupo Y numa maquina, seria sempre no contexto 42, IP interno 192.168.0.42, porta 2242.
- * Já o nome da máquina virtual mudaria sempre, eventualmente seguindo o padrao do [puppet-bootstrap](https://git.sarava.org/?p=puppet-bootstrap.git).
+ * Sempre que houvesse uma máquina virtual do grupo Y numa maquina, seria
+   sempre no contexto 42, IP interno 192.168.0.42, porta 2242.
+ * Já o nome da máquina virtual mudaria sempre, eventualmente seguindo o padrao
+   do [puppet-bootstrap](https://git.sarava.org/?p=puppet-bootstrap.git).
diff --git a/provision.md b/docs/provision.md
index 9389eb3..228452d 100644
--- a/provision.md
+++ b/docs/provision.md
@@ -1,40 +1,40 @@
-[[!toc levels=4]]
+# Provisionando um Sistema Operacional
 
-Provisionando um Sistema Operacional
-====================================
+A seguir, o procedimento de instalação de um sistema com disco criptografado,
+opcionalmente com gerenciamento de partida via dispositivo de armazenamento
+USB.
 
-A seguir, o procedimento de instalação de um sistema com disco criptografado, opcionalmente com gerenciamento de partida via dispositivo de armazenamento USB.  
+## Instalação 
 
-Instalação 
-----------
-
-Após a [instalação da Hydra Suite](/install), basta iniciar o procedimento com os devidos privilégios administrativos (como `root` ou usando o `sudo`):
+Após a [instalação da Hydra Suite](/install), basta iniciar o procedimento com
+os devidos privilégios administrativos (como `root` ou usando o `sudo`):
 
     hydractl provision
 
-O programa perguntará por parâmetros da instalação, como o dispositivo no qual o deve ser instalado, a arquitetura, a versão do sistema e o domínio principal. Depois disso a suíte se encarregará da maior parte dos detalhes de instalação.
+O programa perguntará por parâmetros da instalação, como o dispositivo no qual
+o deve ser instalado, a arquitetura, a versão do sistema e o domínio principal.
+Depois disso a suíte se encarregará da maior parte dos detalhes de instalação.
 
-Continuando remotamente 
------------------------
+## Continuando remotamente 
 
-Agora a máquina já está quase a ponto de poder ser administrada remotamente. Antes disso, configure a rede e adicione as contas de usuário/a iniciais:
+Agora a máquina já está quase a ponto de poder ser administrada remotamente.
+Antes disso, configure a rede e adicione as contas de usuário/a iniciais:
 
     vi /etc/network/interfaces.d/local              # configuracao de rede
     vi /etc/udev/rules.d/70-persistent-net.rules    # ajuste das placas de rede
     vi /etc/resolv.conf                             # para usar o dns disponivel no data center
     adduser nome-de-usuario
 
-Antes de largar a máquina no data center, lembre-se de anotar os fingerprints do ssh exibidos anteriormente.
+Antes de largar a máquina no data center, lembre-se de anotar os fingerprints
+do ssh exibidos anteriormente.
 
-Expansão de espaço em disco 
----------------------------
+## Expansão de espaço em disco 
 
 * [How to resize a LUKS-encrypted partition created over LVM2](http://www.saout.de/tikiwiki/tiki-index.php?page=ResizeLUKSPartitions).
 * [Resizing Encrypted Filesystems](http://www.debian-administration.org/articles/536).
 * [Resizing a dm-crypt / LVM / ext3 partition](http://www.hermann-uwe.de/blog/resizing-a-dm-crypt-lvm-ext3-partition). 
 
-Referências 
------------
+## Referências 
 
 Algumas referências para instalação:
 
@@ -43,7 +43,9 @@ Algumas referências para instalação:
 * [EncryptedFilesystems - Ubuntu Documentation](https://help.ubuntu.com/community/EncryptedFilesystems).
 * [Encrypting an entire system - ArchWiki](https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LUKS_on_LVM).
 
-A opção de partida `rootdelay` é importante no caso de sistemas contidos dentro de volumes USB, já que o kernel demora alguns instantes para detectar tais volumes. Detalhes a respeito em
+A opção de partida `rootdelay` é importante no caso de sistemas contidos dentro
+de volumes USB, já que o kernel demora alguns instantes para detectar tais
+volumes. Detalhes a respeito em
 
 * [Installing Linux on USB - Part 5: Installing Debian Linux on USB flash memory drives](http://blogs.koolwal.net/2009/02/03/installing-linux-on-usb-part-5-installing-debian-linux-on-usb-flash-memory-drives/).
 * [initramfs-tools: lvm is not initialized on USB disks](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366175#37).
diff --git a/docs/rescue.md b/docs/rescue.md
new file mode 100644
index 0000000..95ffe03
--- /dev/null
+++ b/docs/rescue.md
@@ -0,0 +1,67 @@
+# Sistema de Resgate
+
+Um sistema de resgate pode ser útil para a [instalação](install.md) de um sistema
+novo ou mesmo para a manutenção de máquinas com defeito.
+
+## Baixando o sistema
+
+Utilizamos imagens `iso-hybrid` do [Debian
+Live](https://www.debian.org/CD/live/) como base para o sistema de resgate.
+
+## Gravando o sistema
+
+    dd if=debian-live-6.0.1-amd64-standard.iso of=/dev/sdb
+
+## Criando uma imagem de resgate
+
+Imagens de resgate podem ser criadas usando o
+[debirf](http://cmrg.fifthhorseman.net/wiki/debirf):
+
+    apt install debirf
+    tar xzf /usr/share/doc/debirf/example-profiles/rescue.tgz 
+    debirf make rescue
+    debirf makeiso rescue
+
+Alternativamente, podemos criá-las usando o
+[live-build](http://live.debian.net/devel/live-build/):
+
+    apt install live-build
+    mkdir live-default && cd live-default
+    lb config
+    sudo lb build
+
+Mais informações
+[aqui](http://live.debian.net/manual/git/html/live-manual.en.html),
+especialmente sobre [criação de
+imagens](http://live.debian.net/manual/git/html/live-manual.en.html#179) e
+[customização de versão e
+pacotes](http://live.debian.net/manual/git/html/live-manual.en.html#managing-a-configuration).
+
+## Habilitando acesso remoto
+
+    apt install openssh-server
+    ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
+
+## Configuração mínima
+
+    sudo su
+    passwd root
+
+## Instalando ferramentas básicas
+
+    apt update
+    apt install screen pciutils usbutils git locales
+
+## Usando remotamente
+
+A grande vantagem do sistema de resgate é a sua possibilidade de utilização
+remota. Com o servidor `SSH` instalado, é possível se conectar a ele do
+conforto do seu desktop ou laptop! Antes de fazer isso, não deixe de verificar
+a impressão digital do serviço `SSH` do sistema de resgate.
+
+A partir do seu computador:
+
+    ssh root@IP-DO-SISTEMA-DE-RESGATE
+    # confirme o fingerprint   
+
+Uma vez no sistema, é até possível compartilhar a sessão de trabalho usando o `screen`.
diff --git a/docs/swap.md b/docs/swap.md
new file mode 100644
index 0000000..9004f47
--- /dev/null
+++ b/docs/swap.md
@@ -0,0 +1,37 @@
+# Swap criptografada no Debian 
+
+Se, no caso de partições de sistemas de arquivos é interessante que sejam
+montadas apenas por intervenção humana (pois do contrário não haverá ganho em
+segurança com a criptografia), o mesmo não precisa ocorrer com a swap porque
+ela é usada apenas como área de troca temporária, mas apenas se a mesma foi
+sempre recriada com uma chave aleatória.
+
+Por isso, não há problema em deixar o sistema recriar uma swap criptografada
+com chave aleatória a cada vez que o sistema é reiniciado. Isso é até uma
+vantagem, já que, a cada vez que o sistema reinicia, ele usa uma chave
+diferente para criar a swap.
+
+O procedimento a seguir é baseado em [Encrypted swap partition on
+Debian/Ubuntu](http://feeding.cloud.geek.nz/2008/03/encrypted-swap-partition-on.html).
+
+## Procedimento 
+
+Considerando que você esteja com o pacote `cryptsetup` instalado, proceda da
+seguinte maneira para a criação de um dispositivo de swap:
+
+    swapoff -a
+    cryptsetup -h sha512 -c aes-xts-plain64:sha256 -s 512 create swap /dev/SUA_SWAP
+    mkswap -f /dev/mapper/swap
+    swapon /dev/mapper/swap
+
+Adicione a seguinte entrada no seu `/etc/crypttab`:
+
+    swap /dev/SUA_SWAP /dev/random swap,cipher=aes-xts-plain64:sha256
+
+Substitua a entrada atual para a swap do `/etc/fstab` para a seguinte:
+
+    /dev/mapper/swap none swap sw 0 0
+
+Proceda de modo análogo para cada swap existente no sistema. Ao reiniciar sua
+máquina, o sistema deverá ser capaz de recriar os dispositivos de swap usando
+uma nova senha aleatória a cada vez. 
diff --git a/docs/todo.md b/docs/todo.md
new file mode 100644
index 0000000..17f00d2
--- /dev/null
+++ b/docs/todo.md
@@ -0,0 +1,12 @@
+# TODO
+
+## [Certificados](certs.md)
+
+* Disponinibilizar modelos (`templates/certs` e `notices/certs`).
+* Procedimento para salvar contratos, invoices, etc no repositório de
+  documentação.
+* Onde for possível, substituir "SSL" por "TLS", "x509", "certs" ou
+  "Certificados" quando aplicável.
+* Traduzir
+  [Certificates](https://help.riseup.net/pt/security/network-security/certificates)
+e usar como referência de protocolo.
diff --git a/ikiwiki.yaml b/ikiwiki.yaml
deleted file mode 100644
index 871539e..0000000
--- a/ikiwiki.yaml
+++ /dev/null
@@ -1,427 +0,0 @@
-# IkiWiki::Setup::Yaml - YAML formatted setup file
-#
-# Setup file for ikiwiki.
-# 
-# Passing this to ikiwiki --setup will make ikiwiki generate
-# wrappers and build the wiki.
-# 
-# Remember to re-run ikiwiki --setup any time you edit this file.
-#
-# name of the wiki
-wikiname: Padr&atilde;o Fluxo
-# contact email for wiki
-adminemail: rhatto@fluxo.info
-# users who are wiki admins
-adminuser:
-- rhatto
-# users who are banned from the wiki
-banned_users: []
-# where the source of the wiki is located
-srcdir: .
-# where to build the wiki
-destdir: www
-# base url to the wiki
-url: https://padrao.fluxo.info
-# url to the ikiwiki.cgi
-cgiurl: https://padrao.fluxo.info/ikiwiki.cgi
-# do not adjust cgiurl if CGI is accessed via different URL
-reverse_proxy: 0
-# filename of cgi wrapper to generate
-cgi_wrapper: ''
-# mode for cgi_wrapper (can safely be made suid)
-cgi_wrappermode: 06755
-# number of seconds to delay CGI requests when overloaded
-cgi_overload_delay: ''
-# message to display when overloaded (may contain html)
-cgi_overload_message: ''
-# enable optimization of only refreshing committed changes?
-only_committed_changes: 0
-# rcs backend to use
-rcs: git
-# plugins to add to the default configuration
-add_plugins:
-- goodstuff
-- sidebar
-- favicon
-# plugins to disable
-disable_plugins:
-- openid
-- editpage
-# additional directory to search for template files
-templatedir: /usr/share/ikiwiki/templates
-# base wiki source location
-underlaydir: /usr/share/ikiwiki/basewiki
-# display verbose messages?
-#verbose: 1
-# log to syslog?
-#syslog: 1
-# create output files named page/index.html?
-usedirs: 1
-# use '!'-prefixed preprocessor directives?
-prefix_directives: 1
-# use page/index.mdwn source files
-indexpages: 0
-# enable Discussion pages?
-discussion: 0
-# name of Discussion pages
-discussionpage: Discussion
-# use elements new in HTML5 like <section>?
-html5: 0
-# only send cookies over SSL connections?
-sslcookie: 0
-# extension to use for new pages
-default_pageext: mdwn
-# extension to use for html files
-htmlext: html
-# strftime format string to display date
-timeformat: '%c'
-# UTF-8 locale to use
-#locale: en_US.UTF-8
-# put user pages below specified page
-userdir: ''
-# how many backlinks to show before hiding excess (0 to show all)
-numbacklinks: 10
-# attempt to hardlink source files? (optimisation for large files)
-hardlink: 0
-# force ikiwiki to use a particular umask (keywords public, group or private, or a number)
-umask: 2
-# group for wrappers to run in
-#wrappergroup: ikiwiki
-# extra library and plugin directories
-libdirs: []
-# extra library and plugin directory (searched after libdirs)
-libdir: ''
-# environment variables
-ENV: {}
-# time zone name
-timezone: :/etc/localtime
-# regexp of normally excluded files to include
-#include: ^\.htaccess$
-# regexp of files that should be skipped
-exclude: (?^:www)
-# specifies the characters that are allowed in source filenames
-wiki_file_chars: -[:alnum:]+/.:_
-# allow symlinks in the path leading to the srcdir (potentially insecure)
-allow_symlinks_before_srcdir: 0
-# cookie control
-cookiejar:
-  file: /home/rhatto/.ikiwiki/cookies
-# set custom user agent string for outbound HTTP requests e.g. when fetching aggregated RSS feeds
-useragent: ikiwiki/3.20170111
-# theme has a responsive layout? (mobile-optimized)
-responsive_layout: 1
-# try harder to produce deterministic output
-deterministic: 0
-
-######################################################################
-# core plugins
-#   (editpage, git, htmlscrubber, inline, link, meta, parentlinks,
-#    templatebody)
-######################################################################
-
-# git plugin
-# git hook to generate
-#git_wrapper: /git/wiki.git/hooks/post-update
-# shell command for git_wrapper to run, in the background
-#git_wrapper_background_command: git push github
-# mode for git_wrapper (can safely be made suid)
-#git_wrappermode: 06755
-# git pre-receive hook to generate
-#git_test_receive_wrapper: /git/wiki.git/hooks/pre-receive
-# unix users whose commits should be checked by the pre-receive hook
-#untrusted_committers: []
-# gitweb url to show file history ([[file]] substituted)
-historyurl: https://git.fluxo.info/padrao/log/[[file]]
-# gitweb url to show a diff ([[file]], [[sha1_to]], [[sha1_from]], [[sha1_commit]], and [[sha1_parent]] substituted)
-diffurl: https://git.fluxo.info/padrao/commit/[[file]]?id=[[sha1_commit]]
-# where to pull and push changes (set to empty string to disable)
-gitorigin_branch: ''
-# branch that the wiki is stored in
-gitmaster_branch: master
-
-# htmlscrubber plugin
-# PageSpec specifying pages not to scrub
-#htmlscrubber_skip: '!*/Discussion'
-
-# inline plugin
-# enable rss feeds by default?
-rss: 1
-# enable atom feeds by default?
-#atom: 0
-# allow rss feeds to be used?
-#allowrss: 0
-# allow atom feeds to be used?
-#allowatom: 0
-# urls to ping (using XML-RPC) on feed update
-pingurl: []
-
-######################################################################
-# auth plugins
-#   (anonok, blogspam, emailauth, httpauth, lockedit, moderatedcomments,
-#    opendiscussion, openid, passwordauth, signinedit)
-######################################################################
-
-# anonok plugin
-# PageSpec to limit which pages anonymous users can edit
-#anonok_pagespec: '*/discussion'
-
-# blogspam plugin
-# PageSpec of pages to check for spam
-#blogspam_pagespec: postcomment(*)
-# options to send to blogspam server
-#blogspam_options: blacklist=1.2.3.4,blacklist=8.7.6.5,max-links=10
-# blogspam server JSON url
-#blogspam_server: ''
-
-# emailauth plugin
-# email address to send emailauth mails as (default: adminemail)
-#emailauth_sender: ''
-
-# httpauth plugin
-# url to redirect to when authentication is needed
-#cgiauthurl: http://example.com/wiki/auth/ikiwiki.cgi
-# PageSpec of pages where only httpauth will be used for authentication
-#httpauth_pagespec: '!*/Discussion'
-
-# lockedit plugin
-# PageSpec controlling which pages are locked
-#locked_pages: '!*/Discussion'
-
-# moderatedcomments plugin
-# PageSpec matching users or comment locations to moderate
-#moderate_pagespec: '*'
-
-# openid plugin
-# url pattern of openid realm (default is cgiurl)
-#openid_realm: ''
-# url to ikiwiki cgi to use for openid authentication (default is cgiurl)
-#openid_cgiurl: ''
-
-# passwordauth plugin
-# a password that must be entered when signing up for an account
-#account_creation_password: s3cr1t
-# cost of generating a password using Authen::Passphrase::BlowfishCrypt
-#password_cost: 8
-
-######################################################################
-# format plugins
-#   (creole, highlight, hnb, html, mdwn, otl, po, rawhtml, rst, textile,
-#    txt)
-######################################################################
-
-# highlight plugin
-# types of source files to syntax highlight
-#tohighlight: .c .h .cpp .pl .py Makefile:make
-# location of highlight's filetypes.conf
-#filetypes_conf: /etc/highlight/filetypes.conf
-# location of highlight's langDefs directory
-#langdefdir: /usr/share/highlight/langDefs
-
-# mdwn plugin
-# enable multimarkdown features?
-#multimarkdown: 0
-# disable use of markdown discount?
-#nodiscount: 0
-
-# po plugin
-# master language (non-PO files)
-#po_master_language: en|English
-# slave languages (translated via PO files) format: ll|Langname
-#po_slave_languages:
-#- fr|Français
-#- es|Español
-#- de|Deutsch
-# PageSpec controlling which pages are translatable
-#po_translatable_pages: '* and !*/Discussion'
-# internal linking behavior (default/current/negotiated)
-#po_link_to: current
-
-######################################################################
-# special-purpose plugins
-#   (osm, underlay)
-######################################################################
-
-# osm plugin
-# the default zoom when you click on the map link
-#osm_default_zoom: 15
-# the icon shown on links and on the main map
-#osm_default_icon: ikiwiki/images/osm.png
-# the alt tag of links, defaults to empty
-#osm_alt: ''
-# the output format for waypoints, can be KML, GeoJSON or CSV (one or many, comma-separated)
-#osm_format: KML
-# the icon attached to a tag, displayed on the map for tagged pages
-#osm_tag_default_icon: icon.png
-# Url for the OpenLayers.js file
-#osm_openlayers_url: http://www.openlayers.org/api/OpenLayers.js
-# Layers to use in the map. Can be either the 'OSM' string or a type option for Google maps (GoogleNormal, GoogleSatellite, GoogleHybrid or GooglePhysical). It can also be an arbitrary URL in a syntax acceptable for OpenLayers.Layer.OSM.url parameter.
-#osm_layers:
-#  OSM: GoogleSatellite
-# Google maps API key, Google layer not used if missing, see https://code.google.com/apis/console/ to get an API key
-#osm_google_apikey: ''
-
-# underlay plugin
-# extra underlay directories to add
-#add_underlays:
-#- /home/rhatto/wiki.underlay
-
-######################################################################
-# web plugins
-#   (404, attachment, comments, editdiff, edittemplate, getsource, google,
-#    goto, mirrorlist, remove, rename, repolist, search, theme, userlist,
-#    websetup, wmd)
-######################################################################
-
-# attachment plugin
-# enhanced PageSpec specifying what attachments are allowed
-#allowed_attachments: virusfree() and mimetype(image/*) and maxsize(50kb)
-# virus checker program (reads STDIN, returns nonzero if virus found)
-#virus_checker: clamdscan -
-
-# comments plugin
-# PageSpec of pages where comments are allowed
-#comments_pagespec: blog/* and !*/Discussion
-# PageSpec of pages where posting new comments is not allowed
-#comments_closed_pagespec: blog/controversial or blog/flamewar
-# Base name for comments, e.g. "comment_" for pages like "sandbox/comment_12"
-#comments_pagename: ''
-# Interpret directives in comments?
-#comments_allowdirectives: 0
-# Allow anonymous commenters to set an author name?
-#comments_allowauthor: 0
-# commit comments to the VCS
-#comments_commit: 1
-# Restrict formats for comments to (no restriction if empty)
-#comments_allowformats: mdwn txt
-
-# getsource plugin
-# Mime type for returned source.
-#getsource_mimetype: text/plain; charset=utf-8
-
-# mirrorlist plugin
-# list of mirrors
-#mirrorlist: {}
-# generate links that point to the mirrors' ikiwiki CGI
-#mirrorlist_use_cgi: 1
-
-# repolist plugin
-# URIs of repositories containing the wiki's source
-#repositories:
-#- svn://svn.example.org/wiki/trunk
-
-# search plugin
-# path to the omega cgi program
-#omega_cgi: /usr/lib/cgi-bin/omega/omega
-# use google site search rather than internal xapian index?
-#google_search: 1
-
-# theme plugin
-# name of theme to enable
-#theme: actiontabs
-
-# websetup plugin
-# list of plugins that cannot be enabled/disabled via the web interface
-#websetup_force_plugins: []
-# list of additional setup field keys to treat as unsafe
-#websetup_unsafe: []
-# show unsafe settings, read-only, in web interface?
-#websetup_show_unsafe: 1
-
-######################################################################
-# widget plugins
-#   (calendar, color, conditional, cutpaste, date, format, fortune,
-#    graphviz, haiku, headinganchors, img, linkmap, listdirectives, map,
-#    more, orphans, pagecount, pagestats, poll, polygen, postsparkline,
-#    progress, shortcut, sparkline, table, template, teximg, toc, toggle,
-#    version)
-######################################################################
-
-# calendar plugin
-# base of the archives hierarchy
-#archivebase: archives
-# PageSpec of pages to include in the archives, if option `calendar_autocreate` is true.
-#archive_pagespec: page(posts/*) and !*/Discussion
-# autocreate new calendar pages?
-#calendar_autocreate: 1
-# if set, when building calendar pages, also build pages of year and month when no pages were published (building empty calendars).
-#calendar_fill_gaps: 1
-
-# img plugin
-# Image formats to process (jpeg, png, gif, svg, pdf or 'everything' to accept all)
-#img_allowed_formats: ''
-
-# listdirectives plugin
-# directory in srcdir that contains directive descriptions
-#directive_description_dir: ikiwiki/directive
-
-# teximg plugin
-# Should teximg use dvipng to render, or dvips and convert?
-#teximg_dvipng: ''
-# LaTeX prefix for teximg plugin
-#teximg_prefix: |
-#  \documentclass{article}
-#  \usepackage[utf8]{inputenc}
-#  \usepackage{amsmath}
-#  \usepackage{amsfonts}
-#  \usepackage{amssymb}
-#  \pagestyle{empty}
-#  \begin{document}
-# LaTeX postfix for teximg plugin
-#teximg_postfix: \end{document}
-
-######################################################################
-# other plugins
-#   (aggregate, autoindex, brokenlinks, camelcase, ddate, embed, favicon,
-#    filecheck, flattr, goodstuff, htmlbalance, localstyle, loginselector,
-#    notifyemail, pagetemplate, pingee, pinger, prettydate, recentchanges,
-#    recentchangesdiff, relativedate, rsync, sidebar, smiley,
-#    sortnaturally, tag, testpagespec, trail, transient)
-######################################################################
-
-# aggregate plugin
-# enable aggregation to internal pages?
-#aggregateinternal: 1
-# allow aggregation to be triggered via the web?
-#aggregate_webtrigger: 0
-
-# autoindex plugin
-# commit autocreated index pages
-#autoindex_commit: 1
-
-# camelcase plugin
-# list of words to not turn into links
-#camelcase_ignore: []
-
-# flattr plugin
-# userid or user name to use by default for Flattr buttons
-#flattr_userid: joeyh
-
-# pinger plugin
-# how many seconds to try pinging before timing out
-#pinger_timeout: 15
-
-# prettydate plugin
-# format to use to display date
-#prettydateformat: '%X, %B %o, %Y'
-
-# recentchanges plugin
-# name of the recentchanges page
-recentchangespage: recentchanges
-# number of changes to track
-recentchangesnum: 100
-
-# rsync plugin
-# command to run to sync updated pages
-#rsync_command: rsync -qa --delete . user@host:/path/to/docroot/
-
-# sidebar plugin
-# show sidebar page on all pages?
-#global_sidebars: 1
-
-# tag plugin
-# parent page tags are located under
-#tagbase: tag
-# autocreate new tag pages?
-#tag_autocreate: 1
-# commit autocreated tag pages
-tag_autocreate_commit: 1
diff --git a/index.md b/index.md
deleted file mode 100644
index f93fb7b..0000000
--- a/index.md
+++ /dev/null
@@ -1,58 +0,0 @@
-Padrão Fluxo
-============
-
-O Padrão Fluxo é uma sistematização de configuração de servidores, gerenciadores de conteúdo e aplicações diversas usados pelo Grupo Fluxo. O padrão foi desenvolvido para:
-
-* Ter controle dos pacotes utilizados, arquivos de configuração e serviços em uso.
-* Uniformidade de administração.
-* Sistema de gerenciamento de backups comum para que as máquinas de um projeto possam trocar dados.
-* Que um servidor seja configurado apenas uma vez e que suas configurações possam ser aproveitados para outras máquinas.
-* Que sites e serviços sejam armazenados de maneira regular para facilitar atualizações e migrações.
-* Manter projetos e serviços isolados uns dos outros através de servidores virtuais.
-* Tornar a instalação dos servidores facilmente replicável. 
-
-A antiga documentação do Padrão Fluxo ainda [está disponível](trac/).
-
-# Conteúdo
-
-* [Sistema de resgate](rescue).
-* [Boxes](boxes).
-* [Instalação](install).
-* [Provisionamento](provision).
-* [Domínios](domains).
-* [Bootless](bootless).
-* [Swap](swap).
-* [Firewire](firewire).
-* [Firewall](firewall).
-* [Backup](backup).
-* [Chaves](keys).
-* [Certificados](certs).
-* [Cryptocalypse](cryptocalypse).
-* [Auditoria](audit).
-* [Bootstrap](bootstrap).
-* [Gerindo um nodo](nodo).
-
-# Licença
-
-O Padrão Fluxo é distribuído conforme a [GNU Affero General Public License](http://www.gnu.org/licenses/agpl-3.0.html):
-
-    Fluxo Pattern
-    Copyright (C) 2015      Fluxo  Group
-    Copyright (C) 2009-2015 Sarava Group
-
-    This program is free software: you can redistribute it and/or modify
-    it under the terms of the GNU Affero General Public License as
-    published by the Free Software Foundation, either version 3 of the
-    License, or any later version.
-
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU Affero General Public License for more details.
-
-    You should have received a copy of the GNU Affero General Public License
-    along with this program.  If not, see <http://www.gnu.org/licenses/>.
-
-----
-
-This wiki is powered by [ikiwiki](http://ikiwiki.info).
diff --git a/install.md b/install.md
deleted file mode 100644
index 8dd1f80..0000000
--- a/install.md
+++ /dev/null
@@ -1,28 +0,0 @@
-[[!toc levels=4]]
-
-Instalação da Hydra Suite
-=========================
-
-Atualmente o Padrão Saravá utiliza a [Hydra Suite](http://git.sarava.org/?p=hydra.git;a=summary) para fazer o provisionamento. Versões anteriores deste documento não o utilizam, são mais descritivas e talvez até mais interessantes ao público interessado nos pormenores do procedimento de instalação.
-
-A Hydra Suite pode ser obtida e instalada diretamente do seu repositório:
-
-    git clone --recursive git://git.sarava.org/hydra.git
-
-Verifique a [integridade do código](https://manual.sarava.org/specs/code/):
-
-    cd hydra
-    tag="`git describe --abbrev=0 --tags`"
-    git tag -v $tag && git checkout $tag
-
-Opcionalmente instale a suite no sistema:
-
-    ./hydractl install
-
-Ambiente de trabalho administrativo
------------------------------------
-
-    HYDRA="nome-do-grupo"
-    FOLDER="`hydra $HYDRA folder`"
-    MAIN_DOMAIN="`hydra $HYDRA config domain`"
-    DOMAIN="$MAIN_DOMAIN" # ou outro domínio
diff --git a/keys.md b/keys.md
deleted file mode 100644
index 7f0bdc8..0000000
--- a/keys.md
+++ /dev/null
@@ -1,158 +0,0 @@
-[[!toc levels=4]]
-
-Repositório de chaves
-=====================
-
-Configuração
-------------
-
-A maior parte dos procedimentos a seguir depende do aplicativo
-[keyringer](http://git.fluxo.info/?p=keyringer.git;a=summary), da [Hydra
-Suite](http://git.fluxo.info/?p=hydra.git;a=summary) e de uma configuração do
-tipo
-
-Proceda então com a [configuração do ambiente de trabalho administrativo](/install).
-
-Inicializando um repositório
-----------------------------
-
-    # Inicializando
-    keyringer $HYDRA init $FOLDER/conf/keyring
-
-Gerando chaves https
---------------------
-
-Gerar chaves e certificados SSL auto-assinados é simples:
-
-    # Gerando chaves para https
-    keyringer $HYDRA genpair ssl-self ssl/$DOMAIN $DOMAIN
-
-Caso você queira gerar apenas a chave e a requisição de certificação (CSR), use
-
-    keyringer $HYDRA genpair ssl ssl/$DOMAIN $DOMAIN
-
-Para a chaves e requisições CaCert, use
-
-    keyringer $HYDRA genpair ssl-cacert ssl/$DOMAIN $DOMAIN
-
-Gerando chaves para novos nodos
--------------------------------
-
-    # Gerando chaves ssh e gpg para novos nodos
-    # A importacao das chaves gpg nos nodos deve ser feita manualmente
-    hydra $HYDRA newkeys
-
-Submetendo mudanças
--------------------
-
-    # Submetendo
-    keyringer $HYDRA git remote add origin giolite@admin.$DOMAIN:keyring.git
-    keyringer $HYDRA git push origin master
-
-Importação de chaves GPG
-------------------------
-
-Importando chaves nos seus respectivos nodos:
-
-    hydra $HYDRA import-key
-
-Chaves pessoais
-===============
-
-Para gerar uma chave SSH pessoal, use um comando do tipo
-
-    ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa     -C "seu@email"
-    ssh-keygen -t ed25519     -f ~/.ssh/id_ed25519 -C "seu@email"
-
-Esse tipo de comando irá gerar uma **chave privada** em `~/.ssh/id_rsa` e uma
-respectiva **chave pública** em `~/.ssh/id_rsa.pub`. Se você já possui uma
-chave em `~/.ssh/id_rsa` e quiser mantê-la, escolha outro nome para a nova
-chave, como por exemplo `~/.ssh/id_rsa_aplicacao`.
-
-Senhas
-------
-
-Exemplo de geração de senhas usando o [pwgen](http://packages.debian.org/lenny/pwgen):
-
-    pwgen -s -y 25
-
-Atenção: muitos programas e configurações podem não funcionar por conta do uso
-de caracteres especiais nas senhas. Assim, recomenda-se evitar alguns
-caracteres especiais -- por exemplo delimitadores de campo -- quando for o caso
-e/ou testar a senha após a sua escolha.
-
-Impressões digitais
-===================
-
-Chaves SSL
-----------
-
-Chaves SSL podem ter seu fingerprint determinado através usando o [OpenSSL em linha de comando](http://www.madboa.com/geek/openssl), com linhas do tipo
-
-    openssl x509 -noout -in /etc/ssl/certs/cert.crt -fingerprint
-    openssl x509 -noout -in /etc/ssl/certs/cert.crt -fingerprint -md5
-
-Chaves públicas SSH
--------------------
-
-O seguinte comando retorna todas as fingerprints dos arquivos de chave pública ssh terminados em `.pub` no diretório `/etc/ssh/`:
-
-    hydractl ssh-finger
-
-Para obter um fingerprint salvo no seu `~/.ssh/known_hosts` pessoal, use
-
-    ssh-keygen -l -F  servidor.exemplo.org        -f ~/.ssh/known_hosts
-    ssh-keygen -l -F [servidor.exemplo.org]:porta -f ~/.ssh/known_hosts
-
-Monkeysphere
-============
-
-O [monkeysphere](http://web.monkeysphere.info) é um programa que permite a verificação de hosts SSH e usuários/as através da Teia de Confiabilidade do OpenPGP. Com ele, o gerenciamento de fingerprints fica mais fácil e evita que páginas como esta centralizem informações que possam se desatualizar.
-
-Além dos [usos já documentados](http://web.monkeysphere.info/doc/), o monkeysphere pode ser utilizado também para autenticação em sistemas que não possuem tal suporte:
-
-    monkeysphere gen-subkey -l 4096                      # caso voce ainda nao tenha uma chave
-    mkdir -m 700 ~/.monkeysphere
-    echo "SEU-ID" >> ~/.monkeysphere/authorized_user_ids # exemplo: "Seu Nome <seu-email@example.org>"
-    touch ~/.ssh/id_rsa_monkeysphere.pub
-    chmod 600 ~/.ssh/id_rsa_monkeysphere.pub
-    MONKEYSPHERE_AUTHORIZED_KEYS=$HOME/.ssh/id_rsa_monkeysphere.pub monkeysphere update-authorized_keys
-
-Agora, basta fornecer a chave localizada em `~/.ssh/id_rsa_monkeysphere.pub` para autenticação :)
-
-Hashes
-======
-
-Hashes são úteis para o armazenamento de senhas de usuário. São usados por exemplo no `shadow(5)`. Para gerar um hash compatível com o shadow (por exemplo para gestão via [puppet-user](http://git.fluxo.info/?p=puppet-user.git;a=summary)), utilize o seguinte comando disponível no pacote [whois do Debian](https://packages.debian.org/stable/whois):
-
-    mkpasswd -m sha-256
-
-Hashes para `htpasswd` são descritos [aqui](http://sarava.fluxo.info/Ajuda/ProtegendoConteudo).
-
-Exportação de assinaturas locais
-================================
-
-    gpg --armor --export-options export-local-sigs --export KEYID
-
-Forçando entrada de senhas via console no GnuPG
-===============================================
-
-    DISPLAY="" gpg <opcoes>
-
-Mudando senhas de chaves
-========================
-
-    ssh-keygen -p -f ~/.ssh/id_rsa
-    gpg --edit-key <ID> edit-key passwd
-
-Chave OpenPGP de Coletivo
-=========================
-
-Vide [Chave OpenPGP de Coletivo](role).
-
-Referências
-===========
-
-* [Using ssh-agent with ssh](http://mah.everybody.org/docs/ssh).
-* [Using Rsync and SSH ](http://troy.jdmz.net/rsync/index.html).
-* [SSH and ssh-agent](http://www.securityfocus.com/infocus/1812).
diff --git a/local.css b/local.css
deleted file mode 100644
index 3a76320..0000000
--- a/local.css
+++ /dev/null
@@ -1,176 +0,0 @@
-body{
-/*	font-family:Palatino,georgia,"times new roman",serif; */
-	font-size: 1.03em;
-	margin-left: auto;
-	margin-right: auto;
-	width: 800px;
-}
-.actions{
-/*	font-family:Palatino,georgia,"times new roman",serif; */
-	font-size: .95em;
-	text-align: left;
-}
-#content{
-	margin-left: 10px;
-	margin-right: -10px;
-	text-align: left;
-	border-right: dashed 1px;
-	padding-right: 30px;
-}
-.pagedate{
-	font-family: times;
-	font-size: .8em;
-}
-
-.sidebar {
-	line-height: 3ex;
-	width: 20ex;
-	float: right;
-	margin-right: 40px;
-	margin-bottom: 40px;
-	padding: 2ex 2ex;
-  border: none;
-}
-
-/*Elements*/
-hr{
-	width: 50%;
-	border: solid 1px black;
-}
-blockquote{
-	border: dashed 1px;
-	padding-left: 20px;
-	margin-left: 15px;
-	background-color: #ccc;
-}
-p{
-	margin-bottom: 1.2em;
-}
-ol{
-	margin-left: 1em;
-}
-/* Headings */
-.header{
-	font-family: georgia;
-	font-size: 1.25em;
-	line-height: 1em;	
-	font-weight: bolder;
-}
-h1{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 2em;
-	font-weight: bold;
-	line-height: 1em;
-	margin-left: 1em;
-	text-indent: -1em;
-}
-h2{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 1.8em;
-	line-height: 1em;	
-	font-weight: bold;
-	margin-left: 1em;
-	text-indent: -1em;
-}
-h3{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 1.6em;
-	font-weight: bold;
-	line-height: 1em;
-	margin-left: 1em;
-	text-indent: -1em;	
-}
-h4{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 1.4em;	
-	font-weight: bold;
-	line-height: 1em;
-	margin-left: 1em;
-	text-indent: -1em;
-}
-h5{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 1.2em;	
-	font-weight: bold;
-	line-height: 1em;
-	margin-left: 1em;
-	text-indent: -1em;
-}
-h6{
-	font-family:Palatino,georgia,"times new roman",serif; 
-	font-size: 1em;	
-	font-weight: bold;
-	line-height: 1em;
-	margin-left: 1em;
-	text-indent: -1em;
-}
-/*Forums*/
-form{
-	font-size: .9em;
-	font-family: "Inconsolata", "monaco", "droid sans mono",fixed;
-	margin-left: 1em;
-	margin-top: 1.2em;
-}
-textarea{
-	font-family: "Inconsolata", "monaco", "droid sans mono",fixed;
-   	font-size: .9em;
-        border: solid 1px;
-	width: 500px;
-	margin-bottom: 10px;
-}
-input#comments{
-	font-family: "Inconsolata", "monaco", "droid sans mono",fixed;
-	font-size: .9em;
-	width: 550px;
-	line-height: 1em;
-	background-color: #fff;
-	border: solid 1px;
-}
-input#comments{
-	font-family: "Inconsolata", "monaco", "droid sans mono",fixed;
-	font-size: .9em;
-	width: 550px;
-	line-height: 1em;
-	background-color: #fff;	
-        border: solid 1px;
-}
-input[type="submit"]{
-	font-family: 
-	font-size: .9em;
-	font-weight: bold;
-	line-height: 1em;
-	background-color: #ddd;	
-	margin-right: 1.1em;
-	margin-top: 10px;
-	padding: 3px;
-	text-align: center;
-	width: 9.5em;
-        border: solid 1px;
-}
-#blogform input[name="title"]{
-	font-family: "inconsolata", "monaco", "droid sans mono",fixed;
-	font-size: .9em;
-	line-height: 1.2em;
-	font-size: 1.1em;
-	margin-left: .4em;
-	margin-right: .4em;
-        border: solid 1px;
-}
-#blogform input[type="submit"]{
-	font-family: "Inconsolata", "monaco", "droid sans mono",fixed;
-	font-size: .9em;
-	line-height: 1em;
-	font-size: 1em;
-	background-color: #ddd;
-        border: solid 1px;
-}
-
-#content pre {
-  background: rgb(230,230,230);
-  padding: 10px;
-  border: solid 1px #BBBBBB;
-}
-
-.pageheader .actions ul {
-  border-bottom: none;
-}
diff --git a/mkdocs.yml b/mkdocs.yml
new file mode 100644
index 0000000..cadf882
--- /dev/null
+++ b/mkdocs.yml
@@ -0,0 +1,25 @@
+site_name: Padrão Fluxo
+
+theme:
+  name: readthedocs
+
+  logo: https://fluxo.info/images/fluxo.png
+
+nav:
+  - index.md
+  - rescue.md
+  - boxes.md
+  - install.md
+  - provision.md
+  - domains.md
+  - bootless.md
+  - swap.md
+  - firewire.md
+  - firewall.md
+  - backup.md
+  - keys.md
+  - certs.md
+  - cryptocalypse.md
+  - audit.md
+  - bootstrap.md
+  - nodo.md
diff --git a/rescue.md b/rescue.md
deleted file mode 100644
index 4a3734e..0000000
--- a/rescue.md
+++ /dev/null
@@ -1,68 +0,0 @@
-[[!toc levels=4]]
-
-Sistema de Resgate
-==================
-
-Um sistema de resgate pode ser útil para a [instalação](/install) de um sistema novo ou mesmo para a manutenção de máquinas com defeito.
-
-Baixando o sistema
-------------------
-
-Utilizamos imagens `iso-hybrid` do [Debian Live](https://www.debian.org/CD/live/) como base para o sistema de resgate.
-
-Gravando o sistema
-------------------
-
-    dd if=debian-live-6.0.1-amd64-standard.iso of=/dev/sdb
-
-Criando uma imagem de resgate
------------------------------
-
-Imagens de resgate podem ser criadas usando o [debirf](http://cmrg.fifthhorseman.net/wiki/debirf):
-
-    apt install debirf
-    tar xzf /usr/share/doc/debirf/example-profiles/rescue.tgz 
-    debirf make rescue
-    debirf makeiso rescue
-
-Alternativamente, podemos criá-las usando o [live-build](http://live.debian.net/devel/live-build/):
-
-    apt install live-build
-    mkdir live-default && cd live-default
-    lb config
-    sudo lb build
-
-Mais informações [aqui](http://live.debian.net/manual/git/html/live-manual.en.html), especialmente sobre [criação de imagens](http://live.debian.net/manual/git/html/live-manual.en.html#179) e [customização de versão e pacotes](http://live.debian.net/manual/git/html/live-manual.en.html#managing-a-configuration).
-
-Habilitando acesso remoto
--------------------------
-
-    apt install openssh-server
-    ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
-
-Configuração mínima
--------------------
-
-    sudo su
-    passwd root
-
-Instalando ferramentas básicas
-------------------------------
-
-    apt update
-    apt install screen pciutils usbutils git locales
-
-Usando remotamente
-------------------
-
-A grande vantagem do sistema de resgate é a sua possibilidade de utilização
-remota. Com o servidor `SSH` instalado, é possível se conectar a ele do
-conforto do seu desktop ou laptop! Antes de fazer isso, não deixe de verificar
-a impressão digital do serviço `SSH` do sistema de resgate.
-
-A partir do seu computador:
-
-    ssh root@IP-DO-SISTEMA-DE-RESGATE
-    # confirme o fingerprint   
-
-Uma vez no sistema, é até possível compartilhar a sessão de trabalho usando o `screen`.
diff --git a/sidebar.md b/sidebar.md
deleted file mode 100644
index fabe3e2..0000000
--- a/sidebar.md
+++ /dev/null
@@ -1 +0,0 @@
-<img class="logo" src="https://fluxo.info/images/fluxo.png" alt="Padr&atilde;o Fluxo" />
diff --git a/swap.md b/swap.md
deleted file mode 100644
index 8cd73ef..0000000
--- a/swap.md
+++ /dev/null
@@ -1,30 +0,0 @@
-[[!toc levels=4]]
-
-Swap criptografada no Debian 
-============================
-
-Se, no caso de partições de sistemas de arquivos é interessante que sejam montadas apenas por intervenção humana (pois do contrário não haverá ganho em segurança com a criptografia), o mesmo não precisa ocorrer com a swap porque ela é usada apenas como área de troca temporária, mas apenas se a mesma foi sempre recriada com uma chave aleatória.
-
-Por isso, não há problema em deixar o sistema recriar uma swap criptografada com chave aleatória a cada vez que o sistema é reiniciado. Isso é até uma vantagem, já que, a cada vez que o sistema reinicia, ele usa uma chave diferente para criar a swap.
-
-O procedimento a seguir é baseado em [Encrypted swap partition on Debian/Ubuntu](http://feeding.cloud.geek.nz/2008/03/encrypted-swap-partition-on.html).
-
-Procedimento 
-------------
-
-Considerando que você esteja com o pacote `cryptsetup` instalado, proceda da seguinte maneira para a criação de um dispositivo de swap:
-
-    swapoff -a
-    cryptsetup -h sha512 -c aes-xts-plain64:sha256 -s 512 create swap /dev/SUA_SWAP
-    mkswap -f /dev/mapper/swap
-    swapon /dev/mapper/swap
-
-Adicione a seguinte entrada no seu `/etc/crypttab`:
-
-    swap /dev/SUA_SWAP /dev/random swap,cipher=aes-xts-plain64:sha256
-
-Substitua a entrada atual para a swap do `/etc/fstab` para a seguinte:
-
-    /dev/mapper/swap none swap sw 0 0
-
-Proceda de modo análogo para cada swap existente no sistema. Ao reiniciar sua máquina, o sistema deverá ser capaz de recriar os dispositivos de swap usando uma nova senha aleatória a cada vez. 
diff --git a/todo.md b/todo.md
deleted file mode 100644
index 4e9af1b..0000000
--- a/todo.md
+++ /dev/null
@@ -1,12 +0,0 @@
-[[!toc levels=4]]
-
-TODO
-====
-
-[Certificados](certs)
----------------------
-
-* Disponinibilizar modelos (`templates/certs` e `notices/certs`).
-* Procedimento para salvar contratos, invoices, etc no repositório de documentação.
-* Onde for possível, substituir "SSL" por "TLS", "x509", "certs" ou "Certificados" quando aplicável.
-* Traduzir [Certificates](https://help.riseup.net/pt/security/network-security/certificates) e usar como referência de protocolo.