OpenLDAP é um software open source que implementa o protocolo LDAP (Lightweight Directory Access Protocol) e está disponível nos repositórios das principais distribuições Linux e BSD.
Seu uso mais comum é para autenticação de usuários em casos onde a informação precisa estar disponível em várias plataformas, aplicações de diferentes fornecedores necessitam de tais informações e os registros armazenados sofrem poucas alterações.

Vários softwares suportam o protocolo LDAP, tais como Apache, Subversion, Squid e é claro sistemas operacionais como Linux e Windows (Active Directory).
O objetivo aqui é mostrar o básico para configurar um servidor LDAP de forma rápida e simples no CentOS mas a idéia pode ser aproveitada em outras distros como Ubuntu ou Fedora.

Instalação e Configuração

Instale os pacotes necessários:

# yum install openldap-servers openldap-clients

Copie o modelo slapd.conf para /etc/openldap e altere:

# cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.conf
# vim /etc/openldap/slapd.conf
 
include          /etc/openldap/schema/core.schema
include          /etc/openldap/schema/inetorgperson.schema
include          /etc/openldap/schema/openldap.schema
 
allow bind_v2
 
pidfile           /var/run/openldap/slapd.pid
argsfile           /var/run/openldap/slapd.args
 
database config
access to *
               by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
               by * none
 
database monitor
access to *
               by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
               by dn.exact="cn=admin,dc=dominio,dc=com,dc=br" read
               by * none
 
database      bdb
suffix             "dc=dominio,dc=com,dc=br"
checkpoint   1024 15
rootdn          "cn=admin,dc=dominio,dc=com,dc=br"
rootpw          senha
 
directory        /var/lib/ldap
 
index objectClass                                    eq,pres
index ou,cn,mail,surname,givenname   eq,sub

rootdn tem permissão para adicionar ou remover qualquer informação na árvore de diretórios. rootpw pode conter a senha em plain text ou criptografada. Por medidas de segurança é aconselhável adicionar o hash gerado pelo comando slappasswd:

# slappasswd -s senha
{SSHA}m/SnFEf/S+S5jGjCof1Ltesi9noPBiXf

Apague a configuração padrão removendo tudo que está dentro do diretório /etc/openldap/slapd.d:

# rm -rf /etc/openldap/slapd.d/*

Copie o arquivo /usr/share/openldap-servers/DB_CONFIG.example para /var/lib/ldap/DB_CONFIG:

# cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Execute o slapdtest para converter as configurações do arquivo slapd.conf (formato antigo) no formato mais recente onde as configurações ficam armazenadas no diretório slapd.d:

# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d

Atribua as permissões dos arquivos de configuração ao usuário e grupo ldap:

# chown ldap.ldap -Rf /etc/openldap/slapd.d/*
# chown ldap.ldap -Rf /var/lib/ldap/*

Para finalizar, inicie o servidor OpenLDAP:

# service slapd start
Starting slapd:                                                        [  OK  ]

Agora o servidor OpenLDAP está configurado e funcionando escutando na porta padrão 389. Com isso é possível usar o rootdn e rootpw para criar e gerenciar a árvore de diretórios LDAP.

Criando diretórios

LDAP utiliza o padrão LDIF para gerenciamento de registros. LDIF é um formato de troca de dados em plain text para representar o conteúdo de diretório e requisições de atualização, transportando conteúdo de diretório como um conjunto de registros.
Crie um arquivo chamado primeiroregistro.ldif como abaixo:

# vim /etc/openldap/primeiroregistro.ldif
dn: dc=dominio,dc=com,dc=br
dc: dominio
objectClass: top
objectClass: domain
 
dn: cn=desenvolvedores,dc=dominio,dc=com,dc=br
objectClass: top
objectclass: groupOfNames
cn: desenvolvedores
member: cn=gustavo,cn=desenvolvedores,dc=dominio,dc=com,dc=br
 
dn: cn=gustavo,cn=desenvolvedores,dc=dominio,dc=com,dc=br
objectclass: top
objectclass: inetOrgPerson
cn: gustavo
sn: Gustavo
uid: 10
userpassword: senha

Agora execute o ldapadd para adicionar as entradas do arquivo primeiroregistro.ldif na base LDAP. Quando for solicitada a senha, informe o rootpw que está no arquivo slapd.conf:

# ldapadd -h localhost -a -W -x -D "cn=admin,dc=dominio,dc=com,dc=br" -f /etc/openldap/primeiroregistro.ldif

Nesse exemplo foi criada uma estrutura onde dominio.com.br é o topo da hierarquia, desenvolvedores é um grupo que está um nível abaixo e gustavo é uma pessoa pertencente ao grupo desenvolvedores. Também é possível criar outros diretórios no mesmo nível ou abaixo de desenvolvedores.
Lembrando que é sempre recomendado inserir no atributo userpassword o hash gerado pelo comando slappasswd ao invés de plain text.

Como podem ver, as três entradas no arquivo primeiroregistro.ldif possuem linhas em comum como dn e objectclass. O dn é a chave para identificar um diretório e objectclass especifica o schema utilizado. O LDAP possui vários schemas com um conjunto de atributos e alguns com dependências para outros schemas. No início do arquivo slapd.conf foram incluídos os schemas utilizados nesse exemplo. Um diretório pode ter mais de um schema e alguns atributos são de preenchimento obrigatório. Por exemplo, usando o inetOrgPerson os atributos cn e sn obrigatoriamente precisam conter algum valor, já uid e userpassword são opcionais, sequer precisam ser adicionados. É possível criar um schema com outros atributos mas isso já é um tópico mais avançado.

O arquivo primeiroregistro.ldif pode ser deletado pois não será mais utilizado.

Há ainda os comandos ldapdelete e ldapmodify com funcionamento semelhante. Mais detalhes em man ldapdelete e man ldapmodify.

Buscas com filtros

Operador =

# ldapsearch -x -b "dc=dominio,dc=com,dc=br" "(objectclass=inetOrgPerson)"

Operador or

# ldapsearch -x -b "dc=dominio,dc=com,dc=br" "(uid=10)" or "(cn=gustavo)"

Operador &

# ldapsearch -x -b "dc=dominio,dc=com,dc=br" "(&(uid=10)(cn=gustavo))"

Ferramentas para administração

Ao lidar com uma base de centenas de diretórios fica complicado, entediante e perigoso administrar uma árvore utilizando as ferramentas de linha de comando. Pensando nisso foram desenvolvidas ferramentas gráficas para esse tipo de trabalho. Das opções open source, duas me chamaram a atenção, o Apache Directory Studio e o phpLdapAdmin. A primeira é baseada na popular IDE Eclipse e me pareceu mais fácil e amigável e por isso vou mostrar como instalar no Fedora 16:

Faça o download em http://directory.apache.org/studio/download/download-linux.html. Descompacte em /opt/ApacheDirectoryStudio e crie um arquivo em /opt/ApacheDirectoryStudio/startup.sh com permissão de execução com o conteúdo abaixo:

# vim /opt/ApacheDirectoryStudio/startup.sh
export GDK_NATIVE_WINDOWS=1
/opt/ApacheDirectoryStudio/ApacheDirectoryStudio

Pronto!!! Execute /opt/ApacheDirectoryStudio/startup.sh para abrir o Apache Directory Studio.

Links

http://www.openldap.org/
http://www.tldp.org/HOWTO/LDAP-HOWTO/
http://migre.me/7Zeup
http://directory.apache.org/studio/download/download-linux.html

Ext JS 4 trouxe uma nova maneira de construir interfaces ricas com a introdução do padrão MVC. Ao permtir a separação das regras de negócios e componentes visuais é obtido um código mais limpo e fácil de dar manuntenção.

A arquitetura do padrão MVC usado pelo extjs4 é definido da seguinte maneira:

• Model: é uma classe que representa uma tabela do banco de dados.
• View: é um componente visual como por exemplo datagrid, combobox, panel…
• Controller: é onde fica o código que faz a aplicação funcionar. Serve como uma ponte entre o Model e a View, possui regras de negócio e renderiza componentes.

ExtJS utiliza convenções para facilitar a vida do desenvolvedor.

Estrutura de arquivos:
Um diretório app para cada projeto e dentro dele os diretórios model, controller, view e store. O arquivo app.js no mesmo nível do diretório app.
Dentro do diretório view deve ser criado um subdiretório com o nome de cada controller que renderiza alguma view.

Nomes de arquivos:

• Models: CamelCase no singular.
• View: um subdiretório com o nome do controller em minúsculo e dentro CamelCase para o nome do componente.
• Controllers: CamelCase no plural.
• Stores: CamelCase no plural.

