Obs. Está disponível também no sistema o preview do Gnome 3.0!

Mais informações no site oficial do projeto…

Obs. Reloading modules is also possible via the web interface since ejabberd 0.9.1.

Open an Erlang console on the ejabberd node with:
# ejabberdctl debug

And select the module you wish to compile with:
c(mod_version).

If you just want to reload the .beam file (without recompiling the module), use:
l(mod_version).

Obs. Replace “mod_version” with the name of the file you want to recompile / reload.

There’s no automated way to export all users like Openfire does, but we can dump our entire database, consider that you are using the internal erlang mnesia database, to a text file and filter just the values we want (in this case, users and passwords) using the following steps:

1. Dump the database to a text file:

# ejabberd_ctl ejabberd@localhost dump /tmp/mnesia.dump

2. Filter the dump to get only registered users

# cat /tmp/mnesia.dump | grep ‘{passwd,{‘ > /tmp/tmplist.txt

3. Convert your temporary generated file to the format you prefer, in this case getting a list (username, hostname, password):
   

   # sed -e ‘s/{passwd,{“//g;s/”,”/ /g;s/”},”/ /g;s/”}.//g’ /tmp/tmplist.txt > /tmp/userlist.txt

Obs. The database registers that store user information in the dump have the following format:
{passwd,{“USER”,”VIRTUAL-HOST”},”PASSWORD”}.

Para abrir conexão em um novo servidor sem perder a conexão atual utilize:

/CONNECT irc.server.net

Lembrando que para se conectar a um novo servidor, finalizando a conexão anterior o comando chamado é “/SERVER irc.newserver.net”.

Para listar os servidores atualmente conectados na máquina utilize o comando /SERVER sem nenhum parâmetro adicional, que mostrará uma saída parecida com:

-!- oftc: irc.oftc.net:6667 ()
-!- freenode: irc.freenode.net:6667 ()
-!- efnet: irc.efnet.org:6667 ()

Como mostrado acima, cada conexão com servidor é classificada por uma tag diferente (normalmente o nome do servidor, logo após o sinal -!-) que será utilizada para fazer referência durante a execução de comandos.

Para se desconectar de algum dos servidores utilize:

/DISCONNECT freenode

Onde “freenode” é a tag que faz referência à conexão realizada no irc.freenode.net.

A tag de referência pode ser utilizada em boa parte dos comandos disponíveis, assim como:

/MSG -tag nick mensagem
/JOIN -tag #channel
/QUERY -tag nick
/TOPIC -tag #channel novo topico

Para aqueles que ainda não conhecem o Irssi, ele é um IRC client rico em funcionalidades, leve, flexível, tem suporte a temas, possui suporte a SILC, tem uma ótima integração com o GNU Screen e não necessita de bibliotecas gráficas para a execução. Recomendo a todos!

Recomendo a leitura do “A Guide to Efficiently Using Irssi and Screen” para quem está iniciando sua utilização.

Em termos de carga de servidor a diferença é absurda, o Ejabberd tem um consumo muito baixo de recursos, principalmente se comparado a máquina virtual Java do Openfire. Outra vantagem que pude perceber é a facilidade em se montar um cluster de máquinas para atender alta demanda do serviço, apesar dos plugins de cluster do Openfire serem bem funcionais e fáceis achei bem interessante o método utilizado pelo Ejabberd.

Uma desvantagem que podemos perceber é a falta da interface administrativa super completa do Openfire, a ausência de qualquer edição de arquivos de configuração e o gerenciamento bem prático de plugins, entre eles os gateways de messengers externos e principalmente o plugin de auditoria que permite facilmente gerenciar as conversas e conexões da rede.

Com a utilização do Ejabberd na instalação do servidor aberto aqui do projeto do site, onde qualquer pessoa pode se cadastrar e utilizar os serviços e o gerenciamento é quase que totalmente realizado através dos clients disponívels, a migração foi uma alternativa bem interessante que trouxe diversos benefícios e principalmente novos conhecimentos em Erlang e no banco de dados Mnesia.

Em geral, recomendo a todos o Ejabberd como servidor Jabber/XMPP!

Após algum tempo pesquisando verifiquei que o sistema de busca padrão do Mediawiki é o “fulltext search”, que por padrão ignora quaisquer palavras com menos de 4 caracteres nas pesquisas.

