segunda-feira, 4 de julho de 2011

#FISL 12: Automação de processos com software livre #BPM



A palestra sobre automação de processos revelou uma solução que não conhecia, chamada Bonita, e desenvolvida pela Bonitasoft. A solução foi desenvolvida em 2001, e em 2009 foi criada a Bonitasoft que hoje oferece todo o suporte à solução.

O palestrante, Miguel Koren, é funcionário da Konsultex, uma empresa que trabalha com BI, BPM, BCM, ERP e CRM com software livre, utilizando as soluções Bonitasoft, Alfresco, SpagoBI, Openbravo e Opencrx, entre outras.

Ele começou a palestra falando sobre os conceitos de BPM, e disse que na verdade já se fazia BPM há muito tempo, mas com outros termos (TQM, BPR, ERP, Groupware, EAI, CRM, Workflow, SOA), e citou as diversas organizações que regem os padrões desta área (WfMC, BPMI, ABPMP, Workflow Patterns).

Explicou então que o Bonita é uma solução baseada em Java, e composta de três elementos: Bonita Studio (Eclipse), Bonita Engine e UI Management (figura), implementando ainda conceitos de TAD e fornecendo diversos templates para aplicações comuns. Possui ainda conectores para envio de e-mail, acesso a BD, gestão de documentos (GER), Single sign on, compatibilidade com LDAP, integração através de web services e uma infinidade de outros recursos.

A solução permite ainda fazer comparações da execução de processos com diferentes recursos e situações, simulando e ajudando a otimizar o processo.
Acredito que para quem precisa de uma solução BPM, o Bonita é uma alternativa a ser considerada.

Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

#FISL 12: #Debian, inovações e revoluções

Mais uma palestra do Felipe van der Wiel, desta vez sobre as inovações do Debian, listadas a seguir:

  • MultiArch - facilita a integração entre arquiteturas 32 e 64 bits, viabilizando a execução transparente de aplicações 32 bits em ambiente 64 bits, e vai estar disponível na próxima versão.
  • Snapshots - permite acesso a versões antigas de pacotes, para resolver problemas de compatibilidade.
  • Constantly Usable Testing (CUT) - conceito de "rolling distribution", permite a utilização dos pacotes mais novos para aplicações populares sem comprometer (muito) a estabilidade do sistema. Indicado para quem quer sempre as versões mais novas.
  • Debian Archive Kit (DAK) - ferramenta para gestão do repositório de pacotes.
  • DebDelta - vai permitir atualizações incrementais dos pacotes, reduzindo bastante o tempo necessário para concluir o processo.
  • jigdo - disponibilização facilidada de pacotes sem necessidade de baixar ISO completo.
  • Debian Weather - indica o quanto é seguro atualizar a distribuição naquele dia, para diversas arquiteturas.
  • Debian BTS - o Bug Tracking System é a ferramenta usada para o acompanhamento dos bugs na distribuição.
  • Packages QA - Informações sobre pacotes como histórico e outros dados úteis para desenvolvedores e testadores de qualidade.
  • Popcon - análise de popularidade de versões, arquiteturas e pacotes.
  • Debian External Health Status - estatísticas técnicas sobre a distribuição.
  • Patch Tracking System - acompanhamento de patches dos pacotes.

Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

 

#FISL 12: #rrdtool por Tobi Oetiker

Em mais uma daquelas palestras em que me senti fazendo parte da história, vi o "pai da criança" apresentar o rrdtool, uma das ferramentas mais usadas em soluções de gerenciamento ou qualquer aplicação que precise gerar relatórios e gráficos com dados coletados ao longo do tempo. Nas palavras de Tobi Oetiker, o rrdtool é um "banco de dados de séries temporais" (tradução livre).

Mas a apresentação começou com Tobi brincando com um dos seus mais novos experimentos, o "Extopus - The Monitoring Agregator", uma ferramenta que, pelo que entendi, promete agregar todos os dados coletados e gráficos correspondentes numa única interface, evitando aqueles scripts inconvenientes, como o indexmaker do MRTG.

Pesquisando um pouco no site encontrei ainda o Torrus, definido como uma alternativa ao MRTG e outras ferramentas de gerenciamento, contemplando recursos como discovery, alertas, relatórios e coletas via SNMP.

Mas voltando ao foco da palestra, o rrdtool foi apresentado como uma ferramenta de coleta e armazenamento de dados coletados em "séries temporais", otimizado para desempenho, provendo recursos como a consolidação automática dos dados com base nas definições do usuário.

