Backup na nuvem com Tarsnap

Este post estava sendo escrito antes de eu abandonar meu blog, então onde estiver escrito recentemente, hoje, etc, leia-se 2 anos atrás.

Recentemente precisei implementar uma solução de backup para alguns servidores de internet, após uma pesquisa rápida optei pelo Tarsnap, uma solução de backup em nuvem baseado na infra-estrutura de armazenamento da Amazon.

Eu queria algo simples de implementar e manter, não queria ter mais um servidor nas mãos, nem queria ter que lidar com detalhes de ssh, rsync, ftp, etc. Em resumo:

• Não queria manter um novo servidor (nem físico nem virtual)
• Não queria usar o Bacula, ótima ferramenta mas complicado
• A solução deveria ser simples de configurar e manter, do tipo “configure uma vez, contrate um serviço e funcione para o resto da vida”
• Não estava procurando apenas uma ferramenta, mas também um serviço de armazenamento para backup

O Tarsnap é uma ferramenta e também um serviço de armazenamento, o preço é bem razoável, $0.30 por GB de armazenamento mensal e $0.30 por cada GB transferido. A cobrança é pré-paga, e para começar a usar o serviço é necessário adicionar um crédito mínimo de $ 5.

Os créditos são consumidos diariamente, quando eles acabam o serviço continua funcionando por até 7 dias, isto dá tempo de pôr créditos novamente sem interrupção dos backups. Hoje, o backup dos meus servidores tem aproximadamente 7 GB e isto consome um pouco menos de $ 5 mensal.

Infelizmente, o tarsnap não é software-livre, o autor disponibiliza o código fonte, mas a licença não permite redistribuir o software com modificações. Apesar disso o autor afirma contribuir bastante com o libarchive, uma biblioteca livre para compressão e arquivamento usada como base para o tarsnap.

Não vou detalhar o uso da ferramenta, darei apenas dois exemplos básicos: (1) como adicionar um servidor e (2) como criar backups. Considerando que você já tem o tarsnap instalado em seu servidor, veja as instruções de instalação aqui, gere uma chave para ele com o comando abaixo, se tiver dificuldades consulte este link.

# tarsnap-keygen --keyfile /root/tarsnap.key --user me@example.com --machine mybox

Substitua me@example.com pelo email usado para criar a conta no Tarsnap, e mybox pelo hostname do seu servidor. Faça uma cópia de seguança do arquivo /root/tarsnap.key, sem ele não será possível acessar o backup!

Com isso já é possível criar um novo backup, o comando abaixo cria um backup do diretório /home por exemplo, veja outros comandos aqui.

# tarsnap -c -f mybackup-home /home

O tarsnap apenas cria, lê, apaga e restaura backups, ele não gerencia agendamento, política de retenção, periodicidade, etc. É necessário alguma outra ferramenta para essa tarefa, em uma rápida pesquisa encontrei o tarsnapper, um agendador para o tarsnap, com ele é possível de maneira simples definir uma política de retenção usando um arquivo de configuração localizado em /etc/tarsnapper.conf. Veja um exemplo:

# fazer backup diario e reter:
# a cada semana (7 dias)
# a cada mes (30 dias)
# a cada semestre (180 dias)

deltas: 1d 7d 30d 180d

target: /mybox/$name-$date

jobs:
  etc:
    source: /etc

  mysql:
    source: /var/backups/mysql
    exec_before: /usr/local/bin/dump-mysql

  foswiki:
    sources:
      - /var/lib/foswiki/data
      - /var/lib/foswiki/pub

O tarsnapper deve ser agendado no cron, eu sugiro executar ele diariamente, para isso crie o arquivo /etc/cron.daily/tarsnapper com o seguinte conteúdo:

#!/bin/sh
# Start in the root filesystem, make SElinux happy
cd /

tarsnapper -o configfile /etc/tarsnap.conf -c /etc/tarsnapper.conf make >> /var/log/tarsnapper.log 2>&1

Dê permissão de execução a este arquivo, isto vai fazer o cron vai rodar o tarsnapper diariamente executando o tarsnap para cada job presente no arquivo de configuração. Lembrando que todos os comandos foram testados no sistema operacional Debian GNU/Linux e não há garantias que funcionem corretamente em outros sistemas.

Com isso você tem um esquema de backup simples de implementar e manter. Espero que tenha sido útil de alguma forma, em caso de dúvidas, sugestões ou reclamações, por favor, entre em contato através do email, twitter ou se preferir atrevés do meu perfil no github.

Monitorando JBOSS com Zabbix

