-
@girish thank you for the support and answers
i got to this, and maybe it good to know that at the very beginning i was started with the mijn.mastodon.education as name, changed this to the good one mastodon.education, and the admin centre is https://my.mastodon.education/ -
@redegelde for future, since it seems you are not much aware of how linux terminals work, to view a file, you can view it into the terminal with
cat /var/log/nginx/error.log
this will dump the whole content there for a start. Directly executing a file like you did from your screenshot, will attempt to well execute or run that, which in this case it not an executable or otherwise a runnable script.To come back to your root issue. With such federated apps, changing the domain afterwards causes often various side-effects. In your case would just start over, uninstall the app instance and install a new one. Afterall this is very easy with Cloudron.
-
@redegelde I'm seeing this issue as well.
As @nebulon says, "the well known uri should actually be /.well-known/... " but /well-known-handler/ is the script on the bot that handles the call to /.well-known/, so that's all fine.
As @girish says, the call to your webfinger (or my webfinger) request does work fine, too. The response is exactly what it should be. But it is also accompanied by this error in the logs.
So, I think...
- It's an error appearing in your logs
- It doesn't matter, because the actual call is handled fine.
I think what's happening here is that it's looking for a custom .well-known configuration, not finding one, and then using the default response. So everything's fine - but the error shouldn't be appearing in the logs.. at least, that's how I'm reading it.
-
@jamescridland said in Mastodon Get well known handler:
I think what's happening here is that it's looking for a custom .well-known configuration, not finding one, and then using the default response. So everything's fine - but the error shouldn't be appearing in the logs.. at least, that's how I'm reading it.
We give the app a chance to handle well-known. If it doesn't, we try to handle it (to return responses from the configuration in the Domains view - https://docs.cloudron.io/domains/#well-known-locations). As you said, what is happening is Mastodon handled it but returned a 404. Then our code also tries to handle it and prints out a 404.
So.. just ignore the logs I guess. It's not really an error, it's just a 404.
-
@girish Hmm.
We give the app a chance to handle well-known. If it doesn't, we try to handle it
Not sure this is what's happening.
If I visit https://social.crid.land/.well-known/webfinger?resource=acct:james@crid.land
The Mastodon server log returns:
Nov 11 18:30:54 (ipaddress) - - [11/Nov/2022:08:30:54 +0000] "GET /.well-known/webfinger?resource=acct:james@crid.land HTTP/1.1" 200 264 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36"
It's an HTTP 200 OK response. It's handled the
.well-known
entirely correctly.The Cloudron server logs consistently also says:
GET /well-known-handler/webfinger?resource=acct:james@crid.land 404 Not Found No custom well-known config 1.252 ms - 71
So, for some reason, Cloudron has not noticed that the
.well-known
has been correctly handled, and is also triggering. (Not quite sure where the 404 goes.)I think this is an error (and a bug in Cloudron). Code should not be executing on a successful web request. How do I report this?
For @redegelde to know: this is not a bug in Mastodon (or, indeed, generated by it). Which probably explains why I couldn't find the well-known-handler in the Mastodon codebase!
-
@jamescridland you are right, I flipped the order. Our code handler has higher priority (over mastodon). This is why you see the 404 handler on Cloudron side first.
well-known URIs are fairly generic, it's used for Let's Encrypt etc. So, we have a "generic" route handler like well-known/* . Maybe this can be made more specific to avoid the 404 messages in Cloudron logs but it does complicate the code.
-
@redegelde "With such federated apps, changing the domain afterwards causes often various side-effects."
https://masto.host/dns/#:~:text=Currently Mastodon doesn't support,subdomain you want to use.
https://docs.joinmastodon.org/admin/config/ Look under Basic->Federation
This isn't a Cloudron issue. If anything, Cloudron makes installing, running and using Mastodon so simple.
If you do start over, I don't think you can use just mastodon.education, because Cloudron needs that root domain for the /.well-known... right Cloudronites? So something more like social.mastodon.education, or mstdn.mastodon.education, etc. will be needed for the new Mastodon instance.
BTW, good work on grabbing mastodon.education! There aren't many mastodon.xxx's left!
-
@redegelde maybe we can start over fresh here. What again is your exact issue with that instance? Are you just concerned about that log line stating that something is contacting the well known handler and Cloudron (not even the mastodon app itself) is just showing an info message about 404 here?
-
@nebulon Hi, think it was an combination. The place was growing and some users get an 500 in there screen. Also posting does not work, I discover lak of space so increase the server."
At the same time i saw when i was looking to the logs Known handler error lines.This is still the case, but site is working good, no complains
GET /well-known-handler/nodeinfo 404 Not Found No custom well-known config 0.804 ms - 71
GET /well-known-handler/host-meta 404 Not Found No custom well-known config 1.776 ms - 71
GET /well-known-handler/webfinger?resource=acct:redegelde@mastodon.education 404 Not Found No custom well-known config 0.889 ms - 71Good services,
enough space(48 GB used of 168,9GBso ift this is no problem, leave it i think
-
-