domingo, 15 de agosto de 2021

Criando um pendrive com mais de um sistema operacional com o Ventoy

Nestes tempos em que muitas máquinas não vem mais com drive de CD/DVD, precisamos nos virar com os pendrives e bootar pela porta USB. Mas isso nem sempre é fácil.

Para uma distribuição Linux atual podemos pegar uma imagem e rodar o comando:

dd if=imagem.iso of=/dev/sdd (Usei sdd como exemplo. Mas pode ser sdb, sdc ou qualquer outro dependendo da sua máquina. Só não pode ser sda ou algum outro ocupado por um HD senão perde os seus arquivos e talvez terá que reinstalar o seu sistema operacional).

No Windows você pode apelar para o Rufus.

Já uma imagem de instalação Windows, tem a ferramenta própria da Microsoft (Media Creation Tool) ou, se estiver no Linux, procurar por algumas ferramentas, por exemplo: https://github.com/WoeUSB

Mas hoje eu esbarrei em uma nova ferramenta que permite fazer algo que facilita muito as coisas. Você, simplesmente, joga algumas isos e pode bootar elas em um menu, na inicialização. Essa ferramenta se chama Ventoy.


Para usar só é preciso fazer um download em https://www.ventoy.net/en/download.html e escolher o arquivo conforme o seu sistema operacional. Aqui vou usar o Linux, por exemplo. Neste caso o ventoy-1.0.50-linux.tar.gz que é a última versão no momento da publicação. Descompacta, entra dentro da pasta ventoy-1.0.50 e rode o comando, como root ou  usando o sudo antes: bash VentoyWeb.sh

Vai aparecer uma mensagem assim:


===============================================================
 Ventoy Server 1.0.50 is running ...
 Please open your browser and visit http://127.0.0.1:24680
===============================================================

################## Press Ctrl + C to exit #####################

Acessa o site que vai encontrar a interface web do programa:



Se estiver em inglês pode ir em Languages se quiser mudar. De preferência deixe um pendrive plugado. Neste exemplo estou usando um de 8 GB para testar. Vai em Instalar. Ele vai alertar que os dados serão perdidos já que será reformatado e clica em OK 2 vezes. (Verificação dupla para não se arrepender depois).

Após a instalação o pendrive estará pronto para uso. Entre no pendrive e copie algumas isos.


No exemplo coloquei as imagens do Clonezilla, do Debian Bullseye, que saiu ontem, o Gparted Live, o Rocky Linux e a instalação do Windows 10.

Só não coloquei o Ubuntu por falta de espaço.

Agora pegue um computador e inicializa pela usb que vai encontrar a seguinte tela:


Neste ponto é só escolher uma imagem no menu e, pronto, a iso vai iniciar sem problemas.

Quando quiser atualizar é só colocar uma nova imagem no pendrive e ele estará pronto para o uso.

As vezes pode acontecer de uma iso não funcionar e deixar a tela bagunçada. Nos testes isso aconteceu em um notebook Dell com as imagens da Debian e Rocky Linux e não aconteceu em uma máquina virtual. Neste caso existe um workaround.

Crie uma pasta ventoy dentro do pendrive e baixe o arquivo https://www.ventoy.net/download/ventoy.json nele . O conteúdo este arquivo é simplesmente:
{
    "theme": {        
        "display_mode": "CLI"
    }
}

Ele muda a interface para texto, no estilo simples do GRUB, e a inicialização das isos ocorre sem problemas.

OBS: No FAQ ele menciona o problema em imagens Windows. Mas nos testes isso ocorreu nestas duas imagens Linux e o Windows inicializou normal. Pelo menos a solução deu certo no notebook Dell.

Com isso você terá um pendrive inicializável com a opção de rodar qualquer imagem de uma maneira fácil e prática.

Como referência vou deixar este vídeo, que foi no qual descobri esta ferramenta do canal TechHut. Ele está em inglês mas mostra a ferramenta já em ação.


Tenham um bom domingo.

sábado, 14 de agosto de 2021

Lançado o Debian Bullseye

 



Depois de 2 anos, 1 mês, 9 dias de desenvolvimento e um sábado inteiro de atualizações, foi lançando, agora a pouco, a versão 11.0 da distribuição Debian, também conhecida como Bullseye, o cavalo do Woody.

Existem várias novidades que está descrito no link de lançamento, o que pode incluir o suporte ao sistema exFAT dentro do kernel oficial. A inclusão do pacote ipp-usb, para uso de impressoras, via USB sem um driver específico e muitos outros.

Para baixar os cds, dvds e outras mídias para instalação é só acessar o site https://www.debian.org.

Tenham um bom final de semana.

domingo, 27 de junho de 2021

Como migrar de CentOS 8 para o Rocky Linux 8

Aconteceram várias coisas nesta semana. Dentre elas o anuncio de uma nova versão do Windows pela MicrosoftCPI pegando fogo no Senado (Que sexta foi essa??) e mais algumas outras. Mas nós vamos focar em um lançamento no mundo Linux: O lançamento do Rocky Linux 8.4.



Como foi explicado em https://www.adilson.net.br/2020/12/o-centos-como-conhecemos-chegara-ao-fim.html, o Rocky Linux pretende ser uma distribuição 100% compatível com o Red Hat Enterprise Linux (RHEL), o que o tornará o que o CentOS deixará de ser no final do ano. Um clone gratuito do RHEL no qual não será necessário pagar para baixar as atualizações.

