These apps serve different purposes, so I don't think one can really answer the question without knowing the use-case.

My suggestion is if you only care about webmail, then Rainloop wins. It's quicker, nicer interface (IMO), intuitive, etc. If you however also want to manage a calendar and contacts, then SOGo is likely the better one as Rainloop does mail and contacts only, no calendar or anything like that. And even for contacts, it's differently managed - Rainloop simply stores them, but SOGo "hosts" them so they're also accessible via CardDAV protocols into apps like Contacts on macOS or iOS, Calendar on macOS, etc.

Basically, Rainloop is a webmail client whereas SOGo is what's called "groupware" as it will sync contacts, calendars, tasks, etc. in addition to the mail client role.

If you elaborate on your use-case, then people can probably give you a more accurate answer. Hopefully the above helps in the meantime.

I just realized from comments on a different thread that you now have yearly/annual pricing which is a generous discount per month. I may have missed the announcement of those pricing changes, not sure when that came into effect but I appreciate it.

As a Canadian who ends up paying even more than the listed price due to currency conversion between USD and CAD, I am very thankful for the chance to have that discount by paying for a year in advance. Of course one has to have the means to be able to justify a year up-front, but I can definitely see myself using this for a year or more at least.

As a result, I have changed my plan from monthly to yearly, and I just wanted to say thank you. This brings down my total cost of ownership (TCO) by quite a bit. This takes me down from roughly $40 CDN to $20 CDN, saving me $20 a month, or $240 over the course of the year.

Anyways, ultimately I really just wanted to say thank you, and hopefully let others know about this too in case it helps them. This was a pleasant surprise to see.

Reference: https://cloudron.io/pricing.html

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

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 and CalDAV server to use as an alternative to Radicale, SOGo, and Nextcloud.

A good one I have seen recommended often is "sabre/dav". It's also updated more often than Radicale too from what I can tell. I think this would be a great addition for those people who want a more pure CalDAV and CardDAV server.

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

Hello,

I was just thinking as I have about 30 apps now running on my Cloudron (many are just WordPress, not 30 different apps, lol), that it'd be great to see quickly without having to go into each individual app that those which I want auto backups are enabled and those I want disabled are in fact disabled.

Having a list somewhere would be great. I was thinking it'd be very useful perhaps adding a section on the Backup page that calls out any apps that are currently set to be disabled in auto-backups, so that anyone who's about to go in and do a manual backup for the whole system can see at a glance which apps may not be included or are otherwise disabled for backups.

Would anyone else find this useful? Is it possible something like this can be added to the Backup page in Cloudron?

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.

@girish Ah, that's interesting. That isn't documented anywhere that I could find, so that wasn't known. Yes, 3 weeks sounds about right - the "a month" was more figurative as it was close. Unfortunately I can't say for certain now as the backups were failing due to disk space so I had to remove the old backups - this is how I came to learn of this discrepancy between my understanding of how retention time works and what was happening in my system.

Is this something we can customize by any chance? It's a great idea, I like that you're doing it for keeping backups when a package version change happens, because you're right - people usually don't see any smaller issues until a while later. I just wonder if it could be an option to overwrite it all for people who may not have a lot of disk space to spare. May be useful to expose that in the GUI.

On a related side note: One thing I've come to learn through using Cloudron the past 8 months or so is that there is a lot of stuff missing from the documentation that we only find out about later in the forum. I actually am the rare oddball who likes to write up documentation to help others (this is part of my day job), so I'm happy to help contribute these types of updates if you have a list or backlog of items that need to make it into the documentation. If there's anything I can offer on that side of things, I'd love to help so it improves the docs for everyone and hopefully prevents these types of issues from consuming your time.

Peertube apparently now has an LDAP ability now too. Saw this today: https://framagit.org/framasoft/peertube/official-plugins/-/tree/master/peertube-plugin-auth-ldap

@nebulon I think the app icons themselves should be left alone. Looking great!

Okay, it seems it's working now with a new instance of Radicale. No idea why the 409 Conflict happened in the first place though. Here's what I have learned, for anyone who comes across this in the future:

• It seems that Radicale does not like multiple hostnames / redirects to the main hostname, and clients connecting to the redirect name causes the 502 Bad Gateway errors.

• If you run into the 409 Conflict, I guess just migrate everything to a new instance, and it somehow resolves it. lol.

Thanks for everyone's help on this!

Another update: Quickly spun up a new Radicale instance at davtest.<domain> and created a new event and then moved it to another calendar on the same instance, and now I get it successfully moved.

Sep 17 10:03:33 [2020-09-17 17:03:33 +0000] [1/Thread-124] [INFO] MOVE response status for '/<username>/87F80099-3192-4C3C-A7E4-C64B864557B1/2BEA501D-3AFF-4DAB-822E-CA90AD276E08.ics' in 0.207 seconds: 201 Created

