Mnemonic's Fike

Da genialidade à imbecilidade o limite é uma curva

Entendendo um pouco mais sobre containers

| Comments

Se está curioso em saber mais sobre containers Linux, especificamente sobre o Docker e como foi implementado. No blog do DotCloud tem alguns textos do Jérôme Petazzoni detalhando sobre o Docker e como funciona.

Tem um epub deles um menor mas legal de ler.

Containers Linux com Docker

| Comments

Docker é provavelmente o novo buzzword depois do OpenStack (se você lembrar de outro, comenta aí.). O Docker é desenvolvido em Go e usa a Apache License, ele algumas funcionalidades interessantes ao LXC como um repositório público de containers, DSL(Domain-Specific Language) bem simplicado para criar containers e fazer commit (como svn commit ou git commit) das alterações dos containers.

A página de manual do Docker tem uma explicação melhor que a minha.

Docker complementa o LXC, atuando como uma API de alto nível no nível de processo. Ele executa processos unix com forte garantia de isolamento e repetibilidade nos servidores.

O conceito de container é antigo no universo Unix/Linux e várias “implementações”, antes de virtualização ser amplamente usado era muito comum usar chroot para prover isolamento de serviços (BIND, Postfix, etc.). Outros tipos de containers muito usados no Linux são OpenVZ e Vserver mas nenhum deles teve uma adoção em massa tão grande como o Docker. Isso porque ele facilitou muito o trabalho para criar e manter os containers. Essas são alguns razões porque ele tem sido adotado por muitas empresas como: Googe, Red Hat, Baidu, Ebay, Yandex, Spotify, Canonical, etc.

A instalação, atualmente, é bem relativamente simples. A maioria das distribuições Linux suporta de alguma forma. No Debian está disponível nos repositórios oficiais para Sid e Jessie (a próxima versão estável).

Se quiser instalar o Docker no Wheezy (atual versão estável) terá que usar os pacotes mantido pela equipe do Docker e usar o kernel linux acima da versão 3.8. Provavelmente terá que usar o repositório Backports para isso, então terá que acrescentar no arquivo sources.list.

1
2
3
4
5
#echo "http://http.debian.net/debian/ wheezy-backports main non-free contrib" >> /etc/apt/sources.list.d/backports.list

#aptitude update

#aptitude -t wheezy-backports install linux-image-amd64 linux-headers-amd64

Os textos na internet mostram duas formas de instalar no Wheezy, uma usando o Docker empacotado para o Ubuntu e a outra baixando o binário diretamente do site do Docker.

1
#wget https://get.docker.io/builds/Linux/x86_64/docker-latest -O /usr/local/bin/docker

Mais detalhes de como instalar no Wheezy, recomendo ler os textos no Debian Administration.

No Jessie e no Sid, basta instalar via aptitude.

1
#aptitude install docker.io

O restante do texto e outros poderão ser escritos num futuro próximo, será usado como referência o Docker do repositório oficial do Debian.

O Docker tem um repositório público onde qualquer pode disponibilizar container para qualquer um usar. Algumas empresas estão suportando oficialmente seus produtos no Docker (Ubuntu e CentOS). Além dos repositórios oficiais tem uma grande variedade de container disponíveis, pode usá-las para testar softwares ou se confiar no autor do container usá-las para disponibilizar rapidamente um servidor JBoss, MongoDB, PostgreSQL, etc.

Para pesquisar os containers disponíveis é usando o search.

1
2
3
4
5
6
7
8
9
10
11
12
13
$docker.io search postgresql | head -n10

NAME                     DESCRIPTION                                     STARS  OFFICIAL  AUTOMATED
postgres                 PostgreSQL is a powerful, open source obje...   65
paintedfox/postgresql    A docker image for running Postgresql.          30                 [OK]
atlassian/jira           Atlassian Jira image with Postgresql.           11                 [OK]
helmi03/docker-postgis   PostGIS 2.1 in PostgreSQL 9.3                   9                  [OK]
zaiste/postgresql        PostgreSQL 9.2 - https://gist.github.com/z...   8
zumbrunnen/postgresql    PostgreSQL from apt.postgresql.org              6                  [OK]
orchardup/postgresql     https://github.com/orchardup/docker-postgr...   6                  [OK]
kamui/postgresql         PostgreSQL 9.3 with configurable login/dat...   5                  [OK]
tutum/postgresql         PostgreSQL Docker Image – listens on po...      4                  [OK]
[...]

