Sobre o novo sistema de avaliação de palestras do FISL

Esse post é uma rant. Nem é tão pela minha palestra não ter sido chamada, é mais pela esquisitisse da coisa.

Para quem não sabe, o FISL mudou a avaliação esse ano. Basicamente, organizaram as palestras em duplas, como se fosse um campeonato, e todo mundo que submeteu palestras ganhou tokens para avaliar 5 palestras, funcionando como um campeonato de Xadrez: você podia escolher qual das duas palestras “ganhava” entre as duas avaliadas, se “empatava” ou ainda podia pular aquelas duas e ir para outras palestras.

Os problemas na minha opinião começam exatamente na opção de ‘pular’ as palestras. Com isso eu pude simplesmente ficar pulando as palestras até cair em uma que eu conhecesse o palestrante ou o assunto e escolhesse aquela. Eu espero que o sistema tenha sido desenhado de forma que todas as palestras recebessem o mesmo número de votos!

O outro problema é que essa forma de avaliação virou um concurso de popularidade. Obviamente as pessoas escolheram palestras de pessoas que conheciam, ou de assuntos extremamente populares mas não necessariamente relevantes.

Alguns exemplos: Se você usa Java, o FISL não vai ser um lugar interessante para você. Das 20 palestras na trilha PHP/Java, só 3 falam de Java. Na trilha de assuntos emergentes, 5 das 10 palestras são sobre Cloud Computing e 2 sobre virtualização (que é bem ali, pregado em Cloud Computing).

Esse efeito parece ser menos acentuado nas trilhas mais especializadas, como a de Kernel e a de Segurança, mas mesmo assim o que se observa é que os assuntos ‘populares’ foram escolhidos a revelia de assuntos que poderiam ser interessantes, mas que os ‘avaliadores’ (palestrantes) não tinham como julgar.

Por exemplo, na trilha de Desenvolvimento (outras linguagens) você tem palestras sobre Javascript, MySQL Stored Procedures e  Shell Script, mas deixaram palestras sobre Clojure, Scala e C de fora. Isso só demonstra que as pessoas que estavam avaliando estavam pensando no pop, não no realmente interessante. Se você analisar bem as trilhas, vai ver que as palestras escolhidas são sempre as que apresentam uma solução (nem sempre nova), enquanto as que são de aprofundamento em algum assunto ou ferramenta são largadas de lado.

Isso vai de encontro ao que se espera do FISL: palestras que mostrem para quem já trabalha na área temas tecnicamente atraentes ou assuntos populares/básicos? Precisamos realmente de tantas palestras de PHP e Cloud Computing, deixando de fora assuntos não populares mas extremamente interessantes? Eu preferiria ver palestras sobre novas linguagens como Scala e Clojure do que MAIS UMA palestra sobre Shell Script, mas aparentemente eu sou a minoria

Acho que é muito bonito isso de ‘democratizar a escolha das palestras’, mas ainda acho que esse tipo de coisa tem de ser resolvida na base de benevolent dictatorship mesmo, ou pelo menos uma forma de garantir que um certo nível de homogeneidade seja mantida.

intel

PS: Claro, a sempre presente palestra “Mulheres e Software Livre” está lá de novo esse ano. É quase uma presença tão garantida quanto o Maddog.

PKI: Indo de Gnomint para EJBCA

Uma das coisas que eu sempre me preocupo em fazer ao chegar em um novo trabalho para lidar com infraestrutura é instalar uma série de serviços para ajudar na administração. Isso inclui wikis, monitoramento, um sistema de tickets de serviço, e por ai vai. Outra coisa é criar uma estrutura básica de PKI para emissão de certificados SSL para servidores e outros serviços.

Gerenciar uma Certificate Authority (Autoridade Certificadora ou CA) pode ser feito de várias formas, desde usando os comandos do openssl na mão, passando por utilizar as facilidades de PKI do Active Directory do Windows e algumas ferramentas gráficas como o Gnomint.

Até a semana passada eu estava realmente usando o Gnomint, mas tive uma série de problemas, principalmente com encoding e com um plano de utilizar essa PKI de forma mais ampla. O Gnomint é ótimo para gerenciar pequenas PKIs, mas quando você pensa em emitir milhares de certificados SSL, vocẽ precisa de algo mais parrudo.

Acabei lendo sobre o EJBCA, que é uma aplicação que roda em JBoss e tem uns usuários bem famosos (incluindo o SERASA, aqui no Brasil). O EJBCA foi então a escolha para gerência da PKI.

A instalação dele no Debian (Lenny) foi bem simples, basicamente porque o pacote JBoss do Debian atualmente não faz porra nenhuma, e você tem de baixar o mesmo do site do JBoss e instalar na mão (isso quer dizer descompactar para algum lugar, eu sugiro o /opt). Algumas coisas que eu fiz e podem ajudar:

