Configuração de Um Ambiente de Testes para o OpenStack – Parte 3 – Network

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Com a configuração feita no post anterior, podemos partir para configurar o segundo host com os serviços de rede. A princípio, já poderíamos instanciar máquinas apenas com o Controller configurado. Mas a adição do Network torna o cenário, ainda controlado, um pouco mais realista.

Configurações no Ubuntu

Assim como na configuração do Controller, vamos atualizar a sources.list para adicionar o repositório com a versão mais recente do OpenStack.

openstack@network:~$ sudo apt-get install ubuntu-cloud-keyring 

Coloque a linha abaixo no arquivo /etc/apt/sources.list.d/cloud-archive.list:

deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 

Em seguida, atualize o sistema:

openstack@network:~$ sudo apt-get update && sudo apt-get dist-upgrade

Vamos configurar a rede. Aqui temos que prestar atenção em detalhe. A interface da rede externa (endereço 192.168.122.3/24) será alterada. Nós vamos criar uma bridge pública. Se você logou na máquina pela interface da rede externa, sai e comece a sessão SSH por outro endereço. O arquivo /etc/network/interfaces deve ficar assim:

# The loopback network interface
auto lo
iface lo inet loopback

# Bridge Pública
auto eth0
iface eth0 inet manual
        up ifconfig $IFACE 0.0.0.0 up
        up ip link set $IFACE promisc on   
        down ifconfig $IFACE down

# Rede de Gerência
auto eth1
iface eth1 inet static
        address 192.168.0.3
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        ### static routing ###
        post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
        pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

# Rede de Dados
auto eth2
iface eth2 inet static
        address 10.10.10.2
        netmastk 255.255.255.0
        network 10.10.10.0
        broadcast 10.10.10.255
        ### static routing ###
        post-up route add -net 10.10.10.0 netmask 255.255.255.0 dev eth2
        pre-down route del -net 10.10.10.0 netmask 255.255.255.0 dev eth2

Antes de reiniciar, instale todos os pacotes necessários. Com a interface pública como bridge, não teremos acesso aos repositórios do Ubuntu no primeiro momento.

openstack@network:~$ sudo apt-get install ntp quantum-plugin-openvswitch-agent quantum-dhcp-agent quantum-l3-agent

Devemos ativar o roteamento de pacotes no kernel. Coloque as opções a seguir no arquivo /etc/sysctl.conf:


Coloque também as mesmas informações do /etc/hosts do Controller no Network. Configura o NTP:

openstack@network:~$ sudo cat /etc/ntp.conf
server 192.168.0.2
openstack@network:~$ sudo service ntp restart
 * Stopping NTP server ntpd                                                                                                           [ OK ] 
 * Starting NTP server ntpd                                                                                                           [ OK ]

Por via das dúvidas, reinicie a máquina.

Serviços de Rede

Vamos agora configurar os serviços de rede.

Open-vSwitch

O Open-vSwitch é uma ferramenta de criação de switchs virtuais. Nós já instalamos o pacote acima, vamos iniciar o daemon:

openstack@network:~$ service openvswitch-switch start

Os comandos abaixo criam uma bridge virtual:

openstack@network:~$ sudo ovs-vsctl add-br br-int
openstack@network:~$ sudo ovs-vsctl add-br br-ex
openstack@network:~$ sudo ovs-vsctl add-port br-ex eth0
openstack@network:~$ sudo ip link set up br-ex 

Com isso, criamos uma bridge interna (br-int) e uma externa (br-ex). Devemos adicionar no /etc/network/interfaces a configuração abaixo para garantir conectividade pela rede externa:

Quantum

Vamos agora integrar o Quantum do network com o controller. Configure as seguintes opções no arquivo /etc/quantum/l3_agent.ini:

auth_url = http://192.168.0.2:35357/v2.0
admin_tenant_name = service
admin_user = quantum
admin_password = openstack
metadata_ip = 192.168.0.2
use_namespaces = False

Configure as seguintes opções no arquivo /etc/quantum/api-paste.ini:

auth_host = 192.168.0.2
admin_tenant_name = service
admin_user = quantum
admin_password = openstack

Configure as seguintes opções no arquivo /etc/quantum/quantum.conf:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_host = 192.168.0.2
rabbit_password = openstack

Configure as seguintes opções no arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini:

sql_connection = mysql://quantum:openstack@192.168.0.2:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
enable_tunneling = True
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.10.10.2

Configure a seguinte opções no arquivo /etc/quantum/dhcp_agent.ini:

use_namespaces = False

Agora, vamos reiniciar todos os serviços:

openstack@network:~$ sudo service quantum-plugin-openvswitch-agent restart
openstack@network:~$ sudo service quantum-dhcp-agent restart
openstack@network:~$ sudo service quantum-l3-agent restart

Redes Virtuais

Criação de Redes Virtuais

Vamos agora configurar o necessário para criação de redes virtuais. O primeiro passo é criar um arquivo com as variáveis de ambiente, para facilitar a execução dos comandos no prompt. O arquivo deve ser nomeado novarc:

export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL="http://192.168.0.2:5000/v2.0/"
export SERVICE_ENDPOINT="http://192.168.0.2:35357/v2.0"
export SERVICE_TOKEN=openstack

Vamos carregar essas variáveis e garantir que as mesmas são carregadas toda vez que entrarmos no sistema com o usuário ‘openstack’.

source novarc
echo "source novarc">>.bashrc

Vamos baixar o script de automação do site oficial do projeto. O script se chamada quantum-networking.sh. Nós temos que alterar os endereços IPs no script. A alteração será feita de acordo com a tabela na Parte 1 desse tutorial. A primeira coisa que temos que notar é que a nossa rede externa não é 7.7.7.0/24, mas sim 192.168.122.0/24. Portanto, altere os seguintes campos no script:

EXT_NET_CIDR="192.168.122.0/24"
EXT_GW_IP="192.168.122.3"
EXT_NET_GATEWAY="192.168.122.1"
POOL_FLOATING_START="192.168.122.130"   
POOL_FLOATING_END="192.168.122.150"     

Também aproveite para corrigir as últimas linhas do script. Elas executam comando que necessitam de privilégios de super-usuário.

sudo ip addr flush dev $EXT_NET_BRIDGE
sudo ip addr add $EXT_GW_IP/$EXT_NET_LEN dev $EXT_NET_BRIDGE
sudo ip link set $EXT_NET_BRIDGE up

Em seguir, execute o script:

openstack@network:~$ ./quantum-networking.sh 
Added interface to router 357a19df-004a-47ef-919b-3a7e4b0c1e53
Created a new subnet:
+------------------+--------------------------------------------------------+
| Field            | Value                                                  |
+------------------+--------------------------------------------------------+
| allocation_pools | {"start": "192.168.122.130", "end": "192.168.122.150"} |
| cidr             | 192.168.122.0/24                                       |
| dns_nameservers  |                                                        |
| enable_dhcp      | False                                                  |
| gateway_ip       | 192.168.122.1                                          |
| host_routes      |                                                        |
| id               | 05f4eb00-c3aa-494f-9b04-08ad8c895749                   |
| ip_version       | 4                                                      |
| name             |                                                        |
| network_id       | 4e7f1f37-b4a8-4111-a1d5-84245fe80500                   |
| tenant_id        | 4630c01242484c2ba63cf6392c78061c                       |
+------------------+--------------------------------------------------------+
Set gateway for router 357a19df-004a-47ef-919b-3a7e4b0c1e53
Configuração Layer3

Vamos configurar as funcionalidades da camada 3. Anote o identificador da rede externa (‘ext_net’) retornado pelo comando ‘quantum net-list’. Coloque no arquivo /etc/quantum/l3_agent.ini o campo ‘gateway_external_network_id = ID’, onde ID é o identificador da rede externa. Anote também o identificador do roteador ‘provider-router” retornado por ‘quantum router-list’ e atualize o campo ‘router_id = ID’ no mesmo arquivo. Para finalizar, reinicie o serviço:

openstack@network:~$ sudo service quantum-l3-agent restart
quantum-l3-agent stop/waiting
quantum-l3-agent start/running, process 32735

Com isso, finalizamos a configuração do nó Network.

Anúncios

Configuração de Um Ambiente de Testes para o OpenStack – Parte 2 – Controller

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Instalação e Configuração do OpenStack

Com as máquinas virtuais configuradas no post anterior, vamos partir para a configuração dos serviços do OpenStack. Em teoria, se você está usando máquinas reais, seria possível começar o tutoria a partir deste ponto.

Controlador

Com as máquinas criadas e configuradas, vamos para o OpenStack. Primeiro passo, vamos logar no Controller e configurar os repositórios do Ubuntu para utilizar a versão mais nova do OpenStack:

openstack@controller:~$ sudo apt-get install ubuntu-cloud-keyring
openstack@controller:~$ cat /etc/apt/sources.list.d/cloud-archive.list
deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 
openstack@controller:~$ sudo apt-get update && sudo apt-get upgrade

Em seguida, edite o arquivo /etc/sysctl.conf com as seguintes opções:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0  

O arquivo /etc/hosts deve conter os endereços das máquinas da nuvem:

127.0.0.1       localhost
#127.0.1.1      controller
192.168.0.2     controller
192.168.0.3     network
192.168.0.4     compute

NTP

O NTP é um programa que sincroniza o tempo da máquina com um servidor da rede. Precisamos instalá-lo para garantir sincronização entre as máquinas da nuvem:

openstack@controller:~$ sudo apt-get install -y ntp
openstack@controller:~$ sudo cp /etc/ntp.conf /etc/ntp.conf.old
openstack@controller:~$ cat /etc/ntp.conf
server ntp.ubuntu.com iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 10
openstack@controller:~$ sudo service ntp restart
 * Stopping NTP server ntpd                                                                                                                                                                                  
 * Starting NTP server ntpd       

MySQL

Instale o MySQL-Server, colocando a senha do banco como openstack. Configure o banco com os comandos abaixo.

openstack@controller:~$ sudo apt-get install mysql-server python-mysqldb
openstack@controller:~$ sudo sed -i 's/127.0.0.1/0.0.0.0/g' /etc/mysql/my.cnf
openstack@controller:~$ sudo service mysql restart
mysql stop/waiting
mysql start/running, process 4219
openstack@controller:~$ mysql -u root -p <<EOF
CREATE DATABASE nova; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localhost' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.1' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.2' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'192.168.0.3' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'controller' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'compute' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'network' IDENTIFIED BY 'openstack'; 
CREATE DATABASE cinder; 
GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE glance;
GRANT ALL PRIVILEGES ON glance.* TO 'glance'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE keystone;
GRANT ALL PRIVILEGES ON keystone.* TO 'keystone'@'localhost' IDENTIFIED BY 'openstack';
CREATE DATABASE quantum;
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'localhost' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'192.168.0.2' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'192.168.0.3' IDENTIFIED BY 'openstack';
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'controller' IDENTIFIED BY 'openstack'; 
GRANT ALL PRIVILEGES ON quantum.* TO 'quantum'@'network' IDENTIFIED BY 'openstack'; 
FLUSH PRIVILEGES;
EOF

RabbitMQ

O RabbitMQ é um sistema de mensagens:

openstack@controller:~$ sudo apt-get install rabbitmq-server
openstack@controller:~$ sudo rabbitmqctl change_password guest openstack
Changing password for user "guest" ...
...done.

Keystone

O Keystone é o serviço de identidade do OpenStack. Vamos primeiro configurar o banco de dados do Keystone:

openstack@controller:~$ sudo apt-get install keystone python-keystone python-keystoneclient
openstack@controller:~$ sudo mv /etc/keystone/keystone.conf /etc/keystone/keystone.conf.old
openstack@controller:~$ sudo cat /etc/keystone/keystone.conf
[DEFAULT]
admin_token = openstack
bind_host = 0.0.0.0
public_port = 5000
admin_port = 35357
compute_port = 8774
verbose = True 
debug = True 
log_file = keystone.log
log_dir = /var/log/keystone
log_config = /etc/keystone/logging.conf

[sql]
connection = mysql://keystone:openstack@localhost:3306/keystone
idle_timeout = 200
(resto igual ao arquivo original)
openstack@controller:~$ sudo service keystone restart
keystone stop/waiting
keystone start/running, process 6271
openstack@controller:~$ sudo keystone-manage db_sync

Vamos em seguida criar um arquivo com as variáveis de ambiente necessárias para interagir com o OpenStack:

openstack@controller:~$ cat novarc 
export OS_TENANT_NAME=admin
export OS_USERNAME=admin
export OS_PASSWORD=openstack
export OS_AUTH_URL="http://localhost:5000/v2.0/"
export SERVICE_ENDPOINT="http://localhost:35357/v2.0"
export SERVICE_TOKEN=openstack
openstack@controller:~$ source novarc 
openstack@controller:~$ echo "source novarc">>.bashrc

O próximo passo é povoar o banco de dados do Keystone. Para isso, vamos fazer uso dos scripts keystone-data.sh e keystone-endpoints.sh . Baixe-os na máquina Controller. No keystone-data.sh, deixe o começo do script da seguinte forma:

ADMIN_PASSWORD="openstack"
SERVICE_PASSWORD="openstack"
SERVICE_TOKEN="openstack"
export SERVICE_ENDPOINT="http://localhost:35357/v2.0"
SERVICE_TENANT_NAME=${SERVICE_TENANT_NAME:-service}

