sexta-feira, 24 de janeiro de 2014

Recebendo alertas de falhas de servidores HP ProLiant rodando Ubuntu

Apesar de não suportar o sistema operacional Ubuntu, muita gente não sabe, mas a HP disponibiliza suas ferramentas de gerenciamento de servidores ProLiant no formato .deb, tendo inclusive um repositório disponível que pode ser facilmente configurado em seu servidor.

As ferramentas disponíveis permitem verificar tempetura, velocidade dos fans, estado do disco e da controladora RAID, configurar o iLO entre outras coisas.

Mas como faço para instalar as ferramentas?

Para começar, adicione o seguinte repositório no seu servidor:

deb http://downloads.linux.hp.com/SDR/downloads/ProLiantSupportPack/ lucid current/non-free

Mesmo o repositório sendo para o Ubuntu 10.04, as ferramentas funcionam perfeitamente no 12.04  (nas versões mais novas ainda não pude testar).

Após rodar um apt-get update, ficarão disponíveis os seguintes pacotes: 
  • cpqacuxe: utilitário web de configuração dos arrays de disco (necessita controladora RAID, e não, ele não funciona com o "RAID" onboard que depende de drivers que normalmente está disponível nos servidores ML110).
  • hp-health: contém as ferramentas para monitoramento da "saúde" do sistema.
  • hpsmh: provê a página web de gerenciamento do sistema onde é possível visualizar os alarmes e a "saúde" do servidor.
  • hp-smh-templates: contém templates para a página web de gerenciamento do sistema.
  • hp-snmp-agents: contém o servidor SNMP e agentes de storage e de rede para todos os servidores ProLiant.
  • hpacucli: é a versão de linha de comando do cpqacuxe.
  • hponcfg: contém as ferramentas de linha de comando para configurar o iLO.
E depois de instaladas, o que eu posso fazer?

Dos pacotes acima, eu pude testar apenas o hp-health, hpacucli e o hpsmh, e somente as seguintes ferramentas: hplog, hpacucli e a interface web do hpshm.

hplog

O hplog, entre outras coisas, possibilita a visualização do status atual da temperatura, dos fans e da energia, permitindo que tais dados sejam utilizados em um script para geração de um alerta por e-mail, por exemplo, que é o objetivo principal deste post.

Alguns exemplos:

Temperatura atual

root@lnxsrv:~# hplog -t
ID     TYPE        LOCATION      STATUS    CURRENT  THRESHOLD
 1  Basic Sensor Ambient         Normal    66F/ 19C 104F/ 40C
 2  Basic Sensor Memory Board    Normal   132F/ 56C 230F/110C
 3  Basic Sensor CPU (1)         Normal    86F/ 30C 212F/100C
 4  Basic Sensor CPU (1)         Normal    86F/ 30C 212F/100C
 5  Basic Sensor I/O Zone        Normal    96F/ 36C 145F/ 63C
 6  Basic Sensor CPU (2)         Normal   ---F/---C 212F/100C
 7  Basic Sensor CPU (2)         Normal   ---F/---C 212F/100C
Status dos fans
root@lnxsrv:~# hplog -f
ID     TYPE        LOCATION      STATUS  REDUNDANT FAN SPEED
 1  Var. Speed   System Board    Normal     No      Low    ( 35)
 2  Basic Fan    System Board    Absent     No      Unknown
 3  Var. Speed   System Board    Normal     No      Low    ( 35)
 4  Basic Fan    System Board    Absent     No      Unknown
 5  Var. Speed   CPU (1)         Normal     N/A     Low    ( 35)
 6  Basic Fan    CPU (2)         Absent     N/A     Unknown

Status do power
root@lnxsrv1:~# hplog -p
ID     TYPE        LOCATION      STATUS  REDUNDANT
 1  Standard     Pwr. Supply Bay Normal     No
 2  Standard     Pwr. Supply Bay Absent     No

hpacucli

O hpacucli, entre outras coisas, possibilita a visualização do status atual da controladora e dos discos, permitindo que tais dados sejam utilizados em um script para geração de um alerta por e-mail, por exemplo.


Alguns exemplos:

Status da controladora
root@lnxsrv:~# hpacucli ctrl all show status
Smart Array E200i in Slot 0 (Embedded)
   Controller Status: OK
   Cache Status: OK
   Battery/Capacitor Status: OK

Status dos discos
root@lnxsrv:~# hpacucli ctrl slot=0 pd all show detail
Smart Array E200i in Slot 0 (Embedded)
   array A
      physicaldrive 2I:1:1
         Port: 2I
         Box: 1
         Bay: 1
         Status: OK
         Drive Type: Data Drive
         Interface Type: SATA
         Size: 250 GB
         Firmware Revision: HPG9
         Serial Number: Z3THAVJF
         Model: ATA     VB0250EAVER
         SATA NCQ Capable: False
         PHY Count: 1
         PHY Transfer Rate: 1.5GBPS
      physicaldrive 2I:1:2
         Port: 2I
         Box: 1
         Bay: 2
         Status: OK
         Drive Type: Data Drive
         Interface Type: SATA
         Size: 250 GB
         Firmware Revision: HPG1
         Serial Number: 9SF0527C
         Model: ATA     GB0250EAFJF
         SATA NCQ Capable: False
         PHY Count: 1
         PHY Transfer Rate: 1.5GBPS

