Tempos atrás publiquei um post em meu blog falando sobre ferramentas de backup onde comentei sobre o RESTORE, e falei que o que me incomodava a respeito desse projeto era que eu não havia encontrado os fontes para download.
Pois bem: hoje recebi um e-mail do Presidente/CTO da Holonix onde ele me esclarecia os locais para download dos fontes, que são:
http://trac.holonyx.com/svn/restore/
http://sourceforge.net/svn/?group_id=198657
http://rubyforge.org/scm/?group_id=4561
Segue abaixo o e-mail na íntegra:
Saw a mention on your blog about RESTORE, we do indeed supply FULL sources for RESTORE, mirrored in at least three public locations.
http://trac.holonyx.com/svn/restore/
http://sourceforge.net/svn/?group_id=198657
http://rubyforge.org/scm/?group_id=4561
Also, there have been huge changes lately, I don't have the VM or Live CD done yet but .deb packages are always available at
http://distro.ruffdogs.com/restore/
Thanks so much for your attention to this project.
--
Garret Acott
President/CTO
Holonyx, Inc
970.232.2050
Ficam aqui minhas desculpas sobre a informação equivocada.
Assim que sobrar um tempo irei testar a última versão dessa ferramenta e postarei sobre isso aqui no blog.
sexta-feira, 23 de novembro de 2007
quinta-feira, 22 de novembro de 2007
Usando o pdnsd para fazer cache local de DNS
O pdns é uma ferramenta desenvolvida para fazer cache local de DNS em seu desktop/servidor.
Mas por que motivo cachear o DNS ?
O cache local de DNS permite uma maior velocidade de navegação (principalmente em conexões lentas) pois evita que sempre que seja preciso resolver um nome seja necessário consultar um servidor DNS externo.
Além disso também garante uma maior disponibilidade de resolução de nomes no caso do servidor DNS externo apresentar problemas, o que evita que você, por exemplo, não possa navegar (obviamente o pdnsd só resolverá os endereços já cacheados, mas isso com certeza já ajuda muito).
Configurando
O pdns usa o arquivo de configuração /etc/pdnsd.conf.
Nesse arquivo é preciso informar os servidores DNS externos (podem ser um ou mais) onde o pdnsd irá conectar para resolver o nome que não está ainda cacheado e também como o pdnsd irá trabalhar (TTLs, diretórios de armazenamento, entre outras coisas).
Segue como exemplo uma configuração básica do pdnsd usando o DNS do Terra como exemplo (200.176.2.10):
Atenção: Se você usa DHCP é normal que o resolv.conf seja reescrito sempre que o IP for "adquirido". Nesse caso, será sempre necessário alterar o arquivo após o computador "pegar" o IP.
E como funciona exatamente ?
Ao consultar o endereço, o pdnsd primeiro tenta localizar o endereço no cache. Se o endereço existir, ele vai verificar o TTL do mesmo. Caso o TTL não tenha ainda expirado, o IP cacheado será usado.
Caso o TTL tenha expirado ou o endereço não exista em cache, o pdnsd então irá procurar o endereço solicitado nos servidores DNS externos configurados.
Para quem quer uma navegação mais dinâmica, seja por pouca banda ou mesmo só para otimizar um pouco a velocidade, o pdnsd é uma opção interessante e de simples instalação, tanto para servidores quanto para desktops.
Mas por que motivo cachear o DNS ?
O cache local de DNS permite uma maior velocidade de navegação (principalmente em conexões lentas) pois evita que sempre que seja preciso resolver um nome seja necessário consultar um servidor DNS externo.
Além disso também garante uma maior disponibilidade de resolução de nomes no caso do servidor DNS externo apresentar problemas, o que evita que você, por exemplo, não possa navegar (obviamente o pdnsd só resolverá os endereços já cacheados, mas isso com certeza já ajuda muito).
Configurando
O pdns usa o arquivo de configuração /etc/pdnsd.conf.
Nesse arquivo é preciso informar os servidores DNS externos (podem ser um ou mais) onde o pdnsd irá conectar para resolver o nome que não está ainda cacheado e também como o pdnsd irá trabalhar (TTLs, diretórios de armazenamento, entre outras coisas).
Segue como exemplo uma configuração básica do pdnsd usando o DNS do Terra como exemplo (200.176.2.10):
É preciso também alterar o /etc/resolv.conf de forma que o nameserver seja o localhost, deixando nele somente a seguinte linha:
// $Id: pdnsd.conf.in,v 1.4 2000/11/11 20:32:58 thomas Exp $
global {
perm_cache=512; # Tamanho maximo do cache em disco (em Kb)
cache_dir="/var/cache/pdnsd"; # Local do armazenamento do cache
max_ttl=604800; # TTL (Time to Live) em segundos. 1 semana
run_as="pdnsd";
paranoid=off; # Se for on, consulta sempre o DNS externo
# caso contrario usa o cache
status_ctl=on;
}
server {
ip="200.176.2.10"; # IP do Server DNS externo
timeout=30;
interval=30;
uptest=ping;
ping_timeout=50;
purge_cache=off;
}
source {
ttl=86400; # TTL do /etc/hosts (padrão 1 dia)
owner="localhost.";
file="/etc/hosts";
}
nameserver 127.0.0.1
Atenção: Se você usa DHCP é normal que o resolv.conf seja reescrito sempre que o IP for "adquirido". Nesse caso, será sempre necessário alterar o arquivo após o computador "pegar" o IP.
E como funciona exatamente ?
Ao consultar o endereço, o pdnsd primeiro tenta localizar o endereço no cache. Se o endereço existir, ele vai verificar o TTL do mesmo. Caso o TTL não tenha ainda expirado, o IP cacheado será usado.
Caso o TTL tenha expirado ou o endereço não exista em cache, o pdnsd então irá procurar o endereço solicitado nos servidores DNS externos configurados.
Para quem quer uma navegação mais dinâmica, seja por pouca banda ou mesmo só para otimizar um pouco a velocidade, o pdnsd é uma opção interessante e de simples instalação, tanto para servidores quanto para desktops.
quarta-feira, 21 de novembro de 2007
KDE 4 RC1 - Pacotes disponíveis para Kubuntu 7.10
terça-feira, 20 de novembro de 2007
Usando impressoras fiscais Bematech no Linux via USB
Quem compra algum modelo de impressora fiscal Bematech que vem com USB (ex: MP3000) e tenta usar no Linux já deve ter percebido que não consegue fazer o software dela funcionar, apesar da mesma ser reconhecida normalmente pelo SO.
Pois é: realmente a aplicação fornecida pelo fabricante (bematech.out) não funciona se a impressora for ligada via USB no Linux.
O problema se dá pela seguinte razão: a impressora ao ser plugada no Linux via USB emula uma porta paralela e o software fornecido só trabalha com portas seriais.
Ao plugar a mesma num Ubuntu é criado automaticamente um /dev/usblp0. Configurando o software da impressora para mapear a porta usando esse device, ao tentarmos rodar o mesmo ele informa que houve problema com a porta serial. Foi percebido após alguns debugs que o software usa ioctl (que só funciona com portas seriais), e isso acaba causando o erro.
Em contato com o suporte da fabricante, a informação é de que realmente a impressora não funciona no Linux se plugada na porta USB, mas existe um projeto para desenvolver um software compatível que não tem ainda nem previsão de início, quanto mais de release.
E por enquanto o jeito mesmo é usar a boa e velha porta serial...
PS: se você desenvolver um software para isso, por favor depois poste aqui o link para os sources. ;-)
Pois é: realmente a aplicação fornecida pelo fabricante (bematech.out) não funciona se a impressora for ligada via USB no Linux.
O problema se dá pela seguinte razão: a impressora ao ser plugada no Linux via USB emula uma porta paralela e o software fornecido só trabalha com portas seriais.
Ao plugar a mesma num Ubuntu é criado automaticamente um /dev/usblp0. Configurando o software da impressora para mapear a porta usando esse device, ao tentarmos rodar o mesmo ele informa que houve problema com a porta serial. Foi percebido após alguns debugs que o software usa ioctl (que só funciona com portas seriais), e isso acaba causando o erro.
Em contato com o suporte da fabricante, a informação é de que realmente a impressora não funciona no Linux se plugada na porta USB, mas existe um projeto para desenvolver um software compatível que não tem ainda nem previsão de início, quanto mais de release.
E por enquanto o jeito mesmo é usar a boa e velha porta serial...
PS: se você desenvolver um software para isso, por favor depois poste aqui o link para os sources. ;-)
Firefox 3 - Beta 1 disponível para download.
Está disponível para download o Beta 1 do Firefox 3.
Agora de "maneira oficial", já que aparentemente o mesmo havia vazado na semana anterior.
Para mais informações e links para download, clique aqui.
Agora de "maneira oficial", já que aparentemente o mesmo havia vazado na semana anterior.
Para mais informações e links para download, clique aqui.
sábado, 17 de novembro de 2007
Ubuntu lança atualização "bugada" do Samba
Quem usa o Samba com Ubuntu Dapper (6.06) e atualizou os pacotes ontem deve ter passado por uma surpresa bem desagradável.
A atualização liberada (3.0.22-1ubuntu3.4) estava bugada e a autenticação no domínio usando máquinas Windows parou de funcionar.
Logo após ao meio-dia (horário de Brasília) os pacotes foram removidos, mas aí já era pra muita gente.
A solução encontrada naquele momento foi fazer o downgrade pra versão anterior (3.0.22-1ubuntu3.3) para que tudo voltasse a funcionar.
Consultei hoje e já percebi que saiu uma nova versão (3.0.22-1ubuntu3.5), mas ainda não tive como testar. Segunda eu vejo.
Se alguém já testou, poste seus comentários.
Espero que o pessoal do Ubuntu tenha mais cuidado com essas coisas. Já é a segunda vez em pouco mais de 1 ano que eles lançam pacotes problemáticos.
Boa sorte para nós. :-)
UPDATE (19/11) : Segue a URL do bug.
A atualização liberada (3.0.22-1ubuntu3.4) estava bugada e a autenticação no domínio usando máquinas Windows parou de funcionar.
Logo após ao meio-dia (horário de Brasília) os pacotes foram removidos, mas aí já era pra muita gente.
A solução encontrada naquele momento foi fazer o downgrade pra versão anterior (3.0.22-1ubuntu3.3) para que tudo voltasse a funcionar.
Consultei hoje e já percebi que saiu uma nova versão (3.0.22-1ubuntu3.5), mas ainda não tive como testar. Segunda eu vejo.
Se alguém já testou, poste seus comentários.
Espero que o pessoal do Ubuntu tenha mais cuidado com essas coisas. Já é a segunda vez em pouco mais de 1 ano que eles lançam pacotes problemáticos.
Boa sorte para nós. :-)
UPDATE (19/11) : Segue a URL do bug.
sexta-feira, 16 de novembro de 2007
Ainda sobre rsync (agora com Ubuntu)
Em um post anterior, falei sobre haverem restrições do uso do rsync no Ubuntu.
Resolvi fazer um post espefíco sobre o assunto, para ajudar quem como eu passou por problemas assim.
As restrições resumem-se basicamente a três fatores principalmente:
1) Filesystems temporários
2) Uso de UUIDs ao invés de devices
3) Interfaces persistentes (vínculo entre mac address da placa e nome da interface)
Normalmente, no caso de uma sincronia de servidores temos 2 maneiras distintas de fazê-lo:
A) Podemos sincronizar o servidor em cima de um HD vazio, mas já particionado.
B) Podemos sincronizar o servidor em cima de um base system previamente instalado.
Maneira A
A maneira A é a mais "complicada" delas pois é preciso ter cuidado com os 3 fatores listados acima. Vamos por partes:
Fator 1:
O fator 1 é o que necessita de maior cuidado pois está ligado a forma de boot do Ubuntu (o fator 2 também tem relação com o boot, mas conseguimos bootar o servidor usando um init=/bin/bash, por exemplo). Para que o Ubuntu possa bootar é necessário que exista no filesystem root ( /) um diretório /var/run e um diretório /var/lock.
Essas pastas são necessárias antes que o /var seja montado (se ele for uma partição separada). Caso esses diretórios não existam o Ubuntu não irá bootar.
Solução: Ao criar a partição / (que normalmente é uma partição à parte, pois o /var normalmente é outra partição), crie os diretórios /var/run e /var/lock para garantir que seu Ubuntu suba.
ATENÇÃO: nunca efetuei diretamente a operação dessa maneira. Estou relatando o que é necessário para o sistema bootar, baseado em pesquisas e comentários encontrados pela rede (normalmente uso a segunda forma de sincronia para garantir o pleno funcionamento - com o base system pré instalado. Demora mais, mas é mais seguro :-) ). Se você optar sincronizar direto no HD vazio criando os diretórios, depois relate sua experiência, por favor.
Fator 2: O Ubuntu, ao invés de trabalhar com devices no /etc/fstab e no /boot/grub/menu.lst, trabalha já há algumas versões com UUIDs (não vou entrar no mérito de vantagens e desvantagens, muito menos dispor sobre o porque da mudança). Se esse formato não for alterado para o formato "antigo" (arquivos de dispositivos - /dev/sda1 ou /dev/hda1, por exemplo), ao tentar bootar o novo servidor, o sistema não irá subir pois não encontrará as partições.
Solução: Após sincronizar todo o servidor, antes de rebootar o mesmo, retorne seus arquivos /etc/fstab e /boot/grub/menu.lst para o formato convencional de device (no fstab, o nome do device está inclusive comentando na linha anterior). Sincronizando dessa forma, seu novo servidor não irá ter problemas no boot. Dica: no root do menu.lst coloque o device onde está o /.
Fator 3: O Ubuntu (7.10) guarda as interfaces de rede e seus respectivos nomes (nada mais do que um vínculo do mac address da placa de rede com o nome "ethX") no arquivo /etc/udev/rules.d/70-persistent-net.rules (O Debian Etch usa o arquivo /etc/udev/rules.d/z25_persistent-net.rules de forma similar). Ao trazer esse arquivo do servidor antigo o servidor novo pode por exemplo então passar a reconhecer a sua eth0 como eth1 (pois a eth0 já vai estar associada ao mac da placa do servidor antigo).
Solução: Apague o arquivo /etc/udev/rules.d/70-persistent-net.rules. Com isso ele será recriado corretamente no próximo boot. Ou ainda, não sincronize o mesmo, colocando-o na lista de exclusão do rsyncd.conf.
ATENÇÃO: do Ubuntu 6.06 ao Ubuntu 7.04 e no Debian Sarge o nome do arquivo é /etc/iftab.
Maneira B
A maneira B é mais simples, pois será necessário lidar somente com os fatores 2 e 3 já explicados acima.
Acredito que com essas dicas, os problemas de usar o rsync com o Ubuntu sejam todos solucionados.
Pelo menos até o lançamento da versão 8.04 ;-)
Resolvi fazer um post espefíco sobre o assunto, para ajudar quem como eu passou por problemas assim.
As restrições resumem-se basicamente a três fatores principalmente:
1) Filesystems temporários
2) Uso de UUIDs ao invés de devices
3) Interfaces persistentes (vínculo entre mac address da placa e nome da interface)
Normalmente, no caso de uma sincronia de servidores temos 2 maneiras distintas de fazê-lo:
A) Podemos sincronizar o servidor em cima de um HD vazio, mas já particionado.
B) Podemos sincronizar o servidor em cima de um base system previamente instalado.
Maneira A
A maneira A é a mais "complicada" delas pois é preciso ter cuidado com os 3 fatores listados acima. Vamos por partes:
Fator 1:
O fator 1 é o que necessita de maior cuidado pois está ligado a forma de boot do Ubuntu (o fator 2 também tem relação com o boot, mas conseguimos bootar o servidor usando um init=/bin/bash, por exemplo). Para que o Ubuntu possa bootar é necessário que exista no filesystem root ( /) um diretório /var/run e um diretório /var/lock.
Essas pastas são necessárias antes que o /var seja montado (se ele for uma partição separada). Caso esses diretórios não existam o Ubuntu não irá bootar.
Solução: Ao criar a partição / (que normalmente é uma partição à parte, pois o /var normalmente é outra partição), crie os diretórios /var/run e /var/lock para garantir que seu Ubuntu suba.
ATENÇÃO: nunca efetuei diretamente a operação dessa maneira. Estou relatando o que é necessário para o sistema bootar, baseado em pesquisas e comentários encontrados pela rede (normalmente uso a segunda forma de sincronia para garantir o pleno funcionamento - com o base system pré instalado. Demora mais, mas é mais seguro :-) ). Se você optar sincronizar direto no HD vazio criando os diretórios, depois relate sua experiência, por favor.
Fator 2: O Ubuntu, ao invés de trabalhar com devices no /etc/fstab e no /boot/grub/menu.lst, trabalha já há algumas versões com UUIDs (não vou entrar no mérito de vantagens e desvantagens, muito menos dispor sobre o porque da mudança). Se esse formato não for alterado para o formato "antigo" (arquivos de dispositivos - /dev/sda1 ou /dev/hda1, por exemplo), ao tentar bootar o novo servidor, o sistema não irá subir pois não encontrará as partições.
Solução: Após sincronizar todo o servidor, antes de rebootar o mesmo, retorne seus arquivos /etc/fstab e /boot/grub/menu.lst para o formato convencional de device (no fstab, o nome do device está inclusive comentando na linha anterior). Sincronizando dessa forma, seu novo servidor não irá ter problemas no boot. Dica: no root do menu.lst coloque o device onde está o /.
Fator 3: O Ubuntu (7.10) guarda as interfaces de rede e seus respectivos nomes (nada mais do que um vínculo do mac address da placa de rede com o nome "ethX") no arquivo /etc/udev/rules.d/70-persistent-net.rules (O Debian Etch usa o arquivo /etc/udev/rules.d/z25_persistent-net.rules de forma similar). Ao trazer esse arquivo do servidor antigo o servidor novo pode por exemplo então passar a reconhecer a sua eth0 como eth1 (pois a eth0 já vai estar associada ao mac da placa do servidor antigo).
Solução: Apague o arquivo /etc/udev/rules.d/70-persistent-net.rules. Com isso ele será recriado corretamente no próximo boot. Ou ainda, não sincronize o mesmo, colocando-o na lista de exclusão do rsyncd.conf.
ATENÇÃO: do Ubuntu 6.06 ao Ubuntu 7.04 e no Debian Sarge o nome do arquivo é /etc/iftab.
Maneira B
A maneira B é mais simples, pois será necessário lidar somente com os fatores 2 e 3 já explicados acima.
Acredito que com essas dicas, os problemas de usar o rsync com o Ubuntu sejam todos solucionados.
Pelo menos até o lançamento da versão 8.04 ;-)
quarta-feira, 14 de novembro de 2007
Openfire - Nova atualização do Sip Phone Plugin
Após relatar no fórum da Ignite Realtime sobre o problema que estava tendo com esse plugin, o usuário barata7 (Thiago), desenvolvedor do mesmo corrigiu o bug e postou nova versão (1.0.2) solucionando o problema de teste de contas SIP.
Ainda assim continuo com problemas, mas agora ele mudou, pois recebo um timeout quando efetuo os testes.
Já reportei o caso, e vamos ver o que acontece agora. :-)
Ainda assim continuo com problemas, mas agora ele mudou, pois recebo um timeout quando efetuo os testes.
Já reportei o caso, e vamos ver o que acontece agora. :-)
terça-feira, 13 de novembro de 2007
Openfire - atualizado o plugin Sip Phone
Saiu a versão 1.0.1 do plugin Sip Phone.
Como única novidade, a correção de um bug que gerava incompatibilidade com o PostgreSQL e possivelmente outros DBs também (eles não citam quais).
Apesar da atualização, eu ainda continuo "lutando" com o mesmo para fazê-lo funcionar com o nosso servidor Asterisk.
Assim que resolver o problema irei postar tudo sobre esse plugin aqui.
Como única novidade, a correção de um bug que gerava incompatibilidade com o PostgreSQL e possivelmente outros DBs também (eles não citam quais).
Apesar da atualização, eu ainda continuo "lutando" com o mesmo para fazê-lo funcionar com o nosso servidor Asterisk.
Assim que resolver o problema irei postar tudo sobre esse plugin aqui.
Sincronizando computadores com rsync
Às vezes é necessário sincronizar dados entre servidores ou até mesmo copiar um servidor inteiro para outro hardware. Uma aplicação fantástica para essas tarefas é o rsync.
O rsync é uma ferramenta open source que permite a transferência de arquivos de forma incremental. Além disso, ela pode também ser usada para sincronia entre micros, partições e diretórios.
Nesse post, vou supor que seja necessário sincronizar um servidor inteiro para outro. Vou também supor que o kernel do Linux não seja compilado especificamente para o hardware, ou se for o caso, que os dois hardwares sejam idênticos. Também estou supondo que o particionamento dos discos seja igual, ou que ao menos existam as mesmas partições vinculadas aos mesmos devices (os tamanhos dos particionamentos podem ser diferentes (assim como os tipos de sistemas de arquivos), mas se obviamente o seu particionamento destino for menor que o origem os dados poderão não caber).
A melhor forma de uso do rsync para esse tipo de tarefa, do meu ponto de vista, é como cliente/servidor.
Configurando o servidor (origem dos dados)
No caso de seu micro origem ser um Debian (ou Ubuntu), será necessário antes de mais nada permitir que o daemon do rsync possa ser iniciado. Para isso deve-se alterar a opção RSYNC_ENABLE de false para true no arquivo /etc/default/rsync.
Depois é preciso configurar o arquivo /etc/rsyncd.conf.
Para ficar bem genérico, pode-se deixar o mesmo da seguinte forma:
Esse configuração lhe dá acesso a todo o sistema de arquivos, com permissão somente de escrita.
Na linha exclude você deverá setar os arquivos e/ou diretórios que não devem ser sincronizados (separe os mesmos por espaço).
Depois disso já é possível iniciar o daemon.
ATENÇÃO: não aconselho manter o daemon ativo dessa forma, por questões óbvias de segurança (que não serão tratadas nesse post). Use o mesmo e desabilite-o logo em seguida.
Sincronizando o cliente (destino)
Supondo que seu servidor de origem tenha 4 partições ( /, /usr, /var e /home ), você pode rodar 4 comandos rsync no cliente para pegar os dados partição a partição (apesar de ser possível sincronizar direto o / teríamos de separar uma série de pastas que não necessariamente precisam ser sincronizadas. Além disso a opção x garante que o somente a partição selecionada seja trazida sem invadir outros pontos de montagem temporários como /var/run, /var/lock, entre outros ):
Obviamente você pode adicionar outras partições se for o caso (ou remover também).
Explicando os parâmetros
A opção -a aciona o modo arquivo e é o mesmo que a opção -rlptgoD (recursivo, com cópia de symlinks, preservando permissões, preservando data e hora, preservando grupos, preservando proprietários e preservando arquivos especiais e de devices).
A opção v ativa o mode verboso.
A opção x ativa o backup do filesystem principal, sem entrar recursivamente nos demais.
A opção --delete faz com que os arquivos do destino que não existem na origem sejam apagados, para garantir que os dados sejam os mesmos nos dois lados.
O ip será o do seu servidor de origem (onde foi configurado o rsync servidor).
O root (logo após o ::) é o nome do "compartilhamento" que você setou no servidor.
Logo após o parâmetro "root" vem então o que você quer copiar (se for diretório, sempre é necessário finalizar com o /).
E por final, você deve informar o destino pra onde vão os dados (novamente, se for diretório, finalize com /).
Exemplos explicados
Ex: rsync -avx --delete ip::root/etc/ /tmp/
Irá sincronizar todo o conteúdo da pasta etc dentro da pasta tmp.
Ex: rsync -avx --delete ip::root/etc /tmp/
Irá sincronizar a pasta /etc dentro da pasta tmp (ou seja, existirá um /tmp/etc).
Considerações
Esse procedimento já foi testado com sucesso em servidores Debian até a versão 4.0 (Etch). No Ubuntu o mesmo também pode ser utilizado, mas com restrições, principalmente na sincronização do /, pois a forma de trabalho dos tmpfs do Ubuntu pode gerar problemas na hora de bootar o servidor (estamos estudando no momento uma forma de fazer isso com segurança).
Finalizando
Para finalizar acho que é importante lembrar que essa é apenas uma das possibilidades de uso do rsync, e que a ferramenta merece ser mais explorada pois pode ser usada no dia a dia de qualquer usuário, seja ele um administrador de sistema ou um usuário final.
Para mais informações consulte aqui e aqui.
O rsync é uma ferramenta open source que permite a transferência de arquivos de forma incremental. Além disso, ela pode também ser usada para sincronia entre micros, partições e diretórios.
Nesse post, vou supor que seja necessário sincronizar um servidor inteiro para outro. Vou também supor que o kernel do Linux não seja compilado especificamente para o hardware, ou se for o caso, que os dois hardwares sejam idênticos. Também estou supondo que o particionamento dos discos seja igual, ou que ao menos existam as mesmas partições vinculadas aos mesmos devices (os tamanhos dos particionamentos podem ser diferentes (assim como os tipos de sistemas de arquivos), mas se obviamente o seu particionamento destino for menor que o origem os dados poderão não caber).
A melhor forma de uso do rsync para esse tipo de tarefa, do meu ponto de vista, é como cliente/servidor.
Configurando o servidor (origem dos dados)
No caso de seu micro origem ser um Debian (ou Ubuntu), será necessário antes de mais nada permitir que o daemon do rsync possa ser iniciado. Para isso deve-se alterar a opção RSYNC_ENABLE de false para true no arquivo /etc/default/rsync.
Depois é preciso configurar o arquivo /etc/rsyncd.conf.
Para ficar bem genérico, pode-se deixar o mesmo da seguinte forma:
[root]
path=/
uid=0
gid=0
read only=true
exclude=/etc/network/interfaces /etc/hostname
Esse configuração lhe dá acesso a todo o sistema de arquivos, com permissão somente de escrita.
Na linha exclude você deverá setar os arquivos e/ou diretórios que não devem ser sincronizados (separe os mesmos por espaço).
Depois disso já é possível iniciar o daemon.
ATENÇÃO: não aconselho manter o daemon ativo dessa forma, por questões óbvias de segurança (que não serão tratadas nesse post). Use o mesmo e desabilite-o logo em seguida.
Sincronizando o cliente (destino)
Supondo que seu servidor de origem tenha 4 partições ( /, /usr, /var e /home ), você pode rodar 4 comandos rsync no cliente para pegar os dados partição a partição (apesar de ser possível sincronizar direto o / teríamos de separar uma série de pastas que não necessariamente precisam ser sincronizadas. Além disso a opção x garante que o somente a partição selecionada seja trazida sem invadir outros pontos de montagem temporários como /var/run, /var/lock, entre outros ):
rsync -avx --delete ip::root/ /
rsync -avx --delete ip::root/usr/ /usr/
rsync -avx --delete ip::root/var/ /var/
rsync -avx --delete ip::root/home/ /home/
Obviamente você pode adicionar outras partições se for o caso (ou remover também).
Explicando os parâmetros
A opção -a aciona o modo arquivo e é o mesmo que a opção -rlptgoD (recursivo, com cópia de symlinks, preservando permissões, preservando data e hora, preservando grupos, preservando proprietários e preservando arquivos especiais e de devices).
A opção v ativa o mode verboso.
A opção x ativa o backup do filesystem principal, sem entrar recursivamente nos demais.
A opção --delete faz com que os arquivos do destino que não existem na origem sejam apagados, para garantir que os dados sejam os mesmos nos dois lados.
O ip será o do seu servidor de origem (onde foi configurado o rsync servidor).
O root (logo após o ::) é o nome do "compartilhamento" que você setou no servidor.
Logo após o parâmetro "root" vem então o que você quer copiar (se for diretório, sempre é necessário finalizar com o /).
E por final, você deve informar o destino pra onde vão os dados (novamente, se for diretório, finalize com /).
Exemplos explicados
Ex: rsync -avx --delete ip::root/etc/ /tmp/
Irá sincronizar todo o conteúdo da pasta etc dentro da pasta tmp.
Ex: rsync -avx --delete ip::root/etc /tmp/
Irá sincronizar a pasta /etc dentro da pasta tmp (ou seja, existirá um /tmp/etc).
Considerações
Esse procedimento já foi testado com sucesso em servidores Debian até a versão 4.0 (Etch). No Ubuntu o mesmo também pode ser utilizado, mas com restrições, principalmente na sincronização do /, pois a forma de trabalho dos tmpfs do Ubuntu pode gerar problemas na hora de bootar o servidor (estamos estudando no momento uma forma de fazer isso com segurança).
Finalizando
Para finalizar acho que é importante lembrar que essa é apenas uma das possibilidades de uso do rsync, e que a ferramenta merece ser mais explorada pois pode ser usada no dia a dia de qualquer usuário, seja ele um administrador de sistema ou um usuário final.
Para mais informações consulte aqui e aqui.
segunda-feira, 12 de novembro de 2007
Intel lança nova linha de processadores.
Via Zumo.
A Intel lançou ontem sua nova linha de processadores chamada Penryn.
Sua principal novidade é o Core 2 de 45 nm, que reduz em 25% o tamanho do chip em relação a um equivalente de 65nm.
Com isso o custo de produção deve ser reduzido e o custo do processador também deve baratear para o usuário final. Não agora no lançamento, é claro, quando o mesmo está sendo vendido a US$ 999 para lotes de mil peças.
A matéria completa você pode ler aqui.
Leia também sobre os chips de 45nm no site da Intel.
A Intel lançou ontem sua nova linha de processadores chamada Penryn.
Sua principal novidade é o Core 2 de 45 nm, que reduz em 25% o tamanho do chip em relação a um equivalente de 65nm.
Com isso o custo de produção deve ser reduzido e o custo do processador também deve baratear para o usuário final. Não agora no lançamento, é claro, quando o mesmo está sendo vendido a US$ 999 para lotes de mil peças.
A matéria completa você pode ler aqui.
Leia também sobre os chips de 45nm no site da Intel.
sábado, 10 de novembro de 2007
Mais sobre os eventos comunitários do fisl
Mais um ano que chega ao final e lá estamos nós de novo abrindo as inscrições dos eventos comunitários do fisl. Bom sinal !!! :-)
Já é o quarto ano que cuido dos ECs e pela quarta vez consecutiva teremos mudanças neles (afinal precisamos evitar a rotina não é ?).
Só para recapitular, segue um pequeno histórico dos ECs no fisl, para quem não conhece:
No fisl 6.0, os ECs eram chamados de pré-eventos, pois ocorriam um dia antes da abertura oficial do Fórum. Na época 29 ECs foram realizados, a maioria deles em simples salas de aula da PUCRS, e os mesmos foram um sucesso e contaram com grande público. Tivemos tanta demanda que as sessões foram realizadas do turno da manhã até o turno de noite. E valeu qualquer improviso, até mesmo o Randal Schwartz "transformando o laptop dele em um AP (Access Point)" durante um evento do Perl para prover wireless para todo o resto do pessoal da sala. :-)
No fisl 7.0 houve a mudança pra FIERGS. Espaço novo, formato "novo", um dia a mais de evento (oficial), e a "criação" dos eventos comunitários propriamente ditos, agora fazendo parte da grade oficial. Isso deu um aspecto mais "formal" para os ECs que puderam contar com a mesma estrutura das palestras, pois usavam as mesmas salas. Por outro lado, em função dos mesmos agora fazerem parte da grade, o número máximo de sessões por evento foi reduzido para 3. Nessa edição tivemos 30 ECs realizados.
Chegou então o fisl 8.0 que teve a redução de um dia, e que trouxe como mudança para os ECs basicamente a diminuição do número de espaços na grade, algo inevitável. Ainda assim os mesmos foram um sucesso. Claro que devido a redução da duração do evento, tivemos uma queda nos números, o que fez com que somente 25 ECs fossem realizados nesse ano.
E agora ? O que tem de novo ?
No fisl 9.0, como não poderia deixar de ser diferente, novas mudanças nos Eventos Comunitários estão a caminho. Como os ECs já fazem parte da grade do fisl há 3 edições, acreditamos que devemos tomar algumas medidas que visem melhorar os mesmos e ajudem a aumentar o nível do fisl de uma forma geral. Esperamos que essas mudanças também possam ajudar a aumentar a qualidade dos eventos propostos. São elas:
A maioria das mudanças visa garantir mais espaço efetivamente para os grupos e comunidades, já que os ECs foram criados exatamente com esse intuito: dar espaço para que as comunidade e grupos de SL possam se encontrar, debater e além de tudo ajudar a construir o fisl.
Já especificamente na parte dos Papers , pecamos por não ter desenvolvido a tempo um formulário específico para os ECs, obrigando os mesmos a usar o formulário padrão (que não tem todos os campos). Dessa forma, pedimos que os proponentes tentem enquadrar todas as informações da melhor forma possível dentro do formulário disponível.
Espero que as mudanças sejam compreendidas e aceitas, pois a intenção da Organização é sempre fazer o fisl melhor do que o do ano anterior. Certamente não podemos agradar a todos, mas de qualquer forma isso faz parte e quando decidimos mudar já tínhamos consciência disso.
É isso aí. Aguardo as inscrições de vocês e os espero no fisl 9.0, agora de volta à PUCRS pra alegria de muita gente (inclusive a minha).
Até lá.
:-)
Já é o quarto ano que cuido dos ECs e pela quarta vez consecutiva teremos mudanças neles (afinal precisamos evitar a rotina não é ?).
Só para recapitular, segue um pequeno histórico dos ECs no fisl, para quem não conhece:
No fisl 6.0, os ECs eram chamados de pré-eventos, pois ocorriam um dia antes da abertura oficial do Fórum. Na época 29 ECs foram realizados, a maioria deles em simples salas de aula da PUCRS, e os mesmos foram um sucesso e contaram com grande público. Tivemos tanta demanda que as sessões foram realizadas do turno da manhã até o turno de noite. E valeu qualquer improviso, até mesmo o Randal Schwartz "transformando o laptop dele em um AP (Access Point)" durante um evento do Perl para prover wireless para todo o resto do pessoal da sala. :-)
No fisl 7.0 houve a mudança pra FIERGS. Espaço novo, formato "novo", um dia a mais de evento (oficial), e a "criação" dos eventos comunitários propriamente ditos, agora fazendo parte da grade oficial. Isso deu um aspecto mais "formal" para os ECs que puderam contar com a mesma estrutura das palestras, pois usavam as mesmas salas. Por outro lado, em função dos mesmos agora fazerem parte da grade, o número máximo de sessões por evento foi reduzido para 3. Nessa edição tivemos 30 ECs realizados.
Chegou então o fisl 8.0 que teve a redução de um dia, e que trouxe como mudança para os ECs basicamente a diminuição do número de espaços na grade, algo inevitável. Ainda assim os mesmos foram um sucesso. Claro que devido a redução da duração do evento, tivemos uma queda nos números, o que fez com que somente 25 ECs fossem realizados nesse ano.
E agora ? O que tem de novo ?
No fisl 9.0, como não poderia deixar de ser diferente, novas mudanças nos Eventos Comunitários estão a caminho. Como os ECs já fazem parte da grade do fisl há 3 edições, acreditamos que devemos tomar algumas medidas que visem melhorar os mesmos e ajudem a aumentar o nível do fisl de uma forma geral. Esperamos que essas mudanças também possam ajudar a aumentar a qualidade dos eventos propostos. São elas:
- As inscrições deverão ser feitas através do papers: com isso poderemos aprimorar a organização, centralizando as informações e otimizando os processos.
- Os coordenadores dos ECs deverão tentar encaixar seu EC em 1 sessão. Duas sessões só serão concedidas mediante justificativa que será avaliada pela organização: essa certamente é uma medida que deve desagradar muitos, mas que foi necessária para que possamos aumentar a qualidade do fisl.
- Os eventos que tiverem uma comunidade e/ou grupo de usuários vinculado terão prioridade de aprovação: já que na realidade esse é o objetivo do eventos comunitários, como o próprio nome já diz, essa medida visa garantir os espaços dos ECs para quem é de direito.
- Não serão aceitos ECs que tenham o objetivo de divulgar projetos e/ou softwares. Nesses casos, o proponente deverá inscrever sua palestra na trilha que for mais apropriada: essa medida também visa garantir os espaços para as comunidades, já que apresentar um projeto ou software não caracteriza necessariamente um EC. Nesses casos, essa palestra deve ser cadastrada nas trilhas e aguardar a avaliação do Temário.
- Eventos que não sejam vinculados diretamente a software livre serão reprovados: já que o fórum é sobre software livre, decidimos dar espaço nos ECs especificamente para eventos que tenham relação direta com o tema. Outros tipos de palestras (de cunho filosófico, político ou social por exemplo) deverão ser inscritas na trilha respectiva e irão passar pela avaliação do Temário, já que esse não é o objetivo dos ECs.
- Um coordenador de EC só poderá coordenar um, e somente um, evento comunitário no fisl 9.0: com isso poderemos dar mais espaço para pessoas diferentes poderem ter seu EC no fisl.
A maioria das mudanças visa garantir mais espaço efetivamente para os grupos e comunidades, já que os ECs foram criados exatamente com esse intuito: dar espaço para que as comunidade e grupos de SL possam se encontrar, debater e além de tudo ajudar a construir o fisl.
Já especificamente na parte dos Papers , pecamos por não ter desenvolvido a tempo um formulário específico para os ECs, obrigando os mesmos a usar o formulário padrão (que não tem todos os campos). Dessa forma, pedimos que os proponentes tentem enquadrar todas as informações da melhor forma possível dentro do formulário disponível.
Espero que as mudanças sejam compreendidas e aceitas, pois a intenção da Organização é sempre fazer o fisl melhor do que o do ano anterior. Certamente não podemos agradar a todos, mas de qualquer forma isso faz parte e quando decidimos mudar já tínhamos consciência disso.
É isso aí. Aguardo as inscrições de vocês e os espero no fisl 9.0, agora de volta à PUCRS pra alegria de muita gente (inclusive a minha).
Até lá.
:-)
sexta-feira, 9 de novembro de 2007
Abertas as inscrições para os Eventos Comunitários do fisl9.0
Estão abertas as inscrições.
Não perca tempo e inscreva seu Evento Comunitário já.
Para saber mais sobre como fazer a inscrição e sobre as novas mudanças, acesse aqui.
Aguardo vocês. :-)
Não perca tempo e inscreva seu Evento Comunitário já.
Para saber mais sobre como fazer a inscrição e sobre as novas mudanças, acesse aqui.
Aguardo vocês. :-)
Ainda sobre o Asterisk IM 1.4.0
Encontrei no site da Ignite Realtime uma thread falando especificamente sobre o problema que estou tendo com este plugin, e parece que mais gente está passando por situações similares desde o lançamento dessa nova versão.
O mais interessante é que depois instalado, a conexão com o servidor Asterisk resolveu ficar ativa (o que não estava acontecendo), mas ainda não testei para verificar se as funções estão funcionando corretamente.
Vamos aguardar pra ver o resultado disso...
O mais interessante é que depois instalado, a conexão com o servidor Asterisk resolveu ficar ativa (o que não estava acontecendo), mas ainda não testei para verificar se as funções estão funcionando corretamente.
Vamos aguardar pra ver o resultado disso...
quarta-feira, 7 de novembro de 2007
Propus - apresentação de case no VoIPCenter 2007
Marlon Dutra, um dos diretores da Propus (empresa onde trabalho), apresenta hoje um de nossos cases no VoIPCenter & Asterisk On-Line 2007.
A palestra será "Case de sucesso: Guascor Empreendimentos Energéticos".
Resumo: "A empresa Guascor possui cinco grandes escritórios, onde cada um deles recebeu um servidor VoIP. Cada servidor possui um E1 de voz com a rede pública, e todos eles são interligados por MPLS, com QoS (DiffServ). Todas as chamadas entre filiais são feitas internamente, com ramais de 4 dígitos. Chamadas externas sempre são encaminhadas pela rota de menor custo. O case vai mostrar que além da grande adição de tecnologia, houve uma redução forte nos custos de comunicação, justificando todo o investimento e manutenção da plataforma."
Ainda esse ano, no fisl8.0, ele já havia apresentado um outro case de sucesso nosso.
O programa completo do evento, pode ser visto aqui.
A palestra será "Case de sucesso: Guascor Empreendimentos Energéticos".
Resumo: "A empresa Guascor possui cinco grandes escritórios, onde cada um deles recebeu um servidor VoIP. Cada servidor possui um E1 de voz com a rede pública, e todos eles são interligados por MPLS, com QoS (DiffServ). Todas as chamadas entre filiais são feitas internamente, com ramais de 4 dígitos. Chamadas externas sempre são encaminhadas pela rota de menor custo. O case vai mostrar que além da grande adição de tecnologia, houve uma redução forte nos custos de comunicação, justificando todo o investimento e manutenção da plataforma."
Ainda esse ano, no fisl8.0, ele já havia apresentado um outro case de sucesso nosso.
O programa completo do evento, pode ser visto aqui.
Asterisk IM versão 1.4.0
Juntamente com a versão do Openfire 3.4 saiu a nova versão do plugin Asterisk IM.
Pode-se perceber de imediato que na tela de cadastro do vínculo do JID com o ramal SIP aparece um ComboBox com todos os devices disponíveis (que ele lê diretamente do Asterisk), o que pode evitar erros e garantir um cadastro correto.
Mas para quem prefere digitar, ainda existe um text box para agilizar o processo.
O changelog completo pode ser visto aqui.
Bem interessante !
Pode-se perceber de imediato que na tela de cadastro do vínculo do JID com o ramal SIP aparece um ComboBox com todos os devices disponíveis (que ele lê diretamente do Asterisk), o que pode evitar erros e garantir um cadastro correto.
Mas para quem prefere digitar, ainda existe um text box para agilizar o processo.
O changelog completo pode ser visto aqui.
Bem interessante !
terça-feira, 6 de novembro de 2007
Openfire 3.4.1 disponível
Saiu a versão 3.4.1 do Openfire, que está disponível aqui.
Ainda não instalei a mesma, mas pude ver que ela tem uma série de novas features e bugs fixes.
Entre todos, acho que o mais interessante deles é o recurso de clustering, que vem somente disponível na versão enterprise.
É instalar pra ver...
UPDATE: Ao instalar a versão 3.4.1, o plugin do Asterisk IM foi atualizado para a versão 1.4 e parou de comunicar com o servidor. Logo, resolvi fazer um downgrade para versão 3.3.3 que está mais estável (ao menos nesse caso...)
UPDATE2 (07/11): Instalei a versão 3.4.1 em outra rede que rodava Asterisk 1.2 e o mesmo funcionou perfeitamente...
Ainda não instalei a mesma, mas pude ver que ela tem uma série de novas features e bugs fixes.
Entre todos, acho que o mais interessante deles é o recurso de clustering, que vem somente disponível na versão enterprise.
É instalar pra ver...
UPDATE: Ao instalar a versão 3.4.1, o plugin do Asterisk IM foi atualizado para a versão 1.4 e parou de comunicar com o servidor. Logo, resolvi fazer um downgrade para versão 3.3.3 que está mais estável (ao menos nesse caso...)
UPDATE2 (07/11): Instalei a versão 3.4.1 em outra rede que rodava Asterisk 1.2 e o mesmo funcionou perfeitamente...
quarta-feira, 31 de outubro de 2007
Auth-client-config
Outra ferramenta que vem já com a nova versão do Ubuntu é o auth-client-config.
auth-client-config é um script python que modifica os arquivos de configuração do pam e o nsswitch.conf auxiliando nas configurações de autenticação. Ele pode ser usado por administradores de sistema para efetuar de forma fácil e rápida as configurações destes.
Ainda não utilizei a ferramenta, mas acho que a mesma pode ser bastante interessante e que merece um post. A possibilidade de criação de profiles é algo que pode agilizar muito em casos de instalações em larga escala.
Se alguém já usou e tem mais informações, fique à vontade para postar um comentário.
auth-client-config é um script python que modifica os arquivos de configuração do pam e o nsswitch.conf auxiliando nas configurações de autenticação. Ele pode ser usado por administradores de sistema para efetuar de forma fácil e rápida as configurações destes.
Ainda não utilizei a ferramenta, mas acho que a mesma pode ser bastante interessante e que merece um post. A possibilidade de criação de profiles é algo que pode agilizar muito em casos de instalações em larga escala.
Se alguém já usou e tem mais informações, fique à vontade para postar um comentário.
Mudanças na autenticação via LDAP do Ubuntu 7.10
Quem usa autenticação por LDAP e instalou a nova versão do Ubuntu (7.10 - Gutsy Gibbon) deve ter percebido que as coisas mudaram um pouco.
Além de corrigir os bugs das versões anteriores (principalmente a inexistência do grupo nvram que fazia o boot levar "séculos"), os arquivos de configuração mudaram. E para melhor.
Agora, ao invés de ter de configurar o libnss-ldap.conf e o pam_ldap.conf, basta configurar o arquivo ldap.conf que fica no /etc. Ele tem basicamente a mesma estrutura destes o que não será um problema pra quem já sabia como proceder nas versões anteriores.
Muito mais simples...
Além de corrigir os bugs das versões anteriores (principalmente a inexistência do grupo nvram que fazia o boot levar "séculos"), os arquivos de configuração mudaram. E para melhor.
Agora, ao invés de ter de configurar o libnss-ldap.conf e o pam_ldap.conf, basta configurar o arquivo ldap.conf que fica no /etc. Ele tem basicamente a mesma estrutura destes o que não será um problema pra quem já sabia como proceder nas versões anteriores.
Muito mais simples...
sábado, 27 de outubro de 2007
Openfire - uma análise mais completa
Tenho percebido uma grande movimentação em meu blog que vem de pessoas que a cada dia que passam buscam mais e mais informações sobre Jabber (XMPP - leia mais aqui e aqui), mais especificamente sobre o servidor Jabber Openfire.
O Openfire é um servidor Jabber desenvolvido em Java pela Ignite Realtime. Acompanho o mesmo desde os tempos em que se chamava Wildfire e ainda estava na versão 2.x. Desde lá ele passou por inúmeras melhorias, recebendo mais recursos e aprimorando os que já existiam (como a autenticação LDAP, por exemplo).
O Openfire tem uma gama imensa de recursos, sendo que do meu ponto de vista um dos mais interessantes é o uso de plugins, que permitem extender as funcionalidades do servidor.
Existe quase uma dezena de plugins disponíveis (e outros que já estão em desenvolvimento), dos quais dois eu acho que merecem um destaque especial:
E a instalação ?
Requisitos básicos para instalação: Java JRE (recomendo a versão 6 update 3), MySQL (dê preferência para a versão 5, que tem suporte a replicação) e um servidor LDAP (opcional, que pode ser usado para autenticação).
Como meu negócio é software livre, eu vou falar da versão pra Linux, é claro.
A instalação é toda via Browser. Antes é claro você precisará abrir o .tar.gz que você baixou (ou instalar o .rpm), instalar o MySQL, criar o DB, o usuário do DB e dar as permissões de acesso ao mesmo. Depois disso basta apontar o browser para o domínio, na porta 9090 e seguir os passos (ex: http://localhost:9090). Claro que isso irá instalar um servidor básico. O resto das configurações são depois feitas pela interface web de administração, ou editando o arquivo openfire.xml que fica na pasta conf, dentro da pasta Openfire.
Já instalei o servidor, e agora ?
Depois do servidor instalado se você estiver usando LDAP para autenticar os usuários e se tiver feito tudo corretamente, basta começar a configurar e conectar os clientes.
Se você não usar LDAP será necessário logar na interface administrativa e criar os usuários e grupos manualmente. Nesse aspecto o Openfire é super bacana. Você pode criar grupos de usuários que se enxergam automaticamente entre si, fazendo com que não seja necessário que os usuários se adicionem uns aos outros na suas listas. Você pode criar vários grupos e fazer com que eles se vejam ou não. Você pode inclusive colocar nos grupos usuários de outros domínios jabber, já que você pode interconectar as redes usando o protocolos s2s.
Essa é outra feature muito legal do Openfire. Você pode permitir que seu servidor se conecte a qualquer outro servidor Jabber, ou você pode fazer uma black list de servidores que não podem ser conectar ao seu servidor, ou ainda uma whitelist só com os servidores que podem ser conectar. No caso da empresa onde trabalho, nosso servidor se conecta somente aos servidores jabber de nossos clientes e com isso podemos incluir contatos dos nossos clientes sem precisar ter um usuário jabber na rede deles. Muito prático.
Outro recurso disponível é a criação de salas de conferência. Você pode configurar os membros que podem acessar a sala, uma senha para acesso e uma série de opções que possibilitam e/ou limitam o que os membros podem fazer na sala.
As mensagens offline também tem uma configuração específica. Você pode armazenar as mesmas (e configurar o que fazer quando o limite de espaço de armazenamento for excedido), pular (não armazenar e informar o remetente) ou liberar (não armazenar e nem avisar o remetente que a mensagem não será entregue).
Com relação a auditoria (que é recurso pelo qual tenho percebido grande interesse por parte dos visitantes do blog), é possível configurar o Openfire para armazenar as mensagens em arquivos de logs (separados por usuário) em uma pasta a ser espeficada, até um limite de espaço a ser determinado (por usuário e total). Você pode configurar por quantos dias os logs serão armazenados (pode ser indefinidamente) e os pacotes a serem auditados. Também é possível informar uma lista de usuários que não deverão ser auditados. Quanto a auditoria, 2 questões devem ser esclarecidas: primeiro, o Openfire não tem um visualizador de logs de auditoria, cabendo a você desenvolver um próprio e segundo, se você utilizar gateways para outros protocolos (MSN, ICQ, etc...) essas mensagens também serão auditadas, o que parece ser algo pelo qual os administradores tem tido muito interesse ultimamente.
Outro recurso que pode ser importante, dependendo da situação é possibilidade de ativar compressão entre o cliente e o servidor. Isso pode ajudar a diminuir o uso de banda em conexões de pouca largura.
Acho que por último e não menos importante também é a capacidade do Openfire de transferir arquivos (ou desabilitar essa feature) entre os clientes. É um padrão do protocolo XMPP, mas merece certamente ser citado, pois muitas pessoas tem dúvidas se isso é possível com Jabber.
Obviamente existem outros recursos que poderiam ser citados mas acho que os principais já foram elencados acima.
E o que vem pela frente ?
A última versão estável é a 3.3.3 sendo que a 3.4 está em desenvolvimento (o programa de beta testing vai até o dia 31 de outubro - próxima quarta) e sua principal novidade será o suporte a clustering permitindo distribuir a carga entre vários servidores que servem o mesmo domínio, além é claro de diminuir o downtime, pois caso uma máquina falhe outra irá continuar atendendo.
Concluindo...
Do meu ponto de vista o Openfire é o servidor que oferece os melhores recursos entre todos os servidores Jabber que conheço e eu com certeza o recomendo para pequenas e médias instalações.
Como já disse num post anterior, não sei informar se ele seria capaz de atender um domínio como o jabber.org, por exemplo, ou que hardware seria necessário para suportar a média de 8000 conexões simultâneas deste.
Se você quiser testar, por favor depois me relate como foi sua experiência.
UPDATE (28/10 - 15:39): Informações adicionais sobre os bancos de dados suportados foram adicionados nos comentários.
UPDATE (25/01): Criada a lista de e-mail Openfire-BR. Saiba mais.
O Openfire é um servidor Jabber desenvolvido em Java pela Ignite Realtime. Acompanho o mesmo desde os tempos em que se chamava Wildfire e ainda estava na versão 2.x. Desde lá ele passou por inúmeras melhorias, recebendo mais recursos e aprimorando os que já existiam (como a autenticação LDAP, por exemplo).
O Openfire tem uma gama imensa de recursos, sendo que do meu ponto de vista um dos mais interessantes é o uso de plugins, que permitem extender as funcionalidades do servidor.
Existe quase uma dezena de plugins disponíveis (e outros que já estão em desenvolvimento), dos quais dois eu acho que merecem um destaque especial:
- Asterisk-IM que "integra" o Openfire com seu servidor Asterisk
- Gateway IM que integra sua rede Jabber com outros protocolos como MSN, ICQ, AIM, etc... Este em particular eu já havia usado em sua versão Beta, época em que cada transporte (gateway) era um plugin diferente e bastante instável. Nessa última versão (que já não é mais beta) o plugin está muito melhor e mais prático.
E a instalação ?
Requisitos básicos para instalação: Java JRE (recomendo a versão 6 update 3), MySQL (dê preferência para a versão 5, que tem suporte a replicação) e um servidor LDAP (opcional, que pode ser usado para autenticação).
Como meu negócio é software livre, eu vou falar da versão pra Linux, é claro.
A instalação é toda via Browser. Antes é claro você precisará abrir o .tar.gz que você baixou (ou instalar o .rpm), instalar o MySQL, criar o DB, o usuário do DB e dar as permissões de acesso ao mesmo. Depois disso basta apontar o browser para o domínio, na porta 9090 e seguir os passos (ex: http://localhost:9090). Claro que isso irá instalar um servidor básico. O resto das configurações são depois feitas pela interface web de administração, ou editando o arquivo openfire.xml que fica na pasta conf, dentro da pasta Openfire.
Já instalei o servidor, e agora ?
Depois do servidor instalado se você estiver usando LDAP para autenticar os usuários e se tiver feito tudo corretamente, basta começar a configurar e conectar os clientes.
Se você não usar LDAP será necessário logar na interface administrativa e criar os usuários e grupos manualmente. Nesse aspecto o Openfire é super bacana. Você pode criar grupos de usuários que se enxergam automaticamente entre si, fazendo com que não seja necessário que os usuários se adicionem uns aos outros na suas listas. Você pode criar vários grupos e fazer com que eles se vejam ou não. Você pode inclusive colocar nos grupos usuários de outros domínios jabber, já que você pode interconectar as redes usando o protocolos s2s.
Essa é outra feature muito legal do Openfire. Você pode permitir que seu servidor se conecte a qualquer outro servidor Jabber, ou você pode fazer uma black list de servidores que não podem ser conectar ao seu servidor, ou ainda uma whitelist só com os servidores que podem ser conectar. No caso da empresa onde trabalho, nosso servidor se conecta somente aos servidores jabber de nossos clientes e com isso podemos incluir contatos dos nossos clientes sem precisar ter um usuário jabber na rede deles. Muito prático.
Outro recurso disponível é a criação de salas de conferência. Você pode configurar os membros que podem acessar a sala, uma senha para acesso e uma série de opções que possibilitam e/ou limitam o que os membros podem fazer na sala.
As mensagens offline também tem uma configuração específica. Você pode armazenar as mesmas (e configurar o que fazer quando o limite de espaço de armazenamento for excedido), pular (não armazenar e informar o remetente) ou liberar (não armazenar e nem avisar o remetente que a mensagem não será entregue).
Com relação a auditoria (que é recurso pelo qual tenho percebido grande interesse por parte dos visitantes do blog), é possível configurar o Openfire para armazenar as mensagens em arquivos de logs (separados por usuário) em uma pasta a ser espeficada, até um limite de espaço a ser determinado (por usuário e total). Você pode configurar por quantos dias os logs serão armazenados (pode ser indefinidamente) e os pacotes a serem auditados. Também é possível informar uma lista de usuários que não deverão ser auditados. Quanto a auditoria, 2 questões devem ser esclarecidas: primeiro, o Openfire não tem um visualizador de logs de auditoria, cabendo a você desenvolver um próprio e segundo, se você utilizar gateways para outros protocolos (MSN, ICQ, etc...) essas mensagens também serão auditadas, o que parece ser algo pelo qual os administradores tem tido muito interesse ultimamente.
Outro recurso que pode ser importante, dependendo da situação é possibilidade de ativar compressão entre o cliente e o servidor. Isso pode ajudar a diminuir o uso de banda em conexões de pouca largura.
Acho que por último e não menos importante também é a capacidade do Openfire de transferir arquivos (ou desabilitar essa feature) entre os clientes. É um padrão do protocolo XMPP, mas merece certamente ser citado, pois muitas pessoas tem dúvidas se isso é possível com Jabber.
Obviamente existem outros recursos que poderiam ser citados mas acho que os principais já foram elencados acima.
E o que vem pela frente ?
A última versão estável é a 3.3.3 sendo que a 3.4 está em desenvolvimento (o programa de beta testing vai até o dia 31 de outubro - próxima quarta) e sua principal novidade será o suporte a clustering permitindo distribuir a carga entre vários servidores que servem o mesmo domínio, além é claro de diminuir o downtime, pois caso uma máquina falhe outra irá continuar atendendo.
Concluindo...
Do meu ponto de vista o Openfire é o servidor que oferece os melhores recursos entre todos os servidores Jabber que conheço e eu com certeza o recomendo para pequenas e médias instalações.
Como já disse num post anterior, não sei informar se ele seria capaz de atender um domínio como o jabber.org, por exemplo, ou que hardware seria necessário para suportar a média de 8000 conexões simultâneas deste.
Se você quiser testar, por favor depois me relate como foi sua experiência.
UPDATE (28/10 - 15:39): Informações adicionais sobre os bancos de dados suportados foram adicionados nos comentários.
UPDATE (25/01): Criada a lista de e-mail Openfire-BR. Saiba mais.
sexta-feira, 26 de outubro de 2007
Superkaramba
Como muitos eu tenho o meu lado usuário que adora um Desktop visualmente bacana e com extensões legais (preferem widgets ?) mas que ao mesmo tempo sejam também úteis.
Por isso, nunca deixo de instalar o SuperKaramba onde quer que eu esteja. O SuperKaramba é uma ferramenta que permite instalar (e até mesmo criar) widgets para seu desktop KDE.
Ele é muito popular e existem centenas de temas disponíveis para o mesmo na página do KdeLook.org. É incrível o que você encontra lá: desde temas para IM, mail, música, monitoração, até leitores de RSS e de comics online. Muito bom.
Entre os temas que eu não dispenso estão:
Kroller: o Kroller cria uma barra de menus similar a do Mac OSX que dá um visual muito bacana ao Desktop além de ser de uma praticidade incrível. Tente usar uma vez e você nunca mais conseguirá ficar sem ele.
Aero AIO: O Aero AIO é um tema que mostra todas as informações de seu computador. Uso de memória, CPU, rede, disco, versão de kernel, uptime, entre outras. Conta ainda com uma série de plugins que podem ser instalados para aumentar a quantidade de itens a serem monitorados.
Liquid Weather: O Liquid Weather é o melhor tema e software que já vi pra previsão do tempo. Cheio de recursos e de uma visual incrível, supera quaisquer outros softwares do tempo como o KWeather o e plugin ForecastFox do Firefox. Sensacional !
Se você como eu gosta desse tipo de recursos no Desktop, o SuperKaramba foi feito pra você.
Por isso, nunca deixo de instalar o SuperKaramba onde quer que eu esteja. O SuperKaramba é uma ferramenta que permite instalar (e até mesmo criar) widgets para seu desktop KDE.
Ele é muito popular e existem centenas de temas disponíveis para o mesmo na página do KdeLook.org. É incrível o que você encontra lá: desde temas para IM, mail, música, monitoração, até leitores de RSS e de comics online. Muito bom.
Entre os temas que eu não dispenso estão:
Kroller: o Kroller cria uma barra de menus similar a do Mac OSX que dá um visual muito bacana ao Desktop além de ser de uma praticidade incrível. Tente usar uma vez e você nunca mais conseguirá ficar sem ele.
Aero AIO: O Aero AIO é um tema que mostra todas as informações de seu computador. Uso de memória, CPU, rede, disco, versão de kernel, uptime, entre outras. Conta ainda com uma série de plugins que podem ser instalados para aumentar a quantidade de itens a serem monitorados.
Liquid Weather: O Liquid Weather é o melhor tema e software que já vi pra previsão do tempo. Cheio de recursos e de uma visual incrível, supera quaisquer outros softwares do tempo como o KWeather o e plugin ForecastFox do Firefox. Sensacional !
Se você como eu gosta desse tipo de recursos no Desktop, o SuperKaramba foi feito pra você.
OpenVPN
Falando em túneis e VPNs uma ferramenta muito útil e com uma imensa gama de recurso é o OpenVPN.
O OpenVPN é uma solução de VPN que usa autenticação por chaves o que aumenta muito a segurança da conexão.
Por ser muito flexível e parametrizável, ela pode ser implementada de várias formas. Você pode implementar sua VPN peer to peer (usando tun) ou então pode fazer com que seu micro cliente receba um IP da rede onde você está conectado (usando tap - no Linux isso demanda algumas outras modificações, inclusive no proxy ARP. Se alguém tiver interesse por favor contate-me.). Seja qual for a forma usada, você poderá implementar roteamento para os demais micros de sua rede usando a OpenVPN. Além disso você também pode implementar sua VPN usando TCP ou UDP. A escolha é sua.
A configuração da OpenVPN é bastante simples, sendo relativamente similar no lado cliente e no lado servidor. No lado do servidor você irá utilizar o arquivo server.conf. No lado do client, se você usar Linux, você pode criar um arquivo .conf para cada cliente onde deseje conectar e deixar todos na pasta /etc/openvpn (Debian ou Ubuntu). Na realidade o OpenVpn lê todos os arquivos .conf da pasta e executa os procedimentos de cada um (levanta um servidor, conecta na rede A, conecta na rede B, etc...)
Como a autenticação se faz por chaves, você precisará criar uma autoridade certificadora que irá assinar os certificados de todos os clientes que irão conectar no servidor. Se tiver dúvidas de como fazer isso, leia meu post anterior sobre openssl e geração de certificados. Além disso será necessário gerar uma chave específica também para cada cliente.
E se por ventura, sua máquina cliente rodar Windows, fique tranquilo: para essa plataforma existe o cliente OpenVPN Gui que se aloja na tray area, e que pelo menu de contexto permite que você conecte e desconecte de sua VPN com praticidade. O arquivo de configuração do mesmo é similar ao do Linux, mas a extensão muda de .conf para .opvn. Os parâmetros são exatamente os mesmos só mudando a forma de indicar os caminhos dos certificados e arquivos de log, é claro.
Se for o caso, você também pode instalar seu cliente OpenVPN Windows como um serviço, fazendo com que sua VPN seja automaticamente conectada ao ligar o micro (eu particulamente prefiro subir a mesma quando se faz necessário, seja no Linux ou no Windows).
Como você pode perceber o OpenVPN é uma ferramenta muito útil e com uma vasta lista de features, o que me permitiria escrever páginas e páginas sobre ele. Como em blogs posts muito longos ficam extremamente maçantes e a intenção do mesmo é ter textos curtos com análises de ferramentas em geral, caso você queria mais informações ou somente queria trocar uma idéia me envie um e-mail.
O OpenVPN é uma solução de VPN que usa autenticação por chaves o que aumenta muito a segurança da conexão.
Por ser muito flexível e parametrizável, ela pode ser implementada de várias formas. Você pode implementar sua VPN peer to peer (usando tun) ou então pode fazer com que seu micro cliente receba um IP da rede onde você está conectado (usando tap - no Linux isso demanda algumas outras modificações, inclusive no proxy ARP. Se alguém tiver interesse por favor contate-me.). Seja qual for a forma usada, você poderá implementar roteamento para os demais micros de sua rede usando a OpenVPN. Além disso você também pode implementar sua VPN usando TCP ou UDP. A escolha é sua.
A configuração da OpenVPN é bastante simples, sendo relativamente similar no lado cliente e no lado servidor. No lado do servidor você irá utilizar o arquivo server.conf. No lado do client, se você usar Linux, você pode criar um arquivo .conf para cada cliente onde deseje conectar e deixar todos na pasta /etc/openvpn (Debian ou Ubuntu). Na realidade o OpenVpn lê todos os arquivos .conf da pasta e executa os procedimentos de cada um (levanta um servidor, conecta na rede A, conecta na rede B, etc...)
Como a autenticação se faz por chaves, você precisará criar uma autoridade certificadora que irá assinar os certificados de todos os clientes que irão conectar no servidor. Se tiver dúvidas de como fazer isso, leia meu post anterior sobre openssl e geração de certificados. Além disso será necessário gerar uma chave específica também para cada cliente.
E se por ventura, sua máquina cliente rodar Windows, fique tranquilo: para essa plataforma existe o cliente OpenVPN Gui que se aloja na tray area, e que pelo menu de contexto permite que você conecte e desconecte de sua VPN com praticidade. O arquivo de configuração do mesmo é similar ao do Linux, mas a extensão muda de .conf para .opvn. Os parâmetros são exatamente os mesmos só mudando a forma de indicar os caminhos dos certificados e arquivos de log, é claro.
Se for o caso, você também pode instalar seu cliente OpenVPN Windows como um serviço, fazendo com que sua VPN seja automaticamente conectada ao ligar o micro (eu particulamente prefiro subir a mesma quando se faz necessário, seja no Linux ou no Windows).
Como você pode perceber o OpenVPN é uma ferramenta muito útil e com uma vasta lista de features, o que me permitiria escrever páginas e páginas sobre ele. Como em blogs posts muito longos ficam extremamente maçantes e a intenção do mesmo é ter textos curtos com análises de ferramentas em geral, caso você queria mais informações ou somente queria trocar uma idéia me envie um e-mail.
Vtun - Minha conexão já era...
Após instalar o Ubuntu Gutsy Gibbon (7.10) me deparei com o seguinte problema: não consigo mais fechar um túnel Vtun com servidores rodando Debian ou outras versões mais antigas do Ubuntu.
Acredito ser um problema de versão, pois o Gutsy traz a versão 3.0 do Vtun enquanto as outras distribuições "mais antigas" ainda usam a versão 2 do mesmo.
Se você passou por algo similar e conseguiu resolver a questão, por favor me mande um e-mail com a solução. :-)
Se eu encontrar a resposta, irei postar aqui no blog.
Acredito ser um problema de versão, pois o Gutsy traz a versão 3.0 do Vtun enquanto as outras distribuições "mais antigas" ainda usam a versão 2 do mesmo.
Se você passou por algo similar e conseguiu resolver a questão, por favor me mande um e-mail com a solução. :-)
Se eu encontrar a resposta, irei postar aqui no blog.
quinta-feira, 25 de outubro de 2007
Eventos comunitários no fisl 9.0
Atenção:
nos próximos dias estarão sendo abertas as inscrições para os eventos comunitários do fisl 9.0.
Para quem ainda não sabe ou não conhece, os eventos comunitários são conferências e encontros de comunidades, propostos e organizados por seus próprios integrantes que ocorrem dentro da grade do fisl.
Fiquem ligados!!!
9º Fórum Internacional Software Livre - fisl9.0
17, 18 e 19 de abril de 2008
Porto Alegre RS Brasil
nos próximos dias estarão sendo abertas as inscrições para os eventos comunitários do fisl 9.0.
Para quem ainda não sabe ou não conhece, os eventos comunitários são conferências e encontros de comunidades, propostos e organizados por seus próprios integrantes que ocorrem dentro da grade do fisl.
Fiquem ligados!!!
9º Fórum Internacional Software Livre - fisl9.0
17, 18 e 19 de abril de 2008
Porto Alegre RS Brasil
quarta-feira, 24 de outubro de 2007
Gerando certificados com o OpenSSL
Gerar certificados é uma tarefa que eventualmente se faz necessária.
Pensando em facilitar esse processo (que eu particularmente acho meio chato e que nunca lembro exatamente de todos seus passos), resolvi criar um script para isso.
Para que o mesmo funcione é necessário que você tenha o certificado da CA (autoridade certificadora) que irá efetuar a assinatura e a senha deste.
Segue:
Se você quiser mais informações, pode ver esse pequeno howto criado pelo Marlon Dutra (que eu tomei por base para gerar o meu script).
Pensando em facilitar esse processo (que eu particularmente acho meio chato e que nunca lembro exatamente de todos seus passos), resolvi criar um script para isso.
Para que o mesmo funcione é necessário que você tenha o certificado da CA (autoridade certificadora) que irá efetuar a assinatura e a senha deste.
Segue:
#!/bin/bash
# geraCert.sh
# Parametros
# $1 = nome do certificado a ser gerado
# $2 = nome do certificado da CA
if [ "$1" = "" ]; then
echo
echo 'Sintaxe: geraCert.sh nome do certificado nome da CAnome do certificado nome da CA '
echo
exit
fi
if [ "$2" = "" ]; then
echo
echo 'Sintaxe: geraCert.sh'
echo
exit
fi
if [ ! -f "./$2.crt" ]; then
echo
echo Arquivo $2.crt não encontrado
echo
exit
fi
# Gera uma nova chave
openssl genrsa -out $1.key 1024
# Gera uma requisição de assinatura
openssl req -new -key $1.key -out $1.csr
# Gera um certificado assinado através da requisição (5 anos)
openssl x509 -days 1825 -CA $2.crt -CAkey $2.key -in $1.csr -req -out $1.crt
# Visualiza o certificado
openssl x509 -text -noout -in $1.crt
# Verifica a assinatura
openssl verify -CAfile $2.crt $1.crt
Se você quiser mais informações, pode ver esse pequeno howto criado pelo Marlon Dutra (que eu tomei por base para gerar o meu script).
Convertendo timestamps
Você como eu já deve ter precisado converter um timestamp em uma data "legível".
Para isso, segue um script que faz exatamente isso (Atenção, ele usa Perl e necessita da ctime.pl).
Espero que seja útil.
Para isso, segue um script que faz exatamente isso (Atenção, ele usa Perl e necessita da ctime.pl).
#!/bin/bash
# timestamp.sh
#
# Parametros
# $1 = timestamp
if [ "$1" = "" ]; then
echo
echo 'Sintaxe: timestamp.sh timestamp'
echo
exit
fi
EPOCH=$1
DATE=$(perl -e "require 'ctime.pl'; print &ctime($EPOCH);")
echo $DATE
Espero que seja útil.
Configurando o Nagios com o Nagios Web Config
O Nagios é uma ferramenta muito interessante (e eficiente) para monitorar serviços e servidores. Só que por outro lado, uma das coisas mais maçantes e tediosas que existem é ter de configurar o mesmo. São horas e horas em cima de vários arquivos de configurações para poder colocá-lo em funcionamento.
Mas com o Nagios Web Config isso tudo fica diferente.
O Nagios Web Config é um software que serve para configurar os hosts, serviços, grupos de hosts, comandos e todas as demais configurações do Nagios (exceto a configuração inicial do mesmo) de forma visual e prática utilizando para isso o seu browser. Por isso mesmo, ele já foi planejado para ser implementado na própria sidebar do Nagios, o que facilita ainda mais seu uso.
E como ele trabalha ? Ao ir adicionando/deletando/editando as configurações ele vai armazenando as mesmas em um DB MySQL. Depois você pode solicitar que ele escreva as configurações e ele próprio irá gerar os arquivos necessários sem que haja necessidade de editá-los manualmente. Além disso, como os dados ficam num DB caso você precise reinstalar o servidor (ou por exemplo decida colocar o Nagios em outro servidor), não haverá necessidade de refazer todas as configurações.
Como nem tudo são flores, a instalação dele junto a um Nagios recém instalado pode ser meio "chata", sendo necessário gerar algumas configurações básicas do Nagios para que o mesmo no mínimo consiga ser iniciado. Ou seja, você não vai escapar de ter de meter a mão nos arquivos do Nagios no início, mas depois tudo vai ficar muito mais simples. Pode confiar.
Sem dúvida é uma excelente ferramenta para otimizar esses processos de configuração e que com certeza ajudará muito a manter seu Nagios sempre atualizado, e o melhor, de forma bem simples. :-)
Mas com o Nagios Web Config isso tudo fica diferente.
O Nagios Web Config é um software que serve para configurar os hosts, serviços, grupos de hosts, comandos e todas as demais configurações do Nagios (exceto a configuração inicial do mesmo) de forma visual e prática utilizando para isso o seu browser. Por isso mesmo, ele já foi planejado para ser implementado na própria sidebar do Nagios, o que facilita ainda mais seu uso.
E como ele trabalha ? Ao ir adicionando/deletando/editando as configurações ele vai armazenando as mesmas em um DB MySQL. Depois você pode solicitar que ele escreva as configurações e ele próprio irá gerar os arquivos necessários sem que haja necessidade de editá-los manualmente. Além disso, como os dados ficam num DB caso você precise reinstalar o servidor (ou por exemplo decida colocar o Nagios em outro servidor), não haverá necessidade de refazer todas as configurações.
Como nem tudo são flores, a instalação dele junto a um Nagios recém instalado pode ser meio "chata", sendo necessário gerar algumas configurações básicas do Nagios para que o mesmo no mínimo consiga ser iniciado. Ou seja, você não vai escapar de ter de meter a mão nos arquivos do Nagios no início, mas depois tudo vai ficar muito mais simples. Pode confiar.
Sem dúvida é uma excelente ferramenta para otimizar esses processos de configuração e que com certeza ajudará muito a manter seu Nagios sempre atualizado, e o melhor, de forma bem simples. :-)
mkntpwd
Uma ferramenta que eu sempre preciso e nunca encontro é o mkntpwd.
Ele serve para criar os password hashes do Samba que são armazenados nos atributos de senha do mesmo no LDAP.
Ele é utilizado principalmente pelo PhpLdapAdmin, mas também se faz necessário na ferramenta de administração LDAP criada pela Propus.
Ou seja, sempre que preciso instalar a mesma eu nunca acho os fontes. Por isso resolvi criar um post sobre o assunto pra não perder mais o link.
Você pode baixar os fontes do mkntpwd aqui.
Ele serve para criar os password hashes do Samba que são armazenados nos atributos de senha do mesmo no LDAP.
Ele é utilizado principalmente pelo PhpLdapAdmin, mas também se faz necessário na ferramenta de administração LDAP criada pela Propus.
Ou seja, sempre que preciso instalar a mesma eu nunca acho os fontes. Por isso resolvi criar um post sobre o assunto pra não perder mais o link.
Você pode baixar os fontes do mkntpwd aqui.
Gmail vai começar a suportar IMAP
Deu no Google Operating System e no Google Blogoscoped.
O Gmail começou a suportar também IMAP. Para setar essa nova feature vá em Configurações na Aba de Encaminhamento e POP/IMAP.
Como o recurso é muito recente, nem todas contas ainda o possuem (a minha ainda não tem), mas o mesmo vai começar a aparecer para todos os usuários nos próximos dias.
Vejam a figura abaixo:
Leia mais aqui ou aqui.
O Gmail começou a suportar também IMAP. Para setar essa nova feature vá em Configurações na Aba de Encaminhamento e POP/IMAP.
Como o recurso é muito recente, nem todas contas ainda o possuem (a minha ainda não tem), mas o mesmo vai começar a aparecer para todos os usuários nos próximos dias.
Vejam a figura abaixo:
Leia mais aqui ou aqui.
terça-feira, 23 de outubro de 2007
KDE 4 - Beta 3 no Ubuntu Gutsy 7.10
O site do Kubuntu está disponibilizando um howto para orientar os usuários interessados a instalar o KDE4 beta 3 no Gutsy (7.10).
Quem quiser arriscar pode ver as instruções aqui. O melhor é que é possível instalar o KDE4 junto do KDE3, mas de qualquer maneira eu não recomendo isso para micros de produção, prefiro aguardar o Kubuntu 8.04.
Boa sorte para quem tentar :-)
Quem quiser arriscar pode ver as instruções aqui. O melhor é que é possível instalar o KDE4 junto do KDE3, mas de qualquer maneira eu não recomendo isso para micros de produção, prefiro aguardar o Kubuntu 8.04.
Boa sorte para quem tentar :-)
segunda-feira, 22 de outubro de 2007
Novo cliente IM - Instanbird
Me deparei com um novo cliente de IM que parece ter futuro. É o Instantbird.
Ele reúne o melhor da Mozilla com o Pidgin. Para quem usa o Pidgin, verá que ele o lembra em alguns aspectos, principalmente no gerenciamento de contas. Da Mozilla vem os add-ons no mesmo estilo de Firefox e Thunderbird o que promete facilitar a construção de complementos que devem começar a aparecer em breve (assim eu espero...).
Como é ainda a versão 0.1 ele ainda é muito cru para o usuário final, sendo interessante pra quem gosta de testar e conhecer novos produtos. Coloquei nele minha conta ICQ e nem os nomes dos usuários ele resolveu. Não tem menu de contexto, não tem envio de arquivos, ainda não tem praticamente nada, só troca de mensagens.
Espero que dê certo e o projeto siga adiante, pois tem tudo para ser um grande cliente.
Ele reúne o melhor da Mozilla com o Pidgin. Para quem usa o Pidgin, verá que ele o lembra em alguns aspectos, principalmente no gerenciamento de contas. Da Mozilla vem os add-ons no mesmo estilo de Firefox e Thunderbird o que promete facilitar a construção de complementos que devem começar a aparecer em breve (assim eu espero...).
Como é ainda a versão 0.1 ele ainda é muito cru para o usuário final, sendo interessante pra quem gosta de testar e conhecer novos produtos. Coloquei nele minha conta ICQ e nem os nomes dos usuários ele resolveu. Não tem menu de contexto, não tem envio de arquivos, ainda não tem praticamente nada, só troca de mensagens.
Espero que dê certo e o projeto siga adiante, pois tem tudo para ser um grande cliente.
domingo, 21 de outubro de 2007
Novo blog para Off topics
Resolvi criar um novo blog somente para postar sobre outros assuntos que não estejam necessariamente relacionados a informática (o que não quer dizer que não vá postar nada sobre esse tema também ;-) ).
Nesse novo blog irei falar sobre música, quadrinhos, videogames, filmes e irei também incluir meus post pessoais, além de outras bobagens ou coisas interessantes que aparecerem por aí.
Se alguém quiser acompanhar, o endereço é http://offtopicsandfun.blogspot.com/.
Se preferir, o RSS é http://feeds.feedburner.com/Mhterres-OffTopicsAndFun.
Nesse novo blog irei falar sobre música, quadrinhos, videogames, filmes e irei também incluir meus post pessoais, além de outras bobagens ou coisas interessantes que aparecerem por aí.
Se alguém quiser acompanhar, o endereço é http://offtopicsandfun.blogspot.com/.
Se preferir, o RSS é http://feeds.feedburner.com/Mhterres-OffTopicsAndFun.
sexta-feira, 19 de outubro de 2007
quinta-feira, 18 de outubro de 2007
Openfire e o plugin Gateway IM
Um recurso que pode ser bem importante para quem pensa em implementar um servidor de mensagens instantâneas é poder se interligar com as outras redes de IM disponíveis (ICQ, MSN, AIM).
Por mais que você pretenda usar somente o Jabber, muitas pessoas continuarão pelo menos no período inicial de implantação necessitando de suas contas nas outras redes para manter seus contatos ativos.
Pensando nisso, resolvi falar sobre um plugin que pode ser a solução se você tem esse problema: o Gateway IM.
O Gateway IM permite que você instale os chamados transportes sobre o Jabber. Os transportes nada mais são que meios de se acessar um conta de outra rede (MSN, ICQ ou outros protocolos) usando sua própria conta Jabber. Isso permite ao SysAdmin bloquear totalmente esses protocolos em sua rede e liberar os mesmos somente para usuários específicos. E fica melhor: você pode liberar a conta ICQ para o usuário A, para o usuário B liberar somente a conta MSN e para o usuário C não liberar rede nenhuma. O plugin é muito flexível.
Após a instalação do plugin, aparecerá uma nova opção chamada Gateways na aba do Servidor (bem no final da lista). Lá existem 2 itens:
Configurações: nesse item você irá determinar quais tipos de gateway quer liberar (AIM, Gadu Gadu, ICQ, IRC, MSN e Yahoo). Existem outros gateways experimentais os quais eu não recomendo que sejam marcados em servidores de produção.
Cada gateway tem 3 opções:
Testes: aqui você irá testar a conexão de seu server Jabber com a rede que você quer conectar.
Opções: aqui você irá configurar os dados de conexão a rede (os dados default costumam funcionar bem).
Permissões: aqui você irá setar como serão as permissões de acesso, que são 3 possíveis: Todos os usuários podem ser registrar. Esses usuários e/ou grupos podem se registrar (você então deverá informar os usuários e grupos com permissão) ou Somente registro manual (o que obriga que você cadastre cada usuário e sua conta específica na rede que será acessada - é mais trabalhoso, mas gera o maior controle possível).
Registros: Se você tiver escolhido para algum gateway a opção de registro manual, nesse item você irá mapear o usuário jabber e sua conta na rede externa. Para isso basta adicionar o novo usuário e colocar seu login da rede Jabber, o tipo de gateway, o usuário da rede externa, sua senha da rede externa e o apelido.
Ao cadastrar minha conta MSN na conta Jabber de nosso servidor, tão logo cliquei no botão Adicionar e minha conta MSN foi automaticamente desconectada do Pidgin. Instantaneamente meus contatos MSN começaram a aparecer na minha lista através do transporte Jabber.
Percebe-se que realmente o plugin além de ser muito útil é bastante simples de utilizar. E o que é ainda melhor, já que seus usuários estarão navegando via Jabber, todas as mensagens das outras redes também poderão ser monitoradas via a auditoria do Openfire.
Se você preferir pode também usar outros clientes específicos Jabber para evitar que os usuários tenham acesso a outros protocolos. Seguem algumas sugestões:
psi - Linux/Windows
Coccinella - Linux/Windows
Exodus - Windows
E outros mais podem ser encontrados aqui.
UPDATE (25/01): Quer trocar idéias com usuários do Openfire ? Cadastre-se na lista Openfire-BR
UPDATE 17/06/2012: Saiba mais sobre o Spectrum IM, o projeto atual do desenvolvedor do Kraken e do Gateway IM (ambos descontinuados).
Por mais que você pretenda usar somente o Jabber, muitas pessoas continuarão pelo menos no período inicial de implantação necessitando de suas contas nas outras redes para manter seus contatos ativos.
Pensando nisso, resolvi falar sobre um plugin que pode ser a solução se você tem esse problema: o Gateway IM.
O Gateway IM permite que você instale os chamados transportes sobre o Jabber. Os transportes nada mais são que meios de se acessar um conta de outra rede (MSN, ICQ ou outros protocolos) usando sua própria conta Jabber. Isso permite ao SysAdmin bloquear totalmente esses protocolos em sua rede e liberar os mesmos somente para usuários específicos. E fica melhor: você pode liberar a conta ICQ para o usuário A, para o usuário B liberar somente a conta MSN e para o usuário C não liberar rede nenhuma. O plugin é muito flexível.
Após a instalação do plugin, aparecerá uma nova opção chamada Gateways na aba do Servidor (bem no final da lista). Lá existem 2 itens:
Configurações: nesse item você irá determinar quais tipos de gateway quer liberar (AIM, Gadu Gadu, ICQ, IRC, MSN e Yahoo). Existem outros gateways experimentais os quais eu não recomendo que sejam marcados em servidores de produção.
Cada gateway tem 3 opções:
Testes: aqui você irá testar a conexão de seu server Jabber com a rede que você quer conectar.
Opções: aqui você irá configurar os dados de conexão a rede (os dados default costumam funcionar bem).
Permissões: aqui você irá setar como serão as permissões de acesso, que são 3 possíveis: Todos os usuários podem ser registrar. Esses usuários e/ou grupos podem se registrar (você então deverá informar os usuários e grupos com permissão) ou Somente registro manual (o que obriga que você cadastre cada usuário e sua conta específica na rede que será acessada - é mais trabalhoso, mas gera o maior controle possível).
Registros: Se você tiver escolhido para algum gateway a opção de registro manual, nesse item você irá mapear o usuário jabber e sua conta na rede externa. Para isso basta adicionar o novo usuário e colocar seu login da rede Jabber, o tipo de gateway, o usuário da rede externa, sua senha da rede externa e o apelido.
Ao cadastrar minha conta MSN na conta Jabber de nosso servidor, tão logo cliquei no botão Adicionar e minha conta MSN foi automaticamente desconectada do Pidgin. Instantaneamente meus contatos MSN começaram a aparecer na minha lista através do transporte Jabber.
Percebe-se que realmente o plugin além de ser muito útil é bastante simples de utilizar. E o que é ainda melhor, já que seus usuários estarão navegando via Jabber, todas as mensagens das outras redes também poderão ser monitoradas via a auditoria do Openfire.
Se você preferir pode também usar outros clientes específicos Jabber para evitar que os usuários tenham acesso a outros protocolos. Seguem algumas sugestões:
psi - Linux/Windows
Coccinella - Linux/Windows
Exodus - Windows
E outros mais podem ser encontrados aqui.
UPDATE (25/01): Quer trocar idéias com usuários do Openfire ? Cadastre-se na lista Openfire-BR
UPDATE 17/06/2012: Saiba mais sobre o Spectrum IM, o projeto atual do desenvolvedor do Kraken e do Gateway IM (ambos descontinuados).
Ubuntu Gutsy Gibbon liberado
Não é novidade mas eu não poderia de deixar de postar a notícia.
O Ubuntu 7.10 está disponível para download.
Ubuntu - versão x86
Kubuntu - versão x86
Ubuntu - versão 64
Kubuntu - versão 64
Para outras versões e mirrors do Ubuntu, clique aqui.
Para outras versões e mirrors do Kubuntu, clique aqui.
Interessado no Xubuntu, clique aqui.
Ou se preferir, peça gratuitamente seus CDs do Ubuntu ou do Kubuntu.
ISOs já baixados e dist-upgrades em andamento.
Vamos ver qual é :-)
O Ubuntu 7.10 está disponível para download.
Ubuntu - versão x86
Kubuntu - versão x86
Ubuntu - versão 64
Kubuntu - versão 64
Para outras versões e mirrors do Ubuntu, clique aqui.
Para outras versões e mirrors do Kubuntu, clique aqui.
Interessado no Xubuntu, clique aqui.
Ou se preferir, peça gratuitamente seus CDs do Ubuntu ou do Kubuntu.
ISOs já baixados e dist-upgrades em andamento.
Vamos ver qual é :-)
segunda-feira, 15 de outubro de 2007
ejabberd 2 - o que vem por aí...
Novas e aguardadas features estão chegando na nova versão do ejabberd, ainda sem previsão de lançamento. Entre elas:
*Visualização do IP dos clientes na interface admin Web
*Melhoria nos logs s2s (server to server)
*Módulo de autenticação LDAP que agora permite fazer bind em múltiplos atributos
*Autenticação via PAM
*Suporte para pool de servidores LDAP
*Instalador full 64 bits
*Porta do MySQL/PostgreSQL que agora pode ser especificada no arquivo de configuração
*Lista de servidores liberados/bloqueados para comunicação s2s
E muitas outras. No total são quase 200 bugs/novas features/melhorias em comparação a versão atual (1.1.4).
É aguardar e instalar assim que sair :-)
*Visualização do IP dos clientes na interface admin Web
*Melhoria nos logs s2s (server to server)
*Módulo de autenticação LDAP que agora permite fazer bind em múltiplos atributos
*Autenticação via PAM
*Suporte para pool de servidores LDAP
*Instalador full 64 bits
*Porta do MySQL/PostgreSQL que agora pode ser especificada no arquivo de configuração
*Lista de servidores liberados/bloqueados para comunicação s2s
E muitas outras. No total são quase 200 bugs/novas features/melhorias em comparação a versão atual (1.1.4).
É aguardar e instalar assim que sair :-)
Bacula - backup eficiente
Um serviço muito importante para qualquer servidor é o do backup (apesar de muita gente não dar o valor necessário até precisar dele).
E falando em backup, uma ferramenta que me vem direto ao pensamento é o Bacula.
O Bacula é um software livre com recursos de backup em rede. Ele pode usar vários tipos de mídias para backup como fitas, DVDs, CDs ou mesmo um HD. Além disso, ele tem clientes para Linux e Windows o que flexibiliza bastante o backup de um ambiente homogêneo.
A instalação do servidor consiste basicamente em compilar/instalar o pacote e depois configurar os serviços. Você pode usar um DB MySQL ou PostgreSQL como forma de armazenamento do catálogo. O servidor se divide em 3 serviços: o director, o storage e o file daemon (opcional para o servidor).
O director é onde você configura efetivamente o servidor. Nele você configura seu DB, os endereços de e-mail para envio das mensagens de alerta/aviso e os pools de volumes. Além disso nele você também deve setar os jobs, os clientes e os file sets.
Os clientes são as máquinas onde você vai conectar para buscar os dados.
Os file sets são os arquivos que vocês vai backupear do cliente.
Os jobs são nada mais do que a junção de tudo isso, ou seja o cliente, com o file set, agendamento de horário, nível do mesmo além de outras features. Você pode configurar um job padrão com as configurações comuns e dizer para seus outros jobs para usá-lo, setando no mesmo só as configurações mais específicas.
Além disso, você pode ter mais que um job para um mesmo cliente com um file set diferente, ou seja, você pode backupear seus dados em várias partes, na hora que for mais oportuna. A flexibilidade do bacula nesse ponto é muito interessante.
No director você também pode configurar para rodar scripts antes ou depois de um job específico. Por exemplo, você pode fazer o dump de uma base MySQL antes de fazer o backup do servidor MySQL, ou então, você pode fazer a fita ser ejetada após o último job.
O storage é onde você configura onde serão armazenados os dados. Nele você informa se vai usar uma unidade de fita, um DVD, um CD ou todos eles.
O file daemon também deve ser configurado para que seu servidor possa ser backupeado. Ele é opcional para o servidor funcionar, mas você não vai deixar de backupear o próprio servidor, correto ? ;-)
Já no lado do cliente, basta instalar o file daemon e configurar o mesmo. Ou seja, no cliente a operação é muito simples, ainda mais se for um cliente Linux. Se for Windows pode ser um pouco mais chato, porque após instalar o mesmo, é necessário copiar os arquivos de configuração e reiniciar o serviço. O problema aí é saber onde exatamente colocar os arquivos. :-D
Se precisar de mais informações sobre isso, me avise que eu possa detalhar melhor a situação.
O bacula possui vários softwares para conectar ao seu console que permitem configurá-lo, agendar jobs, restaurar dados, etc...
O principal deles é o bconsole, que é via linha de comando. Graficamente temos o bweb (via web, obviamente, que pode ser obtido pelo svn do bacula e que vale a pena instalar), um console para gnome (que nada mais é que um frontend visual para o bconsole, bastante interessante e que tem uma linha de comando como o bconsole), um monitorador que fica no tray e mais recentemente o BAT (Bacula Administration Tool) que promete ser a ferramente gráfica oficial do Bacula.
Claro que nem tudo é perfeito, então segue uma lista de features que eu acho que seriam interessantes:
Aviso programado por e-mail que informa o label da fita do próximo backup a ser realizado (para por exemplo, enviar um e-mail às 17hs informando qual o nome da fita que deve ser colocada para o próximo backup, que roda às 23hs).
Um novo evento de script para quando a fita lotar (para poder ejetar a fita, por exemplo).
Concluindo, na minha opinião é uma ótima ferramenta que deve ser avaliada por todos interessados numa solução de backup.
Outras ferramentas de backup:
Amanda - nunca usei, mas está em desenvolvimento há bastante tempo e tem sua última versão lançada em 06/06/2007 (versão 2.5.2p1).
Restore - tem chamado minha atenção pelo constante desenvolvimento que tenho percebido nos últimos tempos. A última versão é a 4.0b3-1(lançada em 15/10/2007). O que me incomoda com relação ao Restore é que ele não disponibiliza os fontes (ou se faz, está bem escondido). No site só existe ISO das VMs e pacotes binários para Debian e Ubuntu.
ERRATA (23/11): Quer obter os fontes do Restore? Saiba aqui como fazê-lo.
E falando em backup, uma ferramenta que me vem direto ao pensamento é o Bacula.
O Bacula é um software livre com recursos de backup em rede. Ele pode usar vários tipos de mídias para backup como fitas, DVDs, CDs ou mesmo um HD. Além disso, ele tem clientes para Linux e Windows o que flexibiliza bastante o backup de um ambiente homogêneo.
A instalação do servidor consiste basicamente em compilar/instalar o pacote e depois configurar os serviços. Você pode usar um DB MySQL ou PostgreSQL como forma de armazenamento do catálogo. O servidor se divide em 3 serviços: o director, o storage e o file daemon (opcional para o servidor).
O director é onde você configura efetivamente o servidor. Nele você configura seu DB, os endereços de e-mail para envio das mensagens de alerta/aviso e os pools de volumes. Além disso nele você também deve setar os jobs, os clientes e os file sets.
Os clientes são as máquinas onde você vai conectar para buscar os dados.
Os file sets são os arquivos que vocês vai backupear do cliente.
Os jobs são nada mais do que a junção de tudo isso, ou seja o cliente, com o file set, agendamento de horário, nível do mesmo além de outras features. Você pode configurar um job padrão com as configurações comuns e dizer para seus outros jobs para usá-lo, setando no mesmo só as configurações mais específicas.
Além disso, você pode ter mais que um job para um mesmo cliente com um file set diferente, ou seja, você pode backupear seus dados em várias partes, na hora que for mais oportuna. A flexibilidade do bacula nesse ponto é muito interessante.
No director você também pode configurar para rodar scripts antes ou depois de um job específico. Por exemplo, você pode fazer o dump de uma base MySQL antes de fazer o backup do servidor MySQL, ou então, você pode fazer a fita ser ejetada após o último job.
O storage é onde você configura onde serão armazenados os dados. Nele você informa se vai usar uma unidade de fita, um DVD, um CD ou todos eles.
O file daemon também deve ser configurado para que seu servidor possa ser backupeado. Ele é opcional para o servidor funcionar, mas você não vai deixar de backupear o próprio servidor, correto ? ;-)
Já no lado do cliente, basta instalar o file daemon e configurar o mesmo. Ou seja, no cliente a operação é muito simples, ainda mais se for um cliente Linux. Se for Windows pode ser um pouco mais chato, porque após instalar o mesmo, é necessário copiar os arquivos de configuração e reiniciar o serviço. O problema aí é saber onde exatamente colocar os arquivos. :-D
Se precisar de mais informações sobre isso, me avise que eu possa detalhar melhor a situação.
O bacula possui vários softwares para conectar ao seu console que permitem configurá-lo, agendar jobs, restaurar dados, etc...
O principal deles é o bconsole, que é via linha de comando. Graficamente temos o bweb (via web, obviamente, que pode ser obtido pelo svn do bacula e que vale a pena instalar), um console para gnome (que nada mais é que um frontend visual para o bconsole, bastante interessante e que tem uma linha de comando como o bconsole), um monitorador que fica no tray e mais recentemente o BAT (Bacula Administration Tool) que promete ser a ferramente gráfica oficial do Bacula.
Claro que nem tudo é perfeito, então segue uma lista de features que eu acho que seriam interessantes:
Aviso programado por e-mail que informa o label da fita do próximo backup a ser realizado (para por exemplo, enviar um e-mail às 17hs informando qual o nome da fita que deve ser colocada para o próximo backup, que roda às 23hs).
Um novo evento de script para quando a fita lotar (para poder ejetar a fita, por exemplo).
Concluindo, na minha opinião é uma ótima ferramenta que deve ser avaliada por todos interessados numa solução de backup.
Outras ferramentas de backup:
Amanda - nunca usei, mas está em desenvolvimento há bastante tempo e tem sua última versão lançada em 06/06/2007 (versão 2.5.2p1).
Restore - tem chamado minha atenção pelo constante desenvolvimento que tenho percebido nos últimos tempos. A última versão é a 4.0b3-1(lançada em 15/10/2007). O que me incomoda com relação ao Restore é que ele não disponibiliza os fontes (ou se faz, está bem escondido). No site só existe ISO das VMs e pacotes binários para Debian e Ubuntu.
ERRATA (23/11): Quer obter os fontes do Restore? Saiba aqui como fazê-lo.
Openfire e o plugin asterisk-IM
Um recurso muito interessante do Openfire é sua "integração" com o asterisk.
O plugin do asterisk, pode ser facilmente instalando usando a aba Plugins do console de administração do Openfire. Após sua instalação, uma nova aba surgirá na barra (Asterisk-IM), onde então devem ser feitas as configurações específicas do mesmo, que são as seguintes:
1) Habilitar o plugin (basta clicar no option button Enabled).
2) Configurar o(s) servidor(ou servidores) asterisk: nesse passo você irá adicionar um servidor clicando na opção Add Server e irá informar os seguintes dados:
Server Address: o nome do servidor (para identificação)
Server IP: ip do servidor
Port: porta de conexão, padrão 5038
Username: nome do usuário que irá conectar no manager do asterisk
Password: senha do usuário
3) Configurar o Phone Manager: o importante aqui é setar o contexto do asterisk (Asterisk Context) somente.
4) Criar os mapeamentos dos telefone: nessa opção você irá mapear seu usuário jabber com um ramal e device de telefone, com os seguintes dados:
Username: nome do usuário Jabber
Device: device do asterisk, ex: SIP/101
Extension: ramal (ex:101)
Caller ID: identificação do ramal (opcional)
Primary: marque sim se o ramal for primário, no caso do usuário ter mais de 1 ramal (opcional em caso de apenas um ramal para o usuário)
Com isso feito, basta agora ligar para o ramal do usuário mapeado e quando ele atender automaticamente seu status mudará para Away com mensagem "On the phone". Ao desligar a chamada, ele irá retornar ao estado anterior.
Bacana e bem útil, esse é um plugin que pode ser instalado e configurado com facilidade e que é uma das features que me faz gostar do Openfire e das quais eu sinto falta no ejabberd.
UPDATE (25/01): Quer trocar idéias com usuários do Openfire ? Cadastre-se na lista Openfire-BR.
O plugin do asterisk, pode ser facilmente instalando usando a aba Plugins do console de administração do Openfire. Após sua instalação, uma nova aba surgirá na barra (Asterisk-IM), onde então devem ser feitas as configurações específicas do mesmo, que são as seguintes:
1) Habilitar o plugin (basta clicar no option button Enabled).
2) Configurar o(s) servidor(ou servidores) asterisk: nesse passo você irá adicionar um servidor clicando na opção Add Server e irá informar os seguintes dados:
Server Address: o nome do servidor (para identificação)
Server IP: ip do servidor
Port: porta de conexão, padrão 5038
Username: nome do usuário que irá conectar no manager do asterisk
Password: senha do usuário
3) Configurar o Phone Manager: o importante aqui é setar o contexto do asterisk (Asterisk Context) somente.
4) Criar os mapeamentos dos telefone: nessa opção você irá mapear seu usuário jabber com um ramal e device de telefone, com os seguintes dados:
Username: nome do usuário Jabber
Device: device do asterisk, ex: SIP/101
Extension: ramal (ex:101)
Caller ID: identificação do ramal (opcional)
Primary: marque sim se o ramal for primário, no caso do usuário ter mais de 1 ramal (opcional em caso de apenas um ramal para o usuário)
Com isso feito, basta agora ligar para o ramal do usuário mapeado e quando ele atender automaticamente seu status mudará para Away com mensagem "On the phone". Ao desligar a chamada, ele irá retornar ao estado anterior.
Bacana e bem útil, esse é um plugin que pode ser instalado e configurado com facilidade e que é uma das features que me faz gostar do Openfire e das quais eu sinto falta no ejabberd.
UPDATE (25/01): Quer trocar idéias com usuários do Openfire ? Cadastre-se na lista Openfire-BR.
sexta-feira, 12 de outubro de 2007
E por falar em RSS...
E por falar em RSS, segue aqui pra quem se interessar uma lista de alguns interessantes RSS que tenho no meu Google Reader:
BR-Linux - Notícias sobre Software Livre
Digg - Notícias em geral
Freshmeat - Atualizações de Softwares Livres e Lançamentos
KDE Dot News - Notícias sobre o KDE
Kernel Linux - Notícias sobre novas versões do Kernel Linux
Omelete - Cinema, DVD, HQs e séries de TV.
Official Google Blog - Blog oficial do Google
OhGizmo - Novidades sobre aparelhos eletrônicos em geral
Outerspace - Games, games e mais games
Por um punhado de pixels - Cinema, séries, cultura em geral
Projeto Software Livre - Notícias de Software LIvre
Random Good Stuff - Similar ao OhGizmo
TechEBlog - Idem
Ubuntu Fridge - Notícias sobre Ubuntu
XKCD - comics geeks
É só clicar e assinar :-)
Quem quiser outras dicas de RSS legais é só falar...
BR-Linux - Notícias sobre Software Livre
Digg - Notícias em geral
Freshmeat - Atualizações de Softwares Livres e Lançamentos
KDE Dot News - Notícias sobre o KDE
Kernel Linux - Notícias sobre novas versões do Kernel Linux
Omelete - Cinema, DVD, HQs e séries de TV.
Official Google Blog - Blog oficial do Google
OhGizmo - Novidades sobre aparelhos eletrônicos em geral
Outerspace - Games, games e mais games
Por um punhado de pixels - Cinema, séries, cultura em geral
Projeto Software Livre - Notícias de Software LIvre
Random Good Stuff - Similar ao OhGizmo
TechEBlog - Idem
Ubuntu Fridge - Notícias sobre Ubuntu
XKCD - comics geeks
É só clicar e assinar :-)
Quem quiser outras dicas de RSS legais é só falar...
FeedBurner e Technorati
Cadastrei meu blog no Technorati para aumentar a divulgação do meu blog, já que agora decide começar a postar mais e tentar dar um "rumo" para o mesmo.
Aproveitei também e mudei meu RSS para o FeedBurner para poder obter estatísticas de uso do mesmo. Então se você assina meu RSS, por favor assine-o novamente usando a URL do FeedBurner (basta clicar no ícone da barra de endereço ou no novo ícone que posicionei na lateral direita - em todo caso você pode também clicar aqui).
O FeedBurner foi comprado pelo Google, o que provavelmente fará com que ele se integre ao Blogspot/Blogger no futuro, mas ainda não é o caso.
Para quem tem um blog, vale a pena usar os 2 serviços, principalmente o FeedBurner para você pode ter todas estatísticas de acesso do RSS e de seu site.
Muito bom mesmo.
Aproveitei também e mudei meu RSS para o FeedBurner para poder obter estatísticas de uso do mesmo. Então se você assina meu RSS, por favor assine-o novamente usando a URL do FeedBurner (basta clicar no ícone da barra de endereço ou no novo ícone que posicionei na lateral direita - em todo caso você pode também clicar aqui).
O FeedBurner foi comprado pelo Google, o que provavelmente fará com que ele se integre ao Blogspot/Blogger no futuro, mas ainda não é o caso.
Para quem tem um blog, vale a pena usar os 2 serviços, principalmente o FeedBurner para você pode ter todas estatísticas de acesso do RSS e de seu site.
Muito bom mesmo.
quinta-feira, 11 de outubro de 2007
Ubuntu Open Week
Em época de lançamento de nova versão do Ubuntu, está programada uma nova Ubuntu Open Week.
A Ubuntu Open Week é uma semana de eventos virtuais que ocorrem no canal #ubuntu-classroom nos servidores IRC da rede Freenode.
Ela vai consistir de 42 tutoriais dos mais variados assuntos e vai contar com várias pessoas envolvidas diretamente no projeto, como Jono Bacon, Daniel Holbach, entre outros e inclusive uma sessão com Mark Shuttleworth. Entre os temas, podemos encontrar: empacotamento, triagem de bugs, traduções, acessibilidade e muito mais. Haverão também sessões para Kubuntu, Xubuntu, Ubuntu Studio e Gobuntu.
A programação completa pode ser encontrada aqui.
A Ubuntu Open Week é uma semana de eventos virtuais que ocorrem no canal #ubuntu-classroom nos servidores IRC da rede Freenode.
Ela vai consistir de 42 tutoriais dos mais variados assuntos e vai contar com várias pessoas envolvidas diretamente no projeto, como Jono Bacon, Daniel Holbach, entre outros e inclusive uma sessão com Mark Shuttleworth. Entre os temas, podemos encontrar: empacotamento, triagem de bugs, traduções, acessibilidade e muito mais. Haverão também sessões para Kubuntu, Xubuntu, Ubuntu Studio e Gobuntu.
A programação completa pode ser encontrada aqui.
quarta-feira, 10 de outubro de 2007
Servidores Jabber
Uma questão que deixa muitas dúvidas quando pensa sem Jabber é: qual servidor eu vou usar ?
Dentro os vários que existem, dois eu acho que são muito interessantes:
Openfire (3.3.3) e ejabberd (1.1.4).
O Openfire (antigo Wildfire) é um servidor jabber em Java, que tem muitos recursos interessantes é uma interface web de configuração extremamente completa e simples.
Entre seus principais recursos os que mais me chamam atenção são: Plugins, auditoria das mensagens dos usuários e controle de conexão com outros servidores jabber.
Os plugins são dos mais variados: Transportes ICQ, MSN e até integração com o Asterisk (que é bem bacana).
Quanto a auditoria de mensagens dos usuários, o Openfire permite manter as mesmas em logs, mas não fornece uma forma de visualizá-los. Para isso desenvolvi um PHP que mostra o conteúdo das mesmas de forma bem simples.
Já com relação ao controle de conexão com outros servers, acho interesssante que o Openfire possibilite a criação de listas brancas de permissão, o que garante que só servidores confiáveis possam se comunicar com o Openfire (esse recurso deve também ser disponibilizado no ejabber 2, que ainda está em desenvolvimento).
Já o ejabberd apesar de não possuir algumas dessas features do Openfire conta com uma importante vantagem: o fato de ser o servidor que roda no Jabber.org. Isso já mostra a robustez e capacidade do mesmo em atender uma grande quantidade de usuários. Para se ter uma idéia, no Jabber.org existem mais de 330 mil usuários registrados, e uma média de 8000 usuários simultâneos. Isso tudo rodando num Dual P4 com 4Gb de memória e DB PostgreSQL. Para visualizar mais dados sobre o servidor, vá na página de Status do servidor Jabber.org.
Muitos poderão dizer que o Jabber.org não é uma grande referência pois fica muito tempo fora do ar. Conversando com stpeter, administrador do Jabber.org levantei essa questão e ele me explicou que muitos dos problemas se devem aos usuários usarem o Jabber.org como área de testes, o que gera instabilidade no servidor. Por exemplo: usuários com 600 mil mensagens offline, usuários que criam web services para fazer inúmeras conexões e por aí vai. Com tanta "invenção", realmente não tem servidor que aguente.
Com relação a performance, pesa (ou será que não ?) o fato do Openfire ser em Java. Já o ejabberd é escrito em Erlang, uma linguagem não muito conhecida e utilizada.
De minha experiência, conheço servidores rodando Openfire com mais ou menos 50 usuários sem grande consumo de recursos do hardware em máquinas relativamente baratas. Mais do que isso eu ainda não utilizei, mas acredito que possa ser viável fazê-lo. Já o ejabberd tem o Jabber.org como um ótimo case de instalação o que faz com que eu prefira-o para instalações com grande número de usuários.
Dentro os vários que existem, dois eu acho que são muito interessantes:
Openfire (3.3.3) e ejabberd (1.1.4).
O Openfire (antigo Wildfire) é um servidor jabber em Java, que tem muitos recursos interessantes é uma interface web de configuração extremamente completa e simples.
Entre seus principais recursos os que mais me chamam atenção são: Plugins, auditoria das mensagens dos usuários e controle de conexão com outros servidores jabber.
Os plugins são dos mais variados: Transportes ICQ, MSN e até integração com o Asterisk (que é bem bacana).
Quanto a auditoria de mensagens dos usuários, o Openfire permite manter as mesmas em logs, mas não fornece uma forma de visualizá-los. Para isso desenvolvi um PHP que mostra o conteúdo das mesmas de forma bem simples.
Já com relação ao controle de conexão com outros servers, acho interesssante que o Openfire possibilite a criação de listas brancas de permissão, o que garante que só servidores confiáveis possam se comunicar com o Openfire (esse recurso deve também ser disponibilizado no ejabber 2, que ainda está em desenvolvimento).
Já o ejabberd apesar de não possuir algumas dessas features do Openfire conta com uma importante vantagem: o fato de ser o servidor que roda no Jabber.org. Isso já mostra a robustez e capacidade do mesmo em atender uma grande quantidade de usuários. Para se ter uma idéia, no Jabber.org existem mais de 330 mil usuários registrados, e uma média de 8000 usuários simultâneos. Isso tudo rodando num Dual P4 com 4Gb de memória e DB PostgreSQL. Para visualizar mais dados sobre o servidor, vá na página de Status do servidor Jabber.org.
Muitos poderão dizer que o Jabber.org não é uma grande referência pois fica muito tempo fora do ar. Conversando com stpeter, administrador do Jabber.org levantei essa questão e ele me explicou que muitos dos problemas se devem aos usuários usarem o Jabber.org como área de testes, o que gera instabilidade no servidor. Por exemplo: usuários com 600 mil mensagens offline, usuários que criam web services para fazer inúmeras conexões e por aí vai. Com tanta "invenção", realmente não tem servidor que aguente.
Com relação a performance, pesa (ou será que não ?) o fato do Openfire ser em Java. Já o ejabberd é escrito em Erlang, uma linguagem não muito conhecida e utilizada.
De minha experiência, conheço servidores rodando Openfire com mais ou menos 50 usuários sem grande consumo de recursos do hardware em máquinas relativamente baratas. Mais do que isso eu ainda não utilizei, mas acredito que possa ser viável fazê-lo. Já o ejabberd tem o Jabber.org como um ótimo case de instalação o que faz com que eu prefira-o para instalações com grande número de usuários.
Gnarwl - um "vacation" usando LDAP
Procurando uma solução de resposta automática para e-mail para um servidor rodando Postfix e Courier, me deparei com uma ferramenta muito interessante.
Trata-se do GNARWL.
Gnarwl é um autoresponder de e-mail que se integra a um servidor LDAP, o que resolveu a minha questão de imediato, já que todas as contas de e-mail estavam armazenadas em um.
Ele tem um schema próprio que ao ser incluído no LDAP libera uma nova classe (Vacation) e novos atributos. Entre eles os mais importantes são o vacationActive (resposta automática ativa ou não) e vacationInfo (mensagem da resposta automática).
O Gnarwl também tem arquivo de configuração próprio que permite setar o tempo de intervalo de resposta para mensagens vindas de mesmo remetente (como no vacation) e outras coisas mais.
É uma excelente solução para quem está precisando de uma configuração de resposta automática para seu servidor.
E o melhor de tudo, para integrar ao postfix basta uma meia dúzia de linhas.
Vale a pena dar uma olhada.
UPDATE (07/07/2008):
Trata-se do GNARWL.
Gnarwl é um autoresponder de e-mail que se integra a um servidor LDAP, o que resolveu a minha questão de imediato, já que todas as contas de e-mail estavam armazenadas em um.
Ele tem um schema próprio que ao ser incluído no LDAP libera uma nova classe (Vacation) e novos atributos. Entre eles os mais importantes são o vacationActive (resposta automática ativa ou não) e vacationInfo (mensagem da resposta automática).
O Gnarwl também tem arquivo de configuração próprio que permite setar o tempo de intervalo de resposta para mensagens vindas de mesmo remetente (como no vacation) e outras coisas mais.
É uma excelente solução para quem está precisando de uma configuração de resposta automática para seu servidor.
E o melhor de tudo, para integrar ao postfix basta uma meia dúzia de linhas.
Vale a pena dar uma olhada.
UPDATE (07/07/2008):
- Clique aqui para ir para o novo site do projeto.
- A última versão disponível (3.4) possui um "plugin para o Horde" que permite manipular o Gnarwl direto na interface de configurações dos usuários. Com isso o controle do vacation fica muito mais simples (ainda não testei com quais versões do Horde funciona). Não sei se as versões anteriores já traziam o recurso, mas é possível que já estivesse disponível há algum tempo.
- Saiba como fazer o Gnarwl funcionar com TLS aqui.
Bobby Tables :-)
O xkcd é um site com tiras diárias de quadrinhos muito divertido pra quem é da área de TI.
Na tirinha de hoje eles se superaram e eu acho que vale um post.
Conheçam o pequeno Bobby Tables.
:-)
Na tirinha de hoje eles se superaram e eu acho que vale um post.
Conheçam o pequeno Bobby Tables.
:-)
quinta-feira, 4 de outubro de 2007
Liquid Rescale
Ok,
eu sei que não é novidade, mas eu realmente fiquei impressionado e achei que o Liquid Rescale merecia um post.
Não sou nenhum expert em Gimp (dá pra me encaixar no nível semi-intermediário ou básico avançado :-) ), mas com o liquid rescale é muito fácil mexer na imagem (redimensionar mantendo ou removendo partes da mesma) e o resultado é surpreendente.
Um HowTo pode ser encontrado aqui.
Segue o resultado de um teste que fiz com uma imagem de 1024x768. Para obter o resultado da segunda foto, mandei preservar as casas e as motos e redimensionar a imagem para 800x768.
O fundo todo foi dimensionado para a nova largura mas os objetos selecionados foram preservados de forma perfeita. Outra coisa interessante é que mesmo mexendo só na largura e não alterando a altura os demais objetos não ficaram com aquele formato "esticado". Cabe ressaltar que isso funciona muito melhor com paisagens no fundo.
Quem não conhece a imagem original pode nem perceber a manipulação.
Imagem Original 1024x768
Imagem modificada 800x768
Mais informações sobre esse plug-in você encontra aqui. Você também pode ver um vídeo demonstrando o plugin aqui.
Muito show :-)
eu sei que não é novidade, mas eu realmente fiquei impressionado e achei que o Liquid Rescale merecia um post.
Não sou nenhum expert em Gimp (dá pra me encaixar no nível semi-intermediário ou básico avançado :-) ), mas com o liquid rescale é muito fácil mexer na imagem (redimensionar mantendo ou removendo partes da mesma) e o resultado é surpreendente.
Um HowTo pode ser encontrado aqui.
Segue o resultado de um teste que fiz com uma imagem de 1024x768. Para obter o resultado da segunda foto, mandei preservar as casas e as motos e redimensionar a imagem para 800x768.
O fundo todo foi dimensionado para a nova largura mas os objetos selecionados foram preservados de forma perfeita. Outra coisa interessante é que mesmo mexendo só na largura e não alterando a altura os demais objetos não ficaram com aquele formato "esticado". Cabe ressaltar que isso funciona muito melhor com paisagens no fundo.
Quem não conhece a imagem original pode nem perceber a manipulação.
Imagem Original 1024x768
 |
