Finalmente saiu o trailer do Big Buck Bunny (antigo Peach).
Para quem não conhece, trata-se da primeira animação a ser totalmente produzida usando uma ferramenta livre, mais especificamente o Blender.
Não perca mais tempo e veja o trailer aqui.
terça-feira, 18 de março de 2008
Big Buck Bunny - Veja o trailer
Finalmente saiu o trailer do Big Buck Bunny (antigo Peach).
Para quem não conhece, trata-se da primeira animação a ser totalmente produzida usando uma ferramenta livre, mais especificamente o Blender.
Não perca mais tempo e veja o trailer aqui.
fisl9.0 - A grade preliminar já está disponível
Liberada a grade preliminar do fisl9.0.
É importante ressaltar que é uma grade preliminar e que deverá sofrer muitas mudanças até a data do evento, como por exemplo, a alteração das trilhas que no momento estão sub divididas.
As novidades deverão ser diárias, por isso fiquem de olho.
:-)
É importante ressaltar que é uma grade preliminar e que deverá sofrer muitas mudanças até a data do evento, como por exemplo, a alteração das trilhas que no momento estão sub divididas.
As novidades deverão ser diárias, por isso fiquem de olho.
:-)
segunda-feira, 17 de março de 2008
Mudança no blog
Seguindo as mudanças que eu já havia feito em meu blog, quando resolvi manter esse endereço somente para tratar de software livre e open source, resolvi também mudar o nome e a URL do mesmo.
Sendo assim, refletindo as mudanças, agora o mhterres@linux:/home/MarceloTerres passa a se chamar Mundo Open Source e atende agora na URL http://mundoopensource.blogspot.com.
Espero fazer jus ao nome. ;-)
Sendo assim, refletindo as mudanças, agora o mhterres@linux:/home/MarceloTerres passa a se chamar Mundo Open Source e atende agora na URL http://mundoopensource.blogspot.com.
Espero fazer jus ao nome. ;-)
sábado, 15 de março de 2008
fisl9.0 - falta pouco mais de 1 mês
Pois é, o fisl está chegando de novo.
Esse ano estamos de volta a PUC, o que certamente vai agradar muita gente. Confesso que a área da Fiergs era melhor, mas, do meu ponto de vista, faltava transporte e mais opções pra alimentação.
De qualquer forma, o último fisl realizado na PUC (fisl 6.0 em 2005) foi um sucesso, e estamos fazendo todo possível para que esse ano seja outro sucesso como de costume.
Entre as presenças internacionais, teremos nomes já tradicionais no evento como Jim McQuillan (LTSP), Jon Maddog Hall, Etienne Delacroix, entre outros.
Já entre as novidades, temos a presença do pessoal da Mozilla Foundation (Mitchell Baker, Chris Blizzard, Chris Hofmann, Marcio Galli), do pessoal do Google (Zaheda Bhorat, Bram Moolenaar - criador do Vim), do pessoal da OSI (Danese Cooper, Rishab Ghosh), entre tantos mais. Além disso teremos presença em peso também da área de Open Source da Sun, que darão várias palestras no evento (Rich Sands, Ray Gans, Roger Brinkley, Bruno Souza, etc).
Veja a lista em http://fisl.softwarelivre.org/9.0/www/palestrantes (atenção, a mesma é atualizada periodicamente, então fique de olho).
A grade de programação preliminar deverá ser lançada essa semana, mas por enquanto já temos o resultado das duas primeiras chamadas de palestras que podem ser vistas aqui.
Os eventos comunitários também já estão confirmados, assim como o Workshop de Software Livre. Destaque também pra Arena de Programação que esse ano promete muitas novidades.
É isso, agora é ficar de olho no site pra ir descobrindo o que vem por aí e de 17 a 19 de abril ir na PUCRS conferir o evento de perto.
Tenho certeza de que você não vai se arrepender. :-)
Esse ano estamos de volta a PUC, o que certamente vai agradar muita gente. Confesso que a área da Fiergs era melhor, mas, do meu ponto de vista, faltava transporte e mais opções pra alimentação.
De qualquer forma, o último fisl realizado na PUC (fisl 6.0 em 2005) foi um sucesso, e estamos fazendo todo possível para que esse ano seja outro sucesso como de costume.
Entre as presenças internacionais, teremos nomes já tradicionais no evento como Jim McQuillan (LTSP), Jon Maddog Hall, Etienne Delacroix, entre outros.
Já entre as novidades, temos a presença do pessoal da Mozilla Foundation (Mitchell Baker, Chris Blizzard, Chris Hofmann, Marcio Galli), do pessoal do Google (Zaheda Bhorat, Bram Moolenaar - criador do Vim), do pessoal da OSI (Danese Cooper, Rishab Ghosh), entre tantos mais. Além disso teremos presença em peso também da área de Open Source da Sun, que darão várias palestras no evento (Rich Sands, Ray Gans, Roger Brinkley, Bruno Souza, etc).
Veja a lista em http://fisl.softwarelivre.org/9.0/www/palestrantes (atenção, a mesma é atualizada periodicamente, então fique de olho).
A grade de programação preliminar deverá ser lançada essa semana, mas por enquanto já temos o resultado das duas primeiras chamadas de palestras que podem ser vistas aqui.
Os eventos comunitários também já estão confirmados, assim como o Workshop de Software Livre. Destaque também pra Arena de Programação que esse ano promete muitas novidades.
É isso, agora é ficar de olho no site pra ir descobrindo o que vem por aí e de 17 a 19 de abril ir na PUCRS conferir o evento de perto.
Tenho certeza de que você não vai se arrepender. :-)
Openfire: como bloquear usuários MSN usando o Gateway IM e o Packet Filter
Uma pergunta que muitas vezes me fazem é: Usando o transporte MSN no Openfire como posso fazer para liberar o usuário X para falar com somente alguns contatos do MSN, já que o padrão é que ele possa falar com todos ?
Até hoje eu ainda não tinha respostas para essa pergunta, apesar de ter uma noção de como fazer, principalmente depois que me indicaram o plugin Packet Filter. Só que hoje resolvi testar o mesmo e encontrei uma forma de resolver isso.
O que faz o plugin Packet Filter ?
O Packet Filter é uma espécie de "iptables" para Openfire. Ele permite que você aceite, rejeite ou descarte vários tipos de pacotes XMPP baseado em regras que você pode estabelecer.
É mais ou menos assim: você pode dizer que o usuário fulano não pode enviar nem receber mensagens do usuário ciclano, ou que o grupo contabilidade pode mandar e receber mensagens do grupo diretoria, mas não do grupo rh, e por aí vai.
Vendo essas features imaginei que fosse de alguma forma possível usar o recurso para filtrar os contatos MSN (ou ICQ, ou AIM, ou o protocolo que for).
Bem, descobri que É POSSÍVEL sim, mas que é um trabalho árduo pelo menos da forma que estou implementando as regras. A forma de implementação padrão obriga que os filtros sejam feitos conta a conta e para que o mesmo funcione da forma que eu implementei você tem de liberar também um a um os contatos para qual seu usuário pode enviar/receber as mensagens (inclusive os contatos Jabber do servidor local). Ou seja, numa instalação com muitos usuários usando o transporte MSN isso pode ser inviável de gerenciar/administrar.
Mas porque isso é trabalhoso ?
Porque na realidade o packet filter não foi feito para trabalhar com os transportes, mas sim com contas locais. Mas já que no Openfire, todos os contatos de um transporte tem um JID válido você pode usar o plugin para isso também.
Você pode explicar isso melhor ?
Cada usuário do Openfire ganha um JID, que é a identificação do usuário para o servidor. No meu servidor de testes, chamado openfire.inet, meu usuário marcelo responde pelo JID marcelo@openfire.inet.
Agora vejamos o caso do transporte MSN: ao vincular minha conta local Jabber (marcelo@openfire.inet) a uma conta MSN usando o plugin Gateway IM, todos meus contatos MSN ganharam também um JID válido. Então, por exemplo, o meu contato marceloterres@dominio.com passou a ter um JID local chamado marceloterres\40dominio.com@msn.openfire.inet.
Agora que ele tem um JID, eu posso usá-lo para criar regras no Packet Filter. :-)
Mas de que forma o packet filter será eficaz ? Como posso implementá-lo ?
A melhor forma que encontrei até o momento é a seguinte:
Até hoje eu ainda não tinha respostas para essa pergunta, apesar de ter uma noção de como fazer, principalmente depois que me indicaram o plugin Packet Filter. Só que hoje resolvi testar o mesmo e encontrei uma forma de resolver isso.
O que faz o plugin Packet Filter ?
O Packet Filter é uma espécie de "iptables" para Openfire. Ele permite que você aceite, rejeite ou descarte vários tipos de pacotes XMPP baseado em regras que você pode estabelecer.
É mais ou menos assim: você pode dizer que o usuário fulano não pode enviar nem receber mensagens do usuário ciclano, ou que o grupo contabilidade pode mandar e receber mensagens do grupo diretoria, mas não do grupo rh, e por aí vai.
Vendo essas features imaginei que fosse de alguma forma possível usar o recurso para filtrar os contatos MSN (ou ICQ, ou AIM, ou o protocolo que for).
Bem, descobri que É POSSÍVEL sim, mas que é um trabalho árduo pelo menos da forma que estou implementando as regras. A forma de implementação padrão obriga que os filtros sejam feitos conta a conta e para que o mesmo funcione da forma que eu implementei você tem de liberar também um a um os contatos para qual seu usuário pode enviar/receber as mensagens (inclusive os contatos Jabber do servidor local). Ou seja, numa instalação com muitos usuários usando o transporte MSN isso pode ser inviável de gerenciar/administrar.
Mas porque isso é trabalhoso ?
Porque na realidade o packet filter não foi feito para trabalhar com os transportes, mas sim com contas locais. Mas já que no Openfire, todos os contatos de um transporte tem um JID válido você pode usar o plugin para isso também.
Você pode explicar isso melhor ?
Cada usuário do Openfire ganha um JID, que é a identificação do usuário para o servidor. No meu servidor de testes, chamado openfire.inet, meu usuário marcelo responde pelo JID marcelo@openfire.inet.
Agora vejamos o caso do transporte MSN: ao vincular minha conta local Jabber (marcelo@openfire.inet) a uma conta MSN usando o plugin Gateway IM, todos meus contatos MSN ganharam também um JID válido. Então, por exemplo, o meu contato marceloterres@dominio.com passou a ter um JID local chamado marceloterres\40dominio.com@msn.openfire.inet.
Agora que ele tem um JID, eu posso usá-lo para criar regras no Packet Filter. :-)
Mas de que forma o packet filter será eficaz ? Como posso implementá-lo ?
A melhor forma que encontrei até o momento é a seguinte:
- em primeiro lugar você deve liberar todas os contatos que você quer permitir para o usuário (inclusive os contatos do servidor local e não só os do transporte MSN). A liberação é uma via de mão dupla, pois você precisa liberar o envio e precisa também liberar o recebimento de mensagens para cada contato do usuário (a não ser é claro que você queira que algum contato do usuário só possa mandar mensagens e não receber e vice versa).
- em segundo lugar você deve criar 2 regras dizendo que os pacotes de mensagens de quaisquer outros usuários serão rejeitados (ATENÇÃO: para essas regras use só os pacotes de mensagens, porque se você usar os pacotes do tipo any (quaisquer) o usuário não conseguirá nem logar no servidor).
IMPORTANTE: O packet filter, assim como o Iptables, usa precedência para as regras, por isso a primeira regra que fechar é a que vale. Dessa forma, coloque antes as regras de liberação e depois as regras de bloqueio.
Tem um exemplo prático ?
A imagem abaixo ilustra melhor a questão (clique nela para ampliar e entender).
Nesse servidor de testes (openfire.inet) o usuário marcelo@openfire.inet pode mandar e receber mensagens para/do usuário local fulano (fulano@openfire.inet) e também do seu contato MSN (marceloterres@dominio.com). Todos as mensagens enviadas/recebidas de seus demais contatos serão rejeitadas, como pode ser visto nas 2 últimas linhas.
Isso não impede que o usuário veja todos seus contatos que estiverem online e nem que eles o vejam também, mas caso o usuário tente mandar uma mensagem para um contato bloqueado o servidor Openfire informa que a mensagem foi rejeitada (uma forma de resolver a questão da visibilidade seria rejeitar todos os pacotes (any) de cada contato bloqueado, mas aí isso teria de ser feito contato a contato, ou seja, mais trabalho manual).
Acredito que a solução acima não seja a mais elegante e mais simples mas de momento foi a forma que encontrei para resolver a questão.
Talvez em breve tenhamos um plugin só para isso, ou quem sabe o próprio Gateway IM não venha a implementar esse recurso, mas para quem não pode esperar, é uma solução que pode ser implementada agora.
PS: caso tenha outra sugestões de implementação, por favor poste aqui.
UPDATE (13/11/2008): Não deixem de ler o comentário de Sarunas, pois o mesmo parece simplificar e muito o uso do Packet Filter. Eu ainda não tive tempo de testá-lo, mas assim que for possível irei fazer, e conforme também vá recebendo feedback de outras pessoas, vou postar mais sobre isso aqui.
Leia também:
Tem um exemplo prático ?
A imagem abaixo ilustra melhor a questão (clique nela para ampliar e entender).
Nesse servidor de testes (openfire.inet) o usuário marcelo@openfire.inet pode mandar e receber mensagens para/do usuário local fulano (fulano@openfire.inet) e também do seu contato MSN (marceloterres@dominio.com). Todos as mensagens enviadas/recebidas de seus demais contatos serão rejeitadas, como pode ser visto nas 2 últimas linhas.
Isso não impede que o usuário veja todos seus contatos que estiverem online e nem que eles o vejam também, mas caso o usuário tente mandar uma mensagem para um contato bloqueado o servidor Openfire informa que a mensagem foi rejeitada (uma forma de resolver a questão da visibilidade seria rejeitar todos os pacotes (any) de cada contato bloqueado, mas aí isso teria de ser feito contato a contato, ou seja, mais trabalho manual).
Acredito que a solução acima não seja a mais elegante e mais simples mas de momento foi a forma que encontrei para resolver a questão.
Talvez em breve tenhamos um plugin só para isso, ou quem sabe o próprio Gateway IM não venha a implementar esse recurso, mas para quem não pode esperar, é uma solução que pode ser implementada agora.
PS: caso tenha outra sugestões de implementação, por favor poste aqui.
UPDATE (13/11/2008): Não deixem de ler o comentário de Sarunas, pois o mesmo parece simplificar e muito o uso do Packet Filter. Eu ainda não tive tempo de testá-lo, mas assim que for possível irei fazer, e conforme também vá recebendo feedback de outras pessoas, vou postar mais sobre isso aqui.
Leia também:
Bug no Bacula versão < 2.2.5
Para quem está usando o Bacula versão 2.X < 2.2.5 é altamente recomendável o upgrade para a última versão (2.2.8).
Até a versão 2.2.4 havia um bug que me foi reportado pelo Lutieri que pode causar a maior confusão.
É o seguinte: se você rodar um restore de algum job, o bacula equivocadamente altera a data do LastWritten do volume para a data desse restore (mesmo que o restore seja somente um procedimento de leitura e não escrita).
Isso pode causar a maior dor de cabeça, pois atrapalha todo o controle de retention do volume, fazendo com que o mesmo não seja reciclado na data correta.
Mais um esclarecimento: esse problema atinge somente o servidor, então a versão no cliente pode ser mantida.
Não percam tempo e atualizem seus servidores agora.
Até a versão 2.2.4 havia um bug que me foi reportado pelo Lutieri que pode causar a maior confusão.
É o seguinte: se você rodar um restore de algum job, o bacula equivocadamente altera a data do LastWritten do volume para a data desse restore (mesmo que o restore seja somente um procedimento de leitura e não escrita).
Isso pode causar a maior dor de cabeça, pois atrapalha todo o controle de retention do volume, fazendo com que o mesmo não seja reciclado na data correta.
Mais um esclarecimento: esse problema atinge somente o servidor, então a versão no cliente pode ser mantida.
Não percam tempo e atualizem seus servidores agora.
quarta-feira, 12 de março de 2008
Openfire 3.5.0 RC1
A Ignite Realtime liberou hoje para download o Openfire 3.5.0 RC1.
Com previsão de lançamento da versão final para o final de março/início de abril, o Openfire 3.5.0 traz uma quantidade grande de novos recursos e mudanças significativas. Além disso também estão sendo disponibilizados novas versões dos plugins já existentes que serão compatíveis com o 3.5.0 (veja a lista de plugins aqui).
Entre as novidades podemos destacar:
Caso você não queria aguardar o release final, já pode baixar o RC1 aqui.
Para os que forem testar a Ignite Realtime incentiva que postem suas dúvidas no Fórum de suporte do Openfire.
Boa sorte aos Beta Testers ;-)
Com previsão de lançamento da versão final para o final de março/início de abril, o Openfire 3.5.0 traz uma quantidade grande de novos recursos e mudanças significativas. Além disso também estão sendo disponibilizados novas versões dos plugins já existentes que serão compatíveis com o 3.5.0 (veja a lista de plugins aqui).
Entre as novidades podemos destacar:
- Segurança
- Gerenciador de bloqueio de contas: permite aos administradores bloquear (desabilitar) contas previnindo que os usuários loguem. Isso pode ser feito por um período de tempo ou "para sempre".
- Auditoria para o console de administração: esse novo recurso permite armazenar as mudanças na configuração do servidor, inclusive logando quem efetuou as mesmas.
- Invisibilidade
- Agora é possível se conectar se mantendo invisível. Você pode ficar invisível para todos, mas se quiser pode ficar visível só para alguns usuários específicos.
- Performance
- Foram implementadas muitas melhorias na performance do servidor.
- Console de administração
- O console de administração foi redesenhado para otimizar e facilitar seu uso.
Caso você não queria aguardar o release final, já pode baixar o RC1 aqui.
Para os que forem testar a Ignite Realtime incentiva que postem suas dúvidas no Fórum de suporte do Openfire.
Boa sorte aos Beta Testers ;-)
sábado, 8 de março de 2008
Samba 3.0.28a
Lançado o Samba 3.0.28a que resolve uma série de bugs das versões anteriores.
Como principais pontos podemos citar:
- Corrigida a falha que não permitia fazer join em domínios Windows 2008
- Corrigidos problemas de interoperabilidade com Windows Vista (incluindo com SP1 RC)
E se preferir, faça download da nova versão.
sexta-feira, 7 de março de 2008
Sip Communicator - uma promessa interessante
Há tempos venho procurando por um software que integre os protocolos XMPP e SIP e que seja livre.
Existem por aí algumas ferramentas, mas muitas pagas e que não me agradaram na forma de licenciamento. Outra alternativa disponível seria usar o servidor Openfire e o cliente Spark com os plugins SIP, mas pelos testes realizados não acho que os mesmos estejam funcionando tão bem (ao menos ainda não).
E por um acaso do destino, quando já tinha deixado de procurar me deparei com uma nova ferramenta que está em desenvolvimento. Pois trata-se do Sip Communicator.
O Sip Communicator é a ferramenta que vem atender essa demanda da melhor forma possível. Aliando XMPP, MSN, ICQ, IRC entre outros protocolos de IM e incorporando o protocolo SIP fica fácil e muito produtivo usar o mesmo software para IM e para telefonia. E não para por aí, pois já existe a promessa de suportar IAX e quem sabe o que mais pode vir em breve.
O projeto ainda é meio cru, sendo que diariamente são lançados nightly builds (tem até repositório Debian), e ainda está na versão alpha, mas parece que tem tudo pra dar certo.
Testei o mesmo e encontrei alguns bugs (o que é bastante compreensível nessa etapa de desenvolvimento), entre eles:
- Ao cadastrar uma conta jabber (eu só testei com jabber, porque era isso que me interessava. MSN, ICQ e outros protocolos pode-se implementar com transportes para maior controle) logo que se conecta a primeira vez somente alguns contatos aparecem. Para resolver isso é necessário fechar e abrir o programa novamente (desconectar e reconectar talvez baste). Depois disso tudo fica normal.
- Ao efetuar uma ligação sip, a pessoa do "outro lado da linha" escuta a voz cortada. Observei esse comportamento tanto para Linux quanto para Windows.
Por outro lado a comunição XMPP foi tranquila e sem problemas. A interface é interessante (ao contrário do que encontrei quando testei o Instantbird), mas deve ser melhorada mais pra frente.
Com certeza o Sip Communicator é um projeto que promete, e todos aqueles que tem o desejo de usar um único cliente XMPP/SIP devem ficar de olho no mesmo.
Veja os screenshots aqui.
PS: se você resolver testar o mesmo seus comentários serão muito apreciados.
quinta-feira, 6 de março de 2008
Pidgin 2.4.0
Foi lançado no final do mês passado o Pidgin 2.4.0.
Ele tem bastante melhorias e alguns recursos novos, mas do meu ponto de vista nada excepcional.
Veja o ChangeLog completo aqui e baixe os pacotes pra Ubuntu/Debian aqui
Ele tem bastante melhorias e alguns recursos novos, mas do meu ponto de vista nada excepcional.
Veja o ChangeLog completo aqui e baixe os pacotes pra Ubuntu/Debian aqui
quarta-feira, 5 de março de 2008
Openfire 3.5.0 adiado
Poxa, estava todo empolgado com o lançamento do Openfire 3.5.0 amanhã e quando fui no site da Ignite Realtime levei um banho de água fria.
A versão foi adiada para ser lançada juntamente com o Clearspace 2.0, um outro software colaborativo da Jive Software (braço comercial da Ignite Realtime).
Então fica assim. Aguardaremos novamente até mais ou menos o final de março e início de abril.
Leia aqui a notícia.
A versão foi adiada para ser lançada juntamente com o Clearspace 2.0, um outro software colaborativo da Jive Software (braço comercial da Ignite Realtime).
Então fica assim. Aguardaremos novamente até mais ou menos o final de março e início de abril.
Leia aqui a notícia.
sexta-feira, 29 de fevereiro de 2008
Atualizações de segurança do Debian Sarge vão até o dia 31 de março
Recebi hoje um e-mail informando que o suporte de atualizações de segurança para o Debian Sarge (3.1) segue somente até o dia 31 de março.
Segue o e-mail:
É hora de começar a preparar os dist-upgrades. :-)
Segue o e-mail:
------------------------------------------------------------------------
The Debian Project http://www.debian.org/
Security Support for Debian 3.1 to be terminated press@debian.org
February 29th, 2008 http://www.debian.org/News/2008/20080229
------------------------------------------------------------------------
Security Support for Debian GNU/Linux 3.1 to be terminated on March 31st
One year after the release of Debian GNU/Linux 4.0 alias 'etch' and
nearly three years after the release of Debian GNU/Linux 3.1 alias
'sarge' the security support for the old distribution (3.1 alias
'sarge') is coming to an end next month. The Debian project is proud
to be able to support its old distribution for such a long time and
even for one year after a new version has been released.
The Debian project has released Debian GNU/Linux 4.0 alias 'etch' on
the 8th of April 2007. Users and Distributors have been given a
one-year timeframe to upgrade their old installations to the current
stable release. Hence, the security support for the old release of
3.1 is going to end in March 2007 as previously announced.
Previously announced security updates for the old release will continue
to be available on security.debian.org.
É hora de começar a preparar os dist-upgrades. :-)
domingo, 24 de fevereiro de 2008
EasyVMX! - criador online de virtual machines para VMWare
Se você usa o VMPlayer e não sabe como fazer para criar suas VMWares "do zero", o site EasyVMX! foi feito para você.Com o EasyVMX! você pode criar arquivos de VMWares para quaisquer tipo de SO e com todos os recursos necessários. Você pode informar o SO, a memória, discos, número de processadores, som, shared folders e tudo o que for necessário, como se estivesse usando um VMWare Workstation.
Aí depois de terminar de configurar sua VMWare é só fazer o download dela (em formato zip), descompactar e rodar a mesma no VMPlayer.
Muito bom !!!
Vtun 3.0.2: ainda incompatível com o servidor versão 2.X
Quando instalei o Ubuntu Gutsy tive uma surpresa desagradável: a versão do Vtun que vem na distro (3.0.0) era incapaz de se conectar a um servidor rodando a versão 2.X.
Pois bem, depois de ter desistido de usar o vtun, eis que os desenvolvedores após mais de um ano do lançamento da versão 3.X, resolveram corrigir isso na nova versão 3.0.2 que foi lançada no dia 08 passado.
Como não haviam pacotes deb, tentei instalar o mesmo de duas formas:
1)Baixei o tar.gz aqui e compilei o Vtun dos sources. PS: para instalar o Vtun usando os sources no Ubuntu, você precisará antes instalar o yacc. Para isso baixe o mesmo aqui. Eu tentei fazer dessa maneira mas obtive um erro de compilação.
2)Baixei o rpm do fc8 aqui e use o alien para convertê-lo para .deb. Depois instalei-o com o comando dpkg. Para que o mesmo iniciasse, tive ainda de fazer os seguintes passos:
Tentei isso já em 2 locais diferentes e os problemas foram os mesmos.
Se você já passou por algo semelhante e conseguiu resolver, por favor poste aqui seu comentário.
Por enquanto a minha solução foi baixar o pacote da versão anterior do Ubuntu, instalar e colocar em hold.
:-/
Pois bem, depois de ter desistido de usar o vtun, eis que os desenvolvedores após mais de um ano do lançamento da versão 3.X, resolveram corrigir isso na nova versão 3.0.2 que foi lançada no dia 08 passado.
Como não haviam pacotes deb, tentei instalar o mesmo de duas formas:
1)Baixei o tar.gz aqui e compilei o Vtun dos sources. PS: para instalar o Vtun usando os sources no Ubuntu, você precisará antes instalar o yacc. Para isso baixe o mesmo aqui. Eu tentei fazer dessa maneira mas obtive um erro de compilação.
2)Baixei o rpm do fc8 aqui e use o alien para convertê-lo para .deb. Depois instalei-o com o comando dpkg. Para que o mesmo iniciasse, tive ainda de fazer os seguintes passos:
- Criei o arquivo /etc/init.d/vtun com o seguinte conteúdo:
#!/bin/sh -e
# vim:ts=4:sw=4:et:ai:sts=4
#
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DAEMON=/usr/sbin/vtund
CONFFILE=/etc/vtund.conf
PIDPREFIX=/var/run/vtund
test -f $DAEMON || exit 0
test -f $CONFFILE || exit 0
test -f /etc/default/vtun && . /etc/default/vtun
case "$1" in
start)
if [ -f /etc/vtund-start.conf ]; then
echo "/etc/vtund-start.conf has been replaced!"
echo "Please read /usr/share/doc/vtun/NEWS.Debian"
fi
if [ -n "$RUN_SERVER" ] && [ "$RUN_SERVER" != no ]; then
echo -n "Starting vtund server: "
start-stop-daemon --start --startas $DAEMON --oknodo \
--pidfile $PIDPREFIX.server.pid -- -s $SERVER_ARGS
echo "vtund[s]."
fi
for i in 0 1 2 3 4 5 6 7 8 9; do
eval name=\$CLIENT${i}_NAME
eval host=\$CLIENT${i}_HOST
eval args=\$CLIENT${i}_ARGS
if [ -n "$name" ] && [ -n "$host" ]; then
echo -n "Starting vtund client $name to $host: "
start-stop-daemon --start --startas $DAEMON --oknodo \
--pidfile $PIDPREFIX.$name-$host.pid -- $name $host $args
echo "vtund[c]."
fi
done
;;
stop)
echo "Stopping vtund."
for i in $PIDPREFIX*.pid; do
test -f "$i" || continue
start-stop-daemon --oknodo --stop --pidfile $i
rm -f $i
done
;;
reload|force-reload)
echo "Reloading vtund.";
for i in $PIDPREFIX*; do
test -f "$i" || continue
start-stop-daemon --oknodo --stop --signal 1 --pidfile $i;
done
;;
restart)
$0 stop
sleep 1;
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac
exit 0 - Criei o arquivo /etc/default/vtun com o seguinte conteúdo:
# Session name
CLIENT0_NAME=suasessao
#
# Destination host
CLIENT0_HOST=seuservidor
#
# Optional parameters
# CLIENT0_ARGS=
- Instalei os pacotes libsll-dev, liblzo-dev e zlib1g-dev
- Rodei o comando ln -s /usr/lib/libcrypt.so /lib/tls/i686/cmov/libcrypt.so.6
- Rodei o comando ldconfig
- Configurei os dados no arquivo /etc/vtund.conf
- Iniciei o serviço e pronto, meu Vtun agora estava pelo menos iniciando.
Tentei isso já em 2 locais diferentes e os problemas foram os mesmos.
Se você já passou por algo semelhante e conseguiu resolver, por favor poste aqui seu comentário.
Por enquanto a minha solução foi baixar o pacote da versão anterior do Ubuntu, instalar e colocar em hold.
:-/
sexta-feira, 22 de fevereiro de 2008
Lançado ejabberd 2.0.0
Foi oficialmente lançado o ejabberd 2.0.0.
Entre as novas melhorias/recursos cabe citar:
Clustering e arquitetura:
Parece que os recursos do ejabberd estão caminhando em direção ao Openfire, mas de forma bem mais lenta. Enquanto a versão 2.0.0 levou 15 meses de desenvolvimento para ser lançada, novas versão do Openfire são lançadas periodicamente (destaque para a versão 3.5.0 que sai no próximo dia 6).
De qualquer maneira ainda vejo o ejabberd como uma boa alternativa para que não quer usar Java no servidor. Não dá pra esquecer que o mesmo tem o jabber.org como um de seus grandes cases, o que não é pouca coisa.
Entre as novas melhorias/recursos cabe citar:
Clustering e arquitetura:
- Nova arquitetura de cluster no frontend e no backend para assegurar melhor escalabilidade e robustez.
- Todos os componentes agora rodam no modo cluster.
- Novo algoritmo de balanceamento de carga para suportar clustering de chat multi usuário e gateways.
- Suporte a traffic shapping nos componentes para evitar abusos.
- Suporte para múltiplas conexões s2s por domínio.
- Suporte a lista negra e lista branca.
- Intervalo de retentativa de conexão s2s.
- Suporte a pool de servidores
- Suporte a clustering e balanceamento de carga.
- Habilidade de definir a configuração padrão de uma sala no arquivo de configuração do ejabberd.
- Recursos anti abuso, tais como: ACL para limitar a criação de salas persistentes por usuários autorizados, definição de número máximo de usuários por sala, limitação de número máximo de salas que um usuário pode conectar simultaneamente.
- Suporte a PAM no sistemas *nix.
- Agora o ejabberd tem tradução para o Português do Brasil, entre outros 24 idiomas.
- Logs melhorados com mais níveis
Parece que os recursos do ejabberd estão caminhando em direção ao Openfire, mas de forma bem mais lenta. Enquanto a versão 2.0.0 levou 15 meses de desenvolvimento para ser lançada, novas versão do Openfire são lançadas periodicamente (destaque para a versão 3.5.0 que sai no próximo dia 6).
De qualquer maneira ainda vejo o ejabberd como uma boa alternativa para que não quer usar Java no servidor. Não dá pra esquecer que o mesmo tem o jabber.org como um de seus grandes cases, o que não é pouca coisa.
quarta-feira, 20 de fevereiro de 2008
Openfire 3.5.0 em breve...
Li hoje que o Openfire 3.5.0 está a caminho e deve ser lançado dia 06 de março, cheio de melhorias e novas features.
Faltam 15 dias...
:-D
Faltam 15 dias...
:-D
domingo, 17 de fevereiro de 2008
Lançado Debian 4.0r3
Acaba de ser lançado o Debian 4.0r3.
Essa release não é uma nova versão, mas sim a mesma versão stable (Etch) com todas as últimas correções de segurança.
Se você já possui o CD do Debian 4.0 não precisa fazer o download. Um apt-get update; apt-get upgrade já resolve. Agora caso queira baixar o Etch, aproveite e já pegue a r3, pois irá lhe poupar uma grande quantidade de downloads.
Veja o release oficial aqui.
Essa release não é uma nova versão, mas sim a mesma versão stable (Etch) com todas as últimas correções de segurança.
Se você já possui o CD do Debian 4.0 não precisa fazer o download. Um apt-get update; apt-get upgrade já resolve. Agora caso queira baixar o Etch, aproveite e já pegue a r3, pois irá lhe poupar uma grande quantidade de downloads.
Veja o release oficial aqui.
quinta-feira, 14 de fevereiro de 2008
fisl9.0
Essa semana acabei assumindo um compromisso que vai tomar todo meu tempo livre, mas que com certeza vai ser um desafio e tanto.
Além da coordenação dos eventos comunitários, da qual já cuido desde o fisl6.0, assumi hoje também a coordenação do GT Temário (o comitê de programa) do fisl9.0, pois o Paulo Meirelles que estava cuidando disso vai precisar se afastar da função.
Vai ser muito bacana, mas com certeza também muito trabalhoso, afinal hoje faltam somente 62 dias para o fisl9.0 e ainda tem muita coisa a ser feita. Como entrei no meio do processo agora tenho de correr atrás, mas as coisas estão fluindo melhor do que eu pensava. :-)
Vou tentar dar o meu melhor para que tudo seja muito bem feito, com muito comprometimento e responsabilidade. Espero que com isso consigamos fazer um fisl à altura dos anteriores.
E por causa disso, provavelmente não terei muito tempo para postar em meus blogs, assim eles devem ficar meio desatualizados (mas prometo que vou tentar).
Ah, e por falar no fisl, não perca tempo e inscreva-se já.
Vejo vocês lá.
Além da coordenação dos eventos comunitários, da qual já cuido desde o fisl6.0, assumi hoje também a coordenação do GT Temário (o comitê de programa) do fisl9.0, pois o Paulo Meirelles que estava cuidando disso vai precisar se afastar da função.
Vai ser muito bacana, mas com certeza também muito trabalhoso, afinal hoje faltam somente 62 dias para o fisl9.0 e ainda tem muita coisa a ser feita. Como entrei no meio do processo agora tenho de correr atrás, mas as coisas estão fluindo melhor do que eu pensava. :-)
Vou tentar dar o meu melhor para que tudo seja muito bem feito, com muito comprometimento e responsabilidade. Espero que com isso consigamos fazer um fisl à altura dos anteriores.
E por causa disso, provavelmente não terei muito tempo para postar em meus blogs, assim eles devem ficar meio desatualizados (mas prometo que vou tentar).
Ah, e por falar no fisl, não perca tempo e inscreva-se já.
Vejo vocês lá.
quinta-feira, 7 de fevereiro de 2008
youtube-dl
Já tinha lido algo sobre o youtube-dl, esse software para download de vídeos do YouTube feito em Python, mas nunca tinha me animado em testar.
Hoje porém quis fazer um teste e realmente aprovei a ferramenta.
O youtube-dl é um pequeno script de mais ou menos 15Kb que faz muito bem o seu trabalho. Basta informar a URL que ele se encarrega de providenciar o download do vídeo (em formato flv). Além disso ele possui algumas outras opções, como por exemplo usuário e senha, que deve ser usado caso seja necessário logar antes para assistir o vídeo.
Quem quiser baixar os vídeos do YouTube vai encontrar nessa ferramenta um excelente aliado.
Hoje porém quis fazer um teste e realmente aprovei a ferramenta.
O youtube-dl é um pequeno script de mais ou menos 15Kb que faz muito bem o seu trabalho. Basta informar a URL que ele se encarrega de providenciar o download do vídeo (em formato flv). Além disso ele possui algumas outras opções, como por exemplo usuário e senha, que deve ser usado caso seja necessário logar antes para assistir o vídeo.
Quem quiser baixar os vídeos do YouTube vai encontrar nessa ferramenta um excelente aliado.
Assinar:
Postagens (Atom)