O OSDVT é um projeto que tem o objetivo de oferecer uma estrutura de virtualização de desktops, usando o KVM como Hypervisor, o SPICE como protocolo de acesso remoto e uma interface Python/GTK para que o cliente gerencie suas VMs. Todo o código é licenciado sob GPL.
Arquitetura:
Nesse artigo iremos percorrer todo o processo de instalação da última versão, a 0.2.2, em um servidoor Fedora 15.
O post de hoje é sobre uma ferramenta muito legal chamada BoxGrinder. O BoxGrinder é um projeto membro da comunidade JBoss, produzido pelo Project Odd Team e está (finalmente) nos repositórios oficiais do Fedora 15.
O objetivo dessa ferramenta é gerar imagens (appliances) de máquinas virtuais, personalizando a instalação, determinando que pacotes serão instalados e executando tarefas pós instalação. Algo muito parecido com o que o kickstart faz, mas com o foco em virtualização. Assim, o BoxGrinder tem a capacidade de gerar o seu appliance sem intervenção, nos formatos RAW, vmware e ec2, que podem ser usados pelo KVM, VmWare e pelo serviço de cloud da Amazon, respectivamente. Os formatos vmware e ec2 são gerados fazendo uma conversão a partir do RAW por meio de plugins.
Observe o esquema a seguir:
Esse é um post no mínimo 6 anos atrasado. Há muito tempo usei esse recurso para fazer o roteamento de acordo com o tráfego de rede, marcando os pacotes com a tabela mangle do iptables. Como é um assunto recorrente em várias listas de discussão e vez por outra alguém precisa, segue a dica:
É necessária a instalação do “iproute2″.
1º Você precisa marcar os pacotes… cada numero de marcação será posteriormente associado a uma tabela de roteamento. Pra marcar, use a tabela mangle do iptables, na CHAIN PREROUTING, pra que os pacotes cheguem no “roteamento” devidamente marcados:
iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 25 -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 110 -j MARK --set-mark 3 iptables -t mangle -A PREROUTING -s 192.168.0.0/24 -p tcp --dport 80 -j MARK --set-mark 4
Hoje li dois posts[1][2] muito interessantes sobre Cultura Livre e Software Livre. O primeiro escrito por Nina Paley[3], uma cartunista e ilustradora americana, e o segundo uma espécie de esclarecimento/contestação escrito por Joe Brockmeier[4], lider do Gnome Press Releases[5] team.
Os termos “Software Livre” e “liberdade” aqui tratados dizem respeito aos respectivos conceitos[6] defendidos pela Free Software Foundation.
Basicamente, Paley “reclama” de duas coisas:
Primeiro: o fato da FSF não estender seus conceitos de liberdade de software à cultura. Esse argumento é embasado no fato de a FSF recomendar o uso de licenças “Non Derivatives” para “Works that express someone’s opinion—memoirs, editorials, and so on…”[7]. No final, ela responde a dúvida que me acompanhou por todo o post – “o que é que eu tenho com isso?”, ou seja, por que a FSF deveria estender o conceito de liberdade de software às obras culturais? Bom, o argumento dela é, no mínimo, interessante (já explico por que): “I want the Free Software community – those who currently best understand the Four Freedoms – to champion the rest of Culture, not just Software. I want Freedom for All.”
Dentre as novidades apresentadas pelo Fedora 15, uma que me chamou atenção foi o FirewallD. FirewallD é um serviço que oferece um gerenciamento dinâmico das regras de firewall.
A principal motivação para criar um daemon que gerencia regras de firewall é o fato do modelo atual de gerenciamento estático de regras implicar em um reinicio completo do firewall, que inclui descarregar os módulos do kernel e recarregar os módulos necessários para a nova configuração. Isso tem como consequência a perda do estado das conexões ativas.
O daemon de firewall gerencia as regras dinamicamente e aplica as mudanças sem reiniciar todo o firewall. Assim, não é necessário recerragar os módulos do kernel. É importante observar que, usando o FirewallD, todas as modificações no firewall devem ser feitas pelo daemon, assegurando que o estado do daemon e do kernel estão em sincronia. O FirewallD não analisa regras criadas pelo comando iptables, possuindo binários e sintaxe própria.
Continue lendo »