Com isso você mata os pré-requisitos do EJBCA. De resto, o guia de instalação dele é bem certinho. Mas basicamente o que você tem de fazer é:

• Dentro do diretório do EJBCA tem o diretório conf, onde você deve copiar o ejbca.properties.sample para ejbca.properties e configurar. Algumas coisas são bem avançadas como por exemplo guardar as chaves e certificados em dispositivos de hardware, mas no meu caso a maioria dos padrões serviu bem.
• Leia o arquivo database.properties.sample e o documento howto databases que tem dentro do /doc do EJBCA. Lá tem os comandos para se criar o banco postgres mas basicamente você cria um usuário ejbca com uma senha qualquer, e um banco com este usuário sendo o owner.

O resto do guia é bem mastigado. Lembre-se que o login na interface administrativa só é feito via Certificado, então depois de instalado não perca o arquivo superadmin.p12 queé gerado na instalação e deve ser importado no seu browser para que se possa acessar a interface.

Dentro do diretório do EJBCA existem também documentos descrevendo a utilização de vários servidores de aplicação diferentes assim como outros bancos de dados.

A outra parte foi mais complicada. Eu tinha de pegar os certificados e as chaves privadas das minhas CAs internas do Gnomint e colocá-las no EJBCA. Seria simples, se o Gnomint exportasse o PKCS#12 direito, mas aparentemente ele faz alguma besteira no formato e o EJBCA dá um erro. A solução foi a seguinte, e pode ser utilizada para migração de várias outras formas de PKI para o EJBCA:

• No Gnomint, exportei separadamente o certificado da minha Root CA para um arquivo e a chave privada da mesma para outro.
• Usando o openssl, criei um arquivo PKCS#12 usando estes dois arquivos, com o seguinte comando:

sudo openssl pkcs12 -export -out rootca.p12 -inkey rootca.key -in rootca.pem -name privateKey

• Isso ai cria um arquivo que o EJBCA alegremente importou como a minha nova RootCA, via interface gráfica, sem estresse.
• Caso você, como eu, tenha de importar CAs subordinadas (sempre uma boa idéia), você tem de repetir o procedimento acima para cada uma (exportar chave e certificado de cada uma), mas tem uma pegadinha: no caso de CAs subordinadas, você tem de incluir no comando openssl a opção -certfile rootca.pem. Porquê disso, você deve perguntar. Porquê sem isso, a cadeia (chain) de certificados fica incorreta no PKCS#12 e quando a Sub CA for importada ela vai aparecer como auto-assinada, e não assinada pela sua Root CA (ou seja, sua cadeia vai ficar quebrada).
• Eu tive de importar também alguns certificados já emitidos para servidores aqui. Isso não é extremamente necessário, mas se não for feito você vai ficar sem uma forma de revogar estes certificados pelo EJBCA futuramente. Existe uma ferramenta chamada bin/ejbca.sh do EJBCA que faz essa importação sem trauma.

Depois disso, só alegria. O EJBCA tem uma interface pública que fica disponível na porta 8080, onde são publicados as CRL (Certificate Revocation Lists) e também onde usuários podem submeter CSRs (Certificate Signing Request) para geração de novos certificados. A interface administrativa roda na porta 8443 e só pode ser acessada por quem tem o certificado correto instalado no browser, e cuida do resto da PKI.

PKIs são dados sensíveis. Você deve ter backups seguros das configurações e principalmente das keychains das suas CAs. Se você perde uma chave ou um certificado Raiz, você perde toda a segurança que ele propõe, e vai ter de re-emitir TODOS os seus certificados. Lembre-se de limitar o acesso a interface administrativa e a própria máquina, várias camadas de firewall são aconselhadas.

A minha PKI roda numa máquina virtualizada, mas eu não aconselho isso para qualquer lugar onde os certificados serão utilizados em funões críticas. Uma máquina virtualizada é altamente mais sucetível a ataques e a roubo de dados (afinal de contas, se roubar a imagem, rouba-se tudo).

O próximo passo é dar uma conferida na integração do EJBCA com LDAP, para ver como fica uma PKI realmente grande e integrada com outros sistemas.

intel

Para ser um Sysadmin

Vendo o formspring do fike eu tentei me lembrar do que um bom sysadmin precisa. Eu e ele terminamos o papo no gtalk, e eis a lista sem uma ordem específica:

1. Sistemas Operacionais e Organização de Computadores (não adianta tentar ser um sysadmin sem ter um amplo conhecimento de como o SO e Hardware funcionam)
2. Rede (mesma coisa ali de cima, e aqui estamos falando daquelas chatices de TCP/IP, cabeçalhos, window size, mtu e tudo mais, não só roteamento)
3. Programação (tem de saber algum shell script, e mais uma linguagem de verdade)
4. Conceito das linguagens utilizadas no ambiente que vai se administrar (java, python, etc…)
5. Banco de Dados (como eles funcionam, transações, locking, particionamento, tuning)
6. Inglês (isso é óbvio)

Mas dai você vai dizer “porra, mas esse monte de coisa?”. Acredite, o seu ambiente vai dar merda e você pelo menos tem de ter conhecimento o bastante para apontar a falha (além de ter de resolver).

intel

(quase) Trocando o Prism por um script de 60 linhas

Quase, mas quase mesmo.

O Prism é o antigo xulrunner da Mozilla. Básicamente é um browser capado para rodar aplicações web em janelas separadas do browser normal. Assim se a aplicação trava você não perde o browser, ou vice e versa. Eu uso bastante para rodar o gmail, o webmail do trabalho e o brizzly. O problema é que o treco é muito bloated. E da uns paus muito bizarros com SSL. E usa Gecko e mais uma estrutura gigante do Firefox por trás que não é bem necessário ao que ele se propõe.

Como o kov é minha musa inspiradora, resolvi dar uma fuçada no PyWebkitGTK e acabei escrevendo uma coisinha semi funcional em 60 linhas de Python . Chamei o script de prisw, tipo, Prism com o M invertido vira W de WebKit. Ta-dã.

A parte mais importante tá aí: ele lê arquivos de configuração e roda em janelas separadas. Eu só não parei de usar o Prism ainda porquê preciso:

1. Colocar o código para que links clicados sejam passados para o OS (eu não quero abrir janelas e urls dentro da mesma app)
2. Tratar o título da janela com relação a mudanças que acontecem no TITLE das páginas (gmail e brizzly fazem isso)
3. Talvez colocar uma opção para mostrar uma barra de status, nem que seja para mostrar se o SSL está ativo
4. Lidar com cookies. Atualmente, mesmo que eu peça para guardar informações de login/etc, essas infos não tem onde serem salvas.

O WebKit que eu estou usando tem alguns probleminhas também com dimensionamento de janela, mas parece que já estão resolvendo no upstream. Daqui umas 2 semanas eu revisito o código e quem sabe eu posso parar de usar Prism, e ainda ganhar as vantagens do WebKit (velocidade, javascript violentamente rápido, etc…).

Aliás, tenho de dizer que optparser e configparser fazem a vida ficar extremamente simples ao se lidar com linhas de comando e arquivos de configuração em python viu.

Sintam-se livres para baixar e fuçar o script, ele é GPL, claro.

intel

Como funciona a parada da Gestão da Porta 25

Baseado nesse post do br-linux e nas dúvidas do povo no twitter, resolvi escrever um post rápido sobre o como funciona. Pode ser que tenha algo faltando ou errado, se tiver avisem nos comentários.

É assim:

Imagine que você tem um email email@longe.cu que fica longe.

Atualmente sua máquina conecta na porta 25 do servidor smtp.longe.cu para enviar email para qualquer lugar. Para isso ele deve pedir uma senha para permitir que você consiga enviar email e fazer relay.

Com a gerência da porta 25, vc não conseguiria fazer isso mais, a porta seria bloqueada. Teria algumas opções:

• Passar a usar SMTP com TLS/SSL que usa a porta 900 e algo.
• Usar um MSA (Mail Submission Agent) do seu provedor de conexão.

Esse MSA basicamente é um servidor que aceita conexões na porta 487, num formato igual ao SMTP mas com alguns relaxamentos de cabeçalho. Esse servidor tem de estar configurado para fazer relay para qualquer lugar do planeta, desde que a conexão venha da rede que ele serve, independente do FROM do email.
Então o seu cliente de correio envia a sua mensagem como você mesmo (email@longe.cu) para o MSA que daí envia ele pra o TO dele.

FROM: email@longe.cu
TO: bleh@gmail.com; bleh@uol.com.br; bleh@longe.cu

O que o MSA faz é enviar via SMTP (e aí entra o MTA) para os MXs responsáveis pelos dominios gmail, uol e longe.cu

Então sua mensagem continua saindo com seu email, da mesma forma de antes, só não vai ser do SMTP do domínio do email, mas isso não faz muita diferença.

Algumas vantagens/desvantagens que eu vejo:

• Os provedores de conexão tem mais controle sobre o que sai na sua rede de SMTP. Evita que faixas inteiras sejam banidas por causa de 1 spammer enviando emails diretamente lá de dentro;
• Até onde eu vi isso quebra SPF;
• Provedores de conexão poderiam bloquear envio de certos tipos de mensagem e etc.

intel