Criando Imagens pro VMware

Aqui vai um roteiro rápido para produção de imagens do VMware a partir de umas anotações que fiz durante a produção da Maemo SDK VMware Appliance aqui no INdT.

Disco Virtual

Usamos o qemu-img para criar um HD virtual de 7G. O arquivo criado possui inicialmente 960k, ele irá crescer conforme a necessidade até atingir o tamanho máximo.

$ qemu-img create -f vmdk maemo-sdk.vmdk 7G

Descritor da imagem

Um arquivo VMX descreve as características da máquina virtual da sua imagem. Essa imagem tem 512M de RAM, a ide0 aponta para o disco virtual que criamos (maemo-sdk.vmdk), a ide1 apontando para o arquivo ISO que contém o sistema a ser instalado. Pra o arquivo a seguir foi criado um link simbólico chamado cdrom.iso para o cd de instalação do Xubuntu.

Arquivo de exemplo: maemo-sdk.vmx

#!/usr/bin/vmware
#
displayName = "Linux 2.6.x Host"
guestOS = "otherlinux"
#
config.version = "8"
virtualHW.version = "4"
memsize = "512"
#
ide0:0.present = "TRUE"
ide0:0.fileName = "maemo-sdk.vmdk"
#
ide1:0.present = "TRUE"
ide1:0.autodetect = "FALSE"
ide1:0.startConnected = "TRUE"
ide1:0.fileName = "cdrom.iso"
ide1:0.deviceType = "cdrom-image"
#
floppy0.present = "FALSE"
usb.present = "TRUE"
sound.present = "TRUE"
#
displayuName = "Maemo SDK Appliance"
#
checkpoint.vmState = ""
#
scsi0:0.redo = ""
ide0:0.redo = ""
#
extendedConfigFile = "maemo-sdk.vmxf"
virtualHW.productCompatibility = "hosted"
tools.upgrade.policy = "manual"
#
isolation.tools.hgfs.disable = "FALSE"
#
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.generatedAddress = "00:0c:29:c7:60:13"
ethernet0.generatedAddressOffset = "0"
uuid.location = "56 4d 4b 68 5e 47 c7 0b-33 1f 73 b1 f9 c7 60 13"
uuid.bios = "56 4d 4b 68 5e 47 c7 0b-33 1f 73 b1 f9 c7 60 13"
tools.remindInstall = "FALSE"
#
uuid.action = "create"
#
sharedFolder.option = "alwaysEnabled"
tools.syncTime = "TRUE"
#
usb.autoConnect.device0 = ""
#
floppy0.fileName = "/dev/fd0"

Instalacão do Sistema

Rodamos o VMWare Player

$ vmplayer maemo-sdk.vmx

e procedemos como numa instalação comum.

Pós-instalacão

Depois de tudo pronto desabilitamos o cdrom, substituindo o trecho

ide1:0.present = "TRUE"
ide1:0.autodetect = "FALSE"
ide1:0.startConnected = "TRUE"
ide1:0.fileName = "cdrom.iso"
ide1:0.deviceType = "cdrom-image"

por

ide1:0.present = "FALSE"

Daí podemos remover pacotes desnecessários para emagrecer a imagem. O OpenOffice.org é um dos mais obesos e provavelmente o sujeito que pegar a imagem já vai ter algum office instalado no sistema host. Para descobrir bons alvos para matar vá na linha de comando do sistema instalado na imagem e dê um:

dpkg-query -W --showformat='${Installed-Size} ${Package}\n' | sort -n

Pra facilitar um pouco, eis a lipo que fiz no Xubuntu:

