Tópico Entendendo o buildout.cfg do Manual do Desenvolvedor Plone traduzido para o Português

Como gerenciar o arquivo principal de configuração do buildout


Nota importante: Este documento se aplica ao Plone 3.2 ou superior. Em versões do Plone anteriores a 3.2, o arquivo padrão do buidout.cfg era significativamente diferente porque o Plone não era totalmente eggficado.

O buildout.cfg é o arquivo mais importante em seu novo ambiente de buildout. Veja como ele se parece:

[buildout]
parts =
    zope2
    productdistros
    instance
    zopepy

# Modifique o numero aqui, e no find-links abaixo, para alterar a versão 
# do Plone que será utilizado
extends = http://dist.plone.org/release/3.3.5/versions.cfg
versions = versions


# Adicione aqui fontes adicionais para download de eggs (repositórios). 
# O repositório dist.plone.org contém os arquivos de pacotes do Plone.
find-links =
    http://dist.plone.org/release/3.3.5
    http://dist.plone.org/thirdparty

# Acrescente eggs adicionais aqui.
eggs =

# Referencie quaisquer eggs que esteja desenvolvendo aqui, um por linha
# por exemplo: develop = src/my.package
develop =

[zope2]
recipe = plone.recipe.zope2install
url = ${versions:zope2-url}

# Utilize esta seção para baixar produtos old-style adicionais.
# Liste as URLs dos tarballs dos produtos (separados por espaço
# em branco, ou quebra de linha, com linhas subseqüentes indentadas).
# Caso algum arquivo contenha muitos produtos como em um diretório
# de alto nível, liste os nomes de arquivo (isto é, a última parte da URL,
# normalmente com um sufixo .tar.gz ou similar) sob 'nested-packages'.
# Se algum arquivo extrai para um diretório de algum produto com o sufixo
# da versão, liste o nome do arquivo em 'version-suffix-packages'.
[productdistros]
recipe = plone.recipe.distros
urls =
nested-packages =
version-suffix-packages =

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
# Para sites em produção, comente as duas linhas a seguir
debug-mode = on
verbose-security = on

# Se você quer que o Zope reconheça qualquer egg adicional, liste-os aqui.
# Isto deveria incluir qualquer development egg que você listou em develop-eggs
# acima, por exemplo: eggs = Plone my.package
eggs =
    Plone
    ${buildout:eggs}

# Se você quer registrar slugs ZCML para algum pacote, liste-os aqui.
# por exemplo: zcml = my.package my.other.package
zcml =

products =
    ${buildout:directory}/products
    ${productdistros:location}

[zopepy]
recipe = zc.recipe.egg
eggs = ${instance:eggs}
interpreter = zopepy

extra-paths = ${zope2:location}/lib/python
scripts = zopepy

Vamos agora percorrê-lo passo-a-passo.


A seção [buildout]

A seção [buildout] é o ponto de partida do arquivo de configuração. Ela contém uma lista de "parts" que serão configuradas separadamente em seções ao longo do arquivo. Cada part, ou seção, possui uma recipe (receita) associada que é o nome de um egg que sabe como executar uma determinada tarefa, por exemplo, construir o Zope ou criar uma instância do Zope. Uma recipe tipicamente contém um mínimo de configurações/opções.

Nossas configurações globais são as seguintes:

[buildout]
parts =
    zope2
    productdistros
    instance
    zopepy

find-links =
    http://dist.plone.org/release/3.3.5
    http://dist.plone.org/thirdparty

eggs =

develop =

Isto especifica que as seções zope2, productdistros, instance e zopepy serão executadas, nessa ordem. Em seguida, nós dizemos ao buildout que ele pode pesquisar em uma lista de links quando for procurar eggs para fazer download. Sempre será adicionada a essa lista a busca no Cheese Shop, isto é, o PyPI: Python Package Index.

Observe que as configurações são comumente quebradas em múltiplas linhas. Para isso funcionar, todas as linhas depois da primeira devem começar com ao menos 4 espaços.

Em seguida, nós podemos listar quaisquer eggs que o buildout deva baixar e instalar para nós. Nesta configuração podemos incluir a especificação da versão. Por exemplo, se você quer o sqlalchemy 0.3 e não o 0.4, você poderia listar:

eggs =
    sqlalchemy>=0.3,<0.4dev

