Seu servidor tá perdendo o IP?

Eu estava com um problema ao utilizar o FreeBSD com uma placa wireless: “eventualmente perdia o IP e a rota era derrubada”. Como resolver isso? Bem, fiz uma gambiarra na cron, que verifica periodicamente a conexão com o meu roteador (ou um host de outra rede) e restaura a conexao quando necessário. Seque o script:

#!/bin/sh

var=`ping -W 1000 -c 1 150.162.165.1 `
if [ $? -eq 0 ]
then
else
/etc/rc.d/netif restart >> /var/log/restart_network.log
/etc/rc.d/routing restart >> /var/log/restart_network.log
fi

No comando Ping, o parametro -W indica o timedout (1 segundo) enquanto que o parametro -c 1 indica que será enviado apenas um pacote.

Quanto à cron, agendei para ser executada cada 10 minutos.

0/10 * * * * /root/bin/check.sh > /dev/null

O script pode (e deve) se alterado para outros SO’s. Espero que este post seja útil.

Anúncios

SUGAR CRM – Um sistema adequado para relacionamento com clientes ACCURATI

O SUGAR CRM é um sistema adequado para relacionamento com cliente. Possui vários módulos, dentre eles:

  • Cadastro de clientes e contatos
  • Chamadas técnicas / bugs
  • Email integrado

Estou testando atualmente no site da minha empresa que atua nas áreas de:

Confiabilidade Metrológica, verificações periódicas, verificações rápidas, verificações intermediárias, interim-check, metrologia & instrumentação, máquinas de medir por coordenadas – MMC, coordinate measurement machine- CMM, gestão da metrologia,automação, qualidade metrológica, ISO 10360-2, ISO/IEC 17025.

Endereço: http://accurati.com.br/sugar e pode ser baixado em http://www.sugarcrm.com/

Postfix: Uma solução caseira para Autoreplies

Este foi meu problema mais recente. Eu precisei configurar um servidor de email para o meu domínio. Porém, este servidor não oferece acesso pop aos usuários, ou seja, apenas redireciona as mensagens para os usuários de acordo com uma tabela virtual.

Assim, as soluções existentes, como o Vacation, não satisfaziam minhas necessidades, porque o usuário deveria existir no sistema, não funcionaria com o alias. Desta forma, implementei um pequeno script PHP e configurei o postfix para tal tarefa de autoreply.

Passo 1: configurando o script PHP

É necessário você criar um arquivo PHP (ex: /etc/postfix/autreply.php) com o seguinte conteúdo:

#!/usr/bin/php
<?

$DEBUG=1;
$MSG_DEBUG = “”;

if($argc == 3) {
$sender = $argv[1];
$mailbox = $argv[2];
$handler = fopen(“/etc/postfix/db.txt”,”r”);

$headers = ‘Content-type: text/html; charset=iso-8859-1’ . “\r\n” . ‘From: ‘ . $mailbox . “\r\n” .
‘Reply-To: ‘ . $sender . “\r\n” .
‘X-Mailer: PHP/’ . phpversion();

while (($data = fgetcsv($handler, 1000, “|”)) !== FALSE) {
$num = count ($data);
$row++;

if($sender == $mailbox) {
continue;
}

$str .= “Verificando se $data[0] == $mailbox …. “;
if($data[0] == $mailbox) {
$str .= ” OK “;
debug($str);
send($sender,$mailbox, $data[1]);

} else {
$str .= ” NAO”;
debug($str);
}
}
fclose($handler);

if($DEBUG) {
mail(“mailto@yourmailserver.com”, “[$mailbox] Entrega negada.” , $MSG_DEBUG, $headers);
}

} else {
exit (0);
}

function send($sender, $mailbox, $msg) {
global $headers;
$mensagem = “<html><body><p>Erro:<p><h3>”.$msg.”</h3></p></body></html>\n\n”;
mail($sender, “[$mailbox] Entrega negada.” , $mensagem, $headers);
debug(“Enviando email para $sender, assunto:  \”[$mailbox] Entrega negada.\”, texto: $mensagem”);
}

function debug($msg=”) {
global $MSG_DEBUG;
$MSG_DEBUG .= “\n” . $msg;
}

?>

Lembre-se de colocar a opção de execução no arquivo (chmod 755 /etc/postfix/autoreply.php). Além disso, é necessário criar uma arquivo de base de dados (/etc/postfix/db.txt) com as contas que estão com o autoreply ativo e as respectivas mensagens. O formato do arquivo é o seguinte:

noreply@yourdomain.com.br|Aqui é a mensagem de resposta ao sender, pode ser em formato HTML.

Passo 2: configuração e adequações no Postfix

No Postfix, algumas adequações são necessárias. Para começar, vamos habilitar o script PHP no arquivo master.cf. Para isso , basta adicionar o conteúdo abaixo na última linha do master.cf:

autoreply       unix    –       n       n       –       –   pipe flags=F user=nobody argv=/etc/postfix/autoreply.php ${sender} ${original_recipient}

Além disso, precisamos adicionar o seguinte conteúdo no /etc/postfix/transport:

autoreply@yourdomain.com.br autoreply:

E, também, adicionar a linha no /etc/postfix/virtual:

noreply@yourdomain.com.br       devnull@localhost, autoreply@autoreply.yourdomain.com.br

O autoreply.yourdomain.com.br não é um domínio válido e não deve ser colocado no main.cf. Após feito isso, é necessário que você refaça a base de dados e reinicie o postfix:

postmap /etc/postfix/virtual

postmap /etc/postfix/transport

/etc/init.d/postfix restart

Parabéns, tudo deve estar funcionando.. Para testar, envie um email para noreply@yourdomain.com.br e aguarde alguns segundos para receber a mensagem configurada acima.

Um pré-requisito para este tutorial funcionar é que seu postfix deve estar com o virtual domains habilitado.

Detectando gargalos na conexão com a rede externa utilizando o Multi Ping

É comum ouvir reclamações do tipo “o servidor está lento” quando usuários acessam um portal ou um sistema remoto qualquer. O problema é saber: “em que local da rede estamos com problema?”.

Uma estratégia de sucesso para detectar aonde está o gargalo da rede, é escolher conjunto de hosts “chaves”  e medir o tempo de resposta do mesmo.

Uma ferramenta muito boa para monitorar o tempo de resposta do ping é o MultiPing, um script integrado com o CACTI. Com ela, podemos ter uma boa estimativa do tempo de resposta de cada “host chave” que desejamos monitorar na rede, ao longo do tempo.

O tempo de resposta do ping é um bom indicador de como está a rede. Obviamente, como o ping parte do seu servidor, quanto mais distante estiver o HOST “pingado”, o tempo de resposta tende a ser maior. A figura abaixo ilustra a aplicação no servidor que eu trabalho.

graph_image

O host “ce” é o gateway da minha empresa (que fica em outra cidade), enquanto o gw-1, gw-2 são os roteadores do meu datacenter (aonde o servidor se encontra) e o gw-rj o gateway da operadora.

Este gráfico mostra um ping elevado em todos os hosts monitorados a partir do gw-rj. O que é óbvio, se a saída com a Internet está lenta, todos os demais (em cascata) estarão.

Muitas outras combinações podem ser realizadas, inclusive quando o datacenter possuir várias conexões com a Internet. A dica é: estude sua estrutura de rede, detecte os hosts “chave” e implante o multiping, você terá uma fonte de dados para futuras tomadas de decisões.

Protegendo o servidor Apache da Intranet em 3 passos

O objetivo deste post é mostrar como proteger as informações confidenciais (ex: login/senha) das aplicações WEB que rodam na sua intranet. Não é necessário comprar um Certificado (ex: verisign.com ou godaddy.com), basta instruir os usuários de como proceder na primeira conexão.

Pré-requisitos:

Sistema Operacional Linux (não testei em outros sistemas), Apache 2 com mod_ssl, OpenSSL e Mod Rewrite…

Passo1: Geração do certificado

Neste passo dois arquivos serão gerados (.key e o .csr).  Cuide MUITO BEM deste arquivo .key, ele é a chave privada da segurança do seu servidor. Coloque permissão somente leirura para o usuário root (chmod 400 dominio.com.key). Já o arquivo CSR (Certificate Signing Reques), contém as informações do certificado (Empresa, Estado, etc.) e, também, a chave pública do certificado.

# openssl req -nodes -newkey rsa:2048 -keyout dominio.com.key -out  dominio.com.csr

A partir dos arquivos gerados, será criado o arquivo do certificado dominio.com.crt:

# openssl x509 -in cdominio.com.csr -out dominio.com.crt -req -signkeydominio.com.key -days 365

Pronto, seu certificado está gerado!!!

Passo 2: Configuração do apache

É necessário configurar o certificado gerado para o domínio virtual em questão. Dentro do <VirtualHost *:443> (ou algo semelhante),  adicione a configuração do certificado:

SSLEngine  on
SSLCertificateFile /root/certificados/dominio.com.crt
SSLCertificateKeyFile /root/certificados/dominio.com.key

Verifique as configuracoes com o comando apache2ctl configtest e depois reinicie o servidor. Pronto, você já pode testar:

https://dominio.com

Passo 3: Obrigar conexão segura (HTTPS) para acessar algumas URIs

Muitas vezes você não quer que todo o site fique protegido. Para estes e outros casos, você pode utilizar o mod_rewrite do apache. Vamos para uma configuração simples do apache para as necessidades (por exemplo) do wordpress.

Neste caso, você quer que os usuários acessem o blog utilizando uma conexão normal (não criptografada), porém, ao acessar a área privada, o usuário é obrigado a acessar por via segura (https), protegendo seus dados.

Relembrando, a configuraçao do domínio virtual tem duas entradas, uma para a porta 80 (<VirtualHost *:80> e outra para a porta padrão doHTTPS, a 443 (<VirtualHost *:443>). Precisamos fazer duas configurações: A primeira, deve fazer com que sempre que um usuário acessar wp-admin ou wp-login seja remetido para uma conexão segura. Isso será feiro na porta 80. A segunda configuração, por sua vez, deve ser configurada na porta 443, onde obrigamos o usuário acesssar as páginas não-privadas utilizando uma conexão HTTP normal, não criptografada. Seguem as duas configurações:

<VirtualHost *:80>

ServerName dominio.com

rewriteEngine On
rewriteRule ^/(.*)(wp-admin|wp-login)(.*)$ https://dominio.com/$1$2$3 [R=301,L]
</VirtualHost>

<VirtualHost *:80>

ServerName dominio.com

SSLEngine  on
SSLCertificateFile /root/certificados/dominio.com.crt

SSLCertificateKeyFile /root/certificados/dominio.com.key

rewriteEngine On
rewriteCond %{REQUEST_URI} !^/(.*)(wp-admin|wp-login)(.*)|(.*\.js.*)|(.*\.css.*)$
rewriteRule ^/(.*)$ http://dominio.com/$1 [R=301,L]
</VirtualHost>

Pronto, seu servidor está configurado para aceitar conexoes seguras e forçar com que os usuários utilizem o HTTPS somente nos locais que você definir.

Configurando o prompt CSH no FreeBSD

Depois de algum tempo, resolvi postar este post mostrando como configurar o promtp CSH do FreeBSD para ficar amigável.  O arquivo de configuração padrão para todos os usuários que utilizam o CSH no BSD é o /etc/csh/cshrc. O arquivo mostrado abaixo foi construído utilizando como referência o site na internet: How to make custom prompts.

Após copiar o arquivo abaixo para o teu servidor, o seu prompt de comando ficará assim:

csh-prompt-freebsd

Sinta-se a vontade para alterar as cores e testar outras combinações, de acordo com as suas necessidades.

# $FreeBSD: src/etc/csh.cshrc,v 1.3 1999/08/27 23:23:40 peter Exp $
#
# System-wide .cshrc file for csh(1).
# $FreeBSD: src/etc/root/dot.cshrc,v 1.30 2007/05/29 06:37:58 dougb Exp $
#
# .cshrc – csh resource script, read at beginning of execution by each shell
#
# see also csh(1), environ(7).
#

alias h        history 25
alias j        jobs -l
alias la    ls -a
alias lf    ls -FA
alias ll    ls -lA
alias vi    vim
alias rm    rm -i
alias ls    ls -G

# A righteous umask
umask 22

set path = (/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin $HOME/bin)

setenv    EDITOR    vim
setenv    PAGER    more
setenv    BLOCKSIZE    K
setenv TERM xterm

if ($?prompt) then
# An interactive shell — set some stuff up
set c1 = “32m”
set s1 = ‘$’
set u1 = `whoami`
if ( $u1 == “root” ) then
echo “Bem-vindo root. Cuidado….”
set s1 = ‘#’
set c1 = “31m”
endif
set prompt = “%{33[1;$c1%}` whoami`%{33[0;32m%}@%m %{33[1;34m%}%~$s1%{33[0m%} ”

set filec
set history = 100
set savehist = 100
set mail = (/var/mail/$USER)
if ( $?tcsh ) then
bindkey “^W” backward-delete-word
bindkey -k up history-search-backward
bindkey -k down history-search-forward
endif
endif