Como exemplo, vou mostrar como criar um projeto usando a estrutura abaixo:

Primeiramente instale um servidor web tal como Apache ou Nginx. A configuração padrão já é suficiente para o propósito desse artigo. Faça o download da versão gratuita do ExtJS 4 em http://www.sencha.com/products/extjs/download?page=a.

$ mkdir -p /var/www/html/extjs4-mvc-tutorial/js
$ cd /var/www/html/extjs4-mvc-tutorial/js
$ wget http://cdn.sencha.io/ext-4.0.7-gpl.zip
$ unzip ext-4.0.7-gpl.zip
$ mkdir -p app/model
$ mkdir -p app/controller
$ mkdir -p app/view/contatos
$ mkdir -p app/store

Crie o arquivo /var/www/html/extjs4-mvc-tutorial/index.html:

<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <title>Ext JS 4 MVC Tutorial</title>
  <link rel="stylesheet" type="text/css" href="js/ext-4.0.7-gpl/resources/css/ext-all-gray.css" />
  < type="text/java" src="js/ext-4.0.7-gpl/ext-all-debug.js"></>
  < type="text/java" src="js/app.js"></>
</head>
<body></body>
</html>

Agora o arquivo /var/www/html/extjs4-mvc-tutorial/js/app.js:

Ext.Loader.setConfig({enabled:true});
Ext.application({
    name: 'extjs4-mvc-tutorial',
    appFolder: '/extjs4-mvc-tutorial/js/app',
    autoCreateViewport: false,
 
    controllers: ['Contatos',],
 
    launch: function() {
        viewport = Ext.create('Ext.container.Viewport', {
            id: 'viewport',
            layout: 'border',
            items: [{
                region: 'center',
                border: false,
                autoScroll: true,
                items: [{
                    xtype: 'contatosGrid',
                    store: 'Contatos',
                }]
            }]
        });
    }
});

app.js cria a aplicação extjs4-mvc-tutorial e define o caminho da appFolder. autoCreateViewport: false permite que eu crie uma viewport assim que a aplicação for criada.
A linha Ext.Loader.setConfig({enabled:true}) é necessária para o carregamento dinâmico das dependências do projeto.
Adicionei um controller na aplicação. Devido a convenção utilizada, extjs sabe exatamente onde onde procurar essa classe controller dentro do appFolder. Ao carregar o controller dinamicante, suas dependências também são carregadas, como por exemplo o store Contatos e a view contatosGrid.

Crie o model /var/www/html/extjs4-mvc-tutorial/js/app/model/Pessoa.js

Ext.define('extjs4-mvc-tutorial.model.Pessoa', {
    extend: 'Ext.data.Model',
    fields: ['id', 'email'],
});

Um model extende de Ext.data.Model e automaticamente ganha os métodos set() e get(). Na versão 4 é possível inserir um Proxy dentro do Model e com isso obtém um funcionamento semelhante ao padrão Active Record.

Crie também a store /var/www/html/extjs4-mvc-tutorial/js/app/store/Contatos.js

Ext.define('extjs4-mvc-tutorial.store.Contatos', {
    extend: 'Ext.data.Store',
 
    model: 'extjs4-mvc-tutorial.model.Pessoa',
    autoLoad: true,
    autoSync: true,
    pageSize: 30,
 
    proxy: {
        type: 'rest',
 
        api: {
            read: '/extjs4-mvc-tutorial/contatos/read',
            create: '/extjs4-mvc-tutorial/contatos/create',
            update: '/extjs4-mvc-tutorial/contatos/update',
            destroy: '/extjs4-mvc-tutorial/contatos/delete'
        },
 
        reader: {
            type: 'json',
            root: 'data',
            successProperty: 'success',
            totalProperty: 'total'
        },
 
        writer: {
            type: 'json',
            root: 'data',
        },
 
        listeners: {
            exception: function(proxy, response, operation) {
                var message = Ext.JSON.decode(response.responseText).message;
                Ext.Msg.alert('Ocorreu um erro', message);
            }
        }
    },
});

Crie a view /var/www/html/extjs4-mvc-tutorial/js/app/view/contatos/Grid.js

Ext.define('extjs4-mvc-tutorial.view.contatos.Grid', {
    extend: 'Ext.grid.Panel',
    alias: 'widget.contatosGrid',
 
    plugins: Ext.create('Ext.grid.plugin.CellEditing'),
 
    columns: [{
        xtype: 'rownumberer',
        width: 30,
    }, {
        text: 'Nome',
        sortable: true,
        dataIndex: 'nome',
        field: {
            xtype: 'textfield'
        }
    }, {
        text: 'E-mail',
        flex: 0,
        sortable: false,
        dataIndex: 'email',
        width: 120,
        field: {
            xtype: 'textfield'
        }
    }],
 
    initComponent: function() {
        this.dockedItems = [{
            xtype: 'toolbar',
            items: [{
                text: 'Adicionar',
                action: 'adicionar'
            }, {
                text: 'Deletar',
                action: 'deletar'
            }]
        }, {
            store: this.getStore(),
            displayInfo: true,
            xtype: 'pagingtoolbar',
            dock: 'bottom',
            beforePageText : 'Pagina ',
            displayMsg: '{0} - {1} de {2}',
            emptyMsg: 'Nada para ser exibido',
        }];
        return this.callParent(arguments);
    },
});

A linha plugins: Ext.create('Ext.grid.plugin.CellEditing') adiciona o plugin para editar células no grid.

Por fim, crie o controller /var/www/html/extjs4-mvc-tutorial/js/app/controller/Contatos.js:

Ext.define('extjs4-mvc-tutorial.controller.Contatos', {
    extend: 'Ext.app.Controller',
 
    models: ['Pessoa'],
    stores: ['Contatos'],
    views : ['contatos.Grid',],
 
    init: function() {
        this.control({
            'contatosGrid button[action=adicionar]': {click: this.adicionar},
            'contatosGrid button[action=deletar]': {click: this.deletar},
        });
    },
 
    adicionar: function(button) {
        button.up('grid').getStore().insert(0, this.getModel('Pessoa').create());
    },
 
    deletar: function(button) {
        var grid = button.up('grid'),
            store = grid.getStore(),
            record = grid.getSelectionModel().getSelection()[0];
 
        if (record) {
            if (confirm('Tem certeza?')) {
                store.remove(record);
            }
        }
    }
});

O controller contém a lógica da aplicação, isolando o model e a view.
Para testar esse exemplo, crie o arquivo /var/www/html/extjs4-mvc-tutorial/contatos/read contendo:

$ vim /var/www/html/extjs4-mvc-tutorial/contatos/read
{ success: true, total: 1, data: [{ 'id': 1, 'nome': 'Gustavo', 'email': 'eu@gustavohenrique.net' }] }

Ao carregar a aplicação será exibido no grid o conteúdo do arquivo acima.

Como não foi utilizada nenhuma linguagem de backend, ao tentar cadastrar, deletar ou atualizar um registro no grid ocasionará um erro 404. Mas se testar no firefox ou chrome usando o firebug vai perceber que são enviados requests do tipo POST, DELETE e PUT, afinal o proxy na store foi configurado para trabalhar como REST.

Links

http://docs.sencha.com/ext-js/4-0/
http://www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1

KVM (Kernel-based Virtual Machine) é uma solução de virtualização open source para Linux incluído por padrão no kernel a partir da versão 2.6.20.
A maioria das distros possuem as ferramentas necessárias para virtualização com KVM nos CDs de instalação ou repositórios de pacotes. Nesse artigo vou usar o Fedora 16 como host e instalar o CentOS como guest.

Instalação no Fedora 16

# yum install qemu-kvm python-virtinst libvirt virt-manager

Verificando suporte virtualização de hardware:

grep -E "(vmx|svm)" --color=always /proc/cpuinfo

Caso a saída do comando acima não retorne nenhuma informação na tela é porque o processador não suporta virtualização de hardware. Sendo asssim há apenas a opção de usar emulação com o QEMU.

Iniciando o serviço:

# service libvirtd start

Antes de instalar o sistema operacional no guest é necessário criar o virtual disk usado pela máquina virtual. KVM suporta o formato raw, qcow2 (nativo do QEMU), VMWare, dentre outros. Vou criar usando qcow2 e alocando 10GB de espaço:

$ qemu-img create -f qcow2 -o preallocation=metadata /home/gustavo/vm/hd-centos.qcow2 10G