Por favor observe que você necessitará do Python Image Library (PIL) para o Plone funcionar. Este exemplo assume que você já possui esta biblioteca instalada e disponível em seu interpretador Python, mas todavia você pode instalar uma versão levemente modificada (a fim de contornar alguns problemas comuns) a partir de um repositório Plone "thirdparty" (de terceiro) acrescentando o seguinte nome em sua lista de eggs:

eggs =
    PILwoTk

E o caminho completo para o pacote na opção find-links:

find-links = http://dist.plone.org/thirdparty/PILwoTk-1.1.6.4.tar.gz

Por fim, nós podemos listar os development eggs, especificando o diretório onde estão os fontes do egg, por exemplo:

eggs =
    my.package

develop =
    src/my.package

Isso presume que existe um egg chamado my.package no diretório src/. Nós veremos como criar eggs um pouco mais a frente neste tutorial. Observe que nós devemos acrescentar my.package também na lista de dependências: development eggs não são acrescentadas automaticamente no "working set" de eggs que serão instalados pelo Zope.


As linhas extends e versions

Essas opções foram introduzidas no Plone 3.2 e fazem referência a um arquivo remoto onde a versão de cada pacote necessário é especificada. Acesse tal arquivo remoto para ver você mesmo como tais dependências são especificadas.

# Modifique o numero aqui, e no find-links abaixo, para alterar a versão 

# do Plone que será utilizado
extends = http://dist.plone.org/release/3.3.5/versions.cfg
versions = versions

Se você quer utilizar um arquivo local ao invés de um remoto para poder trabalhar offline, baixe-o para o seu diretório de buildout e o referencie assim:

extends = versions.cfg

A seção [zope2]

Esta seção constrói o Zope 2, utilizando a receita plone.recipe.zope2install. Se você escolher usar uma instalação do Zope já existente, você não precisará dessa parte. Em todo o caso, ela se parece com isso:

[zope2]
recipe = plone.recipe.zope2install
url = ${versions:zope2-url}

Aqui nós referenciamos a URL de download para o Zope conforme definido na seção versions. Isso assegura que nós sempre baixemos a versão recomendada do Zope. Ao invés disso, você poderia informar manualmente uma URL para download se desejar utilizar uma versão diferente do Zope.

Quando a receita está executando, o Zope 2 é instalado em parts/zope2. A home do Zope ficaria então em parts/zope2/lib/python.


A seção [productdistros]

Esta seção utiliza a recipe plone.recipe.distros e permite o download de distribuições old-style (tarballs) de produtos Zope 2, disponibilizando-os para o Zope. Por padrão vem vazia:

[productdistros]
recipe = plone.recipe.distros
urls =
nested-packages =
version-suffix-packages =

Todavia, você pode listar quantos produtos necessitar para que seja feito o download. Este recipe também é capaz de lidar com pacotes em diretórios de alto nível que contenham um conjunto de diretórios de produto (pacotes aninhados), ou com pacotes que tenham um número de versão no nome do diretório e, portanto, precisa ser renomeado para obter o diretório do produto real (pacote com versão como sufixo).

Considere as seguintes distribuições:

# Uma distribuição típica 
ExampleProduct-1.0.tgz
 |
 |- ExampleProduct
     |
     |- __init__.py
     |- (código do produto)

# Uma distribuição com versão como sufixo
AnotherExampleProduct-2.0.tgz
 |
 |- AnotherExampleProduct-2.0
     |
     |- __init__.py
     |- (código do produto)

# Uma distribuição com pacotes aninhados
ExampleProductBundle-1.0.tgz
 |
 |- ExampleProductBundle
     |
     |- ProductOne
     |   |- __init__.py
     |   |- (código do produto)
     | 
     |- ProductTwo
         |- __init__.py
         |- (código do produto)

A seguir temos como esta seção deverá ser configurada para tentar instalar as três distribuições listadas acima:

[productdistros]
recipe = plone.recipe.distros
urls =
    http://example.com/dist/ExampleProduct-1.0.tgz
    http://example.com/dist/AnotherExampleProduct-2.0.tgz
    http://example.com/dist/ExampleProductBundle-1.0.tgz
nested-packages = ExampleProductBundle-1.0.tgz
version-suffix-packages = AnotherExampleProduct-2.0.tgz

