Fábio da Silva Júnior

Fotos da Infra-Estrutura da ThePlanet

FabioJr — Wed, 11 Aug 2010 14:29:44 +0000

Olá pessoal..

Cabeamento estruturado "4 the win"

Passando rápido pra deixar o link de um post do blog da ThePlanet com fotos de um de seus datacenters. Muito legal:

Data Centric 2.0

[]s

Tomcat no Nagios

FabioJr — Mon, 02 Aug 2010 21:01:19 +0000

Tutorial básico para incluir o monitoramento do tomcat no nagios.

Na verdade ele faz uma verificação na porta padrão do Tomcat, 8080. Faça as alterações conforme as suas configurações.

Primeiro, editamos o commands.cfg. Adicionamos o comando de verificação:

define command{


command_name    check_tomcat
command_line    $USER1$/check_tcp -H $HOSTADDRESS$ -p 8080
}

Depois, editar o arquivo services.cfg, adicionando o seguinte:

define service{


use                             generic-service
# Aqui pode ser tanto um grupo de servidores
hostgroup_name                  grupoDeServidores
# ou somente um servidor
host_name                       servidorTomcat
service_description             TOMCAT
check_command                   check_tomcat
notification_interval           0
}

Pronto! Só dar reload no Nagios e ser feliz.

[]s

#FISL11 – day 2

FabioJr — Fri, 23 Jul 2010 19:29:49 +0000

Resumo rápido do segundo dia:

Dormimos bem, apesar do quarto não ser muito bom. A cama é pequena e eu fiquei com os pés para fora da cama. Os móveis são antigos e as paredes tem uma textura que deixa o quarto com um aspecto de mal cuidado. Pelo menos o chuveiro é a gás e a água é quente e com bastante pressão.
Hoje o motorista não se perdeu na ida para a PUC. Já é uma vitória.
A primeira palestra do dia foi “SELinux, como tornar um servidor seguro.”. Sinceramente não gostei muito da palestra. O palestrante quis defender tanto o SELinux que chegou a parecer uma palestra patrocinada. Falou só dos pontos positivos e esqueceu de citar um problema sério que o SELinux provoca que é a lentidão do servidor.
Assisti a segunda palestra com a Vanessa. O assunto era “Mulheres e o Software Livre”. Essa já foi um pouco melhor, mas foi mais uma mesa redonda do que palestra.
Depois fui assistir uma palestra sobre o nginx, o 3º webserver mais utilizado. Quem deu a palestra foi o próprio criador do nginx, o russo Igor Sysoev. Não consegui ficar até o final por causa do próprio palestrante e do tradutor. Não gosto muito de assistir palestras com tradução, consigo entender melhor ouvindo o cara falar em inglês mesmo. O problema é que o inglês dele era muito ruim. Assim como eu tive dificuldade de entender o que ele dizia, o tradutor também teve, então as frases saiam sem ordem ou sentido. Um horror.
Aproveitei essa saída para almoçar. Comi só um lanche já q tinha atacado um pacote de bolacha durante a palestra do russo.
As 4 palestras seguintes eu assisti no mesmo auditório. Algumas boas, e algumas não tão boas.
“Segurança e desafios em cloud computing”, do Darlan Segalin, me pareceu muito superficial. Ele se preocupou mais em explicar o que era Cloud Computing e deixou pouco tempo para discorrer sobre o assunto do título da palestra. Uma pena porque o assunto é muito interessante.
“Automação de Datacenter”, com Bruno Marcondes e Eduardo Scarpellini foi ótima. Muitas dicas de aplicativos e tecnologias que serão objeto de pesquisa nos próximos meses. Uma palestra com muito conteúdo mas que não ficou chata.Parabens a todos os envolvidos. Aliás, tenho q parabenizar o estande do IG no FISL.
“Curso Ruby on Rails 3.0 Dia 1″, com Daniel Lopes, foi bem legal também. Ele passou uma introdução da linguagem ruby nos moldes do meu curso de python que ministrei junto com o Ronaldo na última Semana da Computação da UNIVALI.
Detalhe que durante o curso de Ruby, que foi de 2 horas, cochilei um tempo e cheguei a babar de tão cansado que estava. Espero que ninguém tenha visto essa cena.
“Análise Forense de Rede utilizando Software Livre”, com o Rafael Soares Ferreira, também foi muito boa, com várias dicas e assuntos para pesquisar e me aprofundar.
Saindo da sala das últimas 4 palestras, fomos na palestra mais esperada do dia, a do Wietse Venema, o criador do Postfix. Não fiquei até o fim, sai mais cedo porque estava muito cansado. Mas o que eu assisti peguei algumas coisas interessantes, mas nada de novo a pesquisar.
Pegamos um taxi para ir para o Hotel. Mais ou menos 40 minutos da PUC ate o Hotel, e pagamos só R$ 20, que dividimos em quatro pessoas e ficou 5 pra cada um. Taxi é muito barato em POA.
Nosso quarto não havia sido limpo e arrumado, porque algum engraçadinho passou e trocou o aviso da porta de “Arrumar o Quarto” para “Não Perturbe”.
Enquanto limpavam o quarto, fomos jantar. Novamente, pouca variedade, mas melhor que passar fome.