Monitorar um JBoss é muito mais do que verificar se as portas estão funcionando, ou se o serviço está em execução. Precisamos monitorar como está a performance do ambiente, e nesse ponto que o Zabbix com sua interface Java para consultas JMX entra “no jogo”.

Introdução

Este tutorial detalha o processo de monitoramento da interface JMX nativa do ZABBIX para monitorar o desempenho do servidor de aplicações JBoss.

Por padrão servidores de aplicações Java, como o JBoss, possibilita a monitoria através da utilização de recursos pela ferramenta JConsole, disponível no pacote JDK do Java, ou utilizar ferramentas de linha de comando como o Twiddle.

A utilização do JConsole é, até certo ponto, aceitável de utilizar, porém integrando este tipo de monitoramento com o ZABBIX, você poderá criar triggers e ações de acordo com os problemas que poderão surgir com seu servidor e/ou aplicativos e enviar alertas. Isso sem falar na ajuda dos gráficos, que facilita a analise do ambiente como um todo. No JConsole isso só é possível gravando os dados em um relatório, pois o monitoramento é feito sem armazenar os dados coletados, ou seja, fazer com o Zabbix é muito melhor.

Ambiente

O ambiente utilizado possui duas máquinas, ambas com a distribuição GNU/Linux Debian wheezy.

Uma das máquinas atua como servidor Zabbix, e nela foi instalada os seguintes pacotes:

• zabbix server 2.4.2
• zabbix-java-gateway 2.4.2
• zabbix-agent 2.4.2
• java 7

Na outra foi instalado o servidor de aplicações web:

• Jboss 4.2.3
• java 5.0_22
• zabbix-agent 2.4.2

Instalação

Nessa documentação não entraremos no detalhe da instalação do servidor Zabbix padrão, vamos apenas detalhar o processo do Zabbix Java Gateway.

O Zabbix Java Gateway é um software escrito em Java e seu funcionamento é bem simples.

Quando o servidor ZABBIX deseja obter o valor de um Item em um JBoss, ele faz a requisição ao Zabbix Java Gateway que fica responsável por interagir com a aplicação JBoss, através de uma API de gerenciamento JMX. Por esse motivo, só é possível fazer este tipo de monitoramento no modo passivo.

Para que o monitoramento JMX funcione, o serviço do Zabbix Java Gateway tem que estar em execução apenas no servidor Zabbix, ou seja, nada precisa ser instalado no servidor JBoss, além do zabbix-agent.

Para instalar o gateway java, execute o comando abaixo:

aptitude install zabbix-java-gateway

Execute o comando abaixo para verificar se o serviço está em execução:

systemctl status zabbix-java-gateway

Caso o serviço não esteja ativo, execute o seguinte comando:

systemctl start zabbix-java-gateway

O Zabbix Java Gateway estará escutando na porta 10052, sendo assim digite o comando abaixo para validar isso:

netstat -anp | grep 10052

O resultado deverá ser algo assim:

tcp 0 0 127.0.0.1:37732 127.0.0.1:10052 TIME_WAIT –
tcp6 0 0 :::10052 :::* LISTEN 4217/java

Configuração no servidor Zabbix

Acesse o arquivo /etc/zabbix/zabbix_server.conf e configure os seguintes parâmetros:

JavaGateway=127.0.0.1
JavaGatewayPort=10052
StartJavaPollers=5

Depois de gravar o arquivo, reinicie o serviço do ZABBIX server e java-gateway:

systemctl restart zabbix-server
systemctl restart zabbix-java-gateway

Configuração no servidor JBoss

Acesse o arquivo $PATH_JBOSS/bin/run.conf e acrescente as linhas abaixo no final do arquivo:

JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote”
JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345″
JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false”
JAVA_OPTS=”$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false”

Reinicie o serviço do JBoss para que as mudanças tenham efeito.

Configuração via interface web

Abra a configuração do host que deseja fazer o monitoramento do JBoss e insira o IP do servidor e a porta 12345, que foi configurada no arquivo run.conf do JBoss, conforme podemos ver na imagem abaixo:

A partir do ZABBIX 2.0 já tem um template pronto com alguns exemplos úteis para utilização, inclusive com gráficos. No menu Configuração >> Templates, procure por Template JMX Generic.

Aplique o template em seu host e aumente o nível de analise do seu ambiente.

Autoria

Esse artigo foi criado por Madson Araujo, em seu trabalho como Bolsista de Monitoramento da UFBA, revisado e transformado em artigo de blog por mim.

Fonte

https://www.zabbix.com/documentation

Joining Facebook

I am really excited to announce that I’m joining Facebook in January! I’ll be bootstrapping Android UI efforts—frameworks and user-facing stuff—in the London office. There are still a lot of details to sort out but that’s the general plan.