"Ain, mas a Red Hat já disponibilizou o RHEL gratuito para pequena escala."

Eu sei, a pressão dos usuários leva a isso. Mas aí já é tarde demais. E se precisar de ir além de 16 máquinas, alguma alternativa? É aí que comentei no post anterior sobre o assunto. Se um projeto não está mais agradando a comunidade, vamos partir para um fork?

É neste ponto que o Gregory Kurtzer, um dos criadores originais do CentOS, resolveu agir e, com ajuda de usuários e empresas, como a Amazon Web Services, Google, e Microsoft, chegamos na disponibilização de uma versão estável do Rocky Linux.

E como o Rocky Linux é um clone do RHEL, é possível passar do CentOS 8 para o Rocky Linux 8. Uma publicação em https://ostechnix.com/how-to-migrate-to-rocky-linux-8-from-centos-8-linux/ explica como isso é feito e vou reproduzir logo 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 sistema ou no sistema dos outros, FAÇA UM BACKUP PRIMEIRO. Seja gerando uma imagem em disco do sistema On Premise, gerando um snapshot da sua máquina virtual ou do seu provedor em nuvem, ou tendo uma máquina reserva com o sistema antigo. Depois não venha chorando dizendo que fez besteira.

E a explicação será sem o sudo, diferente da publicação original estarei usando os comandos como usuário root. Mas quem tem usuário no arquivo sudoers pode rodar com o sudo por mais segurança.

1) Atualize os pacotes para a sua última versão:

dnf --refresh upgrade

2) Se houver atualizações, principalmente de kernel, rode o comando 'reboot'

3) Veja se está rodando o CentOS 8 no seu sistema (A migração não funciona com CentOS 7)

cat /etc/redhat-release

A saída tem que ser algo parecido com isso:

CentOS Linux release 8.4.2105

Ainda pode rodar outro comando para confirmar

cat /etc/os-release

A saída tem que ser algo parecido com isso:

NAME="CentOS Linux"

 VERSION="8"

 ID="centos"

 ID_LIKE="rhel fedora"

 VERSION_ID="8"

 PLATFORM_ID="platform:el8"

 PRETTY_NAME="CentOS Linux 8"

 ANSI_COLOR="0;31"

 CPE_NAME="cpe:/o:centos:centos:8"

 HOME_URL="https://centos.org/"

 BUG_REPORT_URL="https://bugs.centos.org/"

 CENTOS_MANTISBT_PROJECT="CentOS-8"

 CENTOS_MANTISBT_PROJECT_VERSION="8"

4) Vamos baixar o script de migração. O migrate2rocky.sh

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh

O curl tem algumas pegadinhas, verifique se baixou o script correto com um editor (vi, nano, less) ou rodando um 'head migrate2rocky.sh'.

5) Dê permissão de execução ao script.

chmod +x migrate2rocky.sh

6) Rode o script para iniciar a migração

./migrate2rocky.sh -r

A partir deste ponto terá início a atualização dos pacotes. Nos testes que fiz ele só reclamou de um problema nos locales. Isso porque o script foi desenvolvido para usar a localização en_US ao invés de setarem no C padrão. E como a máquina usada usa pt_BR isso gerou alguns erros. Se virem essas mensagens, simplesmente ignore.

Na atualização deve aparecer estas mensagens:

Preparing to migrate CentOS Linux 8 to Rocky Linux 8.


Determining repository names for CentOS Linux 8.....


Found the following repositories which map from CentOS Linux 8 to Rocky Linux 8:

CentOS Linux 8  Rocky Linux 8

appstream       appstream

baseos          baseos

extras          extras


Getting system package names for CentOS Linux 8.......


Found the following system packages which map from CentOS Linux 8 to Rocky Linux 8:

CentOS Linux 8        Rocky Linux 8

centos-backgrounds    rocky-backgrounds

centos-gpg-keys       rocky-gpg-keys

centos-logos          rocky-logos

centos-indexhtml      rocky-indexhtml

centos-linux-release  rocky-release

centos-linux-repos    rocky-repos

[...]


Aí vai baixar um monte de pacotes, mudar tudo de CentOS para Rocky Linux até chegar em:

[...] 

 Complete!

 Done, please reboot your system.

 A log of this installation can be found at /var/log/migrate2rocky.log


7) Veja se ainda em alguma atualização.

dnf distro-sync -y 

8) Estando tudo ok, rode o comando 'reboot'.

9) (Opcional) Se quiser mudar o hostname pode rodar o comando:

hostnamectl set-hostname rocky8

Desloga e reloga do sistema ou,  se algum serviço estiver incomodado com a mudança de nome, dê um novo reboot.

E assim teremos um Rocky Linux a partir de um CentOS 8.

Os testes foram feitos em uma máquina virtual no Virtualbox e deixo uma demonstração da migração no vídeo logo abaixo:


Nele mostra praticamente todos os comandos usados para a migração. O tempo pode variar de instalação em instalação do CentOS 8. Tanto que, no vídeo, cortei o processo de baixar e instalar os pacotes senão ele teria a duração de quase 3,5 Pirulas (Quem assiste o canal do Pirula entende a referência). Então ele só tem um pouquinho mais de meio Pirula.


