@murgero Yeah, makes sense.

@fair Here's a script to create a user and invite them.

#!/bin/bash set -eu # fill these in cloudron=my.domain.com token=a803859d40c9ec4e111ccb111111111111111111111 # the user to add and invite username=test email=test@cloudron.io displayName="Test User" function urlencode() { # https://unix.stackexchange.com/questions/159253/decoding-url-encoding-percent-encoding python2.7 -c "import sys, urllib as ul; print(ul.quote_plus(sys.argv[1]))" $1 } # add user if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST -d "{ \"email\": \"${email}\", \"username\": \"${username}\", \"displayName\": \"${displayName}\" }" https://${cloudron}/api/v1/users?access_token=${token}); then echo "Failed to add user" exit 1 fi userid=$(echo ${out} | jq -r .id) echo "User added: ${userid}" # create an invite. this does not send the email. if you like you can share the invite link using other channels if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST https://${cloudron}/api/v1/users/${userid}/create_invite?access_token=${token}); then echo "Failed to create invitation" exit 1 fi resetToken=$(echo ${out} | jq -r .resetToken) encodedEmail=$(urlencode "${email}") encodedDisplayName=$(urlencode "${displayName}") echo "reset token: ${resetToken} . URL for user to sign up: https://${cloudron}/setupaccount.html?resetToken=${resetToken}&email=${encodedEmail}&displayName=${encodedDisplayName}&username=${username}&profileLocked=true" # tell cloudron to send the invite by mail. invite links are only valid for a day from when they were created if ! out=$(curl -sS --fail -H 'Content-Type: application/json' -X POST https://${cloudron}/api/v1/users/${userid}/send_invite?access_token=${token}); then echo "Failed to send invitation" exit 1 fi echo "Invitation sent"

@girish I seeeeee 🙂

@marcusquinn said in Cloudron Backups to GitLab/GitHub Private Repos:

Not a high priority - but might be nice for both the really tight and multi-location/provider redundancy aims.

I have to think through the rest but multi-location backups is in our radar. We have a long pending issue about this https://git.cloudron.io/cloudron/box/-/issues/528

@marcusquinn I like the idea of atleast just adding a doc page for the moment on how to do this manually till we implement the feature. I will add it our docs.

This is implemented in 5.4

This is implemented in 5.4

This was implemented in 5.2.

This was added in 5.1

Members only flag was added in 5.2

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.

good points, thanks, gonna switch to cifs then! 🙂

Indeed, currently catch-all has to have the feature to set mailboxes across domains (like aliases).

@jdaviescoates 🙂

@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 .

Good morning,

that sounds acceptable for me.

Have a nice day!

@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. 🙂