phar.io Install script broken

[nvuillam]

It seems that since 0.15.0 release, the installation script does not work anymore.

Reason seems to be that wget -O phive.phar https://phar.io/releases/phive.phar now returns a 404 error

Below the error from my Dockerfile execution

Step 36/97 : RUN wget --tries=5 -q -O phive.phar https://phar.io/releases/phive.phar     && wget --tries=5 -q -O phive.phar.asc https://phar.io/releases/phive.phar.asc     && PHAR_KEY_ID="0x9D8A98B29B2D5D79"     && ( gpg --keyserver keyserver.pgp.com --recv-keys "$PHAR_KEY_ID"         || gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$PHAR_KEY_ID"         || gpg --keyserver pgp.mit.edu --recv-keys "$PHAR_KEY_ID"         || gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys "$PHAR_KEY_ID" )     && gpg --verify phive.phar.asc phive.phar     && chmod +x phive.phar     && mv phive.phar /usr/local/bin/phive     && rm phive.phar.asc
 ---> Running in 7b235479a1f1
wget: server returned error: HTTP/1.1 404 Not Found

It blocks new releases of Mega-Linter, please could you fix the issue or provide a workaround ?

Thanks :)

[heiglandreas]

It also breaks CI pipelines on github using

uses: "shivammathur/setup-php@v2"
with:
    tools: "phive"

with the message

==> Setup Tools
✓ composer Added composer 2.1.5
chmod: cannot access '/usr/local/bin/phive': No such file or directory
✗ phive Could not setup phive

wget output is:

$ wget -O phive.phar https://phar.io/releases/phive.phar
--2021-07-26 08:14:34--  https://phar.io/releases/phive.phar
Auflösen des Hostnamens phar.io (phar.io) … 188.94.27.6
Verbindungsaufbau zu phar.io (phar.io)|188.94.27.6|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2021-07-26 08:14:45 FEHLER 404: Not Found.

Curl says this

$ curl -v https://phar.io/releases/phive.phar
*   Trying 188.94.27.6:443...
* Connected to phar.io (188.94.27.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=phar.io
*  start date: Jul 16 03:33:54 2021 GMT
*  expire date: Oct 14 03:33:52 2021 GMT
*  subjectAltName: host "phar.io" matched cert's "phar.io"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e1fcab8580)
> GET /releases/phive.phar HTTP/2
> Host: phar.io
> user-agent: curl/7.74.0
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
* http2 error: Invalid HTTP header field was received: frame type: 1, stream: 1, name: [not found], value: []
* HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
* stopped the pause stream!
* Connection #0 to host phar.io left intact
curl: (92) HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)

[theseer]

Debugging this...

[theseer]

Apparently, even nginx sometimes is just windows in need of a restart...

[heiglandreas]

Can confirm! It works again! Thank you for the fast resolution!

[theseer]

Post mortem

Reason of failure

Digging a bit deeper into log files, it appears to have been a DNS issue.

Details

The release redirect is powered by a small (hacky? ;) ) PHP script which connects to the github API to find the latest release and redirect to the appropriate asset.

Based on the logs from PHP, it appears to have failed to contact github and thus didn't have the required data to perform the redirect. For debugging purposes, i ran that script on the CLI, which took way longer than it should have before finally failing, pointing at connection issues.

When trying to manually connect to github, the hostname could not be resolved. I rebooted the VM, which, apart from of course restarting the processes in question (nginx, php-fpm), also updated the network configuration - namely the DNS server to use. After that, all seems to be working fine again.

Actions taken

Performing an API call to github.com upon every request is a hack, particularly since the current release information doesn't change very often.

The links to the asset files associated with a release are static. The best fix would be to create the redirects statically upon release. I'll create an issue to change this.

[nvuillam]

Works for Mega-Linter now too, thanks for your reactivity :)

[theseer]

You're welcome.

And, just for the record: It had nothing to do with the 0.15.0 release ;)