@girish said in I believe in Cloudron's mission 200%. How can I help?: what the issue is here sometimes warning are only to warn you such as asking you to take a look, often if you able to explain why it's like that and it sound reasonable from a security perspective it's fine. The grub and kernel issues (which are the bulk of it) are outside the scope of Cloudron especially on a VPS. I also don't applied all recommendation because it restrain too much the instance such as an example it will be impossible to login as root from the console unless you reboot at the level 1

@iamthefij Well the you can make it so you're not discoverable unless you message the person. Thats pretty anonymous

Thanks for reaching out, sounds like a very interesting conference. I will send you a mail to get in touch. Best, Johannes

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

@nebulon said in Other pricing model for small installation: dev license and for the dev license, it is one dev license per server/installation ?

Our subscriptions are per Cloudron instance, so per server. We might add multihost or some kind of cluster feature in the future, but so far there was no strong focus on this yet.

@nebulon said in Do the Cloudron MailServer have a TRACKER_ID ?: thunderbird plugins installed? you got me, I forgot my mailhop plugin ;s

OK, I did another round of searching for answers.. I understood a lot from these two posts - https://schub.wtf/blog/2018/02/01/activitypub-one-protocol-to-rule-them-all.html and https://schub.wtf/blog/2019/01/13/activitypub-final-thoughts-one-year-later.html (from one person behind diaspora). 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.

Thanks, I have added both to 4.5 roadmap

wow that’s way more than cool! i’m gradually discovering the magic of Cloudron. Loving it!

Great news! Than I can install on my small server. Have a nice evening

@jdaviescoates You are welcome to suggest merge requests to https://git.cloudron.io/cloudron/docs if you have lots of minor changes (and it feels painful to open a forum thread/suggestion).

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!