Imagem modificada 800x768
 |
Mais informações sobre esse plug-in você encontra aqui. Você também pode ver um vídeo demonstrando o plugin aqui.
Muito show :-)
quarta-feira, 19 de setembro de 2007
Saiu a lista brasileira de equipamentos e serviços compatíveis com o Linux
O BR-Linux depois de uma grande pesquisa de compatibilidade divulgou os resultados finais. E o melhor de tudo: você ainda pode concorrer a prêmios ajudando a divulgar a mesma. Veja:
Ajude a divulgar a lista brasileira de equipamentos e serviços compatíveis com Linux
...e concorra a MP4 e MP3 players, mochilas Targus, períodos de VoIP grátis e até a ventiladores USB - além de contribuir automaticamente para doações para a Wikipedia e o Wordpress! O BR-Linux coletou mais de 12.000 registros de compatibilidade de equipamentos e serviços (webcams, scanners, notebooks, ...) na sua Pesquisa Nacional de Compatibilidade 2007, e agora convida a comunidade a ajudar a divulgar o resultado. Veja as regras da promoção no BR-Linux e ajude a divulgar - quanto mais divulgação, maior será a doação do BR-Linux à Wikipedia e ao Wordpress.
Por hj era isso... :-)
Ajude a divulgar a lista brasileira de equipamentos e serviços compatíveis com Linux
...e concorra a MP4 e MP3 players, mochilas Targus, períodos de VoIP grátis e até a ventiladores USB - além de contribuir automaticamente para doações para a Wikipedia e o Wordpress! O BR-Linux coletou mais de 12.000 registros de compatibilidade de equipamentos e serviços (webcams, scanners, notebooks, ...) na sua Pesquisa Nacional de Compatibilidade 2007, e agora convida a comunidade a ajudar a divulgar o resultado. Veja as regras da promoção no BR-Linux e ajude a divulgar - quanto mais divulgação, maior será a doação do BR-Linux à Wikipedia e ao Wordpress.
Por hj era isso... :-)
domingo, 3 de junho de 2007
Turismo
E hj, domingo, foi dia de turismo em Manaus, afinal ninguém é de ferro.
Saí antes das 10 e fui curtir a feira de rua de Manaus, uma espécie de brique como o da Redenção, mas q ocorre no meio da rua ao lado do hotel onde estou.
Após a ida na feira, fui conhecer os lugares que tinha visto na Internet.
Primeiro fui no Mercado Adolpho Lisboa, mas foi uma pena que ele está sendo restaurado e não deu pra entrar.
Resolvi então voltar para o hotel, mas agora vindo por dentro da cidade, onde me deparei com outras igrejas e prédios muito legais. Meu álbum do Picasaweb está ficando bem bacana.
Depois do almoço (que foi composto de Tambaqui, bacalhau e pirarucu), resolvi dar mais uma volta perto do teatro onde tirei fotos de outros prédios interessantes e depois voltei para o hotel antes que começasse a chover.
Enfim, a segunda está chegando e devo voltar essa semana pra terrinha que tanto sinto falta e para meu lar e os braços da minha amada.
Por hj era isso.
Saí antes das 10 e fui curtir a feira de rua de Manaus, uma espécie de brique como o da Redenção, mas q ocorre no meio da rua ao lado do hotel onde estou.
Após a ida na feira, fui conhecer os lugares que tinha visto na Internet.
Primeiro fui no Mercado Adolpho Lisboa, mas foi uma pena que ele está sendo restaurado e não deu pra entrar.
 |  |
 |  |