Você pode especificar múltiplos downloads em linhas separadas. Quando a recipe é executada, os diretórios dos produtos importados são localizados em parts/productdistros.


A seção [instance]

A seção [instance] põe tudo junto. Ela configura uma instância do Zope através do script plone.recipe.zope2instance. Aqui está com que ela se parece:

[instance]
recipe = plone.recipe.zope2instance
zope2-location = ${zope2:location}
user = admin:admin
http-address = 8080
# comente as duas opções abaixo para sites em produção
debug-mode = on
verbose-security = on

eggs =
    Plone
    ${buildout:eggs}

zcml = 

products =
    ${buildout:directory}/products
    ${productdistros:location}

Aqui, nós referenciamos a instalação do Zope2 configurada na seção [zope2] - se você especificou um local quando criou o buildout você o veria aqui. Então nós especificamos o usuário admin e a senha inicial que será usada apenas quando da criação do banco de dados inicial, e a porta na qual o Zope será vinculado. Nós também ativamos o modo de depuração e o modo de segurança detalhado. Eles são úteis para o desenvolvimento, mas lembre-se de desligá-los para sites em produção, uma vez que podem comprometer a segurança do seu site. Estas opções são usadas para gerar um arquivo zope.conf apropriado para a instância. Acesse página da recipe na Cheese Shop para maiores detalhes sobre as opções disponíveis.

Em seguida, nós especificamos quais eggs serão disponibilizados para o Zope. Isto faz referência ao "global" eggs da seção [buildout], bem como ao próprio Plone. Você pode incluir eggs adicionais aqui, porém geralmente é mais fácil especificá-los no começo do arquivo, de modo que eles sejam referenciados pela variável ${buildout:eggs}.

Arquivos configure.zcml do Zope 3 não são carregados automaticamente por eggs ou pacotes que não suportem z3c.autoinclude e que não estão no namespace Products. Para que pacotes comuns carreguem arquivos ZCML, nós podemos fazer o buildout criar uma ZCML slug listando os pacotes sob a opção zcml:

zcml =
    my.package
    my.package-overrides

Aqui assume-se que my.package foi referenciado anteriormente no buildout. Isto carregaria os arquivos tanto o configure.zcml principal quanto o overrides.zcml deste pacote. A necessidade dessa entrada tende a desaparecer na medida que o uso do z3c.autoinclude se torna generalizado.

Finalmente, nós listamos os diretórios que contenham os produtos no formato Zope 2 - idêntico a pasta Products/ de uma instância convencional. Perceba que o diretório products/ na pasta do buildout principal vem primeiro, seguido pelos produtos baixados definidos na seção [productdistros].

Quando a recipe é executada, o diretório home da instância Zope será parts/instance, e será criado um script de controle em ./bin/instance.


A seção [zopepy]

Nesta última seção é criado um interpretador Python que tem todos os eggs e pacotes (exceto os produtos no estilo Zope 2) que o Zope teria durante a inicialização. Isto pode ser útil para testes.

[zopepy]
recipe = zc.recipe.egg
eggs = ${instance:eggs}
interpreter = zopepy
extra-paths = ${zope2:location}/lib/python
scripts = zopepy

Aqui nós copiamos os eggs da seção [instance], e incluímos o diretório home da instância do Zope no pythonpath.

Quando a recipe é executada, o script será criado em ./bin/zopepy.

Referências

