quinta-feira, 27 de janeiro de 2011

Como Instalar o Pd-Extended no Debian e Ubuntu?

O Pd (ou Pure Data) é um programa de síntese e manipulação digital de áudio extremamente poderoso e vastamente utilizado por profissionais de áudio, pesquisadores, estudantes, compositores, dentre vários outros especialistas da área de áudio, som e música. A instalação normal do programa vem apenas com um pacote básico de recursos e apetrechos, mínimo para que o programa funcione. Entretanto, existem pacotes adicionais com milhares de novos objetos e algoritmos pré-implementados que se tornam facilmente uma mão na roda para quem trabalha com Pd.
Instalar estes pacotes adicionais não é complexo e pode ser feito pelo seu gerenciador de pacotes, se você usa Debian ou Ubuntu!! Basta seguir a dica abaixo:


  • Editando o /etc/apt/sources.list

Os pacotes adicionais foram reunidos todos em um grande pacote DEB. No entanto, este pacote não está nos repositórios padrões tradicionais. Assim, é preciso adicionar um repositório novo à seu banco de repositórios. Fazer isto é simplesmente editar o arquivo /etc/apt/sources.list (como root!!):

vi /etc/apt/sources.list

Agora acrescente a linha correspondente à sua distro e versão, de acordo com as opções abaixo (havendo dúvidas, estes endereços também estão dispostos no site oficial, clicando em http://puredata.info/docs/faq/debian):

Para Debian:
 # Debian/stable
deb http://apt.puredata.info/releases stable main
# Debian/testing
deb http://apt.puredata.info/releases testing main
# Debian/sarge
deb http://apt.puredata.info/releases sarge main
# Debian/etch
deb http://apt.puredata.info/releases etch main
# Debian/lenny
deb http://apt.puredata.info/releases lenny main
# Debian/squeeze
deb http://apt.puredata.info/releases squeeze main

Para Ubuntu:
# Ubuntu/dapper 06.04 LTS
deb http://apt.puredata.info/releases dapper main
# Ubuntu/edgy 06.10
deb http://apt.puredata.info/releases edgy main
# Ubuntu/feisty 07.04
deb http://apt.puredata.info/releases feisty main
# Ubuntu/gutsy 07.10
deb http://apt.puredata.info/releases gutsy main
# Ubuntu/hardy 08.04 LTS
deb http://apt.puredata.info/releases hardy main
# Ubuntu/intrepid 08.10
deb http://apt.puredata.info/releases intrepid main
# Ubuntu/jaunty 09.04
deb http://apt.puredata.info/releases jaunty main
# Ubuntu/karmic 09.10
deb http://apt.puredata.info/releases karmic main
# Ubuntu/lucid 10.04 LTS
deb http://apt.puredata.info/releases lucid main

Agora, salve o arquivo e atualize o repositório de pacotes local, digitando, como root:

apt-get update


  • Instalando o Pacote pd-extended

Agora é bem fácil: seu Linux já sabe como baixar o pacote DEB que você necessita, bastando apenas que você solicite a sua instalação, com o comando abaixo (como root!!). Responda "sim" para as perguntas que forem formuladas (não se preocupe com a mensagem de que o pacote não pôde ser verificado quanto à autenticação):

apt-get install pd-extended

Lendo listas de pacotes... Pronto
Construindo árvore de dependências
Lendo informação de estado... Pronto
Os pacotes extra a seguir serão instalados:
tcllib
Os NOVOS pacotes a seguir serão instalados:
pd-extended tcllib
0 pacotes atualizados, 2 pacotes novos instalados, 0 a serem removidos e 12 não atualizados.
É preciso baixar 26,9MB de arquivos.
Depois desta operação, 16,9MB adicionais de espaço em disco serão usados.
Você quer continuar [S/n]? S
AVISO: Os pacotes a seguir não podem ser autenticados!
pd-extended
Instalar estes pacotes sem verificação [s/N]? s

Em instantes seu Pd estará turbinado!! Se ele estiver aberto durante a instalação, convém que seja reiniciado. Salve seus trabalhos, feche e abra de novo o Pure Data. Bom proveito!!

sábado, 22 de janeiro de 2011

Configurando o Apache para Ler Páginas Pessoais dos Usuários

Esta dica é bem simples: se você usa o Apache 2 e quer permitir que cada usuário do sistema tenha sua página pessoal, residindo dentro de sua própria pasta, onde a página possa ser criada, modificada e atualizada pelo próprio usuário, sem interferência do administrador do sistema, então a solução que você procura está neste artigo!!


  • Criando as Pastas Pessoais dos Usuários

Em cada diretório de usuário (o famoso /home/usuario), você deve criar uma pasta chamada "public_html", que deve ter permissão de acesso e escrita para o próprio usuário; Assim, suponhamos que temos um usuário genérico chamado "usuario". Façamos, como root:

mkdir /home/usuario/public_html
chown usuario /home/usuario/public_html
chgrp usuario /home/usuario/public_html

Estes comandos não só criam a pasta pública onde será armazenada a página pessoal do usuário como também concede ao usuário em questão as permissões de acesso à mesma. É preciso fazer isto para cada usuário!! Claro que fica mais fácil se estes comandos estiverem dentro de um script. Se você quer saber como descobrir todos os usuários do sistema para criar este script, consulte nosso outro artigo aqui!!


  • Configurando o Apache 2 Para Ler o public_html dos Usuários

Este passo é simples: basta ativar o módulo correto!! Verifique se o módulo userdir existe (se você instalou o Apache por um gerenciador de pacotes, certamente ele existirá):

ls /etc/apache2/mods-available/userdir*
/etc/apache2/mods-available/userdir.conf /etc/apache2/mods-available/userdir.load

É preciso que apareçam estes dois arquivos. Agora, verifique se eles estão ativados:

ls /etc/apache2/mods-enabled/userdir*

Caso não haja saída para o comando acima, então precisamos habilitá-los:

cd /etc/apache2/mods-enabled
ln -s ../mods-available/userdir.conf
ln -s ../mods-available/userdir.load

Isto cria os links simbólicos que vão ativar o módulo. A rigor, basta isto (e, claro, reiniciar o Apache) para que tudo funcione, mas várias configurações extras podem ser feitas, editando o arquivo "userdir.conf". Em especial, verifique se a linha "UserDir public_html" está presente. Esta linha define o nome do diretório que será vasculhado na área do usuário para buscar a sua página pessoal.
É possível também ativar e desativar a leitura da pasta pública de usuários específicos, usando a diretiva UserDir, conforme o exemplo:

UserDir enabled usuario1 usuario2
UserDir disabled usuario3 usuario4

Para mais detalhes sobre como configurar este módulo e as diretivas específicas que ele usa, verifique a página do manual oficial.


  • Habilitando o PHP nas Páginas Pessoais dos Usuários

Como esta configuração é muito flexível, é possível que você queira usar este artifício para permitir que vários usuários se tornem verdadeiros desenvolvedores web. Assim, o Apache permite que o PHP instalado no servidor seja habilitado em páginas pessoais dos usuários. Primeiramente, verifique se o seu PHP está instalado. Caso não esteja, é preciso instalá-lo. Não se preocupe: para tanto, consulte detalhadamente este nosso artigo. Agora, para ativar esta opção, vá em:

vi /etc/apache2/mods-enabled/php5.conf

e comente as seguintes linhas (comentar significa iniciá-las com o caracter "#", conforme já está feito no exemplo abaixo):

# [IfModule mod_userdir.c]
# [Directory /home/*/public_html]
# php_admin_value engine Off
# [/Directory]
# [/IfModule]
#[/IfModule]

OBS: substitua os colchetes por sinais de maior e menor que.


  • Concluindo as Configurações!!

Agora, finalmente, reinicie o Apache:

/etc/init.d/apache2 restart

Pronto, tudo está configurado e as pastas já deverão estar respondendo. O endereço de acesso será: http://[domínio ou host]/~[usuario], onde [usuario] é o nome de cada usuário e [domínio ou host] pode ser o nome da máquina com o domínio ou o seu IP. Opcionalmente, você poderá, conforme a necessidade, atrelar algumas páginas pessoais a VirtualHosts, de forma a criar endereços de acesso diferenciados.
Bom, espero que tenha ajudado!! Qualquer coisa, COMENTEM!!

sexta-feira, 21 de janeiro de 2011

Instalando o Suporte a PHP5 no Apache2 (Ubuntu, Debian, etc.)

O PHP é uma linguagem bastante popular de programação para páginas dinâmicas na web. Vários sistemas importantes utilizam esta linguagem, como o MediaWiki e o WordPress. Este artigo é bem breve e ensina como instalá-lo no Apache Web Server 2.
Como vocês sabem, o Apache é um servidor web muito flexível, baseado em módulos. Inicialmente, ele não tem suporte a PHP, mas você pode instalar gratuitamente o módulo de PHP (e o suporte à linguagem), de forma que ele passe a entender e executar o PHP. Assim, após instalado o Apache 2, é preciso que se instale, como root, os seguintes pacotes:

apt-get install php5 libapache2-mod-php5

O pacote php5 contém a linguagem em si e o interpretador para executar seus comandos. O pacote libapache2-mod-php5 contém o módulo do Apache que é capaz de ligar o código escrito em PHP de cada página web de seu servidor ao interpretador de PHP instalado pelo primeiro pacote, de forma a executar com sucesso o referido código.
Após esta instalação, se o servidor Apache não for reiniciado automaticamente (o que muito provavelmente deve acontecer, devido aos scripts do apt-get), você deverá reiniciá-lo, de sorte a carregar o novo módulo. Para tanto, ainda como root, digite:

/etc/init.d/apache2 restart

Simples, rápido e indolor!! Se você não usa uma distro Linux baseada em Debian, você poderá achar estes mesmos pacotes (ou outros com nomes muito similares) no seu gerenciador de pacotes padrão e poderá instalá-los sem medo.
Não tenha medo se seu servidor tem páginas antigas escritas para PHP4. Instalar o PHP5 em geral não afeta nem prejudica as páginas escritas para PHP4 ou anterior. Claro que vale sempre a pena fazer backup e testes, mas em muitas ocasiões tudo funcionará corretamente.
Se você é teimoso e quer conferir se o módulo foi carregado corretamente após esta operação toda, digite:

ls /etc/apache2/mods-enabled/php5*
/etc/apache2/mods-enabled/php5.conf /etc/apache2/mods-enabled/php5.load

Estes dois arquivos devem aparecer como saída para o comando ls, indicando que o módulo está instalado e ativo.

sexta-feira, 14 de janeiro de 2011

Como Implementar uma Lista Circular em Java

Uma lista circular é uma lista ordenada (encadeada) onde o item após o último é o primeiro, e o item anterior ao primeiro é o último. É um caso curioso de algoritmos que, não menos curiosamente, reflete uma infinidade de situações reais. Exemplos:

  1. O itinerário de um ônibus circular. Ao chegar ao último ponto, o ônibus não pára nem volta pelo caminho contrário, mas sim continua em frente e alcança o primeiro ponto, de onde partiu inicialmente, perfazendo todo o caminho de novo.
  2. Os dias da semana ou os meses do ano. Após o último, vem sempre o primeiro de novo, reiniciando um novo ciclo.
  3. A roleta de um jogo. Percorrida seqüencialmente, após completar um círculo completo a roleta volta à primeira posição.

Listas circulares são associadas a qualquer situação onde haja um ciclo característico. E periodizar ou repetir as coisas é uma característica extremamente humana ("Tenho fases, como a lua", lembrando o "Lua Adversa", de Cecília Meireles ou, quem sabe, de outras poetisas...).
Listas circulares têm grande aplicação em jogos, manipulação de imagens, manipulação de streams e arquivos, vários sistemas humanos, além de milhares de outras ocasiões.
A classe abaixo implementa a criação de uma lista circular em Java a partir de um ArrayList. Não é uma classe Thread-safe, assim como o ArrayList também não o é, mas é um exemplo razoavelmente completo, testado e seguro que você poderá utilizar livremente em muitas situações. Se você utilizar esta classe em seus programas e sistemas, por favor, faça as referências do seu autor, data, etc, conforme mostrado no javadoc. Considere-a lançada sob licença LGPL.


FONTE: http://pastebin.com/NSw67CbW

Note que esta classe se comporta exatamente como um ArrayList, podendo inclusive ser construída a partir de qualquer Collection. No entanto, existem 3 métodos de navegação que implementam o comportamento circular da lista:

getActual(): retorna o objeto atual. Existe um índice interno que controla a navegação. Assim, você poderá navegar passo a passo pela lista, indo tanto na direção progressiva (para frente) quanto na direção regressiva (para trás). Cada vez que a lista é percorrida, este índice interno é alterado. Se precisar pegar o objeto que corresponde exatamente à posição onde o índice está parado no momento, este método faz isto por você!

next(): retorna o próximo objeto, caminhando com o índice para frente e posicionando-o sobre este objeto retornado. Como é uma lista circular, se você está no último item da lista e dá um "next()", então você receberá o primeiro item da lista, mantendo a característica cíclica da mesma.

previous(): faz o mesmo que o next(), mas em direção oposta: retorna o objeto anterior, caminhando com o índice para trás e posicionando-o sobre este objeto retornado. Como é uma lista circular, se você está no primeiro item da lista e dá um "previous()", então você receberá o último item da lista, mantendo a característica cíclica da mesma.

Além destes métodos, o método get(int index), que já existe na superclasse, foi sobrescrito de forma que nunca lance ArrayIndexOutOfBoundsException, ou seja, qualquer índice que seja passado vai sempre retornar um elemento dentro da lista, calculado circularmente de acordo com o total de elementos da lista. Assim, é seguro usar uma lista como esta dentro de um laço arbitrário, onde o índice do laço é bem maior que a lista. Como exemplo, imagine que você quer desenhar um quadro de tamanho 100x100 com apenas 3 cores que se repetem. Você poderia muito bem fazer:

// Lista circular com 3 elementos apenas!!
CircularArrayList circularList = new CircularArrayList(colors);

for (int i=0; i<100;>

Bom, esta classe ainda pode ser mais aprimorada, se for de seu interesse. Possíveis melhorias seriam:

  • Métodos como "moveTo(int newIndex)" e "moveTo(E element)", que reposiciona o índice em uma posição arbitrária. É útil se a navegação tender a se tornar mais alternada que seqüencial, especialmente se a lista for grande.
  • Métodos "first()" e "last()", se houver necessidade.
  • Uma versão desta classe completamente Thread-safe e otimizada para bom desempenho!! Isto seria de fato uma grande contribuição!!

Espero ter ajudado com este artigo!! Qualquer coisa, COMENTEM!!!

domingo, 9 de janeiro de 2011

Configurando o WebDAV com SSL no Apache

Este é o artigo final da série sobre WebDAV e Apache, portanto assumimos que todos os passos dos artigos anteriores foram realizados com sucesso. Você poderá encontrá-los seguindo os links:

1- Como Acessar o SVN via HTTP (acesso via porta 80, sem SSL);
2- Criando Certificados SSL com OpenSSL (como criar seu certificado. Caso já o tenha, pode pular este artigo);
3- Configurando o Apache com SSL (como fazer seu Apache usar um certificado digital).

Seguindo estes passos, você deverá ter, em seu arquivo de configuração do Apache (geralmente /etc/apache2/apache2.conf), ao menos um contêiner [Location], onde estará configurado o seu repositório SVN. Claro que você pode ter mais de um [Location], caso seu Apache precise servir vários repositórios ao mesmo tempo. Você também deve ter criado seu arquivos de senhas HTTP, onde a autenticação do usuário será feita.
Você notará que, mesmo com autenticação do usuário (no modo basic authentication, usando a diretiva AuthType Basic), ainda há risco de segurança, pois a senha e os dados não são encriptados, de forma que a senha é enviada em texto puro (plain text) e pode, com certa habilidade, ser capturada por pessoas mal-intencionadas. O outro modo de autenticação (digest), onde a senha é passada como uma soma MD5, ainda tem algumas falhas em seus processos. Sendo assim, a segurança somente estará garantida se seu acesso ao repositório for feito integralmente em conexão segura, via SSL.
Este artigo ensina rapidamente como configurar o SSL que seu Apache já tem (vide artigos anteriores) com o seu repositório SVN.


  • Acessando o WebDAV com Conexão Segura no Apache

Suponhamos então que você tenha um contêiner [Location] como este, no seu /etc/apache2/apache.conf:

[Location /repositorio1]
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor que!!

Este [Location] funciona, mas responde apenas via HTTP, na porta 80. Para ele passar a responder na porta 443, com conexão segura, precisamos de duas coisas (assumindo que as chaves já estão instaladas e configuradas no Apache, conforme mostrado nos artigos anteriores):

1- Proibir o acesso ao contêiner pelo protocolo HTTP (porta 80). Ou seja: forçar o acesso ao WebDAV via SSL. Para tanto, basta acrescentar a linha em negrito:

[Location /repositorio1]
SSLRequireSSL
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Location]

OBS: Substitua os colchetes por sinais de maior e menor que!!

A diretiva SSLRequireSSL impede que o acesso a este [Location] seja feita por qualquer outro meio que não via SSL. Existem outras diretivas que podem controlar este acesso, como a SSLVerifyDepth 1, que indica a profundidade (níveis de sub-diretórios) em que o acesso forçado em SSL deve ser aplicado. Evidentemente, informar o número zero "0" irá sugerir toda a árvore de diretórios. Para o nosso caso, esta diretiva não é necessária, pois, sem ela, o SSL já é forçado em todo o repositório, que é o que queremos.
Agora seu repositório está inacessível: não responde mais na porta 80 (o Apache vai informar a mensagem "Forbidden", ou seja, acesso negado), mas ainda não responde na porta 443. Para completar a operação, execute o passo 2, abaixo.

2- Criar um VirtualHost para o acesso seguro via SSL.
Um VirtualHost é um super contêiner do Apache que faz diversas coisas: mapeamento de URLs, redirecionamentos, escolha de portas, criação de regras de acesso, configuração de Aliases, dentre outras coisas, e suporta praticamente qualquer contêiner e diretiva dentro dele. Exatamente por isto precisamos criar um VirtualHost para o acesso à porta 443, conforme mostramos no exemplo:

[VirtualHost 127.0.0.1:443]
Servername localhost
DocumentRoot /var/www
[IfModule mod_ssl.c]
SSLEngine on
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
[/IfModule]
[/VirtualHost]

OBS1: Substitua os colchetes por sinais de maior e menor que!!
OBS2: Substitua o IP 127.0.0.1, que é usado apenas como exemplo, pelo IP de seu servidor!!

O que isto faz?? Bom, vamos aos detalhes:

VirtualHost IP:443 - Significa que você está criando o conjunto de regras específicas para o uso da porta 443, que é a porta configurada para conexão segura por SSL, o chamado protocolo HTTPS.
Servername localhost - É o nome do servidor. Troque o termo "localhost" por um nome válido. Este é usado apenas como exemplo.
DocumentRoot /var/www - É claro que este não é o endereço de seu repositório, mas é um local que vai ser utilizado caso alguém tente ler a URL raíz de seu servidor, por exemplo: https://localhost. Se você informar o endereço físico (diretório no sistema de arquivos) de um de seus repositórios aqui, estará criando uma brecha de segurança para um possível invasor. O local que o DocumentRoot informar não impede que um ou mais [Location] sejam contemplados pelo VirtualHost protegido.
SSLEngine on e demais diretivas do módulo SSL (mod_ssl.c) - responsáveis por ativar efetivamente o SSL nesta porta informada. Por aqui, você nota que é possível, no Apache, servir o SSL em ainda outra porta, diferente da 443. Não sei por que você desejaria isto mas, caso deseje, tenha a certeza de adicionar a diretiva "Listen" com o número da porta desejada. Exemplo: "Listen 400", para a porta 400. Isto não é informado no VirtualHost, mas sim no ports.conf, ou, opcionalmente, no apache2.conf, httpd.conf ou no mods-available/ssl.conf.

Existem outras coisas que você pode pendurar no VirtualHost, como os contêineres [Directory], que poderão ser utilizados especialmente para outros portais e sites que você serve com seu Apache. O fato de existir um contêiner para a porta 443 não impede que exista outro para a porta 80. Desta forma, seu Apache pode servir tanto conexões seguras (SSL/HTTPS) quanto conexões abertas (HTTP na porta 80). Basta configurar direitinho os VirtualHost. Como este artigo é apenas sobre o WebDAV e não um curso de Apache, recomendo que, se este é o seu caso, procure a documentação do Apache para maiores detalhes. Um exemplo mais sofisticado de configuração do VirtualHost pode ser encontrado aqui.


  • Configurando o WebDAV com SSL sem usar Location (Somente o VirtualHost)

Esta não é, inicialmente, a minha recomendação, porém provavelmente será mais útil a quem tem apenas um repositório para servir com o Apache e quer configurar o Apache como um servidor dedicado. Um servidor dedicado é aquele que serve a apenas um portal ou serviço, normalmente um que sofra com muitos acessos e grande carga, de sorte a justificar um servidor só para ele. Pode ser o caso de sua empresa, por exemplo, se todos os projetos estão centrados em um único repositório SVN acessado a partir de um único servidor Apache, vindo a sofrer grande volume de acessos.
Bom, neste caso, você pode fazer a configuração toda diretamente no VirtualHost, eliminando o contêiner [Location]. Isto vai ajudá-lo a configurar o repositório diretamente na URL raíz, ou seja, no caminho virtual "/" de seu servidor. Vide o exemplo abaixo:

[VirtualHost 127.0.0.1:443]
Servername localhost
DocumentRoot /var/www
[IfModule mod_ssl.c]
SSLEngine on
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
[/IfModule]
[Directory /opt/svn/repositorio1]
DAV svn
SVNPath /opt/svn/repositorio1
AuthType Basic
AuthName "repo1"
AuthUserFile /opt/svn/passwd
[Limit PUT POST DELETE PROPFIND PROPPATCH MKCOL COPY MOVE LOCK UNLOCK]
Require valid-user
[/Limit]
[LimitExcept GET]
Require valid-user
[/LimitExcept]
[/Directory]
[/VirtualHost]

OBS: Substitua os colchetes por sinais de maior e menor que!!

Note que este exemplo é bem semelhante ao primeiro. A diferença é que ele migra praticamente todas as informações que colocamos no contêiner [Location] (referentes à configuração do WebDAV), que ficava diretamente no /etc/apache2/apache.conf, para dentro de um contêiner [Directory]. Este, por sua vez, é disposto dentro do contêiner VirtualHost, em /etc/apache2/apache.conf. Isto provoca que as informações do [Directory] digam respeito ao endereço raíz e poderão ser acessadas pela URL https://localhost/.
Conforme mencionado, é o caso ideal para quem mantém apenas um repositório e tem um Apache exclusivo para o mesmo, embora outros VirtualHost (e contêineres [Directory]) possam ainda ser criados e configurados neste mesmo Apache.


  • Conclusões

Foram apresentadas duas técnicas para a configuração do WebDAV no Apache usando SSL: uma mais própria para configurar um único repositório e outra mais apropriada para múltiplos repositórios do SVN. A sua escolha da técnica, bom como qualquer refinamento a ser incluído, deve levar em conta o uso de seu repositório, a carga que ele recebe e a quantidade de repositórios gerenciados pelo Apache. O uso do WebDAV, mesmo via SSL, não exclui que o Apache sirva outras páginas e sistemas.
Espero que este conjunto de tutoriais tenha sido útil!! Lembre-se de que, sempre que possível, é fundamental que você COMENTE!!!

sexta-feira, 7 de janeiro de 2011

Configurando o Apache com SSL (Certificação Digital)

Este artigo é a continuação do artigo anterior: Criando Certificados SSL com OpenSSL. Aqui vamos aprender a usar o CA (certificate authority - autoridade certificadora) criado anteriormente para criar chaves assinadas digitalmente e implantá-las no Apache Web Server. A criação e assinatura das chaves é um processo que pode ser usado Ipsi literis para qualquer serviço ou aplicativo que necessite de chaves assinadas, diferindo apenas o processo de implantação das mesmas. Como exemplo, vamos implantá-la no Apache Web Server, de forma a que ele venha a suportar conexões seguras (protocolo HTTPS). As conexões seguras do Apache normalmente são servidas na porta 443 (e não na porta 80) e, para que funcionem, dependem de configuração extra: cada pasta virtual interessada em servir via conexão segura deve criar uma entidade VirtualHost para tanto. Este artigo não cobre a criação do VirtualHost (que será tema do próximo artigo, o terceiro desta série), mas somente a implantação e configuração do Apache de sorte a torná-lo apto e pronto para servir páginas via SSL, quando desejado.


  • Criando uma Chave e um Requerimento (Certificate Request)

Antes de tudo, entre como root. Em seguida, volte ao nosso diretório especial que criamos para guardar os arquivos do OpenSSL (se você seguiu nosso primeiro artigo, possivelmente nomeou este diretório de "/var/ssl"):

cd /var/ssl

Agora, vamos utilizar o certificado já criado anteriormente para criar uma chave e um signing request:

openssl req -new -nodes -out name-req.pem -keyout private/name-key.pem -config ./openssl.cnf

O que isto faz??
req -new: significa que vai criar um request novo.
-out name-req.pem: o nome da sua chave pública. Pode ser o nome do host, ou algo assim. Escolha o nome de sua preferência, mas evite usar o termo "key", para não confundir com o arquivo de chave privada.
-keyout private/name-key.pem: o nome de sua chave privada. Pode ser qualquer nome, mas sugiro que você utilize o mesmo nome do arquivo anterior, adicionando o termo "key". Note que este arquivo vai para a pasta private e deve estar protegido, ou seja, inacessível a terceiros, por motivos de segurança.
-config ./openssl.cnf: o mesmo arquivo de configuração do OpenSSL utilizado para criar o seu certificado (realizado no artigo anterior, conforme mencionado no caput deste artigo).

O OpenSSL vai fazer aquelas mesmas perguntas anteriores, a respeito de sua localidade (país, estado, cidade) e do nome da sua organização. Responda às perguntas (ou uso os valores padrões) exatamente conforme foi feito na criação de seu certificado, executado no artigo anterior.
Após esta operação, surgirão dois novos arquivos em ser diretório: name-req.pem (contendo o certificate request) e, dentro do diretório private, name-key.pem (private key - chave privada).


  • Assinando o Certificate Request

Agora vamos propriamente assinar este requerimento do certificado. Isto servirá para garantir que o usuário conectado ao seu servidor por conexão segura realmente recebeu a chave dele através de seu servidor, e não uma chave adulterada por terceiros. Esta verificação é obrigatória para o protocolo SSL, por isso precisa ser feita.
Bom, trocando em miúdos, basta digitar:

openssl ca -out name-cert.pem -config ./openssl.cnf -infiles name-req.pem

O que isso significa??
ca: vamos assinar o request e criar um certificado assinado.
-out name-cert.pem: o nome do novo certificado, agora devidamente assinado.
-config ./openssl.cnf: naturalmente, o mesmo arquivo de configuração utilizado desde o início.
-infiles name-req.pem: o arquivo de request original, gerado no passo anterior, que ainda não está assinado mas já contém a chave em si.

Lembra-se de que, quando geramos, lá no artigo anterior, o seu certificate authority, você foi obrigado a dar uma senha?? Pois é: este é o momento de usá-la. A primeira coisa que o comando faz é pedir aquela mesma senha, que deve ser digitada exatamente conforme o foi na criação do seu CA, no artigo anterior.
Em seguida, o comando exibe todas as informações particulares de seu servidor informadas na criação da chave e faz duas perguntas:

Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

Digite "y" para a primeira pergunta, para que o certificado seja assinado. Isto vai gerar o arquivo name-cert.pem no diretório. Este arquivo nada mais é do que o mesmo request anterior, tendo adicionado um bloco contendo a assinatura, ou seja, os dados informados do servidor e o cálculo MD5SUM destes dados encriptados em RSA com a senha que você digitou. Nunca ninguém no mundo vai ser capaz de abrir esse cálculo RSA e ler o MD5SUM se não possuir a sua bendita senha. Quebrar essa senha certamente dará muito trabalho. Por isso o certificado está assinado e é seguro.
Responda "y" para a segunda pergunta. Isto irá criar uma cópia exata do arquivo no diretório "certs", o seu banco de dados de certificados, porém utilizando o nome dado no arquivo "serial", que criamos no artigo anterior (você achou que ele não serviria para nada, mas aí está a função dele!!). Automaticamente, este arquivo "serial" é sobrescrito com o valor numérico seqüencial imediatamento posterior (antes era 100001, agora é 100002).


  • Vamos Conferir Tudo??

Esta seção foi escrita para quem duvida do que eu digo... não precisa ser realizada, mas vai te ajudar a conferir e entender o que foi feito até o momento.


1- Testando se o seu certificado é igual ao que está no banco de certificados:

diff name-cert.pem certs/100001.pem

Se o comando não mostrou saída de texto, os dois arquivos existem, têm estes nomes e são iguais.


2- Verificando se o arquivo de índice está com o valor imediatamente posterior:

cat serial
100002

De fato, está pronto para o próximo certificado, que será armazenado no banco (pasta certs) com o nome "100002.pem". Se você configurou o atual certificado com data de expiração de 1 ano (365 dias), este certificado novinho provavelmente será gerado no ano que vem...


3- Verificando se as chaves privadas estão geradas:

ls private/
cakey.pem name-key.pem

Sim, ambas as chaves que fazem parte do processo estão lá corretamente.


  • Removendo a Senha da Chave Privada

Alguns serviços tendem a usar a chave privada pedindo a senha a cada vez que se inicializam. Normalmente, desejamos que o serviço inicie com o boot automaticamente e sem pedir nenhuma informação. Para tanto, podemos retirar a senha da chave privada, que não precisa mais dela, pois já estamos com todas as chaves e certificados gerados e prontos. Para tanto, utilize o comando:

openssl rsa -in private/name-key.pem -out private/name-key-nopassword.pem
writing RSA key

Isto vai gerar o arquivo "name-key-nopassword.pem" dentro do diretório private, semelhante ao primeiro, mas sem a senha embutida.


  • Configurando o Apache para Usar o SSL

Agora, finalmente terminamos todas as gerações de chaves, requests e certificados. Precisamos apenas ensinar o Apache a usar essa tecnologia. Então vamos por partes...


1- Ativando o Módulo SSL do Apache

Vamos verificar se seu Apache (que, suponho, já está instalado) está com o módulo de SSL instalado (provavelmente sim) e ativado (talvez não...):

ls /etc/apache2/mods-available/ssl*
/etc/apache2/mods-available/ssl.conf /etc/apache2/mods-available/ssl.load

(substitua "/etc/apache2" pelo local de configuração do seu Apache. Em algumas distribuições, pode ser "/etc/httpd").
Se a listagem acima mostrou os dois arquivos "ssl.conf" e "ssl.load", então o módulo está instalado. Vamos saber se ele está ativado:

ls /etc/apache2/mods-enabled/ssl*
ls: cannot access /etc/apache2/mods-enabled/ssl*: No such file or directory

Se a listagem não retornou os mesmos dois arquivos, conforme o caso aí em cima, então o módulo não está ativo. Para ativá-lo, basta criar, no diretório mods-enabled, um link simbólico para cada arquivo ssl.* presente no mods-available:

ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/ssl.conf
ln -s /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/ssl.load

Agora os módulos estão configurados. Mas, calma, não reinicie o Apache ainda... precisamos configurar o módulo e instruí-lo sobre onde estão as chaves que criamos...


2- Importando as Chaves para o Apache

Vamos criar um diretório dentro das configurações do Apache para armazenar as chaves que desejamos utilizar e, em seguida, copiá-las para lá:

mkdir /etc/apache2/ssl
cp private/name-key-nopassword.pem /etc/apache2/ssl/
cp name-cert.pem /etc/apache2/ssl/


3- Configurando o Módulo SSL do Apache

Agora falta pouco!! Vamos editar o arquivo de configuração do módulo SSL do Apache e dizer para ele onde estão as chaves que acabamos de copiar aí em cima:

vi /etc/apache2/mods-available/ssl.conf

Acrescente, possivelmente ao final do arquivo (porém antes de fechar a tal "IfModule"), as seguintes linhas:

# Including certificate authority
SSLCertificateFile /etc/apache2/ssl/name-cert.pem
SSLCertificateKeyFile /etc/apache2/ssl/name-key-nopassword.pem

Vamos ver se o Apache entendeu bem a configuração e achou os arquivos?? Vamos reiniciá-lo e observar o log de erros:

/etc/init.d/apache2 stop
/etc/init.d/apache2 start
less /var/log/apache2/error.log

Agora o seu Apache já está pronto para utilizar SSL. O que falta é apenas configurar quais portais servidos por ele serão tunelados por conexão segura, ou seja, serão servidos via protocolo HTTPS, pela porta 443, e não mais pela porta 80, que é a padrão. Isto é feito na tag VirtualHost. No próximo artigo trataremos deste pormenor... até lá!!

Quem quiser, claro: comente!!

quinta-feira, 6 de janeiro de 2011

Criando Certificados SSL com OpenSSL

Certificados digitais são utilizados vastamente em diversos serviços de rede, como contêineres HTTP (exemplo: Apache Web Server), servidores de e-mail (Exim4 ou Sendmail), servidores de nomes e diretórios (LDAP), e até para assinar arquivos e documentos digitalmente, como o faz o AutoCAD. Este tutorial mostra, passo a passo, como criar um certificado digital, utilizando a ferramenta OpenSSL. O certificado criado poderá ser importado e utilizado em qualquer aplicativo ou serviço que suporte conexão segura ou assinatura digital.
Para executar as instruções deste tutorial, você deve ter o openssl previamente instalado em sua máquina (possivelmente sua distro Linux já vem com ele) e deve ter acesso de root, pois todos os comandos deverão ser executados como root, desde o início.
Este tutorial inspira-se num tutorial bem detalhado que pode ser encontrado aqui.


  • Criando um Diretório para o SSL

Como o procedimento que iremos realizar gera vários arquivos e diretórios, alguns deles sensíveis e cujo acesso deve ser restrito ao root, então convém que se crie no sistema um diretório para se armazenar estas informações. Pode estar em qualquer lugar e possuir qualquer nome, vou sugerir /var/ssl. Após criar o diretório, restrinja todo o acesso de leitura, escrita e execução dele apenas ao root, por motivos de segurança:

mkdir /var/ssl
chmod 700 /var/ssl

Confira a operação:

ls -l /var/

# deve conter uma linha semelhante a esta:
drwx------ 2 root root 4096 2011-01-06 15:41 ssl

Agora acesse o diretório. Todas as demais operações ocorrerão de dentro dele:

cd /var/ssl/


  • Criando Subdiretórios e Banco de Dados dos Certificados

Uma vez dentro do diretório, vamos criar dois subdiretórios, utilizados para armazenar os certificados e as chaves privadas:

mkdir certs private

Agora vamos criar dois pequenos arquivos textos, um contendo um número seqüencial (utilizado para numerar os certificados na seqüência em que sejam criados) e outro vazio, utilizado para indexar o certificado atual:

echo '100001' > serial
touch certindex.txt


  • Criando um Arquivo de Configuração do OpenSSL Personalizado

O OpenSSL utiliza um arquivo de configuração em modo texto que pode ter qualquer nome. Já existe um arquivo pronto que fica em "/etc/ssl/openssl.cnf". Você pode modificá-lo e utilizá-lo, se desejar. Por questões de padronização, eu sugiro que você crie o seu próprio arquivo de configuração, incluindo nele os dados particulares de sua empresa ou instituição que deverão aparecer no certificado.
Um exemplo deste arquivo está a seguir. A minha sugestão é que você o salve como openssl.cnf.sample. Basta digitar "vi openssl.cnf.sample", apertar "i" (de "incluir") e colar o seguinte conteúdo:

-----------------------------------------------------
#
# OpenSSL configuration file.
#

# Establish working directory.

dir = .

[ ca ]
default_ca = CA_default

[ CA_default ]
serial = $dir/serial
database = $dir/certindex.txt
new_certs_dir = $dir/certs
certificate = $dir/cacert.pem
private_key = $dir/private/cakey.pem
default_days = 365
default_md = md5
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match

[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional

[ req ]
default_bits = 1024 # Size of keys
default_keyfile = key.pem # name of generated keys
default_md = md5 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
req_extensions = v3_req

[ req_distinguished_name ]
# Variable name Prompt string
#------------------------- ----------------------------------
0.organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name (city, district)
stateOrProvinceName = State or Province Name (full name)
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64

# Default values for the above, for consistency and less typing.
# Variable name Value
#------------------------ ------------------------------
0.organizationName_default = My Company
localityName_default = My Town
stateOrProvinceName_default = State or Providence
countryName_default = US

[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always

[ v3_req ]
basicConstraints = CA:FALSE
subjectKeyIdentifier = hash

-----------------------------------------------------

Agora, você já tem um modelo do arquivo de configuração do OpenSSL. Não vamos mexer no modelo, sob pena de perder as informações e dicas contidas nos comentários. Vamos então criar o nosso arquivo personalizado a partir do modelo, e este se chamará simplesmente openssl.cnf:

cp openssl.cnf.sample openssl.cnf


Edite este arquivo e substitua as informações da seção "[ req_distinguished_name ]" por informações em conformidade com as informações que você deseja mostrar no certificado. Lembre-se: evite usar acentos, símbolos, barras, sinais, ou qualquer outro caracter especial fora os símbolos alfanuméricos padrões, pois isto pode criar problemas na codificação da chave!!


  • Criando o Certificado Principal

Antes de criar chaves, você deve criar um certificado principal (root certificate), baseado nas configurações informadas no arquivo de configurações. Todo o resto do trabalho daqui por diante será baseado neste certificado. Assim, para criar este certificado, digite o comando abaixo (sempre de dentro da pasta principal que criamos, e sempre como root!):

openssl req -new -x509 -extensions v3_ca -keyout private/cakey.pem -out cacert.pem -days 365 -config ./openssl.cnf

O que significa tudo isso??
-new: indica que se criará um novo Certificate Authority (autoridade certificadora);
-days 365: a quantidade de dias em que este certificado será válido. Algumas pessoas gostam de deixar o certificado principal válido por 10 anos. Neste caso, informe "3650";
-keyout private/cakey.pem: o local e nome do arquivo de chave que será criado;
-out cacert.pem: o arquivo de certificado que será criado;
-config ./openssl.cnf: o arquivo de configuração que será utilizado como base para a criação deste certificado.

Depois que você der ENTER, o OpenSSL vai pedir alguns dados importantes, iniciando por uma senha (pass phrase). Não perca esta senha!! Ela vai ser necessária mais pra frente!! As outras informações são as mesmas do arquivo de configuração que você já deve ter alterado, ou seja:

- Nome da Organização (ou companhia, empresa, instituto ou órgão);
- Unidade da Organização (ou departamento ou seção);
- Cidade;
- Estado (ou província ou região);
- País (na verdade, apenas as duas letras do código do país. Ex: BR para Brasil);
- O chamado Common Name, geralmente o nome de servidor (hostname) ou IP do mesmo.


  • Instalando o Certificado

Apenas com o exposto você já tem o suficiente para usar o certificado. Foram gerados dois arquivos, a saber:

cacert.pem: é o seu certificado público. Pode ser renomeado e distribuído para outras pessoas ou máquinas, ou mesmo via rede. Pode ser baixado e instalado em navegadores ou clientes de e-mail.
private/cakey.pem: é um arquivo privado e não deve ser distribuído. Ao contrário, deve ficar bem guardado e seguro!! Também pode ser renomeado, no entanto. Este arquivo deve ser utilizado internamente para criar as assinaturas digitais, necessárias para acessos seguros via SSL.


  • Próximos Passos

No artigo seguinte (Configurando o Apache com SSL), vamos aprender a criar duas chaves a partir deste certificado, uma pública e outra privada, assiná-las digitalmente e adicioná-las ao Apache Web Server... continue com a gente!!

segunda-feira, 3 de janeiro de 2011

Ignorando Arquivos com o SVN (ou: Onde Coloco o meu .cvsignore no SVN??)

Quem migrou do CVS para o SVN, especialmente aqueles que converteram seus repositórios com as ferramentas existentes e continuaram seus projetos com o novo versionador, talvez tenha notado que, no SVN (ou Subversion), o antigo arquivo ".cvsignore" não produz nenhum efeito... este presente artigo ensina como fazer o SVN aprender a ignorar alguns arquivos que não devem ser versionados e as diferenças entre o SVN e o CVS consoante a este assunto.


  • Ignorando Arquivos com o CVS

É famoso e fácil esse truque de ignorar arquivos com o CVS. Basta se criar um arquivo chamado ".cvsignore" na pasta onde os arquivos a serem ignorados ficarão (apenas na pasta, não nas sub-pastas!!). Este deverá ser um arquivo texto, contendo, a cada linha, o nome de um arquivo a ser ignorado (você pode usar caracteres como "*", para designar grupos de arquivos com nomes semelhantes).
Isto faz o cliente (e não o servidor!) do CVS deixar de observar os arquivos listados, mas você, um cara esperto, pode subir o arquivo ".cvsignore" e forçar que todos da sua equipe façam o update do mesmo, de forma que aqueles tais arquivos a serem ignorados serão sempre ignorados em todas as máquinas dos membros de sua equipe e nunca serão enviados para versionamento.
Um exemplo de arquivo .cvsignore é:

cat .cvsignore
*jar
*sh
*bat
*bak
*~

Desvantagens do uso desta técnica são:

1- Você depende de um arquivo local que diga o que ignorar, então o servidor não tem controle sobre isto;
2- Pode ser que dois desenvolvedores com arquivos ".cvsignore" diferentes (ou um desenvolvedor sem o tal arquivo) acabem fazendo filtragens diferentes, o que pode culminar no envio indesejado de um arquivo para o versionamento.


  • Ignorando Arquivos com o SVN

Por motivos como o exposto acima, o SVN não utiliza esta técnica (então, não há arquivos ".cvsignore" nem nenhum tipo de ".svnignore"!! Não tente criar este arquivo apenas por força da analogia, pois não funcionará!!).
Para o Subversion, o controle sobre os arquivos a serem ignorados deve estar o tempo todo no servidor, e é adicionado através de uma propriedade de uma pasta. Esta propriedade é criada na pasta específica onde os arquivos serão ignorados e, após a sua criação, a pasta é considerada alterada e necessitará de um commit para efetivação da propriedade no servidor.
Após esta efetivação, os outros membros de sua equipe deverão ver, em seus clientes do SVN, que a pasta foi modificada (porém sem qualquer menção aos arquivos internos desta pasta) e, ao baixarem a nova versão da pasta, automaticamente terão marcada a propriedade responsável por ignorar os arquivos indesejados.
Esta operação gera um número de revisão.


  • Como Definir a Propriedade Que Ignora Arquivos no SVN??

A referida propriedade chama-se svn:ignore e pode ser adicionada de várias maneiras, dependendo de seu cliente de SVN, estando sempre relacionada à pasta cujo conteúdo será filtrado (e não a uma pasta raíz... o conteúdo é filtrado na pasta onde a propriedade é definida, e não nas sub-pastas!!). Assim, se você utiliza o terminal, basta digitar, por exemplo:

svn propset svn:ignore .~* articles/

Isto instrui ao SVN que defina a propriedade (propset) chamada svn:ignore com o valor ".~*" para o diretório articles/. Este modelo, por exemplo, força que um diretório chamado articles, supostamente de documentos do Open Office, ignore todos os arquivos temporários do Open Office, que normalmente têm o nome criado a partir da fórmula ".~[nome do arquivo original]#". Agora, faça o commit, para subir ao servidor esta alteração!!
Se você utiliza um cliente gráfico, como o plugin Subclipse para o Eclipse (do qual falamos detalhadamente neste artigo), basta clicar na pasta desejada com o botão direito e escolher a opção Team, sub-opção "Set Property...", conforme mostrado na Figura 01, abaixo (clique para ampliar a figura!!):


Figura 01: Selecionando a opção para criar a propriedade.

Na janela que surgir, escolha a propriedade svn:ignore e digite, na caixa de texto abaixo, todos os tipos de arquivos que devem ser ignorados, podendo usar o caracter "*" à vontade!! Vide Figura 02:


Figura 02: Definindo a propriedade svn:ignore.

Agora, a pasta que sofreu a configuração estará marcada como modificada e você deverá efetivar esta modificação, enviando-a para o servidor (faça um commit!!). Automaticamente, todos os membros da sua equipe de trabalho, após atualizarem seus projetos pelo repositório (ou seja, após fazerem um update), terão suas configurações de ignorar arquivos ajustada!!

Vantagens desta abordagem são:

1- Não há dependência de um arquivo local, o que impede o problema clássico de um desenvolvedor criar ou modificar este arquivo, esquecer de subir para o servidor, e a equipe começar a trabalhar com políticas diferentes de seleção de arquivos para versionamento.
2- Gera mais consistência entre a pasta e os arquivos permitidos para ela, dificultado que alguém burle esta regra, pois todos serão de certa forma forçados a fazer previamente o update da pasta se quiserem inserir ou modificar algum arquivo nela.
3- A definição da propriedade gera um número de revisão, com sua respectiva mensagem, documentando e caracterizando o ato.

Bom, pessoal... espero que este tutorial tenha ajudado a vocês!! Boa sorte!! (Ah!, COMENTEM aí embaixo!!!).

Aplicando Comandos a vários Arquivos Recursivamente

Este artigo ensina como tirar proveito de uma famosa dupla: os comando find e xargs. Juntos, eles podem capturar arquivos que se encaixam em determinadas características e aplicar, de uma vez só, um comando específico para todos eles. É muito útil se você quiser apagar ou copiar determinados arquivos que existem em vários níveis diferentes da árvore de diretórios, contar linhas de um código que tem arquivos de fontes em vários diretórios dentro de uma pasta de fontes, além de milhares de outras coisas... Vejamos as possibilidades!!


  • O comando find

O segredo de tudo é o comando find. Basicamente, este comando é capaz de varrer o diretório especificado como parâmetro e todos os seus subdiretórios para achar e listar na tela arquivos que se conformem às características especificadas. Ele suporta duas ordens de parâmetros:

[1]- Configuração da busca (nível de profundidade, se deve ou não seguir links simbólicos, se deve ou não penetrar em outros filesystems montados na árvore pesquisada, se deve ser sensível à caixa ou não, etc...).
[2]- Configuração do filtro: quais as características dos arquivos que devem ser encontrados (nome ou trecho do nome do arquivo, data de modificação do arquivo maior ou menor que alguma data indicada, etc...).

Os parâmetros de [1] são sempre maiúsculos, e os parâmetros de [2] são sempre minúsculos. A documentação de todos os parâmetros pode ser fácil e detalhadamente encontrada na página de manual do comando (ou, opcionalmente, uma versão reduzida pode ser encontrada aqui). Para tanto, basta digitar:

man find

Assim, para não ficar muito teórico, vamos aprender a usar este comando a partir de exemplos, vendo como ele pode ser poderoso...


  • Encontrando Todos os .directory do Dolphin

O Dolphin, que vem por padrão com o KDE 4, é um excelente gerenciado de arquivos e realmente foi um bom substituto para quem subutilizava o Konqueror, no KDE 3, apenas como gerenciador de arquivos e pastas. O (grande?) problema dele e que, de fato, muito me incomoda, é que ele cria em diversos diretórios um arquivo oculto chamado ".directory". São arquivos de texto pequenos, contendo informações como a data do último acesso e o modo de visualização de arquivos. Um exemplo de arquivo ".directory":

cat .directory
[Dolphin]
Timestamp=2010,12,4,13,44,38
ViewMode=1

Se você é paranóico como eu e não gosta de deixar registros de onde você passou, ou simplesmente quer apagar estes arquivos para poupar espaço, vamos então primeiro encontrar a todos com o comando find, e depois apagá-los (quanto a apagá-los, continue conosco no item adiante...):

# Voltando para a pasta padrão do usuário
cd

# Encontrando recursivamente todos os arquivos ".directory"
find . -iname .directory

O que significa isso tudo no comando find?

".": diretório atual, a partir de onde a busca deve começar.
"-iname": indica que o filtro será por nome.
".directory": o nome do arquivo. Aqui podemos utilizar os mesmos caracteres curingas que usamos com todos os demais comandos de navegação e manipulação de arquivos.
O resultado será a listagem na tela do caminho a partir do diretório informado, linha a linha, de todos os arquivos encontrados.


  • Removendo Todos os .directory do Dolphin

Agora vamos finalmente apagá-los!! Para tanto, precisamos utilizar o comando xargs. Este comando simplesmente toma a saída de outro comando (como o find) e aplica seqüencialmente um terceiro comando, passado para ele por parâmetro, a cada linha que receber. O comando que apaga arquivos, como sabemos, é o "rm -f" (o parâmetro "-f" apenas assegura que o apagamento será silencioso, ou seja, o comando não vai te perguntar, item a item, se quer mesmo apagar o arquivo). É claro que o xargs tem várias opções e elas estão detalhadas na sua página de manual (digite "man xargs"). Para nós, o que interessa é que ele recebe como parâmetro o comando que deve ser executado para as benditas linhas do resultado.
Importante: para pegar a saída para a tela que o comando find gera e redirecioná-la para o comando xargs, utilize o caracter pipe ("|").
Assim, o comando mágico ficará:

find . -iname .directory | xargs rm -f

Outra opção, dispensando o comando xargs, é:

rm -f 'find . -iname .directory'

A única restrição é que os diretórios não podem ter nomes com caracteres inválidos (possível em alguns filesystems) ou com espaços, senão o comando rm falhará. Lembre-se de que o xargs passa para o comando que lhe foi informado a linha de resultado exatamente como ele a recebe!!


  • Apagando Todas as Pastas .svn

Cuidado com este comando, ele pode ser drasticamente perigoso, embora, em algumas situações, você possa querer isto mesmo....
Quem utiliza projetos versionados já deve ter notado que o cliente de versionamento adiciona geralmente uma pasta oculta com dados da versão local, dados temporários e, algumas vezes, algum cache de arquivos. Exemplos deste comportamento são o Subversion, que cria a pasta ".svn". Para remover estas pastas, use o comando:

find . -iname .svn | xargs rm -rf

A opção "-r" do comando rm apaga a pasta inteira mesmo que ela não esteja vazia, que certamente é o caso de uma pasta deste tipo acima.


  • Buscando Apenas Diretórios

find . -type d -name .sv*

A opção "-type d" indica que só estamos interessados em diretórios. Existem outros tipos que podem ser informados com o parâmetro "-type", a saber "f", para arquivo, "s", para soquete, "l", para link simbólico, etc.


  • Contando as Linhas de Vários Arquivos Fontes Automaticamente

Este é outro momento de glória do comando find!! Para contar as linhas de um arquivo, utilizamos o comando wc -l. O parâmetro "-l" indica que serão contadas apenas linhas.

find ./src -iname *.java | xargs wc -l

Note que, aqui, mostramos que os caracteres como "*" e "?" podem ser utilizados no comando find. Evidentemente, no comando acima, supomos que os arquivos fontes estão no diretório ./src.


  • Contando Todos os Arquivos de um Diretório

Se você quiser contar rapidamente todos os arquivos de um diretório, saiba que existem várias maneiras de se fazer isso, das quais podemos sugerir, com o comando find, uma maneira bem simples:

find . > arquivos && wc -l arquivos && rm arquivos

Dissecando o comando acima:

"find .": simplesmente lista todos os arquivos, já que nenhum filtro foi especificado.
"> arquivos": copia os resultados para um arquivo chamado "arquivos".
"&&": significa que outro comando deverá ser executado em seguida.
"wc -l arquivos": conta todas as linhas do arquivo "arquivos", ou seja, se a cada linha eu tenho, na verdade, um arquivo encontrado pelo comando find, então esta contagem corresponderá ao total de arquivos encontrados.
"&&": outro comando que deverá ser executado na seqüência...
"rm arquivos": claro, vamos apagar o arquivo "arquivos", já que ele foi criado apenas temporariamente para que o comando "wc -l" pudesse contar as suas linhas.

Assegure-se de ter permissão de escrita no local onde o arquivo será criado, para que o comando funcione!!
Este trecho é interessante porque pode dar margem a várias outras idéias (criando pesquisas específicas com os recursos que já vimos acima), como guardar em arquivos diferentes listagens específicas que poderão ser utilizadas em um script mais complexo, evitando repetir o comando find desnecessariamente.


Bom, pessoal, creio que vimos vários exemplos interessantes e muito úteis sobre como tirar proveito dos comandos find e xargs, uma verdadeira dupla dinâmica, usados em conjunto com os comandos wc, rm, dentre outros. Existem muitas outras situações interessantes derivadas destas e muitas outras novas, que podem ser formuladas de acordo com as suas criatividade e necessidade. O céu é o limite!! Espero que tenham gostado!! E não esqueçam que o Pajé adora quando os leitores COMENTAM!!!