More organizing

13 files changed, 685 insertions, 0 deletions

diff --git a/provedor/backups.mdwn b/provedor/backups.mdwn
new file mode 100644
index 0000000..88e4173
--- /dev/null
+++ b/provedor/backups.mdwn
@@ -0,0 +1,36 @@
+[[!meta title="Grupo de Trabalho de 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 [http://rsp.sarava.org RSP], 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 [wiki:Backups/Auditagem 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:
+
+  * [wiki:Comunicacao/Politica Política de segurança da informação].
diff --git a/provedor/backups/entrega.mdwn b/provedor/backups/entrega.mdwn
new file mode 100644
index 0000000..860532c
--- /dev/null
+++ b/provedor/backups/entrega.mdwn
@@ -0,0 +1,80 @@
+[[!meta title="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.mdwn b/provedor/cert.mdwn
new file mode 100644
index 0000000..4638698
--- /dev/null
+++ b/provedor/cert.mdwn
@@ -0,0 +1,122 @@
+[[!meta title="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.
+
+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 chaves de acesso, utilizando para isso OpenPGP. Como exemplo, manter uma página pública e atualizada sobre os atuais certificados utilizados e também informar grupos 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.sarava.org/?p=puppet-ssl.git;a=summary 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.mdwn b/provedor/hospedagem.mdwn
new file mode 100644
index 0000000..6f1ecc4
--- /dev/null
+++ b/provedor/hospedagem.mdwn
@@ -0,0 +1,39 @@
+[[!meta title="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.mdwn b/provedor/hospedagem/carta.mdwn
new file mode 100644
index 0000000..e959ff0
--- /dev/null
+++ b/provedor/hospedagem/carta.mdwn
@@ -0,0 +1,71 @@
+[[!meta title="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/plataforma.mdwn b/provedor/hospedagem/plataforma.mdwn
new file mode 100644
index 0000000..993ee1b
--- /dev/null
+++ b/provedor/hospedagem/plataforma.mdwn
@@ -0,0 +1,27 @@
+[[!meta title="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.mdwn b/provedor/hospedagem/politica.mdwn
new file mode 100644
index 0000000..f41d224
--- /dev/null
+++ b/provedor/hospedagem/politica.mdwn
@@ -0,0 +1,47 @@
+[[!meta title="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.mdwn b/provedor/hospedagem/recusa.mdwn
new file mode 100644
index 0000000..cf3eb07
--- /dev/null
+++ b/provedor/hospedagem/recusa.mdwn
@@ -0,0 +1,26 @@
+[[!meta title="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.mdwn b/provedor/hospedagem/termo.mdwn
new file mode 100644
index 0000000..62ecd7e
--- /dev/null
+++ b/provedor/hospedagem/termo.mdwn
@@ -0,0 +1,105 @@
+[[!meta title="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.mdwn b/provedor/servidor.mdwn
new file mode 100644
index 0000000..e8dfa76
--- /dev/null
+++ b/provedor/servidor.mdwn
@@ -0,0 +1,49 @@
+[[!meta title="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 [wiki:Camadas/RSP Resource Sharing Protocol]:

+

+  * `$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 [wiki:PageTemplates/AdministracaoDeServidor Template para Administração de 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.mdwn b/provedor/sistemas.mdwn
new file mode 100644
index 0000000..dc1b1a3
--- /dev/null
+++ b/provedor/sistemas.mdwn
@@ -0,0 +1,41 @@
+[[!meta title="Configuração de sistemas padronizada e centralizada"]]
+
+[[!map pages="page(organizacao/provedor/sistemas*)" show="title"]]
+
+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 [http://rsp.sarava.org Resource Sharing Protocol] (RSP) 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 do [http://reductivelabs.com/trac/puppet/ Puppet], 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 o [http://padrao.sarava.org Padrão Saravá] 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.mdwn b/provedor/sistemas/dns.mdwn
new file mode 100644
index 0000000..76a76d0
--- /dev/null
+++ b/provedor/sistemas/dns.mdwn
@@ -0,0 +1,16 @@
+[[!meta title="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 [wiki:Camadas/Dominios domínios do Coletivo] 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:
+
+* [wiki:Camadas/Dominios Gerenciamento de domínios].
diff --git a/provedor/sistemas/dominios.mdwn b/provedor/sistemas/dominios.mdwn
new file mode 100644
index 0000000..98d2ca8
--- /dev/null
+++ b/provedor/sistemas/dominios.mdwn
@@ -0,0 +1,26 @@
+[[!meta title="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.