Stiod Blog

É consenso que o fluxo natural de todos seja o amadurecimento, e é com vista nisso que passei a enchergar Java com outros olhos.

Antes eu via Java como uma linguagem muito prolixo, verboso, parecido com aquele momento em que você tem que documentar o seu TCC, porém, começo a sentir que isso é um mal necessário.

Como você pode confiar em um sistema que num determinado momento assume que uma variável é um inteiro e no outro é uma conexão em um servidor IRC pronta para receber comandos de algum mestre? Pois é, é exatamente assim que as linguagens com tipagem dinâmica se comportam, uma vez que o invasor alcança seu objetivo, ele poderá fazer o que quiser. Mas pode ficar tranquilo, esse tipo de coisa não acontece em Java, pois sua estrutura rígida impede que o invasor (ou mesmo o desenvolvedor, por que não?) faça o que bem entende do seu aplicativo.

Outro ponto que considerei, foi com relação a segurança de distribuição do seu sistema. Em linguagens dinâmicas e de script como Python, PHP e Ruby, você normalmente é obrigado a entregar o código-fonte de seus scripts (!!), existem soluções de obscuração de código, mas nada se compara ao excelente sistema de bytecodes do Java, com ele, você pode tranquilamente (sem trema) compilar seu programa e entregar a seu cliente, simples assim

E claro, não posso concluir sem antes falar sobre o número de pacotes de terceiros disponíveis, de acordo com o gráfico claro e lúcido que pode ser encontrado em http://www.cs.berkeley.edu/~flab/languages.html, a linguagem Java (uma das linhas vermelhas) é a que em 2006 mais possui projetos no SourceForge, ou seja, é muita gente criando projetos que com certeza serão úteis a você.

Então não perca tempo, comece logo a estudar Java, pois definitivamente esse será o futuro.

Como fazemos para pegar os valores de uma querystring rodando um shell script por cgi?

Vamos ao código:


for var in `echo $QUERY_STRING | tr "&" "\t"`
do
key=$(echo $var | tr = " " | awk '{print $1}';);
value=$(echo $var | tr = " " | awk '{print $2}';);
declare "query_$key"="$value";
done


Agora a lógica:

Quando chamamos um script via cgi, este cria a variavel de ambiente QUERY_STRING, que conterá o valor do GET em uma string única. Assim temos que tratar esta string para que tenhamos as variáveis com os valores que enviamos.

Vamos começar com este trecho:

`echo $QUERY_STRING | tr "&" "\t"`