Espero que tenham gostado. Se tiverem algo relacionado ao vídeo, comentem falem. Podem criticar a vontade já que é o primeiro vídeo com a minha voz narrando.  Também aceito sugestões e podem ter certeza que será tudo considerado (quase tudo já que os trolls e haters serão ignorados) para produção de futuros vídeos de melhor qualidade.

Para baixar o Rocky Linux: https://rockylinux.org/

Tenham uma boa semana.

domingo, 18 de abril de 2021

Como redirecionar um site do Google App Engine para https.

 



Estava mexendo em um site que é o Palpite para Mega Sena e já tinha habilitado ele para https já tem algum tempo. Ele roda no Google App Engine com php desde 2013 como um experimento e conseguir uns números aleatórios para fazer uma fezinha.

Mas tinha uma coisa que não conseguia era redirecionar do http para https. Se eu entrava na versão http ele ficava como http e não prosseguia. Então teria que adicionar o s no http para que fosse para um lugar seguro.

Fazendo algumas pesquisas cheguei neste resultado em: https://stackoverflow.com/questions/33878825/how-to-permanently-redirect-http-and-www-urls-to-https  Em algumas plataformas uma edição no app.yaml resolve. Mas, em outras, precisa adicionar o redirecionamento na aplicação.  Como nenhuma das respostas incluía o php, então fiz mais uma pesquisa e encontrei a resposta em https://stackoverflow.com/questions/5106313/redirecting-from-http-to-https-with-php que tinha um código que é assim:

if (empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] === "off") {
    $location = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
    header('HTTP/1.1 301 Moved Permanently');
    header('Location: ' . $location);
    exit;
}

O código verifica se existe a variável HTTPS no servidor ou que está setado como "off". Se for verdade é enviado um comando de redirecionamento para a versão https do site.

A partir daí, acessando via https, o código novo não será executado e o restante do script é executado normalmente.

E como fazer isso?? Pode usar o SDK do Google Cloud ou rodar um Cloud Shell na sua conta do Google Cloud. O processo sempre é o mesmo. No início do código , depois do <?php e antes do código original, adiciona o código acima, salva ele e rode o seguinte comando:

gcloud app deploy --version 1 (ou qualquer outro número de versão)

Espera fazer o deploy e verifica se as mudanças surtiram efeito.

Funcionando, todo acesso http é redirecionado para a versão em https.

Detalhes de como funciona o script da Mega Sena: https://wiki.adilson.net.br/diversos/mega-sena.

Tenham uma boa semana.

sábado, 27 de março de 2021

O bloqueio do Canal de Suez não é a primeira "barbeiragem" do Ever Given.

 

Fonte: https://twitter.com/AirbusSpace/status/1375078054884749318


Nesta semana o mundo, ainda todo enrolado com essa pandemia, enfrenta agora mais um novo problema provocado por um encalhe de um super porta-contêineres que bloqueou uma das mais importantes rotas entre a Ásia e a Europa.

O nome do navio é Ever Given, da empresa Evergreen que, segundo eles, devido a ventos fortes, o navio desviou e acabou se esbarrando em um banco de areia, bloqueando totalmente a passagem do canal.

E não dá para passar.


A situação é tão complicada que a rota alternativa dos navios, tanto na ida quanto na volta, terá que ser uma que foi feita, pela primeira vez, por Vasco da Gama, em 1498, que é contornar o Cabo da Boa Esperança.


Fonte G1 e JN: Para o Brasil não faz muita diferença mas, para a Europa o caminho é mais longo.

E, por ser uma rota mais longa e cara, que fizeram o canal de Suez, ainda no século XIX. Mas este problema de ventos carregando um grande navio não é o primeiro do Ever Given. De acordo com https://www.mopo.de/hamburg/frachter-rammt-faehre-knapp-an-der-katastrophe-vorbei-32016794, em fevereiro de 2019, este mesmo navio, ao sair do porto de Hamburgo, na Alemanha, acabou batendo em um pequeno ferry boat, como mostra este vídeo abaixo:


E impacto foi em cima do barco.


Praticamente acabou com o barco.

Segundo os relatórios apresentados, a causa da colisão com o ferry boat eram ventos fortes que empurrou o Ever Given contra a pequena embarcação.

E, dois anos depois, essa nova ventania no Egito empurra o barco fazendo ele encalhar atravessado no Canal de Suez.


É muita coincidência, mais uma o capitão pode pedir música para o Fantástico. A única diferença entre os dois incidentes e no tamanho do prejuízo. Enquanto em Hamburgo a perda é apenas de um pequeno barco, no Egito o prejuízo já está em torno de alguns bilhões de dólares.


Tenham um bom final de semana.

quinta-feira, 25 de março de 2021

Se o seu Linux está trocando ip toda hora, veja o NetworkManager.

Já tem alguns dias que aconteceu uma coisa curiosa em um dos computadores com Linux. De uma hora para outra o IP do computador, conectado via WiFi, alterava o seu IP e isso acontecia praticamente todos os dias. Uma situação um pouco estranha. No caso do servidor DHCP usado, o ISC DHCP, uma ou outra troca ocasional de IP é normal. Mas trocas feitas todos os dias já causa muito estranhamento. Então existe algo de errado.

Ambas as máquinas são Debian Sid e nós sabemos que problemas no Sid podem ocorrer. Então resolvi investigar isso a fundo. Dentro dos logs encontrei algo:


Mar 21 08:34:41 server dhcpd[59268]: reuse_lease: lease age 3758 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.72