As opções de rede disponíveis são bridge, virtual network e user.
bridge permite que à máquina virtual obter endereço IP como se fosse outra máquina na rede onde está o host;
virtual network cria uma rede virtual no qual apenas outros guests na mesma virtual network e o host consegueguem se comunicar;
user provê uma forma de NAT muito limitada, indicado apenas se for executar o kvm com usuário diferente de root.

Para usar o modo bridge primeiramente é preciso criar a interface br0. Os passos estão descritos nas instruções da documentação da libvirt em http://wiki.libvirt.org/page/Networking.

Criando uma Virtual Machine com KVM

Modo simples, especificando o path da iso de instalação e do virtual disk:

# virt-install --name=minha-vm-centos --arch=x86_64 --vcpus=1 --ram=512 --os-type=linux --os-variant=rhel5 --hvm --connect=qemu:///system --network bridge=br0 --cdrom=/home/gustavo/Downloads/softwares/iso/CentOS-6.2-x86_64-LiveDVD.iso --disk path=/home/gustavo/vm/hd-centos.qcow2,size=10 --graphics vnc,keymap=pt-br,  --noautoconsole

Modo muito simples, onde serão feitas perguntas ao usuário:

# /usr/sbin/virt-install --prompt

Rodando no modo gráfico é possível utilizar virt-manager – interface gráfica para gerenciar máquinas virtuais.

Gerenciando máquinas virtuais com o Virsh

Virsh é utilitário em modo texto que utiliza a API da libvirt para gerenciamento de máquinas virtuais. Abaixo os comandos mais utilizados.

Exibir todas as máquinas virtuais:

virsh list --all

Iniciar uma máquina virtual:

virsh start <nome da vm>

Desligar uma máquina virtual:

virsh shutdown <nome da vm>

Editar configuração:

virsh edit <nome da vm>

Forçar o desligamento:

virsh destroy <nome da vm>

Salvar um snapshot:

virsh save <nome da vm> <nome do arquivo>

Restaurar um snapshot:

virsh restore <nome do arquivo>

Acessar remotamente via ssh:

virsh -c qemu+ssh://<usuario>@<ip>/system <nome da vm>

Outras dicas

Para renomar uma máquina virtual no Virsh é necessário copiar o arquivo xml contendo as configurações, editar manualmente esse arquivo, criar uma máquina virtual com o novo nome e remover a antiga.

virsh dumpxml <nome da vm> > arquivo.xml
vim arquivo.xml #alterar o novo nome dentro do arquivo xml
virsh undefine <nome da vm>
virsh define <nome da nova vm>

Após aumentar o espaço de um virtual disk usando o qemu-img é necessário dar boot no guest com alguma distro livecd e usar o software gparted para redimensionar a partição sem perda de dados.

qemu-img resize /home/gustavo/vm/hd-centos.qcow2 +25GB

O processo de clonar uma máquina virtual consiste em criar uma cópia idêntica com outro nome que pode usar o mesmo virtual disk ou um clone.

virt-clone --connect=qemu:///system -o <nome da vm> -n <nome da vm clonada> -f <path do virtual disk>

Links

http://wiki.libvirt.org/page/Networking
http://www.techotopia.com/index.php/Installing_a_KVM_Guest_OS_from_the_Command-line_(virt-install)
http://www.linux-kvm.org/

Recentemente comecei a brincar com o grails e precisei implementar a funcionalidade de login usando uma conta do facebook. Na minha busca sobre autenticação conheci o plugin spring-security-core do qual eu gostei muito e comecei a usar. Para autenticação no facebook existe o plugin facebook-graph que também é muito bom.
Pensando nisso resolvi mostrar como utilizar esses dois plugins juntos para implementar autenticação no facebook com spring-security-core e facebook-graph no grails.
Pra começar vou criar o projeto facebookauth, instalar os plugins e criar as classes SecUser e SecRole referentes à autenticação e controle de acesso:

$ grails create-app facebookauth
$ cd facebookauth
facebookauth$ grails install-plugin spring-seucrity-core
facebookauth$ grails install-plugin facebook-graph
facebookauth$ grails s2-quickstart org.example SecUser SecRole

O plugin spring-security-core provê um novo comando, o s2-quickstart, que serve para criar as classes de domínio referentes ao usuário e suas permissões de acesso. Não entrarei em detalhes sobre seu funcionamento pois há um artigo explicando o básico em http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/.
Com isso foram criadas as classes SecUser, SecRole e SecUserSecRole, os controllers LoginController e LogoutController e a view auth.gsp que contém o formulário de login.
Antes de começar a brincar é preciso efetuar algumas configurações e registar sua aplicação no facebook…

1. Crie uma conta (se não tiver) no facebook
2. Acesse https://www.facebook.com/developers/createapp.php e cadastre sua aplicação com o nome fbauth
3. Após o cadastro, vá na página de edição e clique no menu Web Site, então configure Site URL como www.localhost.com e Site Domain como localhost.com. Altere o /etc/hosts mapeando o ip 127.0.0.1 para www.localhost.com
4. Pegue sua Application ID e Application Secret e adicione as linhas no arquivo grails-app/conf/Config.groovy

   facebook.applicationSecret='sua application secret aqui'
   facebook.applicationId='sua application id aqui'
   facebook.secure=true

Agora precisamos adicionar o atributo facebookId na classe SecUser.

package org.example
 
class SecUser {
 
    String username
    String password
    boolean enabled
    boolean accountExpired
    boolean accountLocked
    boolean passwordExpired
 
    String facebookId
 
    static constraints = {
        username blank: false, unique: true
        password blank: false
        facebookId blank: false, unique: true
    }
 
    static mapping = { 
        password column: '`password`'
    }   
 
    Set<SecRole> getAuthorities() {
        SecUserSecRole.findAllBySecUser(this).collect { it.secRole } as Set
    }   
}

Quando o usuário se autenticar pelo facebook, a aplicação vai receber o facebook id desse usuário e salvar no banco de dados. Então alteramos o comportamento da aplicação passando a buscar o usuário por esse id no banco, não mais por username e password.

O próximo passo é alterar a view de login para inserir um botão para autenticação via facebook. Altere o arquivo grails-app/views/login/auth.gsp inserindo o código abaixo:

<fbg:resources/>
<script type="text/javascript">
    function facebookLogin() {
        FB.getLoginStatus(function(response) {
            if (response.session) {
                window.location ="${createLink(controller:'login', action:'facebookLogin')}";
            }
        });
    }
</script>
<fb:login-button perms="email" onlogin="facebookLogin();" size="large">
    <g:message code="Login"/>
</fb:login-button>

Esse código insere um botão que ao ser clicado vai abrir um popup do facebook para o usuário se autenticar. Se o login for efetuado com sucesso, o popup será fechado e o usuário será redirecionado para a action facebookLogin no controller login.
Lembrando que o controller login foi criado anteriormente quando executamos o comando grails s2-quickstart porém a action facebookLogin não existe. Então vamos criá-la!

// outros imports existentes
 
import org.example.SecUser
import org.example.SecRole
import org.example.SecUserSecRole
 
class LoginController {
    // outros atributos e actions existentes
 
    def facebookGraphService
 
    def facebookLogin = {
        def details = facebookGraphService.getDetails()
        def facebookId = details.id
 
        def user = SecUser.findByFacebookId(facebookId)?: new SecUser(
            username: details.email,
            password: springSecurityService.encodePassword(facebookId),
            enabled: true,
            facebookId: facebookId).save(failOnError: true)
 
        def role = SecRole.findByAuthority('ROLE_FACEBOOK')?: new SecRole(
            authority:'ROLE_FACEBOOK').save(failOnError: true)
        if (! user.authorities.contains(role)) {
            SecUserSecRole.create user, role
        }
 
        SpringSecurityUtils.reauthenticate(user.username, user.password)
        redirect(controller: 'controlPanel')
    }
}

O objeto facebookGraphService é injetado automaticamente pelo grails e ao chamar facebookGraphService.getDetails() é retornado um JSONObject com o seguinte formato:

{"location":{"id":"110200955653479","name":"Rio de Janeiro, Rio de Janeiro"},"link":"http://www.facebook.com/nomedousuario","locale":"en_US","updated_time":"2011-05-11T02:58:41+0000","id":"100000552012367","first_name":"xxxx","username":"xxxx","timezone":-3,"email":"xxxx@xxx.com","verified":true,"name":"Xxxx Xxxxx","last_name":"Xxxx","gender":"male"}

Então pegamos o facebook id e verificamos se existe algum cadastro no banco. Se não houver vai cadastrar um novo usuário usando o e-mail como username e o facebook id como senha. Para nível de acesso, foi adicionada a Role ROLE_FACEBOOK, que vai ser criada caso não exista.

