Sonhadores

Poderíamos fazer deste texto um apanhado geral de diversas frases motivacionais, ou resumos de textos grandiosos sobre como obter sucesso, mas nada disso seria eficiente, pois nada nos impede de os ler a qualquer momento. Sendo assim o problema não é encontrar o que pode nos motivar.

É engraçado , mas depois de tanto tempo lendo sobre motivação, sucesso,filosofia e outro diversos assuntos correlatos, cheguei a conclusão de que as pessoas na sua grande maioria não precisam de motivação …elas precisam apenas sonhar.

Levando isso em consideração lhes pergunto:

– Quais são os seus sonhos?

Esta possivelmente é a etapa mais critica deste texto pois caso você não tenha “na ponta da mente” o que você almeja, é provável que esteja andando em círculos na sua vida.

Os sonhos nos servem de combustível para podermos passar por todas as dificuldades, muitas dessas, criadas por nós mesmos.

Portanto separe algum tempo da sua vida agitada e reflita sobre os seus sonhos.

Outro erro básico que cometemos freqüentemente é:

. Nossos sonhos são pequenos…extremamente pequenos

E posso explicar isso de forma prática e muito simples:

Imagine que seu sonho é comprar um carro e que esse carro seja uma Parati 95… Com certeza esse é um sonho pequeno, mas vamos seguir o raciocínio…por ser pequeno demais, qualquer problema que você tiver durante o período em que estiver se esforçando para realizar este sonho causará um grande impacto no resultado final. Vamos adicionar à essa receita :

– os dias em que você fica um pouco desanimado
– sem forças
– doente
– com preguiça

Enquanto isso o tempo passará e o resultado final será, provavelmente, esse: você

– Compra um fusca 72.

Quando sonhamos muito alto é possível que alcancemos tudo que queremos, porém quando algo de errado acontece temos certeza que mesmo assim alcançaremos algo grandioso.

Problemas com certeza ocorrerão durante o percurso e é por isso que existe uma regra principal para você não desanimar nunca, e ela é muito simples:

– Mentalize claramente como é sentir o gosto do seu sonho realizado.

Guarde essa imagem com você e sempre que você pegar-se desesperado ou desmotivado para ir a luta…. Lembre-se da mentalização que você fez, de você mesmo vencendo e muito provavelmente você não se deixará abater pelo problemas que os esperam.

Sonhando você trilhará os caminhos corretos da vida e servirá de exemplo para as pessoas próximas à você, pois é disso que o mundo precisa … De sonhadores!!!

Monitorando Mysql – Nagios & Munin

Monitorando o Mysql

Administrar uma estrutura baseada em LAMP demanda de muito monitoramento e análise de gráficos de performance. Ferramentas como Munin e Nagios são grandes aliados nesta tarefa e funcionam muito bem , experiência própria 🙂 . A versão do pacote munin-node distrbuída no repositório EPEL , para sistemas Red Hat like, conta com um plugin de monitoramento para o Mysql, plugin esse que permite um monitoramento muito abrangente do Banco de Dados. Este post será dividido em 2 tópicos, um descrevendo como fazer o monitoramento utilizando Nagios, e outro utilizando o Munin.

Nagios monitorando o Mysql

Por padrão a instalação do Nagios conta com um plugin de monitoramento do Mysql , porém mesmo assim, utilizo um plugin chamado “check_mysql_health” , disponível no link: http://labs.consol.de/lang/en/nagios/check_mysql_health/  .  Este plugin consegue monitorar diversas variáveis obtidas através do próprio Mysql , como pode exemplo:

connection-time
tmp-disk-tables
slave-lag

dentre muitas outras . Caso você tenha ficado curioso e queira saber onde o Mysql guarda essas informações utilizadas pelo check_mysql_health , conecte em seu Mysql Server e execute:

SHOW GLOBAL STATUS ;

Este comando irá gerar uma saída extensa, você pode , utilizando uma ferramenta como o Mysql Query Browser, exportar o resultado do comando acima para um CSV e analisá-lo. Com essas informações, é hora de preparármos o plugin para a sua utilização, a minha sugestão é que você tenha uma máquina virtual separada para fazer a compilação deste plugin, sendo quue bastará copiar o executável gerado para os servidores que vocẽ pretende monitorar. Feita essa consideração, vamos à parte prática, na tua VM (tá bom, se não quiser usar VM , faça isso direto no servidor, mas depois não diga que eu não avisei) :

cd ~

