Happy New Year everybody!

Just learned how to deploy a custom app using Bitwarden as the test, but seeing as it should be delivered soon, figured I'd wait for the more official release. So on that note... is there any ETA yet for this app @girish or @nebulon by any chance? If it's going to be a month or two I may start with the custom app, but figured if it'd be just another week or two (or just less than a month), then I'll just wait it out.

Thanks again for all the work you guys do - including everyone else in this thread, as I was able to learn a lot from reviewing everything you all wrote!

Just curious how others organize their Cloudron "My Apps" dashboard. Do you use the labels feature much or just descriptive app URLs to keep them organized? Do you bother with tags? And if you use tags, what are some examples you do to solve problems?

I currently have about 20 apps deployed across roughly 12 domains, and am not having too much difficulty yet with organization but I can imagine a year or two down the road (if I'm still using Cloudron which I assume I will be for now) I may run into issues keeping everything straight in the Dashboard, so figured I'd see what problems people have run into and what they've done to solve them when it comes to organizing their apps.

Any ETA for when 4.2 will be released? Or is it too early to tell yet?

@will This is definitely a discussion and not a support issue. Is something broken in Cloudron? No? Then it’s not a support issue.

I would love to see this project be usable on something like CentOS, but that’s really more because I’m just more experience with CentOS than I am with Ubuntu, not so much for the privacy concerns you raise.

Cloudron simply requires the OS be Ubuntu, it doesn’t require that Ubuntu telemetry be enabled. You’re welcome to disable it all before installing Cloudron and Cloudron will continue to work as its intended to work. You are the admin, you need to maintain your Ubuntu configuration to match your needs. If you require telemetry be disabled, then simply disable it.

If your concern is more the fact that Ubuntu collects telemetry “by default”, well... everyone using Cloudron is likely familiar and technical enough to be comfortable tweaking systems and ensuring that the defaults are actually what they desire and changing anything that isn’t matching their expectations. The same as how one goes through Settings on iOS periodically to make sure everything is as they want it.

If you are THAT concerned about the telemetry data being collected on Ubuntu by default, then simply don’t use the software that requires Ubuntu until it reaches a point where it can support other operating systems too. The team at Cloudron is small, moving to support an entirely different operating system is no small/trivial task, so even if they decided today to move to CentOS it’s probably going to be at least half a year of effort if not much longer than that to be fully matured on CentOS.

Ultimately it’s worthwhile to always consider “risk vs reward” and what data is actually being collected that constitutes a “risk to user privacy”. Personally I don’t care if the company behind Ubuntu knows the resource usage and uptime of my server. That isn’t a “privacy risk” in my opinion because that aren’t actually collecting any user generated data, they’re collecting statistics in that case. However it would be a completely different story if they were also copying over user filesystem data which would contain my emails and website data, client data, passwords, etc.

In summary:

• the suggestion to move to something like CentOS I fully support, I’d love to see that be done.
• in the meantime, you need to make a decision: use Cloudron on an OS you apparently don’t trust, or delay using Cloudron until it supports an OS that you trust.
• if you choose to go with using it still for now on Ubuntu, simply disable the telemetry data collection in Ubuntu to better meet your expectations/use-case.
• this is a discussion not a support case since Cloudron is not broken nor having any issues. Cloudron does not require Ubuntu telemetry be enabled in order to work. Also, it is always up for discussion on how much of an impact the concern you raised impacts people and everyone is going to have a differing opinion on it as to how it will impact them. Just because you may greatly care about one thing doesn’t mean others will care as much as you do nor even care at all.
• gathering telemetry (whether at the OS level or application level) does not automatically equate to “spying”, it all depends on how that data is being used and what benefits may come from it, IMO. And this is my point, others will agree with this and others will disagree. That’s why it’s a discussion.

@murgero You're right, it'd likely be less of a burden if moving just to Debian. My comment however was made explicitly stating CentOS as the target OS rather than Debian (that would be my preference only as I'm more experienced with it, but Debian works too).

Maybe as an alternative to the "open source" filter idea, it could be filtered on if it needs a paid license to run the program as-is? Of course there are always paid support options and paid add-ons/features, but as long as the base product which ships as-is requires a license or doesn't require a license, it'd be good to know that so people don't deploy Confluence for example assuming they can use it like most of the other apps for free and then realize they need to pay for it.

But assuming we go with the "open source" filter idea, my two cents to address the concern from @luckow is that as long as the base project/app has it's source code available, then it's tagged as open source. Because paid add-ons and paid support plans for the app doesn't diminish the open source nature of the original base project. Right? Maybe I'm missing something but it seems to me it'd be something fairly simple like that where we only look at the base project. Add-ons that aren't open source doesn't necessarily "void" the open source nature of the base project/app.

I was going to write a blog post on this one day but here is a quick summary of what I found in moving roughly 12 WordPress sites to the WordPress app in Cloudron...

1. Use the All-In-One WP Migration plugin (https://wordpress.org/plugins/all-in-one-wp-migration/) to export the site, being sure to check the boxes in advanced section that say "Do not export must-use plugins" (if you don't do this it will overwrite the must-used plugins for LDAP authentication in the Cloudron implementation of WordPress)

2. Setup a new base WordPress site in Cloudron, and add in the same All-In-One WP Migration plugin. Now import the site file that was created in step one above.

3. After it's done importing, restart the WordPress site in Cloudron so that it can re-connect it's must-use plugins (initially I find access is lost to the main LDAP admin user until a restart).

4. Once in using your LDAP admin user, remove any old admin user and replace with the new one if you wish, and clean-up any unnecessary plugins and themes that are there by default.

Not only did I find this to be the quickest method but also the safest in terms of not losing anything at all. When I tried the Cloudron blog method it just seemed like a lot of extra work for me. But maybe that's because most of the sites I've designed aren't simple blogs, so maybe their method is still better for simple blog sites.

Enjoy.

Hello,

I noticed recently (likely a bug I'm guessing as it seems to only started in the latest version) that the Graphs page only seems to show a few apps memory usage. It used to show every app broken out in the chart, but it seems to randomly only show anywheres now from 2-6 or so at a time in my experience over the last week. It seems to be different on reboot of the server. For reference, I have 19 apps that are running on this same (and only) server. So I'd expect to see all of them in that graph/chart.

Any assistance would be greatly appreciated.

I think I have stumbled across a bug or possibly more of a missing security workflow that should definitely exist.

I had tried enabling and then later disabling the SSH "support access" function from the Support page in my Cloudron server. When I later went to the Event Log page, I noticed that function enable/disable was never displayed in the table on the Event Log page.

I'm unsure if this is a bug or something that just was overlooked in the design, but I'm sure you'd agree that something as critical as enabling or disabling remote SSH access to a server containing a lot of data should most definitely be properly logged and shown on the Event Log page too.

I recently had to change a mailbox owner to a different user, and realized that I hope that's logged somewhere in the system in case there's any issues after a recent change it'd be easy to audit for both functional and security reasons. But I realized the Event Log does not audit such an event. I strongly believe changing ownership of a mailbox should definitely be included in the Event Log feature due to the impact it can have security-wise.

Thoughts on that? Hopefully that's something easy to implement and not too much work for the Cloudron team. Hate giving you more to do, haha, I just think this one is an important thing to be included in the Event Log.

@heliostatic Coincidentally GoatCounter was requested here just last week: https://forum.cloudron.io/topic/2091/goat-counter

@girish You're always so quick! haha Thank you so much!

I recently had to change a mailbox owner to a different user, and realized that I hope that's logged somewhere in the system in case there's any issues after a recent change it'd be easy to audit for both functional and security reasons. But I realized the Event Log does not audit such an event. I strongly believe changing ownership of a mailbox should definitely be included in the Event Log feature due to the impact it can have security-wise.

Thoughts on that? Hopefully that's something easy to implement and not too much work for the Cloudron team. Hate giving you more to do, haha, I just think this one is an important thing to be included in the Event Log.

Hello,

Not sure if this should be under Support or Discussion, but I noticed that Roundcube is sitting at version 1.3.9 and hasn't been updated for a while. Roundcube project is currently at 1.4.2 (https://roundcube.net/download/).

Is there any ETA on when 1.4.2 will be released in Cloudron's app store?

Dustin.

Maybe as an alternative to the "open source" filter idea, it could be filtered on if it needs a paid license to run the program as-is? Of course there are always paid support options and paid add-ons/features, but as long as the base product which ships as-is requires a license or doesn't require a license, it'd be good to know that so people don't deploy Confluence for example assuming they can use it like most of the other apps for free and then realize they need to pay for it.

But assuming we go with the "open source" filter idea, my two cents to address the concern from @luckow is that as long as the base project/app has it's source code available, then it's tagged as open source. Because paid add-ons and paid support plans for the app doesn't diminish the open source nature of the original base project. Right? Maybe I'm missing something but it seems to me it'd be something fairly simple like that where we only look at the base project. Add-ons that aren't open source doesn't necessarily "void" the open source nature of the base project/app.

@girish Yes I think that clarifies then. Thank you for explaining it. I thought from your earlier post you meant that all LDAP users registered on the Cloudron server would automatically be invited to use Bitwarden and I was worried there for a second. haha. My experience is what you explained most recently in that the invite needs to be manually done through the Bitwarden admin area.

@girish Do all users on the system automatically get invited? I didn't see that in my experience when I deployed the same app the other day, I had to manually invite myself through the /admin panel. I'm going to be a bit embarrassed if all my clients on the server got an email invite without me knowing

Happy New Year everybody!

Just learned how to deploy a custom app using Bitwarden as the test, but seeing as it should be delivered soon, figured I'd wait for the more official release. So on that note... is there any ETA yet for this app @girish or @nebulon by any chance? If it's going to be a month or two I may start with the custom app, but figured if it'd be just another week or two (or just less than a month), then I'll just wait it out.

Thanks again for all the work you guys do - including everyone else in this thread, as I was able to learn a lot from reviewing everything you all wrote!

@murgero You're right, it'd likely be less of a burden if moving just to Debian. My comment however was made explicitly stating CentOS as the target OS rather than Debian (that would be my preference only as I'm more experienced with it, but Debian works too).

@will This is definitely a discussion and not a support issue. Is something broken in Cloudron? No? Then it’s not a support issue.

I would love to see this project be usable on something like CentOS, but that’s really more because I’m just more experience with CentOS than I am with Ubuntu, not so much for the privacy concerns you raise.

Cloudron simply requires the OS be Ubuntu, it doesn’t require that Ubuntu telemetry be enabled. You’re welcome to disable it all before installing Cloudron and Cloudron will continue to work as its intended to work. You are the admin, you need to maintain your Ubuntu configuration to match your needs. If you require telemetry be disabled, then simply disable it.

If your concern is more the fact that Ubuntu collects telemetry “by default”, well... everyone using Cloudron is likely familiar and technical enough to be comfortable tweaking systems and ensuring that the defaults are actually what they desire and changing anything that isn’t matching their expectations. The same as how one goes through Settings on iOS periodically to make sure everything is as they want it.

If you are THAT concerned about the telemetry data being collected on Ubuntu by default, then simply don’t use the software that requires Ubuntu until it reaches a point where it can support other operating systems too. The team at Cloudron is small, moving to support an entirely different operating system is no small/trivial task, so even if they decided today to move to CentOS it’s probably going to be at least half a year of effort if not much longer than that to be fully matured on CentOS.

Ultimately it’s worthwhile to always consider “risk vs reward” and what data is actually being collected that constitutes a “risk to user privacy”. Personally I don’t care if the company behind Ubuntu knows the resource usage and uptime of my server. That isn’t a “privacy risk” in my opinion because that aren’t actually collecting any user generated data, they’re collecting statistics in that case. However it would be a completely different story if they were also copying over user filesystem data which would contain my emails and website data, client data, passwords, etc.

In summary:

• the suggestion to move to something like CentOS I fully support, I’d love to see that be done.
• in the meantime, you need to make a decision: use Cloudron on an OS you apparently don’t trust, or delay using Cloudron until it supports an OS that you trust.
• if you choose to go with using it still for now on Ubuntu, simply disable the telemetry data collection in Ubuntu to better meet your expectations/use-case.
• this is a discussion not a support case since Cloudron is not broken nor having any issues. Cloudron does not require Ubuntu telemetry be enabled in order to work. Also, it is always up for discussion on how much of an impact the concern you raised impacts people and everyone is going to have a differing opinion on it as to how it will impact them. Just because you may greatly care about one thing doesn’t mean others will care as much as you do nor even care at all.
• gathering telemetry (whether at the OS level or application level) does not automatically equate to “spying”, it all depends on how that data is being used and what benefits may come from it, IMO. And this is my point, others will agree with this and others will disagree. That’s why it’s a discussion.