Claudinei Pereira [Blog]

VPS: configuração básica

Claudinei Pereira — Thu, 16 Apr 2015 04:00:00 GMT

Este artigo integra o tutorial em três partes sobre como Configurar e Administrar um VPS para diversos usos, como hospedagem de sites, backups, etc. Para ter acesso às outras partes visite os links a seguir:

O presente texto objetiva documentar os passos gerais para a configuração inicial de um VPS (Virtual Private Server). Optou-se por escolher softwares e configurações que ofereçam um consumo baixo de memória, visto que o servidor de teste possui 128 MB de memória RAM disponível.

Segurança Básica

Os primeiros passos na configuração do servidor devem ser aqueles relacionados à segurança básica. É necessária a criação de um usuário que executará tarefas administrativas por intermédio do comando sudo. O acesso seguro será feito pelo servidor dropbear (mais leve que o openssh) via par de chaves pública/privada e o firewall iptables deixará abertas apenas as portas necessárias.

Senhas e Usuários

Fazer o primeiro login com a senha de root oferecida pela empresa. Mudar a senha do root para uma forte (que pode ser gerada no site www.random.org).

# passwd

Criar um usuário para administração, instalar o programa sudo (caso ainda não esteja instalado) e adicionar o usuário ao grupo sudo.

# adduser nome-do-usuário
# apt-get update && apt-get upgrade
# apt-get install sudo
# adduser nome-do-usuário sudo
# visudo

O comando visudo abre o arquivo /etc/sudoers para edição. A seguinte linha deve ser descomentada e alterada de:

# %sudo ALL=NOPASSWD: ALL

para:

%sudo ALL=(ALL) ALL

Assim, já é possível sair da conta root e fazer login com o novo usuário paraos próximos passos.

SSH

Instalação do Dropbear

O openssh será substituído pelo dropbear que, por sua vez, será gerenciado pelo xinetd:

# apt-get update && apt-get upgrade
# apt-get install dropbear
# apt-get install xinetd

Configurar o xinetd, criando o arquivo /etc/xinetd.d/dropbear com o seguinte conteúdo:

service dropbear
{
     socket_type  = stream  
     only_from    = 0.0.0.0  
     wait         = no  
     user         = root  
     protocol     = tcp  
     server       = /usr/sbin/dropbear  
     server_args  = -i -w  
     disable      = no  
     port         = número-da-porta  
     type         = unlisted  
}

É interessante mudar o valor de port para uma porta de acesso que seja diferente da padrão (22). Talvez 2222 ou alguma porta mais alta, como 50000. Os valores de server_args significam:

-i = Roda como serviço
-w = Não permite login do usuário root

Parar o servidor openssh, evitar que ele inicie ao boot e reiniciar o xinetd para que o dropbear passe a ser o servidor ssh padrão:

# invoke-rc.d ssh stop
# update-rc.d -f ssh remove
# invoke-rc.d xinetd restart

Login via chaves pública/privada

O login utilizando-se de um par de chaves pública/privada adiciona uma camada extra de segurança. Caso ainda não se possua um par de chaves, deve gerá-lo localmente (assumindo-se que há uma distribuição GNU/Linux instalada com openssh):

$ ssh-keygen -t dsa

Isso criará duas chaves, uma pública (id_dsa.pub) e uma privada (id_dsa) no diretório ~/.ssh. Será requisitada uma senha, que pode ser definida ou não.

Caso se possua uma chave privada, basta extrair a pública com o seguinte comando:

$ ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

Em poder da chave pública, deve-se copiá-la para o servidor:

$ scp -P porta ~/.ssh/id_dsa.pub usuário@servidor:~

Fazer login no servidor e adicionar o conteúdo do arquivo id_dsa.pub ao arquivo ~/.ssh/authorized_keys, configurando as permissões necessárias:

$ ssh -p porta usuário@servidor
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ touch ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/authorized_keys
$ cat ~/id_dsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_dsa.pub

Modificar o arquivo /etc/xinetd.d/dropbear para permitir somente o login sem senha, adicionando a opção -s a server_args. Reiniciar o xinetd para que a mudança tenha efeito.

Firewall

A configuração do Firewall seguinte libera apenas as portas necessárias (por enquanto, 80 para o servidor web e a porta para acesso seguro). Colocar o seguinte conteúdo no arquivo /etc/iptables.up.rules:

*filter

# http://articles.slicehost.com/2010/4/30/ubuntu-lucid-setup-part-1

#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
#-A INPUT -p tcp --dport 443 -j ACCEPT

# UN-COMMENT THESE IF YOU USE INCOMING MAIL!

# Allows POP (and SSL-POP)
#-A INPUT -p tcp --dport 110 -j ACCEPT
#-A INPUT -p tcp --dport 995 -j ACCEPT

# SMTP (and SSMTP)
#-A INPUT -p tcp --dport 25 -j ACCEPT
#-A INPUT -p tcp --dport 465 -j ACCEPT

# IMAP (and IMAPS)
#-A INPUT -p tcp --dport 143 -j ACCEPT
#-A INPUT -p tcp --dport 993 -j ACCEPT

#  Allows SSH connections (only 3 attempts by an IP every minute, drop the rest to prevent SSH attacks)
-A INPUT -p tcp -m tcp --dport PORTA -m state --state NEW -m recent --set --name DEFAULT --rsource
-A INPUT -p tcp -m tcp --dport PORTA -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name DEFAULT --rsource -j DROP
-A INPUT -p tcp -m state --state NEW --dport PORTA -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls (Can grow log files fast!)
#-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
#-A INPUT -j REJECT
#-A FORWARD -j REJECT

# It's safer to just DROP the packet
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

IMPORTANTE: mudar o valor de PORTA para a porta que reflita sua configuração de acesso do dropbear. Para que as regras tenham efeito a cada boot, é necessário adicionar o script na inicialização. Para tanto, adicionar um arquivo com o seguinte conteúdo em /etc/network/if-pre-up./iptables:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules

Também é necessário fazê-lo executável com o comando:

# chmod +x /etc/network/if-pre-up.d/iptables

Logs

O logwatch é uma ferramenta útil para acompanhar os logs do sistema via email. Instalação:

# apt-get install logwatch

Para configuração, verificar os arquivos de exemplo em /usr/share/logwatch/default.conf/.

Servidor de email

Por fim, é interessante deixar um servidor de email rodando, para receber via email os logs do sistema gerados pelo logwatch. Para tanto, vamos instalar o exim configurado com uma conta comum do gmail.

Instalação:

# apt-get install exim4-daemon-light mailutils

Configuração:

# dpkg-reconfigure exim4-config

passwd.client

*.google.com:email@gmail.com:senha

exim4.conf.localmacros

MAIN_TLS_ENABLE = 1

Para outros detalhes sobre este tipo de configuração de email, verificar a página GmailAndExim4.

Outras ações

Syslog

Para gerenciar os logs do sistema iremos utilizar o daemon syslog. O VPS de teste possui o rsyslogd, então vamos removê-lo:

# invoke-rc.d rsyslog stop
# update-rc.d -f rsyslog remove

Instalar syslogd:

# apt-get install inetutils-syslogd

Configurar syslogd:

# invoke-rc.d inetutils-syslogd stop
# rm -rf /var/log/*.log
# rm -rf /var/log/mail.*
# rm -rf /var/log/debug
# rm -rf /var/log/syslog
# rm -rf /var/log/fsck
# rm -rf /var/log/news

Arquivo de configuração do syslog (/etc/syslog.conf):

*.*;mail.none;cron.none -/var/log/messages
  cron.*                -/var/log/cron
  mail.*                -/var/log/mail

Adicionar ao logrotate (/etc/logrotate.d/inetutils-syslogd):

/var/log/cron
/var/log/mail
/var/log/messages {
    rotate 4
    weekly
    missingok
    notifempty
    compress
    sharedscripts
    postrotate
    /etc/init.d/inetutils-syslogd reload >/dev/null
endscript
}

Reiniciar syslog:

# invoke-rc.d inetutils-syslogd start

Remoção de pacotes

Alguns pacotes pré instalados no VPS não são necessários, ou serão substituídos por outros, então vamos removê-los:

# apt-get remove bind9
# apt-get remove 'samba*'
# apt-get remove portmap
# invoke-rc.d apache2 stop
# update-rc.d -f apache2 remove
# apt-get remove 'apache2*'
# invoke-rc.d nscd stop
# update-rc.d -f nscd remove
# apt-get remove nscd  
# invoke-rc.d sendmail stop
# update-rc.d -f sendmail remove
# apt-get remove 'sendmail*'