Para contornar esta situação era necessário setar o padrão mínimo de caracteres para 3 diretamente no banco de dados através do próprio my.cnf setando a variável “ft_min_word_len” para o valor desejado e reiniciando o serviço do MySQL:

[mysqld]
…
ft_min_word_len=3

E após a alteração do banco de dados é necessário recriar os índices de pesquisa do Mediawiki para utilizar o novo padrão, para realizar esta operação entre com a seguinte query em sua base de dados:

REPAIR TABLE searchindex QUICK;

Lembrando que a tabela searchindex pode ter o nome diferente dependendo do prefixo utilizado durante a instalação do mediawiki / criação da base de dados, por exemplo, se meu prefix é “wiki_” a minha tabela terá o nome “wiki_searchindex”.

Maiores informações de fulltext search na documentação oficial do MySQL…

Lembrando que existem diversas engines que aprimoram o sistema de busca do Mediawiki, como Lucene-search e Sphinx, se seu sistema de wiki for relativamente grande ou complexo recomendo dar uma olhada…

Para acompanhar o número de downloads oficiais do Firefox está disponível o download counter oficial da Mozilla!

The PNP Developer Team has just released their new version of the graphing addon.
The last version was mainly released for some improvements of the optional “Bulkmode with NPCD” (Nagios Perfdata C Daemon), interesting for huge Nagios installations to decrease check latencies without loosing performance data processing and minor bug fixes.
For more information, screenshots and downloads just have a look at http://pnp4nagios.sourceforge.net/

Published by: Nagios Community

Review Luizxx.COM: ^^

PNP is a great graphing tool for Nagios, building detailed graphs in a organized way. I’ve been using it in some small monitoring structuresand it’s working well… With this new update it’s possible to graph data present on large monitoring structures without overloading the server and with the correct check times without loosing performance and data.

Off course you need to have a complete, structured and well managed Nagios infra-structure to use efficiently any graphing tool, specially NagiosPNP (C + PHP) and NagiosGraph (Perl + CGI)!

Primeiramente realize a instalação do MySQL em ambas as máquinas, lembrando que é altamente recomendável manter a mesma versão em todos os servidores participantes do cluster, e ative o acesso a conexões TCP (vem como padrão na maior parte das distribuições). Para prosseguir com o exemplo, consideraremos que o servidor master tem o IP 192.168.0.1 com hostname Naru e o slave tem o IP 192.168.0.2 com hostname Motoko.

Adicione os seguintes parâmetros na sessão [mysqld] do/etc/my.cnf no master:

log-bin=naru-bin
log-slave-updates
server-id=1

Agora, adicione os seguintes paramêtros no [mysqld] do /etc/my.cnf no slave:

relay-log=motoko-relay-bin
master-host=192.168.0.1
master-user=replication
master-password=mypassword
server-id=2

Inicie o serviço MySQL no servidor master e adicione um usuário com permissão de replication (em nosso caso o usuário é replication e a senha é mypassword), lembrando que esse usuário será utilizado para qualquer conexão entre os servidores :

GRANT REPLICATION SLAVE ON *.* TO ‘replication’@192.168.0.2 \
IDENTIFIED BY ‘mypassword’;

Reinicie o serviço MySQL no servidor master para fixar as alterações.

Após realizar as configurações no servidor master, inicie o serviço MySQL no servidor slave e inicie o serviço de replicação com:

START SLAVE;

Para verificar o status da replicação, utilize a seguinte sintaxe no servidor slave:

SHOW SLAVE STATUS\G;

A linha related_log_files deve indicar o arquivo correspondente, e as linhas Slave_IO_Running e Slave_SQL_Running devem estar setadas para Yes. Desta forma a replicação está sendo feita normalmente.

Lembrando que as bases devem estar em sincronia para o correto funcionamento, desta forma, os dados do servidor slave não podem ser alterados diretamente. Caso tenha algum erro ao iniciar a replicação consulte o log default do MySQL, pois os dados obtidos são bem completos e de fácil entendimento.

Normalmente o principal problema que acontece em servidores que já estão sendo utilizados em produção é a falta de sincronia entre as bases, que pode ser resolvida fazendo um dump da base master e replicando para a slave sem que haja alteração dos dados durante o processo.