Neste estamos mandando exibir o valor da variável QUERY_STRING e jogando a saida para o comando tr, que faz uma tradução de um texto em outro, transformando todos os & em \t no caso.
E o que é esta ` (crase) antes e depois do comando? Serve para você efetivamente executar um comando do shell, onde o resultado é retornado para o script.

Vamos para a próxima linha do script:

key=$(echo $var | tr = " " | awk '{print $1}';);


A partir desta linha, dentro do for, já temos a variavel var com o valor parametro=valor, então temos que pegar este parametro e valor. Exibimos o valor de var, jogando a saída padrão para o tr novamente, só que agora transformamos = em espaço, para aí jogarmos esta saída em outro programa para separar os argumentos, no caso o awk, onde mandamos exibir somente o primeiro parâmetro, rodando direto no shell seria algo como:


$ awk '{print $1}';
parametro valor
parametro


Digitando parametro e valor no awk e mandando exibir apenas o primeiro parâmetro ele retorna somente o primeiro.

Na linha seguinte do nosso script, a mesma coisa é feita, com a diferença de que o segundo parâmetro é pego para termos o valor e não a chave desta vez.

Agora já temos key com a chave do parâmetro do GET, e value com o valor da chave. Vamos a próxima linha:

declare "query_$key"="$value";


Agora estamos criando a variável com o valor de key com o valor de value. Como assim?

Se no GET tivessemos algo como stiod=nozes, $key teria o valor de stiod e $value o valor nozes. Então estariamos criando uma variável stiod com o valor nozes. Seria algo como se estivessemos digitado stiod=nozes no código. Ou seja, a partir deste momento, com o fim do for, temos uma variável com cada chave do GET com o prefixo "query_", e seus respectivos valores.

Seguindo o exemplo anterior, se tivessemos passado arquivo.sh?stiod=nozes, mandando exibir o valor da variável query_stiod seria exibido o valor nozes (echo $query_stiod)

É isso ai,

O comando que extrai todo o conteudo de um arquivo rpm, criando as pastas que o rpm criaria a partir do diretório atual:

rpm2cpio arquivo.rpm | cpio -idmv

Link sobre cpio

Olá !

Nesse post abordarei uma implementação básica de migration utilizando como base o framework Codeigniter.

Cenário

Para aqueles que desconhecem, o recurso de Migration consiste na abstração das alterações em bases de dados para uma classe que automatiza essa tarefa. Isso é particularmente útil quando trabalhamos em equipe e cada profissional desenvolve em seu ambiente, eventualmente modelando novas tabelas ou adicionando campos as já existentes. Dessa forma, evita-se trabalhar diretamente com o SQL (o que possibilita uma independência do SGBD) e o processo de atualização dos diversos ambientes (inclusive o de produção, quando for o caso) se torna mais simples e ágil.

Continue Lendo »

Estava com um problema onde eu precisava preencher um formulário de um arquivo PDF, e conseguia fazer isso gerando um arquivo FDF no PHP. Porém não era tão agradável o usuário baixar o arquivo no formato FDF, que nem é tão conhecido assim, e quando este arquivo fosse aberto, seria feito o download do PDF remoto com o formulário preenchido e ainda só depois de aberto este conseguir salvar uma versão final do arquivo PDF.
Foi então que o PDFTK resolveu o meu problema onde consigo fazer o "merge" destes 2 arquivos através do seguinte comando:

pdftk entrada.pdf fill_form formulario.fdf output saida.pdf


Além deste, também tinha outro problema onde eu precisava juntar vários arquivos pdf para gerar um dinamicamente, e através do PDFTK também conseguimos fazer este merge de PDFs da seguinte forma:

pdftk arquivo1.pdf arquivo2.pdf cat output saida.pdf


É isso ai! =)

Demorou mas chegou!!

Ai está a segunda parte do servidor de email que subi com Postfix + Squirrelmail um tempo atrás...

Instalando o Squirrelmail:

  
  # aptitude install squirrelmail
  # aptitude install php5
  
Quando instalarmos o pacote do squirrelmail, será instalado também o apache2 e outros pacotes e dependências necessárias para o funcionamento dessas ferramentas. 
Depois de instalado, uma das primeiras coisas que temos que fazer, é criar uma espécie de alias para abrir o squirrelmail no browser. Portanto, adicione as duas linhas abaixo no httpd.conf:

  # vim /etc/apache2/httpd.conf
  Alias /webmail "/usr/share/squirrelmail/"
  DirectoryIndex index.php

  Para definir algumas configurações do Squirrelmail, basta usar o comando abaixo. Esse comando abre várias opções de configurações que podemor alterar para deixar o squirrelmail com uma cara mais pessoal. 
  # squirrelmail-configure

  Para acessar o squirrelmail do seu browser, basta usar:
  http://IP.IP.IP.IP/webmail
  ou
  http://www.dominio.com.br/webmail

  Lembrando que a principio, os logins dos usuários são os mesmos usuários que estão criados dentro de /etc/passwd.
  Execute agora o comando que cria a pasta dentro do diretório /etc/skel, para que todos os homes dos novos usuários criados daqui em diante já sejam criados com o diretório Maildir, fundamental para o armazenamento de mensagens no Postfix:

  # maildirmake /etc/skel/Maildir

 Se você já tem usuários criados mas não tem o Maildir dentro do home deles, basta usar o comando abaixo que será criado o Maildir de maneira correta. Caso não seja criado, é bem provável que apareçam erros quando tentar enviar/receber emails:

  # maildirmake /home/usuario/Maildir

  Para trabalhar com o Postfix autenticado usando o módulo SASL e TLS.

  # aptitude install libsasl2 sasl2-bin libsasl2-modules libdb3-util procmail
  # vim /etc/default/saslauthd
  
  Substitua a linha "START=no" por: "START=yes"
E confirme se a linha abaixo está igual:

MECHANISMS="pam"

Também é necessário fazer mais algumas alterações:

  # vim /etc/postfix/sasl/smtpd.conf"

pwcheck_method: saslauthd

mech_list: plain login

Crie o diretório:

# mkdir -p /var/spool/postfix/var/run/saslauthd

  Novamente edite o arquivo e substitua uma linha:

# vim /etc/default/saslauthd
  OPTIONS="-c"  por: OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd -r"

  Reinicie o serviço:

  # /etc/init.d/saslauthd restart
    
  Adicione no postfix o  grupo SASL:

  # adduser postfix sasl

  O proximo passo é adicionar o SASL no  Postfix:

  # vim /etc/postfix/main.cf
  
  Adicione as seguintes linhas:

  smtpd_sasl_local_domain =
  smtpd_sasl_auth_enable = yes
  smtpd_sasl_security_options = noanonymous
  broken_sasl_auth_clients = yes
  smtpd_recipient_restrictions = permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination
  smtpd_tls_auth_only = no

  Reinicie o Postfix:

  # /etc/init.d/postfix reload
  # /etc/init.d/postfix restart

E então, desfrute!!

Para quem está estudando C++ aqui vai uma dica de como ler o valor de um endereço de memória. Basicamente o que vamos fazer são apenas conversões ou “casts” com os valores numéricos.
Continue Lendo »

O RequestContext do django serve para popular o template com variavés padrões, ou seja váriaveis comum aos templates. Quando você usar o RequestContext como parâmetro no render_to_response de sua view, ele usará os chamados context_processor setados na váriavel TEMPLATE_CONTEXT_PROCESSOR do settings.py do projeto(por padrão esta váriavel não esta no settings), funções que retornão um dicionário de dados.

 
TEMPLATE_CONTEXT_PROCESSORS = (
    "django.core.context_processors.auth",
    "django.core.context_processors.debug",
    "django.core.context_processors.i18n",
    "django.core.context_processors.media",
)
 

Para criar um contex_processor é só criar uma função da seguinte maneira, você pode criar um arquivo context_processor.py na pasta de sua app.

 
def teste_contex_processor(request):
    user = request.user
 
    return {
      'user':user,
      'ip_address': request.META['REMOTE_ADDR']
    }
 

e colocar o context_processor criado no settings

 
TEMPLATE_CONTEXT_PROCESSORS = (
    ...,
    "meuprojeto.app.context_processor.teste_context_processor",
)
 

Para usar o RequestContext no render_to_response, basta fazer o seguinte:

 
    ...
    return render_to_response(
        'templates/index.html',
        dicionario_de_dados,
        context_instance=RequestContext(request)
    )
 

*lembrando que você tem que passar request como parâmetro.

People,

Esses dias tive que estudar um pouco sobre Postfix para entender marromenos como que funciona um server de email. Então ai vai um passo-a-passo do que eu fiz para subir  esse servidor de email com Postfix usando o squirrelmail para testar os envios e recebimentos dos emails
Usei Ubuntu Server (não gosto muito mas era o que eu tinha na mão) e gerenciador de pacote aptitude. O mesmo funciona com apt-get se preferir :-p

Primeiramente, vamos instalar os pacotes básicos na máquina. Esses pacotes não são necessariamente só do Postfix.

# aptitude install openssh-server vim-full mutt nmap postfix

Durante a instalação, provavelmente serão feitas algumas perguntas. Por enquanto, apenas dê ENTER para todas elas. Porque assim que a instalação terminar, iremos reconfigurar algumas opções e depois editar o arquivo de configuração direto.

Feita a instalação, vamos reconfigurar algumas opções básicas:

# dpkg-reconfigure postfix

Abaixo, segue um exemplo de configuração que foi definida:

=> OK
=> Internet Site
=> dominio.com.br
=> (em branco)
=> $myhostname, localhost.$mydomain, $mydomain
=> yes
=> 127.0.0.0/8 192.168.1.0/24
=> yes
=> 0
=> +
=> all

Depois que definirmos todas essas configurações, então automaticamente o postfix será recarregado (reload) e reiniciado.
Nesse server básico de Postfix, estou usando a mesma base de usuários comuns do sistema, como usuários que terão email no postfix. Lembrando que todos esses usuários comuns, são os que possuem ID maior que 1000 e estão dentro de /etc/passwd.

Para esse primeiro teste, vou adicionar um usuário novo no sistema:

# adduser joao

Como o postfix já está instalado e com uma pré-configuração, então vamos enviar alguns emails entre os usuários comuns do sistema. Para isso, vamos usar o telnet mesmo:

$ telnet localhost 25

HELO smtp.dominio.com.br
MAIL From: user@dominio.com.br
RCPT to: joao@dominio.com.br
DATA
Mensagem do email.
.
QUIT

Como estamos fazendo tudo na máquina local por enquanto, então usei um telnet localhost na porta 25. Na linha HELO como o próprio nome já fala, estou dando um "Olá" para o meu server de email e domínio. Na linha MAIL From estou avisando qual o usuário que irá enviar o email e na linha RCPT to está o usuário que irá receber o email. Para escrever a mensagem, chamamos o DATA e então basta escrever o que você quiser. Para finalizar a mensagem, basta dar um . único e ele entenderá como fim da mensagem. E para finalizar o telnet, basta dar um QUIT.
É importante prestar atenção nas palavras e letras maiúsculas.

Quando enviarmos esse email para o joao@dominio.com.br, será criado um arquivo com o nome do usuário em /var/mail/.
Por exemplo:

# ls /var/mail
joao

Então para ler o email, pode-se dar um cat nesse arquivo, ou então usar uma ferramenta chamada mutt, que lê emails em linha de comando.

# cat /var/mail/joao
ou
# su joao
$ mutt

Abaixo, segue a estrutura do arquivo /etc/hostname:

# cat /etc/hostname
dominio.com.br

Abaixo, segue a estrutura do arquivo /etc/hosts:

# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 dominio.com.br dominio.com.br
IP.ex.ter.no dominio.com.br dominio.com.br

A estrutura desses arquivos é importante, porque dependendo dos casos, o hostname e o domínio tem que estar com o mesmo nome.

O arquivo de configuração do Postfix está localizado em /etc/postfix/main.cf.
Abaixo vou colocar umas linhas básicas desse arquivo de configuração para analisar o conteúdo. Não vou explicar o que todas as linhas fazem, mas sites como o do próprio postfix explica o conteúdo de cada linha e muitas vezes cita exemplos =p

# vim /etc/postfix/main.cf
myhostname = IP.ex.ter.no.dominio.com.br
mydomain = dominio.com.br
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname, localhost.$mydomain, $mydomain
relayhost =
relay_domains = $mydomain
mynetworks = 127.0.0.0/8 192.168.1.0/24
home_mailbox = Maildir/
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
mailbox_size_limit = 0

Vamos configurar os serviços de pop e imap. Para isso, será necessário instalar os seguintes pacotes:

# aptitude install courier-pop courier-pop-ssl
# aptitude install courier-imap courier-imap-ssl

Quando instalarmoas esses pacotes, será criado um diretório courier dentro do /etc/ e dentro desse diretório, teremos diversos arquivos. Antesde editar os arquivos e fazer as alterações, aconselho renomear os arquivos originais:

# cd /etc/courier
# mv imapd.pem imapd.pem.old
# mv pop3d.pem pop3d.pem.old

O próximo passo, é editar os arquivos imap.cnf e pop3d.cnf e alterar as informações necessárias. Por exemplo coloque em Country=BR, State=Sao Paulo e etc:

# vim imapd.cnf
# vim pop3d.cnf

Quando os arquivos forem alterados, devemos devemos criar novamente os arquivos imapd.pem e pop3d.pem com os comandos:

# mkimapdcert
# mkpop3dcert

O próximo passo agora é instalar o squirrelmail, que é uma ferramenta para testar o envio e recebimento de mensagens de email através de uma interface web mesmo. Se preferir, pode usar alguma outra ferramenta, como eu já tinha comentado antes:

# aptitude install squirrelmail
# aptitude install php5

Continua... :-p

Links de Referências:

http://www.postfix.org/documentation.html

https://help.ubuntu.com/7.04/server/C/postfix.html

http://virtual01.lncc.br/~licht/linux/servidores.postfix.arq.html

http://www.gdhpress.com.br/redeseservidores/leia/index.php?p=cap10-2

Finalmente o Django pra mim atingiu a perfeição, depois da minha surpresa com o {{ block.super }}, agora foi a vez de eu realizar um sonho meu: Aproveitar as interfaces maravilhosas de administração do Django.

Sempre é um verdadeiro pé no saco ter que ficar escrevendo código que você sabe que ta pronto, e mais sacal ainda quando o código ta a apenas "../../" de você, mas agora é um trabalho a menos que eu tenho (especialmente considerando a minha "super habilidade" com CSS).

Agora vamos ao que interessa, o conhecimento necessário pra fazer isso funcionar levou cerca de 4 horas pra ser adiquirido, foram 4 horas engolindo e reengolindo código do Django, mas no final resultou em uma view como a seguinte (ignorem os imports desnecessários):

 
from django.shortcuts import render_to_response
from django.template import RequestContext
from django.utils.text import ugettext_lazy as _
from django.contrib.auth.decorators import login_required
from mysearch.profiles.models import Profile
from mysearch.profiles.admin import ProfileAdmin
from django.contrib import admin
from django.contrib.admin.views.main import ChangeList
 
from django.contrib.auth.models import User
from django.contrib.auth.forms import UserCreationForm
 
@login_required
def index(request):
    admin_model = admin.site._registry[Profile]
    admin_model.admin_site.root_path = request.path
    cl = ChangeList(
        request,
        Profile,
        ProfileAdmin.list_display,
        ProfileAdmin.list_display_links,
        ProfileAdmin.list_filter,
        ProfileAdmin.date_hierarchy,
        ProfileAdmin.search_fields,
        ProfileAdmin.list_select_related,
        ProfileAdmin.list_per_page,
        admin_model)
    cl.query_set = cl.query_set.filter(user=request.user)
    cl.get_results(request)
 
    context = {
        'title': cl.title,
        'is_popup': cl.is_popup,
        'cl': cl,
        'has_add_permission': admin_model.has_add_permission(request),
        'root_path': admin_model.admin_site.root_path,
        'app_label': _('Profile'),
    }
 
    return render_to_response('admin/change_list.html',
        context, context_instance=RequestContext(request))
 

Vamos as explicações agora. Primeiramente, pra que isso funcione é preciso que seu model tenha sido registrado no Admin do Django, no meu caso o model utilizado foi esse chamado Profile.

Depois disso é criado um objeto do tipo `django.contrib.admin.views.main.ChangeList`, infelizmente todos os parametros devem ser passados, e essa foi a parte que mais me decepcionou, uma vez que todos os atributos poderiam ser resgatados com base no último argumento, ou simplesmente pedindo a classe que define o model, mas tudo bem, é um pequeno preço a se pagar pelo beneficio.

Após criar a variável `cl`, vem o ponto que meu deu maior dor de cabeça: Filtrar o que eu quero que apareca para o usuário. Nesse caso eu precisava que o usuário tivesse acesso apenas ao próprio conteudo, e pra isso adicionei o `.filter(user=request.user)`, porém, isso não basta, é preciso chamar a função `cl.get_results(request)` pra que ele possa atualizar a lista de resultados que vai ser usada

A váriavel `context`, neste caso, é usada pelo template `admin/change_list.html`, sinta-se a vontade para copiar o template da pasta do Django e colocar na sua pra editar.

Por fim, basta retornar o template que vai pegar o resultado e imprimir na tela pro seu usuário que será muito feliz
Observações
O template `admin/change_list.html` não imprime a tabela propriamente dia, ela utiliza uma tag (não documentada no site) chamada `result_list`, essa tag recebe um objeto do tipo `ChangeList` que é o nosso `cl`.

Você ainda vai precisa escrever uma view (ou aproveitar a do Admin) para fazer o handle quando o usuário clicar no objeto, mas essa é a parte fácil