Depois ele demonstrou o que a ferramenta é capaz, com exemplos de configurações e gráficos, mas não deu pra anotar muita coisa, por isso prefiro indicar um dos muitos tutoriais no site dele. Só pra destacar alguns recursos importantes, o rrdtool é capaz de sumarizar automaticamente os dados, permitindo, por exemplo, criar gráficos diários com dados coletados a cada 5 minutos e gráficos semanais com dados coletados/consolidados a cada 6 horas, de forma extremamente eficiente e com previsibilidade do espaço em disco necessário, já que o rrdtool automaticamente sobrescreve dados antigos conforme a necessidade.

Fiquei impressionado com a versatilidade do software, e, embora seja um pouco complicado de entender no início, finalmente posso dizer que sei como o rrdtool funciona, e de repente até me arrisco a usá-lo em lugar do MRTG nas minhas aulas de gerenciamento de redes.


Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

sexta-feira, 1 de julho de 2011

#FISL 12: Testes de invasão em cenários turn-key

A palestra do Fabrício (@leuvarus) e do Odilo (@juniorsbr) foi bem interessante, mostrando como realizar um ataque do início ao fim. Tenho a impressão de que em outras palestras de segurança os palestrantes ficam com receio de mostrar o "caminho das pedras", talvez para não incentivar os "newbies" ou mesmo lamers a sairem por aí atacando sites.

Mas não foi este o caso. Os palestrantes mostraram todas as etapas envolvidas na realização de um ataque, do ponto de vista teórico e prático, usando ferramentas diversas. Vamos ao que interessa:

Passos para a realização de um ataque

  • Varredura para identificação e reconhecimento do alvo;
  • Identificação de vulnerabilidades
  • Verificação de vulnerabilidades
  • Acesso privilegiado
  • Manutenção de acesso
  • Limpeza de evidências

Demonstração do ataque

Para demonstrar a realização do ataque, foram usados os chamados cenários turn-keys, ou pré-programados, que consistem em ambientes prontos para a realização dos testes de invasão (na verdade o termo é utilizado no sentido de algo pronto para ser utilizado, não sendo exclusivo da área de segurança).

Há diversas distribuições prontas para serem "alvos perfeitos", de forma que fica facilitada a montagem de um ambiente em laboratório para a realização dos testes. As citadas foram PwnOS, De-ICE.net, Damn Vulnerable Linux e WebGoat. A distribuição PwnOS foi utilizada como alvo nos testes, cujos passos descrevo a seguir:

  • Feita uma varredura na rede com o NMAP para identificar os hosts e serviços disponíveis e talvez vulneráveis;
  • Identificado o host alvo, foi feita uma varredura detalhada com o NMAP para verificar os software e versões em execução;
  • Feita uma verificação com o Nessus para identificar vulnerabilidades nos serviços em execução;
  • Determinado o serviço a ser atacado para obter acesso, no caso o Apache;
  • Com o ataque ao Apache, obteve informações sobre o sistema como lista de usuários (/etc/passwd);
  • Sabendo usuário, foi usado o Metasploit para explorar falha do webmin, permitindo ler arquivos protegidos (/etc/shadow) do sistema operacional;
  • Usando o Nessus, foi identificada uma vulnerabilidade no OpenSSH que permitiria prever a chave de um usuário;
  • Usando o Metasploit e o exploit do webmin foi lido o arquivo de chaves ssh do usuário;
  • Usando a chave obtida foi localizada a chave privada correspondente, que permitiria logar sem senha;
  • Localizada a chave, logou no sistema alvo sem senha;
  • Usado o Metasploit para explorar falha no kernel para se tornar root;

Obviamente que, melhor do que a minha descrição acima, são as imagens dos programas executados e telas com as informações obtidas, por isso recomendo consultar o site dos palestrantes, onde estão não apenas a palestra, mas outros materiais relacionados: http://www.sclinux.org/fisl12/.

 

Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

 

#FISL 12: #Kanban para #sysadmins e #devops

A palestra mais surpreendente do FISL até agora (e provavelmente até o final do evento) foi a do Felipe (faw -at- debian.org). Ele não falou sobre ferramentas ou tecnologia, mas sim sobre pessoas e processos. E de uma forma muito interessante. Muito mesmo!

Antes de falar sobre o tema da palestra em si, vou fazer um parêntesis rápido pra destacar um ponto importante: o devops. O termo vem sendo usado para indicar os "developers-operators", profissionais que desenvolvem e implantam suas soluções, um perfil que, pelo que estou percebendo, vai ser cada vez mais comum de agora em diante, especialmente por conta da computação em nuvem.

