@girish I think the key point here is that simplelogin is self-hostable! https://github.com/simple-login/app#self-hosting So we can have this cake and eat it too! I'll add it to the app request list here.

I've added a task in gitlab for this now at https://git.cloudron.io/cloudron/box/-/issues/738

@nebulon anything here - https://bitwarden.com/help/article/website-icons/ ?

Thank you for the quick reply. But even in my testing environment, telling me my backup method is unsafe once a day is just a hassle to weed them out of the Cloudron update (valuable) notifications. I bet I can just trick Ubuntu into seeing the path as a volume to get rid of the notification. But for normal Cloudron users, I bet an option to acknowledge and disable the “backup is unsafe notification” would be valuable for them especially in their first non-production use of Cloudron (where I’m personally at for now).

I guess some webhook api could be supported. It is a bit of work though and lets first see if this feature is also relevant to more people.

@rmdes I think from a user point of view it just needs to work with either, they don't really care as long as typing results in what they were hoping for. From a Sys Admin point of view, www. is more flexible for scaling and high-availability setups. As an example, if you use Odoo enterprise, it must be www. for the websites.

To add to what @nebulon said, https://cloudron.io/documentation/api/#tag/Services/paths/~1services~1{service}~1logs/get is for the addon logs and https://cloudron.io/documentation/api/#tag/Tasks/paths/~1tasks~1{taskId}~1logs/get for task logs.

This is a good idea. I've added it and it will be part of the next release.

it is much better now !! [image: 1598707309146-80a17127-6013-4785-97ca-0433750b3ec8-image.png]

Just leaving a note to myself here . memcached has mechanism for doing auth easily which makes it hard to make it an addon. There is some complicated SASL based auth setup.

Sorry @marcusquinn dident see that you was using ghost for your blog. in that case, SP_mod will be really a bad choose because front-end and back-end are separate similar on how angular/react works. I really advice you do optimize your image manually for now, and w8 ghost will release some improvement on that.

@marcusquinn Great summary! I've similarly found that ingress transaction costs are more than my monthly storage costs with rsync option and tar zip backups keep timing out. @girish Thanks for adding the additional advanced backup configuration in 5.5! I've tried increasing it for my backups and am excited to see if it helps.

@d19dotca I have added some docs now. https://cloudron.io/documentation/backups/#schedule has info on the timeout and nice. https://cloudron.io/documentation/backups/#concurrency-settings on the concurrency settings.

Yeah, I was hoping to get a picture of the storage used by a user or usergroup across all apps on Cloudron. Apart from companies or single user installs of Cloudron, the thinking was that enabling groups of people to share a server and switch to self hosted open source software would involve having insight into the main variable resource - the storage - in order for the cost sharing to be transparent. I understand that's it's not feasible to implement, so will need to think of other community models for resource sharing. Mounting a users own NFS storage is an option, but Cloudron apps are restricted to a single storage location per app instance. Perhaps users mounting their own external storage in an app like Nextcloud is an option. Any thoughts on a clean model for this kind of resource sharing scenario? This seems to me an important consideration for "regular" users of Cloudron, who might want to get together in order to make switching over from Google etc. financially viable.

This seemed trivial to add, so I fixed it for next release. Thanks for the suggestion!

@Hillside502 embarrassing, yeah I accidentally posted here thinking it was the wishlist. I’m on mobile and can’t see a way to move the topic over... @girish, can an admin do that?

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