Em seguida, torne o script executável e o invoque:

openstack@controller:~$ chmod +x keystone-data.sh 
openstack@controller:~$ ./keystone-data.sh 

No keystone-endpoints.sh, deixe o começo do script da seguinte forma:

# MySQL definitions
MYSQL_USER=keystone
MYSQL_DATABASE=keystone
MYSQL_HOST=localhost
MYSQL_PASSWORD=openstack
# Keystone definitions
KEYSTONE_REGION=RegionOne
SERVICE_TOKEN=openstack
SERVICE_ENDPOINT="http://localhost:35357/v2.0"
# other definitions
MASTER="192.168.0.2"

Em seguida, torne o script executável e o invoque:

openstack@controller:~$ chmod +x keystone-endpoints.sh 
openstack@controller:~$ ./keystone-endpoints.sh 
+-------------+----------------------------------+
|   Property  |              Value               |
+-------------+----------------------------------+
| description |    OpenStack Compute Service     |
|      id     | 7e658862c9244b0da03b0c7497681b9a |
|     name    |               nova               |
|     type    |             compute              |
+-------------+----------------------------------+
(...)

Com isso, temos o Keystone configurado.

Glance

Glance é o serviço de controle de imagens do OpenStack. Vamos instalar os pacotes:

openstack@controller:~$ sudo apt-get install glance glance-api glance-registry python-glanceclient glance-common

Configure as seguintes opções em ambos os arquivos /etc/glance/glance-api.conf e /etc/glance/glance-registry.conf:

sql_connection = mysql://glance:openstack@localhost/glance
admin_tenant_name = service
admin_user = glance
admin_password = password

Os arquivos possuem outras opções, deixe-as como estão. Apenas para o glance-api.conf, configure estas opções:

notifier_strategy = rabbit
rabbit_password = openstack

Agora é questão de reiniciar os serviços e carregar os dados do Glance no MySQL:

openstack@controller:~$ sudo  service glance-api restart
openstack@controller:~$ sudo  service glance-registry restart
openstack@controller:~$ sudo glance-manage db_sync

Em seguida, baixar uma imagem do Ubuntu pronta para a nuvem e registrá-la no Glance. Observe como o serviço é flexível: você pode informar a URL, não precisa baixar a imagem previamente.

openstack@controller:~$ glance image-create \
> --location http://uec-images.ubuntu.com/releases/12.04/release/ubuntu-12.04-server-cloudimg-amd64-disk1.img \
> --is-public true --disk-format qcow2 --container-format bare --name "Ubuntu"
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | None                                 |
| container_format | bare                                 |
| created_at       | 2013-04-23T16:43:17                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 6aa23a63-f2eb-45cc-98bf-7e3d8becc6a4 |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | Ubuntu                               |
| owner            | None                                 |
| protected        | False                                |
| size             | 251789312                            |
| status           | active                               |
| updated_at       | 2013-04-23T16:43:17                  |
+------------------+--------------------------------------+
openstack@controller:~$ glance image-list
+--------------------------------------+--------+-------------+------------------+-----------+--------+
| ID                                   | Name   | Disk Format | Container Format | Size      | Status |
+--------------------------------------+--------+-------------+------------------+-----------+--------+
| 6aa23a63-f2eb-45cc-98bf-7e3d8becc6a4 | Ubuntu | qcow2       | bare             | 251789312 | active |
+--------------------------------------+--------+-------------+------------------+-----------+--------+

Nova

O Nova é o serviço de computação, que trata da criação das máquinas virtuais. Apesar do controlador cuidar da gerência, também vamos instalar o Nova, para manter a uniformidade na nuvem e facilitar a configuração. Partimos para a instalação de pacotes:

openstack@controller:~$ sudo apt-get install nova-api nova-cert nova-common \
> nova-scheduler python-nova python-novaclient nova-consoleauth novnc \
> nova-novncproxy

O arquivo /etc/nova/api-paste.ini deve ser alterado nos seguintes campos:

admin_tenant_name = service
admin_user = nova
admin_password = password

Os campos abaixo deve ser removidos porque instalaremos o serviço Cinder nas próximas etapas, que trata de gerenciar os volumes, eliminando a necessidade do Nova fazer o mesmo. Comente as linhas abaixo no mesmo arquivo.

============================================================
[composite:osapi_volume]
use = call:nova.api.openstack.urlmap:urlmap_factory
/: osvolumeversions
/v1: openstack_volume_api_v1
============================================================

============================================================
[composite:openstack_volume_api_v1]
use = call:nova.api.auth:pipeline_factory
noauth = faultwrap sizelimit noauth ratelimit osapi_volume_app_v1
keystone = faultwrap sizelimit authtoken keystonecontext ratelimit osapi_volume_app_v1
keystone_nolimit = faultwrap sizelimit authtoken keystonecontext osapi_volume_app_v1
============================================================

============================================================
[app:osapi_volume_app_v1]
paste.app_factory = nova.api.openstack.volume:APIRouter.factory
============================================================

============================================================
[pipeline:osvolumeversions]
pipeline = faultwrap osvolumeversionapp

[app:osvolumeversionapp]
paste.app_factory = nova.api.openstack.volume.versions:Versions.factory
============================================================

Vamos agora editar o arquivo /etc/nova/nova.conf com as seguintes modificações:

[DEFAULT]

# MySQL Connection #
sql_connection=mysql://nova:openstack@192.168.0.2/nova

# nova-scheduler #
rabbit_password=openstack
scheduler_driver=nova.scheduler.simple.SimpleScheduler

# nova-api #
cc_host=192.168.0.2
auth_strategy=keystone
s3_host=192.168.0.2
ec2_host=192.168.0.2
nova_url=http://192.168.0.2:8774/v1.1/
ec2_url=http://192.168.0.2:8773/services/Cloud
keystone_ec2_url=http://192.168.0.2:5000/v2.0/ec2tokens
api_paste_config=/etc/nova/api-paste.ini
allow_admin_api=true
use_deprecated_auth=false
ec2_private_dns_show_ip=True
dmz_cidr=169.254.169.254/32
ec2_dmz_host=192.168.0.2
metadata_host=192.168.0.2
metadata_listen=0.0.0.0
enabled_apis=ec2,osapi_compute,metadata

# Networking #
network_api_class=nova.network.quantumv2.api.API
quantum_url=http://192.168.0.2:9696
quantum_auth_strategy=keystone
quantum_admin_tenant_name=service
quantum_admin_username=quantum
quantum_admin_password=openstack
quantum_admin_auth_url=http://192.168.0.2:35357/v2.0
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver

# Cinder #
volume_api_class=nova.volume.cinder.API

# Glance #
glance_api_servers=192.168.0.2:9292
image_service=nova.image.glance.GlanceImageService