Interface web do hpshm

Minha experiência com a interface web não foi das melhores. Usei a mesma em dois modelos diferentes, mas em nenhum deles consegui obter os dados que desejava. Por fim preferi utilizar as ferramentas de linha de comando e não dei mais atenção a este recurso, então é provável que ele tenha sido mal explorado.

E como posso tratar e receber os alertas?

Uma possibilidade (a mais óbvia delas) é tratar a saída dos comandos num script que procura por erros e, caso os mesmos sejam encontrados, enviar o status para um determinado e-mail.

Vou exemplificar abaixo, partindo do pressuposto que desejamos receber alertas em caso de falhas em algum dos HDs do servidor:

#! /bin/bash
#
# Script de envio de e-mail
# em caso de falha de disco
#
# Marcelo Terres
#

MAILTO="marcelo@meudominio.com.br"
MAILSUBJECT="Alarme de disco em $HOSTNAME"
HPACUCLI="/usr/sbin/hpacucli"
MAILEXEC="/usr/bin/mail -a \"Content-Type: text/plain;charset=UTF-8;\" -s \"$MAILSUBJECT\" \"$MAILTO\""

$HPACUCLI ctrl slot=0 pd all show detail | grep "Status: Failed" -q

if [ $? == 0 ]; then

  echo "Erro de disco encontrado"

  MAILBODY="Olá, \nexiste um erro de disco no servidor $HOSTNAME\n\nSaida da verificacao:\n`$HPACUCLI ctrl slot=0 pd all show detail`"
  echo -e "${MAILBODY}" | eval $MAILEXEC
  exit 1
fi

exit 0

O exemplo acima é bastante simplório, é claro, mas tem por objetivo somente servir de base para que você coloque sua criatividade em prática e desenvolva agora algo que atenda sua demanda da melhor forma possível.

Até mais.

quinta-feira, 23 de janeiro de 2014

Bug com smb_auth no Squid3 do Ubuntu 12.04


Há muito tempo que não instalava um Squid e eis que surgiu a necessidade de fazê-lo.

Esta instalação, diferente das anteriores que havia realizado, precisava autenticar no Windows Active Directory 2012, mas como tratava-se de uma autenticação simples, ao invés de Kerberos, Winbind e afins, optei por utilizar a autenticação básica, com os comandos squid_ldap_group e o smb_auth.

Depois da instalação e da configuração finalizadas, iniciei os testes dos mecanismos de comunicação com o AD. Primeiro o squid_ldap_group, que comportou-se como o esperado e depois o smb_auth, que acabou falhando.

Mesmo após vários testes e verificações me deparava sempre com o mesmo problema:
/usr/lib/squid3/smb_auth -d -W MEUDOMINIO -U 192.168.1.2
meu_usuario minha_senha
Domain name: MEUDOMINIO
Pass-through authentication: no
Query address options: -U 192.168.1.2 -R
Domain controller IP address: 192.168.1.2
Domain controller NETBIOS name: MEUDOMINIODC1
Contents of //MEUDOMINIODC1/NETLOGON/proxyauth:
ERR

Como eu tinha certeza de que estava tudo correto, decidi debugar os softwares. Já que o smb_auth era um binário, iniciei a investigação pelo script /usr/lib/squid3/smb_auth.sh

Aparentemente não havia nada de errado com o mesmo, mas ele também falhava nos testes. Resolvi então testar o script passo a passo e acabei  me depararando com um erro lamentável. O comando que verificava o conteúdo do arquivo proxyauth no compartilhamento netlogon não estava enviando os dados de autenticação, como podemos ver abaixo:
authinfo=`smbclient "//$dcname/$AUTHSHARE" -I $dcip -d 0 -E -W "$DOMAINNAME" -c "get $authfilebs -" 2>/dev/null`

Corrigi então o código, que ficou da seguinte maneira:
authinfo=`smbclient "//$dcname/$AUTHSHARE" -I $dcip -d 0 -E -W "$DOMAINNAME" -c "get $authfilebs -" -U $USER 2>/dev/null`
Voilà, problema resolvido:  
/usr/lib/squid3/smb_auth -d -W MEUDOMINIO -U 192.168.1.2
meu_usuario minha_senha
Domain name: MEUDOMINIO
Pass-through authentication: no
Query address options: -U 192.168.1.2 -R
Domain controller IP address: 192.168.1.2
Domain controller NETBIOS name: MEUDOMINIODC1
Contents of //MEUDOMINIODC1/NETLOGON/proxyauth: allow
OK
Espero que este post seja útil e evite que você perca tanto tempo quanto eu perdi numa tarefa tão corriqueira.

