Sequoia quebra os repositórios apt. Como corrigir isso.

For the English version go to: https://www.adilson.net.br/2024/12/sequoia-breaks-apt-repos-how-to-fix-it.html

Depois de muito tempo sem atualizar o blog, vou escrever sobre algo bem recente que aconteceu em alguns dos meus sistemas aqui.

Para quem não sabe, normalmente uso Debian Sid nos desktops e notebooks com várias personalizações e repositórios de terceiros.

E, na semana do Natal, alguns desenvolvedores entregaram um presente para o próprio APT, de acordo com o último changelog.

apt (2.9.19) unstable; urgency=medium

  * Replace GnuTLS and gcrypt with OpenSSL

  * Replace GnuPG with Sequoia on supported Debian platforms

    - methods: Add new sqv method

    - debian: Add default policy to allow SHA-1 self-signatures until 2026

    - debian: Plug sqv into the package build

  * Smaller bits:

    - apt-helper: Add a hash-file helper to debug file hashing

    - Use sq in the test suite, remove apt-key

    - abicheck: Add symbol-merge.py helper

    - Symbols: Merge stable, noble, testing, unstable

 -- Julian Andres Klode <jak@debian.org>  Mon, 23 Dec 2024 12:16:19 +0100

 

 Eles trocaram o GnuPG pelo Sequoia, que é uma implementação alterantiva para o PGP. Só que essa implementação tem umas configurações que, por padrão, bloqueiam o hash inseguro sha-1 para verificar as assinaturas de critografia. 

 Os desenvolvedores até colocaram uma alteração na politica do Sequoia que permite o uso do sha-1 até 2026, para dar tempo dos repositórios se adequarem. 

 Mas sabem como é o Debian Sid.

 

Tem coisas que o Sid quebra

 

 E quebrou com alguns repositórios. Alguns desses erros foram: 

 Err:39 https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease

  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on DB085A08CA13B8ACB917E0F6D938EC0D038651BD is not bound:            primary key   because: No binding signature at time 2024-12-17T17:27:20Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance   because: SHA1 is not considered secure since 2013-02-01T00:00:00Z  

  W: Falhou ao buscar https://pkgs.k8s.io/core:/stable:/v1.31/deb/InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message is: Error: Policy rejected packet type  Caused by:     Signature Packet v3 is not considered secure since 2021-02-01T00:00:00Z

    

  Até tentei verificar algo relacionado na explicação abaixo:

  

  apt (2.9.19) unstable; urgency=medium

  This release switches to OpenSSL for hashing and TLS, replacing the

  GnuTLS and gcrypt libraries.

  This release switches to Sequoia for OpenPGP verification on supported

  Debian platforms. A Sequoia policy override enabling SHA1 self-signatures

  until 2026 is included. To override the policy, the following environment

  variables and files are considered:

  * The APT_SEQUOIA_CRYPTO_POLICY environment variable, and failing that:

    - /etc/crypto-policies/back-ends/apt-sequoia.config,

    - /var/lib/crypto-config/profiles/current/apt-sequoia.config

  * The SEQUOIA_CRYPTO_POLICY environment variable, and failing that:

    - /etc/crypto-policies/back-ends/sequoia.config

    - /var/lib/crypto-config/profiles/current/sequoia.config

 -- Julian Andres Klode <jak@debian.org>  Mon, 23 Dec 2024 12:16:22 +0100

 Só que as configurações não deram certo. A documentação do Sequoia https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/index.html não indicava um local correto para configuração e nem mesmo o ChatGPT conseguia uma configuração correta.

  Se nem a IA sabia como configurar corretamente:

 

 

 

 imagina um humano que só esbarrou no erro. 

 

 Depois de pesquisar muito. Descobri onde foi configurado as politicas do Sequoia no apt:

 

/usr/share/apt/default-sequoia.config

Como não explicam direito outros lugares alternativos 😵‍💫, vai neste mesmo:

Atualização: 9 de janeiro 2025: Um leitor anonimo comentou sobre /etc/crypto-policies/back-ends/apt-sequoia.config. Esta pasta não existe no meu sistema. Então tive que fazer um

mkdir -p /etc/crypto-policies/back-ends/ 

e criar o arquivo apt-sequoia.config para adicionar a configuração abaixo:

Dentro encontra a seguinte configuração:

[hash_algorithms]

sha1.second_preimage_resistance = 2026-01-01

Tenta alterar para 

[hash_algorithms]

#sha1.second_preimage_resistance = 2026-01-01

sha1= 2030-01-01

[packets]

signature.v3 = 2030-01-01

Comentei a primeira linha e adicionei o sha1 com a data para 01/01/2030.

Daí adicionei o campo packets com configuração de signature.v3, que também foi afetada, para 01/01/2030.

Após salvar o arquivo o erro desapareceu.

