Criando Aplicações Integradas de Alta Qualidade para Linux

Imagine que você vai instalar aquele produto caríssimo que sua empresa comprou da ACME, e descobre que terá de fazer o seguinte:

Soa familiar? Quem nunca passou por essa triste situação, que induz o usuário a cometer erros? Se o processo de instalação de seu produto é Descompactar-Copiar-Configurar-ConfigurarMais-Usar, como o acima, você tem um problema, e o usuário não vai gostar.

Usuários gostam de sentir que seu Produto se integra bem ao SO. Não deve exigir que o SO se adapte ao seu Produto (alterando variáveis de ambiente, etc). Deve permitir o usuário Instalar-e-Usar.

A gloria do Instalar-e-Usar é facilmente atingida usando uma receita de 3 ingredientes:

Vamos discutir aqui o que são estes ingredientes, e como implementa-los

Vamos ver a universalidade do conceito acima analizando alguns tipos aleatórios de softwares:

Percebam como o Software em Sí contém toda a lógica de negócio de seu produto, que seria inútil se não houvesse uma Configuração para definir como trabalhar com uma massa de dados, provida pelo usuário. Ou seja, as Configurações são o que ligam seu produto ao usuário.

Podemos pensar numa metáfora sobre um Escultor (software em sí), que precisa receber Bronze (conteúdo) e um Tema ou Inpiração (configuração) de um Mecenas (usuário), para produzir uma bela Obra (conteúdo). Ele anota em seu Diário (logs) as atividades de cada dia para relatar ao seu Mecenas (usuário) que está produzindo.

OK, então vamos ser mais práticos. O fato é que se aplicarmos corretamente o conceito das partes universais, aumentamos enormemente a qualidade de nosso produto. Faremos isso simplesmente separando, encapsulando, cada uma dessas partes em diretórios diferentes (separar em arquivos não é suficiente). Existe um padrão chamado Filesystem Hierarchy Standard que define os diretórios do Linux para cada parte, e vamos discutir isso mais tarde na Secção 4, “Hierarquia de Diretórios do Linux: Orientada às Partes do Software”.

Por enquanto vamos ver o valor disso para o usuário:

Vamos exercitar a separação com um exemplo de um sistema chamado MySoftware, em que a lógica de negócio está puramente no Exemplo 1, “Programa em Shell fazendo referência a configurações externas” e a configuração está em Exemplo 2, “Arquivo contendo somente as configurações para MySoftware”.

Exemplo 1. Programa em Shell fazendo referência a configurações externas

#!/bin/sh

#############################################################################
##
## /usr/bin/MySoftware
##
## Business logic of MyProgram system.
## Do not change nothing in this file. All configuration can be
## made on /etc/MySoftware.conf
##
## We'll not support any modifications made here.
##

# Default configuration file
CONF=/etc/MySoftware.conf	

# Minimal content directories
MIN_CONTENT_PATH=/var/www:/var/MySoftware/www	

if [ -r "$CONF"]; then
        . "$CONF"	
fi

# All the content I'll serve are the "minimal" plus the ones provided
# by the user in the configuration file $CONF
CONTENT_PATH=$MIN_CONTENT_PATH:$CONF_CONTENT_PATH	

.
.
.

	Definição do nome do arquivo de configuração.
	Definição de alguns parâmetros estáticos ao produto.
	A configuração é lida de um arquivo externo, se existir.
	Após a leitura da configuração, todos os diretórios de conteúdo -- do usuário + do produto -- são colocados na $CONTENT_PATH, que será usada daqui para frente.

Exemplo 2. Arquivo contendo somente as configurações para MySoftware

#############################################################################
##
## /etc/MySoftware.conf
##
## Configuration parameters for MySoftware.
## Change as much as you want.
##

# Content directory.
# A ':' separated list of directories for your content.
# The directories /var/www and /var/MySofware are already there, so
# include here your special directories, if any.
CONF_CONTENT_PATH=/var/NewInstance:/var/NewInstance2	

# Your e-mail address, for notifications.
EMAIL=john@mycompany.com	

# Logs directory
LOG_DIR=/var/log/myInstance	

O usuário define estes parâmetros.