quarta-feira, 22 de janeiro de 2014

Limitação do número de ligações simultâneas via IAX


Uma situação bastante comum quando você precisa interligar duas (ou mais) filiais via IAX para que os usuários de ambos locais possam falar sem custo entre si, é a existência de uma banda limitada para o uso de voz.

Quando temos este cenário, normalmente surge um problema: como podemos garantir que não teremos mais ligações simultâneas do que permite a "banda reservada" para este recurso.

Com esta demanda nas mãos, criei um plano de discagem que permite limitar o número de ligações simultâneas quando for utilizado IAX2 (ou, com pequenas adaptações, qualquer outro tipo de canal, como, por exemplo, SIP).

Para efeito de demonstração, vamos supor que você utilize um codec que consuma 64Kbps para cada ligação (G.711 a-law). Vamos supor também que você tenha 256Kbps disponível para voz, podendo realizar então até quatro ligações simultâneas sem perda na qualidade (cortes, "voz robótica", etc...).

A configuração necessária para tal controle é feita no extensions.conf, em três contextos diferentes (não esqueça de adaptar o exemplo à sua realidade):

  • o contexto [globals] é padrão do Asterisk e nele você pode declarar variáveis para uso no plano de discagem;
  • o contexto [from-iax] é o contexto que controlará as chamadas recebidas via IAX;
  • o contexto [saidaexterna] é o contexto de saída das chamadas (exceto chamadas entre ramais locais);

Contexto globals

No contexto [globals] você irá declarar a variável que controla o número máximo de chamadas permitidas, da seguinte forma:
; Controle de chamadas
; 256Kbps  = 4 chamadas a-law de 64Kbps cada
CALL_LIMIT_IAX=4 

Contexto from-iax

No contexto [from-iax]  você irá controlar as chamadas entrantes via IAX, da seguinte forma:
exten => _XXXX.,1,NoOp(Chamada via IAX)
same => n,NoOP(Chamada de origem ${CALLERID(num)} discando para ${EXTEN})
; Adiciona chamada no grupo do IAX2
same => n,NoOP(Adicionando chamada entrante ao grupo IAX2)
same => n,Set(GROUP()="IAX2")
; verifica o número de chamadas simultâneas no grupo
same => n,Set(SIMULTCALL=${GROUP_COUNT("IAX2")})
same => n,NoOp(Ligacoes em curso IAX2: ${SIMULTCALL} de ${CALL_LIMIT_IAX})
; verifica se a chamada pode ser realizada
same => n,GotoIf($[0${SIMULTCALL} <= 0${CALL_LIMIT_IAX}]?call:nocall)
; seção utilizada quando a chamada não pode ser realizada
same => n(nocall),NoOp(Limite de chamadas IAX2 excedido - chamada entrante recusada)
same => n,Playback(canais_iax_ocupados)
same => n,Hangup()
; seção utilizada para realização da chamada para ramais (sip)
same => n(call),Goto(sip,${EXTEN},1)
same => n,Hangup()

Contexto saidaexterna

No contexto [saidaexterna] você irá controlar as chamadas saintes via IAX e outras tecnologias como DAHDI, Khomp ou DGV, da seguinte forma:
exten => _X.,1,Progress
; AGI para obter a variável de discagem ${DIAL} com base no destino da ligação
;
; As saídas possíveis são, por exemplo:
; Khomp/Gebt/${EXTEN}
; Khomp/Ggsm/${EXTEN}
; DGV/g1/${EXTEN}
; IAX2/SPO/${EXTEN}
; SIP/vono/${EXTEN}
;
; Não vou postar o AGI porque ele é muito específico para a solução
; mas você pode gerar o seu próprio AGI com base na sua estrutura
;
same => n,AGI(dialout.agi)
; Obtém o tipo de canal de saída
same => n,Set(OUTCHAN=${DIAL:0:4})
; Verifica se o canal é IAX2. Se não for IAX2 vai diretamente para a discagem
same => n,GotoIf($["${OUTCHAN}"="IAX2"]?iax:call)
; Adiciona chamada no grupo IAX2
same => n(iax),NoOP(Adicionando chamada sainte ao grupo IAX2)
same => n,Set(GROUP()="IAX2")
; verifica o número de chamadas simultâneas IAX2
same => n,Set(SIMULTCALL=${GROUP_COUNT("IAX2")})
same => n,NoOp(Ligacoes em curso IAX2: ${SIMULTCALL} de ${CALL_LIMIT_IAX})
; verifica se a chamada pode ser realizada
same => n,GotoIf($[0${SIMULTCALL} <= 0${CALL_LIMIT_IAX}]?call:nocall)
; seção usada quando a chamada não pode ser realizada
same => n(nocall),NoOp(Limite de chamadas IAX2 excedido - chamada sainte recusada)
same => n,Playback(canais_iax_ocupados)
same => n,Hangup()
; disca
same => n(call),Dial(${DIAL},60,TWXr)
same => n,Hangup()