• Plone.org (http://plone.org/documentation/manual/developer-manual/managing-projects-with-buildout/understanding-buildout.cfg) acessado em 21 de novembro de 2011.

Soluções Livres adotadas pela Procuradoria Geral do Estado da Paraíba.

Desde 2007 a Procuradoria Geral do Estado da Paraíba tem optado preferencialmente por soluções livres de licenciamento para atender suas necessidades por sistemas e ferramentas baseadas em computador. Tem como objetivo gerar economia para o estado com a aquisição de tais licenças e melhorar a segurança da rede interna da PGE/PB.

A aplicação de tal política naturalmente iniciou-se pelos programas utilizados nos servidores, que são os computadores centrais que compartilham recursos e serviços acessados pelos usuários através de interfaces gráficas geradas por aplicativos nas estações de trabalho (máquinas clientes) de forma transparente, isto é, sem que o usuário perceba que programa está fornecendo tal serviço ou recurso, o que praticamente não gera impacto para os usuários. Logo, a primeira solução livre implantada na instituição foi o sistema operacional para acionar os servidores. Para tanto foi escolhido o Ubuntu Linux, devido a familiaridade dos técnicos lotados na Sub-gerência de Tecnologia da Informação com o mesmo, mas principalmente devido a grande e muito ativa comunidade em torno desta distribuição que torna muito fácil encontrar suporte.

Os primeiros serviços disponibilizados sob a nova plataforma dos servidores, destinados ao controle da própria rede, foram: serviço de firewall, proxy de rede, DHCP – Dynamic Host Configuration Protocol e DNS – Domain Name System. As implementações escolhidas destes serviços foram iptables, squid, dhcpd e bind, respectivamente. Posteriormente, foram sendo introduzidas as aplicações para automatização dos processos internos do órgão. Neste momento, entraram em cena o PostgreSQL como banco de dados relacional, o Apache como serviço web, o Tomcat como contêiner para aplicações Java tais como o carro-chefe da instituição: o SGP – Sistema Gestor de Processos – e as linguagens de script PHP e Python/Django para aplicativos de pequeno porte que apoiam rotinas administrativas do órgão. O portal da PGE/PB foi desenvolvido sobre a plataforma Python/Zope/Plone, utilizando como base um pacote chamado PortalModelo desenvolvido pelo Interlegis. O portal além de servir como site institucional também funciona como intranet, concentrando diversos serviços inclusive uma base de dados textual que é usada para entre outras coisas a catalogação dos pareceres editados pela PGE/PB.

Os últimos serviços implantados na infraestrutura da PGE/PB foram o compartilhamento de arquivos via Samba e autenticação via openLDAP. Este último serviço futuramente poderá concentrar a autenticação de todos os sistemas da Procuradoria Geral do Estado, fazendo com que os usuários da rede utilizem um único login e senha para logar na rede, ter acesso restrito a conteúdos da web, além das aplicações da área fim.

Nas estações de trabalho, as aplicações utilizadas são: Ubuntu, BrOffice.org, Firefox, etc..

Atualmente, a PGE/PB encontra-se com seu parque computacional 100% acionado por Linux e com isso já economizou mais de R$ 1 mi, conforme descrito na matéria anterior.

PGE/PB já economizou mais de R$ 1 mi com uso de Software Livre

A Procuradoria Geral do Estado da Paraíba (PGE/PB), por meio da Sub Gerência de Tecnologia da Informação (SGTI), há quase cinco anos instituiu a utilização de programas de computador livres de licenciamento – também conhecidos como software livre -, que além de proporcionar economia mensal de mais de R$ 15 mil (esse valor é relativo apenas a solução de gestão de processos), a migração dos sistemas operacionais e aplicativos utilizados no ambiente de trabalho tem proporcionado um ganho à segurança sem a necessidade de contratação de caras ferramentas de antivírus.

Segundo o gerente da SGTI, Guido Giuseppe, cedido pela CODATA à PGE/PB, a implantação dos programas de software livre iniciou há quase cinco anos, inspirado na política do governo federal, tendo em vista o corte de gastos com a aquisição de computadores, economizando os valores relativos ao licenciamento de produtos como sistemas operacionais, suítes de escritório, antivírus, entre outros.

“O objetivo era o de melhorar a segurança da rede interna da PGE/PB, uma vez que computadores acionados por Linux são reconhecidamente mais resistentes a infestações por vírus e/ou vermes”, revelou.

Visando a migração da plataforma, suportada pela equipe técnica da PGE, entre eles o analista de sistemas Helder Vieira, foi feito um estudo cuja a conclusão foi que os usuários da PGE utilizam o computador basicamente para editar textos e navegar na Internet.

Migração do sistema - Segundo Guido, com base nesse levantamento, o primeiro passo para a migração foi substituir as suítes de escritório e os navegadores web nos computadores dos usuários. Onde havia, por exemplo, uma instalação do MS-Office® foi colocado o BrOffice.org, e onde havia Internet Explorer foi posto o Mozilla Firefox em seu lugar. Com isso, o usuário foi se acostumando com tais ferramentas.

O passo seguinte, como relatou o gerente da SGTI, foi na aquisição de equipamentos novos configurá-los apenas com o sistema operacional livre. “Optamos pelo Ubuntu Linux que já vem com o BrOffice.org e Mozilla Firefox por padrão”, afirmou, ressaltando que em cem por cento dos casos o usuário preferiu um computador novo com o sistema livre a permanecer com o equipamento antigo.

Em paralelo a esse segundo passo, conforme informou Guido, foi feito todo um trabalho de conscientização dos usuários, principalmente sobre a legalidade se softwares, principalmente por se tratar de um órgão que lida com Justiça, como é a PGE, que levou a reinstalação de alguns computadores para por o novo sistema.

“Neste aspecto, alguns usuários perceberam que computadores 'antigos' acionados pelo sistema livre funcionava mais rápido do que os que eram acionados pelo sistema não-livre, com a mesma configuração de hardware, o que fez com que mais algumas estações fossem convertidas. Na verdade o novo sistema deu uma sobrevida aos computadores antigos”, revelou o gerente, afirmando que a PGE ainda dispõe em sua rede computadores com quase nove anos de utilização, funcionando graças ao novo sistema.

De acordo com Guido Giuseppe, a implementação da segunda fase é a mais delicada do processo de migração, pois quando o usuário não consegue realizar alguma tarefa seu primeiro impulso é culpar o novo sistema. “Para minimizar o impacto para o usuário é necessário que o setor de informática disponha de uma equipe que domine o novo sistema e que esteja sempre de prontidão para tirar qualquer dúvida do usuário de imediato”, comentou.

Interface do novo sistema - O gerente ressaltou ainda, que em todas as instalações foram aplicadas um tema que deixa a interface do novo sistema o mais próximo possível do que os usuários já estavam acostumados a utilizar, no caso o Windows. “Na Internet existem vários pacotes que se propõem a isso. Não encontramos nenhum que fosse perfeito mas todos eles, uma vez aplicados, minimizam o impacto
inicial do usuário com o novo sistema. Como o usuário trabalha diretamente com os aplicativos – e não com o sistema operacional – e ele já vinha utilizando o BrOffice.org e o Firefox desde a fase anterior, não resta muitas dúvidas para tirar sobre o novo sistema”, destacou.

Resolvida a migração das estações dos usuários médios adentra-se numa área um pouco complicada –  que pode ser chamada de fase três – que é a dos usuários avançados, ou seja, aqueles que utilizam ferramentas/sistemas/aplicativos específicos para desempenhar suas funções, tais como planilhas sofisticadas, programas especialistas, sistemas legados, etc.. Nesta etapa, como destacou Guido, é necessário estudar diversos tipos de soluções além da substituição do aplicativo por um similar que nem sempre é possível. Entre elas fazer com que o programa em questão funcione no novo sistema através de emulação ou virtualização, modificar ou mesmo reescrever o programa para que o mesmo funcione na nova plataforma.

“A exemplo disso podemos citar o Sistema Gestor de Processos que foi totalmente reescrito para a plataforma web por funcionários da PGE/PB para substituir o legado que funcionava apenas sobre sistema operacional não-livre e que foi fornecido e era mantido por uma empresa de Santa Catarina”, comentou.

Apesar de não existir relatórios consolidados sobre a economia gerada para a PGE nos últimos quatro anos e meio da utilização do novo sistema, a estimativa é que há uma economia de ao menos R$ 15 mil por mês, referente a taxa de manutenção cobrada pela empresa fornecedora do sistema gestor de processos, com base do que era cobrado em 2007.

Além disso, conforme afirmou o gerente da SGTI, para cada estação de trabalho adquirida neste período economizou-se cerca de R$ 500, referentes ao licenciamento do sistema operacional, da suíte de escritório e do antivírus. Atualmente 95% dos computadores desta Procuradoria são equipados com softwares livres. Os cinco porcento restantes, referem-se a programas que ainda não se tem um similar livre (fase três). As fases dois e três são contínuas sem prazo para terminar pois de tempos em tempos as equipes de trabalho são renovadas e/ou são adquiridos novos computadores.

“O resultado mais importante alcançado com esse processo de migração não foi o objetivo inicial – a economia, a segurança – foi a valorização, capacitação e aprendizado do pessoal da PGE e o fortalecimento e conscientização da cultura do software livre como ferramenta de trabalho na Procuradoria Geral do Estado”, declarou.