wget http://labs.consol.de/wp-content/uploads/2010/10/check_mysql_health-2.1.3.tar.gz

tar xvf check_mysql_health-2.1.3.tar.gz

cd check_mysql_health-2.1.3

./configure –prefix=/usr \
–with-perl: /usr/bin/perl \
–with-statefiles-dir: /var/tmp/check_mysql_health \
–with-nagios-user: nagios \
–with-nagios-group: nagios \
–with-mymodules-dir: /usr/lib/nagios/ \
–with-mymodules-dyn-dir: /usr/lib/nagios/

Vale lembrar neste momento que:

– É possível que o usuário/grupo utilizado em teu servidor de monitoramento não seja nagios/nagios ;

– Caso a arquitetura do teu sistema operacional seja 64 bits, os plugins do Nagios estarão em : /usr/lib64/nagios/plugins

Ao executar o processo de configuração do check_mysql_health , execute:

make

Após executar este comando , o plugin estará disponível no seguinte diretório “~/check_mysql_health-2.1.3/plugins-scripts” , o script é : check_mysql_health . Se este arquivo existir, posso dizer que estamos na metade do caminho para termos o monitoramento funcionando. Para que o monitoramento funcione corretamente, adicione um novo usuário no Mysql que será responsável por obter informações do monitoramento, para isso execute os comandos abaixo:

# Mysql Master

mysql -u root -p
GRANT SELECT ON *.* TO ‘<USUARIO>’@’localhost’ IDENTIFIED BY ‘<senha>’;
FLUSH PRIVILEGES;

# No Mysql Slave

mysql -u root -p
GRANT SELECT,SUPER,REPLICATION CLIENT ON *.* TO ‘<USUARIO>’@’localhost’ IDENTIFIED BY ‘<senha>’;
FLUSH PRIVILEGES;

DICA: Ainda é possível adicionar a seguinte restrição “WITH MAX_USER_CONNECTIONS 5;” para restringir a quantidade de conexões feitas pelo usuário de monitoramento. Encontrei esta informação em : http://blog.wl0.org/2010/09/careful-how-you-monitor-mysql/ .

Logado no servidor Mysql que será monitorado, instale as dependências para a execução do script copie-o para a pasta de plugins do Nagios:

yum install perl-Class-DBI perl-Math-BigInt-GMP perl-Cache perl-Cache-Cache perl-DBD-MySQL

# Em sistemas 64 bits:

cp check_mysql_health /usr/lib64/nagios/plugins

# Em sistemas 32 bits

cp check_mysql_health /usr/lib/nagios/plugins

Agora que o script encontra-se no seu diretório, altere as configurações do NRPE “/etc/nagios/nrpe.cfg” , adicionando as linhas abaixo:

#  Mysql Master

command[check_mysql]=/usr/lib64/nagios/plugins/check_mysql -H localhost -u <USUÁRIO> -p <SENHA>
command[check_mysql_connection]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode connection-time
command[check_mysql_uptime]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode uptime
command[check_mysql_log_waits]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode log-waits
command[check_mysql_table_lock]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode table-lock-contention
command[check_mysql_index_usage]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode index-usage
command[check_mysql_tmp_table]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode tmp-disk-tables
command[check_mysql_slow_queries]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode slow-queries
command[check_mysql_long_procs]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode long-running-procs

# Mysql Slave

command[check_mysql]=/usr/lib64/nagios/plugins/check_mysql -H localhost -u <USUÁRIO> -p <SENHA>
command[check_mysql_connection]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode connection-time
command[check_mysql_uptime]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode uptime
command[check_mysql_log_waits]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode log-waits
command[check_mysql_table_lock]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode table-lock-contention
command[check_mysql_index_usage]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode index-usage
command[check_mysql_tmp_table]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode tmp-disk-tables
command[check_mysql_slow_queries]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode slow-queries
command[check_mysql_long_procs]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode long-running-procs
command[check_mysql_slave_io]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode slave-io-running
command[check_mysql_slave_running]=/usr/lib64/nagios/plugins/check_mysql_health –username <USUÁRIO> –password <SENHA> –mode slave-sql-running
command[check_mysql_slave_lag]=/usr/lib64/nagios/plugins/check_mysql_health –warning 60 –critical 240  –username <USUÁRIO> –password <SENHA> –mode slave-lag

Não se esqueça de reiniciar o NRPE após realizar as configurações citadas acima. Caso o NRPE esteja sendo executado via XINETD, execute “service xinetd restart” ou caso ele esteja sendo executado como daemon do sistema, execute “service nrpe restart” . Abaixo um exemplo de como o Nagios irá exibir os monitoramentos configurados acima:

Munin monitorando o Mysql

Atualmente o munin-node distribuído pelo repositório EPEL conta com um plugin muito bacana chamado “mysql_” , este plugin conta com uma série de gráficos. A sua configuração é simples e não exige pós-graduação Sysadmin Master Debugging 🙂 . O primeiro passo é adicionar as credenciais utilizadas pelo munin-node para conectar-se ao Mysql, faça isso editando o arquivo “/etc/munin/plugin.d/munin-node” , e adicionando as linhas baixo:

[mysql_*]
env.mysqlconnection DBI:mysql:mysql;host=127.0.0.1;port=3306
env.mysqluser <USUARIO>
env.mysqlpassword <SENHA>

Como o arquivo alterado terá usuário e senha válido no Mysql , altere as permissões do mesmo para que ninguém roube essas credenciais, faça isso executando:

chmod o-r /etc/munin/plugin-conf.d/munin-node

Para facilitar o processo de configuração deste plugin , criei uma pequena sequência de comandos que serão executados no Mysql Master e no Mysql Slave, abaixo os comandos:

# Mysql Master

graph=”bin_relay_log commands connections files_tables innodb_bpool \
innodb_bpool_act innodb_insert_buf innodb_io innodb_io_pend innodb_log \
innodb_rows  innodb_semaphores innodb_tnx network_traffic qcache qcache_mem \
select_types sorts table_locks tmp_tables”

cd /etc/munin/plugins
for i in $graph ; do
ln -s /usr/share/munin/plugins/mysql_ ./mysql_$i
done

# Mysql Slave

graph=”bin_relay_log commands connections files_tables innodb_bpool \
innodb_bpool_act innodb_insert_buf innodb_io innodb_io_pend innodb_log \
innodb_rows  innodb_semaphores innodb_tnx network_traffic qcache \
qcache_mem replication select_types sorts table_locks tmp_tables”

cd /etc/munin/plugins
for i in $graph ; do
ln -s /usr/share/munin/plugins/mysql_ ./mysql_$i
done

Após executar os comando acima, reinicie o munin-node com o comando: “service munin-node restart” . O Munin gerará diversos gráficos , para ilustrar veja o gráfico abaixo:

É isso galera, espero que este post ajude alguém ! Abraços.

Mysql tmp table – Fast-Post

Bom,

hoje, lendo a documentação do Mysql , me deparei com uma informação interessante, e resolvi compartilhá-la aqui, lá vai….Muitas vezes quando executamos o EXPLAIN antes de uma query, por exemplo:

mysql> explain select * from internalmail

A coluna “Extra” pode exibir o seguinte conteúdo:

Using temporary; Using filesort

Se este valor aparecer, tome cuidado e prepare-se para analisar o que os desenvolvedores estão fazendo 🙂 . De qualquer forma, existe um workaround capaz de amenizar este problema, que é : aumentar o valor da diretiva “tmp_table_size” (http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_tmp_table_size),  ou seja, a diretiva que controla o tamanho máximo que uma tabela temporária pode ter. Vale lembrar, antecipadamente que: se uma tabela temporária em memória , criada pelo Mysql, superar o valor estabelecido nesta variável, a tabela será automaticamente modificada para uma tabela em disco, o que será ainda pior, sendo assim, tome cuidado e observe sempre as variáveis:

Created_tmp_tables / Created_tmp_disk_tables

Estas variáveis são contadores que indicam , respectivamente, quantas tabelas temporarias em memória e em disco foram criadas. ** Para obter estes valores execute no shell do Mysql:

mysql> SHOW GLOBAL STATUS LIKE ‘%Created_tmp%’

Um detalhe que observei apenas hoje está contido no texto abaixo e é o calcanhar de aquiles da configuração das tabelas temporarias :

If an internal temporary table is created initially as an in-memory table but becomes too large, MySQL automatically converts it to an on-disk table. The maximum size for in-memory temporary tables is the minimum of the tmp_table_size and max_heap_table_size values. This differs from MEMORY tables explicitly created with CREATE TABLE: For such tables, the max_heap_table_size system variable determines how large the table is permitted to grow and there is no conversion to on-disk format.

Se você leu o que está escrito acima, perceberá que a variável “max_heap_table_size”, também influencia no comportamento da criação de tabelas temporárias. Bom, agora vamos lá, como alterar esta variável….é simples abra o arquivo de configuração do Mysql e escreva:

tmp_table_size = <VALOR EM BYTES>

Se não quiser utilizar bytes pois não sabe fazer a conversão….utilize a letra “M” que indicará megabytes!

Bom fica ai a dica, espero que ajude algum ser humano ou alienígena !!

Python + MongoDB + Log do Apache

Posso dizer que este post começa do fim para o começo. Então, o fim segue abaixo:

# *-* coding: utf-8 *-*

from pymongo import Connection
from time import gmtime, strftime
import sys
import re

try:
fileAccess = open("/home/erick/temp/access_log","r",1)
except:
print "Falha ao abrir o arquivo"
sys.exit(1)

try:
db = Connection("192.168.1.169").analytics
except:
print "Ocorreu um erro ao conectar-se ao MongoDB"
sys.exit(1)

def mongoInsert(strAcLine):
remote_host, remote_logname, remote_user, date, first_line_request, method, requested_url, http, http_status_code, size_response, time_serve_request, referer , user_agent = strAcLine
db.analytics.insert({ "Remote_Host" : remote_host, "Remote_Logname" : remote_logname, "Remote_User" : remote_user, "Date" : date, "First_Line_Request" : first_line_request, "Method" : method, "Requested_Url" : requested_url, "Http" : http, "Http_Status_Code" : http_status_code, "Size_Response": size_response, "Time_Serve_Request" : time_serve_request, "Referer" : referer , "User_Agent": user_agent })

def mongoValues():
db.analytics.count()
http_st_code = db.analytics.find({"Http_Status_Code" : "304"})
for p in http_st_code:
print p["Ip_Src"]

# Loop que lê linha à linha até o fim do arquivo. OBS: não coloca todas as linhas em memória,
# apenas a linha atual
while file.readline(fileAccess):
strLines = file.readline(fileAccess)
strTemp = re.split(" ",strLines, 12)
mongoInsert(strTemp)

# Abre arquivo para escrita de LOG
logfile = open("/home/erick/temp/log.txt","w")

# Escreve a data no seguinte formado: Tue, 16 Nov 2010 21:02:32 +0000
logfile.write(strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime()) + "\n")

# Faz consulta no MongoDB
mongoValues()

# Escreve a data no seguinte formado: Tue, 16 Nov 2010 21:02:32 +0000
logfile.write(strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime()) + "\n")

# Fecha o arquivo que contém os dados à serem analisados
file.close(fileAccess)

# Fecha o arquivo de log
file.close(logfile)

# Finaliza a execução do script
sys.exit(0)

A proposta do script acima é pegar os dados de um arquivo de log de acesso do Apache e colocá-lo no MongoDB, para que a partir daí seja possível fazer algumas consultas no Banco de Dados. O script acima foi feito por mim apenas para teste e aprendizado, não estou seguindo nenhum padrão.

Os próximos posts irão explicar :

• Como instalar o MongoDB;
• Como instalar a extensão do MongoDB para Python;

MongoDB é alvo dos estudos que venho fazendo nas últimas semanas, espero poder compartilhar com todos o conhecimento que venho adquirindo.

Abraço à todos e até a próxima.

Lighttpd & Apache

Lighttpd & Apache

Bom , demorou mas consegui arranjar um tempo para um novo post. Espero que eu consiga arranjar mais algum tempo para postar aqui as coisas que venho testando e estudando.

A proposta deste post é possibilitar que o leitor consiga utilizar o Lighttpd para fornecer conteúdo estático aos seus usuários. Além também de tentar ensinar como utilizar PHP com FastCGI. Tenho certeza que esta post está incompleto, mas o que tenho escrito aqui já servirá de um ponto de partida. Em breve atualizarei o post com as referências 🙂 … Lembrando, este post baseia-se em distros Redhat-Like!

Instalando o lighttpd

Para instalar o lighttpd é necessário ativar o repositório adicional EPEL, com o seguinte comando:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

Feito isso execute:

yum install lighttpd lighttpd-fastcgi php

Após a instalação o diretório ”’/etc/lighttpd”’ este diretório conterá todos os arquivos de configuração deste servidor Web.

Ativando os módulos necessários

Assim como o Web Server Apache o Lighttpd vem com uma série de módulos que aumentam o número de funcionalidades, para ativar/desativar
módulos no lighttpd encontre a diretiva ”’server.modules”’ e faça as devidas alterações.Por padrão ative os seguintes módulos:

mod_access
mod_alias
mod_accesslog
mod_compress
mod_expire
mod_fastcgi

