Cloudron Forum

Nothing obviously related in there. And sure, just figured I'd drop a report in case it was important.

Indeed on Cloudron the app needs to specify which ports are forwarded from outside to the app container. Currently HA has no ports setup there.

We can easily add port 1400 for this, but it is not clear how this is protected by HA. Is this designed to be used in a trusted home network or fine to be exposed on the public?

@Robin my bad. The lamp.cloudronapp.php73 and lamp.cloudronapp.php74 are totally different packages! I think you are using the very old php 7.3 package. This is why you are not seeing the update. I don't know why the old one was deprecated though.

Not sure if relevant to your situation, but to bypass specific DNS entries you can also do:

local-zone: example.com typetransparent local-data: "my.example.com A 172.18.0.1"

I see I already upped the memory limit some time ago, just pending a new package release.

@girish said in Incorrect error when removing an obsolete alias for a service:

Did you happen to set this up manually?

Hmm, I don't actually know. It's not impossible I guess...

Good to know though, I'll work on cleaning DNS up 🙂

Nothing that mentioned the _ (wildcard) cert at least, which is part of why I'm stumped. I don't know what is creating it, or where to look.

@girish Hmm, that didn't match the behaviour I saw. I ended up with two separate SPF records in Hetzner. One that I had already set up from my own DNS setup, and one added from Cloudron - which didn't contain the content of my own record. Thankfully it wasn't difficult to fix, once I read up on it.

@Robin Yeah, I think what you did is the correct approach. Given that we don't have a "I know what I am doing button..." 🙂

@robin pushed a commit to at least give some explanation for 401 https://git.cloudron.io/cloudron/cloudron-cli/-/commit/d90b23c8b561f29f444145d40e4097cb098e5fa1

Apparently no token or invalid token provided to the REST api currently both returns 401.

I think @robin 's suggestion seems well thought out. The big advantage is that it would be totally optional to do it for apps for which it would be hard, while providing a significantly better UX for apps which do support it.

Thanks for the quick response!

@nebulon Kind of depends on the app type, too, I guess? The one I really notice this stand out on is for LAMP. I have maybe 4-5 of these, all serving static sites. I don't really care when they update, but whenever they do, I get a bunch of notifications for them all at once.

I don't know. I guess I see your point, and maybe it's fine to just leave it be. Ultimately, I guess if you don't design for people to have too many things of the same type, it probably won't matter anyway.

@girish I patched my docker.js manually, and I can confirm that port 53 is now exposed on all interfaces, as I would expect! Thanks!

@girish Yes, that would have been the case. Sorry for not responding here, real life has been busy the past few days 🙂

Thanks for the fix!

@mazarian that's correct, the permission is the thing I fixed in 6.3.5. Glad it's working now and thanks for reporting back!

@girish Yeah, I ran:

/home/git/gitea/gitea convert -c /run/gitea/app.ini as user git, and now things seem converted:

ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci ROW_FORMAT=DYNAMIC

On the downside, the convert tool seems to unconditionally convert, and is quite slow, so I guess it can't easily be run as part of the startup process or something 😕

@girish lol, "Just do it!" 😉

Awesome, thanks for the fix @Robin

Right, we are actually fixing notification for the next release (6.3). In the meantime, Domains -> Renew all certs and then check the logs (button on the same page) if it fails. Usually, Let's Encrypt errors are temporary and currently Cloudron is a bit overzealous reporting those errors.