terça-feira, 29 de abril de 2014

Relatórios de estatísticas do Postfix com PFLogSumm

O servidor de e-mails atualmente é um dos recursos mais importantes de uma empresa. Sem ele vendas podem ser perdidas, a produtividade de todo um time pode diminuir, etc. Ou seja, um servidor de e-mails parado pode custar muito dinheiro para a sua empresa e, talvez, até o seu emprego.
Por isso, é importante saber em detalhes o que passa pelo seu servidor, quem mais utiliza, qual o tamanho médio das mensagens enviadas, etc. E isso não é obtido com programas como o Nagios, por exemplo.
Neste texto, vou apresentar uma das muitas ferramentas que podem fazer esse serviço para você. Ela se chama PFLogsumm.
 
A Ferramenta
 
O PFLogSumm (Postfix Log Entry Summarizer) é um script desenvolvido em Perl, com o objetivo de fornecer uma visão geral da atividade do Postfix com detalhes o suficiente para que o administrador perceba possíveis problemas. Algumas das características dele são:
  • Número total de mensagens recebidas, enviadas, rejeitadas, etc;
  • Relatório sobre as atividades diárias ou de hora em hora;
  • Resumos de avisos, erros fatais e críticos.
E muito mais detalhes (o relatório para um servidor muito utilizado pode ficar bem grande). Além da grande quantidade de detalhes que a ferramenta fornece, um outro ponto positivo é a estabilidade e facilidade de uso.
 
Exemplos de utilização
 
Para utilizar o PFLogSumm, basta fazer o download do pacote, descompactar e executar o arquivo pflogsumm.pl. Não é necessário instalar. Talvez seja necessário que você instale o módulo Date::Calc para que o programa funcione corretamente, mas provavelmente esta será a única dependência com a qual você vai precisar se preocupar.
O site oficial da ferramenta é o http://jimsun.linxnet.com/postfix_contrib.html. Navegue até a seção “Source & Docs: Production Version” e faça o download do pacote “pflogsumm-1.1.1.tar.gz” (a versão estável mais recente disponível enquanto escrevo este texto). Depois descompacte o pacote em algum lugar e pronto (a máquina onde você vai executar o PFLogSumm não precisa ser, necessariamente, o seu servidor de e-mails).
Por padrão, o PFLogSumm não escreve o relatório em nenhum arquivo. Portanto, você vai precisar redirecionar a saída do comando para o arquivo no qual vai querer que todos os dados sejam gravados. Um relatório de exemplo pode ser gerado com o seguinte comando:
 
# ./pflogsumm.pl /var/log/maillog > /tmp/relatorio-emails.txt

Isso irá gerar o relatório padrão baseado nos dados contidos no arquivo /var/log/maillog (geralmente o log padrão do daemon de e-mails), e já contém muitos detalhes. Ele não irá considerar datas. Se você rotaciona seus logs semanalmente, apenas os dados desta semana serão utilizados para gerar o relatório. Se você quiser gerar um relatório apenas com os dados do dia atual:
 
# ./pflogsumm.pl -d today /var/log/maillog > /tmp/relatorio-emails.txt

Para gerar um gráfico com as informações do dia anterior:
 
# ./pflogsumm.pl -d yesterday /var/log/maillog > /tmp/relatorio-emails.txt

Você também pode especificar mais de um log utilizando a notação:
 
# ./pflogsumm.pl /var/log/maillog /var/log/maillog.1 /var/log/maillog.2 > /tmp/relatorio-emails.txt 
 
Conclusão
 
Claro que existem muito mais opções a serem utilizadas na geração do relatório, adicionando ou removendo detalhes de acordo. Porém, a intenção deste texto é apenas apresentar a ferramenta para que você se aprofunde nela de acordo com as suas necessidades.
Vale lembrar também que o PFLogSumm só gera esses relatórios em texto puro. Com estes dados em mãos você pode tomar as providências necessárias para corrigir os problemas que venha a encontrar.
 
Fonte Autor: http://www.pedropereira.net/gerar-relatorios-de-estatisticas-do-postfix-com-pflogsumm/

quarta-feira, 23 de abril de 2014

Dell OpenManage não faz login (refresh na tela) no CentOS 6.4 [Resolvido]

Problema ocorrido: após atualizar o OpenManage da Dell para a versão 7.3, o sistema não loga mais, apenas dá um refresh na tela de login.

Efeito do problema: o problema ocorre porque alguns caracteres especiais não funcionam na senha desta nova versão.

Os caracteres inválidos, são: % & | ; ' " < >

Para não ser necessário alterar a senha do usuário root usado pelo OpenManage, basta criar uma nova conta de usuário para acessar o OpenManage, conforme descrito abaixo:

1. Criar conta de usuário:

# useradd usuário

Comando padrão:

# useradd dell

2. Modificar a conta para não ter shell válido, dentro do /etc/passwd, editar a conta do usuário dell informando/inserindo a variável nologin, conforme exemplo:


dell:x:501:501::/home/dell:/sbin/nologin

3. Alterar a senha do usuário dell para ativar a conta, com o comando:

# passwd dell

Obs.: a nova senha não poderá conter os caracteres inválidos já ditos acima.

4. Modificar o arquivo de informações de login do OpenManage (/opt/dell/srvadmin/etc/omarolemap) cadastrando o novo usuário dell como administrador. O arquivo sem os comentários deverá ficar semelhante as informações abaixo:

#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
root   *       Administrator
dell    *       Administrator
dell    *       Poweruser
+root   *    Poweruser
*       *       User
#@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

5. Reiniciar o serviços do Dell OpenManage com o comando:

# srvadmin-services.sh restart

