What's coming in 5.6

[d19dotca]

@girish Definitely looking forward to the first two mail features in particular!

Is it possible to expand on the "Keep mail backups separate from box backups" part? Is the intention here to restore just mail alone instead of needing to restore the whole server to restore mail? If so - that'd be awesome! Haven't needed that yet but I can imagine a few scenarios where that may happen in the future and make recovery much easier.

Keep up the hard work! Great job you guys!

[girish]

@d19dotca Yes, the idea is to be able to independently backup and restore the mail stuff and also be able to set a location to it, just like any other app. Just like we have app_ and box in backups, idea is now we will have a mail_ in the backups directory (currently, it is in box/mail).

[d19dotca]

@girish Perfect! That’s what I was hoping to see. This new release will check off a bunch of requests I and others made, very happy with this.

[girish]

A progress update on the release.

• VAAPI (hardware transcoding on linux) support work well now. I had posted an update here - https://forum.cloudron.io/topic/3035/transcoding-update

• Lots of activity on the email side:
  

• You can set the mail server location:
  

• Adjust the max message size:
  

• Adjust spam configuration:
  

• We have decided against separating the mail and box backups for this release. There's some complications to do this properly (the mailbox and domain information is currently in the box code, we have to move this to the mail container. it's quite a bit of work and we feel this feature is not important at this point to justify the surgery).

• Cloudron will not auto-update to pre-release version if you simply just checked for an update.

• Scheduler: if you have a bunch of WP apps (especially unmanaged WP), you will see a lot of networking churn in dmesg and docker logs output. We have seen in a couple of customers who have over 100 WP installations, docker gets into some strange deadlock (iptables locking). To circumvent this, the cron job scheduler has been re-designed now so as to not create a new container for every cron run and also shares the networking namespace of the app container. This change requires no changes to apps.

• Allow box auto update pattern to be configurable. The update schedule that in the Settings UI now applies to both the app and platform auto updates (previously, it only applied to app auto updates). This gives you more control on when the updates happen.
  

Phew, already changes are piling up, so will probably have to drop some of the planned features.

[Mallewax]

@girish Still hoping for this one to make it into Cloudron eventually...:=-)

https://hub.docker.com/_/solr

[girish]

@Mallewax Yes, I have added it in our 6.0 list now - https://forum.cloudron.io/topic/2760/what-s-coming-in-6-0 . In fact, I just moved to a new device and search not working reasonably is a bummer.

[marcusquinn]

Nice work on the Mail server side of things!

Being able to set mail server subdomains to the more commonly used mail. will be a bonus.

Thunderbird checks common subdomains as a second resort, although the extra DNS records for the standard autoconfig stuff would be better for more clients to autodetect.

I'm hoping that will help with email client auto-setups but anything you can do to also add the necessary records would be super handy:

• https://forum.cloudron.io/topic/1816/email-autoconfig-for-autoconfiguration-example-via-thunderbird/5
• https://forum.cloudron.io/topic/1296/add-dns-dav-registring/4

[girish]

Yeah, I would love to get the autoconfig functional in this release. I haven't gotten to that yet, and will probably need help of everyone to test auto-detection in variety of clients.

[Mallewax]

@girish Love it....:-) Thank you for your consideration!

[Mallewax]

@girish Maybe this is of help, too....

https://workaround.org/ispmail/buster/mail-client-auto-configuration/

[girish]

We now have server side signatures as well. These can be set per-domain:

I have also made some good progress with NC and WP optimizations. I will make a separate post for that.

[girish]

@doodlemania2 It turns out collecting network information for each container is quite complicated. It's easy to collect the stats at a point in time (like docker stats does) but to do it over a time period, requires us to periodically track the container/process. I put some notes here - https://git.cloudron.io/cloudron/box/-/issues/734 . I have to postpone that task since it's quite complicated. If someone has better technical knowledge on this, please do leave a note on gitlab.

[doodlemania2]

Thanks for the update good sir!

[d19dotca]

Any ETA on 5.6? Can't wait for these mail improvements.

[girish]

@d19dotca It's getting here, a couple of things left. Hopefully late next week

[girish]

For the email auto-configuration, for now I will just add docs on how to set this up manually. It's a bit complicated to automatically set all this up because outlooks requires SRV records (for which we have to write automation code for the DNS providers) and thunderbird/k9 requires setup of .well-known files. This has the same issue as mastodon where we can automate only the website is also on Cloudron. So, for now, I will put docs on how anyone can set this up manually.

[will]

@girish Can Cloudron not write to the "well-known" folder on the host?

I was thinking matrix could be a switch in the admin panel.

[girish]

@will It can but it only works when the domain's web server is hosted on Cloudron. For example, cloudron.io website is hosted on a different server than cloudron.io email. The well-known has to be added on whichever server is hosting the website and not the email server.

[will]

@girish I would guess that most people have everything they can on cloudron, is that the reality in the field?

[marcusquinn]

@will I see what @girish is saying:

• One Cloudron managed server has Email hosted with it's various subdomains
• Another (maybe Cloudron managed) server has the root website domain.
• So the .well-known file needs hosting on the root domain server.

I've been thinking a fair amount recently about whether to www. the main website or not.

Originally, I though, who still types www.?

But, that misses the ability to manage it as just another subdomain, and have the main root domain 301 redirect to www..

Reasons for having www.? Well, this use-case could be one. CNAME load-balancing could be another.

I'm thinking that Google does www. for their main domain and many other big players do too, so maybe they are right and my non-www. thinking for succinct brevity was missing some of these other possibilities that using www. enables.

Might be an SEO risk changing large websites and potentially messing up the 301 redirects for all indexed URLs but I'm having a serious think about going back to www. given those using it probably know more than I do as to why it might be better.