No retorno do comando, alguns campos relevantes são NAME, STAR e AUTOMATED. NAME com “/” é dono do repositório e o nome do repositório, o STAR é o números de pessoas que marcaram como destaque o repositório e AUTOMATED é se o container foi criado automaticamente ou não. Talvez este seja o mais interessante ou “auditável” porque ele é gerado por um arquivo com os passos para criar o container que foi publicado no Github ou Bitbucket.

Se quiser um container usando o Debian como base, tem duas formas. Uma usando o repositório “semi-oficial” e a outra é você usando o debootstrap. Alguns desenvolvedores do Debian não recomendam usar o repositório semi-oficial porque ele está ligeiramente diferente da versão via debootstrap. Recomendo leitura do texto do Joey Hess que tem um ponto de vista interessante.

Pela simplicidade de usar containers com o Docker, pode-se esquecer alguns aspectos de segurança, então é recomendado fortemente ler o texto “CONTAINERS & DOCKER: HOW SECURE ARE THEY?” no blog do Docker e também a página de segurança na documentação oficial

Docker é uma das coisas mais legais que pude me envolver um pouco mais nos últimos tempos mas é importante lembrar que ele não é (e nem pode ser considerado) a nova bala de prata.

Instalando e usando o veewee no Debian

| Comments

Veewee é uma ferramenta para criar templates para o Vagrant, KVMs e outros sistemas de virtualização. Costumo usá-lo para criar imagens com alguns serviços instalados para desenvolver algum sistema ou testar alguma solução/prova de conceito.

Se for instalar o veewee usando Ruby gerenciado pelo rvm, depois da instalação será necessário alterar a versão do ruby no arquivo rvmrc. No momento que foi escrito este texto a versão estável do Ruby é 2.1.2.

Baixando o Veewee

1
$git clone https://github.com/jedi4ever/veewee.git veewee

Instalando…

1
fike@klatoon:~/d/veewee$ bundle install

Uma das despendências do Veewee é o Nokogiri e ele depende da libxml2. Se quiser usar o Nokogiri com a libxml2 empacotado para seu linux terá que reinstalar ele.

1
$gem install nokogiri -- --use-system-libraries

Para este post, o box que será criado é o Debian Wheezy 7.5 32 bits (i386). Outras distribuições Linux ou outros sistemas operacionais com templates disponíveis.

1
$veewee vbox templates

Criando as definições para criar o box para o Vagrant.

1
$veewee vbox define 'debtest' 'Debian-7.5.0-i386-netboot'

No diretório definitions estão scripts de instalação e personalizações. Se precisar de algum modificação da instalação, é aí que deve alterar. Por exemplo, trocar o idioma padrão que será instalado.

1
sed -i 's/en\_US/pt\_BR/g' definitions/debtest/preseed.cfg

Muitas outras modificações podem ser feitas, veja a documentação e veja os scripts que estão nas definições do template.

Criando o vm.

1
$veewee vbox build 'debtest'

Se precisar instalar ou configurar alguma outra que não foi abordado pelos scripts que no diretório definitions, pode entrar via ssh.

1
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 7222 -l vagrant 127.0.0.1

Para verificarse a box está ok.

1
$veewee vbox validate 'debtest

Exportar a box.

1
$veewee vbox export 'debtest'

Com a box pronta é só importar para o Vagrant.

1
2
3
$vagrant init 'debtest'

$vagrant box add 'debtest' '/home/fike/d/veewee/debtest.box'

Fusos horário e etcetra

| Comments

Algum tempo atrás usava um relatório de um serviço em que o se você mudasse fuso horário (timezone) do relatório de GMT (0) para o horário brasileiro. Ao invés de trocar de GMT para GMT -3 e diminuir três horas, na verdade mudava para +3.

