Cleanup old stuff

5 files changed, 10 insertions, 380 deletions

diff --git a/index.md b/index.md
index 17d4b9d..f93fb7b 100644
--- a/index.md
+++ b/index.md
@@ -24,8 +24,6 @@ A antiga documentação do Padrão Fluxo ainda [está disponível](trac/).
 * [Swap](swap).
 * [Firewire](firewire).
 * [Firewall](firewall).
-* [VServers](vservers).
-* [Puppet](puppet).
 * [Backup](backup).
 * [Chaves](keys).
 * [Certificados](certs).
diff --git a/puppet.md b/puppet.md
deleted file mode 100644
index 67a672d..0000000
--- a/puppet.md
+++ /dev/null
@@ -1,216 +0,0 @@
-[[!toc levels=4]]
-
-Bootstrap da configuração do puppet 
-===================================
-
-Pré-requisitos
---------------
-
-### DNS
-
-Certifique-se de que existe uma entrada do tipo `puppet.projeto.org` apontando para o host que hospeda (ou hospedará) o puppetmaster. Caso contrário, será preciso adicionar o nome do host no `/etc/puppet/puppet.conf` de cada cliente logo após sua instalação:
-
-    [puppetd]
-    server = puppet.projeto.org
-
-E então reiniciar o serviço:
-
-    /etc/init.d/puppet restart
-
-### Firewall
-
-É importante que o vserver hospedeiro do puppet tenha acesso SSH externo. Assim, certifique-se que seu Debian/Firewall possua uma linha do seguinte tipo no arquivo `/etc/shorewall/rules`:
-
-    DNAT            net             vm:192.168.0.2:22 tcp 2202
-
-No caso, `192.168.0.2` é o IP do vserver, `22` a porta de destino nesse IP e `2202` a porta aberta para a conexão externa. Para tal configuração ser efetiva, o `ListenAddress` do `/etc/ssh/sshd_config` do servidor SSH da **máquina hospedeira** deve estar restrito ao IP real da máquina.
-
-Gitosis
--------
-
-O gitosis é um gerenciador de repositórios git que utiliza chaves públicas ssh para controle de acesso. A ferramenta é simples, poderosa, está nos repositórios do debian estável, e sua configuração é feita através de um repositório git, o que sugere um bom ponto de partida para o bootstrap.
-
-Hoje em dia o Padrão Saravá utiliza o gitolite, porém o bootstrap inicial utilizou o gitosis. Fica aos leitores/as o exercício de utilizar o gitolite.
-
-gitosis via puppetmasterd
--------------------------
-
-O primeiro passo é criar o arquivo de manifesto `/etc/puppet/manifests/classes/gitosis.pp` com o seguinte conteúdo:
-
-    class gitosis {
-      # directory for gitosis user and repositories
-      file { "/var/git":
-        ensure => directory,
-        mode   => 0755,
-        owner  => gitosis,
-        group  => gitosis;
-      }
-    
-      # the needed packages
-      package { gitosis: ensure => installed; }
-      package { sudo:    ensure => installed; }
-      package { git:     ensure => installed; }
-    
-      # alters the user's home dir
-      user { gitosis:
-        allowdupe => false,
-        comment   => "git repository hosting,,,",
-        ensure    => present,
-        home      => "/var/git",
-        shell     => "/bin/sh";
-      }
-    
-      # tries to get rid of ugly directory structure
-      file { "/srv/gitosis":
-        ensure => absent,
-        force  => true;
-      }
-      file { "/srv": ensure => absent; }
-    }
-
-O arquivo acima, além de garantir que o git, sudo e gitosis estejam instalados, altera o home do usuário gitosis para `/var/git`, dentro do qual será criado um diretório chamado `repositories` onde serão armazendos nossos repositórios git.
-
-Para aplicar as configurações ao nó, adicionanos o seguinte conteúdo ao arquivo de manifesto `/etc/puppet/manifests/site.pp`:
-
-    import "classes/gitosis.pp"
-    
-    node 'admin.projeto.org' {
-      include gitosis
-    }
-
-Para dar acesso ao primeiro usuário do gitosis, basta executar o seguinte comando:
-
-    sudo -H -u gitosis gitosis-init < FILENAME.pub
-    # (ou simplesmente copie e cole a chave pública aqui)
-
-Um comentário importante sobre a opção `-H`:
-
-    .. warning::
-    
-    	For now, ``gitosis`` uses the ``HOME`` environment variable to
-    	locate where to write its files. If you use ``sudo -u``
-    	without ``-H``, ``sudo`` will leave the old value of ``HOME``
-    	in place, and this will cause trouble. There will be a
-    	workaround for that later on, but for now, always remember to
-    	use ``-H`` if you're sudoing to the account.
-
-Agora podemos clonar o repositório administrativo do gitosis remotamente:
-
-    git clone ssh://gitosis@servidor.projeto.org:porta/gitosis-admin
-
-A configuração não deve ser feita diretamente no repositório do gitosis no servidor, como indicam os autores:
-
-    You should always edit the configuration file via ``git``. The file
-    symlinked to ``~/.gitosis.conf`` on the server will be overwritten
-    when pushing changes to the ``gitosis-admin.git`` repository.
-
-puppetmasterd via gitosis 
--------------------------
-
-Agora que podemos alterar a configuração do gitosis remotamente, vamos criar a permissão de acesso ao novo repositório de configurações do puppet, alterando `gitosis-admin/gitosis.conf`:
-
-    [gitosis]
-    
-    [group gitosis-admin]
-    writable = gitosis-admin
-    members = usuario@maquina
-    
-    [group puppet]
-    writable = puppet
-    members = usuario@maquina
-
-E atualizamos as configurações no servidor através do git local:
-
-    git commit -a
-    git push origin master
-
-Agora, de volta ao servidor, inicializamos um repositório git em `/etc/puppet` e clonamos para o diretório do gitosis:
-
-    cd /etc/puppet
-    git init
-    git add *
-    git commit
-    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 puppet remotamente:
-
-    git clone ssh://gitosis@servidor.projeto.org:porta/puppet.git
-
-Agora adicionamos um manifesto para o puppetmasterd em `puppet/manifests/classes/puppetmasterd.pp`:
-
-    class puppetmasterd {
-      package { puppetmaster: ensure => installed }
-    
-      # updates the puppet configuration dir with git repositories
-      # every 5 minutes.
-      cron { puppet-conf:
-        command => "git --git-dir=/etc/puppet/.git/ pull /var/git/repositories/puppet.git master && \
-                    git --git-dir=/etc/puppet/.git/ --work-tree=/etc/puppet/ checkout -f",
-        user    => root,
-        hour    => '*',
-        minute  => '*/5',
-        ensure  => present;
-      }
-     
-      # runs the service
-      service { puppetmasterd: ensure => running; }
-    }
-
-E atualizamos `puppet-conf/manifests/site.pp`:
-
-    import "classes/gitosis.pp"
-    import "classes/puppetmasterd.pp"
-    
-    node 'admin.projeto.org' {
-      include gitosis
-      include puppetmasterd
-    }
-
-Enviamos as novas configurações para o servidor:
-
-    git add classes/puppetmasterd.pp
-    git add site.pp
-    git commit
-    git push origin master
-
-Finalmente, no servidor, fazemos a última atualização do repositório de configurações do puppet na mão:
-
-    git --git-dir=/etc/puppet/.git/ pull /var/git/repositories/puppet.git && \
-    git --git-dir=/etc/puppet/.git/ --work-tree=/etc/puppet/ checkout -f
-
-Agora a nova regra do cron garantirá que o repositório em `/etc/puppet` estará sempre atualizado com o repositório em `/var/git/puppet-conf`.
-
-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`.
-
-Stored Configs
---------------
-
-Para utilizar [storeconfigs](http://reductivelabs.com/trac/puppet/wiki/UsingStoredConfiguration) via mysql, proceda com os seguintes comandos:
-
-    apt-get install mysql-server
-    mysqladmin -u root -p create puppet
-    mysql -u root -p
-
-Comandos para o mysql:
-
-    GRANT ALL PRIVILEGES ON puppet.* TO puppet@"%" IDENTIFIED BY 'senha';
-    flush privileges;
-
-Linhas adicionadas no puppet.conf do nodo master, na seção `[puppetmasterd]`:
-
-    storeconfigs = true
-    dbadapter    = mysql
-    dbserver     = localhost
-    dbuser       = puppet
-    dbpassword   = senha
-
-Referências
------------
-
-* [Puppet no Riseup](https://we.riseup.net/riseup+tech/puppet). 
-
-Adicionando mais masters
-========================
-
-[Como adicionar mais puppetmasters](master).
diff --git a/puppet/master.md b/puppet/master.md
deleted file mode 100644
index 1a44775..0000000
--- a/puppet/master.md
+++ /dev/null
@@ -1,74 +0,0 @@
-Configurando um master
-======================
-
-Procedimento para configurar um novo master e eventualmente assumi-lo como o
-master principal da rede.
-
-Deploy do nodo
---------------
-
-* Assumiremos `$old` como o hostname do master antigo.
-* Nós usaremos o master `$old` para configurar o master `$node`.
-* Assim, siga as [instruções para adicionar um nodo](/nodo), levando em conta:
-  * Inicialmente, a configuração do nodo com `nodo::role::master::main: false`.
-  * Se o nodo for assumir o papel de um master principal, use `nodo::role::master::main: true`
-    após a aplicação do primeiro catálogo.
-
-Mudança de porta
-----------------
-
-Em alguns casos -- dependendo de onde o novo master for hospedado --, pode ser necessário
-usar uma porta fora do padrão para o `puppetmaster`.
-
-No caso de mudança de portas do puppetmaster, comunicar essa mudança aos nodos
-via `puppet::daemon::port` e aguardar aplicação de catálogo de todos os nodos.
-
-Mudança do DNS
---------------
-
-Esta etapa consiste em fazer a atualização do DNS, para que os nodos acessando `puppet.$domain`
-caiam direto no novo master. Use a seguinte configuração na interface de atualização de DNS,
-substituindo `$node.$domain` pelo domínio do novo master (o ponto final é importante):
-
-    admin    3600   IN   CNAME   $node.$domain.
-    munin    3600   IN   CNAME   $node.$domain.
-    nagios   3600   IN   CNAME   $node.$domain.
-    puppet   3600   IN   CNAME   $node.$domain.
-
-As próximas etapas podem ser executadas enquanto o DNS é propagado.
-
-Importação da chave de backups
-------------------------------
-
-Para importar a chave privada do nodo `$old` no nodo `$node`, use
-
-    admin@box$ HOST=$old hydra $hydra import-key $node
-
-Restore dos backups
--------------------
-
-Assumindo que o backup criptografado já esteja disponível em `$node:/var/backups/remote/$old.$domain`:
-
-    root@master$ hydractl backup-restore-master $old
-
-Após o restore, o nodo deverá estar pronto para assumir o papel de master.
-
-Atualize seu ~/.ssh/config
---------------------------
-
-Exemplo de configuração pessoal, substituindo as variáveis de acordo:
-
-    Host admin.$domain
-       HostName $node.$domain
-       Port $porta
-
-Assim, independentemente qual seja o nodo master atual, ele sempre estará acessível pelo alias `admin.$domain`,
-evitando mudanças desnecessárias e tediosas em referências de inúmeros repositórios.
-
-Possíveis problemas
--------------------
-
-As seguintes mensagens de erro podem aparecer no novo master depois de sua ativação:
-
-* "You cannot collect without storeconfigs being set": o problema tende a desaparecer conforme os exported resources forem sendo definidos.
-* [Collected resources with a puppet master fail on Ruby 1.9.x](http://projects.puppetlabs.com/issues/10963): basta aplicar o patch manualmente.
diff --git a/rescue.md b/rescue.md
index 055c182..4a3734e 100644
--- a/rescue.md
+++ b/rescue.md
@@ -8,7 +8,7 @@ Um sistema de resgate pode ser útil para a [instalação](/install) de um siste
 Baixando o sistema
 ------------------
 
-Utilizamos imagens `iso-hybrid` do [Debian Live](http://live.debian.net) como base para o sistema de resgate.
+Utilizamos imagens `iso-hybrid` do [Debian Live](https://www.debian.org/CD/live/) como base para o sistema de resgate.
 
 Gravando o sistema
 ------------------
@@ -20,14 +20,14 @@ Criando uma imagem de resgate
 
 Imagens de resgate podem ser criadas usando o [debirf](http://cmrg.fifthhorseman.net/wiki/debirf):
 
-    apt-get install 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-get install live-build
+    apt install live-build
     mkdir live-default && cd live-default
     lb config
     sudo lb build
@@ -37,7 +37,7 @@ Mais informações [aqui](http://live.debian.net/manual/git/html/live-manual.en.
 Habilitando acesso remoto
 -------------------------
 
-    apt-get install openssh-server
+    apt install openssh-server
     ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
 
 Configuração mínima
@@ -49,13 +49,16 @@ Configuração mínima
 Instalando ferramentas básicas
 ------------------------------
 
-    apt-get update
-    apt-get install screen pciutils usbutils git locales
+    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 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:
 
diff --git a/vservers.md b/vservers.md
deleted file mode 100644
index 6a77259..0000000
--- a/vservers.md
+++ /dev/null
@@ -1,81 +0,0 @@
-[[!toc levels=4]]
-
-Linux-VServers num Servidor Debian 
-==================================
-
-Considerando um sistema Debian [instalado de acordo com o padrão](../install), esta seção trata da configuração do ambiente para [Linux-VServers](http://www.linux-vserver.org/).
-
-Criação do volume 
------------------
-
-Para preparar o volume do `/var/vservers`, primeiramente verifique o espaço disponível:
-
-    vgdisplay vg
-
-Como examplo, consideremos uma saída que contenha um `Free PE` equivalente a `232811`, correspondente aos +/-900GB remanescentes no disco. Assim, crie o `/dev/vg/vservers` e comece com a escrita de sujeira no dispositivo:
-
-    lvcreate -l 232811 -n vservers vg
-    dd if=/dev/urandom of=/dev/vg/vservers
-
-Esse procedimento vai demorar umas boas horas (talvez até alguns dias), então basta deixar a máquina ligada até que ele seja concluído e que então seja possível criar o volume criptografado e o sistema de arquivos em `/dev/vg/vservers`.
-
-Criptografia e pontos de montagem
----------------------------------
-
-Após encher o disco com dados aleatórios, proceda com a criptografia do volume:
-
-    cryptsetup -h sha256 -c aes-cbc-essiv:sha256 -s 256 luksFormat /dev/vg/vservers
-    cryptsetup luksOpen /dev/vg/vservers vservers
-    mkfs.ext4 /dev/mapper/vservers
-
-O `/etc/crypttab` deve ganhar uma linha adicional para que o sistema tente descriptografar a partição no boot:
-
-    vservers        /dev/mapper/vg-vservers none            luks,cipher=aes-cbc-essiv:sha256
-
-O `/etc/fstab` também deve ganhar uma linha:
-
-    /dev/mapper/vservers  /var/vservers  ext4  defaults,errors=remount-ro  0 0
-
-Agora basta montar a nova partição:
-
-    mkdir -p /var/vservers && mount /var/vservers
-
-Configurando o ambiente 
------------------------
-
-Preparamos o diretório base dos vservers da seguinte forma:
-
-    rm -f /etc/vservers/.defaults/vdirbase  
-    ln -s /var/vservers /etc/vservers/.defaults/vdirbase
-    setattr --barrier /var/vservers
-
-Criando um VServer 
-------------------
-
-Escolha a configuração:
-
-    export vserver="nome-do-vserver"
-    export project="projeto.org"
-    export context="numero-do-contexto"   # exemplo: 2
-    export network="configuracao-de-rede" # exemplo: eth0:192.168.0.2/24
-    export version="lenny"                # versao do debian
-
-Crie o vserver:
-
-    vserver $vserver build -n $vserver --context $context --hostname $vserver.$project \
-                                       --interface $network -m debootstrap -- -d $version
-
-Agora basta iniciá-lo:
-
-    vserver $vserver start
-
-E instalar os aplicativos básicos:
-
-    vserver $vserver exec apt-get update
-    vserver $vserver exec apt-get upgrade
-    vserver $vserver exec apt-get install lsb-release cron sudo openssh-server locales openssl
-
-Para inicialização automática do vserver durante a inicialização do servidor:
-
-    echo default > /etc/vservers/$vserver/apps/init/mark
-