/etc/apt/trusted.gpg mostrando warning no apt. Como resolver essa mensagem.

 A última versão do apt começa a mostrar uma pequena mensagem. Mais ou menos semelhantes a essa:

W: https://repo.skype.com/deb/dists/stable/InRelease: Key is stored in legacy tr
usted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key
(8) for details.

Isso por conta de uma mudança no próprio aplicativo do apt, que interfere nas chaves gpg utilizadas.

apt (2.4.0) unstable; urgency=medium

 GPG verification now first tries only the trusted.gpg.d keys, before
 then falling back to the legacy trusted.gpg keyring and issuing a
 warning to migrate keys if verification succeeded in the fallback.

-- Julian Andres Klode <jak@debian.org>  Tue, 22 Feb 2022 20:01:00 +0100

"A verificação GPG agora, primeiramente, apenas as chaves dentro do trusted.gpg.d, antes de voltar para o chaveiro legado trusted.gpg e emitindo um alerta para migrar as chaves se a verificação for bem sucedida no fallback."

Isso só acontece na versão 2.4.0 que já entrou no Debian Sid e pode aparecer no Ubuntu e derivados em breve.

Mas como silenciar essas mensagens??

A solução é bem mais simples.

Entra no /etc/apt/trusted.gpg.d e rode o comando

ln -s /etc/apt/trusted.gpg

Assim é criado um link simbólico e o apt nem solta a mensagem. É uma solução prática, rápida e não trará nenhuma dor de cabeça mais para frente.

Tenham uma boa semana.

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.

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 Microsoft, CPI 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.

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.

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.

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:

https://en.wikipedia.org/wiki/CentOS

https://itsfoss.com/centos-stream-fiasco/

https://news.itsfoss.com/rocky-linux-announcement/

https://news.terminalroot.com.br/centos-acabou.html

Tenham uma boa semana.

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.

Mais detalhes em:  https://olhardigital.com.br/dicas_e_tutoriais/noticia/como-fazer-o-chrome-mostrar-os-enderecos-completos-dos-sites/102197

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

Tenham uma boa semana.

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.

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.

Método simples de criar um repositório Debian/Ubuntu sem precisar de servidor web

Hoje esta dica surgiu num momento muito delicado. Eu aqui uso o Debian Sid onde, praticamente todo mundo sabe, as coisas podem quebrar de uma hora para outra. Então, numa das atualizações do systemd e kernel, eu reiniciei a minha máquina e me deparei com este erro:

O boot parou com um ABRT. :o

Tentei voltar para versão anterior do kernel e o erro persistia. Então imaginei que o erro seria no systemd. Depois de dar um boot com o live cd e refazer a conexão, fiz uma pesquisa e encontrei a causa neste bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892360. No momento em que estiver lendo a falha já foi corrigida mas, na hora precisava fazer alguns testes e tinha um patch que corrigia isso.

Agora era partir para um ambiente chrooted, pelo live cd, para que eu possa compilar os pacotes modificados. Após preparar os pacotes, sabia que não eram todos que precisavam ser instalados.

Como fazer isso já que não tinha condições de instalar um apache e preparar um ambiente seguro de um repositório temporário. Bom, existe uma maneira.

copie os pacotes gerados para uma pasta. Digamos que seria /usr/local/debs, por exemplo.

Feito isso entre na pasta e rode o seguinte comando:

 dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz

 Feito isso edite o /etc/apt/sources.list e adicione o seguinte:

deb [trusted=yes] file:/usr/local/debs/ ./

O '[trusted=yes]' é para evitar que o apt reclame de autenticação e da existência de pacotes não assinados.

Daí é apt-get update e apt-get upgrade (ou install pacote) para que os pacotes seja atualizados sem nenhum problema.

Depois foi reiniciar a máquina e o acesso normalizou.

Claro que isso não substitui o repositório oficial. Mas é um bom quebra-galho quando precisa recompilar os pacotes e só precisa atualizar o necessário.

Depois do uso não esqueça de comentar o repositório já que, por enquanto, não será mais necessário.

Tenham um bom final de semana.

Migrando de iptables para nftables

O assunto de hoje é sobre firewall

Hoje vou falar sobre o nftables. Um sistema de firewall para Linux que pretende substituir o atual iptables, ip6tables e qualquer outro tables que trabalha com as regras de permissão de acesso e encaminhamento de pacotes. Por ser tudo reunido em um único aplicativo ele tem a vantagem de evitar a duplicação de códigos e qualquer outro problemas em que ocorre em um dos apps em separado.

O pior é que vivi esta parte da pior maneira quando compilei o kernel 4.14 da primeira vez. Na verdade demorou alguns dias já que não notei falhas de rede até que tentei acessar algo, da rede interna, exclusivamente em ipv6. A conexão não ia de maneira alguma, mesmo com todas as regras do ip6tables corretas. Voltando para o kernel 4.13 a conexão ipv6 normalizou.

