search

SpenceKonde / ATTinyCore

Arduino core for ATtiny 1634, 828, x313, x4, x41, x5, x61, x7 and x8
Other
1.53k stars 301 forks source link

http://drazzy.com/package_drazzy.com_index.json --> connection refused #803

Closed mtempels closed 8 months ago

mtempels commented 9 months ago

Drazzy.com returns connection refused when trying to download the board json file:

$ telnet drazzy.com 80 Trying 52.4.232.83... telnet: connect to address 52.4.232.83: Connection refused telnet: Unable to connect to remote host

telnet drazzy.com 443 Trying 52.4.232.83... telnet: connect to address 52.4.232.83: Connection refused telnet: Unable to connect to remote host

It seems there is something wrong with drazzy.com?

Cheers Matthijs

SpenceKonde commented 9 months ago

Yes I am aware of the issue. Apparently sometime in the past week or so github started forcibly upgrading http connections to https connections within github actions (there is another issue about this somewhere I don't immediately see where) which showed a spotlight on the fact that I have botched the https configuration on drazzty.com and was renewing a certificate, but the server continued to present the default one that came with httpd installation.

My first attempt at improving things however instead made things worse and the apache server doesn't start right now.

ladyada commented 9 months ago

do you need a hand automating the json & zip creation/updating so that you can host it on github pages rather than through a separate site?

SpenceKonde commented 9 months ago

The issue I'm having has nothing to do with that (and I'd sooner make the cores unavailable than host the json on github like some kind of scrub). I host the packages themselves on github, plus the x64 linux avr-gcc package since most of the activity downloading the packages is the CI testing. I host everything else on a real service like a real person (AWS EC2 for the large avr-gcc blobs, everything else on my servers.

My problem at this point is that http://drazzy.com works, but https://drazzy.com doesn't, and I don't really understand why. I've got certs from let's encrypt. a while ago I had it serving the wrong certs, but was never able to make it server https and use the right certs.

2bndy5 commented 9 months ago

My problem at this point is that http://drazzy.com works, but https://drazzy.com doesn't, and I don't really understand why. I've got certs from let's encrypt. a while ago I had it serving the wrong certs, but was never able to make it server https and use the right certs.

Instead of contending with problems you don't understand, wouldn't it be easier to switch to a web hosting platform that does this for you (& for free)? I do not intend any offense, rather I'm just trying to encourage swifter resolution.

I'd sooner make the cores unavailable than host the json on github like some kind of scrub

This seems a bit confrontational for such a friendly suggestion/offer. I'm not sure why you're so against it, other than a breaking change for existing installs to get updates. Even if you do fix the certs (or whatever the real problem is), there's no guarantee that it won't come up again over time (ie future/inevitable changes to SSL).

Since v2.0 seems around the corner, I think this would be an ideal time to introduce any breaking changes.

My stake in this: I'm using this drazzy json link to compute compile size differences in RF24 lib's Arduino CI, and it has been failing to do so because of this issue.

SpenceKonde commented 9 months ago

Uh, the issue with the latest versions of the CLI looks like it's saving the json file with the wrong file name o_O I think there was an assumption that it was related to https in a previious discussion, but I don;t belive it was ever shown to be related. And when I finally saw what the issue looked like on a system, it doesn't look like an SSL thing to me... SSL failures fail to connect, they don't download the file and mangle the name. They were messing with this part of board manager backend, and I'd guess that they broke something related to file name handling...? It doesn't really make sense, this failure pattern. No https library will make a request, give you the file with the wrong name and then verify the cert and find that it's not trusted....

For Arduino CI, just tell it to use CLI 0.33.0 (see https://github.com/SpenceKonde/DxCore/blob/6fa5efbd2181590e0276e19a756c4c9564c33497/.github/workflows/compile-examples.yml#L326 ) - DxCore one linked since that is the most readable of the CI's - the workflow file for this core is almost impenetrable, and the workflow for mTC is like 2x longer I think, in terms of lines of yaml (versus DxC's)

2bndy5 commented 9 months ago

I didn't see anything in the Arduino CLI changelogs that indicated a problem... I will try to downgrade that in our CI (& report back). FWIW, I am able to use the latest Arduino CLI on my local (Windows 11) machine to install the ATTinyCore:avr.

2bndy5 commented 9 months ago

For Arduino CI, just tell it to use CLI 0.33.0 (see https://github.com/SpenceKonde/DxCore/blob/6fa5efbd2181590e0276e19a756c4c9564c33497/.github/workflows/compile-examples.yml#L326 )

Yep that solved it for me! 🎉 Thanks for the advice and sorry for the thread pollution here.

per1234 commented 9 months ago

the latest versions of the CLI looks like it's saving the json file with the wrong file name

I submitted a report of the bug to the Arduino IDE developers: https://github.com/arduino/arduino-cli/issues/2345

I think there was an assumption that it was related to https in a previious discussion, but I don;t belive it was ever shown to be related. And when I finally saw what the issue looked like on a system, it doesn't look like an SSL thing to me.

I guess you are referring to https://github.com/SpenceKonde/ReleaseScripts/issues/42

SpenceKonde commented 9 months ago

Gaaah! Thank you, there is it! I'd been looking for that issue all week!

SpenceKonde commented 8 months ago

Closing, the server is running again.