Cloudron Forum

I still think that my well-known file is not being read correctly. So the federation tester reverts back to testing the default federation port, which is 8448 and fails unless I forward it myself to the cloudron's 443 port.

This hypothesis does explain the behavior but what I'm not getting is why the well-known setup on my end would be incorrect. It looks ok as far as I can tell.

Sorry I missed some of your questions above. Yes, I am running synapse on my cloudron server.

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Can you check what is listening on your server with sudo lsof -i :8448 ?

When I run this on the cloudron server (I'm assuming that what you meant) I get no output. That would make sense since the Synapse app doesn't listen on 8448.

My only hypothesis right now is that my setup for the well know file is somehow wrong. The error above also mentions No SRV records found. Is that talking about not finding the well-known info at the root?

I think I'm not explaining myself correctly

@joseph said in Federation testing fails unless port 8448 is forwarded to 443:

Port forwarding in your firewall makes no difference.

It does because I'm forwarding 8448 on my firewall to 443 on the cloudron server. I mentioned that above I think

Maybe ignore my previous comment too. AFAICT, your domain works fine and does not contact 8443.

The well-known part is set up correctly. You can try curl -L https://malenfant.net/.well-known/matrix/server to make sure.

As I mentioned above I am checking malenfant.net with the checker and not matrix.malenfant.net.

The reason my domain currently works with the checker is because I have port 8448 forwarded to 443 on my firewall in front of the server.

If I remove the forwarding and run the checker I get the error I mentioned in my first post:

Connection Errors
Get "https://xx.xx.xx.xx:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Get "https://[xxx:xxx:xxx:xxx:xxx:xxx]:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

which would seem to indicate that the tester does NOT read the well-known file and indeed tries to check 8448.

I just tried right now with the forwarding disabled:

Thanks. That was mostly my understanding of how it 'should' work too.

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

If you check federation for your base domain, you can see that it actually checks port 443 not 8448.

This is where the results in my original post surprised me. If you look at the error log I got from the federation tester it looks like is does test for port 8448 and ignores the setting I have in the .well-known file which should point it to port 443.

Once I forward 8448 to 443 the federation testers returns no errors.

So my question was, does the tester ignore the well known file or did I set something up incorrectly when I seup the app? Basically do other people get the same error with the tester when using a fresh install of the app with the .well-known file correctly setup.

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

But https://federationtester.matrix.org/#malenfant.net correctly recognizes federation. Is this with your fix?

Yeah. If I don't forward 8448 then the tester returns the error I put in the original post.

Clouflare proxying is off for both matrix.malenfant.net and malenfant.net in my case.

Does anyone know if the federation tester actually reads the well-known server info as part of the test?

@andreasdueren said in Federation testing fails unless port 8448 is forwarded to 443:

@DidierMalenfant Do you have any app installed on the base domain?

@james said in Federation testing fails unless port 8448 is forwarded to 443:

Also, you have to use the base domain in the federation tester not e.g. synapse.cloudron.club.

Yes to both of those (I can curl https://malenfant.net/.well-known/matrix/server too and the returned json looks correct).

It could very well be that the tester doesn't read the well-known server info but if that's the case then, again, maybe that should be added to the docs so others can know they might see this error.

Or maybe I've done something wrong in setting this up...

I have the synapse app installed and I ended up having to port forward port 8448 to port 443 on my firewall in order to get federation testing to pass.

Otherwise this error would be returned:

Connection Errors
Get "https://xx.xx.xx.xx:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)Get "https://[2600:8802:3000:1492:56b2:3ff:fe09:1c9]:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

I have the well known location setup up on the bare domain with port 443 but somehow this is not enough to get the server to pass the federation test.

I don't see any mention of the port forwarding requirement in the docs, although it does mention that the app uses 443 for both user and server communications.

Did I do something wrong in my setup or should this be maybe added to the documentation somewhere?

Thanks! as it turns out, in my case it was the cloudflare proxy causing issues. I had disabled it for IPv4 but forgot to do the same for IPv6 so the results/errors were confusing because of this.

Sweet, thanks. I added it to my start script.

I migrated my Mastodon instance from masto.host to a cloudron app and I've noticed that it doesn't seem to be federating correctly.

For example I can only see posts from @macrumors@mastodon.socialon my instance until July 11th and then nothing. If I go directly on mastodon.social all their more recent posts are all there there. I don't see any user facing errors on the website or in the admin section (federation for mastodon.social says "No failures on record").

I added these to my env.production file:

RAILS_LOG_LEVEL=debug
LOG_LEVEL=silly

and rebooted the container. Once the site was back up I searched for @macrumors@mastodon.social in the search bar and grabbed the log after that.

I see this:

2025-08-09T20:45:27Z 2025/08/09 20:45:27 [error] 49#49: *5 connect() failed (111: Connection refused) while connecting to upstream, client: 172.18.0.1, server: , request: "GET /api/v1/announcements HTTP/1.1", upstream: "http://127.0.0.1:3000/api/v1/announcements", host: "malenfant.net", referrer: "https://malenfant.net/deck/search?q=%40macrumors%40mastodon.social"

172.18.0.x seems to definitely be the sub-net that the docker container is on but I don't understand what it's trying to do here.

As a bonus, I'm pretty sure that my posts are not being seen by all my followers either but I only have anecdotal evidence of this at this point.

Anyone with some Masto admin experience able to guide me in the correct direction for diagnosing/fixing this? I'm willing to learn but I don't know where to start...

I was testing cloudron migration for my test/dev server and everything worked fine apart from the file ownership inside /app/data weren't correct after the migration. I had to manually do a chown cloudron:cloudron to fix it.

Since the only app on that server was one of my own, I was wondering if I did anything wrong in the app itself that would cause this to happen.

Should all file ownership be handled by the migration or is it left to the app itself to fix this during its init?

Latest update works! Thanks for the fixes.

I'm going to play with it for a bit but I'll leave a few more things I noticed in case you want to address those too:

• If you do git add --chmod=+x cld.sh locally you can then commit the executable flag with your repo and skip a step in the README.
• The cld.sh script should probably have a set -e line at the top (after the #!/bin/bash) to make sure the script stop executing if something goes wrong with one of the commands.
• Currently everything in /app/data is owned by root and I believe agate itself is launched as a root owned app. It's probably safer to make all the files in in /app/data owned by cloudron:cloudron and launch programs with /usr/local/bin/gosu cloudron:cloudron to run as the cloudron user. I might be off here but that was my understanding of recommended behavior looking at the documentation. Someone else can deny or confirm.

Great job on the app!

Testing it now...

• You need a chmod +x cld.sh in the repo.
• The installation never completes for me. It gets stuck at Waiting for propagation of newsite.malenfant.dev even though the DNS is updated. The app doesn't seem to launch.

Could be something with the DNS on cloudflare... Log shows:

Jul 16 17:28:25 box:dns/waitfordns resolveIp: Checking A for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns resolveIp: No A. Checking CNAME for newsite.malenfant.dev at 162.159.38.40
Jul 16 17:28:25 box:dns/waitfordns isChangeSynced: NS davina.ns.cloudflare.com (162.159.38.40) errored when resolve newsite.malenfant.dev (A): Error: queryCname ENODATA newsite.malenfant.dev

but if I ping newsite.malenfant.dev from the command line it gets resolved correctly... odd.

Could it be that the domain is hardcoded in cld.sh?

# Generate self-signed wildcard certificate for all subdomains
echo "Generating self-signed wildcard certificate for *.appx.uk..."
# Extract the base domain (appx.uk) from CLOUDRON_APP_DOMAIN
BASE_DOMAIN="appx.uk"
WILDCARD_DOMAIN="*.${BASE_DOMAIN}"

Nice one!

I think as an option it's a really good idea. I'll look into it if I get a chance.

@timconsidine said in Agate - A simple gemini server:

If it were built into your agate deployment, would that deliver an app which effectively serves both gemini and http ?

It looks like it could work. What I'm not sure is:

• How do we make it an option so that people who don't want http can have it off.
• It doesn't seem to return when launched so how do we run both this and agate side by side?
• How safe is the http server for this? The one I use for the health check, Caddy, is pretty well supported and widely used. I don't know about this one.

@LoudLemur said in Agate - A simple gemini server:

I think Agate supports multiple users, so that might end up with some confusion, too.

The way the app is setup in my case is just to serve files located in /app/data/public. You can see the default index.gmi in there after you install; the app. Editing this and setting up the folder structure is left to the user as it's basically gemini stuff and not specific to the app itself.

I'm going to update the README in the repo to mirror @timconsidine's great step by step instructions on installing the image.

@timconsidine said in Agate - A simple gemini server:

@LoudLemur try ….
cloudron install —image didiermalenfant/net.malenfant.agate:latest
In other words put a space not a colon after ‘image’

Yep, good catch. That's totally a typo on my part.

@LoudLemur said in Agate - A simple gemini server:

Move Agate to your Cloudron
It helps to have a GUI, so install the Cubby application on Cloudron.
Then, open Cubby's file browser and use it to upload the agate folder to an appropriate place (where?!) on your Cloudron.

Wait... I'm confused. Where are those steps from? The next step in my list above was to install the cloudron CLI.

@LoudLemur said in Agate - A simple gemini server:

What is the procedure to try and install this on Cloudron?

• Make sure your Cloudron backups are up to date
• Clone the app's repo from https://code.malenfant.net/didier/agate-app.git
• Install the cloudron CLI
• Login to your cloudron server
• CD into the cloned repo's folder
• Type cloudron install --image:didiermalenfant/net.malenfant.agate:latest
• Enter the subdomain you want to install the app at.

Let me know if you encounter any issues. This is pre-release software but it would be good to get feedback from other people too.