Mar 21 08:34:41 server dhcpd[59268]: DHCPDISCOVER from 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:41 server dhcpd[59268]: ICMP Echo reply while lease 192.168.0.72 valid.

Mar 21 08:34:41 server dhcpd[59268]: Abandoning IP address 192.168.0.72: pinged before offer

Mar 21 08:34:41 server dhcpd[59268]: Wrote 0 deleted host decls to leases file.

Mar 21 08:34:41 server dhcpd[59268]: Wrote 0 new dynamic host decls to leases file.

Mar 21 08:34:41 server dhcpd[59268]: Wrote 21 leases to leases file.

Mar 21 08:34:43 server dhcpd[59268]: DHCPDISCOVER from 5c:ea:1d:17:bf:01 via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPOFFER on 192.168.0.182 to 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPREQUEST for 192.168.0.182 (192.168.0.1) from 5c:ea:1d:17:bf:01 (notebook01) via eth0

Mar 21 08:34:44 server dhcpd[59268]: DHCPACK on 192.168.0.182 to 5c:ea:1d:17:bf:01 (notebook01) via eth0


A mensagem acima difere um pouco de:


Mar 21 12:00:54 server dhcpd[147933]: DHCPREQUEST for 192.168.0.159 from 98:39:8e:68:ab:f4 (Mobile-Phone) via eth0

Mar 21 12:00:54 server dhcpd[147933]: DHCPACK on 192.168.0.159 to 98:39:8e:68:ab:f4 (Mobile-Phone) via eth0


Vou ter que explicar o significado das mensagens do log para descrever o que ocorre.


O esquema do DHCP é mais ou menos esse


  • A máquina que precisa de IP manda, via broadcast, uma mensagem de DHCPDISCOVER, esperando que o servidor DHCP responda (Tem algum servidor DHCP?? Eu quero um IP!).
  • Se for a primeira vez, o servidor envia um comando DHCPOFFER fornecendo um endereço IP (Eu tenho aqui o IP 192.168.5.23 para você.)
  • A partir daí a máquina manda o comando DHCPREQUEST, solicitando este IP. (Eu quero o IP 192.168.5.23!)
  • Então o servidor responde com um DHCPACK, com todas as informações, finalizando a configuração (Então pode usar este IP.)
  • Só que este IP tem um tempo de uso, quando terminar este tempo, a máquina manda um novo DHCPREQUEST (Eu ainda quero usar este IP!).
  • Então o servidor responde de volta com um DHCPACK, renovando o tempo de uso deste IP (Tudo bem, pode continuar usando este IP).


Só que, em vez disso, a máquina manda um novo DHCPDISCOVER (Tem algum servidor DHCP?? Eu quero um IP!).

O servidor verifica e descobre que a máquina já usou um IP antes. Faz uma verificação na rede vê que o IP ainda está ativo. Daí marca como temporariamente abandonado. (Ué? Já tem uma máquina com este IP. Não quero nenhum conflito de IP então vou fornecer um outro.). Mas só que o IP ativo era da máquina que mandou a requisição, não de alguma outra que entrou com IP fixo.


  • Neste ponto o servidor manda um DHCPOFFER com um novo IP. (Olha, este IP está ocupado mas tenho o 192.168.5.84)
  • Daí máquina responde com um DHCPREQUEST (Eu quero o iIP 192.168.5.84!)
  • O servidor responde com um DHCPACK e o IP da máquina é alterado (Então agora você pode usar este IP).


Mas isso não poderia acontecer, já que o IP ocupado já está sendo usado pela máquina original. O normal seria mandar um DHCPREQUEST direto.


Após quebrar a cabeça encontrei uma coisa como descrito em https://wiki.archlinux.org/index.php/NetworkManager_(Portugu%C3%AAs)#Cliente_DHCP (Eu sei que é ArchLinux e a minha máquina é Debian. Mas, apesar das diferenças, a configuração do serviço em uma distribuição pode servir na outra.) Nesta página diz o seguinte:


"Por padrão, o NetworkManager usa seu cliente DHCP interno. O plugin DHCPv4 interno baseado na biblioteca n-dhcp4 do nettools"


Humm será que a configuração do DHCP via NetworkManager bugou??


Então segui esta dica:


Para usar o cliente DHCP da ISC, instale dhclient. Para alterar o backend do cliente DHCP, defina a opção main.dhcp=nome_cliente_dhcp com um arquivo de configuração em /etc/NetworkManager/conf.d/. Por exemplo:


/etc/NetworkManager/conf.d/dhcp-client.conf

[main]

dhcp=dhclient



O dhclient já se encontrava instalado, então eu adicionei esta configuração e reiniciei o NetworkManager e, até agora, não houve novas mudanças de IP.


Verificando os processos notei onde ficava as configurações de concessão nos clientes. (/var/lib/NetworkManager)


ls *.lease -lrt

-rw-r--r-- 1 root root   69 mai  3  2018 dhclient6-02505906-fe76-460f-92e6-19c45eb565e1-wlp1s0.lease

-rw-r--r-- 1 root root   69 mai 13  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root 1350 mai 18  2018 dhclient-0d445d73-9092-4943-a981-0d0c2af8ac75-wlp1s0.lease

-rw-r--r-- 1 root root   69 mai 25  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root 1022 jun  1  2018 dhclient-02505906-fe76-460f-92e6-19c45eb565e1-wlp1s0.lease

