Não sei quando foi, mas aconteceu. Era algo que eu imaginava a algum tempo: um dropbox da vida mantido pela canonical e integrado ao Ubuntu. O projeto em Beta se chama UbuntuOne, e infelizmente depende de um “invitation” para participar ( eu já solicitei o meu ).
Na versão gratuita são oferecidos 2gb de espaço para o usuário, um ícone na área de notificação permite o acesso as funcionalidades do produto, que no momento são: integração com o Nautilus, capacidade de compartilhar arquivos com outros usuários, sincronização e uma interface Web que permite o acesso aos dados.
Alem da versão gratuita,existe também a versão paga, que por enquanto tem como único diferencial o espaço, são 10gb por 10 doletas mensais.
Antes que alguém pergunte, o protocolo em que está sendo desenvolvido o UO é livre e o cliente é open source. Contudo o servidor é da Canonical e não existem planos de disponibilizar o código fonte! Mas nada impede que alguém desenvolva um servidor próprio baseado nas especificações públicas.
Em um futuro próximo vai ser liberado uma API(fato) em cima do CouchDB(meio-fato) para que desenvolvedores possam projetar suas apps e trabalhar diretamente com o UO. Isso vai servir para facilitar a sincronização de dados dos diversos aplicativos do Ubuntu entre máquinas diferentes.
Update:
Leia também: http://tarzxvf.com/ubuntu-one-primeiras-impressoes
Ontem a noite fiz a instalação do Ubuntu 9.04, e até agora só tive 4 problemas. São eles:
- O driver Open Source para placa de Vídeo ATI as vezes “pisca” a tela.
- O driver proprietário fglrx causa um crash no sistema.
- O Liferea trava logo depois de abrir.
- O ctrl+alt+backspace não funciona.
Os 3 primeiros são bugs, e só me resta esperar uma atualização. Já o lance do backspace dizem que é feature! Tá bom…
Enfim, para desabilitar essa “feature” basta adicionar no fim do seu xorg.conf:
Section "ServerFlags"
Option "DontZap" "False"
EndSection |
Outra alternativa válida é rodar:
pascal@workaholic:~$ sudo apt-get install dontzap
seguido de:
pascal@workaholic:~$ dontzap – -disable
update 1:
O Eri foi alem e consultou as fontes do texto sobre latência, e indicou esse como leitura para entender bem o conceito.
ps. eu li e confirmo, realmente vale a pena ler o texto
Oi, tudo bom?
Para o sysadmin que ainda não leu, LEIA!
Leia com cuidado, atenção, reflita sobre e depois leia de novo!
http://lonesysadmin.net/2008/09/08/downtime/
http://highscalability.com/latency-everywhere-and-it-costs-you-sales-how-crush-it
nota mental: talvez seria uma boa eu traduzir e postar por aqui!
E se possível eu gostaria de ver um post do Eri Ramos sobre o tema! Acho que ele pode ter uma boa história para contar
Em 2007 eu fiz uma experiência com modens/routers. A pesquisa englobou links estáticos e dinâmicos de uma fornecedora de internet aqui do Sul. Eu escaniei 65.025 possíveis hosts, procurando por equipamentos com as portas 23/80 (que pode caracterizar um router) e testei uma amostra dos resultados utilizando as senhas padrões dos dispositivos.
O trabalho foi bem manual e me tomou aproximadamente 2 semanas porem trouxe algumas conclusões interessantes, como por exemplo:
dentre o pessoal que usa 3com o habito de trocar a senha padrão é bem maior se comparado ao pessoal que usa dlink. Mas isso é bem óbvio né? E dentre os dlinks somente 30%~40% trocava as senhas dos equipamentos. Isso significa que 6 ou 7 em cada 10 pessoas com dlinks mantinham a senha default.
Nos últimos 2 meses tem se falado muito a respeito de uma botnet de modens/routers, segundo as informações disponíveis ela compreende um grupo de equipamentos que permite ao atacante instalar um ‘novos software’ com alguma facilidade. Depois de instalado, esse worm se conecta a canais de mirc a espera de comandos do dono da botnet. Alem é claro de procurar novos equipamentos para infectar, inclusive testando as senhas default.
Eu resolvi repetir a experiência em menor escala. Como da ultima vez, escrevi um código que busca por routes/modens, e em seguida tenta logar no equipamento e me retornar o DNS usado. Fiz o script baseado em um Router DL-500B. E qual a surpresa?
Em 255 hosts estáticos escaniados encontrei 16 possíveis roteadores, 8 deles eram DL-500B e 5 deles logaram com a senha default e me retornaram o DNS. Pois é, nos últimos 2 anos as coisas não mudaram muito.
Você percebe a gravidade dessa situação? Só para citar como exemplo a questão do DNS, alguém mal intencionado poderia trocar os servidores DNS do equipamento, por um DNS próprio que aponte para sites falsos. Dessa forma seria bem fácil roubar usuários e senhas de serviços populares como o gmail, hotmail, ou até mesmo dados bancários. Considerando ainda que os links estáticos dessa fornecedora são para uso empresarial a situação fica ainda pior.
Para quem ficou curioso, a base do script que faz o scan é essa:
#!/usr/bin/python import os import re rede = 'x.x.x.' for i in range(255): final = str(i) tmp = os.popen("nmap -PN -p80,23 " +rede+final).read() if (re.search("open telnet",tmp)!=None) and (re.search("open http",tmp)!=None): print "Provavelmente um router: ",rede+final |
Já o resto do script eu não vou postar, para evitar que os kids façam bobagem!
Alguma vez enquanto você escrevia um código já aconteceu de “acidentalmente” soltar um rm * no lugar errado? Pois é, comigo já. Aconteceu ALGUMAS vezes, teve até um dia que isso aconteceu DUAS vezes, e lá vai o tanso aqui reescrever todo o código.
Alguns podem dizer que a melhor maneira de evitar isso é usar um repositório versionado. Mas e se você quer apenas escrever um script? Não precisa nem ser “bonito”, basta funcionar? Nesses casos o uso de um repositório parece que só te atrasa.
Pensando nisso (e usando a filosofia do não precisa nem ser bonito, basta funcionar), criei esse fim de semana o backup_this. Basicamente é uma ferramenta que comprime a pasta corrente em um arquivo .tar.gz e envia ela para o gmail.
Funciona assim:

Se você quiser testar pode fazer o download aqui, depois é só mover para /usr/bin/ e colocar a permissão de execução.
Eu estou gostando, acho que até que vou fazer umas melhorias. Incluir envio por ssh, exclusão de tipos de arquivos, passagem de alvos como parâmetros e etecétera.
Eu não gosto muito de trabalhar com servidores de e-mail, na sua maioria são caóticos em se tratando do gerenciamento. Tudo que você quer fazer depende de muitas modificações nos arquivos de configuração, adição de patches ou softwares extras. Particularmente me desagrada muito a maneira como se linka os mail servers a um banco de dados para gerenciar usuários e domínios. Mas aparentemente não sou o único a pensar assim.
Duncan McGreggor levou isso ao próximo nível, o cara codificou o próprio mail server. Infelizmente ele parou com a “loucura” mas felizmente ele disponibilizou o código no launchpad.
Estive pensando em dar uma olhada, e quem sabe, trabalhar em cima do código, ou talvez eu deva fazer o meu próprio? Com certeza traria um bocado de conhecimento e muitas horas de diversão!
E você? Já teve vontade de reescrever um software por não gostar dos já disponíveis na comunidade?
São eles:
4.2.2.1
4.2.2.2
4.2.2.3
4.2.2.4
4.2.2.5
4.2.2.6
Essa dica brotou nos meus feeds: Easy to remember public DNS servers
Como o título sugere, é uma lista de DNS servers fáceis de serem memorizados. Ideal para troubleshooting, principalmente em se tratando dos pontos 1, 3, 5 e 7!
Para mim é uma mão na roda.
Os sistema Gnu/Linux permitem ao usuário/administrador a possibilidade de parar e retomar tarefas, bem como enviar tarefas para background ou foreground. Tomemos como exemplo o seguinte script:
#!/bin/bash echo "Iniciado " for ((i=1;i<=20;i++)) do sleep 1 done echo "Finalizado" exit 0 |
Ele simplesmente faz um for de 1 a 20 com um sleep de 1 seg. Isso faz com que entre a exibição de “Iniciado”, e a exibição de “Finalizado” se passe 20 segundos.
Aplique o modo de execução no arquivo e execute em um terminal:
pascal@workaholic:~$ chmod +x exemplo.1.sh
pascal@workaholic:~$ ./exemplo.1.sh
Como esperado, durante os próximos 20 segundos seu terminal estará inutilizado. Agora vamos tentar uma abordagem diferente:
Inicie uma tarefa e em seguida pare essa tarefa (Ctrl-Z):
pascal@workaholic:~$ ./exemplo.1.sh
Iniciado
^Z
[1]+ Stopped ./exemplo.1.sh
Exiba as tarefas:
pascal@workaholic:~$ jobs
[1]+ Stopped ./exemplo.1.sh
Agora reinicie a tarefa em background:
pascal@workaholic:~$ bg
[1]+ ./exemplo.1.sh &
Exiba novamente as tarefas:
pascal@workaholic:~$ jobs
[1]+ Running ./exemplo.1.sh &
Coloque a tarefa novamente em foreground:
pascal@workaholic:~$ fg
./exemplo.1.sh
Finalizado
Mágico não?
Como podemos ver, as teclas Ctrl-Z nos permite parar um script ou até um programa como o mcedit, top, etc. Depois você pode gerenciar a fila de jobs utilizando os comandos:
Um atalho para colocar um programa em background é utilizar o caractere & no final da linha de comando que chama o programa. Ex.
pascal@workaholic:~$ ./exemplo.1.sh &
Iniciado
[1] 13432
pascal@workaholic:~$ jobs
[1]+ Running ./exemplo.1.sh &
O gerenciamento de tarefas não foge muito disso, existem ainda alguns detalhes a serem observados e algumas lições a serem aprendidas, mas essas você aprende fazendo.
Afinal, tudo mastigado vira vomito!
Não é de hoje que o uso de repositórios versionados como o git, bazaar, subversion e outros, se tornou comum. E com a popularização dessas ferramentas, muitas implementações interessantes tem sido feitas para outras áreas, alem do desenvolvimento de software. Uma delas – e que eu já procurava a algum tempo – é o etckeeper, que como o próprio nome sugere mantem o /etc do seu sistema em um repositório versionado.
Depois de instalado, o etckeeper se integra ao gerenciador de pacotes e comita cada alteração após a instalação de softwares ou atualização do sistema. É realmente muito prático. Alem disso você pode realizar commits manuais após alterações nos seus arquivos, mas se você esqueceu de comitar não tem problema, o etckeeper comita para você na próxima vez que o seu gerenciador de pacotes for acionado.
Como instalar e usar o etckeeper ( procedimento executado em um Ubuntu 8.10 )
* Instale os pacotes
root@saltador:~# apt-get install git-core gitk etckeeper
* Crie o repositório
root@saltador:~# etckeeper init
* Realize o primeiro commit ( fundamental para iniciar o rastreamento dos arquivos )
root@saltador:~# etckeeper commit “primeiro commit”
A partir daqui seu /etc já está sendo versionado, você pode testar modificando algum arquivo de configuração, ou utilizando o apt-get para atualizar, remover ou instalar programas.
* Você pode conferir as alterações através do aplicativo gráfico gitk
root@saltador:~# cd /etc
root@saltador:/etc# gitk
Meu interesse real é manter centralizado e versionado as configurações dos servidores que administro, vou estudar a ferramenta e confirmar essa possibilidade.
nota: Nos comentários do artigo onde descobri o etckeeper, existe algumas sugestões alternativas. Assim que encontrar o método ideal eu posto os resultados e um guia prático.
“First of all, giving names to the male cows”
PGP e GPG são coisas diferentes mas parecidas. O PGP ou Pretty Goog Privacy foi originalmente desenvolvido em 1991, e foi vagarosamente tomando espaço na rede como um método de criptografia prático e seguro. Porem, devido a problemas relacionados a patentes, uma implementação aberta do PGP foi desenvolvida em 1997 com o aval da produtora original do PGP. A essa primeira versão aberta do PGP foi dada o nome de: OpenPGP (criativo não?).
Dois anos se passam e em 1999 Werner Koch lança o release 1.0.0 do GPG – também conhecido como Gnu Privacy Guard – a essa altura o OpenPGP já era um padrão na Internet, logo, o GPG foi projetado para seguir esse padrão.