Mas voltando ao tema da palestra, não sei se sou ignorante mas o fato é que nunca tinha ouvido falar desse tal de kanban. O kanban é uma técnica, metodologia, estratégia, sei lá, chame como quiser, para ajudar a estruturar o fluxo de trabalho de equipes. A idéia é bem simples, e o ponto chave é ter uma noção visual deste fluxo.

Esta noção visual pode ser implementada através de um quadro branco, de cortiça, painel ou qualquer meio que permita ver, claramente, como está o fluxo de trabalho das pessoas. O Felipe usou como exemplo um quadro branco, então vamos manter o exemplo. Neste quadro branco, cada profissional da equipe deve colar um post-it com cada atividade que esteja em andamento, assim todos podem saber o que cada um está fazendo, e são realizadas reuniões para analisar as atividades. Mas isto não é tudo. Vou tentar descrever uma sequência para dar uma idéia melhor de como a coisa pode funcionar.

  • Define-se como será criada a noção visual do fluxo de trabalho da equipe (quadro branco, por exemplo);
  • Define-se como cada funcionário deve registrar as atividades (post-it);
  • No mínimo, devem ser criadas duas "áreas" para registro de atividades: pendentes, e em execução;
  • Estabelece-se um limite para as atividades em execução, de forma que uma tarefa só pode sair de pendente para em execução se houver menos tarefas em execução que o limite estabelecido, garantindo que as atividades serão finalizadas, e permitindo identificar atividades que estão demorando muito e podem, por exemplo, requerer mais pessoas envolvidas;
  • O kanban vai registrar apenas atividades com duração significativa, maior que um ou dois dias, por exemplo, de forma a não burocratizar o processo com registros desnecessários de pequenas atividades executadas em minutos ou horas;
  • O kanban não elimina a necessidade de um sistema de registro de solicitações, pois é nele que vão ficar todos os detalhes da realização da atividade;
  • Há ferramentas automáticas e via web para apoiar o kanban, mas a idéia é garantir a noção visual, algo que ficaria bastante prejudicado caso fosse usado um sistema automatizado via web, por exemplo;
  • As reuniões são muito importantes, e sugere-se uma reunião de 5 minutos em pé, diariamente, para avaliar o kanban, com quem estiver disponível, para forçar as pessoas a estarem na reunião no dia e horário definidos;
  • Há ainda reuniões semanais (15 minutos) e mensais para discussões mais detalhadas;

Espero que as informações tenham sido suficientes para dar uma idéia do que é o kanban e como ele funciona.

O Felipe explicou que, na empresa em que trabalha, uma rede hospitalar, o kanban foi implementado com 4 áreas (piscina de idéias, fila limitada de 7 itens, itens em execução limitados a 2 itens e documentação limitada a 3 itens), ainda não surtiu o efeito desejado, havendo inclusive um funcionário extremamente resistente que tem dificultado o processo.

Apesar disso, o Felipe descreveu casos em que a adoção do kanban aumentou drasticamente a eficiẽncia de equipes de TI em outras empresas, e indicou que os resultados começam a aparecer entre 3 e 6 meses.

Outros pontos importantes destacados foram:

  • No início da implementação, devem ser registradas todas as atividades em andamento, e portanto pode ficar inviável criar limites para tarefas pendentes, em execução ou documentação, por exemplo;
  • Cada implementação do kanban é única, pois depende da adaptação do modelo à realidade de cada empresa;
  • O kanban tem diversos benefícios, entre eles a forma simples de fornecer a toda a equipe a visão clara das atividades pendentes e em andamento;
  • Pode ser necessário segmentar por área de atuação, por tempo (escalada hierárquica) ou mesmo por pessoa, caso a equipe tenha duas atribuições muito separadas. 

Eu achei a idéia muito, muito interessante, e espero um dia poder aplicar este modelo pra ver seu funcionamento mais de perto, pois acredito muito nos benefícios que pode trazer. Espero que vocês acreditem também!

Mais informações podem ser encontradas no sysadvent.

Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

#FISL 12: #Zabbix, Zabbix, Zabbix

Parece que o Zabbix está se tornando "a" solução livre para monitoramento de ambientes. Todas as palestras que tocavam no assunto monitoramento usavam o Zabbix como exemplo, e duas palestras foram especificamente sobre a ferramenta.