Cheguei no quarto depois de jantar e cai direto na cama. Não consegui postar ontem, por isso estou postando hj. Espero que mais tarde consiga fazer meu resumo de hj.

[]s

FISL11 – Day 1

FabioJr — Thu, 22 Jul 2010 02:14:31 +0000

Resumo rápido do primeiro dia:

Viagem cansativa e muito fria. Chegamos podres e não aguentamos até o fim do dia. Fomos para o hotel as 2 da tarde.
Já na primeira palestra que nós escolhemos, o palestrante não foi, e nós que já estávamos meio desanimados, acabamos desistindo de ir em outras palestras.

Primeira palestra com a @vanessametonini

Fomos visitar o museu da PUC já que não iríamos a outras palestras. Muito legal por sinal.

Globo do Museu da PUC

Almoçamos as 13h no restaurante embaixo do restaurante universitário. Comida muito boa, mas o pessoal da cozinha meio lento. Demoravam pra trazer a comida.
Pegamos a estrada para o hotel as 14:15, e o motorista errou o caminho 3 vezes. Detalhe que ele tinha um GPS, que dizia o caminho em pt-br.

Voltando para o Hotel

Chegamos finalmente no hotel e ainda tivemos que esperar o quarto terminar de ser limpo.
Ficamos meio frustrados com a qualidade do quarto e arrependidos de não ter feito reserva do quarto “luxo”.
Decidimos tentar trocar o quarto e pagar a diferença, mas todos os quartos já estavam ocupados. Agora torcemos por uma desistência para pegar um quarto melhor.
Jantamos no restaurante do hotel, que tem pouca variedade, mas a comida até que é razoável.
Jogamos Wii no quarto do @leuvarus, e depois fomos para o quarto escolher as palestras do dia seguinte. Amanha mais um capítulo do FISL11.

[]s

Email e as habilidades no computador

FabioJr — Wed, 02 Jun 2010 14:01:31 +0000

Tirando um pouco da poeira do meu blog, venho fazer um post rápido sobre uma imagem que li no GoogleReader hj de manhã do Gizmodo.

O que o seu endereço de email diz sobre as suas habilidades com computador?

Habilidades e os emails

Eu uso email do gmail e trabalho com TI. Me considero uma pessoa hábil com o computador. Sô bonito?

Dicas rápidas de SVN

FabioJr — Wed, 07 Apr 2010 18:33:49 +0000

Versão Brasileira, Herbert Richers

Dicas rápidas de svn

Criar um repositório svn (usuário dever o svn):

svadmin create <repositório>

Importar um repositório (usuário dever o svn):

svn import

Exportar repositório:

svn export

Dêem uma olhada no SVNBook.

[]s

Backup, ou vc tem, ou vc não tem!

FabioJr — Tue, 06 Apr 2010 19:40:12 +0000

Esse é o estado deste blog...

Tirando as teias de aranha do blog, venho falar um pouco sobre uma coisa tão importante na vida do SysAdmin, o bendito Backup.

Essa semana surgiu uma pergunta na lista de emails do FreeBSD de um colega que se referia a ferramentas de backup. Sempre achei que para esse tipo de pergunta, não há nada melhor do que passar a experiência vivida adiante. Prontamente dei algumas sugestões a ele, e não fui o único. Dentre as sugestões que foram postadas, estavam: Amanda e backuppc. Nunca utilizei nenhuma ferramenta pronta de backup, então não posso opinar nada sobre elas, mas pelo que meus colegas de lista reportam, parecem ser bem confiáveis.

Duh!!

Minha sugestão a ele foi utilizar as boas e velhas ferramentas nativas dos sistemas *nix: Rsync e tar. Cada caso é um caso, e isso significa que para cada ambiente de servidores, devemos utilizar ferramentas diferentes. Porém, acredito que uma coisa é certa, em quase todos os casos podemos usar rsync ou tar. Simplesmente porque geralmente a solução mais simples é a utilização de ferramentas simples aliadas ao bom senso do Administrador de Servidores.

