Arquitetura:

Nesse artigo iremos percorrer todo o processo de instalação da última versão, a 0.2.2, em um servidoor Fedora 15.

Preparação

Para esse artigo, usaremos o Fedora 15. O OSDVT 0.2.2 necessita do Spice versão 0.8 para funcionar. No moento que escrevo, as únicas distribuições que possuem essa versão do Spice em seus repositórios são:

• Fedora 15
• Red Hat Enterprise Linux 6
• Fedora 14 usando repositório virt-preview.

O CentOS 6 ainda está com Spice v0.4 em seus repositórios, mas o update para 0.8 deve sair em breve.

O spice-server só funciona em servidores x86_64.

SERVIDOR

Vamos parar temporariamente o iptables:

service iptables stop

Pacotes

Instale os pacotes necessários:

yum install qemu-kvm qemu-img spice-server \
       mysql-server MySQL-python python-ldap \
       bridge-utils tunctl Django httpd \
       mod_ssl mod_python

Banco de dados

Inicialize o MySQL:

service mysqld start

Defina senha de root do MySQL:

mysqladmin -u root password 'osdvt'

Configure o serviço para inicializar no boot:

chkconfig mysqld on

Crie o banco de dados:

mysql --user=root --password=osdvt -e "create database db_osdvt"

OSDVT Server

Baixe e extraia o pacote do OSDVT Server:

cd /usr/local/
wget http://www.ucs.br/projetos/osdvt/download/osdvt-server-0.2.2.tgz
tar xvfz osdvt-server-0.2.2.tgz

Server Web Admin

Entre no diretório do Web Admin

cd /usr/local/osdvt/osdvtweb

Ajuste o arquivo “settings.py” com as informações do seu banco de dados, caso você tenha host/db/user/pass diferentes do default.

Depois disso, crie a estrutura do banco de dados. Durante esse passo, você poderá definir a senha de root do Django Admin, caso seja a primeira vez que você executa esse comando:

python manage.py syncdb

Teste se o Django Admin está funcionando usando o webserver do Django. Isso é apenas um teste, pois iremos usar o Apache para rodar o Django Admin.

python manage.py runserver 0.0.0.0:8000

