quarta-feira, 9 de dezembro de 2020

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

 

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

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

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

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

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

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

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

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

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

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

E assim vai nascer o Rocky Linux

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

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

Mais informações:

Tenham uma boa semana.

sexta-feira, 4 de setembro de 2020

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

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

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

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

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

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

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

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

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


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

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


segunda-feira, 3 de agosto de 2020

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

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


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

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

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


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


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

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

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

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

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

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

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


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

Ah, mas vou usar o VirtualBox enquanto isso.


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


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

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

Tenham uma boa semana.


quarta-feira, 17 de junho de 2020

Como fazer o Google Chrome voltar a exibir a URL completa

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

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

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

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

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

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

Agora aparece a opção.

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

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


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

Tenham uma boa semana.