What's coming in Cloudron 6.3
-
@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.
This one is implemented now in the Email view. The app package has to explicitly say whether it supports this feature or not using the
optionalflag to thesendmailaddon.
I'm waiting like gold for this update, especially because Cloudron Mail is changing Mautic email configuration all time.
The Amazon SES-API and queue configuration that I have within Mautic is misconfigured every time the application restarts, updates, recovers ... it's frustrating.
-
New browser login locations is implemented. This is only for dashboard logins and not for LDAP login (because many apps send mails by themselves).
-
New browser login locations is implemented. This is only for dashboard logins and not for LDAP login (because many apps send mails by themselves).
-
@girish said in What's coming in Cloudron 6.3:
This is only for dashboard logins
Since this already covers the dashboard, is it automatically available for apps using proxyauth as well?
-
@fbartels we could do that for the auth proxy as well, but right now it is not. For other apps using LDAP this will be a bit harder since the ldap server currently does not see the upstream user-agent or IP.
@nebulon ah, I kind of thought that the proxyauth would use the very same mechanisms of the dashboard for authentication. But the dashboard being mainly driven by an api with token authentication that of course does not have to be true.
Totally understand that the same is not possible for apps that use ldap under the surface.
-
@girish said in What's coming in Cloudron 6.3:
As a pre-requisite for Cloudron 7 multi-host feature, we have to move file system data into the database. Much grunt work to be done here.
A big chunk of this landed today. Certificates also need to be migrated to the database, that should be done tomorrow. Essentially, from the next release,
/home/yellowtent/boxdatawill only contain mail server data and nothing else since everything has moved to the database. I will probably take this opportunity to separate box backups and mail backups. The box backup is going to be just the mysql dump and nothing else. -
Before Cloudron 7, we need some more work to make the single server install secure. For this reason, we will spend some time first with the following:
- (Security) - Inform users about new browser/IP logins.
(Security) - Better email monitoring/visibility for admins. @d19dotca raised many important posts and there's also existing ones. We have to read the posts in more detail and discuss internally before we give more details on what we plan to do here.(moved to next release)(Security) - Add a way to secure/limit access to specific apps and dashboard. For example, a set of apps are public and the rest are only accessible via wireguard/openvpn. This combined with mandatory 2FA for dashboard will make good security.(moved to next release)- Reduce/remove some notifications. It seems a bit noisy.
- Fix email situation for Go apps like Statping, Commento that are having trouble sending mails via our email server.
- 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
Move TURN server to port 443.(moved to next release)- As a pre-requisite for Cloudron 7 multi-host feature, we have to move file system data into the database. Much grunt work to be done here.
- Vultr DNS
- Vultr Object Storage
@girish said in What's coming in Cloudron 6.3:
As a pre-requisite for Cloudron 7 multi-host feature, we have to move file system data into the database. Much grunt work to be done here.
This is now done! Now the boxdata only contains the mysqldump and email.
root@my:/home/yellowtent/boxdata# ls -l total 900 -rw-r--r-- 1 yellowtent yellowtent 913492 May 7 06:00 box.mysqldump drwxr-xr-x 9 yellowtent yellowtent 4096 May 4 07:34 mailI am looking into moving mail as a separate backup just like an app. That way in future releases we can restore mail data (mailboxes) independently of box code just like apps.
-
-
Before Cloudron 7, we need some more work to make the single server install secure. For this reason, we will spend some time first with the following:
- (Security) - Inform users about new browser/IP logins.
(Security) - Better email monitoring/visibility for admins. @d19dotca raised many important posts and there's also existing ones. We have to read the posts in more detail and discuss internally before we give more details on what we plan to do here.(moved to next release)(Security) - Add a way to secure/limit access to specific apps and dashboard. For example, a set of apps are public and the rest are only accessible via wireguard/openvpn. This combined with mandatory 2FA for dashboard will make good security.(moved to next release)- Reduce/remove some notifications. It seems a bit noisy.
- Fix email situation for Go apps like Statping, Commento that are having trouble sending mails via our email server.
- 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
Move TURN server to port 443.(moved to next release)- As a pre-requisite for Cloudron 7 multi-host feature, we have to move file system data into the database. Much grunt work to be done here.
- Vultr DNS
- Vultr Object Storage
@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.
-
@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.
@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?
-
@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?
@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 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.
@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 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?
-
We now show the ubuntu version is the settings view.
Additionally, there is now an alert for Ubuntu 16 users.
-
We now show the ubuntu version is the settings view.
Additionally, there is now an alert for Ubuntu 16 users.
-
This looks wonderful! Loving this QoL changes.
-
We now show the ubuntu version is the settings view.
Additionally, there is now an alert for Ubuntu 16 users.
@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! 
--
Dustin Dauncey
www.d19.ca -
@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! @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 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.
@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?
--
Dustin Dauncey
www.d19.ca -
@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?
@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?