-rw-r--r-- 1 root root   69 jun  1  2018 dhclient6-ce0c666e-52d3-4d31-9b7c-0a588f831938-wlp1s0.lease

-rw-r--r-- 1 root root  570 jun  1  2018 dhclient-ce0c666e-52d3-4d31-9b7c-0a588f831938-wlp1s0.lease

-rw-r--r-- 1 root root    0 jun  1  2018 dhclient-923bb507-d222-4c11-be80-239380ece5d7-wlp1s0.lease

-rw-r--r-- 1 root root   69 jun  1  2018 dhclient6-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root   69 jul  8  2018 dhclient6-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root  766 ago  6  2018 dhclient-328b281b-3000-4a45-9998-40261aeced67-wlp1s0.lease

-rw-r--r-- 1 root root  948 ago 27  2018 dhclient-be0f0986-3785-406e-a654-3b18f24ba242-wlp1s0.lease

-rw-r--r-- 1 root root   69 set 11  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root  998 set 11  2018 dhclient-2c13e46d-1878-43c5-97e0-9105467c2350-wlp1s0.lease

-rw-r--r-- 1 root root 1380 set 12  2018 dhclient-c16f749f-5c07-4f7a-b127-3c171df374a3-wlp1s0.lease

-rw-r--r-- 1 root root  536 out  2  2018 dhclient-d3a40ff6-5d10-41f5-9793-1a2a0a8ce95c-wlp1s0.lease

-rw-r--r-- 1 root root   69 out 28  2018 dhclient6-2c6d923f-f466-4c4e-b66e-ad3ec647cef9-wlp1s0.lease

-rw-r--r-- 1 root root 1001 out 28  2018 dhclient-2c6d923f-f466-4c4e-b66e-ad3ec647cef9-wlp1s0.lease

-rw-r--r-- 1 root root  383 out 30  2018 dhclient-83d56bf6-bebb-4d5e-8482-b1ff4a9d00e2-wlp1s0.lease

-rw-r--r-- 1 root root  772 out 30  2018 dhclient-dc902bc5-e968-4b29-8aba-ef16408d62a6-wlp1s0.lease

-rw-r--r-- 1 root root 1064 dez  4  2018 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root   68 dez  4  2018 dhclient6-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root  772 jan 18  2019 dhclient-518b09a6-9cfc-4635-bf56-ae6f63969145-wlp1s0.lease

-rw-r--r-- 1 root root  511 abr  5  2019 dhclient-ef0ed57a-15fc-4178-947c-f55cf55d985c-wlp1s0.lease

-rw-r--r-- 1 root root  772 abr 18  2019 dhclient-77d4d0e6-6804-4120-87f7-6e93da3cec2e-wlp1s0.lease

-rw-r--r-- 1 root root 1162 mai  9  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root  404 mai 17  2019 dhclient-8060d99a-4eb0-4faf-8490-45b76ce159ac-wlp1s0.lease

-rw-r--r-- 1 root root 1160 jul 10  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root 4917 jul 16  2019 dhclient-30eea889-018c-4497-81e6-40954c2cf299-wlp1s0.lease

-rw-r--r-- 1 root root 1140 jul 25  2019 dhclient-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root  916 jul 25  2019 dhclient-0eb7c19a-c154-4967-8028-d402d219ce71-wlp1s0.lease

-rw-r--r-- 1 root root 1308 jul 29  2019 dhclient-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root 1162 jul 29  2019 dhclient-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root 2616 jul 31  2019 dhclient-a5092b04-3274-4d62-906e-49b5f53dce35-wlp1s0.lease

-rw-r--r-- 1 root root  772 jul 31  2019 dhclient-549dd9df-23db-49d8-90eb-6ba0de3b96ec-wlp1s0.lease

-rw-r--r-- 1 root root  321 ago 26  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u3.lease

-rw-r--r-- 1 root root  320 set 13  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u1.lease

-rw-r--r-- 1 root root  321 out 14  2019 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp0s20f0u2.lease

-rw-r--r-- 1 root root  215 out 15  2019 internal-549dd9df-23db-49d8-90eb-6ba0de3b96ec-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  1  2019 internal-57a3995a-0ca6-4610-816e-6dd024085915-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  6  2019 internal-7c67b0fd-5e40-4ac4-ae99-2abc37d034d4-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  6  2019 internal-38e86600-9943-4568-9b74-8c0b3065a24d-wlp1s0.lease

-rw-r--r-- 1 root root  215 nov  7  2019 internal-f3617cf2-0230-43a5-9bd1-5b1c548a8e4d-wlp1s0.lease

-rw-r--r-- 1 root root  215 dez  5  2019 internal-a467e312-98de-4900-8ff2-952eb8bf1238-wlp1s0.lease

-rw-r--r-- 1 root root  215 dez  6  2019 internal-a870b552-943a-45d5-af33-180306cc9b7a-wlp1s0.lease

-rw-r--r-- 1 root root   61 dez 20  2019 internal-3cdafbc1-afa9-4418-8938-dcc8661e2bca-wlp1s0.lease

-rw-r--r-- 1 root root   60 jan  3  2020 internal-34cdab43-7d25-4082-b458-8d9a93203bc2-wlp1s0.lease

-rw-r--r-- 1 root root   58 fev  1  2020 internal-a5092b04-3274-4d62-906e-49b5f53dce35-wlp1s0.lease