Esta é apenas uma solução temporária enquanto os desenvolvedores façam as correções no apt ou, quem mantem os repositórios, façam as atualizações nas assinaturas para padrões mais recentes que o Sequoia suporta sem problemas.

Tem que estar em mente que o SHA-1 já não é mais seguro e uma atualização do apt pode sobrescrever o /usr/share/apt/default-sequoia.config. Se o erro voltar, terá que aplicar as alterações novamente no arquivo.

Caso encontrem uma alternativa melhor, me informe nos comentários que será testado.

Agora você pode tentar a solução acima:

Um Feliz Ano Novo para todos.

Sequoia breaks apt repos. How to fix it.

Para versão em português vai em: https://www.adilson.net.br/2024/12/sequoia-quebra-os-repositorios-apt-como.html

After a long time without updating this blog, I will write about a issue that happened with some systems here.

If you have not noticed. I use Debian Sid in my desktops and notebooks with lots of customizations and third party repositories.

And, on this Christimas week, some devs give a present for the apt, as shown in this last changelog:

apt (2.9.19) unstable; urgency=medium

  * Replace GnuTLS and gcrypt with OpenSSL

  * Replace GnuPG with Sequoia on supported Debian platforms

    - methods: Add new sqv method

    - debian: Add default policy to allow SHA-1 self-signatures until 2026

    - debian: Plug sqv into the package build

  * Smaller bits:

    - apt-helper: Add a hash-file helper to debug file hashing

    - Use sq in the test suite, remove apt-key

    - abicheck: Add symbol-merge.py helper

    - Symbols: Merge stable, noble, testing, unstable

 -- Julian Andres Klode <jak@debian.org>  Mon, 23 Dec 2024 12:16:19 +0100

They switched from GnuPG to Sequoia, that is an alternative PGP implementation. But this implementations has some configurations that default blocks the insecure sha-1 hash for checking crypto signiatures.

The devs also put a change on the Sequoia policy that allows sha-1 until 2026.

But you know how Debian sid is like:

There are some things that Sid breaks.

And it breaks some repos. Some errors were:

Err:39 https://packagecloud.io/slacktechnologies/slack/debian jessie InRelease

  Sub-process /usr/bin/sqv returned an error code (1), error message is: Signing key on DB085A08CA13B8ACB917E0F6D938EC0D038651BD is not bound:            primary key   because: No binding signature at time 2024-12-17T17:27:20Z   because: Policy rejected non-revocation signature (PositiveCertification) requiring collision resistance   because: SHA1 is not considered secure since 2013-02-01T00:00:00Z  

  W: Falhou ao buscar https://pkgs.k8s.io/core:/stable:/v1.31/deb/InRelease  Sub-process /usr/bin/sqv returned an error code (1), error message is: Error: Policy rejected packet type  Caused by:     Signature Packet v3 is not considered secure since 2021-02-01T00:00:00Z

Even I tried to check something related below:

  apt (2.9.19) unstable; urgency=medium

  This release switches to OpenSSL for hashing and TLS, replacing the

  GnuTLS and gcrypt libraries.

  This release switches to Sequoia for OpenPGP verification on supported

  Debian platforms. A Sequoia policy override enabling SHA1 self-signatures

  until 2026 is included. To override the policy, the following environment

  variables and files are considered:

  * The APT_SEQUOIA_CRYPTO_POLICY environment variable, and failing that:

    - /etc/crypto-policies/back-ends/apt-sequoia.config,

    - /var/lib/crypto-config/profiles/current/apt-sequoia.config

  * The SEQUOIA_CRYPTO_POLICY environment variable, and failing that:

    - /etc/crypto-policies/back-ends/sequoia.config

    - /var/lib/crypto-config/profiles/current/sequoia.config

 -- Julian Andres Klode <jak@debian.org>  Mon, 23 Dec 2024 12:16:22 +0100

But these configurations didn't worked. The Sequoia documentation https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/index.html does't show a right place for this configuation and, even, ChatGPT hasn't got a right answer for this issue.

If, even, an IA knows how to configure it correctly:

Imagine a human that saw this error for the first time:

After a lot of research. I discovered where they configure apt Sequoia policies:

/usr/share/apt/default-sequoia.config

Since they didn't explain any alternative locations 😵‍💫, I will edit this file.

Update Jan 9th 2025: An anonymous reader commented about  /etc/crypto-policies/back-ends/apt-sequoia.config . This folder does not exists on my system so I have to do a

mkdir -p /etc/crypto-policies/back-ends/ 

and create apt-sequoia.config for adding the configuration below.

Inside you will find this configuration:

[hash_algorithms]

sha1.second_preimage_resistance = 2026-01-01

Try to change them to:

[hash_algorithms]

#sha1.second_preimage_resistance = 2026-01-01

