Can you describe the use-case a bit further? Cloudron already collects logs for each application and addon, as well as the Cloudron related platform components. Generally it is not supported to install other daemons on the side of Cloudron on the same server, since we cannot test such configurations during updates.
FYI all the logs are collected currently as described here https://cloudron.io/documentation/troubleshooting/#logs
It seems the apps started out initially just federating with instances of themselves. When this was the case, they used webfinger for discovering accounts and information about an account. All the apps are just using @username@installation_domain (and not root domain). Peertube has no setting like LOCAL_DOMAIN - https://github.com/Chocobozzz/PeerTube/blob/develop/config/production.yaml.example#L6 . Same for pixel fed - https://github.com/pixelfed/pixelfed/blob/dev/.env.example#L7 . I guess nobody has gotten to the point of having the same @username@rootdomain to be used across apps. This makes sense because the apps don't really talk to each other apart from providing an activitypub stream. Think of it as each of those document editors supporting MSXML. None of them could load each others stuff in the very early days.
In essence, the correct approach for Cloudron for now is to not let LOCAL_DOMAIN be configurable in mastodon. It's just confusing that it even exists without the surrounding standards to support it across apps.
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.
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?
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 😉
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!
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.