-rw-r--r-- 1 root root   59 fev 28  2020 internal-30eea889-018c-4497-81e6-40954c2cf299-wlp1s0.lease

-rw-r--r-- 1 root root   58 jun 10  2020 internal-7018e3cc-b3d2-43bf-91d6-b01272ddf91f-wlp1s0.lease

-rw-r--r-- 1 root root   60 jun 15  2020 internal-3226454e-aa87-45c3-930e-6c7121910d49-bnep0.lease

-rw-r--r-- 1 root root   59 jun 23  2020 internal-b7d7cfb9-64ca-40d5-8085-37680735d0eb-wlp1s0.lease

-rw-r--r-- 1 root root   60 out 23 16:49 internal-cf2d4e9d-9cbe-46fe-a874-8ac046a7b2a4-wlp1s0.lease

-rw-r--r-- 1 root root   59 out 23 17:01 internal-5ae0cffe-f1c7-43f2-9b27-eed3a5ecdcb9-wlp1s0.lease

-rw-r--r-- 1 root root   60 nov 10 15:58 internal-0ca8ecbf-b70b-4e83-a02e-f2d3c847343b-wlp1s0.lease

-rw-r--r-- 1 root root   60 nov 10 16:04 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-enp2s0.lease

-rw-r--r-- 1 root root   61 jan 20 17:49 internal-63f967ee-d4dc-48dc-a363-9bd48f63d53b-usb0.lease

-rw-r--r-- 1 root root   58 mar  6 14:39 internal-f48cbc0e-97ec-495e-b33d-4d279224fb5f-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 13 23:50 internal-d4f5d26a-a21c-4803-b240-acf2b1368b6c-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 20 11:06 internal-0eb7c19a-c154-4967-8028-d402d219ce71-wlp1s0.lease

-rw-r--r-- 1 root root   60 mar 21 17:18 internal-ca818677-2457-4ffd-8f58-e0dde62d99bc-wlp1s0.lease

-rw-r--r-- 1 root root  830 mar 21 17:47 dhclient-ca818677-2457-4ffd-8f58-e0dde62d99bc-wlp1s0.lease


Originalmente o NetworkManager usava o dhclient até, mais ou menos, agosto de 2019, quando uma atualização fez com que ele usasse a biblioteca interna para as requisições de DHCP. Até aí nada demais. Funcionou normal até março de 2021, quando os problemas começaram a ocorrer. Então provavelmente foi quando o bug apareceu. Agora, já ajustando a configuração para usar novamente o dhclient os problemas acabaram.


Eu ainda não vi no https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=network-manager;dist=unstable alguma mensagem relativa a isso. Mas teria que fazer alguns testes e, provavelmente, alguém que usa uma rede maior, vai perceber e abrir um ticket informando sobre a falha. Então, enquanto não corrigem, a mudança para o dhclient pode resolver esta falha.


Tenham um bom dia.


quarta-feira, 9 de dezembro de 2020

O CentOS, como conhecemos, chegará ao fim. Mas nem tudo está perdido.

 

Uma péssima notícia para os usuários de CentOS, que é uma distribuição que é uma cópia quase  exatamente igual ao Red Hat Enterprise (Só tem alguns ícones e arte trocados e outras poucas coisas. Mas o resto é igual). A última versão do CentOS é a 8 que é exatamente igual ao Red Hat 8. Isso até o final de 2021 quando será descontinuada e ficará apenas o CentOS stream. Para entender melhor, vamos ver a história do CentOS.

O CentOS nasceu justamente por uma coisa que o Red Hat Enterprise Linux (Também conhecido como RHEL) tinha de desvantagem: As atualizações vinham por uma sistema de assinatura, no qual pagava para ter suporte. Nem todo mundo tinha condições de pagar então a comunidade pegou o código-fonte (É quase tudo Software Livre, exceto os logos e a marca Red Hat), recompilou tudo, adicionou um novo logo e uma nova marca e, assim nasceu o CentOS.

Neste ponto a Red Hat não podia fazer nada já que é software livre a comunidade podia fazer o que quiser com o código. Isso foi em 2004. A grande vantagem do CentOS é que é um sistema tão estável quanto o RHEL original por ser exatamente um clone.

Dez anos depois, vendo que o CentOS fazia muito sucesso, a Red Hat resolveu patrocinar o sistema. Juntamente com isso os direitos das marca CentOS foi transferido para a Red Hat e o sistema foi considerado uma versão comunitária do RHEL, só com o suporte da comunidade. De qualquer forma ainda continuava como um clone do RHEL.

Só que, em 2018, a IBM compra a Red Hat. Algo que surpreendeu muita gente. É muito dinheiro investido e a comunidade achando que não iam mexer no CentOS. Só que acabaram mexendo recentemente.

Um anúncio, nesta semana, marca o fim prematuro do CentOS 8 para o final de 2021, deixando apenas o CentOS Stream. O CentOS Stream é uma versão rolling release do CentOS no qual as atualizações mais recentes irão direto para ele antes de ir para o RHEL. Para entender melhor vou deixar um gráfico tirado do link https://itsfoss.com/centos-stream-fiasco/

A figura mostra o modelo de desenvolvimento atual do CentOS. Tudo começa no Fedora, que repassa tudo para o Red Hat e, a partir dele , é clonado para o CentOS. Esse é o "Current release cycle".