Para testar, vamos criar um novo controller e apenas usuários autenticados podem acessar.
O spring security possui uma anotação para ser usada nas actions onde voce define a lista de Roles que podem acessar a action. Se o usuário não possuir nenhuma dessas Roles então será redirecionado para página de login.

Vamos criar o controller grails-app/controllers/ControlPanelController.groovy com o código abaixo:

import grails.plugins.springsecurity.Secured
 
class ControlPanelController {
 
    @Secured(['ROLE_FACEBOOK']) 
    def index = { 
        render "Olá! Você fez o login pelo facebook! \o/"
    }   
}

Se tudo deu certo, quando acessar a action index do controller controlPanel o usuário será redirecionado à tela de login. Ao clicar no botão do facebook, um popup será exibido para que o usuário se identifique usando suas credenciais do facebook. Login efetuado então será redirecionado para o controller controlPanel que dessa vez vai exibir a mensagem de boas vindas.

Links

http://www.grails.org/plugin/facebook-graph
https://github.com/chechu/grails-facebook-graph
http://blog.springsource.com/2010/08/11/simplified-spring-security-with-grails/
https://github.com/gustavohenrique/grails-facebook-auth-example

Por padrão o grails utiliza o HSQLDB como banco de desenvolvimento, teste e produção. Saiba como configurar o banco de desenvolvimento para usar sqlite3.
O primeiro passo é instalar o jar do sqlite-jdbc junto com suas dependências. Para isso é necessário editar grails-app/conf/BuildConfig.groovy deixando conforme abaixo:

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.dependency.resolution = {
    inherits("global")
    log "warn"
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()
        mavenCentral()
    }
    dependencies {
        runtime group:'org.xerial', name:'sqlite-jdbc', version:'3.6.16'
    }
}

Feito isso basta executar o comando grails install-dependency para o fazer o download e instalar a lib com suas dependências.

$ grails install-dependency

Depois criar o arquivo src/java/dialect/SQLiteDialect.java. Essa classe java pode ser encontrada no projeto hibernate-sqlite:

package dialect;
 
import java.sql.Types;
 
import org.hibernate.dialect.Dialect;
import org.hibernate.dialect.function.StandardSQLFunction;
import org.hibernate.dialect.function.SQLFunctionTemplate;
import org.hibernate.dialect.function.VarArgsSQLFunction;
import org.hibernate.Hibernate;
 
public class SQLiteDialect extends Dialect {
    public SQLiteDialect() {
        super();
        registerColumnType(Types.BIT, "integer");
        registerColumnType(Types.TINYINT, "tinyint");
        registerColumnType(Types.SMALLINT, "smallint");
        registerColumnType(Types.INTEGER, "integer");
        registerColumnType(Types.BIGINT, "bigint");
        registerColumnType(Types.FLOAT, "float");
        registerColumnType(Types.REAL, "real");
        registerColumnType(Types.DOUBLE, "double");
        registerColumnType(Types.NUMERIC, "numeric");
        registerColumnType(Types.DECIMAL, "decimal");
        registerColumnType(Types.CHAR, "char");
        registerColumnType(Types.VARCHAR, "varchar");
        registerColumnType(Types.LONGVARCHAR, "longvarchar");
        registerColumnType(Types.DATE, "date");
        registerColumnType(Types.TIME, "time");
        registerColumnType(Types.TIMESTAMP, "timestamp");
        registerColumnType(Types.BINARY, "blob");
        registerColumnType(Types.VARBINARY, "blob");
        registerColumnType(Types.LONGVARBINARY, "blob");
        // registerColumnType(Types.NULL, "null");
        registerColumnType(Types.BLOB, "blob");
        registerColumnType(Types.CLOB, "clob");
        registerColumnType(Types.BOOLEAN, "integer");
 
        registerFunction("concat", new VarArgsSQLFunction(Hibernate.STRING, "",
                "||", ""));
        registerFunction("mod", new SQLFunctionTemplate(Hibernate.INTEGER,
                "?1 % ?2"));
        registerFunction("substr", new StandardSQLFunction("substr",
                Hibernate.STRING));
        registerFunction("substring", new StandardSQLFunction("substr",
                Hibernate.STRING));
    }
 
    public boolean supportsIdentityColumns() {
        return true;
    }
 
    /*
     public boolean supportsInsertSelectIdentity() {
     return true; // As specify in NHibernate dialect
     }
     */
 
    public boolean hasDataTypeInIdentityColumn() {
        return false; // As specify in NHibernate dialect
    }
 
    /*
     public String appendIdentitySelectToInsert(String insertString) {
     return new StringBuffer(insertString.length()+30). // As specify in NHibernate dialect
     append(insertString).
     append("; ").append(getIdentitySelectString()).
     toString();
     }
     */
 
    public String getIdentityColumnString() {
        // return "integer primary key autoincrement";
        return "integer";
    }
 
    public String getIdentitySelectString() {
        return "select last_insert_rowid()";
    }
 
    public boolean supportsLimit() {
        return true;
    }
 
    public String getLimitString(String query, boolean hasOffset) {
        return new StringBuffer(query.length() + 20).append(query).append(
                hasOffset ? " limit ? offset ?" : " limit ?").toString();
    }
 
    public boolean supportsTemporaryTables() {
        return true;
    }
 
    public String getCreateTemporaryTableString() {
        return "create temporary table if not exists";
    }
 
    public boolean dropTemporaryTableAfterUse() {
        return false;
    }
 
    public boolean supportsCurrentTimestampSelection() {
        return true;
    }
 
    public boolean isCurrentTimestampSelectStringCallable() {
        return false;
    }
 
    public String getCurrentTimestampSelectString() {
        return "select current_timestamp";
    }
 
    public boolean supportsUnionAll() {
        return true;
    }
 
    public boolean hasAlterTable() {
        return false; // As specify in NHibernate dialect
    }
 
    public boolean dropConstraints() {
        return false;
    }
 
    public String getAddColumnString() {
        return "add column";
    }
 
    public String getForUpdateString() {
        return "";
    }
 
    public boolean supportsOuterJoinForUpdate() {
        return false;
    }
 
    public String getDropForeignKeyString() {
        throw new UnsupportedOperationException(
                "No drop foreign key syntax supported by SQLiteDialect");
    }
 
    public String getAddForeignKeyConstraintString(String constraintName,
            String[] foreignKey, String referencedTable, String[] primaryKey,
            boolean referencesPrimaryKey) {
        throw new UnsupportedOperationException(
                "No add foreign key syntax supported by SQLiteDialect");
    }
 
    public String getAddPrimaryKeyConstraintString(String constraintName) {
        throw new UnsupportedOperationException(
                "No add primary key syntax supported by SQLiteDialect");
    }
 
    public boolean supportsIfExistsBeforeTableName() {
        return true;
    }
 
    public boolean supportsCascadeDelete() {
        return false;
    }
}

Feito isso agora vem a configuração do banco em grails-app/conf/DataSource.groovy. Atente para a url utilizada, nela consta o path para o banco de dados sqlite3. Quanto a ação do dbCreate, fica ao critério de cada um.

development {
    dataSource {
        dbCreate = "create-drop" // one of 'create', 'create-drop','update'
        url = "jdbc:sqlite:/tmp/meubanco.sqlite3"
        logSql = "true"
        dialect = "dialect.SQLiteDialect"
        driverClassName="org.sqlite.JDBC"
    }
}

Agora é só criar as classes de modelo e executar o projeto com grails run-app para criar o banco /tmp/meubanco.sqlite3.

Introdução

Jython é o responsável por tornar possível essa façanha. Segundo a wikipedia:
“Jython é uma implementação da linguagem Python que gera bytecode para máquinas Java (JVM – Java Virtual Machine). Com ela é possível fazer o desenvolvimento de aplicações híbridas que unem código em Java e Python. Esta ferramenta é muito útil também para embutir uma linguagem para criação de scripts em aplicações que requerem este tipo de funcionalidade. Também inclui um compilador que converte código fonte Python em Java bytecode, permitindo que programadores Python possam escrever classes que possam ser utilizadas por um programa Java.”
Nesse artigo vou usar o servidor tomcat por ser open source e fácil de instalar e configurar. Para fazer deploy no tomcat, é preciso antes criar um arquivo .war. Para isso vou instalar o django-jython que além de simplificar muito a criação do war facilita o acesso à banco de dados.
Informações detalhadas sobre o funcionamento e arquitetura das tecnologias utilizadas podem ser encontradas nos seus respectivos sites.

Instalação

