What's coming in Cloudron 6.3

[girish]

Pushed a change that makes the filenames of backups more readable. It's just app_<domain>_vVersion.

root@my:/var/backups/2021-05-09-000811-352# ls
app_test.cloudron.work_v1.1.3.tar.gz

[girish]

@girish said in What's coming in Cloudron 6.3:

Volumes - make mounting easier by automating fstab/exports entries

This is also mostly done. When adding a volume, you can choose the mount type

The current volumes are migrated as "no-op" mount type (as in, user managed the mount themselves). It shows the status of each volume as well:

One thing we decided to go with systemd mounts instead of /etc/fstab. This allows us to create mounts that have correct dependency with the unbound DNS server for CIFS and NFS mounts.

A similar mounting change will be done for the Backups view as well.

[jdaviescoates]

@girish said in What's coming in Cloudron 6.3:

One thing we decided to go with systemd mounts instead of /etc/fstab.

So what will happen to existing volumes that are already mounted using /etc/fstab?

[nebulon]

@jdaviescoates I think instead of coming up with migration code, which will be a bit messy given the fstab format to correctly parse in all circumstances, I think we will ignore those and ask the admin to reconfigure the volume via the UI once. That way the admin can test and validate timely.

[jdaviescoates]

@nebulon said in What's coming in Cloudron 6.3:

I think we will ignore those and ask the admin to reconfigure the volume via the UI once. That way the admin can test and validate timely.

Just to be clear, if the admin takes no action will existing volumes keep working?

[nebulon]

@jdaviescoates yes, the code does not touch existing mountpoints as such.

[girish]

We now show the ubuntu version is the settings view.

Additionally, there is now an alert for Ubuntu 16 users.

[micmc]

@girish AWESOME!

[A Former User]

This looks wonderful! Loving this QoL changes.

[d19dotca]

@girish Please tell me 6.3 is coming down the pipe this week. I'm so eager for it! Desperately needing some of these email improvements, specifically the most urgent for me is the ability to not forward email on to mailing lists if it's been identified as spam. The limitations currently are impacting the trust of my mail server by other systems like Gmail which is rate limiting my emails now because so much spam is forwarded on to a couple of Gmail addresses via the mailing list functionality. At least they're not outright blocking me, but that'd be the next logical step that I want to avoid!

[girish]

@d19dotca it's unlikely this week, we just had a call yesterday and decided to release what we have right now. So, we have already started testing and running e2e. I will leave a note on the progress here. I moved the security+email features to the next immediate release. As for the specific issue you are facing wrt not forwarding spam, let me see if the fix for that is easy and include it in this release itself.

[d19dotca]

@girish Oh sure, that'd be good. So there's going to be a bug fix version then I presume with what's already been done so far (such as 6.2.9 maybe or still 6.3.0)? And then email + security will be added to something like 6.4 instead if the next release is still 6.3?

[girish]

@d19dotca what's next is 6.3. the email + security will be 6.4 or maybe even part of cloudron 7. we are actually very close to multi-host with the changes in 6.3 !

BTW, about the spam fix, it's easy to check if an email is marked as spam and drop it (i.e based on spamassassin flags). However, since we don't have a place to quarantine yet, you will only see a eventlog entry that it's gone. Is this OK for the moment till we implement a monitorable mail queue?

[girish]

As a final update to the mounting logic, it is also integrated into backups and restore logic.

[scooke]

@girish said in What's coming in Cloudron 6.3:

Pushed a change that makes the filenames of backups more readable. It's just app_<domain>_vVersion.

root@my:/var/backups/2021-05-09-000811-352# ls
app_test.cloudron.work_v1.1.3.tar.gz

Thank you!!

[d19dotca]

@girish said in What's coming in Cloudron 6.3:

BTW, about the spam fix, it's easy to check if an email is marked as spam and drop it (i.e based on spamassassin flags). However, since we don't have a place to quarantine yet, you will only see a eventlog entry that it's gone. Is this OK for the moment till we implement a monitorable mail queue?

I think that's fine for now, but would it be possible to only affect mailing lists perhaps (assuming this change is mostly just temporary and probably will only really be used by me for the time being). I ask because I think if I were to just drop all messages marked as spam from all mail delivery completely, it'd be a detriment to my hosted mailboxes. The only place I want to disable sending spam mail is for mailing lists alone, if possible. But either way I guess, better than nothing I need to ensure Gmail isn't going to block mail from my server completely just because the two addresses my mailing lists forward to are total magnets for spam.

[subtlecourage]

@girish said in What's coming in Cloudron 6.3:

Make email setup inside apps optional. This will make it possible to configure specific apps to use some external service for mail delivery directly and the Cloudron package won't touch their mail settings.
Volumes - make mounting easier by automating fstab/exports entries

The email feature is something I think will help my use caase.
The volume feature is freaking phenomenal.

You are all amazing!

[girish]

Now that Cloudron is in the Vultr marketplace, it seemed the right time to implement Vultr DNS.

[girish]

The last change remaining in 6.3 was related to notifications and most of it had landed yesterday.

• Common issue is that a notification like a cert failure or restart required etc is essentially spammed to all admins and this causes great distress for all. So, we have now moved notifications from being per-user to be instead "system" level. The notification system is thus shared by the admin team and they can figure how to collaborate with other tools instead of Cloudron trying to have some sort of "read" indicator for each one of them.

• Apart from failed backups and cert renewal failures, no emails are sent anymore. You have to visit the dashboard to see notifications since most of them are really not urgent or actionable.

• Cert renewal notification + email is only raised if only 10 days are left to go for existing certificate to expire. The renewal itself will start 30 days in advance. So, we should see this very rarely from here on. Backup renewal notification will only be sent if 3 consecutive backups fail. This way we allow for "external services" to fail now and then without being too aggressive about notifying user.

There's more notes at https://git.cloudron.io/cloudron/box/-/commit/73917e95c9473ec8fc11216fd78607b0a256df7d . There's other minor visual changes as well, I will post a screenshot tomorrow once I complete the UI side.

[girish]

The going is slow... Having to support 3 ubuntu versions takes a lot of testing time The tests currently pass for ubuntu 18 and 20 but not for 16 yet. But we are close! Looks like failures are related to older versions of unbound not supporting sd_notify correctly.