domingo, 18 de abril de 2021

Como redirecionar um site do Google App Engine para https.

 



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

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

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

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

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

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

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

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

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

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

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

Tenham uma boa semana.

sábado, 27 de março de 2021

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

 

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


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

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

E não dá para passar.


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


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

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


E impacto foi em cima do barco.


Praticamente acabou com o barco.

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

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


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


Tenham um bom final de semana.

quinta-feira, 25 de março de 2021

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

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

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


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

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

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

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

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

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

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

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

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

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

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


A mensagem acima difere um pouco de:


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

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


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


O esquema do DHCP é mais ou menos esse


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


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

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


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


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


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


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


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


Então segui esta dica:


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


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

[main]

dhcp=dhclient



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


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


ls *.lease -lrt

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


Tenham um bom dia.


quarta-feira, 9 de dezembro de 2020

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

 

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

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

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

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

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

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

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

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

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

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

E assim vai nascer o Rocky Linux

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

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

Mais informações:

Tenham uma boa semana.

sexta-feira, 4 de setembro de 2020

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

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

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

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

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

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

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

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

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


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

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


segunda-feira, 3 de agosto de 2020

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

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


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

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

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


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


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

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

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

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

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

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

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


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

Ah, mas vou usar o VirtualBox enquanto isso.


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


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

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

Tenham uma boa semana.


quarta-feira, 17 de junho de 2020

Como fazer o Google Chrome voltar a exibir a URL completa

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

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

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

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

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

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

Agora aparece a opção.

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

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


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

Tenham uma boa semana.

sábado, 6 de julho de 2019

Lançado o Debian Buster




Depois de mais de 25 meses de desenvolvimento e, praticamente, um dia de atualizações. Foi lançado, agora a pouco, a versão 10.0 da distribuição Debian, também conhecida como Buster. Acho que este é o segundo nome que não é de um brinquedo da franquia Toy Story. O outro nome é da versão instável que é conhecida como Sid.

Existem várias novidades que estão descritas no link do lançamento, como o suporte a inicialização segura quando o boot é feito pela UEFI. O Wayland sendo usado por padrão no GNOME e muitas outras novidades e atualizações.

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

Tenham um bom final de semana.

quarta-feira, 26 de junho de 2019

Resolvendo os problemas do tamanho do ibdata1 no MySQL - versão 2019

Esta é uma atualização da publicação https://www.adilson.net.br/2009/12/resolvendo-os-problemas-do-tamanho.html , que tem quase 10 anos. Só que vou adicionar alguns detalhes novos que mudaram de 2009 para hoje, em 2019.

Um problema que enfrentava sempre que colocava um aplicativo utilizando o MySQL é o tamanho sempre crescente do arquivo /var/lib/mysql/ibdata1. Este arquivo armazena as tableas do tipo InnoDB e, mesmo que os dados sejam removidos ou elimine tabelas e, até mesmo, banco de dados, o tamanho do ibdata1 não diminui, o que pode ocasionar problemas de espaço em disco mais para frente.


Fazendo uma pesquisa na rede descobri uma boa solução para esta complicação que é definida como padrão em várias instalações do MySQL e, também, no MariaDB.

Como o MariaDB é um fork do MySQL, vou tratar tudo como MySQL. Então o que for para o MySQL pode valer também para o MariaDB.

A primeira coisa a fazer é criar um backup de todos os bancos de dados do MySQL que utiliza as tabelas InnoDB. Vamos imaginar que temos apenas um banco de dados deste tipo no servidor MySQL. Então será feito o seguinte:


mysqldump -u"usuario" --password="senha" --routines bancodedados > bancodedados.sql


Remove o banco de dados propriamente dito no console do MySQL:


DROP DATABASE bancodedados;


Desative o serviço do MySQL:


service mysql stop ou systemctl stop mysql


remove o arquivo ibdata1


rm -rf /var/lib/mysql/ibdata1


Dependendo da versão deve-se, também remover mais dois arquivos senão o MySQL não inicializa.

rm -rf /var/lib/mysql/ib_logfile0  /var/lib/mysql/ib_logfile1

Edita o /etc/mysql/my.cf e adiciona a seguinte linha aonde está o InnoDB:


innodb_file_per_table ou innodb_file_per_table=ON ou innodb_file_per_table=1


Esta linha faz com que as informações das tabelas fiquem em arquivos em separado.


service mysql start ou systemctl start mysql


Recria o banco de dados no console do MySQL


CREATE DATABASE bancodedados;


Restaura o backup dos banco de dados removido:


mysql -u root -p bancodedados < bancodedados.sql


Depois desta configuração, os dados não ficam mais no ibdata1, e sim nos arquivos *.ibd dentro da pasta do banco de dados relacionado. Em algumas tabelas, este arquivo também cresce e, as vezes, não diminui o tamanho mesmo eliminando dados. Mas, para este problema, existe uma maneira de obter mais espaço no servidor após remover os dados.


Dentro do banco de dados, no console do MySQL, rode o comando


OPTIMIZE TABLE tabela;


Este comando faz com que todo espaço vazio dos dados removidos seja liberado no servidor.

Tenham uma boa semana.

sábado, 8 de junho de 2019

Descanse em paz André Matos 😢

A muitos anos atrás eu participava de um outro blog coletivo e fiz uma resenha de um show do Shaman. Eu ainda não encontrei para fazer um "Recordar é viver" do fundo do baú e alguns dos arquivos antigos estão guardados em algum canto do material que veio comigo do RJ até BH.


Hoje não tem Copy & Paste mas a notícia é triste. Os dois antigos blogs tinham links justamente para as páginas do Angra e do Shaman, duas bandas que foram fundados pelo André Matos. E, de alguma forma, influenciou o antigo blog e quem escrevia, incluindo eu e mais alguns amigos.

Então, como homenagem, vou deixar um link do Youtube, que encontrei da música Fairy Tale, da banda Shaman. Da mesma época em que criei a resenha quando fui a um show deles na Barra.



Esta pessoa aqui que já participou do www.juvifa.webblogger.com.br, que virou www.juvidadi.blogger.com.br (os dois já não existem mais) e, atuamente, em carreira solo no site www.adilson.net.br só tem que dizer obrigado por ser parte das nossas vidas e obrigado por ser uma referência ao Rock nacional e internacional. Descanse em paz.