A regra que deu problema foi essa:

ip6tables -t nat -A POSTROUTING -s fd08:7d11:7db1:1ecb::/64 -j MASQUERADE

Ou seja. Tirando a máquina principal, que é roteadora e o ipv6 funciona de qualquer maneira. Qualquer dispositivo, na rede interna, tem conexão ipv6 normal no kernel 4.13. Mas falha quando utiliza o kernel 4.14. O ipv4 roda normal em todas as situações.

Não entendi nada. Funciona em um e não em outro.

Então foram feitos vários testes com o kernel 4.14 tanto em Debian, quanto em Ubuntu e no CentOS. O resultado foi o mesmo e o ip6tables não encaminhava nenhum pacote para fora.

Então resolvi fazer um teste com um nftables com o kernel 4.14 e ver como se comportava. Fui ver como adiciona uma regra parecida com aquela acima e cheguei no seguinte:

table ip6 nat {
 chain prerouting {
   type nat hook prerouting priority 0;
 }
 chain postrouting {
   type nat hook postrouting priority 0;
   oifname "ens33" masquerade
 }
}
Coloquei a regra em um arquivo do tipo teste.firewall e rodei o seguinte comando.

nft -f teste.firewall

Esse comando carrega as regras contidas nos arquivos. Fui fazer um teste e... funcionou.

Até que enfim deu certo. Então o erro é em algo no ip6tables que ainda não foi identificado. Mas já que a tendência é do iptables se juntar ao antigo ipchans como 'deprecated' nos próximos anos. Então vamos pegar as regras atuais e repassar para o nftables.


Mas como migrar tudo que é feito em iptables/ip6tables para nftables???

Por sorte os desenvolvedores criaram duas maneiras de migrar as regras de um para outro. Um deles é pelo uso do iptables-nftables-compat, aonde não muda as regras atuais e deixa o nftables fazer as coisas, nos bastidores. Mas o melhor é aprender os novos comandos. Por isso foi utilizado ip(6)tables-translate, que pega as antigas regras do iptables e mostra qual o comando equivalente para o nftables.

Depois de rodar o comando em quase todas as regras (depois explico o porquê). Chegou a hora de mudar as regras locais.

A regra do nat é mais fácil já que precisa repetir apenas o a regra, no mesmo arquivo só que muda o ip6 para ip, para uso do ipv4 e colocar para carregar quando rodar o nft -f teste.firewall

As demais regras tem umas pegadinhas:

Antes de rodar qualquer comando é necessário adicionar, no inicio de cada arquivo de firewall, os seguintes comandos:

nft add table ip filter                                                            
nft add chain ip filter INPUT { type filter hook input priority 0\; policy accept\; }                                                                   
nft add chain ip filter FORWARD { type filter hook forward priority 0\; policy accept\; }                                                               
nft add chain ip filter OUTPUT { type filter hook output priority 0\; policy accept\; }

nft add table ip6 filter                                                       
nft add chain ip6 filter INPUT { type filter hook input priority 0\; policy accept\; }                                                                   
nft add chain ip6 filter FORWARD { type filter hook forward priority 0\; policy accept\; }                                                               
nft add chain ip6 filter OUTPUT { type filter hook output priority 0\; policy accept\; }

Detalhe para o \ antes do ; para evitar problemas na hora de executar via shell script.

Esses comandos criam as tables e chains necessárias para o uso das regras. Sem isso qualquer comando pode acarretar em erro.

Depois de criado, pode conferir através do comando 'nft list tables'

yoda:~# nft list tables
table ip6 filter
table ip6 nat
table ip filter
table ip nat

Agora é adcionar as regras. 

Se, antes, foi utilizado a regra:

iptables -A INPUT -i ppp0 -p tcp --destination-port 700 -j REJECT

ele agora pode ser executado dessa maneira:

nft add rule ip filter INPUT iifname ppp0 tcp dport 700 counter reject

O mesmo vale para o ipv6 já que só precisa alterar uma coisa no comando:

nft add rule ip6 filter INPUT iifname ppp0 tcp dport 700 counter reject

O resto pode ser feito em todos os comandos...   Não exatamente...

Apenas um comando no iptables e um comando em ip6tables não dá para ser migrado, por enquanto.

Esse comando é o:

iptables -t mangle -o ppp0 --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN
-m tcpmss --mss 1400:1536 -j TCPMSS --clamp-mss-to-pmtu

E o seu equivalente no ip6tables.

Justamente o comando que regula o tamanho do mtu para evitar problemas no envio de alguns pacotes um pouco grandes em conexões ppp. Até hoje ele ainda está no TODO do projeto.