apt-get remove --purge libpurple0 gimp-print cdparanoia wireless-tools ubuntu-standard network-manager avahi-daemon gnome-games gnome-cards-data dvd+rw-tools abiword-common abiword powernowd gnumeric-common pidgin-data parted network-manager-gnome gnumeric-gtk libnss-mdns tasksel-data laptop-mode-tools avahi-autoipd ubuntu-minimal gnome-games-data mozilla-thunderbird powermanagement-interface xubuntu-desktop tasksel acpi-support gimp wpasupplicant laptop-detect pidgin displayconfig-gtk brasero hotkey-setup abiword-plugins gimp-data example-content thunderbird orage apport apport-gtk python-apport update-manager update-manager-core update-notifier update-notifier-common xfce4-appfinder

Cuidado que essa lista pode não ser legal para a sua appliance, analise com cuidado. Um dos efeitos colaterais das remoções acima foi a conexão de rede da imagem parar de funcionar, devido à ausência do NetworkManager (que não faz muito sentido numa imagem). Foi necessário editar o /etc/network/interfaces e acrescentar as linhas:

auto eth0
iface eth0 inet dhcp

Depois reinicie as interfaces de rede:

sudo /etc/init.d/networking restart

Outra coisa útil é habilitar o login automático com o GDM, para isso basta is em System->Administration->Login Window e na aba Security marque Enable Automatic Login com o usuário que criado na instalação. Ainda na mesma aba, na seção Permissions escolha Allow login if all write permissions on user’s home directory (alguém me contou que isso resolve um inexplicável bug do tema).

Depois você pode acrescentar as aplicações relevantes, mudar o tema, etc.

VMware Tools e Open Virtual Machine Tools

VMware Tools são ferramentas que podem ser instaladas no sistema da imagem vmware e que acrescentam funcionalidades de arrastar e soltar arquivos e cópia e colagem de texto entre o sistema hospedeiro e o sistema virtualizado. Além disso faz com que o ponteiro do mouse não fique preso na janela do VMware Player, o que ajuda muito os claustrofóbicos e as pessoas que não gostam de sentir presas.

O problema do VMware Tools é que ele não pode ser livremente distribuído junto com a imagem que você produziu, o que significa que o usuário deverá proceder a instalação por conta própria, o que é uma droga. Ainda mais porque a obtenção do instalador é meio cabeluda.

Felizmente a VMware liberou os tools sob licenças GPL, LGPL e compatíveis, criando o projeto Open Virtual Machine Tools. Infelizmente tem sido um cu de boi pra instalar essa coisa! Ou seja, tem make install não mermão! A documentação sobre empacotamento ajudou bastante, mas ainda era coisa muito chata, mas eis que de repente surge Daniel Baumann do Debian e empacota os tools pro repositório experimental. \o/

Update: depois de instalar pacotes na imagem não esqueça de dar um sudo apt-get clean para remover os debs do diretório /var/cache/apt/archives.

Anúncios

Pacote Debian do Vala

Hoje Alberto Ruiz (que parece assustadoramente com um amigo meu; alô Icaro!) fez um binding Vala pro GtkMozEmbed, daí me empolguei e fiz um pacote Debian do bicho. Estava num Ubuntu Gutsy e não testei em nenhuma outra máquina, então só garanto funcionar do Gutsy pra cima (dica: precisa libglib maior igual a 2.12.9).

Download: vala_0.1.2-1_i386.deb

Se quiser experimentar uns códigos (com um esclarecedor Makefile), veja o post anterior sobre Vala.

Já criei um binding pro Hildon que deve deixar os manos do INdT felizes, só falta arrumar uma coisa e outra e mando o patch.

“Deployment” em Windows com Py2Exe e NSIS

Deployment segundo a wikipedia:

Software deployment é toda atividade que torna um sistema de software disponível para uso.

Como o TagMap é feito em Python+GTK, e pelo que vi o público interessado é composto majoritariamente de usuários de windows, pedir que eles instalem Python, GTK+ e PyGTK pra só então chegar em meu humilde programa, certamente seria uma barreira. Claro que tem o excelente All-in-one PyGTK for windows installer, mas se dá pra facilitar por quê não?