Agora, basta acessar novamente o OpenManage que o acesso deverá funcionar com o novo usuário criado.

quinta-feira, 17 de abril de 2014

Instalação do Dell OpenManage no CentOS 6.X

Segue uma dica para quem tem o sistema operacional CentOS instalado em um servidor Dell, e gostaria de obter o gerenciador de hardware da Dell, o OpenManage.

Embora pouco divulgado no site da Dell, existe uma versão para instalação do OpenManage para o CentOS GNU/Linux.

Sendo assim, segue abaixo a dica de instalação.

1. Adicione o repositório abaixo:

# wget -q -O- http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash

2. Instale o Dell OpenManage:

# yum install srvadmin-all

3. Reinicie o servidor, para que possa sincronizar com a BIOS:

# reboot

4. Acessar o Dell OpenManage.

Após boot do servidor, basta acessar o Dell OpenManage via qualquer browser, através do link:

https://IP_DO_SERVIDOR:1311/

Obs.: O usuário é o root, e a senha é a mesma do root do seu servidor.

Instalando repositório RPMforge no CentOS 6.2


Instalando repositório do RPMforge no CentOS, assim, podendo usufruir de todos os pacotes disponíveis no RPMforge com o utilitário YUM do CentOS.

Exemplo: yum install nome_do_pacote...

1. Importação da chave:

# rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt

2. Download do pacote de instalação:

# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

Obs.: Caso tenha outra versão do CentOS, entrar no link abaixo e verificar o link do pacote adequado à sua versão do CentOS.
3. Checar pacote e chave do arquivo baixado:

# rpm -K rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

4. Instalar o pacote baixado:

# rpm -i rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm

5. Limpar base do yum:

# yum clean all

6. Atualizar a base do yum com o novo repositório:

# yum check-update

terça-feira, 5 de julho de 2011

Tunning Squid. Para alto tráfego!





Neste rápido post pretendo ajudar todos os usuários de Linux que fazem uso do squid como servidor Proxy. 
Não será abordado configurações de regras de squid, apenas iremos tratar algumas configurações necessárias para dar maior agilidade ao squid, para aquelas pessoas que assim como eu tiveram problemas ao ter muitos usuários conectados ao proxy e a Internet se tornar lenta.


No cenário este "tunning" foi feito em um servidor com apenas 1.5GB de ram, e dois discos SCSI de 10k com um processador Pentium III 850MHZ rodando DEBIAN 6. O mesmo esta atendendo em horário de pico em média de 800 usuários simultaneamente.


Então mão na massa:


Modificando algumas configurações do kernel:


Primeiramente vamos alterar alguns valores do kernel padrão, reduzindo o tempo de limpeza da tabela ARP e aumentando o seu tamanho, assim bem como aumentando o número de conexões simultâneas que o servidor ira atender e reduzir o tempo de espera entre as conexões.

Para isso vamos alterar o arquivo sysclt.conf (vim /etc/sysctl.conf) e no final do arquivo adicionar as linhas abaixo:



######################### TUNNING PARA SQUID ####################
# Reduzir o tempo de limpeza da tabela ARP
# Expandir o seu tamanho
net.ipv4.neigh.default.gc_interval = 15
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 16384


# Aumento do numero de conexoes simultaneas
# Reducao do tempo de espera entre as conexoes
net.core.somaxconn = 20480
net.core.netdev_max_backlog = 2048
net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_synack_retries = 1
net.ipv4.tcp_max_syn_backlog = 2048
#########################################################################

Após adicionar as linhas, e salvar o arquivo se faz necessário executar o comando "sysclt -p" para que as alterações sejam importadas pelo kernel.

Modificando os limits de segurança:

Uma outra boa prática adotada foi modificar os valores de limits do kernel. Para se verificar os limits do seu kernel basta digitar o comando "ulimit -a"
No meu caso apenas alterei o valor de open files que no padrão era 1024 e passei para 16384.
 Para fazer essa alteração basta digitar o seguinte comando na console:

ulimit -n 16384

Porém ao reiniciar o servidor, os valores de limits irão retornar para o default, para que isso não aconteça, faça o seguinte:

Edite o arquivo limits.conf (vim /etc/security/limits.conf). No final do arquivo inclua as seguintes linhas:


############### TUNNING DE LIMITS DE KERNEL ###########################
root soft nofile 16384
root hard nofile 32768
* soft nofile 16384
* hard nofile 32768
#######################################################################

Modificando configuração padrão do Squid:

Agora vamos alterar o valor padrão de arquivos de descritores abertos pelo squid. Para isso edite o arquivo /etc/default/squid

Neste arquivo tem um valor padrão de 1024, altere para 4096.

Mais alguns detalhes:

Pronto, o seu kernel para uso do squid esta tunado... Uma alteração a gosto de quem quiser testar também foi modificar os parâmetros de leitura de cache no squid.conf.

Percebi uma melhora significativa na velocidade de acesso ao cache ao usar o método diskd no lugar de aufs. Em algumas pesquisas na Internet encontrei registros em que o diskd consegue fazer até 160 requisições por segundo ao cache no disco sendo que o aufs gira em torno de 40 requisições por segundo.

Entendido isso foi alterado o cache para os seguintes parâmetros:


cache_dir diskd /var/spool/squid 20480 64 256 Q1=64 Q2=72

Se pesquisarem sobre este parâmetro deverão encontrar muita coisa, então não irei abordar o porque dos porquês...

Feito essas configurações, recomendo reiniciar o servidor e levantar o squid para ver as melhoras de performance. No meu caso ficou visivelmente mais rápida a navegação. 

Espero ter ajudado...

Rafael Mendes

Qualquer dúvida deixem suas perguntas.