A partir de 2021 vem o "Next release cycle". Tudo que vem do Fedora vai tanto para o Red Hat quanto para o CentOS. Só que o CentOS não será igual ao Red Hat. E é aí que a comunidade ficou enfurecida já que não terão mais o mesmo servidor estável quanto o RHEL.

Vou perder o servidor estável que criei em CentOS 8

Mas, nós estamos no mundo do software livre. E, como todo software livre, se um projeto não está mais agradando a comunidade, vamos partir para um fork. E é isso que o criador original do CentOS, que não gostou do destino da sua criação, está fazendo agora.

E assim vai nascer o Rocky Linux

De acordo com https://news.itsfoss.com/rocky-linux-announcement/, o Rocky Linux pretende ser o que o CentOS vai deixar de ser: Uma distribuição 100% compatível com o RHEL. Ou seja, mais um clone no qual ficaria de igual para igual com o sistema original.

Por enquanto já tem um repositório vazio no Github. Ainda está tudo no início. Mas espero que logo ninguém mais tenha preocupação para migrar do CentOS para Oracle, Debian, Suse ou qualquer outro sem ter que formatar e refazer tudo de novo.

Mais informações:

Tenham uma boa semana.

sexta-feira, 4 de setembro de 2020

Solução para o VMware com o Kernel 5.8 1 mês depois.