Why Facebook? They have an amazing hacker-driven culture, they’re striving to do open source the right way, there’s a lot of space for experimentation, and they have massive reach in the Android space.

I’m really looking forward to learning a lot at Facebook. And there is so much to be done! I can’t wait to start :-)

Things to celebrate

Turning 35 today, then I get the great news that the person whom I share my dreams with has just become a Debian member! Isn't beautiful? Thanks Tássia, thanks Debian! I should also thank friends who make an ideal ambience for tonight's fun.

Um Trabalho a Troco de nada? A resposta da comunidade GNOME para Jô Soares e Bill Gates à luz da teoria da Dádiva

Sete anos após uma  apresentação feita no IV Fórum GNOME em 2007 com esse mesmo título, finalmente, eu consegui publicar, em parceria com Genauto França Filho (meu orientador de Doutorado), o resultado da pesquisa que tentou responder uma questão que ronda o ecossistema dos projetos de software livre: "quem pode se permitir fazer um trabalho profissional a troco de nada?"  Mais especificamente, esse artigo foi publicado na revista (acadêmica) Sociologias - uma publicação quadrimestral do Programa de Pós-Graduação em Sociologia da UFRGS, destinada a promover intercâmbio entre cientistas sociais.

No entanto, é importante ressaltar que essa questão norteadora da nossa pesquisa foi, inicialmente, levantada por Biil Gates na histórica "Carta Aberta aos Hobbistas" escrita em 1976  - um ano depois da fundação da então "Micro-Soft". Além dele, quatro décadas depois, mais especificamente em outubro de 2006, ela foi "remixada" por Jô Soares, no seu programa de televisão. Em uma de suas entrevistas, ao ser informado pelo Sérgio Amadeu (Prof. da UFABC) e pelo Júlio Neves (Prof. da UNiRio) sobre um possível engajamento voluntário de hackers ligados ao projetos de software livre, Jô Soares ressalta que, na visão dele, "por trás do fato do que é dado (software) de graça há uma intenção de ser vendido. (...) ou é um pessoal que é tudo monge Franciscano?"

O ponto de partida desse artigo que escrevemos na Sociologias é que ainda são poucos os estudos que procuram analisar as características e a natureza desse novo contexto digital (de relações mediadas por dispositivos móveis como computadores, tablets e celulares) para além de um entendimento que tem como base apenas as noções de uma racionalidade utilitária ou do simples interesse econômico. Afinal, podemos dizer que mais recorrente do que esse tipo de pergunta é o tipo de resposta comum (e apressada) que diz que "ninguém trabalha de graça" ou que "sempre há um interesse financeiro nisso tudo".

Para evitar os limites de uma única forma de resposta "apressada" (para não dizer "equivocada") e, com isso, restringir a compreensão sobre a ação dos hackers nesses projetos, avaliamos que era importante respondê-la com um olhar mais científico e aprofundado. Assim, realizamos uma análise mais qualitativa sobre esse "fenômeno" que se apoiou em uma pesquisa de dois anos na comunidade do Projeto GNOME. Essa pesquisa resultou então na minha dissertação de mestrado na UFBA, em um dos capítulos do livro "Software Livre, Cultura Hacker e Ecossistema da Colaboração" e agora nesse artigo publicado na Revista Sociologias.

Membros da Comunidade GNOME por Louis Villa

Em termos de publicação, o diferencial então dessa edição v. 16, n. 36 (2014) da Revista Sociologias é o resgate da obra maussiana que fundamentou conceitualmente essa pesquisa sobre o Projeto GNOME - e, agora, serve também de base do meu projeto de Doutorado. Esse resgaste se dá no contexto de surgimento de uma crítica anti-utilitarista dentro do universo das ciências sociais contemporâneas, a qual foi concretizada pela fundação do MAUSS (Movimento Anti-Utilitarista nas Ciências Sociais).

Contudo, vale ressaltar que esse paradigma sociológico da dádiva busca ir além: mais do que a importância da sua vertente analítica, o MAUSS demonstra ser uma corrente sociológica implicada com a produção de pesquisas que se desenvolve a partir de um paradigma basilar, não apenas nas sociedade tradicionais como também para a sociedade contemporânea: a vida associativa e, em especial, a tripla ação de compartilhar, receber e retribuir. Vale então conferir essa edição da Sociologia da Dádiva na íntegra. 

New Features in Picasso

I’ve always been a big fan of Picasso, the Android image loading library by the Square folks. It provides some powerful features with a rather simple API.

Recently, I started working on a set of new features for Picasso that will make it even more awesome: request handlers, request management, and request priorities. These features have all been merged to the main repo now. Let me give you a quick overview of what they enable you to do.

