BDD com python: Pyccuracy

Achei muito interessantes esta biblioteca pra fazer BDD com python. Ela é baseada no Accuracy (para C# e .net).

Maiores informações: http://tinyurl.com/c64qpp

"Create Django Application" para TextMate

Criei um pequeno comando no editor de Bundles do TextMate pra criar uma aplicação no django. Ele cria já uma estrutura de diretórios que deixa tudo pronto pra escrever templatetags, novos templates, testes, etc.

A estrutura de diretórios fica assim:

app_name/
|
`- __init__.py
|
`- admin.py
|
`- fixtures/
|
`- models.py
|
`- templates/
|
`- templatetags/
|       |
|        `- __init__.py
|
`- tests/
|     |
|      `- browser_tests.py
|     |
|      `- model_tests.py
|     |
|      `- nav_tests.py
|
`- urls.py
|
`- views.py

Segue o código (também disponível em [1]):

res=$(CocoaDialog inputbox --title "Create Application" --informative-text \
                                 "Application name:" --button1 "Ok" \
                                 --button2 "Cancel")

[[ $(head -n1 <<<"$res") == "2" ]] && exit_discard

app_name=$(tail -n1 <<<"$res")

if [ -f "$TM_PROJECT_DIRECTORY/manage.py" ]; then
MANAGE="python manage.py"
else
MANAGE="django-admin.py"
fi

cd $TM_PROJECT_DIRECTORY
$MANAGE startapp $app_name
mkdir $app_name/templatetags $app_name/templates $app_name/tests \
     $app_name/fixtures $app_name/media
touch $app_name/urls.py $app_name/admin.py $app_name/templatetags/__init__.py \
     $app_name/tests/__init__.py
cat > $app_name/urls.py <<EOF
#insert your custom urls here.
from django.conf.urls.defaults import *

urlpatterns = patterns('',
)
EOF

cat > $app_name/admin.py <<EOF
from django.contrib.admin import site
from ${app_name}.models import *

EOF

cd $app_name/tests

for testtype in model browser nav; do
touch ${testtype}_tests.py
cat > ${testtype}_tests.py <<EOF
#${testtype} tests for ${app_name}
from django.test import TestCase
EOF
done

cd -

CocoaDialog ok-msgbox --title "Application Created." \
         --informative-text "Application $TM_PROJECT_DIRECTORY/$app_name created." \
         --button1 "Ok" --float
rescan_project

[1] http://pastebin.com/f1a862c33

Incializando Daemons no Mac OS X

Olá, pessoal! Há muito tempo não posto aqui, mas prometo não ser mais tão relapso :)
Hoje vou contar aqui minha experiência com o launchd, o gerenciador de serviços do Mac OS X. Não é uma experiência muito vasta, mas acho que já é válida pra quem está procurando informações.
Durante este post, vamos ver os seguintes tópicos:

• O que é e como funciona o launchd
• Configuração do serviço
• Opções gerais do arquivo launchd.plist
• Aplicação real: Configurando o daemon de atualização do no-ip[3]

Ao final, estaremos executando o daemon automaticamente durante a inicialização do seu mac :-)

Termos Utilizados

• agent - Programa que roda em background, e é inicializado quando o usuário faz login;
• daemon - Programa que roda em background, e é inicializado juntamente com o Mac OS X.

O que é e como funciona o launchd

Configurar um serviço para rodar em background na inicialização de um sistema operacional nem sempre é uma tarefa simples (tome-se como exemplo a dor de configurar serviços no windows, ou mesmo fazer gerenciamento dos scripts rc*.d no linux). No Mac OS X, o sistema gerenciador de processos é o launchd. Ele gerencia tanto processos que são lançados quando o usuário inicializa a sessão (agents), quando os que são inicializados durante o boot (daemons), e você pode configurar ambos os tipos de aplicação para serem iniciados a seu gosto.
Para fazer o lançamento das aplicações durante o login, o launchd busca informações em arquivos .plist[1] nas seguintes pastas no sistema operacional:

• ~/Library/LaunchAgents - para programas a serem inicializados no login de um usuário específico (provido pelo usuário);
  
• /Library/LaunchAgents - para programas que serão inicializados no login de todos os usuários (provido pelo administrador do sistema);
  
• /Library/LaunchDaemons - para programas a serem lançados durante a inicialização do sistema (provido pelo administrador do sistema);
• /System/Library/LaunchAgents - para serviços internos do Mac OS X a serem lançados no login dos usuários;
  
• /System/Library/LaunchDaemons - para serviços internos do Mac OS X a serem lançados durante o boot.
  

Configuração do serviço

Os passos para a configuração do serviço são poucos e simples. Primeiro, criamos um arquivo .plist com as configurações desejadas do serviço. Depois, colocamos o arquivo em uma das pastas acima citadas, conforme o fim desejado. E pronto! na próxima inicialização, o Leopard já vai inicializar seu serviço normalmente.
Um arquivo .plist nada mais é do que um tipo de arquivo XML, com algumas tags para definição de tipos de dados para a representação de dicionários, listas, strings, etc. É vastamente utilizado em softwares escritos em Objective-C, para serialização de dados.
Para editar um arquivo .plist podemos utilizar qualquer editor de texto. Para quem tem o Xcode instalado, podemos usar o Property List Editor:

Opções gerais do arquivo launchd.plist

A lista completa de opções para um arquivo .plist pode ser obtida em[5]. Seguem aqui os parâmetros mais geralmente usados:

• Label (String) - Identifica únicamente o trabalho a ser executado pelo launchd;
• Disabled (Boolean, false por padrão) - Coloque esta opção para desabilitar temporariamente a inicialização;
  
• UserName (String) - Especifica o usuário que executará o programa. Somente aplicável se o launchd é executado como root.
  
• GroupName (String) - Especifica o grupo que executará o programa. Somente aplicável se o launchd é executado como root.
  
• Program (String) - Caminho completo para a execução do programa;
  
• ProgramArguments (Lista de Strings) - Lista de parâmetros para a execução do programa;
• RunAtLoad (Boolean, false por padrão) - Define se o serviço vai ou não ser carregado na inicialização;
  
• RootDirectory (String) - Caminho para execução "engaiolada" (chrooted);
  
• WorkinDirectory (String) - Caminho para execução da aplicação (chdir).
  

Aplicação real: Configurando o daemon de atualização do no-ip

Primeiro, precisamos baixar o cliente do no-ip em [4], e instalá-lo normalmente. Feito isto, vamos criar um arquivo chamado com.noip.noip2.plist, e editar as seguintes propriedades:

Key	Type	Value
UserName	String	root
Label	String	com.noip.noip2
GroupName	String	wheel
RunAtLoad	Boolean	true
OnDemand	Boolean	false
Program	String	/usr/local/bin/noip2

Para quem quiser editar o arquivo em um editor de texto normal, o código deve ficar desta forma:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>UserName</key>
<string>root</string>
<key>Label</key>
<string>com.noip.noip2</string>
<key>GroupName</key>
<string>wheel</string>
<key>RunAtLoad</key>
<true/>
<key>OnDemand</key>
<false/>
<key>Program</key>
<string>/usr/local/bin/noip2</string>
</dict>
</plist>

E pronto! ao reiniciar o computador, você pode checar o daemon rodando através do comando:

[rodolfocarvalho@imac-rox:~]$ ps aux |grep noip2
root    3717  95.8  0,0   132152    480   ??  Rs   Qua10   1557:56.10 /usr/local/bin/noip2

É isto! espero que minha ajuda tenha sido útil! Qualquer sugestão ou dúvida, é só postar um comentário ;)

Referências:
[1] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/plist.5.html
[2] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man8/launchd.8.html
[3] http://www.no-ip.com
[4] http://www.no-ip.com/client/mac/noip3.1.2a.dmg
[5] http://developer.apple.com/documentation/Darwin/Reference/ManPages/man5/launchd.plist.5.html#//apple_ref/doc/man/5/launchd.plist

Linux como Cliente Active Directory com Samba, Kerberos e Winbind

Olá a todos!
Ontem passei por maus bocados tentando colocar um box linux (Ubuntu 7.04) pra funcionar fazendo logon em um Active Directory, e de quebra ainda fazer ele navegar passando pelo proxy autenticado do ISA server.
Encontrei alguns artigos e tutoriais no nosso querido amigo Google. O que mais me interessou foi este, por se tratar de instalação no ubuntu, e também pela linguagem bem simplificada. Gosto muito de ver pessoas que trabalham com software livre interessadas também na qualidade do material passado à comunidade.
Como o artigo está em inglês (e nem todo mundo tem intimidade com o idioma), vou fazer um resumão do howto aqui no blog.

Ao final desse post, tudo vai estar funcionando após termos cumprido estes passos:

• Checar a conectividade com os servidores
• Acertar a hora da máquina
• Definir um nome para a máquina cliente
• Instalar e configurar os pacotes necessários
• Testar a configuração
• Ver tudo funcionando =)

Considerações Iniciais

Para os que não sabem, o Microsoft® ActiveDirectory é um serviço de diretório, combinado com um sistema de autenticação baseada em tickets. Em outras palavras, é uma implementação do serviço de diretórios LDAP com o Kerberos, do MIT. É importante separarmos serviço de diretório e autenticação, pois utilizaremos estes itens separadamente na hora da implementação do serviço no linux.

Termos Utilizados

• AD: Active Directory
• DC: Domain Controller (Controlador de Domínio)
• lab.exemplo.com: domínio AD
• LAB: domínio AD (formato simplificado, utilizado como 'nome do domínio' no logon das máquinas windows.
• win2k3.lab.exemplo.com: FQDN do DC
  
• 10.0.0.1: Endereço IP do DC
• linuxwork: Nome da máquina que será cliente windows
• LAB.EXEMPLO.COM: Realm (domínio) do Kerberos
• linuxwork.lab.exemplo.com: FQDN da máquina linux
• ntp.exemplo.com: Servidor de Horário (NTP)

Checando a Conectividade

O primeiro passo para configurar a máquina linux é checar se há conectividade entre ele e o DC. Uma maneira simples de fazer isso é 'pingar' o host, dessa maneira:

root@linuxwork:~# ping win2k3.lab.exemplo.com

PING win2k3.lab.exemplo.com (10.0.0.1) 56(84) bytes of data.
64 bytes from win2k3.lab.example.com (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms

É importante checar a conectividade usando o FQDN do DC, pois o AD é dependente do bom funcionamento do DNS (um AD DC sempre tem um servidor DNS instalado).

Servidor de Horário (NTP)

O Tempo é fundamental para o Kerberos, logo devemos estar com o relógio acertado com o AD DC. Não se preocupe, todo AD DC é por si só um servidor de horário =).
Para mantar o relógio sincronizado, vamos instalar o ntp e configurá-lo para buscar a hora no DC:

root@linuxwork:~# apt-get install ntp

No arquvo de configuração do NTP, coloque o FQDN do DC como servidor de horário:

Arquivo: /etc/ntp.conf

...
# You do need to talk to an NTP server or two (or three).
server win2k3.lab.exemplo.com
...

Feito isso, basta reiniciar o servidor ntp:

root@linuxwork:~# /etc/init.d/ntp restart

FQDN

É preciso definir um FQDN para a máquina linux para fazer tudo funcionar com Kerberos e LDAP. Para isso, edite o arquivo /etc/hosts para que a máquina possa reconhecer a si própria:

Arquivo: /etc/hosts

127.0.0.1 linuxwork.lab.exemplo.com localhost linuxwork

Você pode testar a configuranção 'pingando' seu próprio FQDN. o PING deve ser direcionado para o IP 127.0.0.1.

Instalando e Configurando o Kerberos

A primeira coisa a se fazer é instalar os pacotes necessários:

root@linuxwork:~# apt-get install krb5-user libpam-lrb5

Este comando também irá instalar o pacote krb5-config, entre outros.
Na configuração do krb5-config, você será questionado sobre alguns dados. Responda da seguinte forma:

Quais são os servidores Kerberos para o seu domínio?
win2k3.lab.exemplo.com

Qual é o servidor administrativo para seu domínio Kerberos?
win2k3.lab.exemplo.com

Testando
Requisite um 'ticket-granting-ticket' utilizando o kinit:

root@linuxwork:~# kinit Administrador@LAB.EXEMPLO.COM
Password for Administrator@LAB.EXAMPLE.COM: ****

Se nenhuma mensagem for mostrada, é sinal que tudo deu certo! =D

Você pode checar os tickets ativos a qualquer hora através do klist:

root@linuxwork:~# klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@LAB.EXEMPLO.COM

Valid starting     Expires            Service principal
01/21/05 10:28:51  01/21/05 20:27:43    krbtgt/LAB.EXEMPLO.COM@LAB.EXEMPLO.COM
renew until 01/21/05 20:28:51

A partir deste momento o Kerberos já está configurado corretamente. Você pode se desfazer do ticket utilizando o kdestroy.

Entrando no Domínio do ActiveDirectory

Antes de tudo, vamos instalar o software necessário:

root@linuxwork:~# apt-get install samba winbind smbclient smbfs

Configuração

Salve o arquivo /etc/samba/smb.conf como /etc/samba/smb.conf.default. Edite um novo arquivo smb.conf:

Arquivo: /etc/samba/smb.conf

[global]
security = ads
realm = LAB.EXEMPLO.COM
password server = 10.0.0.1
workgroup = LAB
#       winbind separator = +
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
template homedir = /home/%D/%U
template shell = /bin/bash
client use spnego = yes
client ntlmv2 auth = yes
encrypt passwords = yes
winbind use default domain = yes
restrict anonymous = 2
# to avoid the workstation from
# trying to become a master browser
# on your windows network add the
# following lines
domain master = no
local master = no
preferred master = no
os level = 0

Nota: Esta configuração é feita para o logon em apenas um domínio. Caso a máquina faça logons em mais de um domínio, você deve descomentar a linha 'winbind separator' e comentar a linha 'winbind use default domain'

Agora, é preciso reiniciar os serviços do winbind e samba:

root@linuxwork:~# /etc/init.d/winbind stop
root@linuxwork:~# /etc/init.d/samba restart
root@linuxwork:~# /etc/init.d/winbind start

Para entrar no domínio, requisite um TGT (Ticket-Granting-Ticket) para o servidor Kerberos (usando kinit). Após isto, faça:

root@linuxwork:~# net ads join
Using short domain name – LAB
Joined 'linuxwork' to realm 'LAB.EXAMPLE.COM'

Nota: O primeiro logon da máquina deve ser feito por um usuário que tenha permissões para adição de máquinas no domínio.

Testando

Para testar se tudo deu certo até então, vamos usar o wbinfo:

root@linuxwork:~# wbinfo -u

Este comando deve exibir os usuários constantes no domínio.

root@linuxwork:~# wbinfo -g

Este comando deve exibir os grupos (security groups) constantes no domínio.

Autenticação

Agora é preciso configurar o sistema para fazer logon de usuários executando a pesquisa na base de dados AD do DC.

nsswitch

Edite o arquivo /etc/nsswitch.conf:

passwd:         compat winbind
group:          compat winbind
shadow:         compat

Testando

root@linuxwork:~# getent passwd

root:x:0:0:root:/root:/bin/bash
...
LAB+administrator:x:10000:10000:Administrator:/home/LAB/administrator:/bin/bash
LAB+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash
...

Nota: se o samba foi configurado com a opção winbind use default domain = yes, o domínio (LAB) não será exibido antes do nome de usuário.

PAM

Com esta configuração, você pode acessar o computador com contas locais ou com contas de usuário de domínio.
No primeiro login de uma conta de usuário e domínio, seu diretório home será criado. Esta configuração do PAM considera que o sistema primário de autenticação será baseado em contas de domínio e, em segundo lugar, serão usadas as contas de usuários locais. Se a configuração desejada for inversa (se o sistema usar primeiramente as contas locais, por exemplo), a ordem de pam_winbind.so e pam_unix.so deve ser trocada. Quando usada com contas locais, a configuração mostrada aqui irá resultar em falha na autenticação para todas as contas Windows/Samba DC que fizeram login ou usarem o sudo.
Vamos então à configuração:

Arquivo: /etc/pam.d/common-account

account sufficient       pam_winbind.so
account required         pam_unix.so

Arquivo: /etc/pam.d/common-auth

auth sufficient pam_winbind.so
auth sufficient pam_unix.so nullok_secure use_first_pass
auth required   pam_deny.so

Arquivo: /etc/pam.d/sudo

auth sufficient pam_winbind.so
auth sufficient pam_unix.so use_first_pass
auth required   pam_deny.so

@include common-account

Configuração Final

Para fazer tudo funcionar, agora basta criar o diretório /home/LAB:

root@linuxwork:~# mkdir /home/LAB

Isto porque configuramos o arquivo /etc/samba/smb.conf para apontar a pasta home das contas de usuário do domínio para /home/%D/%U (%D = domínio, %U = usuário)

Agora basta fazer o logon na máquina:

login: manuel
Password: *****
...
LAB+manuel@linuxwork:~$

Se a opção winbind use default domain = yes estiver setada, então o usuário deverá fazer logon utilizando o formato DOMINIO+usuario, desta forma: LAB+manuel.

Desta forma, tudo deve funcionar perfeitamente, durante o login e navegação na rede. A partir de agora, vamos apenas fazer as configurações para os aplicativos funcionarem com a autenticação do ISA server.

Proxy
Estava tudo lindo até então... tudo funcionou perfeitamente até aí! A autenticação do sistema com o domínio funcionou perfeitamente. A única coisa que achei um pouco redundante foi o fato de após o logon, ainda precisamos abrir uma tela de terminal, pegarmos o TGT, e entrar na rede com net ads join. Vou estudar uma forma de automatizar o processo, e logo estarei postando aqui.
Mas o que eu imaginava não dar trabalho, me tirou algumas horas pra estudar uma solução. O proxy do ISA server utiliza uma tecnologia proprietária para autenticação, o NTLM (NT LAN Manager), que não funciona como a autenticação de proxy que vemos no squid, por exemplo. Não tive problemas de navegação no Firefox, pois o mesmo tem suporte à autenticação NTLM (inclusive, Ele integra-se com o Kerberos, não necessitando de login/senha no browser, uma vez que o usuário já possua um TGT válido), mas as demais aplicações (como o APT, por exemplo), não funcionavam, mesmo setando a variável $http_proxy no profile do usuário. Mas o 'sofrimento' foi cessado quando encontrei o ntlmaps, ou 'NTLM Authentication Proxy Server', um daemon que funciona como 'proxy do proxy'. Ele se autentica no proxy da Microsoft, e provê o acesso através da porta 5865.
A instalação é tranquila, pois o software já está no respositório do Ubuntu. Para instalar, usamos o bom e velho apt-get:

root@linuxwork:~# apt-get install ntlmaps

Eu recomendo que seja criado um usuário exclusivo para acesso ao ntlmaps no domínio windows (eu o nomeei como 'apt-user', e coloquei-o com permissões de acesso à internet pelo ISA server). As informações deste usuário devem ser colocadas nas configurações do ntlmaps. No prompt de configuração, responda:

Listen Port
5865

Parent Proxy
[IP d ISA]

NT Windows Username:
apt-user

NT Windows Password:
[senha]

Feito isso, basta colocar esta configuração no arquivo /etc/profiles:

...
export http_proxy="http://127.0.0.1:5665/"
...

Nota: o ntlmaps só funciona com HTTP. Mas se você quiser fazer download de arquivos em sites FTP, não se preocupe! o curl tem suporte a autenticação NTLM. Para facilitar o trabalho, criei um script que 'faz o trabalho'. Utilizei-o também no FreeBSD, pra instalar ports, basta substituir o comando 'fetch' por este script. Aqui está fonte do script:

#!/bin/sh

URL=$(echo "$@" | awk -F" " '/^.*[a-z]:\/\/.*/{ \
split($0, args, " "); \
for(i in args){ \
if(args[i] ~ /[a-z]:\/\//){ \
 print args[i]; break; \
} \
} \
}')

echo "fetching $URL..."

/usr/local/bin/curl -O \
              --proxy-ntlm \
              --proxy http://[ip do ISA]:8080 \
              --proxy-user LAB\\apt-user:password $URL

Bem, depois disso, as coisas funcionaram bem bem melhor.
Futuramente, vou postar outro artigo, mostrando como fazer um servidor linux ser um controlador de domínio para máquinas Windows. Até breve!

FiRST TiMe HeRe...

Olá! No meu primeiro post quero desejar boas-vindas a todos os visitantes desse blog! Espero que suas visitas sejam muito proveitosas.

Certa vez, meu amigo Adriano me disse que eu era bom pra testar as coisas... ele sempre vinha com notícias do Slashdot, Think Geek ou outro site geek, ou mesmo notícias da mailing list do python-brasil... sempre que surgia uma ferramenta, uma framework (geralmente escrita em python), ele era o primeiro a me contar... e eu era sempre o primeiro a testar.

Resolvi então criar este blog para compartilhar as experiências dos meus testes, e outras coisas bacanas que a gente acha na net a respeito de programação, de preferência utilizando software livre.


That's all, folks!

Enjoy!