# novnc #
novnc_enable=true
novncproxy_base_url=http://192.168.122.2:6080/vnc_auto.html
vncserver_proxyclient_address=192.168.0.2
vncserver_listen=0.0.0.0

# Misc #
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=true

O comando abaixo serve para popular o banco de dados ‘nova’ com as tabelas necessárias. É recomendável executá-lo como root, em alguns instalações houve erros quando executado como usuário comum.

root@controller:~# nova-manage db sync
2013-04-25 10:43:28 11425 DEBUG nova.utils [-] backend <module 'nova.db.sqlalchemy.migration' from '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/migration.pyc'> __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:506

A mensagem de DEBUG parece ser um problema da versão, mas não impede que o Nova funcione corretamente. Para finalizar, reiniciamos todos os serviços do Nova:

openstack@controller:/etc$ sudo service nova-api restart
openstack@controller:/etc$ sudo service nova-cert restart
openstack@controller:/etc$ sudo service nova-consoleauth restart
openstack@controller:/etc$ sudo service nova-scheduler restart
openstack@controller:/etc$ sudo service nova-novncproxy restart

Com isso, finalizamos o Nova.

Cinder

O Cinder possui uma funcionalidade que já existe no Nova, a gerência de blocos. Porém, essa funcionalidade está sendo separada em novo componente para facilitar a manutenção do Nova. Vamos instalar os pacotes do Cinder:

openstack@controller:~$ sudo apt-get install -y cinder-api cinder-scheduler cinder-volume iscsitarget open-iscsi iscsitarget-dkms python-cinderclient linux-headers-`uname -r`

Em seguida, inicializar os serviços iSCSI:

openstack@controller:~$ sudo sed -i 's/false/true/g' /etc/default/iscsitarget
openstack@controller:~$ sudo modprobe iscsi_trgt
openstack@controller:~$ service iscsitarget start
openstack@controller:~$ sudo service open-iscsi start

Coloque as seguintes opções no /etc/cinder/cinder.conf:

[DEFAULT]
sql_connection = mysql://cinder:openstack@localhost:3306/cinder
rabbit_password = openstack
rootwrap_config = /etc/cinder/rootwrap.conf
api_paste_confg = /etc/cinder/api-paste.ini
iscsi_helper = tgtadm
volume_name_template = volume-%s
volume_group = cinder-volumes
verbose = True
auth_strategy = keystone
state_path = /var/lib/cinder
volumes_dir = /var/lib/cinder/volumes

Altere as seguintes opções no /etc/cinder/api-paste.ini

admin_tenant_name = service
admin_user = cinder
admin_password = openstack

Precisamos utilizar agora o segundo disco da máquina controller. Se você executou a primeira seção deste tutorial sem problemas, deve haver um disco em /dev/sdb ou e /dev/vdb de 5Gb pronto para ser usado. Crie uma partição no dispositivo e depois execute os seguintes comandos:

openstack@controller:~$ sudo pvcreate /dev/sdb1
openstack@controller:~$ sudo vgcreate cinder-volumes /dev/sdb1

Com isso, configuramos um volume LVM para o Cinder. O sistema LVM é interessante pois permite adicionar mais espaço a partições sem a necessidade de reiniciar o servidor. Com isso feito, basta carregar o banco de dados do Cinder e reiniciar os serviços. Novamente, pode ocorrer uma mensagem de DEBUG na sincronização do banco. Ignore-a.

openstack@controller:~$ sudo service cinder-api restart
openstack@controller:~$ sudo service cinder-scheduler restart
openstack@controller:~$ sudo service cinder-volume restart

Com isso, finalizamos o Cinder.

Quantum

O Quantum é o serviço de configuração de redes da nossa nuvem. Vamos instalá-lo:

[soucecode language=”bash”]
openstack@controller:~$ sudo apt-get install quantum-server
[/sourcecode]

Deixe o arquivo /etc/quantum/quantum.conf com as opções da seguinte forma:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_password = openstack

Deixe o arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini com as opções da seguinte forma:

sql_connection = mysql://quantum:openstack@localhost:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
enable_tunneling = True

Deixe o arquivo /etc/quantum/api-paste.ini com as opções da seguinte forma:

admin_tenant_name = service
admin_user = quantum
admin_password = openstack

Inicialize o serviço:

openstack@controller:~$ sudo service quantum-server restart

Dashboard

O Dashboard é a interface web do OpenStack. Sua configuração é fácil, basta instalar os pacotes:

openstack@controller:~$ sudo apt-get install apache2 libapache2-mod-wsgi openstack-dashboard memcached python-memcache

Terminamos o Controller! Agora acesse http://192.168.122.2/horizon e entre com o usuário ‘admin’ e a senha ‘openstack’. Se por acaso tiver algum problema, verifique se todos os serviços estão ativados na opção “Serviços” do DashBoard. O Rabbit não está lá, mas você pode ativá-lo com:

openstack@controller:/etc/init$ sudo update-rc.d rabbitmq-server enable
openstack@controller:/etc/init$ sudo service rabbitmq-server start

Configuração de Um Ambiente de Testes para o OpenStack – Parte 1 – Máquinas Virtuais

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Vou apresentar aqui uma série de posts sobre a configuração de um ambiente de testes para o OpenStack. O objetivo desses posts é explicar como criar um ambiente de testes para a solução de nuvens IaaS OpenStack. Irei instalar os componentes do OpenStack (controller, network e compute) em três máquinas virtuais diferentes, de acordo com o tutorial encontrado no site do projeto. Para criação das máquinas virtuais, será usado o KVM. Para todos os efeitos, esse tutorial foi desenvolvido para o Ubuntu 12.04 LTS 64 Bits. A primeira parte trata da criação das máquinas virtuais.

Instalação e Configuração das Máquinas Virtuais

Instalação do KVM

O primeiro passo é verificar se seu sistema suporta virtualização por hardware. A maioria dos sistemas lançados depois do Intel Core 2 Duo possui suporte a virtualização. A exceção é o caso dos processadores da linha Atom. Para testar se o seu sistema tem suporte, execute o seguinte comando:

~$ sudo kvm-ok

Se a resposta for

INFO: /dev/kvm exists
KVM acceleration can be used

então seu sistema está configurado com o suporte ao KVM.

Agora vamos instalar os pacotes necessários:

~$ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virtinst

E adicione seu usuário ao grupo libvirtd. Depois disso, será necessário sair e logar novamente:

~$ sudo adduser `id -un` libvirtd

Com esses passos, você pode verificar a instalação com o seguinte comando:

~$ virsh -c qemu:///system list
 Id Name                 State
----------------------------------

Mais informações sobre a instalação do KVM na página do Ubuntu sobre o projeto

Criação das Máquinas Virtuais

Iremos criar três máquinas com as seguintes características:

Máquina Controller Network Compute
Discos 2 discos de 5G 1 disco de 5G 1 disco de 5G
Rede Externa (Host NAT) 192.168.122.2/24 192.168.122.3/24 192.168.122.4/24 (veja observação no final)
Rede Gerência 192.168.0.2/24 192.168.0.3/24 192.168.0.4/24
Rede Dados 10.10.10.2/24 10.10.10.3/24

As máquinas terão duas ou três interfaces de rede. O papel de cada rede ficará mais claro no decorrer do tutorial. Para a Rede Externa, a configuração ‘default’ do KVM é suficiente. Precisamos criar mais duas redes no KVM, Gerência e Dados, que não terão acesso a Internet. Servem para comunicação entre as máquinas virtuais. A primeira rede é definida no arquivo gerencia.xml:

<network>
	<name>gerencia</name>
        <bridge name="virbr1" />
        <ip address="192.168.0.1" netmask="255.255.255.0"/>
</network>

A outra rede é definida em um arquivo dados.xml:

<network>
	<name>dados</name>
        <bridge name="virbr2" />
        <ip address="10.10.10.1" netmask="255.255.255.0"/>
</network>

Em seguida, execute os comandos:

~$ virsh net-define dados.xml 
~$ virsh net-define gerencia.xml 
~$ virsh net-autostart dados
~$ virsh net-autostart gerencia
~$ virsh net-start dados
~$ virsh net-start gerencia
~$ virsh net-list
Name                 State      Autostart
-----------------------------------------
dados                active     yes       
default              active     yes       
gerencia             active     yes 

Por segurança, guarde os XMLs em uma pasta chamada networks/ no seu diretório de usuário. Agora, vamos para a criação das máquinas virtuais. Nós vamos criar as máquinas usando a versão 12.04.1 LTS do Ubuntu Server. Usaremos 512Mb de RAM para cada máquina. Novamente, é um ambiente de teste, desempenho não é o objetivo principal. Vamos começar pela Controller. Execute o comando abaixo:

~$ virt-install \
--connect qemu:///system \
--virt-type kvm --name Controller \
--ram 512 \
--disk path=/home/usuario/openstack/disks/controller1.img,size=5 \
--disk path=/home/usuario/openstack/disks/controller2.img,size=5  \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia 

O nome da máquina é Controller, usurá 512 megabytes de RAM. Dois discos são criados, cada um com 5 Gigabytes. Essa máquina dará boot pelo CD de instalação do Ubuntu. Duas interfaces de rede serão criadas, uma default (NAT) e outra privada. Agora execute os seguintes comandos para ter acesso à máquina pelo protocolo VNC:

~/openstack$ virsh list --all
 Id Name                 State
----------------------------------
  2 Controller           running
~/openstack$ virsh vncdisplay 2
:0
~/openstack$ vncviewer 127.0.0.1:0

A partir daí podemos instalar a máquina. Crie o usuário ‘openstack’ e a senha ‘openstack’. Não se preocupe, o SSH não é acessível pela Internet, está protegido pelo NAT. Use o mesmo par usuário/senha nas outras máquinas. O importante é lembrar de instalar o OpenSSH Server para termos acesso externo. Após a instalação, a máquina será desligada. Você deve reativá-la:

~$ virsh start Controller
~$ virsh list 
 Id Name                 State
----------------------------------
  3 Controller           running
~$ virsh vncdisplay 3
~$ :0

Observação: caso você esteja montando o ambiente de teste em uma máquina remota, não conseguirá acessar o VNC do KVM. O VNC não é criptografado por padrão, portanto ele só escuta no endereço 127.0.0.1. A saída é usar um túnel SSH da seguinte forma:

~$ ssh -L <porta_local>:<127.0.0.1>:<porta_destino> -N -f <usuario>@<maquina_destino>
~$ vncviewer 127.0.0.1:0

Só como exemplo de configuração de rede, o arquivo /etc/network/interfaces do Controller deve ficar assim:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.122.2
        netmask 255.255.255.0
        network 192.168.122.0
        broadcast 192.168.122.255
        gateway 192.168.122.1
        dns-nameservers 192.168.122.1

auto eth1
iface eth1 inet static
        address 192.168.0.2
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        ### static routing ###
        post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
        pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

As outras máquinas devem ser configuradas de forma semelhante de acordo com a tabela acima. Não vou mostrar esses passos. Para finalizar, os comandos para criar as outras duas máquinas são:

virt-install \
--connect qemu:///system \
--virt-type kvm \
--name Network \
--ram 512 \
--disk path=/home/usuario/openstack/disks/network.img,size=5G \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia  --network network=dados
virt-install \
--connect qemu:///system \
--virt-type kvm \
--name Compute \
--ram 512 \
--disk path=/home/usuario/openstack/disks/compute.img,size=5 \
--vnc \
--cdrom /home/usuario/openstack/ubuntu-12.04.1-server-amd64.iso \
--network network=default --network network=gerencia  --network network=dados     

Observação importante: No comando de criação da máquina Compute, estamos colocando também a rede default, que é a Rede Externa (Host Nat). Pela tabela acima e de acordo com o tutorial que tomamos como base, essa rede não seria necessária. Entretanto, quando formos configurar o nó, vamos precisar da Internet para poder instalar os pacotes. Então vamos proceder como se colocássemos o endereço 192.168.122.4 na máquina Compute, mas depois vamos desativá-lo.

Inicialização sem Disco pela Rede (PXE) no Ubuntu 12.04

1. Introdução

O objetivo deste tutorial é descrever a configuração necessária para permitir que um computador cliente realize boot pela rede, carregando uma instalação de sistema operacional que está armazenada em um servidor na mesma subrede. Esse cenário não se trata de thin clients. Uma cópia completa do sistema operacional estará em execução no computador cliente, inclusive os processos das aplicações. Quando se fala em thin client, os processos executam no servidor, o cliente apenas exibe os resultados remotamente.

Para a solução de inicialização sem disco, o cliente precisa suportar boot através do ambiente PXE (Preeboot Execution Environment). Este ambiente é responsável pela configuração da rede e cópia dos arquivos necessários do servidor. Sua ativação é realizada através da configuração das opções de boot na BIOS do computador. A princípio, discos ou outro tipo de armazenamento não são necessários no cliente.

O servidor precisa executar serviços de configuração automática de rede (DHCP) e transferência de arquivos (TFTP) para permitir o uso do PXE pelo cliente. O DHCP fornece um endereço IP ao cliente para permitir a comunicação TCP/UDP. O após a configuração de rede, a transferência de um kernel e de um arquivo initramfs é feita através do TFTP. Com isso a máquina cliente consegue carregar o kernel e o sistema inicializa. Mas para se tornar útil, precisamos de uma instalação completa de uma distribuição Linux. A solução é armazenar essa instalação em um diretório do servidor e compartilhá-la com os clientes através de NFS. Esse detalhe é muito importante, pois exige que o kernel enviado ao cliente tenha suporte à NFS.