Acesse a URL do Django Admin pelo seu browser (http://server:8000/admin/). Após efetuar o login, você deverá ver uma página como esta:

Use “Ctrl+c” para encerrar o webserver do Django.

Server Daemon

Entre no diretório raiz do daemon:

cd /usr/local/osdvt/server/

Edite o arquivo “etc/osdvt.conf”. Toda a comunicação entre o cliente e o servidor OSDVT é criptografada com SSL. Um certificado autoassinado é fornecido, mas você pode usar o seu.

Adicionalmente, você pode desabilitar a autenticação LDAP para efetuar testes.

Copie o script de inicialização para o diretório “init.d”:

cp /usr/local/osdvt/server/osdvtd /etc/init.d/

Adicione o osdvtd ao chkconfig:

chkconfig --add osdvtd

Agora, copie o arquivo de configuração do apache para o diretório adequado:

cp /usr/local/osdvt/server/osdvt.conf /etc/httpd/conf.d/

Caso você esteja usando o Red Hat 6 ou CentOS 6, você precisa alterar o caminho do Django Media, pois a versão do Python nessas distribuição é a 2.6:

Alias /media/ /usr/lib/python2.7/site-packages/django/contrib/admin/media/

Para:

Alias /media/ /usr/lib/python2.6/site-packages/django/contrib/admin/media/

Configure o httpd para inicializar no boot:

chkconfig httpd on

Inicialize o httpd:

service httpd start

Agora, abra o “Django Admin” via browser: https://server/osdvtweb/admin/ (para usar o https você precisa ter isntalado o pacote “mod_ssl” ).

Crie uma bridge, que será usada para conectar as VMs na sua rede local. Edite o arquivo “/etc/sysconfig/network-scripts/ifcfg-eth0″, deixando somente as linhas abaixo:

DEVICE=eth0
ONBOOT=yes
BRIDGE=br0

Agora, crie o arquivo “/etc/sysconfig/network-scripts/ifcfg-br0″, com suas configurações de rede:

DEVICE=br0
ONBOOT=yes
BOOTPROTO=dhcp
TYPE=Bridge
NAME="bridge"

Reinicie o serviço “network”:

service network restart

Firewall

Inicie o iptables:

service iptables start

Libere o acesso http e https:

iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 443 -j ACCEPT

Libere o acesso ao Daemon do OSDVT:

iptables -I INPUT -p tcp --dport 6970 -j ACCEPT

Libere as portas que serão usadas pelo SPICE:

iptables -I INPUT -p tcp --dport 5930:5999 -j ACCEPT

Salve as regras criadas:

service iptables save

Osdvt service

Finalmente, podemos iniciar o serviço osdvt:

service osdvtd start

CLIENTE

Os passos a seguir deverão ser efetuados na estação que acessará as máquinas virtuais. Aqui os testes foram feitos em uma estação com Fedora 15.

Packages

yum install spice-client python-dialog

OSDVT Client

Baixe e extraia o pacote com o cliente do OSDVT:

cd ~
wget http://www.ucs.br/projetos/osdvt/download/osdvt-clients-0.2.2.tgz
tar xvfz osdvt-clients-0.2.2.tgz

Execute o cliente:

python ~/osdvt/osdvt-client.py

ou, ajuste o arquivo “osdvt-labs-client.py”…

interface = "eth0"
server = "192.168.0.1"
port = 6970

… e execute o “Labs Client”, que será autenticado pelo IP local em vez de usuário/senha:

python ~/osdvt/osdvt-labs-client.py

No próximo artigo mostrarei como criar e usar sua primeira máquina virtual.

Referência: http://www.ucs.br/projetos/osdvt/index.php/Documentation

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:

Após gerar a imagem no formato base(RAW), o BoxGrinder faz uso de plugins de conversão para os formatos vmware ou ec2. Depois disso, ainda é possível fazer a entrega do appliance usando os plugins de entrega disponíveis. Observe os SOs, formatos e métodos de entrega suportados:

Sistemas operacionais suportados
- CentOS (centos)
- Scientific Linux (sl)
- Red Hat Enterprise Linux (rhel)
- Fedora (fedora)

Formatos suportados
- VMware (vmware)
- Amazon Elastic Compute Cloud (ec2)
- VirtualBox (virtualbox)

Métodos de entrega
- Amazon Simple Storage Service (s3)
- Amazon Simple Storage Service (ami)
- Amazon Simple Storage Service (cloudfront)
- Elastic Block Storage (ebs)
- SSH File Transfer Protocol (sftp)
- ElasticHosts (elastichosts)
- Local file system (local)

O projeto BoxGrinder possui 3 componentes: build, rest e studio:

Nesse post, usaremos apenas o build, que é o utilitário para geração dos appliances. O rest é um servidor para processar nos nós (usando o build) as solicitações de geração de appliances, oferecendo uma API para interação. O studio é uma interface web que ainda não está pronta. Esse seria o ambiente completo para o BoxGrinder:

Vamos por a mão na massa que vai ficar mais fácil de entender…

O objetivo aqui é criar um appliance Fedora 14 com apache instalado e configurado para ser inicializado automaticamente. O formato será o VMware e a entrega será via sftp.

Usando o Fedora 15, primeiro, precisamos instalar o pacote do boxgrinder-build:

[root@localhost ~]# yum install rubygem-boxgrinder-build

Vou criar um diretório de trabalho:

[root@localhost ~]# mkdir appliances
[root@localhost ~]# cd appliances

O segundo passo é criar um arquivo de definição para o appliance. Vou criar um arquivo chamado f14-httpd.appl, com o seguinte conteúdo:

name: f14-httpd
summary: Appliance Fedora 14 com httpd.
os:
  name: fedora
  version: 14
hardware:
  cpus: 2
  memory: 256
  partitions:
    "/":
      size: 2
packages:
  - @core
  - httpd
repos:
  - name: fedora
    baseurl: http://fedora.c3sl.ufpr.br/linux/releases/14/Fedora/x86_64/os/
post:
  base:
    - "chkconfig httpd on"

Nesse arquivo definimos o OS fedora versão 14, que terá uma partição “/” de 2GB, 2 vcpus e 256MB de RAM. Serão instalados os pacotes do grupo core e o pacote httpd. Tudo isso usando o repositório especificado em repos (usar um repositório local melhora bastante o desempenho). Após a criação do formato base (RAW) será executado o comando chkconfig especificado.

(UPDATE) Os repositórios padrões de cada distro são automaticamente adicionados quando você define o “OS”. Só é necessário informar o parâmetro “repos” em caso de repositórios personalizados. Thanks Marek. 

Depois disso, é necessário criar no diretório ~/.boxgrinder/ um arquivo de configuração chamado config para os plugins:

[root@localhost ~]# mkdir ~/.boxgrinder
[root@localhost ~]# vi ~/.boxgrinder/config

E nesse arquivo colocar os seguintes parâmetros:

plugins:
  vmware:
    type: personal
    thin_disk: true
  sftp:
    path: /var
    username: root
    password: minhasenha
    host: vmserver.domain.com

Veja aqui todas as configurações de plugins.

Hora de executar o comando para gerar o appliance:

boxgrinder-build f14-httpd.appl -p vmware -d sftp

Podemos acompanhar a criação do appliance pelo arquivo log/boxgrinder.log

Acessando o diretório de entrega no servidor, temos:

[root@vmserver var]# ls -lah f14-httpd-1.0-fedora-14-x86_64-vmware.tgz
-rw-r--r--. 1 root root 173M Jul 12 15:50 f14-httpd-1.0-fedora-14-x86_64-vmware.tgz

Descompactando o arquivo:

[root@vmserver var]# tar xvfz f14-httpd-1.0-fedora-14-x86_64-vmware.tgz
f14-httpd-1.0-fedora-14-x86_64-vmware/
f14-httpd-1.0-fedora-14-x86_64-vmware/README
f14-httpd-1.0-fedora-14-x86_64-vmware/f14-httpd.vmx
f14-httpd-1.0-fedora-14-x86_64-vmware/f14-httpd.vmdk

Observe que agora temos o arquivo vmx, com as configurações da VM, e o vmdk, a própria imagem gerada.

Tudo pronto… você já pode subir seu appliance usando o VMware. Mas claro que você prefere o KVM!

Até o próximo post.

É 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

Aqui você pode se divertir com as regras do iptables, marcando qualquer tráfego que desejar. Verifique os pacotes marcados:

iptables -t mangle -L -n -v

2º Você agora precisa criar “tabelas” e vinculá-las aos pacotes marcados.  Posteriormente, essas tabelas serão associadas as rotas. Abaixo estou crianda as tabelas “20″ e “21″. Indico também a priridade: 20 por padão.

ip rule add fwmark 3 table 20 prio 20
ip rule add fwmark 4 table 21 prio 20

3º Vamos associar as tabelas com as rotas que você quer seguir:

ip route add default via 10.10.0.1 dev eth0 table 20
ip route add default via 10.20.0.1 dev eth1 table 21

Assim, os pacotes marcados com “3″ foram associados a tabela “20″ e seguirão pelo roteador “10.10.0.1″. Já os pacotes marcados com “4″ foram pra tabela “21″ e seguirão pelo roteador “10.20.0.1″. Vale lembrar que o computador onde estamos trabalhando está, de alguma forma, na mesma rede dos dois roteadores usados nesse exemplo. Normalmente, cada placa de rede estaria ligada diretamente a um dos roteadores.

4º Limpe o cache de roteamento:

ip route flush cache

5º Be happy.

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.”

Segundo: a realidade atual do movimento de “Cultura Livre” ser “atrofiado” pela prevalência de restrições “não comerciais”, fazendo que com artistas só possam se dedicar ao movimento enquanto hobistas, pois não conseguiriam sobreviver sem ganhar nada com seus trabalhos.

No fundo, me parece que ela gostaria que o Movimento de Cultura Livre fosse tudo que o Movimento de Software Livre é hoje, inclusive pedindo apoio da nossa comunidade, que é quem melhor consegue entender o valor da criação colaborativa, mantendo-se livre de amarras financeiras que contribuam para o surgimento de monopólios aprisionadores de conhecimento e, consequentemente, da própria sociedade – StallmanMode.enable()

Em sua réplica, Brockmeier explica o contexto da criação das “liberdades” definidas pela FSF e argumenta sobre as diferenças entre o software e as obras culturais. Ele concentra o texto no aspecto “Non Derivatives”, deixando de lado o problema específico do Movimento de Cultura Livre sobre as recorrentes obras sob licenças “Non Commercial”. Ele explica: mesmo que você não tenha o direito de alterar um livro ou uma escultura(:|), as obras funcionarão conforme previsto pelo autor. E vai além… sobre obras que expressam pontos de vista particulares, uma obra derivada iria confundir o público, que não saberia onde termina a opinião original do autor e onde começa a opinião derivada. Assim, Brockmeier deixa claro: não misture as coisas… padrões diferentes se aplicam a coisas diferentes, mas nada impede que sua obra seja “licenciada” como você bem entender.

Leitura recomendadíssima.

Referẽncias:
[1] – http://blog.ninapaley.com/2011/07/04/rantifesto/
[2] – http://www.networkworld.com/community/anti-rantifesto-free-culture-isnt-the-same
[3] – http://www.ninapaley.com/bio.html
[4] – http://dissociatedpress.net/about/
[5] – http://www.gnome.org/press/
[6] – http://www.gnu.org/philosophy/free-sw.html
[7] – http://www.gnu.org/licenses/license-list.html#OpinionLicenses

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.

Instalando:

[root@localhost ~]# yum install firewalld

Iniciando o serviço:

[root@localhost ~]# service firewalld start

Adicionando o serviço na inicialização do sistema:

[root@localhost ~]# chkconfig firewalld on

Verificando o processo:

[root@localhost ~]# ps x | grep firewalld
10125 ?        Ss     0:00 /usr/bin/python /usr/sbin/firewalld

Habilitando o serviço http:

[root@localhost ~]# firewall-cmd --enable --service=http

Verificando serviços liberados:

[root@localhost ~]# firewall-cmd --list=service
http

Liberando porta específica por tempo determinado (em segundos):

[root@localhost ~]# firewall-cmd --enable --port=3306:tcp --timeout=60

Verificando porta liberada:

[root@localhost ~]# firewall-cmd --list=port
3306:tcp

Por fim, desabilitando um serviço:

[root@localhost ~]# firewall-cmd --disable --service=http

… e uma porta:

[root@localhost ~]# firewall-cmd --disable --port=3306:tcp

Também é possível gerenciar as regras do FirewallD graficamente usando o firewall-applet, mas ele ainda tem alguns bugs de interface que precisam ser resolvidos…

Instalando:

[root@localhost ~]# yum install firewall-applet

Execute:

[root@localhost ~]# firewall-applet

E, na bandeja do sistema, temos:

Site do projeto: https://fedoraproject.org/wiki/FirewallD/

<graphics type='spice' port='5903' />

When I try to start VM with:

# virsh start Ubuntu

I got this error:

error: Failed to start domain Ubuntu
error: internal error Process exited while reading console log output: qemu-kvm: -spice port=5903,addr=127.0.0.1,disable-ticketing: Invalid parameter 'addr'
parse error: port=5903,addr=127.0.0.1,disable-ticketing

Taking a good look in the error, we can see what is wrong: The “addr” parameter is not supported by Spice.

To fix that, I had to edit the “src/qemu/qemu_command.c”, in libvirt source (http://libvirt.org/downloads.html#Compilatio). Just commenting this lines:

/* *       if (def->graphics[0]->data.spice.listenAddr)
*          virBufferVSprintf(&opt, ",addr=%s", def->graphics[0]- gt;data.spice.listenAddr);
*       else if (driver->spiceListen)
*          virBufferVSprintf(&opt, ",addr=%s", driver->spiceListen);
*/

After compiling, I can start my VM:

#virsh start Ubuntu
Domain Ubuntu started

Checking ps:

root     32225 49.5  0.1 871732 22836 ?        Sl   22:27   0:04 /usr/bin/qemu-kvm -S -M pc-0.13 -cpu qemu32 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name Ubuntu -uuid a293bbea-22af-dbef-5a99-07d0e8fe594c -nodefconfig -nodefaults -chardev socket,id=monitor,path=/usr/local/libvirt/var/lib/libvirt/qemu/Ubuntu.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/Ubuntu.img,if=none,id=drive-virtio- isk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0- -  -netdev tap,fd=15,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fd:27:81,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -spice port=5903,disable-ticketing -vga cirrus -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

After that, I need to alter the VM video device from:

<video>
<model type='cirrus' vram='9216' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>

to:

<video>
<model type='qxl' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>

But I got another error:

# virsh start Ubuntu
error: Failed to start domain Ubuntu
error: unsupported configuration: This QEMU does not support QXL graphics adapters

Libvirt finds qemu capabilities with “qemu -help”. Take a look in this code from ”src/qemu/qemu_capabilities.c” file:

    if ((p = strstr(help, "-vga")) && !strstr(help, "-std-vga")) {
        const char *nl = strstr(p, "n");

        flags |= QEMUD_CMD_FLAG_VGA;

        if (strstr(p, "|qxl"))
            flags |= QEMUD_CMD_FLAG_VGA_QXL;
        if ((p = strstr(p, "|none")) && p < nl)
            flags |= QEMUD_CMD_FLAG_VGA_NONE;
    }

Executing “qemu -help” in command, qxl support is not shown:

# qemu -help | grep vga
-vga [std|cirrus|vmware|xenfb|none]

I think libvirt is OK, but qemu needs to show the correct information about vga capabilities.
So, lets back to libvirt qemu source file, to comment a little more code. For while, I will just skip the Qemu QXL support test:

/*   if ((def->videos[0]->type == VIR_DOMAIN_VIDEO_TYPE_QXL) &&
*    !(qemuCmdFlags & QEMUD_CMD_FLAG_VGA_QXL)) {
*    qemuReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s",
*                    _("This QEMU does not support QXL graphics adapters"));
*    goto error;
*   }
*/

After compile once more, we have a libvirt really Spiced!

#virsh start Ubuntu
Domain Ubuntu started

And now, my ps looks like this:

root     29219  6.5  0.1 987516 15144 ?        Sl   22:42   0:00 /usr/bin/qemu-kvm -S -M pc-0.13 -cpu qemu32 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name Ubuntu -uuid a293bbea-22af-dbef-5a99-07d0e8fe594c -nodefconfig -nodefaults -chardev socket,id=monitor,path=/usr/local/libvirt/var/lib/libvirt/qemu/Ubuntu.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=utc -boot c -drive file=/var/lib/libvirt/images/Ubuntu.img,if=none,id=drive-virtio- isk0,boot=on,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0- -  -netdev tap,fd=15,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:fd:27:81,bus=pci.0,addr=0x3 -chardev pty,id=serial0 -device isa-serial,chardev=serial0 -usb -spice port=5903,disable-ticketing -vga qxl -device AC97,id=sound0,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

I reported these bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=664190
https://bugzilla.redhat.com/show_bug.cgi?id=664192

Essa nova versão sai com 85% mais pacotes que a anterior e é o resultado do trabalho de mais de 600 engenheiros/ano, que atenderam as 1821 solicitações de funcionalidades por parte dos parceiros e clientes.

Quem estava acostumado com o padrão de instalação antigo do RHEL não terá muita dificuldade em instalar essa nova versão. Porém, alguns itens interessantes já aparecem aqui nesse ponto.

Uma coisa que me chamou atenção de cara foi não ter mais aquele pedido de número da subscription durante a instalação. Isso agora ficou para o firstboot, onde você pode registrar na RHN. No RHEL5, inserir esse número ( mesmo que fosse opcional) me dava uma sensação de “cadê o serial” :p

Assim que o DVD é carregado aparece um menu, semelhante as ultimas versões do Fedora. Caso você precise passar parâmetros de instalação (linux ks=”…”, por exemplo), você deve apertar esc.

O próximo passo interessante na instalação é a possibilidade de já usar dispositivos de armazenamento especializados, como iSCSI ou FC:

Abaixo, a tela de configuração de um dispositivo iSCSI:

Na criação do sistema de arquvios, o destaque fica por conta do suporte nativo (e natural) ao ext4 e ao XFS:

Na escolha do tipo de instalação me agrada a opção minimal. Era algo que eu realmente sentia falta. Com essa opção selecionada, o sistema será instalado com apenas 219 pacotes, ocupando 693M de espaço em disco (fora os 29M do /boot). Nem pense em usar scp ou wget. Mas não tenha medo, o yum está lá.

Outro destaque fica por conta do sumiço (anunciado, é verdade) do suporte ao Xen, consolidando o KVM como solução de virtualização oficial da Red Hat:

O kernel instalado foi o 2.6.32.

Talvez para agradar os gremistas, que não gostavam de tanto vermelho nessa distro, as coisas estejam mais azuis!

Se você não tem uma subscription pra baixar o RHEL, paciência. Já já o CentOS desembarca por aí.

Comentem com suas experiências (e frustrações, why not?) nessa nova versão.

Ambiente
Os procedimentos abaixo descritos foram testados em duas distribuições:

Debian Etch 4.0r6
Ubuntu 8.10

Ambas instaladas em Máquina Virtual (VirtualBox) autenticando no servidor LDAP:
Para ambas, o procedimento é idêntico.

Instalação
Antes de instalar os pacotes necessários, e recomendado que você atualize seu sistema:

Configurando o Proxy:

export http_proxy="http://proxy.com:3128″
export ftp_proxy="http://proxy.com:3128″

Atualizando APT:

apt-get update

Atualizando sistema:

apt-get upgrade

Vamos precisar do pacote libpam-ldap. Biblioteca que adiciona ao PAM do Linux a funcionalidade de autenticação em servidor LDAP:

apt-get install libpam-ldap

Durante a instalação do libpam-ldap, algumas configurações serão solicitadas:

LDAP Server Uniferm Resource Identifier: ldaps://ldap.com.br
Distinguished name of the search base: ou=People,dc=com,dc=br
LDAP version to use: 3
Make local root Database admin: Não
Does the LDAP database require login: Não

Feito isso, a instalação será concluída.

Arquvios de configuração

/etc/nsswitch.conf

Informando para o sistema que ele irá procurar os usuários na base LDAP e, caso não ache, procura-rá nos arquivos locais.

Edite o arquivo, alterando a linha abaixo:
De:

passwd: compat

Para:

passwd ldap compat

/etc/ldap.conf

Alterando as configurações de acesso ao LDAP.

Descomente e altere a linha:

#port 389

Para:

port 636 #Porta do servico ldaps.

Descomente a linha:

#ssl on

Para:

ssl on #Habilita LDAPS

Descomente e altere a linha:

#tls_checkpeer yes

Para:

tls_checkpeer no # Impede que seja feita a checagem do certificado. No nosso caso isso é importante, pois o certificado foi auto-assinado.

Descomente e altere a linha:

#tls_cacertfile /etc/ssl/ca.cert

Para:

tls_cacert /etc/cacert.pem  # Informa onde está o certificado.

OBS: Certifique-se que o certificado cacert.pem está no diretório /etc/

/etc/pam.d/common-account
Apague todo o conteudo do arquivo e insira o conteúdo abaixo:

account sufficient pam_unix.so
account sufficient pam_ldap.so
account required pam_deny.so

/etc/pam.d/common-auth

Apague todo o conteudo do arquivo e insira o conteúdo abaixo:

auth sufficient pam_unix.so
auth sufficient pam_ldap.so use_first_pass
auth required pam_deny.so

/etc/pam.d/common-password

Apague todo o conteudo do arquivo e insira o conteúdo abaixo:

password required pam_unix.so use_authtok nullok md5
password sufficient pam_unix.so use_authtok md5
password sufficient pam_ldap.so use_first_pass use_authtok md5
password required pam_deny.so

/etc/pam.d/common-session

Apague todo o conteudo do arquivo e insira o conteúdo abaixo:

session required pam_limits.so
session required pam_unix.so
session optional pam_ldap.so

/etc/pam.d/login

Insira a linha abaixo no final do arquivo:

account sufficient /lib/security/pam_ldap.so

Conclusão

Nesse momento você já deve estar conseguindo autenticar em seu linux com uma conta do seu servidor LDAP.

NOTA: Nesse artigo não foi abordada a necessidade de criação dos certificados nem a criação do diretório “home” do usuário automaticamente.

proxy.com

SysV init e os Run Levels

O SysV init tem sido o inicializador do sistema padrão no Linux desde o início de sua fase adulta. Ele foi introduzido pelo Unix System V, da AT&T, a partir de 1983 e seu modelo serviu de inspiração para o Linux. O modelo estabelecido pelo SysV init só é completo com o uso dos Run Levels.

Quando o sistema é inicializado, depois que o kernel termina de carregar, o init é chamado recebendo como parâmetro o runlevel que ele deve executar. De acordo com o runlevel, o SysV init inicia os scripts correspondentes ao nível de execução desejado. Pela Linux Standard Base 4.0, temos os seguintes runlevels…

Para cada Run Level temos um diretório no sistema que contém os scripts (ou links para eles) que devem ser inicializados ou parados. Por exemplo, em um servidor RHEL5, podemos achar os seguintes scripts no diretório correspondente ao Run Level 3:

root@server:~# ls /etc/rc3.d/
S10rsyslog  S16ssh     S21fam   S99rc.local
S12acpid    S20cprint  S24hal   S99rmnologin
S12dbus     S20cups    S89cron  S99stop-bootlogd

Perceabam que no nome do script há ainda um S, indicando que o script receberá “start” como parâmetro (seria K, de Kill, para o script receber o parâmetro stop), e um número que indica a ordem que ele deve ser executado.

Nem todas as distribuições seguem a risca esse padrão de Run Levels. No caso do Debian e derivados, os níveis de 2 a 5 são idênticos. Nesse caso, a interface gráfica é sempre iniciada caso esteja instalada.

Upstart

Pela definição da Canonical, o “Upstart é um substituto do daemon /sbin/init baseado em eventos que inicia serviços durante o boot, para-os durante o desligamento e supervisiona-os enquanto o sistema está em funcionamento.”

O Upstart resolve 2 problemas existentes no modo de funcionamento do SysV init. O primeiro, que julgo o menos importante, é que o Upstart executa os scripts de inicialização de forma paralela, dependendo apenas que os eventos estabelecidos como pré-requisitos ocorram, reduzindo drasticamente o tempo de boot. O segundo, importantíssimo pra mim, é que o Upstart tem a capacidade de monitorar um serviço e, em caso de interrupção abrupta, inicializa-lo novamente. O fato de os eventos determinarem quando um serviço é inicializado ou parado traz vantagens para o sistema, já que os eventos podem ser gerados por qualquer processo.

Como forma de manter a compatibilidade com o SysV init, propiciando uma migração suave, existe um script de Upstart que chama o SysV init passando o run level desejado.

Para criar um script upstart, acesse o diretório dos scripts já existentes. Na versão 10.04 do Ubuntu, o diretório é o “/etc/init”. Em versões passadas, os scripts ficavam em “/etc/event.d”. Os scripts tem a extensão “.conf” e possuem três sessões principais:

• Condições para inicializar ou parar o serviço.
• Ações a serem tomadas antes de inicializar e depois de parar o serviço.
• Comando ou script que inicializa o serviço.

Criaremos então um arquivo chamado “/etc/init/meuservico.conf”

1 – Condições para inicializar ou parar o serviço: aqui iremos definir os eventos esperados para executar ou parar o serviço. Por exemplo:

start on filesystem and net-device-up IFACE=lo

Onde “filesystem” é um evento gerado pelo sistema quando as partições estiverem montadas e “net-device-up IFACE=lo” é um evento gerado pelo sistema quando a interface de loopback estiver “up”.

Da mesma forma, devemos ter o evento que para o serviço:

stop on runlevel [016]

Onde “runlevel [016]” é um evento gerado pelo sistema quando o computador for desligado, ligado ou alternado para monousuário ou reinicializado, respectivamente.

2 – As ações a serem tomadas antes de inicializar e depois de parar o serviço são definidas pelos parâmetros a seguir:

pre-start script
 mkdir /tmp/meuservico
end script

post-stop script
 rm -rf /tmp/meuservico
end script

3 – E, por último, o comando ou script que inicializa o serviço:

exec /usr/bin/meuservico.sh

Onde meuservico.sh pode ser um script ou binário, em qualquer linguagem, inclusive recebendo parâmetros, caso se aplique.

Para gerenciar o serviço criado, usamos os comandos:

start meuservico
stop meuservico
status meuservico

Podemos também emitir eventos personalizados, usando o seguinte comando:

initctl emit evento1

Esse evento pode ser usado como condição de start ou stop do meu serviço.

Pra encerrar, podemos usar o parâmetro “respaw” para que o Upstart monitore e inicie-o novamente em caso de parada abrupta no funcionamento do serviço (tenta dar um kill no processo…).

O arquivo “/etc/init/meuservico.conf” completo ficaria assim:

start on filesystem and net-device-up IFACE=lo
stop on runlevel [016]

respawn

pre-start script
 mkdir /tmp/meuservico
end script

post-stop script
 rm -rf /tmp/meuservico
end script

exec /usr/bin/meuservico.sh

Essa foi um breve introdução ao gerenciamento de serviços Upstart. Para mais informações visite:

http://upstart.ubuntu.com/wiki/

Deixe seu comentário!

:wq

Preparação

Instale os softwares necessários:

apt-get install php5-dev php-pear libaio1 unzip

Entre no diretório onde ficarão os fontes do oracle client:

cd /usr/local/src/

Baixe esses dois arquivos. Precisa se registrar no site:

http://download.oracle.com/otn/linux/instantclient/112010/instantclient-basic-linux32-11.2.0.1.zip

http://download.oracle.com/otn/linux/instantclient/112010/instantclient-sdk-linux32-11.2.0.1.zip

Agora, descompacte os arquivos:

unzip instantclient-basic-linux32-11.2.0.1.zip
unzip instantclient-sdk-linux32-11.2.0.1.zip

Entre no diretório criado

cd instantclient_11_2

Crie o link para uma das bibliotecas

ln -s libclntsh.so.11.1 libclntsh.so

Instalação 

Começando a instalação. Digite:

pecl install oci8

Aparecerá essa mensagem:

downloading oci8-1.3.5.tgz ...
Starting to download oci8-1.3.5.tgz (137,987 bytes)
.............................done: 137,987 bytes
10 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
 1. Please provide the path to the ORACLE_HOME directory. Use
'instantclient,/path/to/instant/client/lib' if you're compiling
with Oracle Instant Client : autodetect

1-1, 'all', 'abort', or Enter to continue:

Digite:1

Aperte <enter>

Please provide the path to the ORACLE_HOME directory. Use
'instantclient,/path/to/instant/client/lib' if you're compiling
with Oracle Instant Client [autodetect] :

Digite: instantclient,/usr/local/src/instantclient_11_2

Aperte <enter>

 1. Please provide the path to the ORACLE_HOME directory. Use
'instantclient,/path/to/instant/client/lib' if you're compiling with
Oracle Instant Client : instantclient,/usr/local/src/instantclient_11_2

Aperte <enter>

Configure o PHP:

vi /etc/php5/apache2/php.ini
extension=oci8.so

Reinicie o Apache:

/etc/init.d/apache2 restart

Verificando se o PHP já mostra o suporte ao Oracle 

Crie um arquvivo php:

vi /var/www/test.php

Insira o conteúdo:

<?php
  phpinfo();
?>

Acesse http://localhost/test.php

Verifique o parâmetro “OCI8 Support: enabled”

Testando a conexão com o banco
Crie um aquivo php:

vi /var/www/connect.php

Insira o conteúdo abaixo, personalizando as informações sobre banco, user, senha e select:

<?php
$conn = oci_connect('hr', 'hr_password', 'mymachine.mydomain/MYDB');
$query = 'select table_name from user_tables';
$stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
while ($row = oci_fetch_array($stid, OCI_ASSOC)) {
  foreach ($row as $item) {
    echo $item." ";
  }
  echo "<br>n";
}
oci_free_statement($stid);
oci_close($conn);
?>

Acesse http://localhost/connect.php