Configurando o módulo do fastcgi

Para configurar o módulo do fastcgi no Lighttpd adicione as seguintes entradas ao arquivo de configuração ”’/etc/lighttpd/lighttpd.conf”’ :

fastcgi.server = ( “.php” => ((
“bin-path” => “/usr/bin/php-cgi”,
“socket” => “/tmp/php.socket”
)))

Alterando a porta do Lighttp

Uma alteração importante à ser feita é alterar a porta em que o Lighttpd irá escutar as conexões, para isso, abra o arquivo de configuração do serviço “/etc/lighttpd/lighttpd.conf” , e procure pela diretiva “server.port” , altere o valor desta diretiva para “81” .

Alterações necessárias do Lighttpd

dir-listing.activate = “disable” # Desativa a listagem de diretórios. O padrão é “enable”

Caso o módulo “mod_compress” esteja ativado será necessário configurar as diretivas abaixo:

compress.cache-dir = “/var/cache/lighttpd/compress/”
compress.filetype = (“text/plain”, “text/html”, “application/x-javascript”, “text/css”)

Não devemos esquecer que o diretório de cache do Lighttpd não é criado por padrão, sendo assim é necessário criá-lo:

mkdir /var/cache/lighttpd/compress/
chown lighttpd.lighttpd /var/cache/lighttpd/compress/
chmod 0750 /var/cache/lighttpd/compress/

Feito isso reinicie o serviço:

service lighttpd restart

Configurando o Apache para acessar o Lighttpd

Para que o Apache possa acessar os dados do cliente no Lighttpd devemos ativar no Apache uma configuração de Proxy Reverso
para um diretório em específico, para que essa configuração funcione é necessário ativar os módulos:

proxy
proxy_http

Ativando esses módulos na configuração do Apache

<VirtualHost static-01.domain.com.br>
ServerName static-01.domain.com.br
ServerAlias static-01.domain.com.br

ProxyPass / http://static-01.domain.com.br:81/
ProxyPassReverse / http://static-01.domain.com.br:81
ProxyPreserveHost on
</VirtualHost>

O conf acima fará com que todas as requisições recebidas pelo Apache com destino ao host “static-01.domain.com.br” , sejam redirecionadas para o Lighttpd que está ouvindo na porta 81 .

Acho que com isso o sistema deverá funcionar….

Abraço à todos que lêem essa jabiraca deste blog !

Lighttpd & ApacheObservações Lighttpd:

– Não suporta .htaccess
– Mono thread

Instalando o lighttpd

Para instalar o lighttpd é necessário ativar o repositório adicional EPEL, com o seguinte comando:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

Feito isso execute:

yum install lighttpd lighttpd-fastcgi php

Após a instalação o diretório ”’/etc/lighttpd”’ este diretório conterá todos os arquivos de configuração deste servidor Web.

Ativando os módulos necessários

Assim como o Web Server Apache o Lighttpd vem com uma série de módulos que aumentam o número de funcionalidades, para ativar/desativar
módulos no lighttpd encontre a diretiva ”’server.modules”’ e faça as devidas alterações.Por padrão ative os seguintes módulos:

mod_access
mod_alias
mod_accesslog
mod_compress
mod_expire
mod_fastcgi

Configurando o módulo do fastcgi

Para configurar o módulo do fastcgi no Lighttpd adicione as seguintes entradas ao arquivo de configuração ”’/etc/lighttpd/lighttpd.conf”’ :

fastcgi.server = ( “.php” => ((
“bin-path” => “/usr/bin/php-cgi”,
“socket” => “/tmp/php.socket”
)))

Alterações necessárias do Lighttpd

dir-listing.activate = “disable” # Desativa a listagem de diretórios. O padrão é “enable”

Caso o módulo “mod_compress” esteja ativado será necessário configurar as diretivas abaixo:

compress.cache-dir = “/var/cache/lighttpd/compress/”
compress.filetype = (“text/plain”, “text/html”, “application/x-javascript”, “text/css”)

Não devemos esquecer que o diretório de cache do Lighttpd não é criado por padrão, sendo assim é necessário criá-lo:

mkdir /var/cache/lighttpd/compress/
chown lighttpd.lighttpd /var/cache/lighttpd/compress/
chmod 0750 /var/cache/lighttpd/compress/

Feito isso reinicie o serviço:

service lighttpd restart

Configurando o Apache para acessar o Lighttpd