Combinar Rsync e/ou tar com shellscript por exemplo pode transformar uma ferramenta simples de sincronização/compactação em rotinas complexas completas de backup.

Tá, mas e ai, quando que eu uso um quando q eu uso outro?

Primeiro é preciso entender o que cada um faz. Começamos pelo rsync então.

Rsync

De acordo com o próprio man do rsync, ele nada mais é do que um rápido e versátil copiador remoto e local de arquivos. E realmente é isso que ele faz. Ele compara duas pastas (origem e destino) e verifica se o que consta na origem também consta no destino. Aquilo que não estiver presente no destino, é copiado da origem, bem como se algo for apagado da origem ele também apaga do destino. Isso faz com que as duas pastas fiquem sincronizadas. Tudo que o diretorio-origem possui, o diretório-destino também possui.

Tar

O tar é um compactador de arquivos. Mas ele serve também para gravar dados em fitas DAT por exemplo. Tar é uma ferramenta poderosa e cheia de recursos, que podem atender praticamente toda as necessidades de alguém q deseja uma rotina de backups eficiente e que ocupe pouco espaço. Se é que isso é possível.

Agora q eu sei o que cada um faz, eu posso escolher melhor a hora de utilizar cada um deles. Se eu quiser manter uma cópia fiel dos dados, utilizo rsync entre dois servidores. Se eu quiser guardar os dados em fita ou em outro hd na rede, e quero ter backups de alguns dias atrás, utilizo tar, que compacta os dados e me deixa mais espaço para armazenamento. Ou ainda utilizar o tar para compactar os dumps do banco e utilizar o rsync para sincronizar estes arquivos com outro servidor. Ou eu posso sincronizar os dados em outro servidor, e criar um arquivo compactado com tar e gravar em uma fita (meio neurótico mas muito seguro).

Vai da vontade e da disposição de cada SysAdmin. Criar scripts que realizam o backup automaticamente é a melhor escolha que alguém que lida com servidores pode fazer. Mas tudo claro com muitos testes e verificações de como o script vai se comportar.

Mas lembrando:

” Quem tem 1 backup, não tem nenhum.“

Ou seja, sempre tenha em mente que backups são ferramentas importantes na segurança dos dados, e por isso devem ser feitos constantemente, e se possível em mais de 1 lugar.

[]s

Apagando arquivos antigos com find

FabioJr — Fri, 18 Dec 2009 17:27:39 +0000

Dica rápida para solucionar problemas de espaço em disco. Bom pra utilizar em scripts de backup.

find {diretório onde os arquivos serão buscados} -type f -atime +{dias} -exec /bin/rm -rf {} ‘;’

Ex.: find /var/backup -type f -atime +3 -exec /bin/rm -rf {} ‘;’

Explicando:

Busca em /var/backup, somente arquivos, não pastas, com data de modificação maior que 3 dias, e remove estes arquivos.

[]s

Só pra registrar

FabioJr — Thu, 17 Dec 2009 12:23:33 +0000

Não.. eu não abandonei meu blog… só estou com pouco tempo pra postar, já que essa coisa de ter um blog toma tempo pra gerar conteúdo.

Deixando tudo arrumado pra poder entrar de férias sem maiores preocupações com minhas crias, então to realmente sem tempo.

Quem sabe nas férias consigo gerer conteúdo pra bastante tempo..

[]s

Monitorando Servidores JAVA com JCONSOLE

FabioJr — Wed, 18 Nov 2009 16:13:08 +0000

Vai um café ai?

Um SysAdmin que não utiliza nenhuma ferramenta de monitoramento em seus servidores, está correndo um grande risco. Primeiro por não ter dados mais concretos sobre o desempenho normal de seus “filhotes”. Segundo que ele não pode prever uma falha, já que pode não conseguir visualizar que o número de requisições ao Apache estão crescendo muito rapidamente, por exemplo, ou que o consumo de memória da JVM do tomcat está fora do normal.

Ferramentas de monitoramento é o que não falta no mercado, tanto proprietárias quanto opensource. Entre elas, posso citar: Cacti, Nagios, Munin, Ganglia, Query Analyzer (MySQL – proprietário), Zenoss, etc. Estes são os que eu lembro de cabeça, mas uma busca no Google pode encontrar muitas outras ferramentas. IMHO estatística nunca é demais. Quanto mais dados sobre o desempenho dos servidores que eu cuido eu tiver, melhor será a decisão que eu vou tomar. Tenho meu planejamento para o blog, posts específicos de cada ferramenta que eu utilizo. Espero conseguir fazer todos eles…

