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.