Gestão e monitoramento de redes e dispositivos com Zabbix

A palestra do Rafael (@gomex) foi bem didática, mostrou como configurar hosts, itens, triggers e actions, e contou com a presença ilustre do criador da ferramenta, Alexei Vladishev, o que deixou o palestrante bem nervoso. Calma, Rafael!

A idéia do Zabbix é ser uma solução robusta para monitoramento de "qualquer coisa", da mesma maneira que o Nagios (reconhecido por sua versatilidade), porém sem problemas como a ausência de uma interface nativa para facilitar a configuração, que muitas vezes depende da edição manual de diversos arquivos.

A palestra mostrou como o Zabbix oferece uma plataforma excelente para monitorar ambientes de diversos portes, e aponto a seguir as razões para isso:
  • Interface web consistente e funcional;
  • Autodiscovery;
  • Templates que facilitam a configuração do monitoramento de muitos itens;
  • Agente poderoso que permite monitorar qualquer informação que possa ser coletada nativamente ou via script;
  • Possibilidade de monitoramento agentless, via SNMP;
Experiência da Dataprev com ferramentas de monitoramento

A pesar do termo ferramentas, a palestra abordou apenas o Zabbix e as "peripécias" do pessoal da Dataprev, que fez algumas coisas bem legais. É verdade que não vi a palestra desde o início, então posso estar enganado, mas acredito que não.
O Elemar deu várias dicas interessantes, que listo a seguir:
  • Evitar o uso dos user-parameters pois podem causar degradação do desempenho no monitoramento;
  • Configurar o agente no modo ativo, onde são relacionados os itens que devem ser monitorados e a periodicidade, e o agente se encarrega de tudo, sem a necessidade do servidor solicitar as informações;
  • Usar o zabbix-sender para enviar ao servidor as informações coletadas de maneira otimizada;
Foi demonstrado também como monitorar a temperatura do datacenter com uma série de termômetros baratinhos ("made in china"), permitindo identificar até o fluxo de pessoas a partir da variação de temperatura, e ainda o monitoramento de scripts de backup e aplicações web (usando o jmetter).

Conclusão

Coincidentemente, estas palestras vieram num momento em que estamos rediscutindo os processos e ferramentas que utilizamos para monitorar nosso ambiente, assim acredito que já temos um caminho a seguir.
Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!

#FISL 12: #Joomla! como plataforma de desenvolvimento de soluções

A palestra do Emerson (@fititnt) prometia, mas acabou sendo decepcionante. Ele iniciou dizendo para aqueles que estavam interessados em aprender a programar com o Joomla! que ali não seria o lugar. Mas o nome da palestra sugeria o contrário! Além disso, ele se perdeu na condução da palestra, e acabava enveredando por assuntos meio fora de contexto, chegando a afirmar a pérola "fazer um cego ver um site" ou algo assim, se referindo à necessidade de acessibilidade nos portais do governo.

De todo modo, a mensagem que ele passou foi interessante. Ele deixou claro que, além de CMS, o Joomla! é um framework de desenvolvimento MVC, e que isso pode ser utilizado independentemente do CMS, e esta característica seria destacada na versão 1.6 que saiu há pouco tempo.

Tenho também que destacar que a palestra traz uma idéia muito importante embutida, a de que precisamos olhar com mais atenção para as soluções que utilizamos em nosso ambiente. E isso independe de ser uma solução livre. O fato é que tendemos a buscar a solução para problemas novos em soluções novas, o que nem sempre é necessário.

Vou exemplificar utilizando a realidade do órgão em que trabalho. Hospedamos um portal nacional que era composto de diversas soluções de colaboração, e que hoje é baseado em Joomla! com extensões. Tenho certeza de que hoje as necessidades dos usuários do portal são melhor atendidas que antes. Inclusive esta mudança teve a ver justamente com a identificação, pelo departamento responsável pelo portal, das vantages de "desenvolver" em cima do Joomla! e usar extensões ao invés de utilizar produtos separados que já apresentavam problemas. Daí meu grande interesse pela palestra.

 

Não costumo criticar palestrantes, ainda mais publicamente, mas tenho certeza que outras pessoas ficaram tão ou mais decepcionadas que eu, por isso fica aqui também como desabafo. Acredito que o Emerson conhece de Joomla!, estou inclusive seguindo o perfil dele no twitter, mas na palestra ele mandou mal.

Siga-nos no Twitter! ou Buzz
Receba os textos via e-mail ou RSS!
Confira outros textos sobre o tema!