Request Handlers

Picasso supports a wide variety of image sources, from simple resources to content providers, network, and more. Sometimes though, you need to load images in unconventional ways that are not supported by default in Picasso.

Wouldn’t it be nice if you could easily integrate your custom image loading logic with Picasso? That’s what the new request handlers are about. All you need to do is subclass RequestHandler and implement a couple of methods. For example:

public class PonyRequestHandler extends RequestHandler {
    private static final String PONY_SCHEME = "pony";

    @Override public boolean canHandleRequest(Request data) {
        return PONY_SCHEME.equals(data.uri.getScheme());
    }

    @Override public Result load(Request data) {
         return new Result(somePonyBitmap, MEMORY);
    }
}

Then you register your request handler when instantiating Picasso:

Picasso picasso = new Picasso.Builder(context)
    .addRequestHandler(new PonyHandler())
    .build();

Voilà! Now Picasso can handle pony URIs:

picasso.load("pony://somePonyName")
       .into(someImageView)

This pull request also involved rewriting all built-in bitmap loaders on top of the new API. This means you can also override the built-in request handlers if you need to.

Request Management

Even though Picasso handles view recycling, it does so in an inefficient way. For instance, if you do a fling gesture on a ListView, Picasso will keep triggering and canceling requests blindly because there was no way to make it pause/resume requests according to the user interaction. Not anymore!

The new request management APIs allow you to tag associated requests that should be managed together. You can then pause, resume, or cancel requests associated with specific tags. The first thing you have to do is tag your requests as follows:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .tag(someTag)
       .into(someImageView)

Then you can pause and resume requests with this tag based on, say, the scroll state of a ListView. For example, Picasso’s sample app now has the following scroll listener:

public class SampleScrollListener implements AbsListView.OnScrollListener {
    ...
    @Override
    public void onScrollStateChanged(AbsListView view, int scrollState) {
        Picasso picasso = Picasso.with(context);
        if (scrollState == SCROLL_STATE_IDLE ||
            scrollState == SCROLL_STATE_TOUCH_SCROLL) {
            picasso.resumeTag(someTag);
        } else {
            picasso.pauseTag(someTag);
        }
    }
    ...
}

These APIs give you a much finer control over your image requests. The scroll listener is just the canonical use case.

Request Priorities

It’s very common for images in your Android UI to have different priorities. For instance, you may want to give higher priority to the big hero image in your activity in relation to other secondary images in the same screen.

Up until now, there was no way to hint Picasso about the relative priorities between images. The new priority API allows you to tell Picasso about the intended order of your image requests. You can just do:

Picasso.with(context)
       .load("http://example.com/image.jpg")
       .priority(HIGH)
       .into(someImageView);

These priorities don’t guarantee a specific order, they just tilt the balance in favour of higher-priority requests.

That’s all for now. Big thanks to Jake Wharton and Dimitris Koutsogiorgas for the prompt code and API reviews!

You can try these new APIs now by fetching the latest Picasso code on Github. These features will probably be available in the 2.4 release. Enjoy!

Introducing dspec

With all the recent focus on baseline grids, keylines, and spacing markers from Android’s material design, I found myself wondering how I could make it easier to check the correctness of my Android UI implementation against the intended spec.

Wouldn’t it be nice if you could easily provide the spec values as input and get it rendered on top of your UI for comparison? Enter dspec, a super simple way to define UI specs that can be rendered on top of Android UIs.

Design specs can be defined either programmatically through a simple API or via JSON files. Specs can define various aspects of the baseline grid, keylines, and spacing markers such as visibility, offset, size, color, etc.

Baseline grid, keylines, and spacing markers in action.

Given the responsive nature of Android UIs, the keylines and spacing markers are positioned in relation to predefined reference points (e.g. left, right, vertical center, etc) instead of absolute offsets.

The JSON files are Android resources which means you can easily adapt the spec according to different form factors e.g. different specs for phones and tablets. The JSON specs provide a simple way for designers to communicate their intent in a computer-readable way.

You can integrate a DesignSpec with your custom views by drawing it in your View‘s onDraw(Canvas) method. But the simplest way to draw a spec on top of a view is to enclose it in a DesignSpecFrameLayout—which can take an designSpec XML attribute pointing to the spec resource. For example:

<DesignSpecFrameLayout
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    app:designSpec="@raw/my_spec">
    ...
</DesignSpecFrameLayout>

I can’t wait to start using dspec in some of the new UI work we’re doing Firefox for Android now. I hope you find it useful too. The code is available on Github. As usual, testing and fixes are very welcome. Enjoy!