http://drazzy.com/package_drazzy.com_index.json --> connection refused
mtempels opened this issue · 10 comments
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
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.
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?
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.
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.
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)
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.
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.
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: arduino/arduino-cli#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 SpenceKonde/ReleaseScripts#42
Gaaah! Thank you, there is it! I'd been looking for that issue all week!
Closing, the server is running again.