Quando eu era o administrador de sistemas para IBM e-business Hosting Services, eu era fascinado pela flexibilidade do Apache permitindo fazer coisas deste tipo:

bash# /usr/sbin/httpd &
bash# /usr/sbin/httpd -f /etc/httpd/dom1.com.br.conf &
bash# /usr/sbin/httpd -f /etc/httpd/dom2.com.br.conf &
bash# /usr/sbin/httpd -f /etc/httpd/dom3.com.br.conf &

Se não passassemos nenhum parâmetro (como no primeiro exemplo), o Apache carregava seu arquivo de configuração default, hardcoded, de /etc/httpd/conf/httpd.conf. Nós criamos outras configurações, uma para cada cliente, com uma estrutura completamente differente, endereço IP, módulos carregados, diretório de conteúdo, senhas, domínios, estratégia de log etc.

Este mesmo conceito é usado por um editor de texto de um desktop multiusuário (como o Linux). Quando o código é carregado, ele procura por um arquivo de configuração no $HOME do usuário, e dependendo quem o invocou (usuário A ou B), aparecerá diferente porque cada um tem sua própria configuração pessoal.

A conclusão óbvia é que o corpo (lógica de negócio) do Software é puro e completamente orientado pela alma (configuração) de quem o manipula. Mas a vantagem competitiva está na facilidade de como trocamos uma alma pela outra, como no caso do Apache. é muito saudável você promover isto ao seu usuário, pois lhe permite criar intimidade, conforto, segurança com seu Produto.

Usamos essa abordagem com muito diferentes Software naqueles tempos de e-business Hosting, e era extremamente prático para manutenções etc. Numa migração de versão, tinhamos controle total de onde estava cada uma de suas partes, e faziamos upgrades e downgrades sem perder tempo, com sucesso óbvio.

Mas haviam uns Softwares que se recusavam a trabalhar desta forma. Tinham tantos parâmetros hardcoded, que não conseguiamos enchergar com clareza o que separava o corpo de sua alma (ou outras partes). Marcavamos estes Produtos como os de sangue ruim, e os descartávamos/trocávamos assim que possível.

Concluimos que os Softwares de sangue bom foram intuitivamente abençoados pela visão das quatro partes de seus desenvolvedores. E eles fizeram nossa vida mais fácil. De fato, foi nessa época que formulamos essa teoria, e ela continua se comprovando.

Você quer criar Software sangue ruim ou sangue bom?

Então vamos resumir o que o FHS diz sobre as pastas (diretórios) do Linux:

Pode parecer uma má idéia quebrar seu Software (como um todo) em vários pedaços, ao invés de mante-lo todo em uma pasta self-contained. Mas um sistema de pacotes (RPM) tem uma base de dados que faz tudo isso para você de uma forma muito profissional, mantendo controle de arquivos de configuração, diretórios etc. E se você espalhar seu Software usando o FHS, além da facilidade ao usuários, você propiciará uma forma intuitiva ao administrador configura-lo, e trabalhar melhor com performance e segurança.

Agora que sabemos onde cada parte de nosso Software deve ser instalada, vamos rever a Tabela das Partes Universais cruzada com o FHS.

Se você é um administrador de sistemas, saiba que esta seção não é para você. Esse é um assunto para desenvolvedores e empacotadores, para facilitar a vida do administrador de sistemas.

Os diretórios /opt e /usr/local são usados pelos administradores para instalar manualmente softwares com arquivos soltos (sem RPM), justamente para ele não perder o controle sobre eles. Repare como esses diretórios ficam separados do resto do sistema.

Um processo de instalação manual (sem RPM, ou baseado em simples cópia de arquivos) fica num documento esquecido dentro do armário (se foi documentado), e na cabeça de quem instalou. Se ele mudar de emprego, aquela instalação fica obscura para o resto da equipe, e é uma bomba relógio.

Com RPM é diferente. RPM (ou qualquer outro sistema de pacotes) é um "processo" de instalação em sí. Está auto documentado na forma de sua base de dados e ações de pré e pós-instalação, o que permite controle total. Torna as instalações independentes de quem instalou, e por isso é processo de negócio.