Para que o Apache possa acessar os dados do cliente no Lighttpd devemos ativar no Apache uma configuração de Proxy Reverso
para um diretório em específico, para que essa configuração funcione é necessário ativar os módulos:

proxy
proxy_http

Ativando esses módulos na configuração do Apache

<VirtualHost static-01.domain.com.br>
ServerName static-01.domain.com.br
ServerAlias static-01.domain.com.br

ProxyPass / http://static-01.domain.com.br:81/
ProxyPassReverse / http://static-01.domain.com.br:81
ProxyPreserveHost on
</VirtualHost>

Instalando o Apache com PHP5

yum install httpd
yum install php-common php-gd php-mcrypt php-pear php-pecl-memcache php-mhash php-mysql php-xml

Alterando a porta da conexão do Apache

vim /etc/httpd/conf/httpd.conf

Procure pela linha que começa com “Listen” e altere a porta para “8080”

Desative as configurações de módulos desnecessários:

cd /etc/httpd/conf.d
mv manual.conf manual.conf.DISABLED
mv perl.conf perl.conf.DISABLED
mv proxy_ajp.conf proxy_ajp.conf.DISABLED
mv python.conf python.conf.DISABLED
mv squid.conf squid.conf.DISABLED
mv webalizer.conf webalizer.conf.DISABLED
mv welcome.conf welcome.conf.DISABLED
mv ssl.conf ssl.conf.DISABLED

Compilando o Varnish para Sistemas RedHat-Like

Command based post:

cd /tmp

# Obtendo o Varnish

wget http://www.varnish-software.com/sites/default/files/varnish-2.1.4.tar.gz

#  Descompacte

tar xvf varnish-2.1.4.tar.gz

# Copia o Varnish compactado para a pasta de source codes

cp varnish-2.1.4.tar.gz /usr/src/redhat/SOURCES

cd varnish-2.1.4/redhat

# Execute o rpmbuild para gerar os rpms

rpmbuild -ba varnish.spec

Depois de algum tempo, os arquivos RPMs serão gerados dentro de “/usr/src/redhat/RPMS” .

# Caso o erro abaixo ocorra

#### top  macro def tmpdir=/tmp/vtc.8121.6b8b4567
#### top  macro def bad_ip=10.255.255.255
#    top  TEST ././tests/v00017.vtc starting
#    top  TEST VCL compiler coverage test: vcc_acl.c
##   v1   Launch
###  v1   CMD: cd ../varnishd && ./varnishd -d -d -n /tmp/vtc.8121.6b8b4567/v1 -p auto_restart=off -p syslog_cli_traffic=off -a ‘127.0.0.1:0’ -S /tmp/vtc.8121.6b8b4567/v1/_S -M 127.0.0.1:33398 -P /tmp/vtc.8121.6b8b4567/v1/varnishd.pid -sfile,/tmp/vtc.8121.6b8b4567/v1,10M
###  v1   debug| storage_file: filename: /tmp/vtc.8121.6b8b4567/v1/varnish.82E3U9 size 10 MB.\n
###  v1   debug| Creating new SHMFILE\n
###  v1   debug| Varnish on Linux,2.6.32-21-server,x86_64,-sfile,-hcritbit\n

…

###  v1   CLI RX  200
#### v1   CLI RX| VCL compiled.
—- v1   VCL compilation got 200 expected 106
#    top  RESETTING after ././tests/v00017.vtc
##   v1   Wait
##   v1   R 8140 Status: 0000
#    top  TEST ././tests/v00017.vtc FAILED
FAIL: ./tests/v00017.vtc

Verifique se o DNS configurado em seu sistema resolve o seguinte endereço:  “10.1.2.” , se o DNS resolver este endereço, então  altere seu servidor DNS para algo como “nameserver 8.8.8.8” e sucesso…

Fonte: http://www.varnish-cache.org/trac/ticket/692#comment:1

Usando o Shorewall

Introdução

Hoje em dia existem muitas ferramentas capazes de configurar regras de firewall em sistemas Linux. Como tudo na vida existem boas soluções para esta finalidade, bem como soluções que são um grande desafio para o sysadmin. Irei abordar neste pequeno artigo como ter o Shorewall (www.shorewall.net), UP and Running. O Shorewall é um pacotes que facilita, padroniza e torna a administração de regras de Firewall baseadas em Iptables muito mais simples , isso acontece pois o Shorewall conta com uma sintaxe de criação de regras própria, sendo assim, mesmo com vários servidores administrados por várias pessoas o trabalho de manter padrões torna-se mais simples. O motivo pelo qual utilizo o Shorewall nas instalações que faço é bem simples: a documentação do projeto é incrível e todas as dúvidas podem ser sanadas com a leitura dos textos produzidos pela comunidade que “toca” o projeto.