ATENÇÃO: É importante que este plano de discagem seja implementado em ambos servidores para que possamos garantir que não sejam recebidas e nem realizadas mais ligações do que o valor limite.

Agora é com você. Adapte e estenda este plano de discagem e se quiser compartilhar suas melhorias, fique à vontade para postá-las nos comentários.


Até a próxima.




terça-feira, 21 de janeiro de 2014

Próxima versão do Openfire trará suporte ao Jitsi Videobridge

Para quem ainda não conhece, o Jitsi Videobridge é um software para conferência de vídeo multi usuário, no estilo Google Hangouts, mas com o código aberto.

Em pleno desenvolvimento (a versão "70" foi lançada na data de ontem), a boa notícia é que o Jitsi Videobridge pode ser instalado como um plugin do Openfire, e o mesmo já foi adicionado na versão 3.9.0 que ainda não tem data de lançamento prevista. 

A nova versão do Openfire, além deste novo recurso, trará como de costume uma série de correções de bugs e de melhorias (as notas de lançamento já podem ser lidas aqui).

E já que estamos falamos do Jitsi Videobridge, o mesmo já está disponível para download com versões para Linux, Windows e OSX nesta URL

Mas se você não quiser esperar o lançamento da versão 3.9.0 do Openfire para testar o novo plugin, baixe-o aqui e boa diversão. 

segunda-feira, 20 de janeiro de 2014

Problema com logs no Openfire 3.8.1 e 3.8.2

Já havia atualizado o Openfire para a última versão (3.8.2) há um bom tempo, mas até o momento não havia sido preciso fazer qualquer verificação nos logs do mesmo.

Semana passada, no entanto, fui obrigado a analisar os logs para verificar uma situação de erro de s2s e percebi que o software não estava gerando os logs a partir da versão 3.8.1 (não pude confirmar a existência do bug na versão 3.8.0).

Após muita pesquisa me deparei com um link que relatava a mesma questão e trazia a solução do problema. 

É muito simples:

  • Localize o script que inicia o Openfire (se não souber onde ele está você pode encontrar esta informação no initscript que fica no /etc/init.d/).
  • Edite este arquivo e procure pela linha que inicia com o comando nohup.
  • Mova os parâmetros -DopenfireHome e -Dopenfire.lib.dir que ficam no final da linha para antes do parâmetro -classpath.
  • Reinicie o Openfire 
Problema resolvido!

sábado, 5 de janeiro de 2013

CCSS (Call Completion Supplementary Services) no Asterisk


O cenário: você liga para um ramal pois precisa falar com o usuário para resolver um problema urgente mas o ramal está ocupado. Você desliga a chamada e de tempos em tempos tenta ligar novamente mas sempre recebe o sinal de ocupado. 

O que fazer? Você pode procurar o usuário para falar pessoalmente com ele. Você também pode desistir de falar com o usuário e tentar resolver o problema por conta própria. Ou então você pode ativar o recurso de Call Completion em seu ramal e esperar que o Asterisk ligue para você quando o ramal do usuário estiver livre.

O CCSS, que está disponível a partir da versão 1.8 do Asterisk, permite que um ramal seja monitorado sob demanda, alertando o usuário e efetuando automaticamente a chamada quando o mesmo ficar disponível. O recurso pode ser utilizado tanto para chamadas não atendidas (CCNR) quando para chamadas ocupadas (CCBS), de forma similar para o usuário.

E como eu implemento o CCSS no Asterisk?

O CCSS é uma feature padrão do Asterisk e para torná-la ativa basta adicionar os seguintes parâmetros a configuração SIP de seus ramais:
cc_agent_policy=generic
cc_monitor_policy=generic
Caso você use SIP realtime, basta adicionar os devidos campos na tabela SIP do banco.

O cc_agent_policy é utilizado pelo usuário que está discando, enquanto o cc_monitor_policy é utilizado pelo usuário a qual está sendo destinada a chamada. Eu prefiro ativar o recurso para todos os ramais, então todos possuem a mesma configuração.

O tipo de agente e de monitor utilizado por mim foi o generic, que atende bem a demanda, mas possui algumas limitações. A principal delas é que o usuário só consegue realizar uma monitoração por vez, ou seja, ele precisa ativar e desativar o recurso para que possa utilizá-lo novamente. 

Outros tipos estão disponíveis e você pode saber mais sobre os mesmos no arquivo /etc/asterisk/ccss.conf, onde você também pode ajustar outras configurações do serviço. A versão 10.X do Asterisk implementa um controle de Device State com o agente genérico que melhora muito a sua funcionalidade.