| Segui então pela orla, passei pelo Mercado (um galpão enorme, com dezenas de mesas com pessoas vendo carne e peixes enormes) e segui novamente pela orla até meu destino final que era o Centro Cultural Chaminé, que infelizmente estava fechado. :-( | |
 |  |
Resolvi então voltar para o hotel, mas agora vindo por dentro da cidade, onde me deparei com outras igrejas e prédios muito legais. Meu álbum do Picasaweb está ficando bem bacana.
Depois do almoço (que foi composto de Tambaqui, bacalhau e pirarucu), resolvi dar mais uma volta perto do teatro onde tirei fotos de outros prédios interessantes e depois voltei para o hotel antes que começasse a chover.
Enfim, a segunda está chegando e devo voltar essa semana pra terrinha que tanto sinto falta e para meu lar e os braços da minha amada.
Por hj era isso.
quinta-feira, 31 de maio de 2007
Manaus - Alguns dias depois...
Alguns dias depois da minha chegada em Manaus e posso dizer que já estou mais acostumado com o local.
Com certeza sinto muuuuuuita falta de casa, mas enfim, tenho de terminar minhas tarefas por aqui.
Manaus, é realmente uma cidade muito interessante, e, pensando bem, é bem legal conhecer um lugar diferente. Além do mais, estou com sorte, e o calor aqui não tem sido muito intenso como deveria. (PS: só lamento não ter podido aproveitar o frio de 5 graus lá de Canoas/Porto Alegre).
A cidade tem muitos prédios antigos, de mais de cem anos atrás, começando pelo belíssimo Teatro, o que é muito bacana. Além disso, todos esses prédios são muito grandiosos, de uma época em que dinheiro sobrava na cidade. Muito legal mesmo.
Ainda não consegui ir em todos lugares, mas se sobrar tempo nesse fim de semana quero dar uma volta no centro, ir no porto tirar umas fotos, na catedral, andar por aqui. Espero que São Pedro ajude...
Era isso por enqto...
http://picasaweb.google.com/mhterres/Manaus
Com certeza sinto muuuuuuita falta de casa, mas enfim, tenho de terminar minhas tarefas por aqui.
Manaus, é realmente uma cidade muito interessante, e, pensando bem, é bem legal conhecer um lugar diferente. Além do mais, estou com sorte, e o calor aqui não tem sido muito intenso como deveria. (PS: só lamento não ter podido aproveitar o frio de 5 graus lá de Canoas/Porto Alegre).
A cidade tem muitos prédios antigos, de mais de cem anos atrás, começando pelo belíssimo Teatro, o que é muito bacana. Além disso, todos esses prédios são muito grandiosos, de uma época em que dinheiro sobrava na cidade. Muito legal mesmo.
Ainda não consegui ir em todos lugares, mas se sobrar tempo nesse fim de semana quero dar uma volta no centro, ir no porto tirar umas fotos, na catedral, andar por aqui. Espero que São Pedro ajude...
Era isso por enqto...
http://picasaweb.google.com/mhterres/Manaus
domingo, 27 de maio de 2007
Viagem a Manaus
Decididamente não sou amigo do avião... :-)
Viajar pra Manaus foi a coisa mais complicada que já fiz na minha vida. Qdo cheguei a Guarulhos já estava com vontade de desistir, mas faz parte a tensão do vôo pra quem não curte voar.
Digamos que ficar 1:20h e depois mais 3:45h voando não é a coisa que eu mais goste do mundo.
De qquer maneira, o que importa é que cheguei bem e já estou atualizando meu álbum do Picasaweb.
Na medida que for tirando fotos vou postando lá. Por enqto só tem umas de dentro do avião mesmo, mas cheguei aqui com chuva e não estava bom para fotografar.
No decorrer da semana devo tirar umas legais.
Viajar pra Manaus foi a coisa mais complicada que já fiz na minha vida. Qdo cheguei a Guarulhos já estava com vontade de desistir, mas faz parte a tensão do vôo pra quem não curte voar.
Digamos que ficar 1:20h e depois mais 3:45h voando não é a coisa que eu mais goste do mundo.
De qquer maneira, o que importa é que cheguei bem e já estou atualizando meu álbum do Picasaweb.
Na medida que for tirando fotos vou postando lá. Por enqto só tem umas de dentro do avião mesmo, mas cheguei aqui com chuva e não estava bom para fotografar.
No decorrer da semana devo tirar umas legais.
terça-feira, 22 de maio de 2007
Otimizando o Linux
Para otimizar seu linux, coloque as seguintes linhas no arquivo /etc/sysctl.conf
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
Reinicie o sistema e era isso.
Caso queira otimizar sem reiniciar, rode os comandos:
echo 5 > /proc/sys/vm/dirty_background_ratio
echo 10 > /proc/sys/vm/dirty_ratio
E era isso :-)
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
Reinicie o sistema e era isso.
Caso queira otimizar sem reiniciar, rode os comandos:
echo 5 > /proc/sys/vm/dirty_background_ratio
echo 10 > /proc/sys/vm/dirty_ratio
E era isso :-)
Assinar:
Postagens (Atom)