Instalações baseadas em copia de arquivos para /opt ou /usr/local nem de longe provê a organização, visibilidade de sistema e controle do RPM. Diria até que /opt e /usr/local seriam obsoletos se todos os softwares fossem distribuidos como pacotes RPM.

É muito importante para a evolução e popularização do Linux (sobretudo no campo de batalha do desktop) que desenvolvedores parem de usar /opt e /usr/local, e comecem a integrar a instalação de seus produtos à árvore principal do sistema. Se depois de ler esta seção você (como desenvolvedor de software) ainda acreditar que estes diretórios são um bom negócio, por favor mande-me um e-mail.

Produtos que são inteiramente instalados sob um diretório (a rasão da existêcia de /opt e /usr/local), usam a abordagem self-contained, que tem os seguintes problemas:

Muitos desenvolvedores acreditam que a abordagem "self-contained" lhes permite trabalhar com várias versões de um mesmo produto simultaneamente, parar testes, ou o que seja. Sim, concordo, com este ou qualquer outro bom motivo do planeta. Mas lembre que um Software de Alta Qualidade (ou Comercial) tem como objetivo a praticidade ao usuário final, e não a facilidade para quem o desenvolve ou testa. Visite um usuário inexperiente (mas potencial cliente) e veja-o instalando seu produto.

Desenvolvedor, não tenha medo de espalhar seus arquivos de acordo com o FHS (livrando-se de /opt e /usr/local), porque o RPM estará de olho neles.

Se você tem uma necessidade de negócio de permitir o usuário trabalhar com várias versões de seu Produto simultaneamente (ou qualuqer outro motivo), faça um pacote relocalizável (relocatable package), cuja descrição está no livro Maximum RPM. Esteja a par também das implicações de usar este recurso, descritos no mesmo livro.

Não é a toa que distribuições como Red Hat e seus derivados usam sempre o padrão de diretórios, ao invés de /opt ou /usr/local. Veja o que a Red Hat fala sobre este assunto, e pense nisso.

	Nota
	Os Makefiles de um Software OpenSource, portável a outros UNICES devem ter como padrão a instalação em /usr/local por questões de compatibilidade. Mas devem dar a opção, e induzir o empacotador, a criar o pacote usando especificações do FHS.

Gostaria de fechar este assunto convidando o leitor a se abstrair e pensar em que qualquer Software pode ser tratado como uma extensão ao Software de nível superior. Então da mesma forma que um plugin de terceiros é uma extensão ao seu Software, seu Software acaba sendo uma extensão ao SO (nível superior). Podemos então aplicar todos os conceitos de facilidade ao usuário etc que discutimos anteriormente, para o desenho da arquitetura de plugins de seu Software.

De ao usuário a opção de instalar somente a parte de seu Software que ele precisa. Imagine que seu Software tenha a parte cliente e servidor, e ambos usam alguns arquivos ou bibliotecas em comum. Quebre então em 3 RPMs. Como exemplo, imagine que o nome de seu produto é MyDB, então você fornecerá os pacotes:

sendo que os dois últimos dependem do primeiro. Se o usuário está instalando o sistema com perfil de cliente, usará:

E se o perfil for de servidor:

Esta abordagem ajuda o usuário a economizar espaço em disco, e ficar ciente de como seu Software está organizado.

Melhor do que uma simples interface gráfica, é um desktop integrado consistente. Portanto desenvolvedor, não reinvente a roda. O que já existe de desktop no Linux é completo, com APIs que facilitam muito sua vida.

Os desktops que hoje reinam na Linuxlândia são o KDE e o GNOME. Tente sempre usar um dos dois, ou ambos.

O KDE é o que mais tem se destacado, oferecendo um verdadeiro desktop consistênte, flexível, e de arquitetura extremamente elegante, incorporando componentes (como COM e COM+ da Microsoft), intercomunicação, performance etc. Está constantemente se aprimorando, e é desenvolvido em C++. Suas aplicações tem um "look-and-feel" integrado e familiar, é leve e maduro. Dizem que o KDE 3 é um diamante lapidado pronto para ser usado, e é a minha principal sugestão para você.

O GNOME também traz a proposta de desktop integrado, mas está longe da maturidade e facilidade do KDE. Por outro lado, é muito bem suportado pela comunidade, e ótimas melhorias vem surgindo.