Caso seja necessário realizar a alteração do servidor master enquanto a máquina slave está em produção, pode-se utilizar as seguintes sintaxes:

SLAVE STOP;
CHANGE MASTER TO master_host=”<IP do servidor master>”, \ maste_log_pos=0;
SLAVE START;

* Tendo em vista que a nova máquina master já está configurada corretamente.

A replicação pode ser realizada de várias outras formas, de acordo com as necessidades de cada ambiente, porém este tutorial indica sua utilização mais simples, normalmente utilizado em sistemas de consulta onde a carga é muito alta e deve ser distribuída.

Minha plataforma utilizada foi um RedHat Enterprise 5 rodando em 64bits, e acabei nao encontrando nenhum pacote pronto e atualizado para a instalacao. Para que nao fosse necessario compilar e instalar tudo manualmente resolvi criar o pacote com base em um spec ja existente e para aqueles que precisarem, vou disponibiliza-lo aqui para download:

Source: pyPgSQL-2.4-0.src.rpm
RedHat Advanced Server 5: pyPgSQL-2.4-0.x86_64.rpm

Apesar de nao ser muito difundido, o software e bem simples e conta com uma documentacao bem completa para a instalacao e configuracao em servidores. Os dados podem ser armazenados localmente em arquivo ou com a utilizacao de uma base de dados PostgreSQL, sendo que quando configurado para utilizar uma base de dados externa e possivel utilizar uma interface web dinamica escrita em PHP ao inves de HTML estatico e em ambos os casos a geracao dos graficos e feita com a utilizacao da biblioteca GD.

Para aqueles que utilizam sistemas RedHat/CentOS deixei disponibilizado aqui os pacotes RPM para download nas plataformas mais comuns (i386, x86_64) e disponibilizei o src.rpm para caso seja necessaria a recompilacao do pacote.

RedHat Advanced Server 5: i386 / x86_64 / Source RPM

A mais comum delas (e menos eficiente na minha opinião) é setar o horário diretamente no seu php.ini através da linha:

date.timezone = "Etc/GMT+2"

Sendo que também é possível utilizar esta chamada diretamente no script de sua aplicação com:

date_default_timezone_set("Etc/GMT+2");

A forma mais eficiente que encontrei para realizar estas transições de horário de forma automática foi utilizando o módulo php-timezonedb que está disponível através do PECL.

Para realizar a instalação do timezonedb é necessário ter as bibliotecas do php (php-dev) disponíveis na máquina.

A forma mais prática de instalação é diretamente através do repositório PECL:

# pecl install timezonedb

E para carregar o módulo na inicialização do PHP, adicione ao php.ini (ou uma entrada no php.d):

extension=timezonedb.so

Para testar o módulo sem a necessidade de reiniciar o servidor web utilize o próprio php-cli:

# php-cli -r "print date('d/m/Y H:i:s e T');"

A saída (em horário de verão) será algo parecido com:

04/02/2008 19:23:32 America/Sao_Paulo BRST

E em horário normal:

04/02/2008 19:23:32 America/Sao_Paulo BRT

Para instalação em um número elevado de servidores é recomendável utilizar o proprio empacotamento de sua distribuicaopara automatizar o processo. Para aqueles que utilizam distribuicoes baseadas em RPM, deixei o pacote source disponivel para download… php-timezonedb.el4.src.rpm

Em servidores de aplicação com base em FreeBSD ele é uma ótima alternativa e apresenta alta performance no processamento das requisições, principalmente na distribuição dos recursos da máquina entre os processos. Segue os procedimentos de instalação contando com a utilização dos ports disponíveis para o FreeBSD.

Primeiramente, atualize sua árvore de ports com:

# portsnap fetch
# portsnap update

Para iniciar a instalação, entre no diretório do port referente ao Lighttpd:

# cd /usr/ports/www/lighttpd

E execute o processo de compilação, instalação e limpeza para finalizar:

# make
# make install
# make clean

Após finalizado o processo de instalação, configure o /usr/local/etc/lighttpd.conf de acordo com seu ambiente e inicialize o serviço com:

# /usr/local/etc/rc.d/lighttpd start