Locales e tempo do servidor

# dpkg-reconfigure locales
# dpkg-reconfigure tzdata

Mudar Shel

Para mudar o shell de bash para mksh:

# apt-get install mksh

Mudar /etc/passwd trocando o bash pelo mksh.

Conclusão

Estes foram os passos inicais para configurar um VPS de 128 mb, procurando deixá-lo preparado para a instalação de outros servidores (web, base de dados, backup). Ãpós o conjunto de instruções relatadas neste artigo, o VPS em questão está consumindo 15 mb de memória RAM, deixando espaço para um servidor web com suporte a PHP, que será o foco do próximo tutorial.

VPS: O que é?

Claudinei Pereira — Thu, 09 Apr 2015 01:00:00 GMT

O tutorial ao qual esta introdução se refere foi dividido em trê partes e tem o objetivo de mostrar como Configurar e Administrar um VPS para diversos usos, como hospedagem de sites, backups, etc. Para ter acesso às partes visite os links a seguir:

Um VPS (do inglês Virtual Private Server) é uma máquina virtual que executa um sistema operacional completo. É instalada em um hardware real que pode trazer várias máquinas virtuais rodando ao mesmo tempo dividindo os recursos existentes entre si. Podem ser utilizados de diversas maneiras, sendo a hospedagem de websites um dos usos mais correntes.

A utilização de um VPS requer um certo conhecimento do sistema operacional em uso, visto que o administrador precisa executar tarefas pertinentes ao gerenciamento de usuários, instalação, configuração e atualização de pacotes, segurança, etc. O acesso a essas máquinas, via de regra, é feito por SSH (Secure SHell) e, nesta modalidade de acesso, as ações nelas executadas são por linha de comando.

Eu adquiri um VPS em 2011, com o intuito de aprendizado e para hospedar alguns websites. Ele possui 256 mb de memória RAM disponível, 10 gb de disco rígido e transferência mensal de 250 gb. Ele roda atualmente um servidor de banco da dados (MySQL) e um servidor web (nginx) com suporte a PHP. Com esta configuração possuo um website pessoal (HTML + CSS), este blog (HTML + CSS), um website de empresa (PHP) e um ambiente virtual de aprendizagem (PHP + MySQL).

O que me motivou a escrever este conjunto de artigos foi a obtenção de mais uma máquina virtual, desta vez para configurar um servidor de backup remoto. Resolvi escrevê-los para referência pessoal futura e também para compartilhar o conhecimento que adquiri durante o processo de administração destes sistemas.

Caso alguém tenha interesse adquirir uma máquina virtual para aprendizado, pode obter uma na mesma empresa em que adquiri a que me servirá de backup remoto: a RamNode. Por 15 doláres AO ANO é possível adquirir um VPS com 128 mb de memória RAM, 12 gb de espaço em disco e 500 gb de transferência mensal.

Vamos botar a mão na massa? :)

Google Apps: Configuração de DKIM

Claudinei Pereira — Wed, 06 Jul 2011 11:40:00 GMT

Este artigo integra o tutorial em duas partes sobre como configurar SPF e DKIM para os emails do Google Apps de forma a demonstrar sua legitimidade. Para ter acesso à outra parte visite o link a seguir:

Google Apps: Configuração de SPF

A configuração de DKIM (do inglês DomainKeys Identified Mail) é outra ferramenta que inibe a utilização de determinado domínio de forma não lícita por spammers. Consiste em adicionar uma assinatura digital aos email, por meio de um par de chaves pública e privada. Com esta configuração, cada email é assinado no servidor de origem pela chave privada e, em seguida, a assinatura é verificada pelo servidor de destino por meio da chave pública disponível vi DNS.

Geralmente, ao configurarmos um servidor de emails, as chaves são criadas no próprio servidor. A chave privada fica gravada num arquivo protegido no sistema de arquivos da máquina e a chave pública é publicada como registro DNS do tipo TXT. Já no Google Apps, a geração das chaves é feita via interface de administração do domínio. O caminho é o que se segue:

Logar na conta de administração do Google Apps e clicar no link Administrar este domínio;
Clicar no menu Ferramentas Avançadas;
Clicar no link Configurar autenticação de e-mails (DKIM);
Clicar no link Gerar novo registro. Abrirá uma caixa de diálogo perguntado sobre o "selecionador de prefixo". É uma configuração opcional e pode ser deixada no padrão (google).

Após os passos anteriores, a chave pública é informada, tendo o seguinte formato:

v=DKIM1; k=rsa; p=VALOR-DA-CHAVE

Também é informado o "selecionador de prefixo", por padrão:

google._domainkey

Devemos atualizar o DNS com um registro TXT com esses valores, sendo que o selecionador deve ser informado como subdomínio. Após a atualização, a propagação da informação pode levar até 48 horas. Para verificar se foi feita a propagação, podemos utilizar o comando host no Linux ou o nslookup no Windows. No Linux, o comando é o seguinte:

$ host -t TXT google._domainkey.dominio.com 8.8.8.8

No Windows:

>nslookup -type=TXT google._domainkey.dominio.com 8.8.8.8

Conclusão

Tanto a configuração de SPF quanto de DKIm são desejáveis e até mesmo necessárias para demonstrar a legitimidade dos emails enviados por um domínio, aumentando sua proteção contra uso indevido por spammers. O Google Apps facilita as configurações, ficando a cargo do administrador de domínio as alterações de DNS necessárias, conforme mostradas neste tutorial.

Google Apps: Configuração de SPF

Claudinei Pereira — Wed, 06 Jul 2011 11:35:00 GMT

Este artigo integra o tutorial em duas partes sobre como configurar o SPF e DKIM para os emails do Google Apps de forma a demonstrar sua legitimidade. Para ter acesso à outra parte visite o link a seguir:

Google Apps: Configuração de DKIM

A configuração de SPF (do inglês Sender Policy Framework) permite ao administrador do domínio autorizar determinados servidores para envio de emails. Desta maneira, o servidor que recebe a mensagem pode verificar que o servidor que a enviou foi autorizado pelo detentor do domínio.

Ao utilizarmos o Google Apps para email e não termos o SPF configurado, quem recebe o email pode verificar conteúdo parecido com o seguinte nos cabeçalhos:

Received-SPF: neutral (google.com: 209.85.210.48 is neither permitted 
nor denied by best guess record for domain of email@dominio.com) 
client-ip=209.85.210.48;
Authentication-Results: mx.google.com; spf=neutral 
(google.com: 209.85.210.48 is neither permitted nor denied by best 
guess record for domain of email@dominio.com)

Ou seja, o servidor que recebeu o email não pôde determinar se a máquina que o enviou era autorizada ou não pelo domínio para envio de emails, dando a ele uma classificação neutra (spf=neutral). Pode ocorrer que emails com SPF neutro acabem sendo marcados como spam por certos servidores receptores, principalmente se o volume de mensagens enviadas for relativamente grande.

Para configurar o SPF para o Google Apps devemos publicar um registro DNS do tipo TXT. Como há variações nos gerenciadores de DNS para domínios, indicaremos somente a linha a ser adicionada ao registro:

v=spf1 include:_spf.google.com ~all

Deve-se esperar um tempo para que o DNS seja propagado (até 48 horas). Para verificar se o registro já está ativo, podemos usar o com o comando host no terminal do Linux:

$ host -t TXT dominio.com

No Windows, o comando é o nslookup:

>nslookup -type=TXT dominio.com 8.8.8.8

Com o registro TXT publicado e funcionando, ao enviarmos um email o receptor poderá verificar o cabeçalho, que agora terá conteúdo parecido com o seguinte, indicando que o teste de SPF teve êxito (pass):

Received-SPF: pass (google.com: domain of email@dominio.com designates 
209.85.210.48 as permitted sender) 
client-ip=209.85.210.48;
Authentication-Results: mx.google.com; spf=pass (google.com: 
domain of email@dominio.com designates 209.85.210.48 as permitted sender)

Google Apps: Emails personalizados para seu domínio

Claudinei Pereira — Wed, 06 Jul 2011 11:30:00 GMT

O tutorial ao qual esta introdução se refere foi dividido em duas partes e tem o objetivo de mostrar como configurar SPF e DKIM para os emails do Google Apps de forma a garantir sua legitimidade. Para ter acesso às partes visite os links a seguir:

Quem deseja dar um aspecto mais profissional ao seu blog, site ou quer ter endereços de email personalizados deve, inevitavelmente, investir num domínio próprio. Domínios .com custam cerca de R$ 18,00 ao ano, os .info custam menos da metade deste valor e há até mesmo os gratuitos como os oferecidos pelo co.cc.

Google Apps Logo.

Ao se possuir um domínio .com, o serviço gratuito Google Apps pode ser usado para personalizar emails (seunome@dominio.com) e até mesmo hospedar sites. Também há a possibilidade de obter uma solução completamente gratuita ao configurar um domínio do co.cc com o Google Apps.

Independente do tipo de domínio utilizado com o Google Apps, pode-se configurar o serviço de maneira que os emails tenham sua origem certificada e sejam assinados digitalmente. Isto diminui as chances de que o endereço de email configurado para o domínio seja utilizado por spammers e / ou acabe sendo marcado como spam pelo receptor.

As configurações citadas são opcionais porém altamente recomendáveis, visto que visam garantir a autenticidade dos emails enviados por determinado domínio. Assim, pode-se ter certeza que as mensagens serão entregues aos seus destinatários, sem serem desviadas para a caixa de spam e podendo não serem vistas.

CDTC - Cursos online gratuitos

Claudinei Pereira — Sat, 02 Jul 2011 07:50:00 GMT

O CDTC (Centro de Difusão de Tecnologia e Conhecimento) é uma iniciativa do governo federal que oferece cursos online gratuitos na área de tecnologia para a comunidade e servidores públicos federais, estaduais e municipais. É uma ótima oportunidade para aqueles que desejam fazer cursos de Ensino a Distância via internet.

bs-iv-folie-4: Há uma busca cada vez maior por cursos online para melhorar o currículo.

Os cursos são realizados na plataforma Moodle, um ambiente de aprendizagem virtual que fornece diversas ferramentas para aprendizado, tais como fórums de discussão, chats e multimídia. Há vários disponíveis, sendo que dentre eles podemos citar como exemplo o de BrOffice, de programação Python e o de Libras.

A inscrição nos cursos para a comunidade do CDTC é feita mediante o cadastro no sistema com um email válido que possua final .br. Caso haja interesse nos cursos para servidores públicos é necessário ter um email institucional - de órgão públicos ou universidades. Também é necessário possuir computador com acesso à internet e disponibilidade de pelo menos uma hora por dia para a realização das atividades.

Os cursos na modalidade de Educação à distância do CDTC são uma ótima forma para atualização profissional. Além disso, dão a oportunidade de conhecer como funciona um ambiente virtual de aprendizagem, podendo despertar no cursista o desejo de continuar sua formação com outros cursos, visto que há graduações e até mesmo pós graduações oferecidas nesta modalidade.

Como criar senhas seguras

Claudinei Pereira — Tue, 28 Jun 2011 16:10:00 GMT

Um recente ataque de um grupo de hackers / crackers organizados resultou no vazamento de 62 mil senhas do writerspace. Isto mostra a fragilidade de alguns sites no que se refere a manter o sigilo e segurança dos dados de seus usuários. Mostra, também, a falta de cuidado de grande parte dos usuários no momento de criarem suas senhas.

Senhas fracas são porta de entrada para ataques cibernéticos.

Uma análise das senhas vazadas (em inglês) demonstra que de nada adianta servidores de internet super seguros se o usuário não dá a devida importância à criação de senhas seguras. Utilizar sequências numéricas simples ou palavras de dicionário é um dos erros mais frequentes na criação de senhas. Por exemplo, veja as 5 senhas mais comuns, dentre as 62 mil, reveladas pela análise citada:

"123456" foi utilizada 558 vezes;
"123456789" foi utilizada 181 vezes;
"password" ("senha", em inglês) foi utilizada 132 vezes;
"romance" foi utilizada 88 vezes;
"102030" foi utilizada 68 vezes.

Outros erros comuns são senhas curtas - a análise demonstra que a extensão de senha média é 7.63 caracteres - e a pouca complexidade das mesmas - feitas somente com letras, ou somente com números, etc. Diante disto, compartilho a seguir algumas dicas para criar senhas mais seguras.