Next I will try moving in the data from the other calendars from the original Radicale instance via exporting the calendar as an ics file via the macOS Calendar app, import to the new instance, and see if I can then still move events to different calendars.

@nebulon & @girish - Okay, great call on the hostname thing, that was indeed the issue for the 502 Gateway errors. So I think what happened there was I originally had everything on dav.<domain> and that's when I was getting the 409 Conflict messages originally reported back on August 17th. But then in troubleshooting I tried migrating everything to a new Radicale instance and at that time decided to also use some extra locations such as calendars.<domain> and contacts.<domain> to make things a little more user friendly. Turns out that was what caused the 502 Bad Gateway.

Now that I re-added my account in Calendars app on macOS to be only looking at the original dav.<domain>, I am back at square one with the 409 Conflict error in the logs.

Sep 17 09:53:01 [2020-09-17 16:53:01 +0000] [1/Thread-7226] [INFO] MOVE response status for '/<username>/<CalendarName>/2BEA501D-3AFF-4DAB-822E-CA90AD276E08.ics' in 0.219 seconds: 409 Conflict

Any ideas? Unfortunately we're sort of back at square one still, as I can't migrate from one calendar to another.

I think my next task will be to create a new Radicale instance then with only one address, then start creating some new entries from scratch and see if the issue still occurs or not. If not, then I'll try to migrate in my ics exports and see if the issue then comes back, because if it does then perhaps that may point to some possible corruption in the data I have? I'll report back when I test this out.

@nebulon I don't believe I have, I think I've added additional domains though. Basically the subdomain for the Radicale instance is "dav" and to my knowledge always has been. However more recently I added in a couple of additional locations like "calendars" and "contacts", etc.

I think what I'll try next is deploy a fresh Radicale instance but specifically only with one location, and making sure the Calendar app uses that one alone and see if I can reproduce it. I had tried before but I think I had also added in additional domains again, so I'll try again with just one, because maybe that's related to the host name check in the Radicale code?

@girish Okay perfect, this worked, thank you so much! Quick question though, I assume this is expected but it just surprised me so wanted to double-check... the files inside of the /home/yellowtent/platformdata/backup/ directory was mostly owned by root:root, is that correct? I assumed it'd mostly be owned by yellowtent:yellowtent, the only file I saw owned by that user and group was the snapshot-info.json file.

@girish ah yes I did. That’ll be it then. I’m just out at the moment but will try this later tonight. Thanks for letting me know so quickly. I suggest we may want to add this to the documentation (unless it’s there and I missed it, lol). I can try to submit a pull request in git too for that to help out.

What is with the one released today (2.0.5-1) that's a different package number than the one above? Is it safe to update to it?

Hi guys,

Would like a sanity check please. I was running out of disk space often lately on my ext4 hard disk for backups, and so today decided to go in and remove them all and basically start fresh.

I expected that the next rsync backup would then be longer and take a lot more space up since it's the "first one", but it only consumes about 2 GB of space which seems way too small when the emails are over 18 GB total alone.

I'd have expected the first backup to be about 20 GB, especially since it's rsync and not tarball. Am I missing something? Is something wrong with the backups after I removed all directories on the ext4 hard disk dedicated to backups?

Seems the HTTP_HOST value is set too in the proxy according to the docs: https://github.com/Kozea/Radicale/blob/9d25cc6c0ae6fa72bd6c57b76cbd25f1fddedbc0/DOCUMENTATION.md
I assume it's using that set in the nginx reverse proxy in it's comparison logic for the MOVE command? Though still doesn't necessarily explain why it works for you guys though, as I assume that same value would be set anyways, it's the hostname of the app after all, isn't it?

@nebulon & @girish - very interesting. According to the Radicale GitHub it's been an issue for others before and sometimes fixed and sometimes needing the proxy to be modified.

One thing worth mentioning in case this is an issue, though it is released now (or will be very soon so this will be an issue down the road perhaps) is I was running macOS 11 (i.e. the latest one released for September 2020 called Big Sur, running on their public beta builds earlier). So maybe there's something different now in how their Calendar app handles changes to calendars - no longer doing a DELETE+ADD but a MOVE now - although it's odd because it wasn't an issue earlier in the beta builds and I think either way they're still doing it correctly (just maybe different) as a MOVE method is a valid command to Radicale. Though this may explain why it works for you and not me, as we're running different macOS versions.

You may be on to something though about that part of the code in their GitHub project with "to_url.netloc != environ["HTTP_HOST"]". Never seen that before and it's never been an issue before to my knowledge. Any ideas where that might be stored though? Is that something I need to change in my environment or is that more of an app thing? I was able to reproduce it before on a brand new Radicale deployment, so I assume this isn't something I have control over?