Para aqueles que não estão habituados a utilizar FreeBSD, esta é a maneira mais simples de manter seu servidor funcional e atualizado, da mesma forma que utilizamos os gerenciadores de pacote no Linux, porém com a diferença de que desta forma a aplicação e compilada diretamente no servidor durante o processo de instalação.

Existem pacotes prontos para a maioria das distribuições, mas o processo de compilação é bem simples e conta com uma ótima documentação no site oficial… Basicamente toda a configuração é feita diretamente no arquivo .rtorrent.rc dentro do home de cada usuário, uma descrição geral dos parametros e um arquivo de exemplo podem ser encontrados aqui.

Adicionando e removendo torrents:

• Backspace – Abre a linha para adicionar novo arquivo .torrent e inicia imediatamente o download
• Enter - Abre a linha para adicionar novo arquivo .torrent e deixa o download parado na fila (Use ctrl+s para ativar)
• Ctrl+O – Específica nova pasta de download para o torrent selecionado (só funciona se ele ainda não foi ativado)
• Ctrl+s – Inicia o download
• Ctrl+d – Para um download ativo ou remove um download que já estava parado
• Ctrl + r – Iniciar a checagem de hash do torrent, sem iniciar download/upload.

Controle de velocidade:

• a / s / d – Aumenta a velocidade de upload em 1/5/50 KB
• z / x / c – Diminui a velocidade de upload em 1/5/50 KB
• Utilizar letras maiúsculas para controle de velocidade de download…

Lembrando sempre que os limites são aplicados de forma global, e não por torrent.

Utilização geral:

• Ctrl + q – Inicia o shutdown do client, já informando os trackers
• + / – - Define a prioridade dos torrents
• | – Ver os logs (aperte espaço para voltar)

Consulte também o guia oficial de utilização

Um dos principais fatores a serem considerados é a especificação do hardware utilizado e a preparação do sistema operacional. Ao utilizar RAID no servidor, prefira implementar em RAID0, que apresenta a melhor performance e dê preferência para realizar o armazenamento de cache e dos logs do Squid em um volume (preferencialmente com discos diferentes) separado, como estes dados normalmente são armazenados no /var, crie um ponto de montagem sobre a pasta apontando para seu volume. A escolha do sistema de arquivos também é um fator extremamente importante para otimizar o funcionamento, além do desempenho é necessário ter estabilidade na manipulação dos dados.

Um ponto crítico que pode fazer com que os usuários sintam lentidão ao utilizar a internet através do proxy é a resolução de nomes (DNS), para aumentar o desempenho na resolução de nomes é recomendável configurar um DNS cache na mesma máquina ou em uma máquina conectada diretamente ao proxy.

Existem alguns parâmetros que devem ser corretamente configurados no squid.conf de modo a otimizar o funcionamento. Segue uma breve descrição dos dois principais:

cache_mem

Esta opção informa ao Squid a quantidade de memória dedicada ao processo (podendo aumentar dependendo da demanda), sendo que em máquinas dedicadas à utilização de proxy podemos definir cerca de 80% da memória total da máquina.

maximum_object_size

Com esta diretiva podemos limitar o tamanho máximo dos objetos em cache para que objetos maiores do que o valor máximo aqui informado não sejam enviados para o disco. Um valor alto pode contribuir com uma maior economia de banda, porém pode causar uma utilização maior dos discos podendo aumentar o tempo de resposta em ambientes de alto tráfego. É recomendada a utilização de um valor entre 4 e 16MB (16384 KB).

A utilização de diversos caches separados em volumes diferentes pode contribuir para otimizar o armazenamento de dados e aumentar a performance do acesso a internet porém não interfere diretamente na performance do servidor.

Já a definição do método de acesso ao cache (store type) oferece difereças significativas na forma como o servidor acessa os discos. Os métodos mais utilizados são ufs, aufs, diskd e coss. Sendo que normalmente o sistema aufs apresenta ótima performance e facilidade de implementação (não depende de daemos externos) na maioria dos casos.

Existem ótimas alternativas para configuração de ambientes grandes onde existem milhares de hosts passando pelo proxy ao mesmo tempo para a distribuição de carga (um tipo de clusterização) em diversos servidores interligados entre si através de ICP, mas esse já é um tipo de instalação bem específica onde temos que fazer um levantamento bem detalhado do ambiente na implementação.