Exemplo: Se no Brasil (sem horário de verão e horário de Brasília) fosse 16 horas, GMT seria 19. Mas no relatório apresentava 22 horas.

O detalhe é que na opção para mudar só tinha opção Etc/GMT -3.

Em sistemas Unix/Linux, Etc é um subdiretório (/usr/share/zoneinfo/Etc). Ele serve de referências de fuso horário para regiões não habitadas.

Então, porque usar +3 ao invés de -3?

Aprendi nas aulas de geografia que o estado de São Paulo está no UTC-03:00. Estamos acostumados usar como referência o sinal de menos, exemplo: “Rio de Janeiro está 3 horas atrás (-3) de Londres. Se Londres for 5 horas, o horário no Rio de Janeiro será 2 horas.”. Entretanto isso é um pouco diferente em sistemas operacionais baseados na POSIX.

Na POSIX, os fusos horários que estão do lado Oeste ao GMT tem o sinal positivo (+) e os que estão à Leste tem o sinal negativo (–).

Com o date e a variável de ambiente TZ pode-se brincar um pouco:

date command and TZ variable
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
#GMT
fike@klatoon:~$ TZ='GMT' date
Sex Mai 16 20:35:03 GMT 2014

#UTC -3
fike@klatoon:~$ TZ='GMT+3' date -R
Fri, 16 May 2014 17:35:03 -0300

#UTC +3
fike@klatoon:~$ TZ='GMT-3' date -R
Fri, 16 May 2014 23:35:03 +0300

#Brasil Leste
fike@klatoon:~$ TZ='Brazil/East' date
Sex Mai 16 17:35:03 BRT 2014

#Brasil Oeste
fike@klatoon:~$ TZ='Brazil/West' date
Sex Mai 16 16:35:03 AMT 2014

#São Paulo
fike@klatoon:~$ TZ='America/Sao_Paulo' date 
Sex Mai 16 17:35:03 BRT 2014

#Rio Branco - Acre
fike@klatoon:~$ TZ='America/Rio_Branco' date 
Sex Mai 16 15:35:03 ACT 2014

#Brasil 
fike@klatoon:~$ TZ='Brazil/East+3' date 
Sex Mai 16 20:35:03 Brazil 2014

#São Paulo 
fike@klatoon:~$ TZ='America/Sao_Paulo+3' date 
Sex Mai 16 20:35:03 America 2014

#Cuiaba
fike@klatoon:~$ TZ='America/Cuiaba' date 
Sex Mai 16 16:35:03 AMT 2014

#Cuiaba 
fike@klatoon:~$ TZ='America/Cuiaba+4' date 
Sex Mai 16 20:35:03 America 2014

#Araguaina
fike@klatoon:~$ TZ='America/Araguaina' date
Sex Mai 16 17:35:03 BRT 2014

#Fernando de Noronha
fike@klatoon:~$ TZ='America/Noronha' date
Sex Mai 16 18:35:16 FNT 2014

Para saber quais são as cidades ou regiões que pode usar no TZ, olhe no ”/usr/share/zoneinfo” que tem outros. Para saber todas as cidades brasileiras que são possíveis de usar no TZ, procure no arquivo zone.tab no tzdata que é disponibilizado na IANA. Uma versão dele pode ver na Wikipedia.

Portanto, fusos horários no horário padrão (standard time) que estão à Oeste de UTC ou GMT tem o sinal negativo (–) e os fusos à Leste que estão à Leste tem o sinal positivo. Mas quando você tem que ajustar o fuso horário num sistema Unix/Linux, lembre-se que o sinal é ao contrário; Oeste é positivo (+) e Leste é negativo (–).

Na lista debian-user tem uma thread com uma boa explicação sobre o tema também recomendável ler o artigo na Wikipedia sobre os fusos horários no Brasil (em inglês que é mais datalhado).

Obs. Imagem da Wikipedia, a original pode ser acessada aqui.

Até quando ele irá sangrar?

| Comments

Até quando corações irão sangrar?

Refazendo a pergunta, até quando teremos novidades sobre as falhas do OpenSSL e o Heartbleed? Hoje, talvez, seja a pergunta de um milhão de obamas.