Uma recomendação para melhorar o funcionamento do sistema é setar a opção callcounter=yes na configuração de seu peer sip e também a opção limitonpeers=yes na seção general do arquivo sip.conf. Apesar de recomendado, efetuei testes sem estas opções (com telefones Polycom) e não encontrei problemas, mas pode ser que outros clientes SIP não se comportem tão bem.

E na prática como funciona?

Na prática funciona da seguinte maneira:

Imaginemos que você queria ligar para o ramal 1200. Você liga para o ramal e ele está ocupado ou não atende a ligação. 

Você desliga a chamada (ou ela é desligada) e você tem até 20 segundos (tempo padrão que pode ser alterado) para solicitar a ativação do serviço de CC. No meu caso basta discar para o *22 que o serviço estará ativo.

Se o ramal estava ocupado, assim que ele desligar o Asterisk irá efetuar uma ligação para o seu ramal. Assim que você atender ele discará automaticamente para o ramal 1200.

Se a ligação não havia sido atendida, o Asterisk entenderá que o usuário não está em sua mesa. Assim, depois que ele fizer uma nova chamada, o Asterisk perceberá que ele está no local e,  assim que ele desligar, realizará uma ligação para o seu ramal e assim que você atender ele discará para o ramal 1200.

Após você falar com o ramal 1200, no entanto, é preciso que você desative o serviço (no meu caso discando para *220), para que possa utilizá-lo novamente (devido ao uso do generic).

Por fim, sugiro que a página de dicas sobre o serviço seja lida, pois ali constam informações e recomendações muito relevantes que devem ser seguidas.

Exemplo do plano de discagem

Segue abaixo um plano de discagem bem simples para ativar e desativar o recurso:
[internal_services]
exten => *22,1,CallCompletionRequest
exten => *22,n,Hangup
exten => *220,1,CallCompletionCancel
exten => *220,n,Hangup

sexta-feira, 4 de janeiro de 2013

Utilizando XMPP para interagir com Asterisk


Na Propus fazemos uso diário da integração de nosso servidor XMPP com o Asterisk

Envio e recebimento de SMS, identificação de chamadas e integração com Google Talk são alguns dos recursos que desenvolvemos e testamos em nosso laboratório. Sempre que posso procuro pesquisar e desenvolver novas ideias para expandir esta integração, pois XMPP e VoIP (em especial Openfire e Asterisk) são duas tecnologias com as quais gosto muito de trabalhar.


Como faço uso destas tecnologias diariamente, nada mais natural do que pensar em utilizar o XMPP para realizar tarefas cotidianas no Asterisk ou até mesmo obter informações do sistema e de seus recursos.

Resolvi então pesquisar mais sobre esta interação e encontrei um blog muito interessante que acabou por me levar a um bot xmpp integrado com Asterisk que vai ao encontro de minhas ideias.

O bot, desenvolvido em perl, faz uso da AMI e da biblioteca Asterisk::AMI para monitorar os eventos do manager do Asterisk e interagir com o sistema. 

Baixei o script e após testá-lo acabei modificando-o e adaptando-o para atender as minhas necessidades, mas "minha" versão ainda está engatinhando, pois ainda existem muitos recursos que podem ser disponibilizados (e alguns mais que estão em construção).

Comando de ajuda implementado pelo script
Compartilho aqui a minha versão do script para que outros possam utilizá-lo e até mesmo estendê-lo e melhorá-lo.

Espero que o mesmo seja útil e que novas versões sejam também compartilhadas nos comentários deste post.

Até mais!

Asterisk e Google Text to Speech

No uso diário do Asterisk, periodicamente me deparo com a necessidade de gerar arquivos de áudio para tocar mensagens informativas básicas para o usuário.

Obter tais arquivos é uma tarefa eventualmente árdua que normalmente envolve a gravação in house dos arquivos (que consome um tempo razoável) ou a contratação de uma empresa especializada. Existem várias empresas excelentes neste nicho de mercado, mas às vezes não existe orçamento ou até mesmo tempo para produzir áudios mais básicos, para consumo interno.

Como alternativa para a criação de tais áudios, encontrei na lista AsteriskBrasil a sugestão do AGI GoogleTTS.

Este AGI utiliza o Google Text to Speech para gerar um arquivo de áudio on demand na linguagem que você indicar, e que, após sua geração, é automaticamente tocado pra o usuário. Como utiliza o Google Text to Speech, este AGI necessita de uma conexão ativa de Internet, mas, como todo software bem planejado, ele  possui um sistema de cache que garante que a mesma mensagem de áudio não precise ser gerada mais de uma vez, o que possibilita que os arquivos de áudio possam ser utilizados mesmo que o link Internet esteja indisponível, contanto que o mesmo já tenha sido gerado anteriormente.

Instalando o googletts.agi

O AGI, que é escrito em perl, depende de algumas bibliotecas e softwares bastante populares, que podem ser facilmente instalados no Ubuntu 12.04 com o comando apt-get install libwww-perl mpg123 sox.

