Links Patrocinados vs Usuários mal Intencionados

Configurei ontem uma campanha de link patrocinado para ajudar na divulgação do meu livro, hoje reparei em algo estranho…

# cat access.log | grep gclid | awk '{print $1}' | sort | uniq -c
43 187.13.33.31
1 188.81.4.13
1 189.125.144.27

Pelo que parece o usuário do IP 187.13.33.31 gostou tanto do anuncio que ficou clicando “ad infinito” no meu link patrocinado… estou curioso para ver como o sistema do google vai tratar estes clicks…

Edson

Edit: pelo que acabei de ver no painel do AdWords o google desconsiderou completamente todos os cliques que o IP 187.13.33.31 fez :)

Lançamento do Livro: Status da promoção de gratuidade

O resultado da promoção que fiz hoje para o meu livro “Kindle: Como formatar e publicar seu livro – Um guia passo a passo para iniciantes” foi bastante positivo :)

O livro continua em 1.o lugar na Categoria “Computação, internet e mídia digital” e se tornou o 4.o no ranking geral de livros gratuitos mais baixados na loja brasileira.

rank-AmazonBR-2013-01-07

Um fato curioso é que mesmo sendo um livro em português, ele está com uma boa classificação nos rankings da loja americana, nas categorias que se aplicam a ele:

AmazonUS-20130107

Como o Paulo comentou no outro post, essa classificação prova que ainda tem MUITOS brasileiros que optaram por não migrar suas contas e continuam comprando e-books pela loja Americana :)

Meu muito obrigado a todos que fizeram o download do Livro hoje e a todos que ajudaram na divulgação do mesmo, espero que ele seja útil a vocês.

E não se esqueçam, a promoção de gratuidade vai até o final do dia de amanhã (08/0/2013), se você ainda não pegou a sua cópia gratuita  ainda da tempo ;)

[ ]‘s Edson

Ps. Saiu uma pequena nota hoje no R7.com sobre o livro :)

 

Kindle: Como formatar e publicar seu livro

Neste final de ano gastei algumas boas horas aprendendo a converter livros para o formato suportado pelo Kindle para ajudar o meu sogro na conversão dos livros dele para o formato de e-book :)

Aproveitei o aprendizado para escrever um pequeno livro sobre o assunto, afinal imagino que muitas pessoas tenham curiosidade (ou mesmo vontade) de aprender como publicar um livro, mesmo que em formato eletrônico.

O meu livro foi publicado em formato eletrônico pela plataforma de publicação direta da Amazon na ultima sexta feira, e dei a ele o nome de  ”Kindle: Como formatar e publicar seu livro – Um guia passo a passo para iniciantes“.

A capa do livro pode ser vista na figura abaixo, é uma provisória pois a minha esposa ainda não acabou de fazer o design da capa definitiva, maravilhas do mundo dos e-books, quando ela terminar eu posso mudar a capa sem nenhum problema ;)

Kindle: Como formatar e publicar seu livro

Nele eu abordo de uma forma bem prática todas as etapas envolvidas na publicação de um livro pela plataforma da Amazon tais como, a formatação do documento original, o processo de conversão para e-book, a criação e configuração da conta na plataforma da Amazon e a publicação em si. Os anexos do livro falam rapidamente sobre o processo de obtenção de um ISBN e do registro da sua obra junto ao escritório de direitos autorais.

É um livro pequeno, se impresso o livro teria algo perto de 120 páginas, afinal não era meu objetivo escrever algo que esgotasse o assunto, meu objetivo era explicar de uma forma simples, para qualquer leigo entender, como era o processo de publicação. Ao todo são mais de 80 figuras, que ilustram passo a passo cada uma das etapas.

Fiquei muito feliz hoje quando descobri que o livro, que lancei na sexta feira, era (pelo menos neste final de semana) o livro mais vendido da  loja brasileira da Amazon na categoria “Computação, internet e mídia digital“.

amazon-06012013

Como não sei se isso algum dia vai acontecer de novo, não podia deixar de registrar com um print screen ;)