nftables frontend

-----------------

- Define lexical distinction between keywords, symbolic constants and

  identifiers

- Define syntax for changing data (connmark, meta etc.)

- payload syntax for matching on IP headers of IPIP/GRE tunnels etc.

- netlink monitor for CLI

Kernel

------

- netlink set API

- kernel set implementation selection

- TC hookup - use dummy classifier or hook "natively" ?

- kill mangle table, make rerouting a configurable table/chain property

- kill nat table? harder because of more special handling

- multi-family tables

- IPv6 ext header matching

- IP style options (IP/TCP/DCCP) matching

- IPsec policy matching

- hashlimit

- quota

- recent(?)

- TCPMSS target - generic packet editor?

- include NLM_F_ ... flags in notifications?

A solução, neste caso, é manter os antigos comandos, sendo os dois últimos remanescentes do antigo ip(6)tables até que os desenvolvedores criem um comando equivalente.

Com isso a rede interna volta a usar tanto o ipv4, quanto o ipv6. Mas, caso precisem saber como anda as regras, pode usar os seguintes comandos:

nft list tables - Exibe os nomes das tabelas criadas

nft list table ip6 nat - Exibe os códigos utilizados na tabela nat do ipv6. Para ipv4 troque ip6 por ip.

nft list ruleset - Exibe o código completo utilizado no nftables tanto no ipv4 quanto no ipv6.

Mais detalhes:

https://en.wikipedia.org/wiki/Nftables

https://wiki.archlinux.org/index.php/Nftables

https://wiki.nftables.org/wiki-nftables/index.php/Main_Page

https://www.vivaolinux.com.br/dica/NFtables-O-Sucessor-do-IPtables-ja-no-kernel-313

Tenham uma boa semana.

Vergonha nacional: Whatsapp bloqueado - Saiba como acessar mesmo assim

Atualização: O bloqueio não durou 12 horas. Um desembargador teve  bom senso e suspendeu a ordem da juiza.

Desde a meia-noite de hoje, por uma decisão da juiza Sandra Regina Nostre Marques, por motivos não muito claros, as operadoras aplicam um filtro, no melhor estilo firewall chinês, e bloqueia o Whatsapp em todo território nacional. Realmente já é uma vergonha e, até mesmo, o atual dono do Whatsapp já se pronunciou agora a pouco.

Mas existem várias maneiras de passar por cima dessa medida, muitas delas envolvem o uso de VPN, como informa aqui, aqui, aqui e muitos outros que apareceram na última madrugada.

Mas nem toda vpn é segura, alguns aplicativos de vpn podem esconder alguns segredos para interceptar os dados. Eu aqui consegui diblar com o Orbot, que é um proxy que utiliza a Rede Tor, a mesma rede da tão comentada Deep Web. É uma opção que acho que é segura já que é feita pelos mesmos desenvolvedores do Tor, que é usada por ativistas em países onde há uma forte censura, pelo Anonymous, integrantes do Estado Islâmico, e diversos outros grupos que estão ou no lado da luz ou do lado negro da força.

Mas como não estamos na China, Irã, ou outro país autoritário que nos metralharia por fazer estes dibles, vou explicar como utilizar esta opção.

OBS: A configuração pode ser um pouco chata ou não funcionar como deveria mas, estabelecendo a conexão já consegue o Whatsapp sem problemas.

OBS2: Não tenho iPhone e Lumia para testar em iOS e Windows Phone, então utilizem os links acima para ver como diblar.

1) Baixe o Orbot no link indicado https://play.google.com/store/apps/details?id=org.torproject.android&hl=pt_BR

2) Após instalado, clica nas configurações (Um botão no canto superior direito) e vá em Selecionar Apps.

3) Daí vai aparecer uma lista enorme de aplicativos que pode escolher qualquer um deles. Para este exemplo vamos escolher o Whatsapp.

4) Após isso, marque o botão APPS para que o Orbot pegue o aplicativo e repasse a conexão dele pelo Tor

5) Clica no botão do Android com a cabeça de cebola, deixando pressionado, para que faça a conexão

6) Ao conectar, testa o Whatsapp e veja se consegue mandar mensagens. Mesmo que seja apenas um tique na mensagem.

Comigo o aplicativo caiu algumas vezes mas, depois de insistir, consegui enviar algumas mensagens:

A mensagem que deixei em um grupo para quem diblar ou retornar no sabado ou antes.

Pelo menos garanti um tique, o que indica que a mensagem chegou no servidor do Whatsapp.

Quem conseguir, me informa nos comentários como acessou e vamos ajudar a passar por cima do dessa ordem judicial ridícula.

Tenham uma boa quinta.