Instalação do Shorewall em Sistemas CentOS

A distro que utilizo em meus testes é a CentOS 5.x e particularmente acho uma boa distribuição, muito estável  e segura, para instalar o Shorewall no CentOS é necessário instalar o pacote EPEL, que adicionará ao sistema um repositório com o mesmo nome e que conta com diversos pacotes adicionais que são mantidos por uma comunidade de colaboradores.  Para instalar o EPEL e o shorewall execute:

su -c ‘rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm&#8217;

yum install shorewall

Após a instalação teremos 2 diretórios que neste instante merecem nossa atenção , são eles :

/etc/shorewall -> Este diretório contém as configurações do Shorewall

/usr/share/shorewall -> Este diretório contém os arquivos de macro que serão discutidos mais adiante

Configuração básica do Shorewall

Como já sabemos onde se encontram os arquivos de configuração do Shorewall podemos iniciar algumas alterações nas suas configurações, e o primeiro arquivo que deve ser alterado para que o Shorewall funcione é “/etc/shorewall/shorewall.conf” ,  a diretiva “STARTUP_ENABLED” deve ter seu valor alterado para “Yes“, apenas assim o Shorewall irá iniciar a compilação de suas regras.

O arquivo citado acima conta com várias opções, como:

VERBOSITY

LOGFORMAT

LOGFILE

Ativando o Shorewall na inicialização do sistema

Basta executar….

chkconfig –level <nível de inicialização> shorewall on

Exemplo:

chkconfig –level 3 shorewall on

Testando as configurações do Shorewall

Para ter certeza de que o Shorewall não encontrou nenhum erro nas configurações feitas e para não trancá-lo para fora do sistema existe a opção “try” que irá compilar as regras e aplicá-las, porém com um timeout, sendo assim, caso tudo dê errado depois de um tempo , estabelecido por você, as regras serão removidas do sistema e você poderá voltar a utilizá-lo normalmente. Esta funcionalidade é especialmente útil pois existem situações em que estamos fazendo uma manutenção remota e é necessário verificar se as regras aplicadas realmente estão corretas. Para fazer proceder com este tipo de teste execute:

shorewall try -C shell <diretório dos confs do shorewall> <timeout em segundos>

Exemplo:

shorewall try -C shell /etc/shorewall 120

Bom se tudo deu certo neste momento você não será desconectado do servidor 🙂 , caso tudo tenha dado errado, em 120 segundos você poderá conectar-se novamente.

O que vem depois?

Nos próximos posts irei detalhar os passos para a configuração do Shorewall, o texto acima servirá apenas como base para você mesmo começar os testes. Good Luck !

Para mim um grande exemplo

Desde 2005 acompanho o MMA, e desde a primeira luta que vi até hoje a pessoa que mais admiro neste esporte é o brasileiro Wanderlei Silva. Acredito que este cara seja uma grande estrela e que sabe como passar boas energias para seu público e é por isso que posto aqui um vídeo sobre a cirurgia pela qual ele passou….

Torcendo para que ele levante o cinturão do UFC !!!

Monitorar é preciso…viver não é precico

Breve introdução

Lembro-me claramente que uma vez no Conisli (Congresso Internacional de Software Livre),  há muito tempo atrás, vi uma palestra sobre monitoramento com Nagios, e recordo do sentimento que sentia naquele momento. Eu ouvia as pessoas falando sobre monitorar 100 , 200, 300 servidores e eu me perguntava se um dia eu chegaria naquele nível.

Pois é, muito tempo se passou e cá estou eu, antes eu não tivesse feito essa pergunta…. brincadeira….uma coisa é certa, hoje percebo que tão divertido e satisfatório atuar nessa área que me sinto alegre ao recordar destes momentos em que começava a descobrir como as coisas realmente funcionavam, era algo mágico.

Por que/o que monitorar ?

Bom vamos lá….

– Por que monitorar?

O processo de monitoramento de serviços/servidores é um requisito para a sobrevivência de todos os negócios que dependem de computadores. Ter um sistema que seja capaz de identificar falhas previamente identificadas , como por exemplo partição do disco cheia, é primordial para o bom andamento das empresas e para o sucesso dos negócios.