Para comemorar o sucesso do lançamento, configurei uma promoção no sistema da Amazon e durante todo o dia de amanhã  (07/01/2013 a partir das 08:00 AM) até o final do dia de terça feira (08/01/2013), quem tiver interesse no assunto poderá fazer o download do  livro gratuitamente :)

Se chegarem a ler o livro, seria uma imensa honra receber um review de vocês no sistema da Amazon sobre o mesmo, seja ele positivo ou negativo ele seria MUITO bem vindo.

Críticas e sugestões sobre o conteúdo também serão bem vindas, afinal por se tratar de um e-book sempre existe a possibilidade de se evoluir o conteúdo :)

[ ]‘s Edson

O uso do OpenPGP Smartcard para autenticação “two factor” no OpenSSH a partir do console do FreeBSD

Só hoje me dei conta de que quando publiquei o tutorial sobre uso do OpenPGP Smartcard para autenticação de 2 fatores no OpenSSH, eu não expliquei como fazê-lo de uma maquina FreeBSD.

Abaixo segue um tutorial rápido, para ficar registrado para referência futura:

a) Instale o gnupg a partir da coleção de ports (/usr/ports/security/gnupg) , na tela de opções que aparece antes da compilação habilite o suporte ao pinentry, ao scdaemon e ao curl.

b) Depois de instalar o gnupg você vai precisar ajustar as permissões do device que representa o seu leitor de smartcard no /dev para que o scdaemon possa funcionar de forma adequada com outros usuários que não o root.

Conecte o seu leitor ao seu seu desktop, e execute o comando usbconfig

[root@vm1 ~]# usbconfig
...
ugen0.4: <Smart Card Reader USB OMNIKEY AG> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON

Como podem ver acima, o meu leitor Omnikey Cardman 3201 foi  reconhecido como /dev/ugen0.4 , supondo que eu o usuário com o qual você deseja utilizar o gnupg pertença ao grupo wheel (para que possa usar o su), você deve adicionar as seguintes 2 linhas ao final do seu arquivo /etc/devfs.conf :

# Permite smartcard reader
own  ugen0.4 root:wheel 
perm ugen0.4 0770

Após alterar o arquivo lembre-se de reiniciar o devfs, executando o comando:

[root@vm1 ~]# /etc/rc.d/devfs restart

c) O próximo passo será gerar as suas chaves no gnupg, copiando-as na sequencia para o seu OpenPGP Smartcard, para isto basta seguir os procedimentos descritos neste post anterior.

d) Agora que você já configurou o seu Smartcard, você precisará configurar o gpg-agent para que o seu client ssh possa utilizá-lo no processo de autenticação. Na prática isto é feito executando-se o gpg-agent com algumas opções especificas, e na sequêcia exportar algumas variáveis de ambiente ($GPG_AGENT_INFO, $SSH_AUTH_SOCK, $SSH_AGENT_PID) que irão viabilizar a integração do ssh e do gnupg.
A automação desta configuração irá depender do shell que você estiver utilizando, para o bash a forma mais simples de fazer isso é editar o seu ~/.profile e adicionar a seguinte linha ao final do arquivo:

# Configura o gpg-agent para ser utilizado com ssh, cache de 10 minutos.
# O comando abaixo deve ser digitado em uma unica linha
eval `killall gpg-agent && gpg-agent --daemon --scdaemon-program /usr/local/bin/scdaemon
      --write-env-file --use-standard-socket --default-cache-ttl 600 --enable-ssh-support
      --default-cache-ttl-ssh 600`

Observe que a declaração acima mata o processo do gpg-agent caso ele já esteja rodando para manter o valor das variáveis coerente com o pid atual.

e) Para verificar se o seu cliente ssh está conseguindo se comunicar com o gpg-agent, execute o comando ssh-add com a opção “-l” para listar as chaves privadas que o agente tem acesso.

f) Para visualizar a chave publica RSA da sua chave para que possa adicioná-la a lista de chaves autorizadas nos seus servidores remotos, basta executar o comando ssh-add com a opção “-L”.

Agora basta se conectar normalmente aos seus servidores :)

