If this is disabled or archived, this also means that it is still "known" to the system, currently the data simply is not removed from the disk, but other relevant information is purged from the database.
So I agree, that deleting an account should also delete the mailbox data, if there is no proper way to restore that (currently you have to create a new mailbox record with the same mailbox handle and magically the data comes back). For that some archived state could be the solution to have a structured way to restore.
@d19dotca I guess that depends exactly on what you want to use the cloudron cli for. A workflow could look like the following:
change/update version of a package in the app
commit the change to git (you could edit and commit directly in e.g. gitea or gitlab)
this automatically triggers the ci platform
this one could do some verification
create the updated docker image
deploy it to your cloudron
The simples form of this could be a post-commit hook in your git hosting tool.
@nebulon For sure, yeah I figured it may need more interest before it's implemented, and realistically I'm probably the only Cloudron user who's hosting on LunaNode (though I'd love to know if others are too), as I think LunaNode is a nice hidden gem that's not overly used yet and I switched to them recently as I had heard great things and their pricing is pretty good. Brief recommendation at the bottom for anyone interested. I'll let them know too about Cloudron in case they can do anything to help out too. 👍
On the topic of DNS at LunaNode though... it seems pretty awesome from what I can tell, as it has integrated load balancing and failover which is perfect and works with their included monitoring feature too (which is like Uptime Robot but provided by LunaNode), and so if my monitor fails and I have a second DNS entry, it'll automatically remove the failed one from the DNS records temporarily until it's back online, giving only the backup DNS entry for the "hot standby" server. Hoping to take advantage of those features in the not too distant future if it's feasible for me to run a second "hot standby" server. Waiting on Cloudron to add in some functionality to clustering which I think is coming in v6. 😉 Once that's there, I hope to be able to do that. Nudge nudge. haha.
🗣 Brief recommendation based on my initial tests so far for other Cloudron users who want a good inexpensive hosting provider: I recently moved my Cloudron server from OVH to LunaNode to test out their performance, and the exact same Cloudron server in OVH used to take 10 minutes to fully come online after a reboot in OVH, and having restored that same server in LunaNode it now takes only 2-3 minutes to fully come online. That's also with some memory-intensive applications like Mastodon and NodeBB (which are always the last two to start in my environment given their resource usage). Same 8 GB nodes between OVH and LunaNode too. This performance improvement now cuts my downtime after reboots for security updates by almost 75%! That's my brief recommendation for LunaNode. haha.
@murgero (you probably know this but just writing it out for the wider audience)...
Cloudron was primarily made to install and manage pre-packaged apps. This meant that addons were defined by the package and we don't want end users to make difficult decisions as to what database to use and what caching backend to use. Lesser choices cover 90% of the use cases.
But over time, we saw a lot of demand about custom apps. And thus LAMP app and even allowing custom packages. And now we probably also need dynamic addons (ie. select which database post installation or just before installation). While this is doable, this moves Cloudron more and more into PaaS territory. My initial instinct is that it's fine to venture into this space and maybe cover 90% of the use cases but we have to think through it 🙂
This is possible but will increase complexity in deploys and maintenance. I have also noticed that MySQL changes things between patch releases a lot. Maybe because their release numbers don't follow semver .
@girish yes, that’s a much better idea. Essentially the ability to “swap” app instances, or in other words the ability to easily promote from staging app instance to production app instance on the same server. That’d be ideal. 🙂
Yeah, email ids don't go via LDAP. Email ids and aliases are restricted because in other email systems people can use _, - and + as subaddress. Cloudron only supports + right now but might extend it to - and _.
@nebulon IIRC, the _ restriction comes when we had 1-1 mapping between username and email. Maybe it's not relevant anymore. I am more open in allowing it in usernames than mailbox names.
When it comes to an "open source" filter, I think the open code based makes more sense, rather than looking at all add-ons or price. We are talking about filters on Cloudron App Store, therefore think the question is, "is the app actually installed from cloudron app store opened of closed?", not any add-ons people may choose to install later on.
Other options could be to have:
a Free Software filter for program without any proprietary add-ons
a "close sourced" filter for apps where the code of the base app is not available (i.e. that app actually installed from the app store)
a $ filter for program that require a paid license
Mainly I think we should NOT conflate price/money and license type / openness of source case. Take Teamspeak, for e.g., it can be used for free, on a free (as in free beer) license, yet it is proprietary software.
I think that whatever filter option we choose, the openness of the code that is actually being installed from the Cloudron App Store (i.e. without add-ons) is the thing that users should be made aware of / able to easily choose from. So as a first implementation of any filter, I thing the open/closed source filter would be the priority.