O Motif não é um desktop integrado. É uma bilioteca de widgets (botão, scrollbar etc), mais um gerenciador de janelas. Ele nasceu comercial, é maduro e bastante usado em aplicações legado. Mas é considerado obsoleto perante o KDE e GNOME, que integram o desktop. O código fonte do Motif foi aberto pelo OpenGroup e por isso também renomeado para OpenMotif.

Java tem sido muito usado para interfaces gráficas, principalmente em Softwares de servidor, onde a interação gráfica é somente um auxílio para a configuração e administração. A Abstract Windowing Toolkit (AWT) do Java, como o próprio nome diz, é independente de desktop. Use interfaces Java para aplicações de usuários específicos, que não necessitem integração com o desktop, ou que não as usarão todos os dias.

Hoje todo desktop tem um browser, e se seu Software for uma aplicação de servidor, a Interface Web é a escolha certa, por permitir que seja administrado de qualquer lugar. Mas tenha sempre em mente a segurança e organização de seus CGIs, pois eles costumam ser a porta de entrada para crackers. Interface web (CGI) é um paradigma completamente diferente de programação. Tente entende-lo conceitualmente primeiro, passando por como um web-server funciona, o que é uma URL, etc, para se aventurar nisso sem comprometer a segurança de seu produto.

Principalmente se for um produto comercial, seu Software deve fornecer um instalador gráfico. Acredite, eles impressionam numa demonstração, e CIOs gostam deles.

Mais que instalação, um wizard auxilia na configuração inicial de um produto, além de coletar dados como chave de ativação etc, e também mostrar a licensa do fabricante.

Um wizard não deve fazer mais do que isso:

Ou seja, o wizard facilita a instalação de RPMs e cria alguma personalização. A responsabilidade de colocar todos os arquivos de seu Software nos lugares corretos é ainda do RPM. Seu instalador nunca deve tomar esta responsabilidade para sí. Pense que um administrador de sistemas experiente (há muitos deles no mundo Linux) deve poder reproduzir a instalação de seu Software sem seu instalador gráfico, usando somente comandos do RPM. De fato, em grandes CPDs, onde se instala software em massa, um instalador gráfico só atrapalha.

O RPM traz ferramentas que auxiliam seu instalador gráfico interagir com ele, tais como um medidor de porcentagem de instalação. Documentação para seu uso estão no manual (man rpm) e no livro Maximum RPM.

Vamos repassar brevemente o que acontece quando bootamos o Linux.

O mecanismo de runlevels permite fazer o Linux se iniciar de formas diferentes. E permitem também mudarmos de um perfil (runlevel) para outro sem rebootarmos.

O runlevel default é definido na /etc/inittab com uma linha do tipo

id:3:initdefault:

Os runlevels são números de 0 a 6, e cada um deles é usado de acordo com o seguinte padrão:

Pode-se mudar de um runlevel para outro com o comando telinit. E pode-se ver o runlevel corrente e o anterior com o comando runlevel. Veja abaixo como mudamos do runlevel 3 para o 5.

bash# runlevel
N 3
bash# telinit 5
bash# runlevel
3 5
bash# 

Podemos citar como exemplo de subsistemas um web-server, um banco de dados, ou ainda a camada de rede do SO. Não consideraremos como sendo subsistema uma aplicação totalmente voltada ao usuário (como um editor de textos).

O Linux provê uma forma elegante e modular para organizar a inicialização dos subistemas. Um fator importante é pensar nas dependências entre eles. Por exemplo, não faz sentido iniciar um web-server antes do subsistema de rede estar ativo.

Os subsistemas se organizam sob os diretórios /etc/init.d e /etc/rc.d/rcN.d:

Portanto, para fazer seu Software iniciar automaticamente no boot, ele deve ser um subsistema, e veremos como fazer isso em seguinda.

Os arquivos de seu Software se espalharão pelo SO, mas você vai querer prover uma interface simples e consistente para que o usuário possa principalmente inicia-lo e para-lo. A arquitetura de Subsistemas promove esta facilidade permitindo-lhe também (não obrigatoriamente) ser automático no boot. Basta colocar um script em /etc/init.d que siga um padrão para que seja funcional e prático.