Depois de 1 mês após o lançamento do kernel 5.8 (veja em https://www.adilson.net.br/2020/08/lancado-o-linux-58-mas-nao-atualize-se.html). Finalmente, na manhã desta sexta-feira, surgiu um patch que corrige esta falha em https://github.com/mkubecek/vmware-host-modules/pull/72 . O autor do patch o fez baseado nas correções que foram aplicadas nas versões em desenvolvimento do VirtualBox.

Eu fiz uns testes aqui e tudo funcionou perfeitamente. Não aconteceu nenhum problema do host ter rebootado ou qualquer outro problema relacionado aos módulos. 

Fora isso, o único problema é em um segfault no vmware-modconfig. Mas aí é um problema mais interno entre o vmware e o /proc do sistema operacional. Isso é mais facilmente corrigido. Enquanto não surge uma nova atualização, isso pode ser corrigido com estes dois passos.

  •  Edita o /usr/bin/vmware e, no final do arquivo, deixe comentado estas linhas:

#if "$BINDIR"/vmware-modconfig --appname="VMware Workstation" --icon="vmware-workstation" &&
#   vmware_module_exists $vmmon; then
  exec "$libdir"/bin/"vmware" "$@"
#fi

Só não comenta a linha do exec, que é o que roda o vmware. Já a parte dos módulos, pode usar o script usado em https://www.adilson.net.br/2017/08/resolvendo-o-problema-compilacao-de.html para compilar os módulos de forma manual toda vez em que for compilar ou instalar um kernel novo a partir da versão 5.8.

De qualquer forma, isso resolve o problema do VMware com o kernel 5.8. Já com o VirtualBox, ainda precisamos esperar a liberação da próxima versão estável. Mas, se estiver com pressa, pode tentar a versão em desenvolvimento. Pena que não tem para Debian/Ubuntu, senão isso seria de grande ajuda. [Atualização para sextar de vez no final de tarde] Já foi liberado a versão mais nova do VirtualBox que também dá suporte ao kernel 5.8. Agora sim isso resolve o problema de virtualização no kernel mais recente.

Apesar de ter agradecido lá no tópico do Github, tenho que agradecer o autor do patch, mais uma vez, pela solução:


Quando tiver mais novidades, com o VirtualBox, eu informo aqui.

Tenham um ótimo final de semana e um bom feriado na segunda.


segunda-feira, 3 de agosto de 2020

Lançado o Linux 5.8 - Mas não atualize se for rodar máquina virtual.

A algumas horas atrás foi lançado o kernel 5.8 conforme monitorado neste Tweet.


Uma lista completa das novidades pode ser conferida em https://kernelnewbies.org/Linux_5.8

Porém, esta atualização vem com alguns efeitos colaterais. Primeiro com os drivers da NVIDIA. Mas isso é facilmente resolvido instalando o último driver disponível que é o 450.57. Veja se a sua distribuição já atualizou ou procure em https://www.nvidia.com.

Agora a dor de cabeça fica por conta da área de virtualização.


Acessando o blog http://rglinuxtech.com/, foi encontrado um relato que diz que o drive do VMware apresenta alguns problemas e, mesmo com alguns patches, qualquer tentativa de iniciar uma máquina virtual pode reiniciar a máquina host sem aviso, conforme o log indicado no mesmo blog mencionado.


$ uname -a
Linux rgz220 5.8.0 #2 SMP Sun Aug 2 16:34:15 PDT 2020 x86_64 x86_64 x86_64 GNU/Linux

[root@rgz220 rgadsdon]# vmware-modconfig –console –install-all
[AppLoader] GLib does not have GSettings support.
Segmentation fault (core dumped)

[root@rgz220 vmware-host-modules-workstation-15.5.6]# make
make -C vmmon-only
make[1]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
Using kernel build system.
make -C /lib/modules/5.8.0/build/include/.. M=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[2]: Entering directory ‘/usr/src/linux-5.8’
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/driver.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/hostif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/linux/driverLog.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/memtrack.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/apic.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/statVarsVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/vmx86.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/sharedAreaVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/cpuid.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/task.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/comport.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/common/phystrack.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmcore/moduleloop.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/monLoaderVmmon.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/monLoader.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/vmmblob.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/bootstrap/bootstrap.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.o
MODPOST /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/Module.symvers
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.mod.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only/vmmon.ko
make[2]: Leaving directory ‘/usr/src/linux-5.8’
make -C $PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= postbuild
make[2]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
make[2]: ‘postbuild’ is up to date.
make[2]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
cp -f vmmon.ko ./../vmmon.o
make[1]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmmon-only’
make -C vmnet-only
make[1]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
Using kernel build system.
make -C /lib/modules/5.8.0/build/include/.. M=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[2]: Entering directory ‘/usr/src/linux-5.8’
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/driver.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/hub.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/userif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/netif.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/bridge.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/procfs.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/smac_compat.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/smac.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vnetEvent.o
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vnetUserListener.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.o
MODPOST /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/Module.symvers
CC [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.mod.o
LD [M] /home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only/vmnet.ko
make[2]: Leaving directory ‘/usr/src/linux-5.8’
make -C $PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= postbuild
make[2]: Entering directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
make[2]: ‘postbuild’ is up to date.
make[2]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
cp -f vmnet.ko ./../vmnet.o
make[1]: Leaving directory ‘/home/rgadsdon/kernel/vmware-host-modules-workstation-15.5.6/vmnet-only’
[root@rgz220 vmware-host-modules-workstation-15.5.6]# make install
install -D -t /lib/modules/5.8.0/misc vmmon-only/vmmon.ko vmnet-only/vmnet.ko
strip –strip-debug /lib/modules/5.8.0/misc/vmmon.ko /lib/modules/5.8.0/misc/vmnet.ko
if test -z “”; then /sbin/depmod -a 5.8.0; fi
[root@rgz220 vmware-host-modules-workstation-15.5.6]# service vmware start
Starting vmware (via systemctl): [ OK ]

[rgadsdon@rgz220 ~]$ vmware
/usr/bin/vmware: line 105: 12956 Segmentation fault (core dumped) “$BINDIR”/vmware-modconfig –appname=”VMware Workstation” –icon=”vmware-workstation”

[rgadsdon@rgz220 ~]$ /usr/lib/vmware/bin/vmware

VMware Workstation Warning:
An old version of smart card service (pcscd) is running on this system. Upgrade to the latest version to use virtual smart cards.

PowerOn
VProbes facility is disabled.
VProbes facility is disabled.
SOUNDLIB: Connection failure: Connection refused
SOUNDLIB: SoundLib_CreatePulseBackend: failed to connect to PA context (Connection refused)
FILE: FileLockMemberValues file ‘/home/rgadsdon/vmware/Windows_XP_Pro-SP3-2/Windows_XP_Pro-000001-cl3.vmdk.lck/M37025.lck’: size 0, required size 512
FILE: FileLockMemberValues removing problematic lock file ‘/home/rgadsdon/vmware/Windows_XP_Pro-SP3-2/Windows_XP_Pro-000001-cl3.vmdk.lck/M37025.lck’
Could not initialize emulated USB smart card subsystem.
VIDE: Using LBA48 for ide0:0
<< Immediate system reboot – connection lost >>
client_loop: send disconnect: Broken pipe


Ainda não existe uma solução, conforme indicado em https://communities.vmware.com/thread/638457, ainda vou monitorar para ver se tem alguma novidade.

Ah, mas vou usar o VirtualBox enquanto isso.


Seria bom se isso fosse simples. Mas, parece que o bug também afeta o VirtualBox: https://www.virtualbox.org/ticket/19644


E agora??? Como rodar as máquinas virtuais??

Por hora, a solução é permanecer na versão 5.7 até que uma correção saia. Qualquer novidade publicarei aqui.

Tenham uma boa semana.


quarta-feira, 17 de junho de 2020

Como fazer o Google Chrome voltar a exibir a URL completa

Já tem algum tempo que o Google Chrome esconde detalhes dos endereços dos sites como os famosos http:// e https:// e também escondem a parte www e m dos endereços. Para alguns isso não é muito problema. Mas, para alguns outros (E isso também me inclui),  acham muito chato esta parte já que não mostra muita coisa e pode ser também uma porta para phishing. Mas parece que apareceu uma forma de retornar a antiga forma sem precisar de pular para o Firefox.

Pegamos um exemplo a própria página do blog no Google Chrome 83. E isso vale em qualquer sistema operacional.

Sem https:// e sem www :/
Em uma aba acesse o endereço about:flags

Note que o endereço é chrome://flags mas ambos os endereços são válidos

Note que você precisa apenas escrever context menu e procura por "Context menu show full URLs". Ao encontrar esta opção, mude a opção para "Enabled" e, em seguida, vai em "Relaunch".

Após reiniciar, feche a aba já que tem várias opções que podem bagunçar o navegador. Volte a URL e clica com o botão direito na barra de endereços.

Agora aparece a opção.

Clica em "Sempre mostrar URLs completos" e aí o endereço completo surge na barra de endereços.
Agora sim o endereço aparece completo

Como a opção do chrome://flags é totalmente experimental, ela pode sumir nas futuras versões ou possa permanecer e até ficar dentro das configurações do Google Chrome. Tomara que fique na segunda opção para não deixar chateados quem prefere ver o endereço completo no navegador.


E espero voltar mais vezes, em breve mais postagens. E tomara que não seja em 2021 ou além.

Tenham uma boa semana.