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.

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.

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

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

5.8: mainline Version: 5.8 (mainline) Released: 2020-08-02 Source: linux-5.8.tar.xz PGP Signature: linux-5.8.tar.sign Patch: full https://t.co/92ScQXt9Ou #linux #kernel

— Linux Kernel Releases (@LinuxKReleases) August 3, 2020

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

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

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

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

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

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

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

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

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

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

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

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

Ah, mas vou usar o VirtualBox enquanto isso.

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

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

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

Tenham uma boa semana.

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.

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.

AOL Instant Messenger será desativado em dezembro

Sabe aquele que achava que morreu? Pois bem, vai morrer no final do ano.

Uma notícia andou circulando no Twitter e sites de tecnologia lá fora nesta sexta. A AOL, que agora pertence a Verizon, anunciou que o serviço de mensagens instantâneas será descontinuado no dia 15 de dezembro, conforme o último tweet enviado pela empresa:

All good things come to an end. On Dec 15, we'll bid farewell to AIM. Thank you to all our users! #AIMemories https://t.co/b6cjR2tSuU pic.twitter.com/V09Fl7EPMx

— AIM (@aim) 6 de outubro de 2017

Quem acessava a Internet nos anos 90 e usou os CDs da AOL sabe como é o AOL Instant Messenger.  Um mensageiro instantâneo criado na mesma época do ICQ, no qual a AOL comprou e fez com que os usuários de um serviço se comunicasse com o outro. O mensageiro só deixou de ser utilizado depois da AOL ter saído do Brasil e da acensão do finado MSN Messenger, no início dos anos 2000. Ainda sim mantinha alguns usuários ativos até hoje no mundo.

Com o fim do AOL Instant Messenger, ainda temos, da primeira geração de mensageiros instantâneos, o ICQ, que pertence, atualmente, a uma empresa russa, e o Yahoo Messenger, este último só está limitado a sua interface web.

Mais informações: (por enquanto é em inglês, mas se aparecer em sites brasileiros, se alguém lembrar, vou informar  Já tem notícia no tecmundo).

https://tech.slashdot.org/story/17/10/06/1649204/rip-aim-aol-instant-messenger-dies-in-december

https://www.usatoday.com/story/tech/talkingtech/2017/10/06/rip-aim-aol-instant-messenger-dies-december/739076001/

https://www.tecmundo.com.br/internet/122782-aol-instant-messenger-dar-adeus-15-dezembro.htm

Tenham um bom final de semana.

Resolvendo o problema de compilação de módulos do VMware na Debian com gcc 7.x

Aqui, em casa, utilizo bastante o VMware Workstation para rodar as minhas máquinas virtuais para testes e ajudar em algumas implementações nos programas que uso. Porém, após as últimas atualizações da minha Debian Sid, com o kernel, aconteceu algo estranho:

Como assim não encontrou o gcc???

Então coloquei /usr/bin/gcc no Location e me retornou isso:

Como assim não achou uma versão compatível???

Então tentei usar a linha de comando rodando o "/usr/bin/vmware-modconfig  --console --install-all". Mas, o que consegui foi:

Failed to get gcc information.

Aí as coisas ficam mais estranhas ainda. Como assim não conseguiu encontrar?? Então resolvi procurar várias soluções para este problema e, tudo que encontrei no Google, não resolveu e o erro ainda persiste.

Então tentei seguir o script /usr/bin/vmware-modconfig. Mas, no final, ele chega no /usr/lib/vmware/bin/appLoader, que é um arquivo binário. Sendo a falha acontecendo no binário, fui verificar os logs e me retornou o seguinte:

2017-08-07T18:46:02.429-03:00| modconfig| I125: Trying to find a suitable PBM set for kernel "4.12.5".
2017-08-07T18:46:02.429-03:00| modconfig| I125: No matching PBM set was found for kernel "4.12.5".
2017-08-07T18:46:02.429-03:00| modconfig| I125: Found compiler at "/usr/bin/gcc"
2017-08-07T18:46:02.431-03:00| modconfig| I125: Got gcc version "7".
2017-08-07T18:46:02.431-03:00| modconfig| I125: Unable to parse gcc version
2017-08-07T18:46:02.434-03:00| modconfig| I125: We are now shutdown.  Ready to die!

De alguma forma a parte do VMware, que gera os módulos, só reconhece as versões do gcc até a 6, acima disso ele não conhece e a compilação é abortada. E o problema só ocorreu porque, durante as atualizações do sistema, a versão do gcc padrão utilizada passou da versão 6 para a 7, e foi aí que a incompatibilidade aconteceu.

Como não quero esperar chegar uma versão mais nova para corrigir, o jeito é criar um script que, pode fazer este papel. O script que criei é esse:

#!/bin/bash

#Cria os módulos de forma manual

/etc/init.d/vmware stop

mkdir /tmp/vmware-build

cd /tmp/vmware-build


tar -vxf /usr/lib/vmware/modules/source/vmmon.tar
tar -vxf /usr/lib/vmware/modules/source/vmnet.tar


cd /tmp/vmware-build/vmmon-only/
make

mkdir /lib/modules/`uname -r`/misc
cp vmmon.ko /lib/modules/`uname -r`/misc/vmmon.ko

cd /tmp/vmware-build/vmnet-only
make


cp vmnet.ko /lib/modules/`uname -r`/misc/vmnet.ko

depmod -a

/etc/init.d/vmware start

cd


rm -rf  /tmp/vmware-build

Este script, descompacta compila e instala os módulos. A vantagem dele é que não precisa verificar qual versão do gcc. Ele já utiliza a última versão, instala e deixa o VMware pronto para o uso.

Após o teste, tudo voltou a funcionar como antes.

Espero que isso ajude a resolver este pequeno problema. Caso tenha erros de compilação, por algum outro motivo, recomendo que dê uma olhada em http://rglinuxtech.com/. Normalmente encontro patches que podem servir para corrigir os módulos do VMware, caso haja problemas após a atualização para a versão mais recente. O site também vale para os módulos da NVIDIA para as placas de vídeo. Vale a pena.

Tenham uma boa semana.