Criando senhas seguras

Para garantir a qualidade de senhas podemos seguir os três fatores já expostos:

Randomização: não utilizar sequências numéricas, palavras de dicionário, dados pessoais como data de nascimento, iniciais, etc;
Extensão: senhas razoavelmente seguras devem possuir entre 12 e 14 (em inglês) caracteres. Quanto mais, melhor;
Complexidade: misturar letras (em caixa alta e baixa), números e símbolos.

Ferramentas

O site random.org é útil para criar senhas randômicas. Sua utilização é simples: devemos informar o número de senhas a gerar e a quantidade de caracteres desejada. Para exemplificar, solicitei a geração de 3 com 14 caracteres cada uma. O resultado foi (AVISO: Não as utilize!!!):

Here are your random passwords:

    crXFEf5HW6gwks
    3rKWwFA9hy6mGq
    9Y6PEZFhUSstTw

Creio que a memorização de senhas assim esteja fora de questão, então podemos anotá-las ou, melhor, utilizar um programa para gerenciá-las, como o KeePass.

Conclusão

Embora a ação de hackers / crackers exponha a fragilidade de servidores web, o ponto mais fraco na cadeia de segurança muitas vezes é o próprio usuário. Por isso, não divulgar dados pessoais na internet e criar senhas de qualidade são ações que podem garantir uma navegação mais segura.

Bandas e twitcam

Claudinei Pereira — Sun, 26 Jun 2011 07:05:00 GMT

Aviso: Este post foi recuperado miraculosamente do cachê do google. Foi escrito no antigo blog em agosto de 2010.

Dia 03 de agosto de 2010, acompanhei o ensaio, via twitcam, de uma banda chamada Rockafé, de Maringá/PR, que tem por baixista o @thiagohmelo. Ele, além de baixista da banda, também é responsável pela walbatroz, empresa de desenvolvimento de softwares e websites, junto com o Ricardo Silva, vulgo @pensarics.

Músico que sou - bem, toco guitarra, já fiz parte de banda de Heavy Metal (Hail Defender!), posso me considerar músico, não? - interessa-me acompanhar o uso que músicos fazem das tecnologias e das ferramentas sociais - no caso, twitter e twitcam. Basta um computador com acesso à internet, câmera e um microfone para que uma banda ou músico possam divulgar sua obra via rede mundial de computadores.

Estou expondo um caso de uma banda local, que faz covers, mas ainda assim apresenta uma boa qualidade. Há casos de bandas já consagradas (Sepultura, por exemplo) que se utilizam do mesmo expediente para transmitirem seus shows. E todos acabam se beneficiando: o público, que passa a conhecer boas novas bandas, ou assiste àquelas que já conhece e admira; e os músicos, que divulgam seu trabalho e consolidam sua base de fãs.

Além da questão da divulgação do trabalho artístico, ainda fica evidenciado o contato direto que os músicos passam a manter com seus admiradores. Divulga-se não só a música ou shows, mas também eles podem saber o que seus ouvintes pensam sobre sua obra, tendo um feedback que pode estimulá-los a manter e ampliar sua atuação "virtual".

Músicos, bandas e ouvintes fazendo parte de uma comunidade voltada à produção e apreciação musical, ligados pelas ferramentas que hoje em dia são disponibilizadas pela internet. Democratização da arte e da diversão musical. Espero vivenciar mais vezes músicos que possuem sua mentalidade voltada para esta nova forma de divulgação!

Update: o Thiago escreveu sobre este ensaio do Rockafé. Os vídeos podem ser vistos em seu perfil do twitcam.

Falha no Dropbox e segurança na Web

Claudinei Pereira — Wed, 22 Jun 2011 07:50:00 GMT

O serviço de armazenamento de arquivos Dropbox (link de afiliado) sofreu uma grave falha de segurança no dia 19 de junho de 2011. Durante 4 horas qualquer conta do site pôde ser acessada somente informando-se o email de cadastro, sem a necessidade de informar a senha. Após a falha ter sido descoberta, foi corrigida em 4 minutos. Os proprietários das contas acessadas no período (cerca de 1%) já foram contactados pelos criadores do serviço.

Unplug for safety: A solução para segurança na internet é não usar a internet.