Outro motivo pelo qual faz-se necessário a utilização de sistemas de monitoramento é a antecipação ao problema, ou seja, é possível estabelecer níveis de criticidade para determinados serviços. Exemplificando: é possível por exemplo gerar alarmes caso o espaço em disco alcance 80% de utilização , sendo assim podemos tomar medidas pró-ativas para evitar que todo o disco seja utilizado e que em decorrência disso o serviço fique indisponível.

Me lembro que na época em que tive a minha própria empresa eu enviava relatórios mensais para nossos clientes comprovando a estabilidade dos servidores/serviços pelo qual nós éramos responsáveis, esse é um outro fator importante, a transparência, este fator é importantíssimo e para mim primordial na relação Cliente x Fornecedor .

– O que monitorar?

Bom a resposta para esta pergunta é muito simples de ser respondida: TUDO !!!

As justificativas para isso são simples:

– Monitorar facilita a tomada de decisões, pois você controla todos os componentes (vamos entender por componentes: serviços, partições, memória, processador), que fazem parte do servidor. É importante que possamos gerar relatórios que indiquem quais componentes do servidor geraram maior número de falha no período de tempo especificado;

– Com monitoramento é possível determinar com maior rapidez qual dos componentes falhou ou está prestes à falhar ;

– Dependendo de onde você trabalhe o monitoramento serve até como um “cala a boca” , que você mostra para o teu gerente 🙂 para mostrar o quão capaz você é …

– Quais ferramentas utilizar?

Vou abordar aqui duas soluções muito conhecidas e utilizadas hoje em dia em diversas empresas , de diversos tamanhos e áreas de atuação:

– Nagios : http://www.nagios.org

– Munin: http://munin-monitoring.org

Apenas para ilustrar quem usa as soluções acima:

– WordPress : Currently we Nagios for server health monitoring, Munin for graphing various server metrics

– Farmville: We use nagios for alerting, munin for monitoring

fonte: http://highscalability.com

Continua…

Instalando a extensão ssh2 no PHP

A extensão ssh2 para PHP permite que conexões à servidores SSH sejam estabelecidas, sendo assim, scripts PHP ganham a funcionalidade de conectarem-se em outros servidores e executem comandos nestes servidores. É possível também utilizar uma função semelhante ao comando “scp”, para a transferência de arquivos.

** Eu não fiz um script que utilize essa extensão, apenas a instalei aqui no ambiente de teste que tenho no meu trabalho. Sendo assim, faltará um exemplo 😦

Geralmente esta extensão pode ser instalada com o comando “pecl” . Caso não saiba onde se encontra o comando execute:

whereis pecl

O comando acima retornará a a localização exata do pecl. Para instalá-lo no sistema execute:

pecl install ssh2

Cas o retorno do comando acima seja parecido com o texto abaixo:

Failed to download pecl/ssh2 within preferred state “stable”, latest release is version 0.11.0, stability “beta”, use “channel://pecl.php.net/ssh2-0.11.0” to install

Cannot initialize ‘ssh2’, invalid or missing package file

Package “ssh2” is not valid

install failed

Você deve executar:

pecl install ssh2 channel://pecl.php.net/ssh2-0.11.0

Se mesmo assim o comando retornar um erro parecido com o texto abaixo:

checking for ssh2 files in default path… not found

configure: error: The required libssh2 library was not found. You can obtain that package from http://sourceforge.net/projects/libssh2/

Significa que devemos instalar algumas dependências para que a compilação possa ser executada corretamente, abaixo os comandos necessários:

yum install libssh2 libssh2-devel

Com os pacotes devidamente instalados é hora, finalmente, de instalar a extensão:

pecl install ssh2 channel://pecl.php.net/ssh2-0.11.0

O processo de instalação será executado com sucesso se uma mensagem semelhante com a apresentada abaixo for exibida:

Build process completed successfully

Installing ‘/usr/local/lib/php/extensions/no-debug-non-zts-20020429/ssh2.so’

install ok: channel://pear.php.net/ssh2-0.11.0

O processo não termina por ai, é necessário ainda ativar esta extensão no “php.ini” , para descobrir onde o arquivo php.ini está localizado execute:

php -i | grep -i “configuration file”

O retorno abaixo deverá ser apresentado:

Configuration File (php.ini) Path => /etc/php.ini

Abra o arquivo para edição e procure a região do arquivo onde as extensões são declaradas, após encontrá-la adicione a seguinte linha:

extension=ssh2.so

Feito isso execute :

php -i

e confira se a extensão está disponível.

Acho que os passo acima são suficientes. Good luck !!