sha1= 2030-01-01

[packets]

signature.v3 = 2030-01-01

I commented the first line and add sha1 with a date to 01/01/2030.

Then I put a [packet] section with signature.v3, that is also affected, with a date to 01/01/2030.

After saving this file the error vanished.

This is a temporary solution until the devs make some fixes to apt or the repositories signatures are updated to the most recent standards that are supported by Sequoia.

And, keep in mind, that SHA-1 is not safe anymore and any apt update will overwrite /usr/share/apt/default-sequoia.config. If theses errors  return, you have to repeat all changes again.

So you can use the new solution above.

If you find a better alternative, show me in the comments below that they will be tested.

Happy New Year for all.

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.

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.

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.

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.

Mudando o horário de verão nos computadores versão 'old school' em 2018

Governo vai, governo vem e sempre uma coisa que não muda desde de 2008 é o horário de verão.

Isso se tornou um alívio para muitos profissionais de TI que utilizavam algumas ferramentas ou gambiarras para evitar que os servidores mostrassem o horário errado.

Mas, neste ano, as coisas mudaram um pouco.

1º tivemos as eleições e, com alguns meses de antecedência, mudaram o horário de verão para o dia 04 de novembro. Porém, quase no início do mês, notaram que o horário de verão começaria na mesma data do Enem. Daí existia o risco disso:

O maior evento de toda fase pré-universitária: Os Atrasados do ENEM 2018

Em vez de mover a data da prova, moveram o horário de verão para o dia 18. Já tem empresa aérea reclamando, os profissionais de TI já estão arrancando os cabelos. E ainda não tem data para atualizar o timezone como mostrado aqui nesta thread.

Atualização de última hora: E o Temer resolveu voltar atrás e volta tudo como era antes.

Então a solução, se isso continuasse, é voltar a usar os antigos métodos. Consegui relembrar através deste link: https://wiki.hackstore.com.br/Corrigindo_manualmente_o_hor%C3%A1rio_de_ver%C3%A3o_brasileiro_no_Linux

Fiz uma pequena adaptação, que funcionou na Debian. Mas pode funcionar no Ubuntu e outras distribuições.

Antes roda o comando  "zdump -v /etc/localtime | egrep '2018|2019'" e confere se o inicio está para 18 de novembro ou antes. Se for antes, então segue as instruções abaixo:

Primeiro, copia e cola o texto a seguir e salva com o nome timezone.zic

Rule Brazil 2017 only - Feb 19 00:00 0 3
Rule Brazil 2017 only - Oct 15 00:00 1 2
Rule Brazil 2018 only - Feb 18 00:00 0 3
Rule Brazil 2018 only - Nov 18 00:00 1 2
Rule Brazil 2019 only - Feb 17 00:00 0 3
Rule Brazil 2019 only - Oct 20 00:00 1 2
Rule Brazil 2020 only - Feb 16 00:00 0 3
Rule Brazil 2020 only - Oct 18 00:00 0 3
Rule Brazil 2021 only - Feb 21 00:00 0 3
Rule Brazil 2021 only - Oct 17 00:00 1 2
Rule Brazil 2022 only - Feb 20 00:00 0 3
Rule Brazil 2022 only - Oct 16 00:00 1 2
Rule Brazil 2023 only - Feb 26 00:00 0 3
Rule Brazil 2023 only - Oct 15 00:00 1 2
Rule Brazil 2024 only - Feb 18 00:00 0 3
Rule Brazil 2024 only - Oct 20 00:00 1 2
Rule Brazil 2025 only - Feb 16 00:00 0 3
Rule Brazil 2025 only - Oct 19 00:00 1 2
Rule Brazil 2026 only - Feb 22 00:00 0 3
Rule Brazil 2026 only - Oct 18 00:00 1 2
Rule Brazil 2027 only - Feb 21 00:00 0 3
Rule Brazil 2027 only - Oct 17 00:00 1 2
Rule Brazil 2028 only - Feb 20 00:00 0 3
Rule Brazil 2028 only - Oct 15 00:00 1 2
Rule Brazil 2029 only - Feb 18 00:00 0 3
Rule Brazil 2029 only - Oct 21 00:00 1 2
Rule Brazil 2030 only - Feb 17 00:00 0 3
Rule Brazil 2030 only - Oct 20 00:00 0 3
Rule Brazil 2031 only - Feb 16 00:00 0 3
Rule Brazil 2031 only - Oct 19 00:00 1 2
Rule Brazil 2032 only - Feb 15 00:00 0 3
Rule Brazil 2032 only - Oct 17 00:00 1 2
Rule Brazil 2033 only - Feb 20 00:00 0 3
Rule Brazil 2033 only - Oct 16 00:00 1 2
Rule Brazil 2034 only - Feb 26 00:00 0 3
Rule Brazil 2034 only - Oct 15 00:00 1 2
Rule Brazil 2035 only - Feb 18 00:00 0 3
Rule Brazil 2035 only - Oct 21 00:00 1 2
Rule Brazil 2036 only - Feb 17 00:00 0 3
Rule Brazil 2036 only - Oct 19 00:00 1 2
Rule Brazil 2037 only - Feb 22 00:00 0 3
Rule Brazil 2037 only - Oct 18 00:00 1 2
Rule Brazil 2038 only - Feb 21 00:00 0 3
Rule Brazil 2038 only - Oct 17 00:00 1 2
Zone America/Sao_Paulo -3:00 Brazil -0%s

