Cloudron Forum

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

@LoudLemur also already packaged as community app
If you don’t check before posting, you risk becoming a bot posting slop

@LoudLemur “just packaged it” - seems a decade ago in my butterfly mind
I don’t think it was as hard as your summary suggests
The hard work is in populating the content and framework docs. I didn’t have a use case for it so I didn’t get into that.
The packaging code is there if you want to clone and develop further - my project list is a little full but will bear this in mind if I need a diversion

@James thank you
I had not initially intended to use CloudronVersions in this way, but it is a real time saver.

Yep, once an app is published, probably no trimming (unless very old revoked versions).

The new Community App functionality is a real bonus, so thanks once more to the Cloudron team for implementing it.

The app update functionality provided (new entry in CloudronVersions.json) really helps with the build cycle, testing changes etc., without time-consuming repeat setup of app environment etc, before it even gets to a MVP release stage.

However that does result in a quite big CloudronVersion.json - on one app in dev, it is 60kb. Not a problem as such. But I wonder if we really need to keep such a big history of the app's dev cycle, 0.0.1, 0.0.2 etc all the way up to say 1.0.0 and beyond. Especially when the older entries become redundant by being explicitly revoked or by representing early prototyping with breaking changes.

I have tested just trimming CloudronVersions.json, removing early entries. It seems to have no ill effects providing the json structure is honoured. So my intention is to prune the versions file of dev release before an app becomes released.

So in terms of managing CloudronVersions.json, I'm interested in Cloudron team's thoughts or any advice.
Maybe you did not expect the functionality to be used like, so did not expect a large versions file. But I can easily see it growing to to 200k in some cases. Not a problem technically, but nevertheless ...

Simple solution : change 'Uninstall' to 'Manage' or 'Stop/Uninstall' or '....'

The column width longest label is 'Access Control' so providing the new label is <= to that, UI works.

Still a little unsure about this.
If the Garage app is storing large volumes, say 5Gb, is backup by tarball appropriate, do we want to be facilitating that ?
That said, I guess it still needs fixing for smaller tarballs.