Você, querido (e raro) leitor deve ter visto em milhares de sites o transtorno que o HeartBleed está causando. Pelo impacto causado é provável que seja a maior falha de segurança na era da Internet 2.0.

Resumindo o que pude compilar:

Robin Seggelmann enviou um patch para o OpenSSL implementando a extensão Heartbeat para TLS (RFC 6520)8. Infelizmente com ela foi também entrou a falha que permite capturar as chaves privadas, essa falha foi chamada pelo Codenomicon como HeartBleed.

O xkcd fez um quadrinho interessante sobre a falha.

O bom texto para entender um pouco mais o bug, é ir ao IDGNow.

O patch foi enviado pelo Robin Seggelmann em Dezembro de 2011 e entrou na versão 1.0.1 (Abril de 2012), afetando as versões posteriores até a 1.0.1f. Algumas formas de contornar são atualizar para versão 1.0.1g ou compilar novamente o Openssl usando a flag -DOPENSSL_NO_HEARTBEATS. Se você estiver usando servidor web (Apache, Nginx, etc) e usar SSL para HTTPS, considere gerar novamente os certificados, nos meus testes usando certificado com certificado antigo e o OpenSSL atualizado continuo apresentando problema com Heartbleed.

O impacto é tão significativo que praticamente todos os grandes serviços na internet bloquearam as senhas antigas forçando os usuários gerarem novamente. Na semana passada tinha até uma lista no Github com os sites mais famosos que ainda não tinha atualizado o OpenSSL e os certificados.

Além dos servidores web, outros softwares foram afetados?

Provavelmente sim, ao menos na teoria, todos os softwares que usam TLS estão potencialmente estão vulneráveis. O OpenSSH não foi afetado em princípio (até que alguém provar que sim…), outros serviços que usam somente SSLv3 também não. Entretanto, comenta-se que o Android na versão 4.1.1 tem o Hearbleed e todos os dispositivos que usam o BlackBerry Messenger também foram comprometidos. Não posso deixar de mencionar que também foi anunciado que alguns equipamentos da Cisco e Juniper entraram na lista também. A Oracle listou quais versões de seus produtos foram afetados pelo bug.

Em meio a tempestade a Akamai enviou um patch inicial para o OpenSSL com a intenção de melhorar a segurança no armazenamento das chaves privadas do SSL, entretanto Willem Pinckaers questionou a efetividade do patch. Provável que tenha novas revisões evolutivas do patch até que seja incorporado em defitinitivo no OpenSSL.

Considerando que o Heartbleed está nos servidores web desde 2012, o quanto as senhas e dados de milhões de usuários foram vazados. É impossível contabilizar porque são dois anos em que a falha esteve disponível sem nenhum alarde.

As recomendações no geral são: atualizar o OpenSSL, gerar novamente as chaves privadas e trocar as senhas. Recomendo que daqui um tempo, troque novamente as senhas porque o Hearbleed porque ainda tem muita coisa pela frente. Pelo que a Bloomblerg noticiou, a NSA sabia da existência do bug há dois anos. Quem mais sabia? Provavelmente muitos outros, infezlimente.

O Pessoal do Elastica criou um vídeo explicando como é o HeartBleed.

Isso me lembrou uma outra falha que causou um grande alvoroço e que acidentalmente foi introduzida também no OpenSSL (0.9.8c-1) mas especificamente no Debian e derivados. A falha foi descoberta em Maio de 2008 pelo Luciano Bello e ela comprometeu as chaves SSH, OpenVPN e DNSSEC.

O curioso que até os produtos e os serviços da Microsoft e outras empresas com a cultura de software proprietários não foram afetados e tem muitos “especialistas” alegando que os produtos/sistemas deles são mais seguros. Esse argumento é levemente falso porque o Heartbleed somente teve essa repercussão grande porque o OpenSSL tem uma licença considerada Código Aberto (“Software Livre”). Se o OpenSSL tivesse uma licença como a maioria dos produtos da Microsoft, provavelmente não saberíamos que ele existia.

