Cloudron Forum

@nebulon The thing is that all records had fully propagated. So I have no explanation for why manual DNS didn't work.. Yes, sure, switching to noop worked, but I shouldn't have had to do that. But OK, if you don't want to dig further we can just call it solved.

Installing anything alongside Cloudron is not recommended and also not supported.

I'm aware, but thankfully, I'm capable of holding my own hand, and it's not like this is some kind of monster of a service that is going to screw things up in massive unfixable ways.

Since Cloudron wants its public IP address for each app for the DNS records it is logical that it will hang at Configuring - Waiting for propagation

I don't see how that follows.

Firstly, because waiting for DNS propagation is not the same as having a public IP address. That is: yes, you clearly need to wait for DNS propagation to complete before it will work - but it had propagated in this case, and it was working just fine, so the message in this case is misleading at best and masking whatever the real problem is.

Secondly, for the case where you're doing certificate management, sure, you need a public IP address so that you can pass a HTTP-01 challenge. But that's disabled here, and that would be a completely different class of error anyway. The record resolved to a routeable address, so I don't see what the problem would be from the networking perspective.

Recapping the problems as I see it here:

• Adding an additional secondary redirect for an app should not block reconfiguration of that app, because that can/will lead to extensive downtime - it might be sensible for there to be a degraded state or notification, but I think that should be handled non-blocking ideally. I can understand that this might not be easy, though.
• Waiting for DNS propagation as an error is sensible, but DNS had propagated in this case, so something else was being waited on, and that should be made clear so that the real underlying problem can actually be fixed.

Hmm. Checked /home/yellowtent/platformdata/logs/box.log, and I notice that even with manual DNS set up, upsertDnsRecords seems to be reporting some stuff.. Changed to no-op, and then things seem fine..

I'm trying to do something a bit different/custom.. I have a service that I don't want to publically expose. So I've installed tailscaled on the cloudron machine.

I've set up a custom wildcard subdomain A record to point to the tailscale IP for the cloudron node. I've also set the domain up in cloudron to use self-signed certs. Now I'm trying to modify an app to have an alternative redirect here, and it's hanging on "Configuring - Waiting for propagation" on the new subdomain..

I'm 100% sure that the record has propagated, because nslookup on the cloudron machine can resolve it, I'm resolving it elsewhere, I've done my homework..

So I'm not quite sure why it's still hanging, or where I need to look to find logs for what might be going wrong here?

Seconded, also interested in this for the tailscale angle

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

Also, now I think of it, Cloudron's disk is separate from the backup disk altogether..

Hmm, disk wasn't full though, just not big enough to hold the backup. And on Cloudron itself, the notification had the right info

On v8.0.6, I ran out of space for backups. I got email notifications about it (good), but the email body was empty. It might be nice to give a reason for the failure there so I know how much to panic about it (or not)

Subject of the mail was: "[Cloudron] Failed to backup"

Possibly relevant: https://community.home-assistant.io/t/sonos-no-sonos-devices-found-on-the-network/205049

First things first, thanks so much. I've wanted to play with HASS for a long time, but never really felt comfortable with running it myself, because it's quite... involved

I've set it up, and things seem to work remarkably well so far, with one exception. I tried to add a Sonos integration, but it doesn't seem to be able to find my system.

The documentation (over at https://www.home-assistant.io/integrations/sonos/) has a mention of Docker networking specifically, so I wonder if this might be something that needs some more tweaking/customisation in Cloudron.

I tried allowing port 1400 via ports.json, but so far, without success... Maybe there's some more firewalling blocking things (i.e. mDNS reply or something like that), not yet sure.

Just opening a thread so it's tracked, anyway, I'll update if I figure anything out.

@joseph Right, I get that. I got the option to update all my other installs a while ago, but the weird thing is that I didn't for this one, and I still can't see a way to update this one anywhere that works. I don't care what the PHP version is (I don't even use PHP), I'd just like to keep it current.

I have a few different LAMP installs. Today, I noticed (because one of them has a different, older icon) that one of them is running an older package version for some reason. Automatic updates are enabled (but obviously not working), and manually checking for updates doesn't seem to do anything either.

Is there some way I can fix this without migrating everything over to a new app install?

Old app details:

Package Version
lamp.cloudronapp.php73@2.0.0-1
Installed At
09/11/2020
Last Updated
Never

A sample from a newer one:

Package Version
lamp.cloudronapp.php74@4.0.0-1
Installed At
02/10/2021
Last Updated
07/29/2024

Aha, you were right actually.. Noticed some other quirks around DNS (most noticeably, it was repeatedly failing when I was ssh'd in). Turns out that unbound isn't very happy when something else above it hijacks DNS traffic (which I'm doing to filter our junk).

Quick fix for now was to add a forward-zone to unbound, but I wonder what the right way to handle - and detect - this is...

Yeah, it's green. I was fiddling with switch config a few days ago which I think was the cause in this case.

I noticed at some point an app I don't use very often failed to update. I noticed this because it wasn't running, and was in error state. In the repair section of settings, I saw this:

The update operation failed with the following error:

Network Error: Network error downloading icon : getaddrinfo EAI_AGAIN api.cloudron.io

My guess is that I had a network outage at some point at just the wrong time while the app was trying to update, and this then caused it to hang in that error state permanently.

Perhaps this sort of transient failure should (automatically) schedule a retry later on?

@girish yeah, well, since when has following the rules ever been fun?

I would guess that they say that because if your actions misbehave, or want to, they can interfere with the running gitea instance, so yeah, a separate host would be nice. but I don't know if cloudron has the ability to provision multiple containers for a single app?

tried to play with it a bit. enabled actions in the ini, as documented here:

https://blog.gitea.io/2022/12/feature-preview-gitea-actions/

installed a runner binary from the link here:

https://gitea.com/gitea/act_runner (just to try get up and running quicker..)

placed it into /tmp/ on the gitea container, chmod +x, ran it. could successfully register the runner.

actually executing actions seems to fail, because by default, it wants a docker connection. looks like this can be hacked out if one builds a runner by hand:

https://github.com/nektos/act/blob/636c8a34aedf9b6251df6729fe673d828f972030/pkg/container/docker_stub.go

... obviously, at the price of having no docker available to the actions, which mean some won't work.

but the docker hurdle aside, this is so easy to set up it that it might be worth exploring as part of the app's package..

looks really exciting, if it works well

@nebulon said in OpenHAB not starting after installation:

gosu cloudron:cloudron /app/code/runtime/bin/karaf daemon

Weird.. When I ran /app/pkg/start.sh in recovery mode, I got this:

==> Ensure directories
==> Changing ownership
==> Starting OpenHAB
Killed

When I started the last command by hand, it actually seemed to run okay (at least, no output, and it didn't get killed...

I had a hunch that maybe it was getting OOM killed, and sure enough, I raised the memory allocation to 512m, and it now seems to start successfully, so maybe the default allocation (256m I think it was?) is just a little too low to start, sometimes?