Casos assim fazem-nos refletir sobre a segurança de nossos dados na web. Usamos emails, comunicadores instantâneos, buscadores e outros serviços disponibilizados online. Ao utilizá-los, concordamos em fornecer dados pessoais como nome completo, localização, preferências pessoais, etc. Ao trocarmos emails com outras pessoas, enviamos fotos, endereços, telefones e outras informações que, pensamos, só podem ser acessadas pelo destinatário do email.

A verdade é que dificilmente alguma informação colocada na internet estará 100% segura. Você utiliza algum serviço do google (como o gmail) ou da Microsoft (como o Hotmail)? Já leu os termos de serviço destas empresas? Se não, veja o que diz os termos de serviço do Google:

14.3 ESPECIFICAMENTE, O GOOGLE, AS SUAS SUBSIDIÁRIAS E LICENCIADORES NÃO GARANTEM QUE:
[...]
(B) O USO DOS SERVIÇOS SERÁ ININTERRUPTO, PONTUAL, SEGURO E ISENTO DE ERROS;

Agora, os termos de serviço da Microsoft:

Fornecemos o serviço "no estado em que se encontra", "com todas as falhas" e "conforme disponível". Não garantimos a precisão ou a atualidade das informações disponíveis do serviço. Você reconhece que os sistemas de computador e telecomunicações não estão livres de falha, e podem ocorrer períodos eventuais de tempo de inatividade. Não garantimos que o serviço será ininterrupto, atualizado, seguro ou sem erros, ou que não ocorrerá perda de dados. [...]

Declarações semelhantes podem ser encontradas no Facebook, no próprio Dropbox ou em qualquer outro serviço online. E nós concordamos com estes termos cada vez que fazemos um cadastro em um novo site / serviço.

Diante disto, qual solução podemos encontrar para a segurança de nossos dados? Para os paranóicos, com certeza é desplugar-se completamente da internet. Particularmente sugiro: bom senso naquilo que enviamos e compartilhamos na internet, tendo-se sempre em mente que nunca estaremos seguros; e aprender um pouco sobre criptografia de dados.

Blogofile e Git

Claudinei Pereira — Mon, 13 Jun 2011 03:05:00 GMT

O Blogofile é um sistema de gerenciamento de conteúdo, desenvolvido em Python e que utiliza a biblioteca Mako para o sistema de templates, podendo ser usado em conjunto com o Git para controle de versão. Ele compila arquivos escritos em diferentes linguagens de marcação - como rst e Markdown, só para citar dois exemplos - para arquivos xHTML válidos. É utilizado para gerenciar sites e blogs, com a vantagem de produzir arquivos estáticos que não dependem de base de dados ou de alguma linguagem instalada no servidor para geração de páginas dinâmicas. Quando utilizado para gerar blogs, utiliza o Disqus como gerenciador comentários.

Instalação em sistemas Debian

Os seguintes passos descrevem a instalação do Blogofile e do Git num servidor remoto, que também deverá ter algum servidor web instalado para servir as páginas xHTML geradas pelo programa.

A instalação do Blogofile pode ser simplificada ao utilizarmos o pacote setuptools, que gerencia a instalação de bibliotecas python. Os seguintes comandos instalam o setuptools, o git e o Blogofile com todas suas dependências:

$ sudo aptitude install setuptools
$ sudo aptitude install git-core
$ sudo easy_install -U blogofile

Com isto feito, podemos iniciar um blog simples numa pasta vazia no diretório $HOME do usuário:

$ mkdir $HOME/blogofile
$ cd $HOME/blogofile
$ blogofile init simple_blog

O comando blogofile init simple_blog cria alguns arquivos e pastas que podem ser editados para criar um site ou blog. Neste último caso, os posts ficam na pasta _posts e devem possuir o formato nome-do-post.linguagem-de-marcação. Após criarmos páginas ou posts, podemos gerar os arquivos estáticos, que ficam armazenados na pasta _site:

$ blogofile build

Configuração

Após o processo de instalação no servidor remoto, devemos configurar o git para iniciar um repositório na pasta do blog ou site para que possamos editar os arquivos num computador local. No computador local, podemos configurar o blogofile por meio do arquivo _config.py, criar páginas ou posts, editar o estilo CSS e adicionar imagens para, finalmente, gravar as alterações locais no servidor remoto.

