Ir para o conteúdo
ou

Thin logo

Tela cheia Sugerir um artigo
 Feed RSS

Grupo de Usuários Debian da Bahia - GUD/BA

7 de Dezembro de 2009, 0:00 , por Software Livre Brasil - | Ninguém está seguindo este artigo ainda.

Seja bem vind@, se você é um debiano (um baiano que usa debian) faça parte de nossa comunidade!

Fui diagnosticado com um tumor renal, e agora?

31 de Dezembro de 2014, 1:00, por Software Livre Brasil - 0sem comentários ainda

Wall-e sob a tomografia computadorizada

Em 2012 fui diagnosticado com um tumor no rim esquerdo, fiz uma cirurgia e a recuperação ocorreu muito rápida e tranquila. Na época fiz uma busca superficial na internet sobre o assunto e encontrei algumas opiniões bem assustadoras, falavam em quimioterapia, radioterapia e afins. Como nada disso foi necessário em meu caso resolvi compartilhar minha experiência aqui, com o objetivo de deixar um relato positivo sobre o tratamento de tumor renal na esperança de que seja útil para alguém.

Bem, vamos lá… 2012, fazia algum tempo que sofria com pequenas dores de estômago, ao investigar a causa descobri que estava com uma gastrite, fiz o tratamento, resolvi o problema mas as dores continuaram, vários exames depois, dentre eles uma tomografia computadorizada de abdómen, identificou um pequeno ponto no rim esquerdo, este pequeno ponto era um tumor e precisava ser removido.

Neste momento o médico me explicou que o procedimento cirúrgico para remoção do tumor apresentava uma chance de cura de 95%, isto me deixou bastante tranquilo, me explicou que a cirurgia era simples, poderia ser feita por vídeo laparoscopia, e que a remoção do tumor no meu caso tinha grandes chances de preservar o rim, ou ao menos parte dele.

Apesar da cirurgia ter sido um sucesso, fazer tudo isto pelo SUS não foi tarefa fácil, eu não tinha plano de saúde então o SUS era minha única alternativa. Por sorte e por ajuda de alguns médicos consegui chegar ao Hospital Aristides Maltez (HAM), ele é referência em tumores no estado Bahia e faz atendimentos 100% pelo SUS.

O próximo passo foi conseguir marcar uma consulta, no HAM isto não é tão fácil, é muita gente para pouco “hospital”, consegui marcar a primeira consulta após esperar uma manhã inteira na fila. Consulta agendada, voltei ao hospital no dia marcado, mais um turno aguardando para ser atendido, fui atendido e a cirurgia foi marcada para um prazo de aproximadamente 15 dias.

O grande dia chegou, em 31 de Janeiro de 2012 fui internado, a cirurgia ocorreu no dia seguinte, o nome exato do procedimento ao qual fui submetido é Ressecção de tumor retroperitoneal + linfadenectomia retroperitoneal, em algumas horas já estava de volta à enfermaria, um médico residente informou que ocorreu tudo bem e que a previsão de alta era em 48 horas. Dentro do prazo previsto recebi alta, me entregaram algumas amostras do tumor para que fosse solicitado biopsia, marquei a consulta de retorno para 2 semanas depois e fui para casa.

Voltei para a consulta já com os resultados da biopsia em mãos, o médico disse que a cirurgia ocorreu da melhor forma possível, e que as chances de cura eram ótimas, mas o resultado da biopsia deu positivo para maligno, ou seja, o tumor era cancerígeno.

Só neste momento eu me toquei de que tive um câncer. Adimito que sempre tive um certo medo, costumava pensar, não com tanta frequência, mas pensava o seguinte:

Puts! Se um dia eu tiver algum tipo de câncer como é que vai ser, quimio, rádio, etc… Deve ser foda!

E de repente eu tive um, fui curado, e quase nem percebi… Reflito sobre isto de uma maneira bem humorada e tranquila, afinal, ficar angustiado não resolveria o problema.

Apesar disso é importante ser disciplinado e seguir as orientações médicas, cumprir os prazos planejados, e não deixar para “depois”, “depois” e “depois”. O meu caso por exemplo requer acompanhamento anual, repito todo ano exames de sangue, tomografia computadorizada de abdómen e radiografia de tórax. Os médicos dizem que casos como o meu, tumor maligno, há chances do tumor voltar, então é necessário acompanhamento para o resto da vida.