Antes de instalar é preciso dizer que utilizar diferentes versões do trio jython + django + django-jython pode não funcionar corretamente. Uma combinação que deu certo pra mim foram jython2.5.2, django-1.2.3 e django-jython-1.2.0, que são as versões utilizadas nesse artigo.

O primeiro passo é instalar o jython. Faça o download em no site do projeto e instale no /opt.

gustavo@notebook ~$ java -jar jython_installer-2.5.2.jar

Detalhes da instalação básica podem ser lidos na wiki http://wiki.python.org/jython/InstallationInstructions.

Considerando que o virtualenv + virtualenv wrapper estão instalados, vou criar um novo ambiente virtual e instalar o django e o django-jython.

gustavo@notebook ~$ mkvirtualenv --python=/opt/jython2.5.2/bin/jython --no-site-packages env_jython
Running virtualenv with interpreter /opt/jython2.5.2/bin/jython
New jython executable in env_jython/bin/jython
Installing setuptools............................done.
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/predeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postdeactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/preactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/postactivate
virtualenvwrapper.user_scripts creating /home/gustavo/.virtualenvs/env_jython/bin/get_env_details
(env_jython)gustavo@notebook ~$
(env_jython)gustavo@notebook ~$ pip install django==1.2.3, django-jython==1.2

Configuração

Django-jython implementa o pacote zxJDBC do jython que permite conectividade à banco de dados usando drivers JDBC.
Para utilizar o mysql é preciso fazer o download do mysql-connector-java-5.1.15-bin.jar, adiciona-lo no CLASSPATH e alterar o DATABASE_ENGINE no settings.py do projeto. Supondo que já exista o projeto myproject criado em /var/www/django, vou criar um diretório lib e copiar o mysql-connector para dentro dele:

(env_jython)gustavo@notebook ~$ mkdir -p /var/www/django/myproject/lib
(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar /var/www/django/myproject/lib/
(env_jython)gustavo@notebook ~$ export CLASSPATH="$CLASSPATH:/var/www/django/myproject/lib/mysql-connector-java-5.1.15-bin.jar"

Alterando o settings.py:

DATABASES = { 
    'default': {
        'ENGINE': 'doj.backends.zxjdbc.mysql',
        'NAME': 'jython_example',
        'USER': 'username',
        'PASSWORD': 'pass',
        'HOST': 'localhost',
        'PORT': '3306',
    }
}
 
INSTALLED_APPS = (
    # outras apps aqui
    'doj',
)

Se o projeto possuir alguma classe no models.py, pode executar o syncdb para criar as tabelas no mysql:

(env_jython)gustavo@notebook myproject$ jython manage.py syncdb

Para finalizar, é preciso adicionar o projeto no PYTHONPATH. Insira o trecho abaixo no arquivo manage.py na linha 3:

import os, sys 
PROJECT_ROOT_PATH = os.path.dirname(os.path.abspath(__file__))
sys.path.append(PROJECT_ROOT_PATH)

Segundo a documentação é possível utilizar um test runner específico do django-jython que permite a saída dos resultados dos testes para um arquivo xml no mesmo formato dos gerados pelo Junit.

Deploy

Tomcat é fácil de instalar e possui uma interface web que permite fazer o upload do pacote tornando o deploy ridiculamente simples. Sua documentação é bastante completa e mostra em detalhes como instalar e configurar o ambiente.
O primeiro passo é gerar um pacote war para deploy no tomcat. Ao adicionar doj em INSTALLED_APPS no settings.py, o django-jython adiciona uma task no manage.py para criação de pacotes. Essa task usa como base o diretório war_skel que por algum motivo não está presente na instalação via pip. Então… vamos criar:

(env_jython)gustavo@notebook ~$ mkdir ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook ~$ cd ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel
(env_jython)gustavo@notebook war_skel$ mkdir -p WEB-INF/lib WEB-INF/lib-python
(env_jython)gustavo@notebook war_skel$ touch application.py
(env_jython)gustavo@notebook war_skel$ touch WEB-INF/web.xml

Conteúdo do application.py:

from django.core.handlers import wsgi
import os
 
def handler(environ, start_response):
    os.putenv("DJANGO_SETTINGS_MODULE", "{{ settings.SETTINGS_MODULE }}")
    h = wsgi.WSGIHandler()
    return h(environ, start_response)

Conteúdo do web.xml:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE web-app
PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
  <display-name>{{ project_name }}</display-name>
  <description>
   {{ project_name }} through WSGI with modjy
  </description>
  <context-param>
    <param-name>files.prefix</param-name> <!-- Needed by fileservlet -->
    <param-value></param-value>
   </context-param>
  <servlet>
    <servlet-name>modjy</servlet-name>
    <servlet-class>com.xhaus.modjy.ModjyJServlet</servlet-class>
    <init-param>
      <param-name>reload_on_mod</param-name>
      <param-value>1</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet>
    <servlet-name>fileservlet</servlet-name>
    <servlet-class>org.jruby.webapp.FileServlet</servlet-class>
  </servlet>
 
  {% if settings.ADMIN_MEDIA_PREFIX %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.ADMIN_MEDIA_PREFIX }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  {% if settings.MEDIA_URL %}
  <servlet-mapping>
    <servlet-name>fileservlet</servlet-name>
    <url-pattern>{{ settings.MEDIA_URL }}*</url-pattern>
  </servlet-mapping>
  {% endif %}
 
  <servlet-mapping>
    <servlet-name>modjy</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>

Lembram do download do mysql-connector-java? Vamos copia-lo também para o diretório war_skel/WEB-INF/lib para ser inserido no pacote war criado pelo manage.py.

(env_jython)gustavo@notebook ~$ cp mysql-connector-java-5.1.15-bin.jar ~/.virtualenvs/env_jython/Lib/site-packages/doj/management/commands/war_skel/WEB-INF/lib/

Agora vem a parte de gerar o pacote war. Entre no diretório do projeto e execute a task war do manage.py. Mas antes certifique-se de ter executado o syncdb:

(env_jython)gustavo@notebook ~$ cd /var/www/django/myproject
(env_jython)gustavo@notebook myproject$ jython manage.py war

Se tudo deu certo, foi gerado um pacote war no diretório de um nível acima do projeto (/var/www/myproject.war).
Com o tomcat rodando, acesse o endereço http://localhost:8080/manager/html, clique em “Select WAR file to upload” e depois no botão deploy.

Conclusão

Embora o jython não tenha um desenvolvimento muito acelerado, vimos que já é possível utilizar um projeto django com acesso à banco de dados com muita facilidade e poucas alterações.
Em termos de desempenho não tenho qualquer informação que possa compartilhar com vocês, e caso alguém tenha algum caso de sucesso (ou mesmo insucesso) seria legal compartilhar com a comunidade.
Lembrando que o django-jython 1.2 possui backend estável apenas para os bancos de dados oracle, mysql e postgresql.

Links

http://www.jython.org/downloads.html/
http://packages.python.org/django-jython/quickstart.html
http://tomcat.apache.org/

Introdução

Nginx foi desenvolvido inicialmente em 2002 por Igor Sysoev para servir um site russo chamado Rambler que tinha milhares de requisições por dia. Entre suas características estão o baixo consumo de cpu e memória (pois usa um processo por core para gerenciar varias conexões) e o formato dos arquivos de configuração que são mais simples de entender e modificar do que os do apache.
Entre os grandes sites que o utilizam, podemos destacar o wordpress e sourceforge.

VirtualEnv é um software que permite criar um ambiente python único e exclusivo para cada projeto. Não entrarei em detalhes sobre seu funcionamento então recomendo uma lida no artigo Gerenciando Ambientes Virtuais que explica melhor sobre o assunto.

Instalação

$ sudo apt-get install nginx
$ sudo pip install virtualenv, virtualenvwrapper

Configuração

Por padrão o arquivo de configuração é o /etc/nginx/nginx.conf. Vamos modifica-lo e deixar como abaixo:

user www-data;
worker_processes 2;
 
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
 
http {
    include     /etc/nginx/mime.types;
    access_log  /var/log/nginx/access.log;
    sendfile        on;
    keepalive_timeout  65;
    tcp_nodelay        on;
    gzip  on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";
 
    server {
        server_name project-1-0;
        listen 80;
 
        location /media {
            autoindex on;
            alias /var/www/project_1_0/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on;
            alias /var/www/project_1_0/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_0;
            fastcgi_pass 127.0.0.2:8000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
        }   
    }
 
    server {
        server_name project-1-3;
        listen 80; 
 
        location /media {
            autoindex on; 
            alias /var/www/project_1_3/media;
            expires 31d;
        }
 
        location /admin_media {
            autoindex on; 
            alias /var/www/project_1_3/media/admin;
            expires 31d;
        }
 
        location / { 
            root /var/www/project_1_3;
            fastcgi_pass 127.0.0.3:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_param REQUEST_METHOD $request_method;
            fastcgi_param QUERY_STRING $query_string;
            fastcgi_param CONTENT_TYPE $content_type;
            fastcgi_param CONTENT_LENGTH $content_length;
            fastcgi_param SERVER_PORT $server_port;
            fastcgi_param SERVER_NAME $server_name;
            fastcgi_param SERVER_PROTOCOL $server_protocol;
       }
    }
}

Pode-se dizer que o arquivo de configuração do nginx é uma lista de diretivas organizadas em uma estrutura lógica. Nginx é modular e cada módulo possui um conjunto específico de diretivas. Na configuração acima, todas as diretivas fazem parte do core do nginx, exceto as diretivas fastcgi que fazem parte do módulo FastCGI. Esse módulo é incluído por padrão na compilação do nginx, sendo assim não é preciso ativa-lo.
Nginx trabalha com um sistema de blocos. Um configuração mínima requer os principais blocos: http, server e location.

O bloco http é responsável por tratar requisições desse tipo. Ele pode conter um ou mais blocos server que contém configurações para um virtual host. Cada server pode ter um ou mais blocos location. Esse por sua vez possui configurações para um determinado url pattern.
Na configuração acima foram criados dois blocos server (um para cada projeto) e cada um possui três blocos location contendo configurações para arquivos estáticos e para os projetos em django.

Algumas diretivas podem ser colocadas na raiz do arquivo, fora dos blocos. Diretivas assim são chamadas de diretivas globais e afetam as demais configurações.
Sobre algumas diretivas:

user www-data
Define o usuário do nginx. Coloquei o mesmo usado pelo apache mas nada impede de usar outro. Apenas lembre-se de atribuir as devidas permissões nos diretórios dos projetos para esse user.

worker_processes 2
Define o número de processos executados por core da CPU. No meu caso, uso uma CPU Core 2 Duo.

error_log /var/log/nginx/error.log
Caminho para o arquivo de log de erros.

pid /var/run/nginx.pid
Caminho para o arquivo contendo o PID do nginx.

include /etc/nginx/mime.types
Similar à função include usada em algumas linguagens. Insere o conteúdo do arquivo externo no trecho indicado.

access_log /var/log/nginx/access.log
Caminho para o arquivo de log de acessos.

sendfile on
Se habilitado, nginx usa sendfile kernel call para gerenciar transmissão de arquivos. Se desabilitado, ele próprio gerencia a transmissão. Dependendo da localização física do arquivo, isso pode afetar a performance.

keepalive_timeout 65
Tempo de espera do servidor para fechar conexões keep-alive.

tcp_nodelay on
Habilita ou não a opção TCP_NODELAY para conexões keep-alive. TCP_NODELAY é usado para um único propósito; desabilitar o algoritmo de buffer Nagle. Deve ser habilitado apenas para aplicações que enviam frequentemente requests sem necessidade de obter um response imediato.

gzip on
Habilita compressão gzip.

gzip_disable "MSIE [1-6]\.(?!.*SV1)"
Desabilita a compressão gzip para requests cujo o User-Agent no cabeçalho http combine com a expressão regular. Nesse caso, desabilita para o internet explorer.

server_name project-1-0
Associa um ou mais hostnames ao bloco server. O nginx verifica o Host no cabeçalho do request e seleciona o primeiro bloco que combina.

listen 80
Escuta na porta 80 (padrão http).

autoindex on
Exibe os arquivos do diretório.

alias /var/www/project_1_0/media
Define a location /media como um atalho para o diretório media do projeto.

expires 31d
Define o tempo de expiração do conteúdo. Nesse caso, 31 dias.

root /var/www/project_1_0
Caminho do projeto.

fastcgi_pass 127.0.0.2:8000
Endereço e porta do servidor web usado pelo django. Ex.: python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/var/run/project_1_0.pid

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_script_name
fastcgi_param REQUEST_METHOD $request_method
fastcgi_param QUERY_STRING $query_string
fastcgi_param CONTENT_TYPE $content_type
fastcgi_param CONTENT_LENGTH $content_length
fastcgi_param SERVER_PORT $server_port
fastcgi_param SERVER_NAME $server_name
fastcgi_param SERVER_PROTOCOL $server_protocol
Repassa os parâmetros do request recebido pelo nginx para o servidor fastcgi.

Para finalizar a configuração, vamos editar o /etc/hosts e adicionar dois virtual hosts referentes aos projetos.

$ sudo /etc/hosts
 
127.0.0.2   project-1-0.localdomain project-1-0
127.0.0.3   project-1-3.localdomain project-1-3

Notem que estou utilizando dois IPs de loopback, ou seja, visível somente na máquina local.

Criando os Projetos

Agora vem a parte mais fácil. Vamos criar dois ambientes virtuais (env-1.0 e env-1.3) e instalar o django-1.0 em um e o django-1.3 no outro.
Dentro de cada ambiente vou criar um projeto que vai exibir a versão do django em uso.
O único pacote python obrigatório a ser instalado é o flup, que é uma coleção de módulos WSGI.
Vou usar o virtualenv + virtualenv wrapper e como já havia dito não entrarei em detalhes sobre essas ferramentas.

Ambiente 1.0

Criando o ambiente env-1.0 e o projeto dentro do diretório /var/www:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.0
(env-1.0)gustavo@notebook www$ pip install django==1.0, flup
(env-1.0)gustavo@notebook www$ django-admin startproject project_1_0

Modificando o arquivo project_1_0/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import *
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.0)gustavo@notebook project_1_0$ python manage.py runfcgi host=127.0.0.2 port=8000 pidfile=/tmp/project_1_0.pid

