@girish It's also quicker to do from Cloudron at times depending on the VPS host as well. For example I'm hosted currently at OVH and it's not the nicest control panel, not super mobile friendly either and takes me about 6 clicks to get to the reboot option. Cloudron is only about 2 (login > System).

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.

As Radicale isn't the most RFC-compliant (they even state that's not their goal), it'd be nice to have a more compliant CardDAV or CalDAV server to use as an alternative to Radicale, and one good one I have heard about is "sabre/dav". It's also updated more often than Radicale too from what I can tell.

https://sabre.io/dav/
https://github.com/sabre-io/dav

Version 1.4.2 is what's currently published on Cloudron, but the developers of Roundcube released version 1.4.3 back on February 19, 2020 (25 days ago). Usually it seems apps are only a day or two out-of-date if even that on Cloudron, but Roundcube seems to be out-of-date a few times now for extended periods. Would it be possible to get 1.4.3 pushed this week?

On a similar note, how could I help contribute to keep Roundcube updated when new releases are available on their GitHub repository? If there's anything I can do (keep in mind I'm a very beginner programmer and only tested a couple of custom apps in my Cloudron for packing them), I'd love to help in a way other than just posting when it's out-of-date for extended periods of time.

Dustin.

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

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

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

@necrevistonnezr According to the demo, the disk has moved to the System page (which honestly this memory graph should too IMO, it's system info, don't need a dedicated page for just memory and disk usage IMO).

Hello,

It seems when using encryption and rsync for backing up Cloudron (this particular configuration is new to my environment), I get an error message with "ENAMETOOLONG", suggesting the file path or name of the file is too long.

The exact error in my case is as follows:

ENAMETOOLONG: name too long, open '/cloudron-backups/snapshot/app_6b96bd5a-0f84-43aa-8558-7544ec25b19e/36gHI-IuCvvayKXxGPRB1Q/ounM2diChi8DjI1Q3dzMDQ/gGJEz0QgDgsR3jo4XlgYXA/lqAVjQcV8mH8VRRpjjOr1g/kJEwyjEtwqB7Sx2f6L-GUw/fu1zv6VH8LxelOLxe0ub0bgswf82VC21bSpaTxbYSq8fHBlOMRamME-qppekZ+OAzSVbZVxrDKhuYkwdDOLWxWGnFX3QZMFdo0l1mjw54vs-piviwM4PIThP9VIlXwl8ngYif83b3MCNO5lyxmQedqOPbjeVBsJOCzttwAqHl04ys1iTlQIrQMY1d2+adF15nNzZONfL4l-Y8S6TnwAySPkhvBLZY8khSMjI6KcZ-8SO8y1ML-NIM3uyj3MtKVsW

How can this type of event be worked around / resolved? In other words, since the filenames are encrypted too I'm not sure which file this references so I don't think I can even try to work around it by editing the file name before it's encrypted. And if it only too long because of it's encrypted value, versus if it wasn't encrypted? If so, I wonder if the encryption can be improved to avoid lengthy file names?

This of course works fine with encrypted tgz method, just not encrypted rsync.

Any help would be appreciated.

Update: I have temporarily worked around this by mounting as CIFS instead of NFS, however I had heard NFS can be more performant so that is why I had chosen NFS. Not sure where the root cause, doubting it's Cloudron but reporting this in case anyone else comes across similar issues with NFS drives particularly if hosted by OVH. CIFS should work instead of NFS in this case.

Hello,

I have recently moved away from DigitalOcean Spaces to try and use an included dedicated backup volume for my VPS at OVH.

The volume is mounted as /cloudron-backups via NFS and I can create files in there. However, the backup task in Cloudron fails after a minute or so with the following error:

Unable to chown:EPERM: operation not permitted, chown '/cloudron-backups/snapshot/app_27179da8-f406-4df2-b367-6f4a6f28f58a/Oi6VqOX2W580nitJHGQaRw

Any ideas what would cause that? If it's a restriction I need to get OVH to lift, what do I ask them for exactly? Just trying to see if this is an application issue or if there's a workaround (I assume it's not an application issue), and if it's an provider issue then what do I actually ask them for if they can make changes? Just the ability to chown? And what is Cloudron trying to chown with exactly, is it just trying to chown to yellowtent:yellowtent?

@yusf It also has a recipe function which is kind of neat. It will tell you what you can make based on your inventory. I could see some people just using this for inventory and some for just recipes. Reference: https://en.demo.grocy.info/recipes

Hello,

It seems I ran into a defect on removing tags. Had a few tags I wanted to remove from a few apps, and anytime I went to remove a tag I couldn't save any changes so the tags remained. In other words, the Save button doesn't enable itself for saving the changes when a change is made in the tagging feature of the app.

I was able to work around this by removing the tags, then adding and removing a space from the Label field, then the Save button was enabled and I was able to save the changes.

This is on version 5.0.4.

Dustin.

@girish I'm always amazed at how quick you guys on these things, thanks for fixing that so soon!

@girish Correct. I updated my comment earlier, I think we published at the same time. haha. That needs to be fixed though still, as it is not expected behaviour. For example, I would not expect Cloudron to use my Password Recovery email address for anything other than recovering my password. It should use the primary email address for everything else.

@girish I just saw my email provided by my employer used in the logs for contact information. So I suppose the good news is this isn't exposed externally, but it still means any messages from Let's Encrypt will go to my work email and not the email I want it to go to.

My statement in the original post was incorrect then I just realized as I sort of wrote it in a way that meant the email was exposed on the certificate and it is not actually on the certificate. Updated statement for clarification: The email address used by Cloudron on certificates is not actually on the certificate, in other words it is not external facing information. However, I believe it is used by Let's Encrypt for communication so internally it may not be the right email that's desired for communication with Let's Encrypt.

@girish Ah okay, perfect, yeah I think that should be changed to just the primary email address, or maybe break it out to be it's own option/field in the configuration of Cloudron by an admin user. I guess in the meantime the workaround is for me to change that Password Recovery email address temporarily, delete all certs, renew them so they use the new email, then set the Password recovery email address back again.

Hello,

I just realized the Password Recovery email on my profile is what appears to be used in the email contact on the certificates that Cloudron retrieves from Let's Encrypt. Unfortunately in my case my recovery email is my employer's email rather than my own.

I suppose I can fix this by changing my password recovery email to match my actual email but it's hosted on Cloudron so if I ever had a password issue I'd lose access.

This seems like a defect. Can anyone please confirm? Maybe I'm doing something wrong?