sábado, 8 de junho de 2019

Descanse em paz André Matos 😢

A muitos anos atrás eu participava de um outro blog coletivo e fiz uma resenha de um show do Shaman. Eu ainda não encontrei para fazer um "Recordar é viver" do fundo do baú e alguns dos arquivos antigos estão guardados em algum canto do material que veio comigo do RJ até BH.


Hoje não tem Copy & Paste mas a notícia é triste. Os dois antigos blogs tinham links justamente para as páginas do Angra e do Shaman, duas bandas que foram fundados pelo André Matos. E, de alguma forma, influenciou o antigo blog e quem escrevia, incluindo eu e mais alguns amigos.

Então, como homenagem, vou deixar um link do Youtube, que encontrei da música Fairy Tale, da banda Shaman. Da mesma época em que criei a resenha quando fui a um show deles na Barra.



Esta pessoa aqui que já participou do www.juvifa.webblogger.com.br, que virou www.juvidadi.blogger.com.br (os dois já não existem mais) e, atuamente, em carreira solo no site www.adilson.net.br só tem que dizer obrigado por ser parte das nossas vidas e obrigado por ser uma referência ao Rock nacional e internacional. Descanse em paz.


sábado, 13 de abril de 2019

A imagem do buraco negro e o avanço da ciência



Esta semana o mundo ficou maravilhado com a divulgação da primeira foto de um buraco negro. Na verdade nem é do próprio buraco negro. E sim do que está ao redor dele. Uma espécie de sombra já que nada consegue escapar dele. O que vemos, na foto, é o disco de acreção que fica ao redor dele. Então, o que está no meio é, com a mais absoluta certeza, um buraco negro.



Esse foi um trabalho de três anos processando 5 petabytes de dados coletados por diversos radiotelescópios espalhados pelos mais diversos cantos do mundo. A quantidade de dados é tão enorme que os dados foram 'transmitidos' por voos de avião. Ou seja, um carregamento enorme de HDs para serem processados.

Katie Bouman, a principal responsável pelo algorítimo para chegar na imagem com uma pequena parte dos dados.  
E este vídeo mostra como foi feita esta coleta e o porque da escolha do M87, apensar de ser em inglês.




Talvez teremos uma foto do Sagitarius A* mas vai demorar um pouco. Apesar de perto ele é menor e bem mais calmo que o buraco negro do M87. Tanto que preparei um vídeo mostrando a tremenda distância que este buraco negro está e a comparação com o sistema solar e o Sagitarius A*.



E, sim, este buraco negro é enorme mesmo. Mas, como foi mostrado no primeiro vídeo, ele é um pontinho que está muito, muito longe. Por isso que saiu um pouco borrado. Mas a importância desta imagem é mostrar que Einstein está certo e todos aqueles que previram os buracos negros conseguiram acertar. Então um marco como este tem que ser comemorado. No futuro, com o avanço da ciência, teremos imagens melhores. Mas isso é apenas um começo.

Mais detalhes: https://eventhorizontelescope.org/
https://www.youtube.com/channel/UC_Fk7hHbl7vv_7K8tYqJd5A - Canal do Space Today. Não vou citar um porque tem vários vídeos falando sobre o assunto. Então é melhor assistir todos.

E tenham um bom final de semana.

domingo, 10 de março de 2019

A senha ji32k7au4a83 parece segura mas não é e é muito comum.



Eu esbarrei numa notícia bem curiosa sobre senhas em https://www.tecmundo.com.br/seguranca/139309-senha-ji32k7au4a83-parece-segura-entenda-password-comum.htm que tem a sua fonte em https://gizmodo.com/why-ji32k7au4a83-is-a-remarkably-common-password-1833045282 que explica sobre uma senha que, apesar de ter letras e números é tão insegura como qualquer outra.

Mas aí você imagina: "Mas ela já foi publicada então já deixou de ser segura já que todo mundo sabe sobre ela." É verdade. Se é pública então deixa de ser seguro. Mas o motivo de ser inseguro é algo totalmente diferente.

Vou evitar um pouco o Copy & Paste e contar toda a história. Tudo começou em um simples tweet do Robert Ou, que ficou intrigado sobre o motivo dessa senha ser tão comum e insegura, estando várias vezes no site Have I been Pwned:


Não demorou muito e a resposta apareceu e o problema é de um teclado lá de Taiwan.

Teclado Zhuyin. Fonte: Apple


Existe uma codificação usada para gerar os caracteres em chinês e a tal senha pode ser traduzida como:

ji3 -> 我
2K7 -> 的
au4 -> 密
a83 -> 碼

Que forma 我的密碼 que pode ser pronunciado como "Wǒ de mìmǎ" e isso pode ser traduzido como "Minha senha".

Isso daí quer dizer minha senha????

Isso mesmo. Tão insegura quanto a palavra password ou senha. E ninguém, fora de Taiwan, poderia imaginar que uma senha dessas pode ser tão insegura assim.

Por isso sempre tem que ter cuidado na hora de criar as senhas. Essa daí já está queimada por conta deste detalhe também já está incluída em muitos dicionários para ataque de força bruta.

Tenham uma ótima semana.



segunda-feira, 4 de março de 2019

Lançado o Linux 5.0



A algumas horas atrás foi liberada a mais nova versão do kernel do Linux, a 5.0.


Era para ser a 4.21, mas o Linus resolveu mudar a numeração logo para 5.0 do mesmo jeito que foi da 3.0 para 4. Então a diferença não é tão grande assim. Mesmo assim tem várias novidades como.

  • Suporte ao AMD Radeon FreeSync;
  • Trabalho contínuo no desenvolvimento do Intel Icelake e outros novos recursos de CPU;
  • Recursos de rolagem de alta resolução da Logitech;
  • Melhorias de rede e muito mais.