Configurando o Git

A configuração do Git descrita nesta seção possibilita a geração automática de arquivos estáticos após cada push do computador local para o remoto. No computador remoto, devemos inicialmente criar um arquivo de configuração do usuário ($HOME/.gitconfig) com o seguinte conteúdo:

[user]
    name = Nome do usuário
    email = nomedousuario@dominio.com

Agora, podemos iniciar o repositório e adicionar os arquivos:

$ cd $HOME/blogofile
$ git init
$ git add .
$ git commit -m "Commit Inicial"

A parte mais importante do processo é a criação do arquivo post-receive, que deve ser gravado na pasta $HOME/blogofile/.git/hooks/ com o seguinte conteúdo:

#!/bin/sh
unset GIT_DIR
cd $HOME/blogofile
git reset --hard
/usr/local/bin/blogofile build

Também devemos torná-lo executável:

$ chmod +x $HOME/blogofile/.git/hooks/post-receive

Este arquivo será executado após cada push, gravando as mudanças nos arquivos do repositório e chamando o comando blogofile build que cria as páginas estáticas.

Ainda na máquina remota, devemos configurar o git para aceitar as mudanças diretamente no branch MASTER. Este comportamento é aceitável num único repositórios com um único usuário, não devendo ser aplicado em repositórios que possuam mais de um usuário ou que sejam idealizados para possuir vários branches. Para tanto, adicionamos as seguinte linhas no arquivo $HOME/blogofile/.git/config:

[receive]
    denyCurrentBranch = ignore

Configurando o Blogofile

Agora podemos começar a trabalhar na máquina local ao clonarmos o repositório remoto. Com isto, podemos trabalhar localmente e só enviar as mudanças para o computador remoto quando as configurações, páginas ou posts estiverem prontos. Para clonar o repositório remoto:

$ git clone ssh://nome-do-usuário@máquina-remota:porta/caminho-do-repositório

O comando trará todos os arquivos remotos para a máquina local. Podemos, então, configurar o blogofile, editando o arquivo _config.py localmente. Algumas variáveis deste arquivo que podemos personalizar:

# URL do site ou blog
site.url = ""
# Nome do site ou blog
blog.name = "" 
# Descricao do site ou blog
blog.description = "" 
# Zona horaria de Sao Paulo
blog.timezone = "America/Sao_Paulo" 
# numero de posts por pagina
blog.posts_per_page = 5 
# Habilita Permalinks automaticos
blog.auto_permalink.enabled = True 
# Formato do permalink. Neste caso, indicamos para o blogofile que
# desejamos somente o titulo do post no permalink
blog.auto_permalink.path = "/:title" 
# Habilita comentarios do disqus
blog.disqus.enabled = True
# Nome de usuario do disqus
blog.disqus.name = ""
# Desabilita pagina inicial customizada. Util no caso de blogs
# instalados diretamente na raiz do site
blog.custom_index = False

Criando Posts

Podemos criar posts no blogofile utilizando várias linguagems de marcação, como rst, markdown e até mesmo html. É importante que o título do arquivo contenha como "extensão" o nome da linguagem de marcação. O seguinte exemplo contém o código que foi utilizado para criar o primeiro post deste blog (nomeado 1. Primeiro Post.markdown):

---
title: Primeiro Post
categories: Pessoal
date: 2011/06/11 17:10:00
tags: teste, dummy
---
Este é o **primeiro** post deste blog, apenas para servir de template
para os posteriores.
![Hello World](/images/hello.png "Hello World!")

Nele utilizei as variáveis title, categories e date para indicar ao blogofile, respectivamente, o título, a categoria e a data de criação do post. O uso da variável tags é opcional.

Para enviar as mudanças de configuração e algum post:

$ git add _posts/nome-do-post.extensão
$ git commit -a -m "Insere post e configuração do _config.py"
$ git push origin master

Conclusão

O blogofile é um gestor de conteúdo indicado para ser utilizado em servidores de baixos recursos de memória ou processamento, pois cria blogs e sites estáticos que não necessitam de base de dados ou de linguagens de programação para geração de páginas dinâmicas. Além disso, permite a customização tanto das páginas e estilos do site como também da lógica por trás da geração dos conteúdos via modificação ou criação de scripts python.