Após fazer o download do arquivo .tar.gz, descompacte-o e coloque o arquivo googletts.agi no diretório /var/lib/asterisk/agi-bin/  para que o Asterisk possa acessá-lo. Não esqueça de verificar as permissões de acesso do arquivo.

Aconselho que antes de iniciar o uso, o arquivo googletts.agi seja editado para definir algumas paramêtros, como a linguagem padrão e o diretório para armazenamento do cache (o diretório padrão, /tmp, certamente não é a melhor escolha para armazenar tais dados).

Utilizando o googletts.agi

Abaixo um pequeno exemplo de utilização da ferramenta para informar de maneira audível ao usuário qual seu ramal e nome de usuário:

[internal_services] 
exten => *65,1,NoOp(Who Am I)
same => n,Answer
same => n,agi(googletts.agi,"Meu ramal é ${CALLERID(num)} e meu usuário é ${CALLERID(name)}",pt-BR)
same => n,Hangup

Use sua criatividade e boa diversão!

sábado, 1 de dezembro de 2012

Ainda sobre o VOX IP da GVT

Após realizar uma nova configuração do GVT VOX IP com Asterisk, eis que percebi que faltaram algumas informações relevantes no post anterior

Como a GVT continua não provendo uma documentação mínima do serviço (confesso que não foi solicitado diretamente, mas, na minha opinião, na instalação do serviço deveria ser entregue ao cliente pelo menos um documento com os dados completos da rede e informações relevantes de configuração), novamente foi preciso utilizar a experiência adquirida para resolver algumas questões. 

Sonho com o dia em que a GVT dará um status mais profissional ao VOX IP, pois parece ainda tratar-se de um serviço "alternativo" ou em fase de testes, o que não é verdade, pois o serviço é bem estável e funcional. Além disso, eu acredito que esse tipo de entroncamento (SIP) será o substituto natural do link E1, apesar das operadoras não quererem aceitar esta realidade.

Pois bem, este post é complementar ao primeiro, e possui algumas informações que serão bastantes úteis na configuração do serviço.

Codecs

A dica inicial é: atenção aos codecs. A GVT instala um link de 1Mbps para  prover 30 canais, e, se não for utilizado o codec adequado, o número de canais pode cair pela metade.

Apesar do VOX IP aceitar o uso do codec g711 alaw (segundo a informação este deve ser o codec secundário na configuração do peer SIP), o mesmo utiliza 64 Kbps de banda, fazendo com que só possam ser utilizados 15 canais simultâneos na banda disponível.

Por isso a GVT recomenda a utilização do codec g729, que utiliza uma banda muito menor possibilitando o uso dos 30 canais simultaneamente. No entanto é importante esclarecer que o Asterisk não disponibiliza o codec. Para instalá-lo é preciso adquirir as licenças da Digium, ao custo de USD 10,00 cada.

Fax

Para uso do Fax, o VOX IP dispõe do T.38, que é o protocolo para transmissão de fax sobre redes IP. O Asterisk já provê suporte a este protocolo, mas também é possível enviar fax utilizando-se o codec g711, com softwares como iaxmodem e hylafax (No caso de uso do T.38, a alternativa para o iaxmodem  é o t38modem).

Também é possível utilizar o Fax for Asterisk, da Digium, mas cada licença para uso de fax (simultâneo) tem o custo de USD 40. 

Uma outra alternativa seria o uso do Free Fax for Asterisk, que disponibiliza uma única licença sem custos, e que pode ser usado em ambientes onde o Fax é utilizado de maneira esporádica.

Identificação de entrada

Um fato que merece ser citado é que o VOX IP não entrega somente o MCDU, mas sim o número completo de destino (DDD + número). 

Assim, se você está migrando de um link E1, ou está acostumado a instalações com links E1, adapte seu plano de discagem para este novo formato.

Roteamento da rede do VOX IP

A abordagem adotada no roteamento da rede do VOX IP tem sido meio radical, mas como não há informação completa da GVT, a mesma tem proporcionado o funcionamento adequado do serviço.

Vou exemplificar:

  • Rede entregue pela GVT para enlace: 10.153.X.Y/29
  • IP de registro do servidor: 10.150.X.Y

Como não havia informações sobre a rede a ser roteada, foi realizado o roteamento da rede 10.150.X.0/24. 

Com este roteamento, apesar do SIP ficar registrado e a chamada ser completada, a ligação ficava muda em ambas pontas. Após uma investigação com o tcpdump, pode-se observar que haviam pacotes vindos da rede 10.152.X.Y, que não estava roteada, o que causava o problema.

Como não havia conflito na rede em questão, foi realizado então o roteamento da rede 10.128.0.0/9, o que certamente não é a melhor prática, mas que permitiu que o serviço funcionasse corretamente.

Caso alguém possua informações corretas sobre a rede a ser roteada, por favor poste nos comentários.

Host não identificado