Agora basta testar. Abra o navegador e digite http://project-1-0/. Se tudo deu certo então será exibido na tela a versão do Django, no caso “10final”.

Ambiente 1.3

Criando o ambiente env-1.3 e o projeto:

gustavo@notebook www$ mkvirtualenv --no-site-packages env-1.3
(env-1.3)gustavo@notebook www$ pip install django==1.3, flup
(env-1.3)gustavo@notebook www$ django-admin startproject project_1_3

Modificando o arquivo project_1_3/urls.py para exibir a versão do django na tela:

from django.conf.urls.defaults import patterns, include, url 
from django.http import HttpResponse
import django
 
urlpatterns = patterns('',
    (r'^version/$', lambda request:HttpResponse(django.VERSION)),
)

Executando o servidor fastcgi:

(env-1.3)gustavo@notebook project_1_3$ python manage.py runfcgi host=127.0.0.3 port=9000 pidfile=/tmp/project_1_3.pid

Abra o navegador e digite http://project-1-3/. Deve ser exibido na tela a versão do Django, “130final0″.

Conclusão

Esse artigo mostrou uma forma simplista de servir dois projetos usando versões diferentes do django no nginx. Na configuração foram criados blocos location para servir arquivos estáticos como /media e /admin_media porém nos projetos não me aprofundei em alterar o settings.py para isso.

O Nginx possui a diretiva include que permite inserir trechos de configuração localizados em outros arquivos no arquivo de configuração principal. Sendo assim, como boa prática, é indicado colocar a configuração de cada projeto em arquivos separados. No ubuntu 10.10 o diretório /etc/nginx possui dois sub-diretórios, sites-available e sites-enabled, similar ao apache2. A idéia é colocar os arquivos de configuração referentes a cada projeto dentro de sites-available e criar um link simbólico em sites-enabled para habilitar seu uso.
Quem quiser conhecer melhor esse fantástico servidor web, recomendo a leitura do livro Nginx HTTP Server, que inclusive serviu como base para esse artigo.

Links

Nginx Project Page
Planet Nginx
Nginx HTTP Server Book

Primeiros Passos

Configurando informações sobre o autor dos commits:

git config --global user.name "Gustavo"
git config --global user.email "gustavo@gustavohenrique.net"

É possível alterar essas informações no arquivo ~/.gitconfig

Criando um repositório local:

cd meuprojeto
git init

Para ter certeza que o repositório foi criado:

git status

Áreas de Trabalho

O git possui 4 áreas de trabalho:
1. O diretório .git que é o repositório contendo todos os arquivos versionados;
2. Working Area que é um snapshot do .git dentro de um determinado momento no tempo;
3. Stage que é um local temporário que armazena a referência para arquivos a serem versionados antes de serem commitados;
4. Stash que também é um local temporário que pode armazenar e esconder arquivos que estão no Stage.