E aqui termino este pequeno relato, desejo sorte para aqueles que estejam passando por situação parecida, tenham tranquilidade, paciência e acima de tudo fé na medicina moderna, ou em qualquer outra coisa que os tranquilize.

Tenho certeza de que vibrações positivas ajudam bastante, e as vibrações dos meus amigos e familiares me ajudaram muito naquele momento, então aproveito este espaço para deixar registrado publicamente um agradecimento especial à todos aqueles que me desejaram sorte e que de alguma forma me enviaram suas boas vibrações.

Obrigado!


Backup na nuvem com Tarsnap

23 de Dezembro de 2014, 1:00, por Software Livre Brasil - 0sem comentários ainda

Chewbacca fazendo backup na nuvem

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.


Voltando a "blogar"

18 de Dezembro de 2014, 1:00, por Software Livre Brasil - 0sem comentários ainda

Han Solo apontando uma arma para Chewbacca

Hoje enquanto conversava com uma amiga no telefone surgiu a seguinte pergunta:

“Por que a gente não posta mais em nossos blogues?”

Ao ouvir isso pensei:

“Humn… Hâmmmn… É porque… Bem… É que…..”

Nenhum argumento minimamente válido surgiu, ou seja, não há motivos, então aqui estou eu “blogando” novamente…

Eu tinha um blog na rede Software Livre Brasil que não via um post desde 2010, na verdade ainda tenho, ele funciona e continuará disponível, mas vou concentar os próximos posts aqui. Mas por que eu saí do Software Livre Brasil? Na verdade não saí, meu perfil continua lá, continarei usando a rede social, e talvez até replique os posts daqui por lá. O que aconteceu foi que a pergunta “Por que a gente não posta mais em nossos blogues?” deu o empurrãozinho que faltava para eu desenrolar as seguintes questões:

E assim aqui está mais um blog nesse mundão virtual, pretendo falar de tudo um pouco, coisas da minha vida pessoal, questões técnicas relacionadas ao trabalho, um pouco da minha experiência no meio acadêmico, música, esportes, livros, etc… Espero que seja útil para mais alguém além de mim mesmo.

Ahhh!!! Dani, obrigado pelo empurrãozinho!


Monitorando JBOSS com Zabbix

11 de Dezembro de 2014, 18:22, por Software Livre Brasil - 0sem comentários ainda

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”.

jboss_logo[1]

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.

Java Gateway ZabbixQuando 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:

zabbixhostjmxinterfaceA 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


New tablet UI for Firefox on Android

3 de Dezembro de 2014, 19:45, por Software Livre Brasil - 0sem comentários ainda

The new tablet UI for Firefox on Android is now available on Nightly and, soon, Aurora! Here’s a quick overview of the design goals, development process, and implementation.

Design & Goals

Our main goal with the new tablet UI was to simplify the interaction with tabs—read Yuan Wang’s blog post for more context on the design process.

In 36, we focused on getting a solid foundation in place with the core UI changes. It features a brand new tab strip that allows you to create, remove and switch tabs with a single tap, just like on Firefox on desktop.

The toolbar got revamped with a cleaner layout and simpler state changes.

Furthermore, the fullscreen tab panel—accessible from the toolbar—gives you a nice visual overview of your tabs and sets the stage for more advanced features around tab management in future releases.

Development process

At Mozilla, we traditionally work on big features in a separate branch to avoid disruptions in our 6-week development cycles. But that means we don’t get feedback until the feature lands in mozilla-central.

We took a slightly different approach in this project. It was a bit like replacing parts of an airplane while it’s flying.

We first worked on the necessary changes to allow the app to have parallel UI implementations in a separate branch. We then merged the new code to mozilla-central and did most of the UI development there.

This approach enabled us to get early feedback in Nightly before the UI was considered feature-complete.

Implementation

In order to develop the new UI directly in mozilla-central, we had to come up with a way to run either the old or the new tablet UIs in the same build.

We broke up our UI code behind interfaces with multiple concrete implementations for each target UI, used view factories to dynamically instantiate parts of the UI, prefixed overlapping resources, and more.

The new tab strip uses the latest stable release of TwoWayView which got a bunch of important bug fixes and couple of new features such as smooth scroll to position.

Besides improving Firefox’s UX on Android tablets, the new UI lays the groundwork for some cool new features. This is not a final release yet and we’ll be landing bug fixes until 36 is out next year. But you can try it now in our Nightly builds. Let us know what you think!