DirectAdmin 1.702

[bymizah]

Hi all,

Starting from version 1.702, sent email limits now also count local-to-local emails (changelog reference). Previously, emails sent between local accounts on the same server were not counted toward the daily sending limit.

This is causing problems for several of my clients. Many of them have forwarders set up to route incoming mail to other departments within the company (internal forwarding). With this change, all of that internal traffic now counts against the daily limit, which can quickly exhaust the quota even though no mail is actually leaving the server.

My questions:

1. Is there a way to disable this behavior, so that local-to-local emails are excluded from the sent email count again?
2. If not, would it be possible to make this an optional/configurable setting (e.g. a per-domain or server-wide toggle to not count local mail)?

I understand the reasoning behind counting all mail, but for setups that rely heavily on internal forwarding, the previous behavior made much more sense. A configurable option would be ideal so admins can choose based on their use case.

Thanks in advance for any guidance.

 

[aysima]

Thanks @zEitEr. A new build is released with the following changes:

1. RoundCube installer will make sure /var/html/webapps directory have fixed permissions, it used to depend on user umask.
2. Fixed PHP patches order to resolve the conflict with lsapi for PHP 7.4, PHP 8.0 and PHP 8.1

The files.directadmin.com mirror automatically gets new files only a couple of days after release and MariaDB pushed out new versions only yesterday. Anyway we manually uploaded the RPMs for now.

We are also seeing the Roundcube 1.7.0 404 issue on CloudLinux servers.

In our case, the problem seems related to CageFS symlink protection.

Current layout:

/var/www/html/roundcube -> ../webapps/roundcubemail-1.7.0-XXXX/public_html

When CageFS symlink protection is enabled, Roundcube returns 404. When it is disabled, Roundcube works.

We need a solution that keeps CageFS symlink protection enabled and allows Roundcube to work without issues. It should also survive future DirectAdmin / CustomBuild Roundcube updates, so the problem does not return after every update.

Could you please check if the new Roundcube symlink/path layout is fully compatible with CloudLinux CageFS, or suggest the correct permanent configuration?

Environment:
DirectAdmin 1.702
CloudLinux 8
CageFS enabled
LiteSpeed

 

[zEitEr]

When CageFS symlink protection is enabled, Roundcube returns 404. When it is disabled, Roundcube works.

It works fine on CloudLinux 9 and CloudLinux 10. So it might be something CloudLinux 8 specific.

 

[aysima]

It works fine on CloudLinux 9 and CloudLinux 10. So it might be something CloudLinux 8 specific.

We agree that having a workaround for CloudLinux 8 would be useful.

However, following your comment, we upgraded the affected servers from CloudLinux 8 to CloudLinux 9 and tested again. After the upgrade, Roundcube started working correctly with CageFS symlink protection enabled.

So the issue appears to be specific to CloudLinux 8. For now, upgrading to CloudLinux 9 resolves it, but a safe solution/workaround for CloudLinux 8 would still be appreciated for servers that cannot be upgraded immediately.

Thanks again.

 

[zEitEr]

but a safe solution/workaround for CloudLinux 8 would still be appreciated for servers that cannot be upgraded immediately.

Manually rolling back to the previous method of placing of roundcube files under /var/www/html/ solved the issue on CloudLinux 8 for me. Probably directadmin developers will find the root cause of the issue on CloudLinux 8.

 

[fln]

A new build is released. It bumps RoundCube version from 1.7.0 to 1.7.1.

 

[sysdev]

Do we really need to first run a da update on all servers and next do another run for the RC update?

There must be a better way for people with many servers.

 

[fln]

If you have not explicitly disabled the DA auto-updates there is no need to run `da update` command. DA will auto update itself. The only action required is to rebuild RoundCube if you see there are pending CustomBuild updates.

 

[sysdev]

If you have not explicitly disabled the DA auto-updates there is no need to run `da update` command. DA will auto update itself. The only action required is to rebuild RoundCube if you see there are pending CustomBuild updates.

In theory yes, yet sometimes machines take a day or more before I get a mail that a DA system has a new version. And after the update I still have to login and check what is updatable on every machine and click either one or all updates.
And if I see an RC update afterwards I still don't know if this update is about a typo somewhere or a CVE that needs more attention than waiting for da to update itself.

To catch that you actually have to run 'da update' a couple of times a day because da updates might or might not contain apps with CVE's.
A CVE needs fixing yesterday, a typo can wait.

 

[fln]

Yes. That is the reason why we have split out auto-update and auto-patch as two independent options. We would prefer autopatch to be never ever be disabled on the production systems. Administrators should not care at all about the hot-fix releases at all. These updates will never change anything that would require system admin attention.

The only thing system admins should keep an eye on is the system updates and CB updates. If there is a security update for some software component it will popup either in the system updates (it comes from the Debian or RHEL maintainers) or it will popup as CB software update. The CB part could be left on auto-pilot if CB cron task is enabled.