Exemplo 6. Esqueleto de um script de Subsistema em /etc/init.d

#!/bin/sh
#
# /etc/init.d/mysystem
# Subsystem file for "MySystem" server
#
# chkconfig: 2345 95 05	
# description: MySystem server daemon
#
# processname: MySystem
# config: /etc/MySystem/mySystem.conf
# config: /etc/sysconfig/mySystem
# pidfile: /var/run/MySystem.pid

# source function library
. /etc/rc.d/init.d/functions

# pull in sysconfig settings
[ -f /etc/sysconfig/mySystem ] && . /etc/sysconfig/mySystem	

RETVAL=0
prog="MySystem"
.
.	
.

start() {	
	echo -n $"Starting $prog:"
	.
	.	
	.
	RETVAL=$?
	[ "$RETVAL" = 0 ] && touch /var/lock/subsys/$prog
	echo
}

stop() {	
	echo -n $"Stopping $prog:"
	.
	.	
	.
	killproc $prog -TERM
	RETVAL=$?
	[ "$RETVAL" = 0 ] && rm -f /var/lock/subsys/$prog
	echo
}

reload() {	
	echo -n $"Reloading $prog:"
	killproc $prog -HUP
	RETVAL=$?
	echo
}

case "$1" in	
	start)
		start
		;;
	stop)
		stop
		;;
	restart)
		stop
		start
		;;
	reload)
		reload
		;;
	condrestart)
		if [ -f /var/lock/subsys/$prog ] ; then
			stop
			# avoid race
			sleep 3
			start
		fi
		;;
	status)
		status $prog
		RETVAL=$?
		;;
	*)	
		echo $"Usage: $0 {start|stop|restart|reload|condrestart|status}"
		RETVAL=1
esac
exit $RETVAL

	Apesar de serem comentários, são usados pelo comando chkconfig e devem estar presentes. Esta linha em particular define que nos runlevels 2,3,4 e 5, este subsistema deve ser ativado com prioridade 95 (um dos últimos), e desativado com prioridade 05 (um dos primeiros).
	Além da própria configuração de seu Software, este script pode ter um arquivo de configuração. O local padrão para isso é sob o diretório /etc/sysconfig, e no nosso caso vamos chama-lo de mySystem. Esta linha de código lê esse arquivo de configuração.
	Seu script pode ter várias funções, mas é obrigatório que implemente start e stop, pois são elas que iniciam e param seu Software no boot. Outros métodos podem ser chamadas a partir de opções da linha de comando, e você pode definir quantos quiser.
	Após definidas as ações do script, a linha de comando é analisada e o método (ação) correto é chamado.
	Se este script for executado sem nenhum parâmetro, retornará uma mensagem de ajuda como a seguinte: bash# /etc/init.d/mysystem Usage: mysystem {start|stop|restart|reload|condrestart|status}
	Aqui vão comandos específicos de seu Software.

Os metodos que você implementou no subsistema mysystem poderão ser invocados pelos usuários com o comando service, como no exemplo:

bash# service mysystem start
Starting MySystem:			[ OK ]
bash# service mysystem status
Subsysten MySystem is active with pid 1234
bash# service mysystem reload
Reloading MySystem:			[ OK ]
bash# service mysystem stop
Stopping MySystem:			[ OK ]
bash# 

Você não precisa se preocupar em gerenciar os links simbólicos em /etc/rc.d/rcN.d. O commando chkconfig faz isso para você, baseado nos comentários de controle definidos no começo de sue script.

bash# chkconfig --add mysystem
bash# chkconfig --del mysystem

Leia o manual do chkconfig para ver o que mais ele pode fazer por você.

Quando criar o RPM, coloque seu script de Subsistema em /etc/init.d e não inclua nenhum link nos diretórios /etc/rc.d/rcN.d, porque é uma decisão do usuário permitir seu Subsistema ser automático ou não. Se os links forem incluidos no pacote, e o usuário faz alguma mudança, o inventário de arquivos do RPM se tornará incosistente.

Os links simbólicos devem ser criados e removidos dinamicamente pelo processo de pós instalação e pré-desintalação de seu pacote, usando o comando chkconfig. Esta abordagem garente 100% de consistência para o pacote e sistema de arquivos.