This was required as part of another feature - making it possible to restore Cloudron without updating DNS (https://git.cloudron.io/cloudron/box/-/issues/737). Currently, it is not at a domain level but at a global level (can always add it later).
I think in theory we could isolate app containers to access only a specific db by restricting based on IP (which MySQL supports). MySQL already has an IP based rate limit for logins, this is why we haven't implemented it. Meaning, an app trying to guess another app's db credentials won't get very far.
@girish said in Proposal: The CUR - Cloudron User Repository:
App packages listed on the current App Store are all open source
Confluence is not open source.
I should have been clearer... I meant the packaging source code itself is opensource (i.e the docker file and the tests) but not the apps themselves. We actually many apps that are not open source - emby, teamspeak, the minecraft apps, the pre-installed smtp plugin in WP (was not opensource, but i have switched it to an open one now), probably forgetting more.
Oh, and it may require like 4 or 5 patches to box code. Forgot about that. 😅It's fully functional tho, a little unpolished, a lot unpolished. But everything works. @girish and I will work together to integrate it properly at some point after 6.0. My patches run at "start" time, so the fact they're inefficient isn't too big of a deal, but just know that somewhere down the line, @girish and I will add it properly into a stable version of Cloudron.
What an accomplishment this was for me back then. I like that my first post in the forums is this crazy hellscape of Cloudron and Docker development jargon. I also wonder if this will ever help anyone down the road. Either way, I'm glad this whole thing is archived, it's p nostalgic for me. ☺️
@nebulon Sure, tags are nice for filtering. I just thing those 3 specific tags could be labels for better visual review scrolling the whole list. Also, bear in mind they should be "OR" labels, so maybe it is a separate field to tags?
@girish Oops, I realized just now, that I didn't reply to your question yet. What I changed and maybe has to be protected from being accidentally overwritten is the 'datadirectory' option in /app/data/config/config.php. I changed that path from the default path to '/media/mymountpoint'.
I don't remember if I had Nextcloud in maintenance mode or put the app in recovery mode, while I changed that path and moved the files. But it was either of them. However, I had some duplicate storage paths in the database afterwards and I manually updated the oc_storages table as described here and did a files:scan afterwards. But that should not be related to what the code for updates overwrites, I guess.
I recall we had an idea of remote listing of the backups in the storage and showing a UI to restore apps from the backups. Essentially, we need a "import UI" over existing backups.
So, maybe in the Backups UI, we have a way to view the remote backups (shouldn't use our backup table but do remote listing), click on a backup and we should be able to restore. User is then insulated from app package version, app id and all those complications.
@cbeams I agree it's great for testing. FWIW, One can already do cloudron install --appstore-id firstname.lastname@example.org to install any package. Also, Cloudron only supports rolling updates, which means that version numbers are mostly just an implementation detail for us and ideally the user should now know about it.
@atrilahiji also, just having per-app setting would enable to do eg. Nextcloud using rsync and other apps using tar which I'd really like to be able to do (and has been previously requested and was even included in a "what's coming in Cloudron X" post but then never actually made it in).
Seems like more of a build toolchain thing, which would sort of put it up to those of us packaging apps and/or perhaps the build service to pick up as a feature. Intriguing, but strikes me as high-effort for middling (at best) reward at first blush.