O restante do tutorial se organiza da maneira descrita a seguir. Primeiro vamos tratar da configuração do serviços DHCP e TFTP. Em seguida, vamos criar no servidor um diretório com a instalação Linux que será carregada no cliente e configurá-la adequadamente. O próximo passo é a configuração de um kernel para boot no cliente. Por último, daremos boot na máquina cliente. Para todos os propósitos, os comandos são executados no Ubuntu 12.04 LTS AMD64. Usamos um servidor e um cliente para demonstração.

2. Configuração dos Serviços

2.1 Configuração do DHCP

O primeiro passo é definir qual a subrede do ambiente. Para nosso estudo de caso, consideramos a rede 10.0.0.0/255.255.255.0. O servidor terá IP 10.0.0.1 e o cliente terá IP 10.0.0.2. Para configurar a interface do cliente, é preciso colocar as informações abaixo no arquivo /etc/network/interfaces:

iface eth2 inet static
    address 10.0.0.1
    netmask 255.255.255.0
    gateway 10.0.0.1

Substitua eth2 e a faixa IP pelos valores adequados caso necessário. Depois disso, basta reiniciar as interfaces de rede:

~# service networking restart
~# service network-manager restart

Detalhe importante: não coloque ‘auto eth2’ antes da linha começando com ‘iface’. Isso evita que o network-manager tente gerenciar a interface. Com a interface configurada, é hora de instalar e configurar o DHCP.

~# apt-get install dhcp3-server
~# cat /etc/dhcp/dhcpd.conf
allow booting;
allow bootp;
subnet 10.0.0.0 netmask 255.255.255.0 {
  range 10.0.0.2 10.0.0.100;
  option broadcast-address 10.0.0.255;
  option routers 2.xxx;
  option domain-name-servers 8.8.8.8;
  filename "/pxelinux.0";
}
~# service isc-dhcp-server restart
isc-dhcp-server start/running, process 11263

O mais importante é a linha filename “/pxelinux.0”. Ela indica o caminho do arquivo que será transferido ao ambiente PXE do cliente. Este caminho é relativo ao diretório do TFTP, que iremos configurar a seguir. Caso o servidor tenha duas interfaces de rede, talvez seja importante alterar o arquivo /etc/default/isc-dhcp-server para ligar o serviço a apenas uma delas.

2.2 Configuração do TFTP

O TFTP é responsável por transferir os arquivos iniciais ao ambiente PXE. Para instalá-lo, digite os comandos abaixo.

~# apt-get install tftpd-hpa
~# cat /etc/default/tftpd-hpa 
# /etc/default/tftpd-hpa
RUN_DAEMON="yes"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"
~# mkdir /var/lib/tftpboot/pxelinux.cfg

Com isso, os arquivos presentes em /var/lib/tftpboot estarão disponíveis ao PXE. O importante agora é instalar o pacote que contém o sistema básico que será enviado e as ferramentas que permitem a criação de um kernel para o boot do cliente. Vamos aproveitar e instalar também o pacote que dá suporte ao NFS por parte do servidor.

~# apt-get install syslinux 

Podemos agora copiar os arquivos básicos para o diretório do TFTP e configurar o restante da estrutura de diretórios.

~# cp /usr/lib/syslinux/pxelinux.0 /var/lib/tftpboot/
~# mkdir /var/lib/tftpboot/pxelinux.cfg/
~# cat /var/lib/tftpboot/pxelinux.cfg/default
LABEL linux
KERNEL vmlinuz-3.2.0-23-generic-pae 
APPEND root=/dev/nfs initrd=initrd.img-3.2.0-23-generic-pae nfsroot=10.0.0.1:/nfsroot,rw ip=dhcp rw (desde APPEND tudo na mesma linha)

O parâmetro nfsroot na linha APPEND indica onde estará a distribuição Linux. Essa será acessada via o NFS, etapa que iremos configurar na próxima seção. Na pasta /var/lib/tftpboot temos que ter um kernel equivalente às linhas KERNEL e ao campo initrd da linha APPEND. Existem várias maneiras de arranjar um kernel adequado. Na seção 2.4, será detalhado como obter um kernel e um initrd adequados. Lembre-se apenas qual arquivo deve ser alterado com as informações do novo kernel (/var/lib/tftpboot/pxelinux.cfg/default).

2.3 Configuração do NFS

Caso você não tenha instalado o NFS na seção anterior, faça agora com o comando abaixo. Além disso, vamos aproveitar para criar o diretório onde estará a instalação do sistema operacional que será carregado no cliente. Para exportá-lo, precisamos também alterar o arquivo /etc/exports.

~# apt-get install nfs-kernel-server
~# mkdir /nfsroot
~# cat /etc/exports 
/nfsroot             10.0.0.0/255.255.255.0(rw,no_root_squash,async,insecure,no_subtree_check)
~# exportfs -rv
exporting 10.0.0.0/255.255.255.0:/nfsroot

Agora a pasta /nfsroot do servidor está acessível ao cliente. Falta agora colocar uma instalação Linux nela. Isso pode ser feito com o comando abaixo.

:~# debootstrap --arch amd64 precise /nfsroot/

Seria o momento para tomar um café, já que demora bastante. O que o comando debootstrap faz é realizar o download do sistema mínimo para garantir uma inicialização. Sua principal utilização talvez seja permitir executar um ambiente de testes em chroot. Após seu término, devemos entrar no ambiente instalado através do comando chroot.

~# mount -o bind /dev /nfsroot/dev
~# mount -o bind /proc /nfsroot/proc
~# mount -o bind /sys /nfsroot/sys
~# chroot /nfsroot/ 

Assim você estará dentro do console da nova instalação. A primeira sugestão é alterar o hostname. Por padrão, o nome da máquina é o mesmo do servidor. Devemos alterar os arquivos /etc/hostname e /etc/hosts para refletir o novo sistema. No nosso caso, iremos adotar ‘virtual’ como nome da máquina.

~# cat /etc/hostname
virtual
~# cat /etc/hosts   
127.0.0.1	localhost virtual
::1		localhost ip6-localhost ip6-loopback
fe00::0		ip6-localnet
ff00::0		ip6-mcastprefix
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

Você pode também instalar qualquer pacote que achar necessário com o apt-get. É aconselhável instalar o cliente do nfs.

~# apt-get install nfs-common

A configuração de rede deve ficar assim:

~# cat /etc/network/interfaces 
auto lo
iface lo inet loopback
iface eth0 inet manual

O /etc/fstab deve ficar desta forma:

~# cat /etc/fstab
proc            /proc           proc    defaults       0       0
/dev/nfs       /                nfs     defaults       1       1
none            /tmp            tmpfs   defaults       0       0
none            /var/run        tmpfs   defaults       0       0
none            /var/lock       tmpfs   defaults       0       0
none            /var/tmp        tmpfs   defaults       0       0

Não esqueça também de adicionar pelo menos um usuário ou alterar a senha de root.

~# passwd
~# adduser usuario

Quando terminar a configuração, lembre de desmontar os diretórios /proc, /dev/ e /sys. Para isso você tem que sair do ambiente chroot. Os comandos necessários são mostrados abaixo. Por enquanto, não saia do chroot, pois ele será necessário para a seção 2.4.

~# exit
~# umount  /nfsroot/dev
~# umount  /nfsroot/proc
~# umount  /nfsroot/sys

2.4 Configuração do Kernel do Cliente

Existem várias maneiras de conseguir um kernel adequado. Você pode compilar a partir do zero ou utilizar o kernel pronto do servidor. Nós vamos usar um meio termo. Vamos utilizar um kernel pré-compilado do Ubuntu vamos personalizar o arquivo initrd para conter os módulos da placa de rede da máquina cliente e do NFS.

O ambiente em chroot criado pelo debootstrap não tem kernel instalado. Basta verificar que a pasta /boot está vazia. Vamos instalar um kernel então. Também vamos instalar o pacote initramfs-tools, pois ele será necessário para criar o arquivo initrd personalizado.

~# aptitude install linux-image-3.2.0-23-generic-pae initramfs-tools

Verifique agora a pasta /boot. Você verá os arquivos vmlinuz-3.2.0-23-generic-pae e initrd.img-3.2.0-23-generic-pae. O primeiro vamos utilizar do jeito que está. Agora o segundo precisamos adaptar. Temos que alterar os arquivos /etc/initramfs-tools/initramfs.conf e /etc/initramfs-tools/modules. As versões finais dos arquivos devem ficar como abaixo abaixo:

~# cat /etc/initramfs-tools/initramfs.conf
MODULES=netboot
BUSYBOX=y
COMPCACHE_SIZE=""
COMPRESS=gzip
BOOT=nfs
DEVICE=
NFSROOT=auto
~# cat /etc/initramfs-tools/modules  	 
# Módulo da placa de rede
8139too
# Módulos do NFS
nfsd
nfs
lockd
fscache
auth_rpcgss
nfs_acl
sunrpc

Veja que no arquivo /etc/initramfs-tools/modules você precisa colocar o módulo da placa de rede do cliente. Não existe maneira simples de descobrir isso. Uma solução é inicializar o cliente com um livecd e descobrir essa informação através dos comandos lspsci e lsmod. Os outros módulos são necessários para carregar o sistema de arquivo NFS. Depois disso, o próximo passo é criar o novo initrd. Para isso, execute o comando abaixo.

#~  mkinitramfs -o /boot/initrd.img-3.2.0-23-generic-pae 3.2.0-23-generic-pae

Com isso, os arquivos do diretório estarão atualizados. Agora, saia do chroot como descrito ao final da seção 2.3 e copie os arquivos para o diretório do TFTP com os comandos abaixo.

#~ cp /nfsroot/boot/vmlinuz-3.2.0-23-generic-pae /var/lib/tftpboot
#~ cp /nfsroot/boot/initrd.img-3.2.0-23-generic-pae /var/lib/tftpboot
#~ chmod -R 777 /var/lib/tftpboot

2.5 Conclusão

Para finalizar, reinicie todos os serviços. Configure a BIOS do cliente para dar boot pela rede e reinicie a máquina. Se tudo der certo, rapidamente você estará no console da máquina cliente.

Referências

https://help.ubuntu.com/community/DisklessUbuntuHowto
https://help.ubuntu.com/community/Installation/OnNFSDrivehttps://help.ubuntu.com/community/PXEInstallServer
https://wiki.ubuntu.com/DebootstrapChroot
http://www.vivaolinux.com.br/artigo/Ubuntu-Server-1204-LTS-Como-Servidor-Gateway-e-DHCP/
http://dathan.org/docs/pxe-mini-howto.html
 

Pirataria Oficializada?

Sou um cliente Dell há muito tempo. Meu primeiro notebook foi um Dell Latitude 120L. O segundo foi um Inspiron 1525. Adquirido com recursos próprios, só tenho netbook da Asus que não é da Dell. O que me agradou na marca desde o começo, além da qualidade dos produtos, foi a possibilidade de comprar pela Web sem trauma e o suporte técnico. Este apresentou uma qualidade e profissionalismo que nunca tinha encontrado no Brasil.

Quando meu irmão expressou o desejo de trocar de notebook, prontamente indiquei o Dell Inspiron 14 N4030. Na época, cerca de um ano e meio atrás, era um ótimo custo benefício. Já vinha com um Core i3, novíssima geração, com preço abaixo dos R$ 2.000,00. Não tinha como errar. Comprei a opção de um ano de garantia porque nunca tinha tido problemas com a marca. O notebook chegou rapidamente e meu irmão ficou satisfeito.

No começo do mês, poucos meses após o fim da garantia, o Inspiron começou a ficar muito lento. Depois, uma mensagem de erro de inicialização do Windows começou a surgir quando o aparelho era ligado. A mensagem oferecia a opção de tentar reparar o Windows ou iniciar normalmente. De início, tentamos reparar o Windows. Entretanto, a opção não tinha efeito. A máquina simplesmente reiniciava e retornava à mensagem de erro.

Não vou entrar nos detalhes do diagnóstico, só irei mencionar que após utilizar um CD de recuperação chamado HIREN e realizado os próprios testes presentes na BIOS do Dell, cheguei a conclusão que o problema era bad blocks no disco rígido. Mesmo após correção e marcação dos blocos com defeito. A solução, nem tão cara hoje em dia, foi trocar o HD. Apesar de não estar na garantia, pude fazer a trocar sem problemas. Foi quase como trocar um cartucho de jogo no Mega Drive.

O drama começou quando fui tentar reinstalar o sistema operacional. Como comprei o computador com uma licença, gostaria de reutilizá-la. Trocar o HD não constitui um novo computador, então não haveria problema legal em reutilizar a licença. O problema é que o notebook não veio com nenhuma mídia de instalação. A única maneira de recuperar o sistema seria utilizar uma partição de recuperação que estava no HD danificado. Ou seja, se pifar seu HD e você estiver fora da garantia, recuperar sua licença não será fácil.

A minha primeira atitude foi entrar em contato com a Microsoft. A resposta foi que ela nada poderia fazer. Em detalhes maiores:

Respondendo seu e-mail, de acordo com suas descrições seu produto é pré-instalado pelo Integrador (OEM). Produtos com este tipo de licença recebem configurações específicas por parte do fabricante do computador, pois dessa forma pode ser instalado e utilizado de forma adequada no equipamento onde é pré-instalado.

 Esclarecemos que a Microsoft Brasil não disponibiliza mídias deste tipo de licenciamento para abastecimento, isto deve ser feito pelo integrador (fabricante do equipamento) que fornece ao usuário final uma mídia (CD) de instalação, de restauração do sistema ou o conteúdo da instalação no HD.

 Enfatizamos que existe um contrato assinado entre a Microsoft e os fabricantes de equipamentos, onde o Integrador é quem fornece suporte técnico e uma forma de reinstalação do software.  Assim, para obter a mídia de reposição de seu Windows, solicitamos que contate o responsável por estas configurações, ou seja, o fabricante do equipamento.

Detalhe para “Enfatizamos que existe um contrato assinado entre a Microsoft e os fabricantes de equipamentos, onde o Integrador é quem fornece suporte técnico e uma forma de reinstalação do software.” .  A Dell, por contrato com a Microsoft, precisa fornecer uma maneira de reinstalar o software. Fui então para o live chat do suporte da Dell. Abaixo uma captura de tela no começo da conversa:

Captura de Tela da Conversa

Quando pergunto sobre como fazer a reinstalação, o atendente Gustavo indica o Google como fonte da mídia. Certo, alguém, em 2012, manda outro ser humano procurar no Google por uma mídia. Caro leitor, coloque “Windows 7 Home Basic 64Bits Pt-Br” no Google. Se 90% das respostas na primeira página não forem de pirataria, pago um pão de queijo ao senhor. Como alguém que trabalha com tecnologia, que passa o dia na frente de um computador conectado à Internet, pode pensar o contrário? Na minha humilde opinião, a Dell oficializa pirataria como uma opção de suporte ao não enviar mídias de reinstalação. Claro, depois que instalar o pirata e colocar o serial key anterior, tudo ficará “legalizado”. Porém, até lá estarei exposto aos riscos de baixar uma versão pirata, que já começam nos próprios sites de download.

O pior que tudo isso é desnecessário. Não quer enviar a mídia para todos, legal. O que custa deixar em uma página? Vai facilitar a pirataria? Vejam no Google se isso faz diferença. Acho que o efeito é o contrário. Tenho certeza que outras pessoas com convicções mais fracas já teriam baixado a versão Ultimate do Windows 7 e instalado. Mas sou contra a pirataria, independente de ser usuário Linux e entusiasta Open Source. Gostaria muito de poder instalar uma licença que comprei legalmente no nosso computador. Mas pelo visto a Microsoft e a Dell preferiram institucionalizar a pirataria.

Para quem estiver afim de diversão, no link abaixo a conversa completa.

ConversaComADell

Getúlio

Acabei de ler Getúlio 1882 – 1930. Uma boa leitura, algo que consegui ler até no ônibus durante as viagens Fortaleza-Quixadá. Como o lançamento é recente, não faltam avaliações de gente mais competente em jornais ou outros blogs. Prefiro falar sobre o que aprendi sobre a figura de Getúlio do que sobre os méritos literários do livro.

Não há como falar de Getúlio sem falar do Rio Grande. E não há como falar do Rio Grande de Getúlio sem mencionar a Revolução Federalista. Foi um conflito sangrento logo após a Proclamação da República que dividiu o estado por anos. De um lado, os “maragatos” que faziam oposição ao modelo da república recém criada. Do outro, os “pica-paus”, seguidores de Júlio de Castilhos, governador rio-grandense e vedete do positivismo brasileiro. Com o apoio federal, os “pica-paus” venceram, porém o sangue derramado manchou as relações políticas gaúchas por muito tempo. As estimativas são de 10.000 mortos. O pai de Getúlio, o veterano da Guerra do Paraguai Manoel Vargas, foi “pica-pau” e essa foi a vertente política adotada pela família. Acho que até que o livro poderia dedicar um pouco mais de atenção a Revolução Federalista, mas como é uma biografia de Getúlio, natural considerar que o leitor já tenha conhecimento de eventos importantes da história do Brasil.

Getúlio desenvolveu sua carreira política em um estado onde brigar com a oposição não significava apenas por em risco a governabilidade, pois sempre havia a possibilidade real de desentendimentos levarem a uma guerra civil. Talvez por isso, nos anos posteriores, ele demonstrou uma hesitação em romper abertamente com Washington Luís que quase levou à loucura seus aliados mais próximos, como João Neves da Fontoura e Osvaldo Aranha. E são os capítulos finais, que relatam toda a organização política para formação da Aliança Liberal e do Golpe de 30, que fornecem os momentos mais emocionantes do livre. É possível sentir nas páginas a tensão em que Getúlio se encontrava, forçado a tomar uma posição contra o governo do qual fizera parte como ministro. Para mim, fica sempre a dúvida: era Getúlio muito cauteloso ou um verdadeiro mestre Sith, sempre moldando a realidade de acordo com seus desejos, sem nunca se expor totalmente.

Uma boa leitura. E com certeza irei atrás das outras biografias escritas pelo Lira Neto, em especial a de Padre Cícero.

Greve todo ano?

Um serviço essencial para a população deve sim ter sua tarifa controlada. Entretanto, mesmo que o poder aquisitivo da população cresça, o lucro dos empresários não aumentará. Afinal, ninguém gasta o dinheiro extra do final do mês em viagens de ônibus.

O poder aquisitivo da camada mais pobre da população brasileira cresceu nos últimos anos. Isso, claro, levou a uma inflação um pouco maior. Portanto, é válida a reclamação dos trabalhadores do transporte público por melhores salários.

Em um cenário em que a tarifa não é ditada pelo mercado e há pressão por aumentos por parte dos motoristas e cobradores, a única solução é diminuir o lucro dos empresários. Enquanto tais lucros são exorbitantes, a sociedade bate palmas. Mais se o cenário continuar se repetindo, a tendência é um lucro cada vez menor. Quem vai investir em um negócio no qual a previsão é diminuição de lucro? O jeito vai ser economizar em outras áreas, manter a frota sucateada e as linhas com cada vez menos ônibus.

O que estou querendo dizer que é uma tarifa fixa é uma abominação em uma economia de mercado. Isso todo mundo sabe. Mas também deixá-la flutuar pode ser prejudicial a população. Não conheço o modelo de concessão da prefeitura de Fortaleza. Mas assim como para outros serviços essenciais, é importante ter competição. Talvez contratos mais curtos, divisão de linhas mais lucrativas baseada no desempenho da empresa, não sei qual seria o ideal. Agora enquanto algum dos prefeituráveis não sentar a bunda no escritório e imaginar uma solução, todo ano teremos o mesmo sufoco.