Zone Brazil/East -3:00 Brazil -0%s

Agora rode o comando 'zic timezone.zic', como root.

Depois disso rode o mesmo zdump acima e confere se a data mudou para 18 de novembro.

Estando tudo certo, agora é descansar tranquilamente sabendo que não terá problemas, mais ou menos o que aconteceu com alguns iPhones hoje.

E, no Windows, como fica??

A partir daí, tem outro procedimento. Antigamente tinha um site da Microsoft que disponibilizava um aplicativo. Como não encontrei mais, então teremos que partir para um aplicativo de terceiros. No site da CNET tem uma versão do Tzedit https://download.cnet.com/Tzedit/3000-2094_4-76358086.html

Normalmente vem dois arquivos dentro do zip. Um para 32 bits e outro para 64 bits. Veja qual é o melhor para o seu sistema.

Rode o aplicativo e vai para o horário correspondente a Brasília.

Daí muda o Start Day de First para Third Sartuday que é 1 segundo antes da virada, igual na figura abaixo:

A alteração é simples.

Dá ok e é só dormir tranquilo.

Isso foi apenas de uma máquina. Para vários computadores e servidores de uma vez, existem várias técnicas como usar algum aplicativo tipo Puppet ou GPO de Windows e muitos outros. Mas aí o Google pode te ajudar nisso.

Mas, como informado na última atualização. O horário de verão volta a ser no dia 4 de novembro. Então, fatalmente, será: PREPARA...

Que agora terá o Show dos Atrasados..

Que acordaram 1 hora mais tarde e não regularam os relógios

chegando 1 segundo depois de fechar o portão...

Material é que não vai faltar este ano..

Tenham uma boa semana.

Como resetar o thumbnail dos sites do Chrome sem apagar o site da lista?

Vamos mexer com as imagens do Chrome

Essa é uma ótima dica que pode ser usada na seguinte situação:

Você usa o Whatsapp Web e recebe uma figura que não quer que receba (Tipo aquela do negão). Daí fecha e deleta a figura.

Nisto você abre uma nova aba e lá está a figura no thumbnail. Em um Desktop, numa sala isolada, é tranquilo e some em alguns dias. Mas imagina que está em um notebook que fica de cima para baixo e com um monte de olhos sufrando no seu ombro durante o dia.

A solução mais simples é remover o thumbnail clicando em remover. Mas você não quer remover o site, só quer apagar a imagem e mudar para uma situação mais inocente. Mas como se faz isso????

Existem várias soluções na rede. Mas são para versões antigas. Como o código do Google Chrome mudou nos últimos anos(Estamos na versão 67), então existe uma outra solução mais localizada. Vamos ver?

Primeiro vamos ver o thumbnail alvo. Vamos utilizar o thumbnail que está literalmente trollando, como exemplo.

Vamos apagar o Troll que a seta está apontando.

Primeiro vamos descobrir onde o perfil da conta é guardado. Digite about: no campo de endereços.

A última linha mostra o caminho do perfil que deve acessar. Nesta é em uma máquina Linux. No Windows o caminho é outro:

Normalmente o caminho termina com a pasta Default. Mas tem casos, se usar multiplos perfis que pode ir para Profile 1, Profile 2. Então o final do caminho pode ser totalmente diferente.

Agora vamos dentro da pasta e precisamos procurar por um arquivo chamado Top Sites. Pode não ter extensão nenhuma, mas é nele que fica os dados dos sites mais visitados e que aparece na tela inicial do Chrome. Instale um software como o sqlitebrowser, fecha o Chrome e abre o arquivo.

Nele tem duas tabelas, a que interessa é a thumbnails e, dentro dela encontramos a linha que queremos mexer:

Achamos a linha que queremos mexer.

A imagem fica justamente codificado na columa thumbnail. Apaga a informação desta coluna, salva e reinicia o Chrome.

O thumbnail pode ter movido para a primeira posição. Mas a figura sumiu.

Ao acessar, a imagem praticamente sumiu. Se fosse o Whatsapp Web, é só acessar que a imagem será outra totalmente diferente e se livrou do enorme constrangimento sem ter que remover o link importante.

Tenham um bom final de 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.