Uma lista completa pode ser conferida em: https://kernelnewbies.org/Linux_5.0

Pode haver alguma complicação para placas NVIDA mas isso se resolve na última versão do driver. Ou, se ainda não estiver disponível na sua distribuição, pode dar uma olhada em http://rglinuxtech.com/. O mesmo vale para os drivers do Vmware.

Quem quiser baixar direto é só ir em: https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.0.tar.xz.

Mais informações:


Tenham um bom Carnaval.

domingo, 24 de fevereiro de 2019

Usando rebase para unificar as alterações no git.

Voltamos ao assunto do git

Essa é uma continuação do https://www.adilson.net.br/2018/02/removendo-commits-indesejaveis-do.html onde, por algum motivo, não conseguimos remover aquela entrada indesejável, após a correção do código das dicas anteriores. Mas, antes, volto a repetir o disclaimer abaixo:

OBS: Este blog não se responsabiliza por estragos causados por quem seguir as dicas a seguir. Se não quer ter problemas no seu repositório ou no repositório dos outros, FAÇA UM BACKUP PRIMEIRO. Seja dando um clone em outro lugar, copiando a pasta .git para um outro lugar ou dando um tar/zip no seu repositório. Depois não venha chorando dizendo que fez besteira.


Agora vamos voltar para a seguinte situação. Os estagiários fizeram tanta alterações no meio, por exemplo:

Number Hash     Commit Message               Author

1      2c6a45b  (HEAD) Adicionando novidades Desenv.
2      93bf23d  bla bla bla bla bla          Estagiário 1
2      ae45fab  Melhorando banco de dados    Estagiário 1
3      77b9b82  Corrigindo banco de dados    Estagiário 2
4      3c9093c  Dando merge com master       Desenv.
5      b3d92c5  Adicionando novo evento      Colega
6      7feddbb  Adicionando arquivos         Desenv.
7      a809379  Commit inicial               Desenv.

Você tenta seguir a dica anterior:

git rebase --onto HEAD~4 HEAD~1 master


Mas acaba em:

Um monte de erros antes...

error: Failed to merge in the changes.
Patch failed at 0001 Adicionando novidades
hint: Use 'git am --show-current-patch' to see the failed patch

Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort"
.

E agora????

Nem tudo está perdido. Antes rode o comando: "git rebase --abort",  "git reset --hard origin/master" e, rode este comando:

git rebase -i HEAD~4 


Vai aparecer várias linhas para fazer as alterações neste estilo:

pick 77b9b82 Corrigindo banco de dados
pick ae45fab Melhorando banco de dados
pick 93bf23d bla bla bla bla bla
pick 2c6a45b Adicionando novidades


Note que a ordem está inversa. Agora, de cima para baixo, troque, a partir da seguinda linha, a palavra pick por squash (ou s que o resultado é o mesmo). O resultado fica, mais ou menos assim:

pick 77b9b82 Corrigindo banco de dados
s ae45fab Melhorando banco de dados
s 93bf23d bla bla bla bla bla
s 2c6a45b Adicionando novidades

Salva e uma outra janela de edição aparece. Neste caso ele mostra todas as linhas dos commits. Comenta todas, menos a que você deseja manter. Isso não altera no resultado final. Mas, como você quer se livrar dos commits indesejáveis, comentar faz todo sentido.

Daí só salva e os commits antigos foram devidamente eliminados quando foi feito a unificação. Mas isso só vale se fez a devida correção no seu commit. Caso contrário faça alguns reverts antes e siga a mesma dica, mudando apenas o número das linhas no HEAD, que aumentou com os reverts.

Mais informações em:

https://www.internalpointers.com/post/squash-commits-into-one-git


Tenham um bom domingo uma ótima semana.


quinta-feira, 24 de janeiro de 2019

Usando o sshuttle para conectar no OpenVPN

Hoje vamos ver túneis

Obs: Não costumo alterar os endereços mas, quem mandou escrever durante o sono 😴. Então quem curtiu pode curtir novamente e desculpe pelos transtornos. Agora o texto já revisado.

Hoje vamos numa situação bem hipotética. Você está com um notebook, em uma rede protegida por um firewall poderoso e precisa acessar um servidor, que se situa a alguns quilômetros daqui, que só é acessível via VPN. Daí tenta rodar o openvpn para conectar e descobre que o firewall desta rede bloqueia os pacotes udp usados pelo software.


O que fazer, neste caso??? O único acesso concreto é em um outro servidor, na porta ssh 22. Esse o acesso é normal. Mas você precisa acessar aquela rede. Bom, para tudo tem um jeito e existe sim, como acessar e, para isso temos o sshuttle.

Mas como fazer para utilizar?? Primeiro instalamos o sshuttle.

Depois, como root, podemos rodar os seguintes comandos:

ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100


Esses dois comandos marcam os pacotes udp para que o sshuttle use a tabela mangle do iptables.

Depois

shuttle --method tproxy -r usuario@servidor.remoto.com.br ip.do.servidor.vpn/32


Deve pedir uma senha do ssh ou use o esquema de chaves publica e privada e, dando certo, deve formar um túnnel e roteando todos os pacotes que vão para ip.do.servidor.vpn sejam direcionados para o primeiro tunnel.

Logo em seguida,  rode o cliente vpn que vai conectar direto. Neste caso o tunnel pega o caminho do ssh, chega no servidor remoto e, este servidor remoto conecta com o servidor vpn. Com isso será possível usar o tunnel normalmente sem se preocupar com o bloqueio do firewall.

Eu não deixei muitos exemplos já que pode usar openvpn ou qualquer outro tipo de vpn que utiliza pacotes UDP.

Mais detalhes pode conferir na documentação do sshuttle.

Tenham uma boa semana.