In the past, I think people have recommended integrating with netdata. I don't have experience with netdata but wanted to throw the idea out there. Other than that, current graphs is rendered using data collected by graphite/carbon.

My point of the 443 port issue was so ya'll could fix the docs. I have manually setup SRV records, that's why I thought it'd be nice to automatically set them up. Also, I meant to put this under discussion, not sure how it ended up in support. Thanks.

BTW: There are now official docker-compose scripts: https://git.tt-rss.org/fox/ttrss-docker-compose

@nebulon said in Feature request: Optionally restrict user profile editing: That sounds like an important use-case indeed and goes into a whole field of more fine-grained control over what users can and cannot do. So far we have tried to not overcomplicate the access control settings, but we are open to small useful adjustments. Given that Cloudron has a special permissions group, the admins and then simply the rest of the other users, would it be sufficient for your use-case to have an admin setting to prevent non-admins from changing their own profile? And if so, what fields should be protected? agreed!!

The dark mode is good but in some conditions.

@msbt said in Piwigo vs. OAuth Login!!: Hey @williamgomes, that error animation is mine and I eventually fixed it, you can find the repo with a working version in this thread. However, a few plugins are not working properly because they use an absolute path (which is non-standard in this environment), which then requires you to manually edit the path in the plugin files to make it work. I haven't updated to piwigo 2.10 yet because I currently don't have an active gallery, but I reckon you could fork it and just replace the version number THX for help!

@necrevistonnezr said in Runcloud.io vs ServerPilot.io vs Cloudron vs Sandstorm: I don't remember this link being there (that you removed) when this topic was opened a few months ago you can see the edit history of a posting. It was only added on the 19th of november at 23:40. Honestly also @KathleenMcArthur feels a bit like a spam bot posting backlinks to earn some referrals.

Hi, I'm very sad to hear that Cloudron core code has become proprietary software. Like @ryangorley, I've always been promoting Cloudron as a great well-supported open source self-hosting option. I too want you guys to succeed but I fail to see a valid reason to turn Cloudron into proprietary software if it is still being developed in the open. My thoughts on the reasons you gave: The technical reason is that the code base has subscription, appstore and sign up logic. It's unclear what the license should be if it requires the cloudron.io service to work. I-am-not-a-lawyer but I'm pretty sure that you can still be under an open source license. I mean, the situation is not "ideal" as an user can't easily self-host without relying on the cloudron.io external service, but anyone is free to create a fork and reimplement these functions. Also, I don't know if it's the case anymore but we used to be able to install cloudron Docker packages built manually without cloudron.io. So in a way, Cloudron was self-hostable, just without the user friendly App Store. The non-technical reason is that we were spending too much time explaining why we call ourselves opensource and charge for it. It should be pretty simple for customers to understand, they are paying for a service of maintenance and support (indirectly funding the development of the core product). That is no different than let's say a WordPress maintenance service to have plugins/themes kept up-to-date by a company. Worse case, if you really want to give proprietary software to some customers, why not dual-license? Contributions would be made under both AGPL and your proprietary license. This way, it's still open source and potential contributors would be a lot more inclined to become involved. Anyway, I wish that a compromise can be found where Cloudron still remain a great open source self-hosting option!

https://git.cloudron.io/cloudron/box/issues/654

Interesting, this was simply missed I guess. I have added it now and it will be part of the next release. It will look like this then: [image: 1572952466019-screenshot_2019-11-05-cloudron.png]

Hi and welcome on board! The warning you are seeing is, because it is never a good idea to store the backups at the very same disk/server. Ideally those should be stored in some other datacenter or such. For Cloudron the backups also are per-app to allow per-app restore if an update failed or something else is broken. This makes the backup service for the whole server not very useful, nevertheless it is still some safety net of course. Ideally you should choose between one of the storage providers we currently support https://cloudron.io/documentation/backups/#storage-providers For your case DigitalOcean Spaces might be a good option.

You guy are are amazing and fast, thank you!

yes, that tag-input component has several other small bugs and we should really replace it. If anyone knows a good angular1 based component to replace it, ideas welcome

This comment was very informative - https://bugs.launchpad.net/ubuntu/+source/ansible/+bug/1833013/comments/6 . I didn't realize you have to pass so many options to make it not ask questions.

Also, note that changing the nameserver sometimes takes a bit of time. So, you might have to wait a bit between step 2 and step 3.

I was unaware of the incremental feature in rsync. That will work for me, thank you!

Looks like it was in fact getting sent to the catchall. Thanks everyone for your input.

@necrevistonnezr Yeah you can click the search icon in the UI, then in the select box, change to "Entire Message" and it searches both the headers, the body, and in some cases attachments as well (in the case of txt attachments I think? I've never had a need for it and no real way to test it) [image: 1566913782769-925fe9c5-e509-4f0a-af70-682114ec4f24-image.png]