E, para finalizar, se você se deparar com um erro semelhante no console do Asterisk, pode ficar tranquilo:
[Dec  1 08:37:42] ERROR[11427]: netsock2.c:269 ast_sockaddr_resolve: getaddrinfo("PAE1CS2K", "5060", ...): Name or service not known
[Dec  1 08:37:42] WARNING[11427]: chan_sip.c:16078 check_via: Could not resolve socket address for 'PAE1CS2K:5060'
O host em questão é o servidor SIP onde você está registrado. 

Para que tal erro não ocorra mais, adicione a seguinte linha no seu arquivo /etc/hosts:


10.150.X.Y   PAE1CS2K

De momento é isso, mas assim que houverem novas informações, possivelmente será feito um update no post.

UPDATE 12/12/2012: é muito importante que seja sempre utilizado o Progress ao receber ou realizar uma chamada externa, caso contrário as ligações podem ser derrubadas pela operadora durante seu curso.

UPDATE 27/12/2012: muita gente relatou ter dificuldades para identificar suas chamadas com o número dos ramais ao invés do número chave do tronco (eu mesmo me deparei com tal situação). Isso ocorre porque a GVT utiliza os headers From e Contact do pacote SIP para fazer a identificação, ao invés de somente o ${CALLERID(num)} provido pelo Asterisk. Para que você possa se identificar com o número do DDR, sete o ${CALLERID(num)} e não utilize o parâmetro fromuser na sua configuração SIP do VoxIP.

Leia também:


terça-feira, 10 de julho de 2012

Lista Openfire-BR - o retorno

A lista Openfire-BR foi recriada.

Foram reinscritos automaticamente na lista todos os usuários que em algum momento enviaram mensagens para a mesma. Possivelmente alguns usuários inativos também foram reinscritos, pois não foi possível identificar quais eram os membros atuais. A estes, peço que façam a gentileza de remover-se novamente e também gostaria que aceitassem minhas sinceras desculpas, mas infelizmente não foi possível realizar algum tipo de filtro para evitar a inscrição indesejada.

O próximo passo agora será recriar os arquivos da lista, o que espero ocorra em breve.

Aos membros da lista que não foram automaticamente inscritos, peço que assinem novamente a mesma para que esta volte à atividade normal.

Obrigado.

segunda-feira, 2 de julho de 2012

Lista Openfire-BR - o reinício

Como todos já devem saber, infelizmente ocorreu um problema com o servidor da ASL que gerenciava as listas de discussões do domínio softwarelivre.org, e, entre as baixas está a lista Openfire-BR.


Devido a este infortúnio, que causou a perda dos dados, será preciso recomeçar a lista, e, para isso, espero contar com o apoio de todos os membros, que precisarão recadastrar-se na mesma, assim que ela for recriada.

Tentarei tomar as seguintes medidas, assim que for possível:
  • Envio de e-mail para todos os membros da lista (ativos e inativos) para que recadastrem-se;
  • Recriação do histórico de mensagens da lista, para que toda a base de conhecimento gerada ao longo de mais de quatro anos não se perca.

Espero poder contar com a colaboração de todos. Assim que a lista estiver disponível, o que deve ocorrer nos próximos dias, um novo post será publicado com as instruções para recadastramento dos interessados.

Até mais!

sexta-feira, 29 de junho de 2012

Problemas na lista Openfire-br


Quem utiliza a lista Openfire-BR deve ter percebido que a mesma está apresentando problemas desde o início da semana. A situação está sendo tratada, e, assim que possível, a lista estará novamente disponível.

Agradeço a paciência e a compreensão dos mais de 600 membros desta lista, que com pouco mais de quatro anos de atividade formou uma bela comunidade em torno deste excelente servidor XMPP.

Abraço a todos.


sexta-feira, 22 de junho de 2012

Free Beer e o fisl 13 (quase um Off-topic)


E amanhã é dia de mais uma brassagem, e a cerveja da vez é a FREE BEER

Para quem não conhece, a FREE BEER é uma Ale com adição de guaraná, cuja receita é publicada sob uma licença Creative Commons (Attribution-ShareAlike 2.5), o que significa que qualquer um pode usá-la para fazer sua própria FREE BEER ou criar uma receita derivada da mesma. Não existem restrições a ganhos financeiros com a FREE BEER (o conceito é de free as in freedom), mas a receita deve ser publicada sob a mesma licença e devidamente creditada.

Pois bem, como o fisl 13 está chegando, e a FREE BEER se identifica com o conceito do mesmo, o pessoal da PROGE decidiu fazer a primeira produção gaúcha desta cerveja, totalizando 150 litros que serão consumidos em um evento da empresa que ocorrerá durante o período do fórum.


E, para ajudar nesta empreitada, alguns membros da Acerva Gaúcha resolveram se unir a causa e participar dessa brassagem (os nomes confirmados até o momento são Felipe Ghellar e Liliane Lewis Xerxenevsky da Caverna dos Ogros e Leonardo Sewald, mestre cervejeiro da Cervejaria Seasons, que irá palestrar sobre a produção de cerveja caseira).