Adicionando arquivos novos ou modificados no Stage:

git add arquivo.txt
git add *.py
git add . (para add todos os arquivos)
git add -i (para modo interativo. 1-5 ou 1,2,3,4 e -3 para retirar)

Removendo arquivos não versionados do Stage:

git rm --cached arquivo.txt
git clean -fd (remove todos arquivos e diretórios)

Removendo arquivos versionados e modificados do Stage:

git reset HEAD arquivo.txt
git reset HEAD (todos os arquivos)

Desfazendo modificações de arquivos versionados no Stage:

git checkout -- arquivo.txt

Trabalhando com o Stash:

git stash (Move todos os arquivos do Stage para o Stash)
git stash save "Mensagem" (Move todos os arquivos do Stage para o Stash e os identifica com uma mensagem)
git stash list
git stash apply (Recupera os arquivos do último Stash de volta para o Stage mantendo cópia no Stash)
git stash apply <ID> (Recupera os arquivos do Stash identificado pelo ID obtido pelo git stash list. Ex.: stash@{0})
git stash pop (Faz o mesmo que apply porém apaga os arquivos do Stash)
git stash drop <ID> (Apaga completamente o Stash)
git fsck --unreachable | grep commit (Recupera arquivos apagados do Stash)

Commits

Apenas arquivos no Stage podem ser commitados.

git commit -m "Mensagem"
git commit -a -m "Mensagem" (commita também os arquivos versionados mesmo nao estando no Stage)

Refazendo commit quando esquecer de adicionar um arquivo no Stage:

git add arquivo.txt
git commit -m "Mensagem" --amend

O amend é destrutivo e só deve ser utilizado antes do commit ter sido enviado ao servidor remoto.

Voltando commits anteriores:

git reset --hard HEAD~1 (volta ao último commit)
git reset --soft HEAD~1 (volta ao último commit e mantém os últimos arquivos no Stage)
git reset --hard XXXXXXXXXXX (Volta para o commit com a hash XXXXXXXXXXX)

Recuperando commit apagado pelo git reset:

git reflog (Para visualizar os hashs)
git merge <hash>

Logs

Visualizando logs:

git log
git log --stat (Mostra o que foi modificado em cada commit)
git log --graph (Mostra gráfico do log)
git log --pretty=oneline (Mostra os commits linha por linha)
git log --pretty=format:"%an %ad %h %s" (Exibe o autor, data, sha1 abreviado e texto do commit)
git log --since=30.minutes ou 1.hour ou 2.hours (Exibe commits dos últimos 30 minutos, 1h ou 2h)
git log --since=10.hours --until=2.hours (Exibe commits entre as últimas 10h e últimas 2h)
git log --before="2010-12-25" (Exibe commits antes do dia 25/12/2010)
git reflog (Mostra commits apagados pelo git reset)

Branches

Cada branch deve ter uma única funcionalidade. É recomendado criar um novo branch a partir do master e aplicar os merges nele para efeito de simulação.

git branch (Lista os branches)
git branch -a (Mostra também os branches do repositório remoto)
git branch -d novobranch (Apaga o branch)
git branch -D novobranch (Força a remoção do branch)
git checkout -b novobranch (Cria um branch contendo os mesmos commits do branch de origem)
git checkout -b novobranch origin/outrobranch (Cria novobranch a partir do outrobranch no repositório remoto)
git checkout -b [branch, tag, sha1]
git checkout -b <branch> v1.0 (Cria um branch a partir da tag v1.0)
git checkout master (Retorna ao branch master)
git rebase master (Atualiza um branch com o que há de novo no master)
git merge novobranch (Faz um merge do que foi feito em novobranch)
git merge novobranch --squash (Permite definir uma nova mensagem em vez das mensagens de todos os commits do novobranch)

Conflitos

Quanto mais tempo demorar para atualizar um branch a partir do master (git rebase), maior será a chance de haver conflitos depois.
O rebase é destrutivo, se estiver trabalhando em um servidor remoto deve usar o merge.

git rebase --skip (Perde o arquivo novo)
git rebase --abort (Cancela o rebase)
git rebase --continue (Para continuar após lidar com o conflito manualmente)

Repositórios

Clonando repositórios:

git clone repo1 repo2 (Clona um repositório e add o repo1 como orign no repo2)
git remote show origin (Origin é uma convenção para o primeiro remote)
git push origin (Envia o commit local para o repositório remoto)
git push origin outrobranch (O mesmo acima mas para um determinado branch)
git remote add origin repo (Adiciona um repositório como remoto)
git pull (Atualiza a partir do repositório remoto)
git pull origin outrobranch (O mesmo acima mas a partir de um determinado branch)
git remote rm origin (Remove o repositório remoto)

Trabalhando como repositórios remotos:
Antes de dar um git push, dar um git fecth e um git rebase para não criar conflitos para outros usuários.

git init --bare (Cria um repositório sem área de trabalho)
git fetch origin (Puxa novos commits do repositório remoto)
git fetch remote <branch> (Puxa novos commits do repositório remoto para o branch)
git push origin <branch> (Envia o que está no branch atual para o branch no repositório remoto)
git push origin v1.0 (Envia a tag v1.0)
git pull (Atualiza o repositório local a partir do remoto. Similar a usar "fecth" + "merge")
git pull origin <branch> (Atualiza o branch local a partir do branch remoto)

Github

Criando seu próprio projeto:
Crie um projeto pelo site do github. Em seguida, na máquina local, crie um par de chaves pública e privada, copie e cole no campo apropriado no github.

ssh-keygen -t rsa

Depois copiar o conteudo de ~/.ssh/id_rsa.pub e colar na página do github.

Fazendo um fork de um projeto:
Faça um fork de um repositório, um clone para sua máquina, altere o código, commit e no site clique no link “pull request”. O dono do repositório original deve adicionar a URL do repositório fork com git remote add usuario urlfork. Depois executar um git fecth para trazer os branches do fork. Usar git diff usuario/ para ver as alterações. Para aceitar, git merge (resolver conflitos caso apareça), criar um novo commit e enviar com o git push. O usuário que fez o fork deve executar o mesmo procedimentos para manter o fork sincronizado com o repositório original.

Patches

Trabalhando com patches:

git format-patch <branch> --stdout > patch.diff (Cria um patch)
git am patch.diff (Aplica o patch)

Tags

Uma tag é utilizada para criar uma versão de lançamento.

git tag v1.0 (Cria a tag v1.0)
git push origin v1.0 (Envia a tag v1.0)
git push --tags (Envia todas as tags)
git checkout -b <branch> v1.0 (Cria um branch a partir da tag v1.0)

git-svn

Lidando com svn:

git svn clone svn://repo (Clona um repositorio svn)
git svn dcommit (Envia commit para o repositório svn)
git svn fecth (Atualiza a partir do repositório svn)

Links

http://git-scm.com/
http://www.kernel.org/pub/software/scm/git/docs/

Apache Wicket é um framework web baseado em componentes utilizando a linguagem java. Entre suas características destaca-se o uso de XHTML puro para templates e ausência de arquivos XML para configurações.

Instalação

Há várias maneiras de instalar o Wicket mas vou abordar a mais simples que é através do Maven.

$ sudo apt-get install maven2
$ mvn archetype:create \
-DarchetypeGroupId=org.apache.wicket \
-DarchetypeArtifactId=wicket-archetype-quickstart \
-DarchetypeVersion=1.4.16 \
-DgroupId=net.gustavohenrique \
-DartifactId=introwicket \
-DinteractiveMode=false
$ cd introwicket
$ mvn eclipse:eclipse

Os comandos acima servem para fazer o download a partir dos repositórios do Maven e criar a estrutura do projeto compatível com o eclipse.
Depois é preciso importar o projeto no eclipse (File\Import\General\Existing Projects into Workspace).

Uma vez importado, nos deparamos com um erro na IDE acusando que não foi possível encontrar o diretório M2_REPO. Para corrigir basta criar a variável M2_REPO em Java Build Path apontando para o repositório local do Maven (geralmente $HOME/.m2/repository).

Configuração Inicial

Nosso exemplo criado através do Maven possui 3 arquivos: WicketApplication.java, HomePage.java e HomePage.html.
O primeiro é uma classe que extende de WebApplication, responsável pelas configurações do Wicket tal como diretório dos HTMLs, montagem de URLs, etc. Os outros 2 constituem um exemplo simples de página.

