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

Aye, probably better to have a ui in box to enable/disable and whitelist domains. I don't have a corporate customer waiting for that, I just thought I left the suggestion here for the future, maybe it could be added when something else in that department is touched. 😉

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

@MooCloud_Matt Correct. The feature request could almost go in two different directions (or be two different phases), in my view.

Direction #1: Able to add specific third-party app packages (whether it's from someone you trust or your own packages). This is similar to what I had requested previously here too in another post: https://forum.cloudron.io/topic/2878/feature-request-add-custom-app-to-app-store-for-local-cloudron?_=1598410841843

Direction #2: Able to add a whole third-party "App Store". This is similar to how Portainer does it, where it reads a JSON file which defines all the stacks that run apps like WordPress (where it requires both a WordPress container and a MySQL container). Of course this method for Portainer works a bit easier because it's just deploying standard Docker containers (often just from the publisher themselves) rather than needing a custom package manifest, etc. I also linked to the Portainer documentation on Templates earlier too: https://portainer.readthedocs.io/en/stable/templates.html

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"

@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

We now have mandatory 2FA in Cloudron 5.4

Implemented in 5.4

This was implemented in 5.2.