Eu também estarei lá realizando a brassagem de aproximadamente 30 litros da FREE BEER. Em breve um post sobre a aventura. :-)

E se você gosta de cerveja não deixe de acompanhar meu blog sobre essa bebida fantástica, o Bier Tasters.

Até mais!

UPDATE 30/06/2012: fotos da brassagem da Free Beer aqui.

terça-feira, 19 de junho de 2012

Mudanças na liderança do ClamAV

Lembro que meu primeiro contato com o ClamAV foi lá pelo final de 2003,  quando o mesmo substituiu um McAfee que era utilizado em um servidor de correio  rodando Debian. Na época o projeto, que havia sido iniciado em 2002, já estava bastante estável e começava a dar seus primeiros passos em direção ao reconhecimento atual.

De lá para cá passaram-se 8 anos onde foram feitas muitas instalações e várias interações, que culminaram com a vinda do criador do projeto, Tomasz Kojm, ao fisl 10 e também com a criação de novos mirrors brasileiros para o software.


Hoje, passados pouco mais de dez anos de sua criação, Tomasz Kojm se despede da liderança do projeto, que ficará ao cargo de Matt Watchinski, que por 10 anos foi encarregado do Vulnerability Research Team (VRT) da Sourcefire (empresa responsável também pelo Snort, e que adquiriu o ClamAV em 2007). 

Segue, na íntegra, o e-mail enviado por Tomasz Kojm.

"Dear ClamAV Users,


This year, ClamAV celebrates its 10th anniversary. The first release was on May 8, 2002, and included the basic command line scanner “clamscan” and database update tool “freshclam”. With your help, the project that started as a hobby has become a complete antivirus solution and one of the most popular Open Source security tools. Today, ClamAV has more than 2 million active installations and scans hundreds of millions of files every day.



We are incredibly proud of this project and of the development work we have been able to do since joining Sourcefire via acquisition in 2007. We’ve had the opportunity to build out the bytecode engine and logical signatures, and implement dozens of other major improvements that make ClamAV a powerful tool.



While we are incredibly proud of this, it is time for us to make a change. ClamAV is now mature software and we are confident that Sourcefire will successfully continue its development, move it forward and maintain the integrity of its infrastructure. Matt Watchinski, who has headed Sourcefire’s Vulnerability Research Team (VRT™) for 10 years, will continue to lead this project. Joel Esler, the company's Open Source community manager, will also be your main point of contact and advocate.



We cannot fully express how grateful we are to all of the people, organizations and companies that have supported us and who will continue to support the project. This includes all the individuals who have contributed virus signatures and the developers who have contributed code to ClamAV throughout the years, the public mirrors that host our virus databases worldwide, the entities that hosted our web site, nameservers and build farm; the developers and package maintainers who have integrated ClamAV into various Open Source products and distributions and, of course, the Open Source community as a whole.



Finally, we would like to thank all who have trusted ClamAV for scanning and protecting some of the most valuable data on their networks.



Sincerely,



Tomasz Kojm <tomasz.kojm@gmail.com> (twitter: @tkojm)
Luca Gibelli <luca@gibelli.it> (twitter: @nervous)
Alberto Wu <acab@digitalfuture.it>
Edwin Török <edwin@etorok.net>"


Fica aqui o agradecimento a Tomasz e sua equipe pelos anos de dedicação, com votos de sucesso em sua nova empreitada.

E também votos de que a Sourcefire continue fazendo um excelente trabalho e que o ClamAV continue sendo uma referência pelos anos vindouros.

Leia também o post no blog do ClamAV.

domingo, 17 de junho de 2012

De volta à atividade

Quase um ano sem novos posts...

O tempo livre, que parece ficar menor a cada dia que passa, e que anteriormente era muito utilizado na manutenção do blog, foi direcionado para atividades de lazer e para a procura de um novo hobby, que ajudasse a equilibrar o stress diário.

Assim, depois de muitos meses, um hobby foi encontrado e um novo blog acabou nascendo, mas isso não significa que o Mundo Open Source foi abandonado. Muito pelo contrário, tudo isso serve para dar um gás e para recarregar as baterias, que eventualmente ficam com pouca carga. :-)

O blog está ativo e tenho procurado responder os comentários na medida do possível, bem como atender todos no bate papo. A participação nas listas (principalmente na Openfire-br) continua fazendo parte da rotina diária bem como o acompanhamento das novidades e lançamentos relacionados ao conteúdo do blog. Além disso, o twitter tem sido uma ótima ferramenta para compartilhar pequenas dicas e novidades da área.

Para dar uma pequena renovada no blog, criei hoje uma seção chamada Openfire - Links Interessantes, onde listei algumas "novidades" dos últimos meses relacionadas ao serviço, que na medida do possível, irão se tornar posts detalhados.

A todos que acompanham o blog, o meu agradecimento. 

Até mais.