diff options
Diffstat (limited to 'doc/hidra.markdown')
| -rw-r--r-- | doc/hidra.markdown | 764 |
1 files changed, 764 insertions, 0 deletions
diff --git a/doc/hidra.markdown b/doc/hidra.markdown new file mode 100644 index 0000000..b620443 --- /dev/null +++ b/doc/hidra.markdown @@ -0,0 +1,764 @@ +Title: O Processo Hidra +Author: Silvio Rhatto +Generator: S9 + +%css + +body { + font-family: monospace; +} + +.centered img { + display: block; + margin-left: auto; + margin-right: auto; +} + +.centered { + text-align: center; +} + +p, li, dt, dd, td, th { + font-size: 16pt; +} + +.slide h1 { + font-size: 25pt; +} + +%end + +!SLIDE centered + + + +O Processo Hidra +================ + +<div class="centered" markdown="1"> + + +De relógios a nuvens, de nuvens a hidras. +</div> + +Parte 1: Introdução +=================== + +Objetivo da apresentação +======================== + +O objetivo desta fala é divulgar os estudos em andamento sobre o processo hidra dando espaço para possíveis andamentos: + + 1. Informar os grupos e pessoas que possuem conteúdo hospedado em infraestruturas tecno-sociais comuns sobre o trabalho desenvolvido. + + 2. Encorajar grupos técnicos existentes para adotarem procedimentos que favoreçam suas infraestruturas a terem comportamento hidra. + +Esta apresentação ainda está em processo de concepção e revisão e por isso não está sendo divulgada. + +O que é uma Hidra? +================== + +Ser mitológico de múltiplas cabeças regenerativas, destruído por Hércules +========================================================================= + +<div class="centered" markdown="1"> + +</div> + +Na biologia moderna, animal aquático que possui capacidades regenerativas +========================================================================= + +<div class="centered" markdown="1"> + +</div> + +O que é o Processo Hidra? +========================= + +O Processo Hidra é uma descrição de infraestruturas tecno-sociais que apresentam: + + 1. Replicabilidade e escalabilidade. + + 2. Capacidade de combinação rizomática. + + 3. Regeneração e reagrupamento após eventos catastróficos. + +A Hidra moderna pode resistir a Hércules. + +Parte 2: Grupos Técnicos Sociais +================================ + +Mas antes façamos uma retrospectiva... + +Sistemas informacionais sociais +=============================== + +Modelo "clássico" de hospedagem: arquitetura "cliente-servidor": + +<div class="centered" markdown="1"> + +</div> + +Trabalho técnico informacional em grupos sociais +================================================ + +Características: + + - Considerado tecnicamente de alta dificuldade e dedicação. + + - Esforço para provisionamento, configuração e manutenção de sistemas. + + - Trabalho demorado: escala de meses para alcançar estabilidade. + + - Suscetível a muitas falhas: escala de horas para que um sistema seja inutilizado. + + - Pouco tempo disponível para o trabalho. + + - Dificuldade para a realização de backups e manutenção de procedimentos administrativos. + + - Baixa mobilização e força de trabalho "tarefeira". + + - Custa um bom dinheiro... + +Interlúdio: a destruição das redes +================================== + + + + +A cada evento catastrófico, vários grupos são prejudicados com danos à comunicação de difícil cicatrização. + +Parte 3: Contra-ataque infraestrutural +====================================== + +Como impedir que uma rede seja destruída mesmo que a remoção de nodos continue? + +A divisão em camadas +==================== + +Observação crucial: + + "Ghost in the shell": o disco e o hardware são intercambiáveis, + provisionamento pode ocorrer em múltiplas etapas. É possível + manter um estoque de discos pré-instalados e uma reserva financeira + para a aquisição de máquinas. Isso e backups permite a reconstrução + de sistemas. + +Conclusão imediata: + + É necessário "descolar" a camada de serviços (web, streaming, email, + etc) da camada infraestrutural (máquinas, conexões, etc): filtragem + de problemas físicos e jurídicos. + +A camada de serviços pode então ser "congelada" na forma de backups, enquanto que a camada infraestrutural não possui "alma" intrínseca, podendo ser reconfigurada quando necessário. Desse modo, várias máquinas podem ser mantidas no ar para aumentar a tolerância a falhas. + +Mas como um sítio pode estar simultaneamente em várias máquinas? + +DNS: colando domínios em máquinas +================================= + + + + +O colamento/descolamento entre camadas é possível mediante mudanças de DNS. + +Proxies: distribuindo um sítio entre máquinas +============================================= + +<div class="centered" markdown="1"> + +</div> + +Aplicação descentralizada ou distribuída +======================================== + +<div class="centered" markdown="1"> + +</div> + +Tipos de camadas +================ + +Informação de um sistema é dividida conforme sua aplicabilidade: + + - Hardware: manifestações cristalizadas de informação: computadores. + + - Programas (software): pacotes. + + - Configuração (módulos). + + - Chaves e senhas. + + - Dados (o conteúdo propriamente dito). + +Tais camadas podem ser empacotadas em sistemas e tais sistemas podem ser agregados em outros sistemas (camadas de camadas de camadas): pode ser uma abstração complicada, mas o ganho conceitual em isolamento de instâncias é importante. + +Problemas +========= + +O discurso é bonito, porém... + + 1. Hardware é muito heterogêneo para padronizações serem efetivas. + + 2. Os programas são muito diversos para serem estudados, integrados e desenvolvidos. + + 3. Configurações são muito complexas e numerosas para serem facilmente separadas e replicadas de forma genérica. + + 4. São necessárias muitas senhas de boa complexidade, o que torna sua manutenção complicada. + + 5. Backups são difíceis de serem realizados e recuperados. + +Ou seja: o discurso da divisão em camadas é interessante, porém na realidade sua implementação enfrenta diversos problemas. Serão eles impeditivos? + +O Plano R* +========== + + + + +O Plano R*: email +================= + +<div class="centered" markdown="1"> + +</div> + +Como é possível? +================ + +O segredo está na articulação da força de trabalho com a divisão de camadas. A regra geral é: + + 1. Utilização de ferramentas sólidas e amplamente utilizadas por comunidades de software livre e aberto. + 2. Trabalho de desenvolvimento focado na integração de soluções existentes, enviando alterações em código corrente acima sempre que possível. + 3. Desenvolvendo código próprio, porém livre, apenas quando não existente ou insuficiente nas comunidades. + +Cada um desdes tipos informacionais é distribuído em unidades que por sua vez são agregados em árvores: + + - Hardware em servidores (canalizadores de fluxos, nodos ou instâncias em nuvens). + - Programas em pacotes e distribuições. + - Configurações em módulos e repositórios. + - Chaves (que são unidades de segredo) em repositórios. + - Dados em árvore de backups. + +Divisão artefática +================== + +A divisão em camadas é artificial (artefática), porém com importantes consequências quando observada à luz da divisão do trabalho de comunidades de software livre e aberto: + + /'\ | + | \./ + upstream downstream + + - Hardware: desenvolvimento caro e complexo; hardware livre e aberto engatinhando; dependência do mercado. Exemplo: disco rígido. + - Programas e distribuições: grandes comunidades de desenvolvimento e uso. Exemplo: GNU/Linux, Debian. + - Configuração: comunidades mais restritas de desenvolvimento e uso. Exemplo: manuais, howtos, módulos. + - Chaves e senhas: restrita ao grupo responsável por manter uma dada infraestrutura. Exemplo: senha de superusuário/a. + - Dados: desenvolvidos pelas pessoas e grupos hospedados. Exemplo: texto num wiki. + +Divisão artefática - 2 +====================== + +É possível reconstruir um sistema dados esses elementos. A divisão do trabalho upstream/downstream é favorável à reconstrução, já que as tarefas se tornam mais complexas ao longo da subida da corrente onde usualmente os grandes grupos sociais se reúnem para solucioná-las. + +Economia de trabalho +==================== + +Assim, é possível economizar muita força de trabalho. + + 1. Enviar um desenvolvimento corrente acima (upstream) libera o grupo técnico de uma manutenção posterior, pois o trabalho passa a ser de responsabilidade da comunidades mais ampla. + + 2. Quanto mais específica for a informação, mais abaixo da corrente (downstream) ela deve ser mantida. + + 3. Naquilo que não houver desenvolvimento corrente acima, atuar como fonte (ou seja, agir como upstream) e fornecer para a comunidade. + +Tipos de salvaguarda +==================== + +Para todas as camadas divididas anteriormente é possível criar algum tipo de salvaguarda contra perdas: + + - Dinheiro: armazenamento e replicação de força de trabalho (potencial de trabalho armazenado). + + - Estoque: hardware hoje é commodity, podendo ser minimamente estocado ou mantido online em diversos locais. + + - Repositórios: programas, pacotes, distribuições e configurações. + + - Backups: manutenção de dados ou coisas sobressalentes. + +Parte 3: contexto brasileiro +============================ + +Orçamento e infraestrutura +========================== + +Custos: + + - Plano R*: EUR 10.000 anuais. + - No Brasil, é praticamente a despesa anual de um centro social alugado e muito mais do que a receita da maioria dos grupos. + +Conexão: + + - Nos EUA e na Europa, a conexão é rápida e barata. Datacenters corporativos são acessíveis. + - No Brasil, a conexão é lenta, cara e o preço dos datacenters é exorbitante. + +Repressão: + + - Criminalização dos movimentos sociais (entulho jurídico). + - Polícia violenta. + +Estaremos impossibilitados/as de mantermos servidores no país? + +Por outro lado +============== + + - A legislação, a jurisprudência, cultura e valores brasileiros são muito mais favoráveis à preservação da privacidade que nos EUA ou na Europa (fator Dantas). + + - Honorários advocatícios não são tão altos quanto no exterior (?). + + - O câmbio é favorável a doações internacionais. + +O caso Satangoss +================ + +"O que demorou quatro anos para juntarmos nos foi arrebatado num único dia." + + - Agosto de 2008: polícia civil apreende o servidor do Saravá sem mandado judicial. + + - Mais de cem sítios fora do ar. + + - Não havia backup remoto e nem medidas de contingência estabelecidas. + + - Todos os ovos estavam na mesma cesta. + + - Grande desmobilização. + + - Análise do caso: http://www.sarava.org/node/44 + +Como reverter a crise num novo ciclo de mudança e amadurecimento? + +Parte 4: O Processo Hidra +========================= + +<div class="centered" markdown="1"> + +</div> + +Regeneração +=========== + +Hidra: toda célula pode ter o germe da própria organização. Múltiplas cabeças, células tronco que podem adquirir especialização conforme a necessidade. + +<div class="centered" markdown="1"> + +</div> + +Hidra em processo +================= + +<div class="centered" markdown="1"> + +</div> + +Hidra em processo - 2 +===================== + +<div class="centered" markdown="1"> + +</div> + +%% Hidra em processo - 3 +%% ===================== +%% +%% +%% +%%Fonte: http://odelberglab.genetics.utah.edu/regen_mech.htm + +%% Arredondamento de aglomerados celulares: +%% ======================================== +%% +%% http://hal.archives-ouvertes.fr/docs/00/02/92/51/PDF/rounding_revised.pdf + +Topologias +========== + + "[To] keep our sources safe, we have had to spread assets, encrypt everything, + and move telecommunications and people around the world to activate protective + laws in different national jurisdictions," Mr Assange said told the BBC earlier + this year. + +Fonte: [http://www.bbc.co.uk/news/world-11047811](http://www.bbc.co.uk/news/world-11047811) + +Possíveis montagens: anel, estrela, rizomática, etc. Frontends e backends. + +Parte 5: O Processo Hidra Saravento +=================================== + + 1. Apresenta Padrão Saravá (Sarava Pattern, [http://padrao.sarava.org](http://padrao.sarava.org)). + + 2. Utiliza Resource Sharing Protocol (RSP, [http://rsp.sarava.org](http://rsp.sarava.org)). + + 3. Considerando a adoção de padrões definidos de política de segurança e privacidade. + + 4. Organiza-se de acordo com protocolos ([http://protocolos.sarava.org](http://protocolos.sarava.org)). + +Na Hidra Saraventa, cada célula é chamada de "nodo": + + - Nodos físicos com servidores virtuais com fins específicos. + + - Nodos virtuais em diversos locais (inclusive hospedados por terceiros). + +Baseada no seguinte pricípio: quais problemas solucionaremos, quais não. + +O Padrão Saravá +=============== + +O Padrão Saravá é uma sistematização de configuração de servidores, gerenciadores de conteúdo e aplicações diversas usados pelo Grupo Saravá. O padrão foi desenvolvido para: + + - Ter controle dos pacotes utilizados, arquivos de configuração e serviços em uso. + + - Uniformidade de administração. + + - Sistema de gerenciamento de backups comum para que as máquinas de um projeto possam trocar dados. + + - Que um servidor seja configurado apenas uma vez e que suas configurações possam ser aproveitados para outras máquinas. + + - Que sites e serviços sejam armazenados de maneira regular para facilitar atualizações e migrações. + + - Manter projetos e serviços isolados uns dos outros através de servidores virtuais. + + - Tornar a instalação dos servidores facilmente replicável. + +Dinâmica de desenvolvimento: + + Documentação wiki -> Configurações pré-gravadas -> Software + +Puppet +====== + + + + +Puppet: compartilhando configuração +=================================== + +Código puppet: + + file { '/etc/passwd': + owner => root, + group => root, + mode => 644, + } + +Módulos compartilhados: + + - [http://git.sarava.org](http://git.sarava.org) + + - [https://labs.riseup.net/code/projects/sharedpuppetmodules](https://labs.riseup.net/code/projects/sharedpuppetmodules) + +Git e gitosis +============= + + + + +O Protocolo de Compartilhamento de Recursos +=========================================== + + "The Resource Sharing Protocol (RSP) is a set of metadata intended to help free + software groups + + * Share their available resources and also Find groups that can host + * services for them given their needs and requirements. + + The RSP splits each resource in a layer or set of service layers. You can think + of service layers something very general, ranging from servers, databases, + websites. If you need to, you can even consider stuff such as tables and + bicycles as layers that provide some kind of service to a hosted group. ;)" + + -- http://rsp.sarava.org + +Orquestração +============ + +Para complementar a Configuração de sistemas padronizada e centralizada, procedimentos como + + 1. Atualização de pacotes. + 2. Atualização de código de gerenciadores de conteúdo. + 3. Carga de bancos de dados. + +podem ser codificados de forma a serem facilmente aplicados a múltiplas camadas de forma simultânea. + +Exemplos: + + - [https://git.sarava.org/?p=hydra.git;a=summary](https://git.sarava.org/?p=hydra.git;a=summary) + - [http://www.capify.org](http://www.capify.org) + - [http://marionette-collective.org](http://marionette-collective.org) + - [https://fedorahosted.org/func](https://fedorahosted.org/func) + - [http://fabfile.org](http://fabfile.org) + - [http://www.debian-administration.org/article/Automating_ssh_and_scp_across_multiple_hosts](http://www.debian-administration.org/article/Automating_ssh_and_scp_across_multiple_hosts) + +Ikiwiki +======= + +O Ikiwiki ([http://ikiwiki.info](http://ikiwiki.info)) é um software de wiki que usa um sistema de controle de versão e arquivos de texto, possibilitando: + + 1. A existência de múltiplas cópias integrais do wiki (online e offline). + 2. Desenvolvimento distribuído de documentação. + +O ikiwiki é muito útil para reunir documentação de sistemas, já que não necessita de nenhum sistema web funcional para abrigá-la. + +Virtualização +============= + +Virtualização através de Linux-VServer (existem outras implementações possíveis): + + - [http://www.linux-vserver.org](http://www.linux-vserver.org) + - [http://slack.sarava.org/vservers](http://slack.sarava.org/vservers) + +Principais vantagens: + + - Permite diversos grupos compartilharem uma mesma máquina presevando sua autonomia. + + - Grupos podem hospedar mutuamente instâncias virtuais. Exemplo: se existem 5 grupos com uma máquina cada um, se cada um deles hospedar um vserver para cada grupo, teremos 4 locais remotos de hospedagem por grupo, aumentando assim as possibilidades de salvaguarda e escalabilidade. + +Keyringer e monkeysphere +======================== + +O Keyringer ([http://git.sarava.org/?p=keyringer.git;a=summary](http://git.sarava.org/?p=keyringer.git;a=summary)) é um repositório distribuído de senhas/chaves baseado em GPG e git. + +O monkeysphere ([http://web.monkeysphere.info](http://web.monkeysphere.info)) é um programa que permite a verificação de hosts SSH e usuários/as através da Teia de Confiabilidade do OpenPGP. Com ele, o gerenciamento de fingerprints fica mais fácil e evita que páginas como esta centralizem informações que possam se desatualizar. + +Tecnologia bootless +=================== + +Muitos esquemas de criptografia em disco se baseiam na proteção das partições de dadados e da área de troca, porém dependem da existência de ao menos uma partição de inicialização com as imagens do sistema e de um setor de inicialização. + +Com acesso físico à máquina, é possível infectar tais dados de inicialização e comprometer a criptografia de todo o sistema. + +Para mitigar a situação, o esquema Bootless é um repositório git que contém as imagens de inicialização e a configuração necessárias para o procedimento de partida. + +Assim, é possível manter a parte de inicialização fora da máquina, por exemplo em chaveiros USB. + +Projeto similar: [http://lfde.org](http://lfde.org) + +Monitoramento: nagios +===================== + +<div class="centered" markdown="1"> + +</div> + +Monitoramento: munin +==================== + +<div class="centered" markdown="1"> + +</div> + +%% +%%Fonte: [http://exchange.munin-monitoring.org/plugins/icecast2/details](http://exchange.munin-monitoring.org/plugins/icecast2/details) + +Backups +======= + +Estratégia: + + 1. Backups locais criptografados com duplicity: + - Incluindo apenas `/etc`, `/var`, `/home`. + - Excluindo logs, cache e backups remotos. + 2. Backups remotos apenas do backup local em duplicity, via rdiff ou rsync. + 3. Nodos designados para armazenamento de backups. + 4. Incrementos locais e remotos para aumentar consistência dos dados. + 5. Procedimento integrado de restore e ativação de nodo. + +Hardware e custos +================= + + - Servidor mini-ITX Atom dual core + 2GB RAM + 1TB: R$680.00. + - Nobreaks APC: +/- R$500,00. + - Banda larga ADSL/cabo: R$80,00 a R$200,00. + - Energia: 180W (mini-ITX) máx. + - Sistema pode ser instalado inclusive em memórias de estado sólido (microSD por exemplo). + +<div class="centered" markdown="1"> + +</div> + +Utilidades: adaptador para discos +================================= + +<div class="centered" markdown="1"> + +</div> + +Utilidades: chave de entropia +============================= + + + + +Segurança +========= + +Acesso remoto: + + - Contas SSH administrativas em todos os nodos. + + - Contas SSH de backup para nodos de backup. + + - Contas SSH de tunelamento para nodos diversos. + +Análise: + + 1. É importante isolar o máximo a capacidade de acesso para contas de nodos de backup ou que tunelem conexões. + + 2. Administradores/as precisam ter boas medidas de segurança: + - Pasta criptografada. + - Senhas e chaves seguras. + +Protocolos sociais +================== + + - Protocolo de Ação Coletiva: [http://protocolos.sarava.org](http://protocolos.sarava.org). + - Outros protocolos e metodologias (contabilidade, acesso à informação, relação com grupos, etc). + - Uso de um sistema de gestão de processos (trac ou similar). + + .------------------->-----------------. + / .----------<--------------<-------. \ + | ' \ \ + | | .------>-----. \ \ + | | | \ \ \ + Proposta -----> Discussão ->--. \ \ \ + | ^ | \ \ \ \ + | | | \ \ \ \ + | `----<-----' | \ \ \ + | | | \ \ + `------>------ Decisão --<--' | \ \ + | | | \ \ + | | | | | + Atribuição de --<---' '---> Arquivamento --->---' ; + Responsabilidades ----->-------' ^ \ / + ^ | ___________/ `---<-----' + | \ .' + | `--> Realização -->--. + | | | \ + | | | / + `----<-----' `-----<---' + +Resumo: Estratégia de gestão +============================ + + - Facilitar instalação, manutenção e gestão de dados. + + - Manter backups em máquinas prontas para serem inicializadas. + + - Manter nodos master prontos para assumirem o posto de "cabeça ativa". + +Parte 6: A Confederação das Hidras Unidas +========================================= + +<div class="centered" markdown="1"> + +</div> + +A Confederação das Hidras Unidas +================================ + + - Hidra é um processo, não uma tecnologia, implementação, sistema ou serviço. + + - Assim, é possível ter hidras menos sistematizadas e com diferentes formas de organização. O processo já ocorre em vários locais. + + - Havendo várias hidras, se elas se integram passa a existir a Confederação das Hidras Unidas. + + - Importante questão do licenciamento: AGPL 3.0 para garantir o máximo possível da disponibilização de código e documentação. + + - Não é estritamente necessária a criação de uma "confederação", já que a cultura de hidras pode ser não-coordenada. + +Parte 7: Nuvens e Hidras +======================== + +Hidras são nuvens (cloud computing)? + + - Cloud computing foca apenas nas instâncias e como estas são integradas por aplicações (IaaS, SaaS, PaaS) e no seu uso sob demanda. + + - Cloud computing é uma iniciativa do mercado e uma tendência à terceirização total das atividades. + + - A Hidra leva em consideração a organização social que suporta a infraestrutura computacional. + + - A Hidra é uma nuvem na qual certos nodos desempenham papéis determinados, porém contendo o germe de toda a organização. + + - Outra classe de nuvens: botnets. + +Nuvens: diagramas +================= + + + + +Tipos de nuvens +=============== + +<div class="centered" markdown="1"> + +</div> + +Parte 8: Futuro +=============== + + - Hidra Saraventa: ainda em intenso desenvolvimento, porém já em estágio maduro. Falta (em agosto/2010): + - Melhoria no procedimento de bootstrap. + - Integração com DNS. + - Sistema de proxy para balanceamento de carga. + - Melhoria de procedimentos de sunsetting de sítios, plataformas e contas. + - Longuíssimo prazo, caso realizável: possibilidade de um nodo ser convertido de uma classe para outra. + - Procedimentos para suporte jurídico. + - Nodos em conexões DSL e cabo: IP dinâmico, DNS reverso, etc. + - VPN entre os nodos, Puppet Dashboard?, External node tool? + - Migrar para Linux Containers (lxc). + - Melhoria da documentação e representações gráficas do processo. + - Storage de dados distribuído. + - Hidras via Rádio. + - Hidras em outros tipos de organizações sociais. + +Parte 9: Conclusões +=================== + + - Resolver a replicação e escalabilidade primeiro na infraestrutura (máquinas, configurações e backups), depois nas camadas superiores (CMSs, por exemplo) + + - Não importa tanto se a rede é centralizada, descentralizada ou distribuída se antes de tudo ela for regenerativa. No entanto, em geral são as redes distribuídas e descentralizadas que possuem fatores de regeneração maiores do que no caso centralizado. + + - Número grande de máquinas é interessante: várias podem estar sem funcionar num dado momento, mas as que estiverem funcionando podem dar conta da demanda. + + - A hidra é indestrutível? Essa questão faz sentido? Positivismo, revoluções e cataclismas: o limite da hidra por ter uma relação e abertura e fechamento (autonomia dependente). + +Parte 10: Referências +===================== + +Referências: imagens usadas +=========================== + + - [http://en.wikipedia.org/wiki/File:Hydra\_04.jpg](http://en.wikipedia.org/wiki/File:Hydra_04.jpg) + - [http://en.wikipedia.org/wiki/File:Hydra001.jpg](http://en.wikipedia.org/wiki/File:Hydra001.jpg) + - [http://code.google.com/edu/parallel/dsd-tutorial.html](http://code.google.com/edu/parallel/dsd-tutorial.html) + - [http://en.wikipedia.org/wiki/File:DNS_in_the_real_world.svg](http://en.wikipedia.org/wiki/File:DNS_in_the_real_world.svg) + - [http://www.linux.org/docs/ldp/howto/Jabber-Server-Farming-HOWTO/c2sfarm.html](http://www.linux.org/docs/ldp/howto/Jabber-Server-Farming-HOWTO/c2sfarm.html) + - [http://www.autistici.org/orangebook/slides/orangebook.en.html](http://www.autistici.org/orangebook/slides/orangebook.en.html). + - [http://www.autistici.org/orangebook/slides/orangebook.en.html](http://www.autistici.org/orangebook/slides/orangebook.en.html) + - [http://perl.apache.org/docs/tutorials/apps/scale_etoys/machine_layout.png](http://perl.apache.org/docs/tutorials/apps/scale_etoys/machine_layout.png) + - [http://en.wikipedia.org/wiki/File:ICEgrid.png](http://en.wikipedia.org/wiki/File:ICEgrid.png) + - [http://www.ibiblio.org/pioneers/baran.html](http://www.ibiblio.org/pioneers/baran.html) + - [http://www1.folha.uol.com.br/folha/ciencia/ult306u442499.shtml](http://www1.folha.uol.com.br/folha/ciencia/ult306u442499.shtml) + - [http://www.tutorvista.com/content/biology/biology-iv/growth-regeneration-ageing/regeneration.php](http://www.tutorvista.com/content/biology/biology-iv/growth-regeneration-ageing/regeneration.php) + - [http://www.uni-kiel.de/zoologie/bosch/developmentalbiology.html](http://www.uni-kiel.de/zoologie/bosch/developmentalbiology.html) + - [http://www.uni-kiel.de/zoologie/bosch/developmentalbiology.html](http://www.uni-kiel.de/zoologie/bosch/developmentalbiology.html) + - [http://www.puppetlabs.com/puppet/introduction](http://www.puppetlabs.com/puppet/introduction) + - [http://docs.reductivelabs.com/guides/introduction.html](http://docs.reductivelabs.com/guides/introduction.html) + - [http://www.nagios.org/about/screenshots](http://www.nagios.org/about/screenshots) + - [http://en.wikipedia.org/wiki/File:Munin-memory-week.png](http://en.wikipedia.org/wiki/File:Munin-memory-week.png) + - [http://hoth.entp.com/output/git_for_designers.html](http://hoth.entp.com/output/git_for_designers.html) + - [http://en.wikipedia.org/wiki/Mini-itx](http://en.wikipedia.org/wiki/Mini-itx) + - [http://www.sataadapter.com](http://www.sataadapter.com) + - [http://www.entropykey.co.uk](http://www.entropykey.co.uk) + - [http://apod.nasa.gov/apod/ap010416.html](http://apod.nasa.gov/apod/ap010416.html) + - [http://en.wikipedia.org/wiki/File:Cloud_Computing_Stack.svg](http://en.wikipedia.org/wiki/File:Cloud_Computing_Stack.svg) + - [http://en.wikipedia.org/wiki/File:CloudComputingSampleArchitecture.svg](http://en.wikipedia.org/wiki/File:CloudComputingSampleArchitecture.svg) + - [http://en.wikipedia.org/wiki/File:Cloud_computing_types.svg](http://en.wikipedia.org/wiki/File:Cloud_computing_types.svg) |