As duas ferramentas necessárias são o Py2Exe, responsável por tornar o script um legítimo executável, e o NSIS, que serve para criar instaladores next-next-finish e que vai fazer todo mundo te olhar como gente grande. ;P

Py2Eexe

O Py2Exe cria o executável a partir de um arquivo de configuração, no caso do TagMap foi o setup_win32.py. Observando o arquivo você verá que não é muito complicado, só substituir alguns valores e pronto; claro que mudanças maiores vão exigir algum estudo, mas se o seu projeto for em PyGTK com Glade pode pegar o meu e apenas trocar os valores (como eu mesmo fiz 😉 ).

No prompt do DOS (ugh!) e no diretório do programa execute:

python setup_win32.py py2exe

Depois de algum trabalho por parte do script será gerado um diretório dist contendo (no meu caso) tagmap.exe, alguns DLLs e outros arquivos. Para executar em qualquer computador basta instalar antes GTK, mas ele também pode ser embutido.

Uma bom código para observar e aprender (e copiar) é o do GAJIM.

NSIS

Com o MakeNSIS que vem com o Nullsoft Scriptable Install System você pode ler um script que descreve o roteiro das perguntas feitas pelo instalador next-next-finish. Claro que ninguém vai ler só apertar o botão insistentemente até chegar no final. Meus scripts são o installer.nsi e installer_gtk.nsi, ambos podem ser facilmente adaptados para outros projetos. Como o nome deve indicar, o segundo script cria um instalador que coloca o GTK junto com o programa, pode parecer um desperdício de espaço, mas com as conexões rápidas e os HDs grandes de hoje em dia esse é um problema muito menor que mandar o usuário baixar um monte de dependências manualmente.

Bem, não tem muito mais o que explicar, até porque ainda estou aprendendo, mas um tutorial completo e direto pode ser encontrado em PyGTK and Py2Exe HowTo.

E os instaladores do TagMap (numa versão muito alfafa) pra windows, com e sem GTK:

P.S.: Um agradecimento especial pra minha gatinha que pacientemente me ajudou a testar. :*

Pacote Debian/Ubuntu para o LogicParser

Seguindo esse excelente tutorial, consegui fazer um pacote pra instalar o LogicParser em distribuições derivadas do Debian. Antes de explicar como foi, tenho de dizer que fazer o primeiro pacote .deb é totalmente lol. Não me perguntem por quê, é algo totalmente emocional. 😉

LogicParser Debian Package

A coisa foi muito facilitada por eu já estar usando autotools no projeto, como expliquei num post anterior, e pelo fato da aplicação ser bem simples. Tudo que tive de fazer foi usar um par de utilitários debian: dh_make e debuild.

Para instalar o que é preciso (além do build-essential):

apt-get install dpkg-dev debhelper devscripts fakeroot linda dh-make

Agora é necessário criar um diretório debian dentro do diretório da aplicação. Normalmente eu trabalho com a versão do SVN num diretório chamado logicparser, mas para fazer o pacote .deb é necessário usar um esquema de nome que inclua a versão da aplicação separada por um hífen, então fiz uma cópia chamada logicparser-0.7.2.

Uma vez dentro de logicparser-0.7.2 executei o comando

dh_make --native --single --email meuemail@mail.com

Isso cria um diretório debian com vários arquivos template, a maioria desnessária para uma aplicação simples, então foram apagados:

rm debian/*.ex debian/*.EX debian/README*

O parâmetro –native significa pacote debian nativo, que foi a forma que escolhi pra fazê-los; –single diz que a aplicação consiste de apenas um executável.

O único arquivo que precisou ser alterado foi o debian/control, para acrescentar uma descrição, a versão e arquitetura alvo:

Source: logicparser
Section: universe/misc
Priority: optional
Maintainer: Marcelo Lira dos Santos <meuemail@email.com>
Build-Depends: debhelper (>= 5), autotools-dev
Standards-Version: 0.7.2

Package: logicparser
Architecture: i386
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Simple parser and calculator for logic propositional expressions. Parser of logical propositions. It generates a parsed tree, a graph in DOT format, and renders it in PNG if GraphViz is available. It also calculates the expression based in values given by the user.

Em seguida a compilação via o script debian/rules dentro de um ambiente fakeroot:

fakeroot debian/rules binary

E finalmente as criação do pacote .deb (ele deve aparecer fora do diretório logicparser-0.7.2):

debuild -us -uc

Esses dois parâmetros são para desabilitar a assinatura de pacotes, o que me faz lembrar que já tá na hora de eu arrumar uma chave PGP…

Foi mais fácil do que pensei, embora saiba que a coisa pode ficar bem mais elaborada. Depois vou ver como automatizar ainda mais o processo a ponto de dar um make deb ou algo assim.

Downloads:

O primeiro Autotools é inesquecível!

Depois de muitas e muitas baixadas de tar.gzês de terceiros, pra descompactar e dar ./configure ; make ; make install, usar autotools em meu próprio projeto dá uma sensação muito boa! Sou praticamente gente grande! =P

Mas tenho de admitir começar foi complicado, são muitas as informações, felizmente pude contar com este excelente tutorial:

Ele faz um progresso gradual, com boas explicações e exercícios. Uma pena que o exemplo com GTK+ esteja totalmente deprecated. Para compensar esse problema e tocar meu projeto, usei um ardil descarado: criei um projeto GTK+ chamado gtk-foo no Anjuta (apt-get install anjuta autogen), sem suporte a internacionalização, pra não complicar as coisas.

Copiei os arquivos autogen.sh e configure.in, Makefile.am, aclocal.m4 e src/Makefile.am de gtk-foo para logicparser. Além disso foi necessário criar os conhecidos arquivos README, NEWS, ChangeLog, etc, conforme manda a tradição. Também foi necessário copiar alguns scripts de /usr/share/automake-1.9 para o diretório do projeto: depcomp, install-sh e missing.

Depois disso alguns ajustes precisaram ser feitos, como em lp_app.h, por exemplo, que guardava a indicação de onde encontrar o arquivo lp_gui.glade, já que o make install deveria colocar o arquivo glade em /usr/local/share/logicparser/glade.

Como ficou o trecho do header lp_app.h:

// For testing propose use the local (not installed) glade file
//#define GLADE_FILE "lp_gui.glade"
#define GLADE_FILE PACKAGE_GLADE_DIR"/lp_gui.glade"

O macro PACKAGE_GLADE_DIR é setado pelo compilador e foi definido em src/Makefile.am:

gladedir = $(datadir)/logicparser/glade
glade_DATA = lp_gui.glade

INCLUDES = \

-DPACKAGE_LOCALE_DIR=\""$(prefix)/$(DATADIRNAME)/locale"\" \
-DPACKAGE_SRC_DIR=\""$(srcdir)"\" \
-DPACKAGE_DATA_DIR=\""$(datadir)"\" \
-DPACKAGE_GLADE_DIR=\""$(gladedir)"\" \
$(PACKAGE_CFLAGS)

AM_CFLAGS =\

-Wall\
-g

bin_PROGRAMS = logicparser

logicparser_SOURCES = \

logicparser.c \
lp_app.c \
lp_graph.c \
lp_test.c \
logicparser.h \
lp_app.h \
lp_graph.h \
main.c

logicparser_LDFLAGS =

logicparser_LDADD = $(PACKAGE_LIBS)

EXTRA_DIST = $(glade_DATA)

O que mais gostei nesse início de uso do Autotools foi o make dist, que gera um logicparser-x.y.z.tar.gz. E por falar nele, podem baixar a última versão (0.4.2) na seção de Downloads: http://code.google.com/p/logicparser/downloads/list

Resta aprender como incluir suporte à internacionalização (provavelmente com ajuda do Anjuta 🙂 e build para Win32. Mas agora chega, estou caindo de sono. Se interessou, veja o site do autotut mencionado acima.