Ao executar a conexão vc será apresentado a tela do pinentry para que digite o seu PIN:

Após digitar a senha correta a conexão irá proceder normalmente.

Simples, não?

[ ]‘s Edson

 

Como implementar um traffic manager com funcionalidade de failover baseado no Amazon Route53

Muitas vezes temos a necessidade de distribuir o trafego de uma aplicação web entre vários servidores, e por diversos motivos nem sempre é possível fazer uso de balanceadores de tráfego (como o F5 big ip por exemplo), seja por que você não tem acesso a um equipamento destes devido ao seu alto custo, seja porque seus servidores estão geograficamente distribuídos e não seria prudente da nossa parte direcionar todo o trafego para um único site para depois reencaminhá-lo para os demais sites.

Num cenário de servidores geograficamente distribuídos, a melhor (e a mais barata) forma de se implementar um Global Service Load Balance continua sendo o bom e velho Serviço de DNS.

Porém para que possamos usar com segurança o DNS Round Robin para função de distribuição de tráfego é necessário contornar uma série de limitações inerentes deste serviço.

A limitação mais critica é que se um determinado servidor deixar de responder por qualquer motivo, um % dos seus usuários não irá conseguir acessar os seus serviços, de forma que para minimizar o impacto para o seu usuário em caso de indisponibilidade de um dos servidores do pool, você precisará encontrar uma forma de garantir que se um determinado servidor apresentar problemas ele será removido rapidamente do pool de IPs que está sendo resolvido pelo DNS, e a unica forma de fazer isso de forma eficiente é automatizando o processo.

Existem diversas empresas (como por exemplo a Dyn.com) que comercializam serviços de DNS que possuem esta funcionalidade de “Traffic Manager”, infelizmente estas empresas cobram seus serviços pelo numero de queries por segundo (qps) que seu domínio recebe, e isso torna o uso da funcionalidade de “Traffic Manager” extremamente custoso pois a eficiência da funcionalidade de failover é inversamente proporcional ao TTL adotado para os registros DNS que ele está gerenciando, ou seja, quanto menor o TTL maior será o seu QPS e maior será o seu custo.

Logo a unica forma de poder contar com essa automação e manter seu custo baixo é implementar a sua própria solução, afinal não é nenhuma engenharia de foguetes :)

É perfeitamente possível implementar uma solução destas utilizando o bind, porém neste caso teríamos que distribuir nossos servidores de DNS em diversas localidades geográficas e dependendo do volume de QPS que você irá receber o dimensionamento dos servidores pode ser problemático.

A minha sugestão para ter uma rede distribuída e redundante de servidores de DNS para suportar a sua plataforma de Traffic Manager é o serviço Route53 da Amazon AWS.

Para facilitar o uso do Route53 para esta finalidade eu disponibilizei no github um pequeno shell script que eu criei:

https://github.com/ebrandi/route53-failover

O script é bastante simples, mas faz o trabalho sujo ;)

Basicamente você vai ter um arquivo texto chamado ips.master que irá listar os ips dos seus servidores, um por linha, no formato Peso:Endereço_IP, se os seus servidores (e os seus links IPs) forem todos iguais entre si, o Peso deve ser sempre 1, caso vc tenha diferenças de recursos entre os seus sites, ajuste o peso de forma a refletir isso.

O script route53-failover.sh deve ser editado para personalizar as variáveis abaixo, que acredito serem auto explicativas:

  • Hostname: nome do servidor, por exemplo www
  • Domain: dominio completo do sevidor, por exemplo fug.com.br
  • ttl: ttl do registro de DNS
  • ZoneID: ID atribuido pelo Route 53 ao seu dominio quando você criou ele pelo painel de controle
  • AccesskeyID: ID de um usuário com permissão de editar seus registros de DNS
  • SecretAPIKey: Senha do usuário acima
  • fail_host: Ultima instância de failover, é um hostname FQDN e pode ser o hostname de uma instância ELB da Amazon AWS, por exemplo wwwservice–frontend-314203742.us-east-1.elb.amazonaws.com. (o ponto no final é obrigatorio)
  • script_path: diretório onde o script foi está instalado
  • test_file: arquivo do web server no qual o script deve buscar uma string para saber se o web server está normal, por exemplo  status
  • test_string: caracteres que devem existir no arquivo de teste colocada entre aspas, por exemplo “Error 200 OK”

