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

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!

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

@girish said in How about a Cloudron meet-up in Berlin in 2021?:

Yes! We did it when Kopano meet was getting packaged

Perfect! I'd join if it was online then. Would love to visit Germany someday, but being "at risk" (cystic fibrosis) I ain't travelling out of Canada during this pandemic, especially when insurance won't cover anything like that anymore haha

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?

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

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.

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

I see https://git.cloudron.io/cloudron/box/-/blob/master/src/nginxconfig.ejs#L75 has the cipher suites but it's for Nginx, is that same list used for the Cloudron mail server outbound?

To my surprise, Fortinet's "fortimail" server isn't quite as secure as it should be when it comes to the certificate and server set... according to https://www.ssllabs.com/ssltest/analyze.html?d=gw6158.fortimail.com

It seems to support all TLS versions though and many ciphers. Is it possible there's a rare incompatibility here though? I'm not sure how to determine that in Cloudron to know what ciphers are used during negotiation.

Running into an issue with one particular mail server for a recipient. My emails aren't arriving at all. I see the following in the logs when it tries to send my message:

2020-11-24T01:21:09.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Looking up A records for: gw6158.fortimail.com
2020-11-24T01:21:09.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Attempting to deliver to: 173.243.136.158:25 (0) (8)
2020-11-24T01:21:10.000Z [ERROR] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Ongoing connection failed to 173.243.136.158:25 : Error: Client network socket disconnected before secure TLS connection was established
2020-11-24T01:21:10.000Z [INFO] [528A8DBB-ECC3-43B8-8D2E-DC65014EC9C5.1.1] [outbound] Temp failing 1606179904597_1606180869126_4_87_95hV7K_3760_88af3024f7bc for 1024 seconds: Tried all MXs

So it tries later and basically is in a loop as it can't succeed. It seems like the backend isn't even responding, but their mail server is definitely working because another client working with alongside (but not at) this other company is receiving mail just fine. Also other mail is being sent and received successfully to other recipients across all sorts of domains. This makes me think it's an issue with their mail server but they seem to have no trouble receiving from anyone else, so I can't quite narrow this down where the issue is.

I think this is unlikely to be a Cloudron issue, but wanted to raise it here in case anyone else has come across this and in case this is some sort of TLS-type compatibility issue. I'm usually pretty good at troubleshooting email issues but this one I can't quite figure out and it's also a bit time-sensitive in nature unfortunately.

I kind of want to say this is a TLS-based issue where the backend requires a certain TLS protocol version which isn't supported / being used from Cloudron server, that's usually where I see "Client network socket disconnected before secure TLS connection was established" with regards to other HTTP services anyways, just never seen it in SMTP before.

Any ideas on the above?

@necrevistonnezr said in After multiple changes to a file on Surfer via WebDAV, further connections timeout with ETIMEDOUT:

If a shop doesn't offer it, I don't use it.

gasp you... you don't use... Netflix or Amazon Prime? haha

lol Yeah I hear ya, I use Apple Pay wherever I can, but being in Canada there's not a lot of Canadian business online that use Apple Pay yet. Thankfully many in-person payments can be done over Apple Pay though, but just not really online yet. I mostly am forced to use US-based companies for things like Netflix and Amazon Prime - neither of which accept Apple Pay or even PayPal in Canada at least. But hey, McDonald's just started taking Apple Pay through their app in Canada. So we're slowly getting there. hahaha

I'd love to see more businesses adopt those services though, it's way more secure and solves that problem of what happens when a credit card is compromised, and much more.

@mehdi said in Ability to modify server name used for SFTP access to avoid use of Cloudron's my.<domain>.<tld>:

the prompt that everybody confirms without even reading

haha, so true. Yeah I got a pop-up that was like "This is a new key" or something and just accepted it. Basically the same kind of message that happens with SSH. I just have certificate-based SSH though where it needs my key to even connect (i.e. you couldn't connect to my server over SSH without it), so I was surprised I didn't need that on my SFTP connection, thought I'd maybe need something similar. But I guess this makes sense then the more I think about it. Just caught me off guard. haha.

Actually I just ran some more tests and found out that a CNAME record isn't even needed. Since my DNS records for the domains I manage are wildcard (i.e. no A records for individual services, but is just the * and @ DNS records to the IP address), it seems I can actually throw in anything I want. So I tested for example whatever.<domain>.ca and still put in the username and password and it was accepted by the SFTP server.

This is interesting as I expected it'd only respond to my.<domain>.<tld> but I suppose that isn't the correct understanding because if it were a CNAME record all it'd be doing anyways is looking up the associated A record and hitting the IP.

I think this works because the lack of certs needed for the handshake. This is strange to me though... am I understanding the above correctly?

I had a moment to test it out so just tried and yes the CNAME workaround seems to work well.

Thank you, guys! Didn't expect that to work because of SSL but didn't realize they didn't really require certs on those connections. Yet somehow it's still the more secure connection type, haha. I think I'm going to have to do a little learning on that one later.

I think it'd still be nice to be able to configure the SFTP server name from within Cloudron, but this CNAME workaround will do the trick for now. Thanks again.

CNAME might work - I can try that, good suggestion - a little unsure that'll work for me as I don't have any wildcard certs (they're per hostname) which would then throw a mismatch, however if you're saying SFTP doesn't require certs then I suppose that may be a moot point and should work. I'll try this later today.

I noticed recently as I am looking to setup an FTP server for a client (using the Surfer app if I can) that in the Access Control tab, the server name they'd have to connect to is the my.<domain>.<tld>, which is personally something I don't really want clients seeing (which was also why I had requested the mail server being accessible from another subdomain which works now in the recent versions).

I'd like to request that there be a way to change the server they access to the domain of the client. So something like sftp.example.com instead of my.cloudron.com (for example). Even if it was still mandated to be something like sftp as the subdomain if it makes it easier to code, it'd at least remove the weird-sounding my subdomain which makes no logical sense to other users.

There may be a technical reason that it's not done that way, not too sure, but wanted to at least request it if that was possible. I assume there can be redirects created for the SFTP functionality if implemented, right?

@yusf I had learned from Girish a little while back that some are kept for particular circumstances. So for example I believe when an app package is updated, it keeps that backup longer than the usual retention policy if I remember correctly, same for Cloudron version changes too. Which is why there are folders that are dated beyond the retention policy. I'm sure Girish can explain better and correct anything I may have gotten wrong, but hopefully that helps explain why you have older ones in there beyond the 1 week retention policy you set.

Edit: I just realized Girish noted this too above on this thread. He linked to this which gives a few "exceptions" to the retention policies: https://docs.cloudron.io/backups/#retention-clean-up