Algumas pessoas são bem críticas ao OpenSSL, principalmente pela código enorme (200 mil linhas) e de qualidade duvidosa. Ao menos é o que diz o Poul-Henning Kamp, desenvolvedor e Varnish. Recomendo ler o artigo (inglês) na [ACM].

Alternativas?

GnuTLS e PolarSSL são algumas. Se alguém já usou algum em seus projetos, conte a experiência para nós. :)

O pessoal do OpenBSD fez um fork (LibreSSL) e estão fazendo uma pequena faxina no código para que falhas como o Heartbleed tenha pouca probabilidade de acontecer.

O artigo na Wikipedia do Heartbleed é a melhor compilação sobre o bug. Vale a leitura.

Recauchutagem do servidor do PostgreSQL Brasil

| Comments

Algum tempo atrás o servidor (olifante) do PostgreSQL Brasil foi invadido e foi colocado algumas páginas em russo. Também foi instalado um web shell que o invasor pode acessar praticamente qualquer parte do servidor.

Os serviços ativos até então eram: o site do PostgreSQL Brasil, o Planeta PostgreSQL Brasil, as listas de discussão e os sites das Conferências PostgreSQL Brasil.

Até o que o Olifante seja reinstalado, apenas as listas de discussão estão funcionando temporariamente em outro servidor.

É ruim que este tipo de coisa aconteça, entretanto o importante para pensar em como evitar que isso aconteça novamente.

Então, um pouco mais de paciência e todos os serviços estarão novamente no Olifante.

Imagem originalmente postada no Flickr do Eric Schmuttenmaer, o original pode ver aqui.

Videoconf do hangout caindo no Debian

| Comments

Ultimamente tenho participado de muitas reuniões por videoconferência usando o Skype ou Hangout. O Hangout especificamente não estava funcionando direito no meu Debian Sid, ao iniciar a videoconferência, ela caía automaticamente.

Procurando um pouco encontrei no fórum de produto do Hangout pessoas com problema similar e que resolveram removendo o pacote libudev0.

shell
1
#aptitude remove libudev0

Voltando ao mundo das corridas

| Comments

Recuperação de uma lesão nunca é fácil, já mais de um ano que não participava de corridas de ruas e na voltei a correr na corrida de verão do Circuito das Estações no mês de Dezembro de 2013. A intenção era correr sem me preocupar com o pace, meu tempo de corrida, etc. Era apenas correr sem dor.

Aos poucos fui sabotando meu planejamento inicial, esqueci o meu tênis de corrida e fui com um tênis que uso apenas para exercícios na academia. Para acrescentar um pouco mais, cheguei um pouco atrasado, faltando 30 segundos para fecharem a largada para preparem a saída da turma dos 10K que iria sair logo mais. Já pode imaginar que não tive tempo de fazer o aquecimento e nem o alongamento.

A corrida em si foi super tranquila, exceto pela euforia de correr primeiros 2k com um pace abaixo dos 5 minutos (não tenho certeza do meu pace porque esqueci meu relógio de corrida…) e os últimos 3km meu fôlego desapareceu completamente mas ao invés de continuar correndo como se fosse a minha última corrida da minha vida, diminui o ritmo para chegar ao final bem.

Não tenho o tempo oficial porque não tive tempo de pegar o chip da organização para marcação oficial do tempo. Mas não importa, pela minhas contas devo ter fechado os 5km perto dos 30 minutos. Gostei de voltar correr novamente e não sentir o nelson voltar a incomodar. O único efeito colateral foi as dores no dia seguinte por ficar tanto tempo sem treinar.

Sabe porque gosto de correr? Porque posso ter essa vista.

Definitivamente 2014 estou de volta as corridas. :)

Sua nuvem cai?

| Comments

Você acha que Cloud Computing são nuvens bonitinhas como essas?

Ou ela está mais para isso?

Existe um falso mito que hospedar os servidores ou aplicação na nuvem (ou cloud se preferir…). Não é mais necessário se preocupar com problemas de disponibilidade como: geradores de energia elétrica, banco de baterias (nobreak), circuitos redundantes de rede lógica e elétrica, segurança patrimonial, etc. Entretanto ao usar algum serviço de nuvem, você está delegando essas preocupações para outra empresa.

