Cloudron Forum

@james good points, thank you.

Honestly … I didn’t check for 9.1.7, lost too much time getting stable operations again, didn’t want to risk further. I will get brave and do it when a process slot appears.

Revoke 9.1.6 : Yes, maybe knee-jerk overkill, but it’s undeniably broken (not Cloudron fault I accept) in a fairly fundamental way for a possibly/probably large number of users. However if 9.1.7 is out and reliable, then users have a path forward. If they know about it.

That’s where the Urgent Advisory Notice is relevant : please check if you’re on kernel xxxx, we have detected incompatibility of 9.1.6 with that, you can fix by 9.1.7 which is available now.

I didn’t choose to deploy 9.1.6, it happened on a reboot and I was left with a broken system. An Advisory would have shortened restoration of full functionality.

FWIW. I have just run into the issue.
Broke connectivity to my cloudron-installed forgejo
Fixed using the patch after losing 4 hours to checking it was not something I did.

IMHO :

• EITHER 9.1.6.should be pulled
• OR 9.1.7 should be accelerated
• AND some kind of a clearer higher profile URGENT ADVISORY should be issued for people to check if uname shows 110

I may have missed such an announcement, but I assume this affects quite a number of Cloudron users, so it should be addressed.

Probably a stupid perception issue but backups on patched 9.1.6 seem slower. Working but much slower than before. Will keep an eye on it and try to get some metrics (to rule out user perception).
Seems that rysnc location (hetzner Storage Box) needed remounting. No idea why, but seeks ok now. Watching.

@James thank you, will check it out and report back

And again (or so it seems).

Custom App under active development, resulting in frequent additions to CloudronVersions.json and growing file size (~2000 lines).
Update fails
Trimmed old versions content so file is now ~200 lines, just the initial 0.0.1 version and the latest versions.
Update starts working again.

Maybe it is some local weirdness (my problem), so would be good to know if others see similar issues when CloudronVersions.json grows large, and if Cloudron team have encountered this.

Small update : although fearful of breaking my production Cloudron, I installed the Netbird client on the box (via command line outside the Cloudron environment - sorry Cloudron team).
Did netbird up -m <separate VPS running management server> -k <netbird key>.
Worked flawlessly.
On management server, added my Cooudron netbird peer into my private network.
Now apps on Cloudron can reach my laptop, and vice versa, via private network.

Specifically a Cloudron app can use Ollama on my laptop running a private model to benefit from Mac Silicon "nearly-gpu-like" performance.
My Cloudron Ollama can't properly run the model because it is CPU only.
Cloudron Ollama running local model on CPU runs at ~6 tokens, or lower.
Mac Ollama private local model achieves ~40 tokens/second.
Not as good as on-demand GPU instance at 80-150 t/s or running an ollama:cloud model also at 80-150 t/s (model dependent).
But 40 t/s is not too shabby and and is viable performance without the cost of an always-on or on-demand GPU.

So getting Netbird management server on Cloudron would definitely be a good thing. Shall try to pick that up shortly.

@marcusquinn you know what, I'd forgotten that I had started looking at this ! Goldfish ! Might have a look this weekend.

I also like Netbird, I have a server running on a non-Cloudron VPS, connecting devices to each other when needed, and making an in-house box available to selected people in external organisations.

"Netbird on Cloudron" can mean :

• use an app on Cloudron to act as 'server'
• install the Netbird client at Cloudron VPS command line (not an app - outside of Cloudron platform), so Cloudron box is on the Netbird network, but no Cloudron app needed. I'd tend towards this if it viable, but my network routing knowledge is poor.

Are peeps here thinking about it a different way ?

@James fair point .... but still stupid IMHO. Especially as it worked perfectly well in 3Gb until recent updates. Not much time to research an alternative just now so will live with it. Simply because I'm lucky enough to have 128Gb RAM on my Cloudron VPS .... but I didn't spec it that way to be wasted on Umami.

Stupidly big for an app of this nature.
I’m replacing it if 8Gb is needed.

I get similar to @ruihildt despite the OOM fix by @James

@LoudLemur thanks - will look into it

@james thank you, I appreciate you looking into and resolving it

Appreciate that mail is the focus of 9.2, but maybe you can sneak in a minor enhancement to Notifications :
From :
'Grafana at grafana.appx.uk updated to package version 2.5.1'
To :
'UPDATED Grafana at grafana.appx.uk to package version 2.5.1'
Speeds user review of notifications

Cloudron Team : I am not clear whether cloudron 3.24.0 used a different upstream base 3.1.0 to previous, but my impression is not. So the issue is in cloudron v3.24.0 ? Can it be fixed ?

Never had a problem with Umami before.
I had it set at 2Gb RAM which is a healthy amount for this kind of app (even maybe high).
Auto-upgrade to Cloudron v3.24.0 immediately brought repeat OOM
Increased it - reluctantly - to 3Gb.
Still crashing.

Checked redid for umami - running at 15% (40/256) - restarted it anyway.

Now umami is not responding.

Anyone else seeing this ?
Don't see any relevant GitHub issues for upstream 3.1.0

@LoudLemur well done, sounds like you have had fun (!).

I'm not clear. You mentioned your production system - is that your own build or using my ALPHA community app ? Or you already cloned/fixed mine ?

If the latter, I can try to make changes as you describe. But I am in the middle of a couple of big projects, so it won't be immediate.

If timing is an issue, you might want to clone/fix and publish your own repo/community app.

I thought I was imagining it, but fairly certain that I am not.

• Working on an app using CloudronVersions to publish, suddenly the app would not update in the Cloudron dashboard.
• CloudronVersions.json is ~1600 lines long, from 0.0.1 to 0.7.5, jumping a few so about 60 versions
• on last update CloudronVersions.json "lost" versions 0.7.2, 0.7.3 and 0.7.4 (and who knows what from earlier in the chain), so app running last version 0.7.4 would not find/recognise 0.7.5 as an upgrade
• fixed by deleting versions 0.0.1 through 0.7.0 to shrink the file, copying 0.7.1 to 0.7.4 and manually editing values
• app then says 'oooo, I see I am on 0.7.4 and found 0.7.4', and allows me to upgrade to latest 0.7.5
• my build cycle is automated, I never touch CloudronVersions.json

Maybe lazy layman's diagnosis : some CLI bug in cloudron versions add loses content in Versions while adding a new one. Triggered by length limit or buffer constraint ?

Not a problem as such, as I now know how to fix it.
Surfacing this in case others come across it, maybe Cloudron team can check it when no other pressing tasks.

@scooke didn't Andreas make it into a community app ?

@LoudLemur of course, your decision. I don't it needed killing, it could be a useful tool, just not auto-post or bulk-post its findings.

Packaged