Uma editado o script, basta colocá-lo para rodar no cron no intervá-lo desejado, se precisar rodar numa periodicidade inferior a 1 minuto, lembre-se que um script com “while true” e “sleep”será o seu melhor amigo ;)

O funcionamento do script é simples:

  • Lê o arquivo ips.master
  • Desmembra cada linha no componente peso e endereço IP
  • Conecta no IP do servidor
  • Solicita o test_file e procura pela test_string
  • Se a resposta do servidor contiver a test_string, o servidor é considerado Normal, e o IP dele será gravado no arquivo ips.tmp o numero de vezes definido como peso para este IP no ips.master
  • Se a resposta do servidor não contiver a test_string, o servidor é considerado inoperante, e o IP dele não será gravado no arquivo ips.tmp
  • Caso a busca pela test_string falhe para todos os IPs listados no arquivo ips.master, será gerado um arquivo ips.tmp vazio.
  • Após a sequência de teste dos servidores, o script verifica se o arquivo ips.tmp está vazio ou se possui conteúdo, e se o arquivo gerado na execução atual é igual ou não ao gerado na ultima execução (ips.tmp.old).
  • Sempre que os arquivos forem iguais, o script encerra sem proceder com nenhuma atualização, pois não houve diferença no resultado dos testes, ou seja, todos os IPs que estavam UP continuam UP e todos os que estavam DOWN continuam DOWN.
  • Se os arquivos forem diferentes significa que houve alteração no status dos servidores, e o script irá proceder com a atualização do DNS. Caso o arquivo esteja vazio, o processo de atualização é o mesmo para quando ele possui conteúdo  com a diferença que no caso do arquivo vazio o script irá gerar um registro DNS to tipo CNAME, e no caso do arquivo conter IPs válidos ele irá criar registros DNS do tipo A.

Resumidamente é isso, ou seja, sempre que vc instalar um novo servidor insira o IP dele no ips.master, a partir dai o script se encarregará de colocá-lo no pool do DNS  Round Robin quando o web server estiver funcionando e de tirá-lo caso ele pare de funcionar.  Se tudo der errado e todos os seus servidores pararem, o script irá apontar o seu site para um CNAME que pode ser o ELB do seu site backup na Amazon AWS, ou mesmo para um outro servidor que contenha uma página estática de manutenção.

E o melhor,  tudo de forma automática! ;)

É óbvio que o meu script não está otimizado e muita coisa pode ser melhorada, mas acho que o importante é que ele faz o serviço :)

Uma melhoria necessária é prever no script um tratamento para os casos em que a API do Route53 estiver funcionando, pela logica atual o processo de atualização vai falhar, e na próxima execução como o ips.tmp e ips.tmp.old continuarão iguais, ele não irá fazer uma nova submissão.

Outra melhoria é incluir um lock no processo, de forma que vc não rode o script uma segunda vez caso ele ainda esteja em execução.

Eu planejo fazer estes ajustes quando sobrar algum tempo livre, pull requests são bem vindos ;)

Planejo depois com calma fazer uma versão em php para que vire um módulo para o Pfsense, mas não tenho previsão de quando vou ter tempo de fazer isso.

Espero que o script seja útil para vocês, no mínimo para aprender como não se fazer um shell script ;)

[]‘s Edson

Ps. Se forem usar este script em produção eu sugiro que façam seus próprios testes antes, e usem por conta e risco ;)

O dia das crianças chegou antes: AR.Drone

Primeiro vooO dia das crianças chegou mais cedo esse ano :)

Faz tempo que o Artur queria um “helicóptero”, e achei que um Parrot AR.Drone seria mais divertido, então dei um de presente pra eles…

Ainda na caixa:

Já desembalado:

Segue o video do primeiro voo :)

[ ]‘s Edson