Feat: refactor, cleanup and organizedevelop

14 files changed, 0 insertions, 913 deletions

diff --git a/provedor/backups.md b/provedor/backups.md
deleted file mode 100644
index c671152..0000000
--- a/provedor/backups.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Grupo de Trabalho de Backups
-
-```eval_rst
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   backups/*
-```
-
-O presente processo estabelece as linhas gerais de funcionamento de um grupo de
-trabalho responsável pela realização de backups para o Coletivo, cujos
-objetivos são delineados nos critérios que a seguir.
-
-## Preservação
-
-O grupo de trabalho deve manter backups do máximo número possível de
-camadas/instâncias do Coletivo, preservando os critérios de segurança e
-privacidade assim como a Política de Segurança da Informação do Coletivo e
-especialmente o seguinte critério de persistência da informação:
-
-`
-Informações armazenados num determinado nível de acesso ou segurança (exemplo,
-disco criptografado) devem, por padrão, permanecer nesse mesmo nível ou serem
-transferidas para um nível mais seguro, exceto quando constitui informação
-desclassificada e permitida para descer de nível.
-`
-
-Do ponto de vista do [RSP](http://rsp.fluxo.info), o GT de Backups deve
-proporcionar replicação de camadas que preservem (ou que aumentem o nível, se
-possível) suas propriedades de segurança e privacidade no acesso à informação.
-
-## Otimização de parâmetros
-
-O grupo de trabalho deve ainda otimizar os seguintes parâmetros ao propiciar a
-realização de backups:
-
-1. Periodicidade.
-2. Incrementos.
-3. Largura de banda.
-4. Segurança e integridade.
-5. Espaço em disco.
-
-## Auditagem
-
-O grupo de trabalho deve também realizar auditagens periódicas nos backups para
-se certificar de sua realização e, se possível, possuir um sistema automático
-de relatórios de backups.
-
-## Dependências
-
-A realização deste processo depende da realização dos seguintes processos:
-
-* [Política de segurança da informação](/coletivo/comunicacao/acl).
diff --git a/provedor/backups/entrega.md b/provedor/backups/entrega.md
deleted file mode 100644
index c2cfb75..0000000
--- a/provedor/backups/entrega.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# Entrega de backups solicitados
-
-Processo que consiste na entrega de backups solicitados por grupos e pessoas
-hospedadas na infra-estrutura do Coletivo. As tarefas envolvidas consistem em:
-
-1. Obter as solicitações a backups e organizá-las numa tabela, mantendo assim o
-   Coletivo informado sobre o andamento deste processo. Por possivelmente
-   existirem backups de qualidades distintas, é preciso perguntar à parte
-   solicitante, caso necessário, de qual backup os dados precisam ser entegues.
-2. Obter, caso existente, o backup solicitado, realizando uma auditoria caso
-   necessário.
-3. Disponibilizar os backups apenas às pessoas responsáveis pelos ou donas dos
-   dados ou informá-las caso o backup não exista. Informá-las também se o eventual
-   backup foi ou não auditado e:
-  a. Caso tenha sido auditado, disponibilizar, em linhas gerais, o procedimento utilizado.
-  b. Caso não tenha sido auditado, informal qual risco isso representa.
-
-Auditoria do backup
--------------------
-
-Quando necessária, a auditoria básica consiste em:
-
-1. Retirar qualquer código executável que possa ser substituído.
-2. Marcar todo o código executável insubstituível como vulnerável, cuja
-   auditoria é deve ser repassada para o grupo dono do código.
-3. Destruição ou modificação de qualquer senha encontrada, mesmo que a mesma se
-   encontre armazenada de modo cifrado.
-4. Auditagem básica de conteúdo: verificação de datas de acesso e escrita a
-   arquivos, passar anti-virus, etc.
-5. Auditagem avançada de conteúdo, se possível.
-
-Procedimentos mais refinados ficam à cargo da situação e do grupo de trabalho
-de entrega de backups solicitados (composto pelas pessoas responsabilizadas
-pelas tarefas acima mencionadas).
-
-Prazos
-------
-
-O prazo de entrega de backups é proporcional ao tamanho do mesmo e à
-necessidade de auditoria:
-
-* Backups de até 100MB: entrega em até 30 dias.
-* Backups de até 1GB: entrega em até 60 dias.
-* Backups maiores que 1GB: entrega em até 90 dias.
-
-No caso de necessidade de auditoria, o prazo de entrega é duplicado.
-
-Template
---------
-
-    Conforme solicitado, o último backup disponível de $descricao, datado de $data
-    e obtido $origem, já está disponível.
-    
-    Seguem os dados:
-    
-      - URL: https://backups.$dominio/$sitio
-      - Conta: $sitio
-      - Senha: $senha
-    
-    O https://backups.$dominio atualmente usa um certificado SSL
-    auto-assinado, cuja impressão digital é
-    
-      $fingerprint
-    
-    Hashes dos arquivos disponibilizados:
-    
-      md5sum:  $hashes
-      sha1sum: $hashes
-    
-    Auditoria realizada:
-    
-      - Busca e eventual remoção de código executável.
-      - Mudança de senhas em banco de dados (senhas truncadas).
-      - Busca por vírus.
-    
-    Tarefas não-realizadas porém recomendadas:
-    
-      - Checagem do conteúdo do banco de dados (para evitar calúnia ou
-        desinformação)
-      - Checagem do conteúdo dos arquivos.
-      - IMPORTANTE: checagem de usuários para evitar inscrições de
-        elementos estranhos.
-      - Checagem da configurações da instância, caso ela seja reinstalada
-        noutro local.
-      - Limpeza do spam e desativação de todas as contas desconhecidas
-        (principalmente relacionadas a spam).
-    
-    Observações:
-    
-      - Em princípio, não há prazo para a permanência de tal backup
-        no local disponibilizado. No entanto, pode ser que ele precise
-        ser apagado para liberar espaço ou nalgum procedimento de
-        limpeza. Por isso, recomenda-se que sejam baixados o quanto antes.
diff --git a/provedor/cert.md b/provedor/cert.md
deleted file mode 100644
index dcf62a8..0000000
--- a/provedor/cert.md
+++ /dev/null
@@ -1,176 +0,0 @@
-# Gestão de chave e certificado SSL
-
-O presente processo trata da gestão de chave e certificado SSL para conexões
-ditas seguras entre servidores do Coletivo.
-
-Considerações
--------------
-
-O Coletivo reconhece que
-
-1. O protocolo HTTPS possui sérios problemas de design, impedindo por exemplo
-   que diferentes certificados possam ser utilizados num mesmo IP.
-
-2. A indústria da certificação digital representa um sério risco de segurança e
-   uma [imposição tecnocrata](http://lair.fifthhorseman.net/~dkg/tls-centralization/) à
-   utilização prática do HTTPS. Ela recria um domínio cartorial no cyberespaço e
-   pode a qualquer momento [ser utilizada por governos ou corporações para forjar
-   certificados autenticados](http://web.monkeysphere.info/news/internet_secret_backdoor/) e
-   com isso [grampear](https://secure.wikimedia.org/wikipedia/en/wiki/Man-in-the-middle_attack)
-   a conexão entre usuários/as e computadores.
-
-3. Idealmente, a atitude a ser tomada por um coletivo técnico radical deveria
-de não utilizar a indústria da certificação como meio de assegurar a
-identificação de seus serviços e máquinas. Deveria, ao invés disso, utilizar
-apenas esquemas abertos como
-    a. Certificadores Comunitários como o [CACert](http://cacert.org).
-    b. [Monkeysphere](http://web.monkeysphere.info).
-    c. A simples verificação da impressão digital dos certificados mediante
-       algum vínculo direto (por exemplo, troca de fingerprints ou validação via
-       OpenPGP) com os/as administradores das máquinas.
-
-4. No entanto
-    a. Nem todos os navegadores acompanham, por padrão, certificados de
-       entidades comunitárias. É o
-       [caso do CACert](https://secure.wikimedia.org/wikipedia/en/wiki/Cacert#Inclusion_status).
-    b. A adoção de ferramentas livres para HTTPS ainda está muito longe de se
-       tornar comum. No presente, haveria pouca possibilidade de que uma metodologia
-       livre seja eficiente. Ao invés disso, haveria um involuntário incentivo aos/às
-       usuários para que aceitem certificados considerados como inválidos pelos
-       navegadores, o que pode facilitar ainda mais o grampo: se os usuário aceitam
-       qualquer certificado, então não haveria diferença entre eles aceitarem o
-       certificado verdadeiro do falso.
-
-Conclusões
-----------
-
-Portanto, o Coletivo conclui que
-
-1. No momento, ainda importante ter um certificado assinado pela indústria da
-   certificação, isto é, por uma entidade autorizada pelo cartel do SSL.
-3. A autoridade certificadora a ser utilizada deve obedecer alguns critérios básicos:
-  a. Não é diretamente conectada a uma agência governamental.
-  b. Não possui problemas políticos óbvios.
-  c. Cujo certificado raíz não está encadeado com certificados que não satisfazem os critérios acima.
-2. Dada a sua insuficiência, tal certificação corporativa não deve ser o único
-   meio para a validação dos certificados SSL e assim esquemas alternativos como o
-   [Monkeysphere](http://web.monkeysphere.info) devem ser utilizados e
-   encorajados, de modo que haja um aumento da massa crítica necessária para
-   tornar tais métodos mais populares. O mesmo se aplica para a verificação da
-   impressão digital dos certificados.
-
-Utilização de HTTPS
--------------------
-
-Conforme o documento [Best Practices for Online Service
-Providers](https://www.eff.org/wp/osp), o Coletivo concorda que conexões HTTPS
-devem ser utilizadas o máximo possível.
-
-1. O Coletivo utilizará HTTPS apenas em servidores confiáveis que onde seja
-   possível armazenar as chaves SSL de forma criptografada.
-2. Utilizar, quando possível, cabeçalhos
-   [HSTS](http://www.debian-administration.org/article/Enabling_HTTP_Strict_Transport_Security_on_debian_servers).
-2. Considerando que o certificado vale apenas para um único domínio e seus
-   subdomínios (isto é, o domínio principal do Coletivo), o Coletivo utilizará
-   HTTPS por padrão apenas:
-     a. Para serviços, sistemas e sítios que utilizem o domínio principal do
-        Coletivo, quando não houver impedimento técnico para tal.
-     b. Para outros domínios desde que solicitado pela parte hospedada.
-3. Considerar a utilização de [entradas CAA no DNS](https://links.fluxo.info/tags/caa).
-
-Implementação
--------------
-
-A implementação de HTTPS também deve obedecer a uma suite bem estabelecida.
-
-Tal escolha deve desabilitar uma série de cifras ruins e habilitar aquelas que
-provém [Perfect Forward Secrecy
-(PFS)](https://secure.wikimedia.org/wikipedia/en/wiki/Perfect_forward_secrecy).
-
-Outros protocolos
------------------
-
-A utilização do SSL também deve se estender a outras plataformas, como por
-exemplo email (via TLS) desde que possível e que atenda critérios análogos aos
-anteriores.
-
-Escolha de autoridade certificadora
------------------------------------
-
-Dentre as autoridades certificadoras, o Coletivo escolhe a [Gandi](https://gandi.net) por:
-
-1. Atender os critérios acima estabelecidos.
-2. Diferentemente de outras empresas, possui uma preocupação com privacidade e
-   comprometimento com serviços de internet alternativos e independentes.
-2. [Contribuir com projetos de código aberto](https://secure.wikimedia.org/wikipedia/en/wiki/Gandi#Gandi_supports ),
-   vide [lista](http://en.gandi.net/supports/).
-
-No entanto, é importante notar as limitações envolvidas na escolha do Gandi:
-
-    Q: Por que muitos grupos usam GANDI como registrar?
-    R: Porque naqueles tempos (2000), ter seu próprio domínio era tranquilamente
-       de 5 a 10 vezes mais caro do que hoje. GANDI acabou com esses preços
-       introduzindo ofertas muito baratas no mercado. E como em geral temos
-       pouco ou nenhum dinheiro para colocar em projetos, simplemente compramos
-       nossos domínios lá.
-    
-    Q: O que GANDI significa?
-    R: Isso é uma curiosidade, mas GANDI significa "Gestion et Attribution
-       des Noms de Domaines Internet", "Atribuição e gestão de nomes de
-       domínio de Internet". Como empresa, o modelo de negócios era simples:
-       praticamente tudo automatizado, praticamente sem suporte e preços
-       baixos.
-    
-    Q: Por que GANDI é vista como uma organização política?
-    R: Os fundadores originais do GANDI tinham idéias políticas sobre bens
-       comuns e como todo o negócio de nomes de domínio da Internet era
-       baseado em escassez virtual. Um deles até escreveu um livro,
-       "Confessions d'un voleur" ("Confissões de um ladrão") no qual ele
-       descreve extensamente sobre como fez um monte de dinheiro exatamente
-       vendendo algo que não existia e que não havia sentido em vender.
-    
-    Q: Por que GANDI é visto como "descolado"?
-    R: Alguns dos fundadores originais também eram envolvidos na cena
-       alternativa da Internet na França. Parte do dinheiro obtida pelo
-       GANDI ajudou outros projetos, um dos quais o operador sem fins
-       lucrativos Gitoyen.
-    
-    Q: Onde estão esses fundadores agora?
-    R: Em algum outro lugar! Como não foram capazes de concordar em onde
-       o dinheiro deveria ir, os quatro fundadores resolveram vender o
-       GANDI. Eles fizeram isso até por um preço justo. Tentaram vender
-       para pessoas que respeitariam o espírito original, e em certo
-       sentido o fizeram. Parece que o GANDI ainda contribui para
-       projetos de software livre e relacionados, tanto em tempo de
-       trabalho quanto em dinheiro.
-    
-    Q: Devo confiar no GANDI?
-    R: Da mesma forma que você confia em qualquer companhia capitalista.
-       Eles preferirão preservar seu negócio ao invés de ajudar você.
-
-Responsabilização
------------------
-
-O Grupo de Trabalho formado pelas pessoas responsáveis pelo presente processo deve:
-
-1. Caso o Coletivo disponha de recursos financeiros, manter certificado SSL
-   assinado para `*.dominio` via [Gandi](https://gandi.net). O Coletivo arcará com
-   os custos. Caso contrário, adotar a certificação
-   [CACert](http://www.cacert.org/) como padrão.
-2. Manter formas alternativas de certificação via:
-     a. [Monkeysphere](http://web.monkeysphere.info).
-     b. A simples verificação da impressão digital dos certificados mediante
-        algum vínculo direto (por exemplo, troca de fingerprints ou validação via
-        OpenPGP) com os/as administradores das máquinas.
-     c. Manter, na medida do possível, o público informado das mundanças nas
-        haves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página
-        ública e atualizada sobre os atuais certificados utilizados e também informar
-        rupos e pessoas próximas sobre mudanças em certificados.
-3. Opcionalmente, manter também a assinatura via [http://www.cacert.org/ CaCert].
-4. Evitar o vencimento da validade dos certificados, utilizando para isso
-   métodos como o [http://prefetch.net/articles/checkcertificate.html
-   ssl-cert-check], implementado por exemplo no
-   [http://git.fluxo.info/puppet-ssl puppet-ssl].
-5. Observar a aplicação dos critérios e determinações do presente processo,
-   operando conjuntamente com o GT de [wiki:Camadas Configuração de sistemas
-   padronizada e centralizada].
diff --git a/provedor/hospedagem.md b/provedor/hospedagem.md
deleted file mode 100644
index bf8b4ce..0000000
--- a/provedor/hospedagem.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Hospedagem
-
-```eval_rst
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   hospedagem/*
-```
-
-Este processo define os procedimentos de hospedagem do Coletivo. A hospedagem
-de conteúdo e/ou serviços constitui processo formal e é dividida em dois
-níveis:
-
-1. Grupo de trabalho de uma dada plataforma.
-2. Grupo responsável por uma dada hospedagem.
-
-## Necessidade de formalização
-
-Como a hospedagem consiste numa atividade sensível, onde é importante dar
-alguma garantia a quem se hospeda e da mesma maneira ter garantias contra
-possíveis problemas que cada hospedagem pode causar, ambos os níveis devem ser
-estabelecidos como processos formais. Além disso, como parte da implementação
-deste processo, inclusive sítios já hospedados e plataformas existentes deverão
-passar pela formalização.
-
-A hospedagem está sujeita a comprometimentos (do Coletivo e da parte hospedada)
-que satisfaçam a uma Política de Hospedagem do Coletivo.
-
-## Grupo de uma plataforma
-
-Ao grupo de trabalho de uma dada plataforma cabe cuidar do funcionamento,
-manutenção e segurança de uma dada plataforma de hospedagem. Para cada
-plataforma a ser oferecida hospedagem é preciso um grupo de trabalho
-responsável.
-
-A não existência de um grupo de trabalho de uma plataforma não proíbe a
-existência de instalações da plataforma para uso interno do Coletivo, mas
-impede que a hospedagem de terceiros (isto é, de grupos e indivíduos de fora do
-Coletivo) seja realizada.
-
-## Grupo de uma hospedagem
-
-Ao grupo de trabalho responsável por uma dada hospedagem cabe cuidar da
-hospedagem de um dado grupo/indivíduo. Para que seja possível hospedar um grupo
-ou indivíduo numa dada plataforma, é necessário que haja um grupo de trabalho
-em funcionamento para essa plataforma.
-
-O processo formal para cada hospedagem deve conter as seguintes ações:
-
-1. Apresentação do Coletivo (realizada durante a etapa "discussão" do processo)
-   através do envio de sua Carta de Hospedagem.
-2. Apresentação do grupo ou indivíduo a ser hospedado realizada durante a etapa
-   "discussão" do processo).
-3. Decisão:
-   * No caso de aprovação da hospedagem pelo Coletivo e após o processo sido
-     responsabilizado:
-       1. A(s) pessoas(s) responsável(is) pela hospedagem deve(m) enviar o
-          Termo de Comprometimento de Hospedagem e a Política de Hospedagem do Coletivo.
-       2. O coletivo ou indivíduo a ser hospedado deve concordar com o Termo de
-          Comprometimento de Hospedagem, caso contrário a hospedagem não pode ser
-          realizada.
-   * No caso de não-aprovação pelo Coletivo ou falta de responsabilização, o
-     grupo ou indivíduo que seria hospedado deve ser informado da decisão
-     juntamente com o motivo, se possível.
-
-## Responsabilização
-
-Cabe ao grupo de trabalho de uma hospedagem:
-
-1. Aplicar a Política de Hospedagem do Coletivo junto à parte hospedada.
-2. Manter a comunicação entre o Coletivo e a parte hospedada.
diff --git a/provedor/hospedagem/carta.md b/provedor/hospedagem/carta.md
deleted file mode 100644
index 10d7f75..0000000
--- a/provedor/hospedagem/carta.md
+++ /dev/null
@@ -1,73 +0,0 @@
-# Carta de Hospedagem
-
-A Carta de Hospedagem não apenas estabelece as intenções e princípios que o
-Coletivo adota para a hospedagem quanto pode ser utilizada como apresentação
-aos grupos e indivíduos canditatos a hospedagem.
-
-    Carta de Hospedagem do $coletivo
-    --------------------------------
-    
-    O $coletivo é parte de uma intersecção de vários grupos que discutem política e
-    tecnologia de diferentes formas. Partindo disso, trabalhamos com servidores de
-    internet, voltados para distintas finalidades de cooperação. Sendo assim, nossa
-    idéia é colaborar com grupos/projetos que participem de experiências de apoio
-    mútuo e múltiplo.
-    
-    O $coletivo é um projeto autônomo, mantido por um coletivo de voluntários e
-    voluntárias. Um dos nossos principais objetivos é a construção coletiva de
-    espaços públicos, comuns entre diversos projetos e grupos que tenham a intenção
-    de fortalecer e estreitar sua convivência.
-    
-    Nossa intenção não é oferecer um "serviço de hospedagem", por isso não estamos
-    dispostos/as a nos aproximar de grupos que busquem este tipo de serviço.
-    Queremos que os grupos  por nós hospedados colaborem com a construção de uma
-    vizinhança, um rizoma. De tal maneira que a técnica e a tecnologia não sejam
-    impedimento para isso, muito pelo contrário.  Sendo a tecnologia também uma
-    construção social, seus propósitos, sua configuração e os processos nos quais
-    ela interfere não podem prescindir dos desígnios dos grupos sociais onde ela é
-    manipulada.
-    
-    A internet é um ambiente de cooperação, mas também de apropriação e exploração
-    de bens públicos.  Nós entendemos que ela só se torna essencialmente um espaço
-    público na medida em que as pessoas possam controlar seus meios de produção e
-    de acesso, o que não ocorre em espaços corporativos ou governamentais. Por isso
-    buscamos a criação de espaços públicos, não corporativos e não estatais, e
-    esperamos que os grupos por nós hospedados colaborem com a construção desses
-    espaços.
-    
-    Durante a construção de tais espaços, realizamos discussões nas quais tentamos
-    desvendar temas como cultura, sociedade, tecnologia, ativismo, mudanças sociais
-    entre outros. Tais estudos, quando possível, são disponibilizados publicamente.
-    
-    Estudamos as implicações políticas da técnica, desenvolvemos sistemas e
-    instrumentos a partir de outros valores políticos, além de dialogarmos
-    politicamente dentro da lógica cíclica da teoria/prática.
-    
-    Por isso, uma de nossas propostas é o estabelecimento coletivo de uma rede de
-    apoio mútuo entre os grupos e indivíduos interessados em partilhar de uma mesma
-    estrutura para compartilhar seus conhecimentos, atividades desenvolvidas e
-    estudos realizados, de forma a integrar ativamente esta rede.
-    
-    Buscamos, portanto, quebrar com a relação prestador de serviço/cliente, pois
-    não somos prestadores/as de serviço e nem os grupos/indivíduos por nós
-    hospedados são nossos clientes, ambos fazemos parte de uma mesma rede de
-    colaboração onde interesses diversos convergem para o fortalecimento dessa
-    rede, e quem sabe para que esta forma de organização extrapole a própria rede e
-    contamine assim as demais esferas que compõe a sociedade.
-    
-    Pensando na distribuição do conhecimento, e como incentivo a novos grupos
-    interessados em manter sua própria plataforma de servidores, buscamos divulgar
-    o máximo da sistematização de organização.
-    
-    E lembre-se: para nós, @ $coletivo não é apenas um sistema de hospedagem ou um
-    mero provedor de serviços.
-    
-    Links de interesse:
-    
-     - Estudos disponibilizados: http://wiki.$dominio
-     - Configurações e procedimentos operacionais: http://padrao.$dominio
-    
-    Atenciosamente,
-    Coletivo $coletivo
-
-[Versão inglesa](/english/hosting/letter).
diff --git a/provedor/hospedagem/database.md b/provedor/hospedagem/database.md
deleted file mode 100644
index c869bb3..0000000
--- a/provedor/hospedagem/database.md
+++ /dev/null
@@ -1,16 +0,0 @@
-# Checklist para Bases de Dados
-
-* Fundamental:
-  * Backups remotos automatizados.
-  * Acesso web à plataforma apenas via conexão mais segura (https).
-  * Adequação à legislação (LGPD, Marco Civil etc).
-  * Minimizar quantidade de dados pessoais coletados e exibidos ao estritamente necessário.
-  * Acesso restrito para informações pessoais.
-* Recomendado:
-  * Não utilizar "nuvem" corporativa: usar servidor próprio, pois evita o acesso por terceirizados.
-  * Protocolo (acordo comum) sobre o uso da plataforma pelos pesquisadores(as), incluindo aspectos sobre privacidade.
-  * Treinamento básico de segurança e privacidade para administradores(as) e alimentadores(as) do sistema.
-  * Definição sobre licenciamento de dados (direitos autorais) e política de dados abertos.
-* Opcional:
-  * Armazenamento criptografado.
-  * Backups offline.
diff --git a/provedor/hospedagem/plataforma.md b/provedor/hospedagem/plataforma.md
deleted file mode 100644
index 322296e..0000000
--- a/provedor/hospedagem/plataforma.md
+++ /dev/null
@@ -1,45 +0,0 @@
-# Grupo de Trabalho de Hospedagem em $plataforma

-

-O presente processo estabelece o funcionamento do Grupo de Trabalho de

-Hospedagem em `$plataforma` (doravante mencionado apenas como

-'''plataforma'''), consistindo em:

-

-1. Manter instalações atualizadas e em funcionamento da plataforma.

-2. Acompanhar avisos de segurança e atualizações dos aplicativos necessários

-   para o funcionamento da plataforma.

-3. Caso não seja realizado automaticamente, efetuar atualizações de segurança

-   em no máximo '''uma semana''' (incluindo finais de semana e feriados) após as

-   mesmas serem disponibilizadas.

-4. Observar e aplicar os critérios de segurança e privacidade existentes para

-   os/as usuários da plataforma.

-5. Caso possível, atender a pedidos do Coletivo pela instalação adicional da

-   plataforma em locais distintos em virtude de aspectos legais e políticos.

-6. Disponibilizar ao Coletivo informações relacionadas aos procedimentos

-   utilizados pelo grupo de trabalho, manutenções e atualizações que foram ou

-   serão efetuadas.

-

-# Responsabilização

-

-É de responsabilização do grupo de trabalho a realização das tarefas

-anteriormente mencionadas. Não é de responsabilidade do presente grupo de

-trabalho:

-

-1. Manter ou entrar em contato com grupos hospedados.

-2. Prestar suporte aos grupos hospedados. 

-

-Não é de responsabilidade do presente grupo de trabalho:

-

-1. Pelo funcionamento de cada instância da plataforma.

-

-Em outras palavras, o presente grupo de trabalho não se responsabiliza pelo uso

-de cada instância da plataforma, mas sim pelo funcionamento, atualização e

-auditoria das instalações globais da plataforma, isto é, o grupo de trabalho

-não lida com instâncias específicas da plataforma mas sim com a infra-estrutura

-da mesma.

-

-# Sobre este texto

-

-O texto deste processo foi redigido utilizando o [Template para Grupo de

-Trabalho de Hospedagem](/organizacao/misc/plataforma). No caso de alterações

-que não dizem respeito apenas ao Grupo e que possam enriquecer tal template,

-favor submetê-las também upstream, isto é, ao texto do template. 

diff --git a/provedor/hospedagem/politica.md b/provedor/hospedagem/politica.md
deleted file mode 100644
index b6cdd8d..0000000
--- a/provedor/hospedagem/politica.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Política de Hospedagem do Coletivo
-
-    Política de Hospedagem do Grupo
-    -------------------------------
-    
-    1. O Coletivo reserva para si o poder de hospedar ou deixar de hospedar
-       qualquer grupo ou indivíduo a partir dos principios e critérios éticos,
-       politicos e práticos do Coletivo.
-    
-    2. No caso de deixar de hospedar um grupo ou indivíduo, o Coletivo se
-       compromete a avisar a parte hospedada com antecedência e disponibilizar os
-       arquivos envolvidos na hospedagem.
-    
-    3. Grupos e indivíduos só são hospedados pelo Coletivo se mostrarem-se
-       dispostos a uma relação recíproca de troca de conhecimento e atividades.
-    
-    4. Criada a parceria o Coletivo deve ser informado das ações e rumos que cada
-       projeto toma caso afetem o Coletivo, assim como o Coletivo se compromete a
-       informar a parte hospedada de qualquer venha a atingi-la.
-    
-    5. Os termos da parceria devem estar claros no sentido de um comprometimento de
-       ambos os grupos no suporte, manutenção, e desenvolvimento dos sitios e afins
-       que venham a ser criados por conta da hospedagem.
-    
-    6. A parte hospedada se responsabiliza pelo conteúdo do sitio, não cabendo ao
-       Coletivo sofrer as consequências jurídicas de conteúdo impróprio ou ilegal. No
-       entanto, o Coletivo fará o máximo possível para proteger a identidade e a
-       privacidade da parte hospedada.
-    
-    7. As relações devem se dar de maneira mais transparente possível, não
-       existindo informação encoberta ou deturpada por ambas as partes.
-    
-    8. As relações tem como finalidade a solidariedade no conhecimento, a
-       complementariedade nas ações e nas trocas entre os grupos, devendo ser
-       imprescíndivel maneiras de ensino-aprendizagem mútuos e de políticas que unam
-       os grupos em prol de uma mudança sócio-política.
-    
-    9. Coletivo se compromete a informar a parte hospedada ao menos em linhas
-       gerais sobre os critérios e políticas de privacidade e segurança das
-       plataformas de hospedagem utilizadas pela parte hospedada.
-    
-    10. Hospedagens de movimentos sociais com atividades sensíveis no país são
-       encaminhadas, quando possível, a plataformas hospedadas no estrangeiro. 
-    
-    11. A hospedagem consiste em cooperação e não prestação de serviços.
-
-[Versão inglesa](/english/hosting/policy).
diff --git a/provedor/hospedagem/recusa.md b/provedor/hospedagem/recusa.md
deleted file mode 100644
index 6dfa6e3..0000000
--- a/provedor/hospedagem/recusa.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Modelo de carta de recusa de hospedagem
-
-Este é um modelo de carta para recusa de hospedagem, no caso de projetos que
-não concordamos. Para evitar mal entendidos, é importante termos um carta
-ponderada e bem esclarecedora.
-
-    Olá $requisitante,
-    
-    Infelizmente não poderemos hospedar o projeto que você requisitou porque:
-    
-      - Consideramos que ele não se enquadra nos princípios éticos que adotamos[1].
-    
-      - E/ou então consideramos que ele se enquadra nos tipos de projetos com os
-        quais mantemos uma postura crítica[2].
-    
-    Acreditamos que não exista uma única forma de luta e muito menos que a nossos
-    princípios éticos e as nossas críticas representem o ponto de vista "correto".
-    Nosso ponto de vista apenas representa as conclusões que chegamos após muita
-    discussão. Tentamos apenas nos manter coerentes com o que acreditamos e é por
-    isso que não podemos efetuar a sua requisição.
-    
-    Não queremos de modo algum que isso signifique que estamos desmerecendo a
-    atuação do seu projeto ou as coisas que você acredita.
-    
-    [1] Vide http://encontro.sarava.org/Principal/ConjuntoDePrincipiosEticos
-    [2] Vide http://wiki.$dominio
-
-[Versão inglesa](/english/hosting/refusal).
diff --git a/provedor/hospedagem/termo.md b/provedor/hospedagem/termo.md
deleted file mode 100644
index 6826af3..0000000
--- a/provedor/hospedagem/termo.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Termo de Comprometimento de Hospedagem
-
-    Olá :)
-    
-    Termo de Comprometimento de Hospedagem
-    --------------------------------------
-    
-    Discutimos e estamos de acordo em oferecer hospedagem conforme sua requisição.
-    Agora, para que possamos efetivamente manter a hospedagem, é preciso:
-    
-      1. Apresentarmos qual é o nosso comprometimento com relação a essa hospedagem.
-      2. Que você e/ou seu grupo concordem com o presente termo de compromisso e com
-         a nossa Política de Hospedagem.
-    
-    Estes são os termos de compromisso mútuo, onde explicitamos qual será nosso
-    comprometimento com a hospedagem em questão pelo qual a parte hospedada precisa
-    concordar para que seja possível manter tal relação.
-    
-    Caso você concorde com os termos desta carta e aceite nossa Política de
-    Hospedagem, basta responder afirmativamente que sua hospedagem será iniciada
-    logo que possível. :)
-    
-    Nosso comprometimento
-    ---------------------
-    
-    Por essa hospedagem, nos comprometemos a manter a hospedagem em funcionamento.
-    A manutenção da hospedagem ocorre através de trabalho voluntário e responsável.
-    
-    A infra-estrutura utilizada para hospedagem é estável, porém sujeita
-    a eventuais intempéries da rede ou mesmo a problemas mais graves.
-    
-    Por isso, a hospedagem pode ficar fora do ar de vez em quando. Estamos sempre
-    atentos e prezamos pela segurança e integridade dos dados hospedados. Porém,
-    por diversos motivos, não podemos garantir a total disponibilidade ou mesmo a
-    eternidade destes dados.
-    
-    Nos comprometemos, na medida do possível, a manter cópias de segurança dos
-    dados contidos em nossa infra-estrutura. No entanto, pedimos a você que
-    mantenha, também na medida do possível, cópias de seus arquivos.
-    
-    Nosso grupo é formado por pessoas que desempenham uma série de tarefas.  As
-    atividades mais importantes e cruciais, como a hospedagem, dependem de várias
-    tarefas e cada uma delas está associada a um grupo de trabalho de pessoas
-    responsáveis pela sua realização.
-    
-    Mesmo assim, pessoas podem deixar de trabalhar num dado grupo de trabalho e
-    eventualmente alguma tarefa não possa mais ser realizada por falta de um mínimo
-    de pessoas responsáveis por ela.
-    
-    É nesse sentido que garantimos o funcionamento e a realização da hospedagem: de
-    acordo com a força de trabalho disponível no nosso grupo. Por isso, é possível
-    que, no futuro, aconteça de termos que encerrar a hospedagem numa dada
-    plataforma.  Mas, se o fizermos, garantimos que não será da noite para o dia e
-    daremos tempo suficiente para que você e seu projeto possam migrar seus dados
-    para outro local.
-    
-    Nos comprometemos também a informar, mediante solicitação, nossos procedimentos
-    de acordo com nossa política de transparência. Tais procedimentos variam desde
-    características de privacidade e segurança das plataformas utilizadas como
-    também da situação do nosso coletivo.
-    
-    Como nossos procedimentos podem variar ao longo do tempo, convém a você nos
-    solicitar as descrições de procedimentos conforme julgar necessário.
-    
-    Temos nossas limitações mas na medida do possível manteremos as coisas
-    funcionando. :)
-    
-    Seu comprometimento
-    -------------------
-    
-    Esperamos de você e do seu projeto que use o recurso oferecido com sabedoria.
-    Não peça sítios e ferramentas que você deixará abandonadas e, caso você instale
-    seu próprio programa, tenha a responsabilidade de deixá-lo atualizado, uma vez
-    que brechas de segurança no seu espaço podem comprometer outros projetos
-    hospedados.
-    
-    Não se esqueça que a manutenção de um sistema de múltiplos projetos é bastante
-    trabalhosa e dificil de manter segura e por isso pedimos a colaboração de todo
-    mundo. Se puder nos comunicar quando for instalar algum software no seu espaço,
-    ficaríamos muito agradecidos/as :)
-    
-    Interfaces de comunicação e compartilhamento
-    --------------------------------------------
-    
-    Um possível espaço de interação entre os projetos é a Lista da Vizinhança[1]
-    (inscrição apenas para emails seguros, entre em contato para detalhes).
-    Cultive-a! Ao hospedarmos grupos e indivíduos, torcemos para que estes também
-    tornem-se responsáveis por zelar por tais espaços de convivência.
-    
-    Nossa vizinhança é também um local de articulação de rede, onde todos os grupos
-    e indivíduos que compartilham da estrutura por nós mantida se comunicam.
-    
-    Se os temas e estudos com os quais nos preocupamos também os/as inspiram, nós
-    os/as convidamos a participar dessas discussões. Para evitar a centralização
-    das discussões, propomos que vocês os discutam coletivamente, em seus projetos
-    e/ou grupos, tornando público os processos e resultados de tais discussões.
-    Para nós é fundamental tentar construir uma metodologia que possibilite a
-    disseminação pública de tais discussões.
-    
-    [1] $endereco_da_lista_da_vizinhanca
-    
-    Em solidariedade,
-    Coletivo $grupo
-
-[Versão inglesa](/english/hosting/terms).
diff --git a/provedor/servidor.md b/provedor/servidor.md
deleted file mode 100644
index b1415af..0000000
--- a/provedor/servidor.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Administração do $servidor

-

-Este processo estabelece os critérios de administração do `$servidor`,

-doravante mencionado como `$servidor`, canalizador de fluxos ou simplesmente

-como servidor.

-

-# Classes RSP

-

-O servidor deve estar configurado de acordo com as seguintes classes do

-[Resource Sharing Protocol](https://rsp.fluxo.info):

-

-* `$classe` - `$classe_versao`.

-

-# Política de Administração

-

-0. Criação de Usuários:

-   a. Qualquer integrante do Coletivo pode ter uma conta no servidor, mas caso

-      tenha deve zelar pela segurança da mesma e concordar com a presente política.

-   b. A criação de usuários no servidor deve ser comunicada ao Coletivo e

-      seguir eventuais procedimentos existentes.

-   c. A senha da conta no servidor não pode ser compartilhada com outras contas

-      e deve ser razoavelmente forte.

-   d. Em caso de perda ou roubo de senha, o Grupo de Trabalho do servidor deve

-      ser contatado o quanto antes.

-

-1. Configuração: ao instalar ou efetuar qualquer tipo de configuração na máquina, procure:

-   a. Adicionar, se possível e/ou necessário, a configuração em sistema de

-      gestão servidores que o Coletivo utiliza.

-   b. Documentar os procedimentos utilizados ou informe ao Grupo de Trabalho do servidor.

-

-3. Comunicação: na medida do possível, comunique o Grupo de Trabalho do

-   servidor sobre alterações feitas na sua configuração configuração.

-

-# Quota

- 

-O Coletivo alocará para si, em princípio, um limite garantido de `$disco` de

-espaço em disco no servidor. Toda a quantidade adicional de disco existente no

-servidor pode ser disponibilizada para outros grupos afins, mediante processo

-formal e sem garantias de backup.

-

-Quotas de uso de banda, processamento e memória ficam a cargo do Grupo de

-Trabalho do servidor ou de todo o Coletivo conforme necessidade ou mediante

-requisição.

-

-# Responsabilização

-

-Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis por este processo

-seguir a política de administração e ainda:

-

-* Zelar para que o servidor possua o nível de segurança, privacidade e

-  estabilidade escolhidas.

-* Cuidar para que o downtime do servidor não passe de `$downtime`.

-* Efetuar as atualizações de softwares necessárias para o funcionamento básico

-  do servidor.

-

-A responsabilização neste processo não implica o compromisso com a

-administração de todas as camadas, aplicações, configurações e dados que

-existam ou possam existir no servidor, mas apenas com o funcionamento básico do

-servidor.

-

-# Dependências

-

-A realização deste processo depende da realização dos seguintes processos: 

-

-* `$dependencia`.

-

-# Sobre este texto

-

-O texto deste processo foi redigido utilizando o [Template para Administração

-de Servidor](/provedor/servidor). No caso de alterações que não dizem respeito

-apenas ao Grupo e que possam enriquecer tal template, favor submetê-las também

-upstream, isto é, ao texto do template. 

diff --git a/provedor/sistemas.md b/provedor/sistemas.md
deleted file mode 100644
index 4e076ab..0000000
--- a/provedor/sistemas.md
+++ /dev/null
@@ -1,72 +0,0 @@
-# Configuração de sistemas padronizada e centralizada
-
-```eval_rst
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   sistemas/*
-```
-
-O presente processo estabelece o funcionamento de uma configuração de sistemas
-padronizada e centralizada. Levando em conta que o Coletivo pode lidar com
-muitas camadas de canalização informacional, cada um com diversos serviços
-configurados, backups locais e remotos e outras especificidades, torna-se
-interessante desenvolver um esquema de configuração centralizada, de forma a
-tornar fácil a manutenção, replicação e substituição dos ambientes assim como o
-compartilhamento de configurações com outros grupos.
-
-## Divisão de configuração e compartilhamento
-
-A configuração dos sistemas é dividida da seguinte forma:
-
-1. Especificação de camadas via [Resource Sharing Protocol
-   (RSP)](https://rsp.fluxo.info) de acordo com as necessidades e possibilidades
-   do Coletivo.
-2. Configuração efetiva dos sistemas através de aplicação especializada.
-
-## Compartilhamento de configurações
-
-No que concerne ao compartilhamento das configurações, a seguinte divisão é
-utilizada:
-
-1. Repositório privado, de acesso restrito ao Coletivo e contendo informações e
-   configurações cuja publicização é prejudicial ou desnecessária do Coletivo.
-2. Repositório público de configurações, denominado de
-   [http://padrao.sarava.org Padrão Saravá], contendo as configurações cuja
-   publicização auxilia no intercâmbio com outros grupos.
-
-Ambos os repositórios devem utilizar controle de versão e o Coletivo ainda é
-encorajado a utilizar configurações disponibilizadas por outros grupos, unindo
-assim esforços para a economizar trabalho.
-
-## Implementação
-
-A configuração efetiva deve ser obtida através do uso de um sistema como o
-[Puppet](http://puppetlabs.com), por ter diversos módulos disponíveis, uma
-linguagem de configuração bastante flexível e uma comunidade próxima que já o
-utiliza.
-
-As seguintes características de implementação devem ser satisfeitas:
-
-1. O repositório e o servidor `puppetmaster` devem rodar a partir de uma
-   instância cuja configuração de camadas é a mais segura do Coletivo e os dados
-   devem estar disponíveis somente via conexão segura.
-2. O repositório '''deve''' ter backups em diversos locais.
-3. O controle de versão utilizado para os módulos e demais configurações do `puppet` é o `git`.
-4. O `puppet` deve estar rodando no maior número possível de camadas do
-   Coletivo e obtendo suas configurações do `puppetmaster`.
-
-## Responsabilização
-
-É tarefa do Grupo de Trabalho de Configurações, composto pelas pessoas
-responsáveis pelo presente processo:
-
-1. Manter o máximo possível de configurações de sistemas do Coletivo segundo os
-   critérios estabelecidos no presente processo.
-2. Realizar auditoriais periódicas (com base anual) seguida relatório e
-   atualização da configuração dos sistemas conforme necessário.
-3. Manter um [padrão de configuração](https://padrao.fluxo.info) atualizado e
-   em funcionamento.
-4. Alterar, na medida do possível, a configuração dos sistemas e documentações
-   relacionadas conforme solicitações do Coletivo.
diff --git a/provedor/sistemas/dns.md b/provedor/sistemas/dns.md
deleted file mode 100644
index 14404d5..0000000
--- a/provedor/sistemas/dns.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# Administração de configurações de DNS dos domínios do Coletivo
-
-Este processo estabelece as linhas gerais para a administração de configurações
-DNS dos domínios do Coletivo.
-
-# Tarefas
-
-Cabe ao Grupo de Trabalho formado pelas pessoas responsáveis pelo presente
-processo:
-
-1. Manter a configuração de DNS dos domínios do observando os critérios de
-   segurança cabíveis.
-2. Atender as requisições do Coletivo de mudanças de configuração de DNS.
-
-## Dependências
-
-A realização deste processo depende da realização dos seguintes processos:
-
-* [Gerenciamento de domínios](/provedor/sistemas/dominios).
diff --git a/provedor/sistemas/dominios.md b/provedor/sistemas/dominios.md
deleted file mode 100644
index a002e5b..0000000
--- a/provedor/sistemas/dominios.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Gerenciamento de domínios
-
-Os domínios utilizados pelo Coletivo constituem seu ''namespace'' no qual podem
-definir endereços de acesso público e privado. Sendo indispensáveis para a
-autonomia básica do Coletivo e para a possibilidade de hospedagem de outros
-grupos, o gerenciamento de domínios constitui um processo de garantia dessa
-autonomia, especialmente se levado em conta que o DNS é um sistema
-centralizado, pouco transparente, anti-democrático e de tendência
-centralizante.
-
-O presente processo estabelece um grupo de trabalho para o gerenciamento de
-domínios, cujas tarefas envolvem:
-
-1. Renovação dos domínios com '''antecedência''' ao prazo de vencimento da
-   mesma, solicitando ao grupo de contabilidade os gastos necessários para cumprir
-   tal tarefa. 
-2. Aplicação de política de privacidade e segurança à configuração dos
-   domínios, incluindo auditoria periódica para a verificação dessas
-   configurações.
-3. Registro de novos domínios conforme a necessidade e formalização pelo Coletivo.
-4. Manter o Coletivo informado sobre essas tarefas.
-
-## Responsabilização
-
-As pessoas responsabilizadas por esse grupo de trabalho precisam ter condições
-de realizar operações financeiras internacionais com cartão de crédito.
-
-## Domínios do Coletivo
-
-Os domínios do Coletivo são:
-
-* domínio1
-* domínio2
-
-Vale observar que:
-
-1. Outros domínios podem ser adicionados na lista mediante procedimento formal
-   para a alteração da mesma.
-2. Por esse processo fica automaticamente aprovado o gasto de recursos
-   financeiros do Coletivo para o pagamento da renovação/registro dos domínios do
-   Coletivo.