Nesse mês (Dezembro de 2013) muitas empresas que hospedam suas aplicações na nuvem foram surpreendidas porque um datacenter teve uma indisponibilidade do tipo citada acima. O datacenter, bem conhecido, teve um problema de energia elétrica e praticamente tornou indisponível todos os sistemas que estão ali hospedados, dentre eles alguns dos principais fornecedores de cloud e consequentemente todos os clientes deles também tiveram seus sistemas indisponíveis.

Um problema deste tipo num datacenter é difícil de acontecer mas acontece, aconteceu e acontecerá. É como um acidente de avião, são várias pequenas coisas que aparentemente não poderiam derrubar uma avião mas elas encadeadas derrubam. No caso de um datacenter são um conjunto de pequenos incidentes/problemas que podem torná-lo indisponível.

O falso mito que ao colocar uma aplicação/sistema na nuvem, ele nunca ficará indisponível porque na nuvem as coisas funcionam automagicamente é mais comum que possa imaginar. Pense um pouco, todo sistema precisa estar armazenado em algum lugar, se não está na empresa precisa estar em outro lugar mesmo na nuvem. A nuvem (IaaS, SaaS, PaaS, etc) facilita muito porque muito coisa é entregue praticamente pronta e com um pouco de ajuste já é possível disponibilizar um serviço rapidamente. Entretanto mesmo na nuvem, um sistema estará alocada num ou mais datacenters. Portanto ao considerar hospedar seu sistema numa infraestrutura na nuvem, considere pensar no contingenciamento dele.

Veja alguns exemplos de incidentes de indisponibilidades:

Geralmente ao colocar um sistema ou site num fornecedor de nuvem como AWS, a maioria esquece de considerar o contigenciamento no custo operacional. A necessidade somente é percebida posteriormente após uma indisponibilidade como as citadas acima. Uma grande vantagem da nuvem é permitir ter um plano de contingência mantendo quase todos serviços de contingência desligado, mantendo somente o necessário para fazer a sincronização dos dados de um infraestrutura para outra (de uma região para outra no caso do AWS).

Alguns sites adotam como parte secundário do plano de contingência ter as partes principais em cache numa CDN (Content Delivery Network), tendo como o ponto principal da contingência a redundância dos serviços numa região geograficamente distante. Exemplo: Numa região diferente do AWS ou num datacenter numa região diferente no caso da Rackspace.

O caso do Netflix é bem interessante como estudo de alta disponibilidade e contingência usando AWS, leitura recomendadíssima.

Se você estiver considerando migrar suas aplicações para a nuvem, considere um plano de contingência. Se puder, construa a arquitetura de seu site, sistema, aplicação, etc. considerando tecnologias que permitam trabalhar de forma distribuída e com redundância. Afinal, uma empresa com o seu negócio parado pode ser muito custoso do que alocar mais recursos computacionais para melhorar o SLA da sistema que suporta o negócio.

Imagens de Charles Rondeau e MALIZ ONG, elas podem ser encontradas em Public Domain Pictures.

Skype e computadores com duas placas de video

| Comments

Infelizmente uso muito Skype no trabalho e estava com um problema com ele ao participar de videoconferências, ele simplesmente caia (famoso segment fault). Depois de um tempo ele automagicamente voltou a funcionar.

Conversando com o Euler e tentando ajudá-lo a fazer o Skype funcionar, percebi que esse problema acontece em computadores que tem duas placa de vídeos e os drivers do kernel linux estão carregados na memória. Se você está com um problema como esse e tem duas placas de vídeo (no meu caso, a segunda placa é uma Nvidia), pode usar o bumblebee para contornar o problema.

O projeto Bumblebee permite usar a tecnologia Nvidia Optimus. O principal ganho em instalar o bumblebee é melhorar o gerenciamento de energia e ganhar alguns minutos a mais ao usar a bateria do notebook.

Para instalá-lo no Debian é relativamente simples, basta:

shell
1
#aptitude bumblebee

Se quiser executar o Skype pela placa de vídeo Nvidia:

shell
1
$optirun skype