Uma página é uma classe que extende de WebPage e define via construtor quais os componentes inseridos via java. O nome do arquivo HTML deve ter o mesmo nome da classe java.
Por padrão, o Wicket procura o html da página no mesmo pacote da classe. Manter os .html junto aos .java é horrível e deixa o projeto desorganizado. Felizmente há como mudar isso.
Abra o WicketApplication.java e vamos fazer alguns ajustes na configuração:

package net.gustavohenrique;
 
import java.net.MalformedURLException;
import java.net.URL;
 
import org.apache.wicket.WicketRuntimeException;
import org.apache.wicket.protocol.http.SecondLevelCacheSessionStore;
import org.apache.wicket.protocol.http.WebApplication;
import org.apache.wicket.protocol.http.pagestore.DiskPageStore;
import org.apache.wicket.session.ISessionStore;
import org.apache.wicket.util.resource.IResourceStream;
import org.apache.wicket.util.resource.UrlResourceStream;
import org.apache.wicket.util.resource.locator.ResourceStreamLocator;
import org.apache.wicket.util.string.Strings;
 
public class WicketApplication extends WebApplication {
    public void init() {
        getMarkupSettings().setDefaultMarkupEncoding("UTF-8");
        getResourceSettings().setResourceStreamLocator(new MyOwnStreamLocator());
    }  
 
    public Class getHomePage() {
        return HomePage.class;
    }
 
    private class MyOwnStreamLocator extends ResourceStreamLocator {
        public IResourceStream locate(Class<!--?--> clazz, String path) {
            String extension = path.substring(path.lastIndexOf('.') + 1);
            String simpleFileName = Strings.lastPathComponent(clazz.getName(), '.');
            // "/" is webapp dir
            String location = "/" + simpleFileName + "." + extension;
 
            try {
                // try to load the resource from the web context
                URL url = WebApplication.get().getServletContext().getResource(location);
                if (url != null) {
                    return new UrlResourceStream(url);
                }
            }
            catch (MalformedURLException e) {
                throw new WicketRuntimeException(e);
            }
            // resource not found; fall back on class loading
            return super.locate(clazz, path);
        }
    }
 
}

O WicketApplication.java agora está configurado para usar UTF-8 como padrão e procurar os arquivos HTML dentro de src/main/webapp.

Brincando com Páginas

Uma página geralmente tem um contrutor que recebe os parâmetros via GET agrupados numa classe PageParameters similar à Map. É no construtor que adicionamos os componentes na página.

Vamos modificar o arquivo HomePage.java para adicionar um link externo e exibir o nome do autor e seu blog na tela de acordo com os parâmetros passados pela URL.

package net.gustavohenrique;
 
import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.link.ExternalLink;
import org.apache.wicket.markup.html.WebPage;
 
public class HomePage extends WebPage {
    public HomePage(final PageParameters parameters) {
        String author = parameters.getString("author", "Gustavo Henrique");
        add(new Label("author", author));
 
        String blog = parameters.getString("blog", "http://gustavohenrique.net");
        add(new ExternalLink("blog", blog));
    }
}

Agora é necessário alterar HomePage.html:

        Introducao ao Wicket
 
        <span>Texto aqui sera substituido</span>
 
        <a>Clique aqui para acessar</a>

O componente Label pode ser convertido para vários elmentos HTML, não apenas um span. O texto no código HTML que estiver dentro de um Label gerado pelo wicket será ignorado no momento da renderização.
Quando se adiciona um componente, obrigatoriamente é preciso usar a propriedade wicket:id="id_do_componente" caso contrário será lançada uma Exception.
Em modo de produção, o termo wicket:id some (fica apenas id) e as Exceptions lançadas são exibidas como erro 500.

Lidando com Formulários

Em Wicket quase tudo é componente. Para tirar melhor proveito do framework e evitar repetição de código é preciso entender como “componentizar” as coisas.
Imagine que você tenha 10 formulários e todos eles têm em comum os campos telefone, celular e email. A idéia de componentizar seria 1. Criar um form com esses componentes e todos os outros herdariam dele 2. Criar um componente (Panel) agrupando esses componentes e todos os forms adicionariam um único componente (1 Panel contendo 3 TextFields) ou 3. Juntar as duas soluções.
Conseguiram entender a idéia de componentização? Abaixo um exemplo sobre o que estou falando:

public class ContactPanel extends Panel {
    public ContactPanel(String id) {
        super(id);
        add(new TextField("phone"));
        add(new TextField("mobile"));
        add(new TextField("email"));
    }
}
 
public class CustomerForm extends Form {
    public CustomerForm() {
        add(new ContactPanel());
    }
}

Continuando nossa brincadeira com o framework…
Vamos criar um formulário para entrar com nome, idade, site e e-mail do autor.

package net.gustavohenrique;
 
import org.apache.wicket.markup.html.basic.Label;
import org.apache.wicket.markup.html.form.Form;
import org.apache.wicket.markup.html.form.RequiredTextField;
import org.apache.wicket.markup.html.form.TextField;
import org.apache.wicket.markup.html.panel.FeedbackPanel;
import org.apache.wicket.model.Model;
 
public class AuthorForm extends Form {
 
    private RequiredTextField name;
    private TextField site;
    private TextField email;
    private TextField age;
    private Label result;
 
    public AuthorForm(String id) {
        super(id);
        add(name = new RequiredTextField("name", new Model("")));
        add(age = new TextField("age", new Model("")));
        add(site = new TextField("site", new Model("")));
        add(email = new TextField("email", new Model("")));
        add(result = new Label("result", new Model("")));
        add(new FeedbackPanel("errors"));
    }
 
    protected void onSubmit() {
        String message = "Olá " + name.getValue() +
                         ", você tem " + age.getValue() +
                         ", seu site é " + site.getValue() +
                         " e seu e-mail é " + email.getValue();
        addOrReplace(result = new Label("result", new Model(message)));
    }
}

E é claro, precisamos incluir o form no HTML:

        Introducao ao Wicket
 
        <span>Texto aqui sera substituido</span>
 
        <a>Clique aqui para acessar</a>
<form method="POST">
<fieldset>
                <label>Nome</label>
<input type="text" />
                <label>Age</label>
<input type="text" />
                <label>Site</label>
<input type="text" />
                <label>E-mail</label>
<input type="text" />
<input type="submit" value="Go" /></fieldset>
</form>

A novidade é o uso do RequiredTextField, onSubmit, Model e FeedbackPanel.
Wicket possui recursos para validações simples como preenchimento obrigatório (required), apenas números, número máximo e mínimo de caracteres, etc. No caso o RequiredTextField requer preenchimento obrigatório.
Mensagens de erro validação podem ser personalizas e definidas em um arquivo de properties a parte. Quando ocorre um erro de validação, é chamado o método onError() em vez do onSubmit(). O FeedbackPanel é um componente que automaticamente exibe as mensagens de erros de validação.
É de boa prática usar Models Objects para guardar valores em componentes. Model é class que implementa IModel que por sua vez é uma interface que abstrai o tipo de dado que o componente recebe como valor. Varia de acordo com a implementação de cada componente. Em componentes Label e TextField, o Model pega o toString() do objeto passado. Já em um ListView é preciso que o objeto implemente uma lista (java.util.List).

Conclusão

Wicket é um framework baseado em componentes e talvez e, IMHO, esse seja seu maior defeito ou qualidade, depende de cada um. Essa foi uma apresentação básica bem superficial com o intuito de ser um ponto de partida para estudos mais aprofundados a quem achar que vale a pena investir tempo nesse framework.

Links relacionados:

http://wicket.apache.org
http://wicketstuff.org/wicket14/
https://cwiki.apache.org/WICKET/

Após alguns meses de abandono e alguns comentários não respondidos (sorry, wordpress mal configurado não me notificou por e-mail), pretendo (de novo) voltar a blogar.

2010 foi incrível. Conheci muita gente, fui em encontros/eventos de várias comunidades de software do RJ e tive uma grande evolução técnica principalmente em java e agile. Investi em ações, vi o final horrível de Lost e também comprei um playstation 3. Tinha três objetivos para o ano passado: dobrar meu salário, ganhar experiência em java e participar mais de projetos open source. A parte boa é que consegui os dois primeiros e a ruim é que eles atrapalharam o terceiro.

Em 2011 pretendo ler mais no kindle, trabalhar menos com java (j2ee) e quem sabe iniciar ou me juntar à alguma startup. Blogar vai ser meu termômetro. Enquanto estiver blogando, sinal de que estou seguindo pelo caminho que tracei. Eu acho.
Àqueles que visitaram esse humilde blog desatualizado, feliz ano novo!!!