Ultimamente tenho trabalho com servidores JAVA. E JAVA, se você não controlar, pode dar muita dor de cabeça, principalmente pelo uso descontrolado de memória. Sem contar que quanto melhor tunado o servidor JAVA estiver, melhor vai ser a performance da aplicação. Como eu precisava de uma ferramenta que me permitisse visualizar o comportamento do servidor, fui atras de alguma q atendesse minhas necessidades. Encontrei o santo JCONSOLE, que já vem com o próprio JAVA. Ele tem tudo que eu precisava. Monitora a memória (Utilização, Garbage Collector, Pool), Threads e Classes.

Para que eu consiga acessá-lo remotamente, preciso adicionar alguns parâmetros na inicialização do meu Application Server. Neste exemplo vou usar o Tomcat, mas acredito que todos os Servlets JAVA aceitem os parâmetros iguais aos que serão apresentados aqui. (Utilizo a mesma configuração no Resin por exemplo)

A configuração consiste em 3 passos:

Setar os parametros na variável CATALINA_OPTS;
Criar os arquivos de controle de acesso jmxremote.access e jmxremote.password
Reiniciar o serviço (tomcat)

1. Setando os parâmetros da variável CATALINA_OPTS:

As opções que vamos incluir nesta variável são:

-Dcom.sun.management.jmxremote # permite o monitoramento da jvm remotamente
-Dcom.sun.management.jmxremote.port=9099 # porta que serviço irá rodar
-Dcom.sun.management.jmxremote.ssl=false # não utiliza SSL
-Djava.rmi.server.hostname=meuservidor.com.br # nome do host

Como aqui eu tenho um script de inicialização do tomcat, eu adiciono estas opções direto no script que fica no /etc/init.d, adicionando a seguinte linha ao script:

CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9099 -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=meuservidor.com.br"; export CATALINA_OPTS

Se você não tiver um script de inicialização, você pode criar e exportar a variável na mão antes de iniciar o tomcat, ou colocar a linha acima no arquivo /etc/enviroment, ou no /etc/profile, notando que o profile só é executado quando o usuário faz login na máquina. Feito isso, vamos a próxima parte.

2. Criando os arquivos de controle de acesso:

Como bom SysAdmin, eu quero que o acesso as informações da JVM tenham acesso restrito. Para isso, vamos criar os arquivos que irão controlar esse acesso. Esses arquivos ficam armazenados dentro do diretório do JAVA, e toda vez q alguma aplicação que está com o jmxremote habilitado utilizar autenticação, ele irá consultar estes arquivos, que são o jmxremote.access e jmxremote.password. Uma informação adicional é que eu posso dizer, utilizando outras opções setadas na variável CATALINA_OPTS, quais arquivos o java deve consultar para verificar as permissões de acesso, mas nesse exemplo, esta opção não vem ao caso.

Então, vamos entrar no diretório onde ficarão armazenados os arquivos de controle de acesso:

# cd $JAVA_HOME/jre/lib/management

E agora criamos os arquivos. O conteúdo do arquivo é tão simples, que podemos utilizar o comando echo para cri-alos, já com o conteúdo desejado. neste exemplo, quero criar dois usuários, um com permissões de leitura, e outro com permissão de leitura e escrita:

# echo "fabio readonly" > jmxremote.access

# echo "fabiow readwrite" >> jmxremote.access

Cuidado com os caracteres “>” e “>>” para não sobrescrever o conteúdo do arquivo no segundo comando. Mesma coisa para o arquivo que armazena as senhas:

# echo "fabio minhasenha" > jmxremote.password

# echo "fabiow minhasenha2" >> jmxremote.password

A permissão destes arquivos deve ser modificada paa 600, portanto:

# chmod 600 jmxremote.access

# chmod 600 jmxremote.password

3. Para completar, reiniciamos o serviço:

# service tomcat restart

# /etc/init.d/tomcat restart

# sh $CATALINA_HOME/bin/shutdown.sh

# sh $CATALINA_HOME/bin/startup.sh

Feito isso, verifique se o tomcat iniciou corretamente, conferindo se o processo foi criado, e dando uma olhada no log:

# ps ax |grep tomcat

# tail -n 100 $CATALINA_HOME/logs/catalina.out

Se estiver tudo ok, você já pode se conectar ao servidor utilizando o jconsole.

PS.: Os dados coletados durante a execução do jconsole, não são armazenados. Portanto, se você desligá-lo, e ligá-lo novamente, os dados obtidos na última execução do programa não estarão mais lá, e a timeline fica vazia outra vez.

[]s