DirectAdmin 1.677

fln

fln

Administrator
Staff member
Joined
Aug 30, 2021
Messages
1,158
We are happy to announce the release of DirectAdmin 1.677.

This release brings all the required changes to make DirectAdmin compatible with RHEL 10 systems. RHEL, Rocky and Alma 10 are expected to be released soon. It can only be tested on CentOS 10. Another important change for Enhanced users is the UTF-8 support. The transition might take more than one release, but we will be adding migrations and tools to make this transition for old servers as smooth as possible. This release brings quite a lot of improvements for CustomBuild. The most important change is the new database configuration layout.

A full release change log is here:

DirectAdmin 1.677​

The update should be automatically available for all installations subscribed to the current release channel.

We appreciate all the feedback on forums and issues reported in the ticketing system.

Thanks!
 
Yes. RHEL 10 support is not available for legacy licenses.
 
I updated my DirectAdmin installation to version 1677 on one of our servers and noticed a strange behavior.
A custombuild update appeared for dovecot_conf, which I applied as usual.

The custombuild log returned the following:

Updating dovecot configuration files...
2025/05/19 20:59:01 info executing task task=action=rewrite&value=mail_sni
2025/05/19 20:59:01 info finished task duration=19.03219ms task=action=rewrite&value=mail_sni
Restarting dovecot.
Dovecot configuration files have been updated successfully.
removing /var/www/html/roundcubemail-1.6.10
Click to expand...

However, immediately after this update, access to the webmail (Roundcube) stopped working entirely.
I saw in the changelog that there were several recent changes to Roundcube, so I’d like to know if this situation is expected?

To restore access, I had to run ./build roundcube, which restored the directory and resolved the issue.

Thanks!
 
Thanks for letting us know.

The dovecot configuration rewrite action is not directly related to the Roundcube. However after an action is performed CustomBuild does an old files cleanup routine. The line:

Code: 
removing /var/www/html/roundcubemail-1.6.10

reveals that CustomBuild removed the Roundcube at this stage. Starting this release the detection mechanism to detect which Roundcube directories to remove have changed. CB keeps a symlink /var/www/html/roundcube that should point to the latest and live Roundcube version. For example:

Code: 
# ls -la /var/www/html/roundcube
lrwxrwxrwx 1 webapps webapps 20 Mar 30 17:55 /var/www/html/roundcube -> roundcubemail-1.6.10

If this symlink is removed or points somewhere else CB will remove all roundcube installations, because it can not detect which version is actually used.

My guess is that on your server the symlink /var/www/html/roundcube was not present and that is why live Roundcube directory was removed. This means that no only Dovecot installation, but any other action with CB would have removed the Roundcube. Reinstalling Roundcube created both the live directory and the symlink.
 
You're right, @fln

My /etc/httpd/conf/extra/httpd-alias.conf file did in fact have a different path set for Roundcube due to a previous adjustment we made.

I’ve reverted it to:

Alias /testmail /var/www/html/roundcube
Click to expand...

I only changed the alias name to testmail, but kept the original path /var/www/html/roundcube.
I believe this should prevent the issue from happening again during future updates.
 
  • Like
Reactions: fln
A small update is released. It makes a couple of minor UI improvements:
  • Removes small scroll bar in File Manager action bar (visible only on some browsers).
  • Some links were black instead of using primary UI color.
 
One more update with small UI improvements:
  • Fixed missing button background color in the BFM page.
  • Restored stripped table rows in light mode.
 
Hi,

Has anyone encountered the same issue as me?
After performing a mass update on several servers running AlmaLinux 8.10, I'm seeing the following error repeatedly in the Apache error log:

exit signal Segmentation fault (11)

I’ve already tried removing most PHP extensions, leaving only ionCube and Zend, and I’ve also rebuilt both Apache and PHP — but the issue still persists.

Can anyone help us?
Thank you!
 
ViT said:
Hi,

Has anyone encountered the same issue as me?
After performing a mass update on several servers running AlmaLinux 8.10, I'm seeing the following error repeatedly in the Apache error log:

exit signal Segmentation fault (11)

I’ve already tried removing most PHP extensions, leaving only ionCube and Zend, and I’ve also rebuilt both Apache and PHP — but the issue still persists.

Can anyone help us?
Thank you!
Click to expand...
You can try creating ticket to DirectAdmin support and we will try checking if the issue is related to DA and DA CustomBuild software or it comes from your system/OS.
 
Just reading the changelog. For 'Roundcube installer and customisations' it says:
The directory ./program can no longer be customised. This used to allow replacing critical Roundcube source files. This customisation is discontinued because it is very fragile and nearly impossible to support multiple Roundcube versions.
Click to expand...
Does this mean any customisations in /usr/local/directadmin/custombuild/custom/roundcube/program/ will no longer be copied to Roundcube? We use that folder to customise the localization labels.inc and messages.inc? We also use it to customise which tools are shown on the compose page html editor.
 
@jigster, yes. Latest CB will not copy over the /usr/local/directadmin/custombuild/custom/roundcube/program/ directory on the freshly installed RoundCoube sources.

The main motivation for discontinuing this type of cutomisations is because they are very fragile and must be updated every time RC sources are updated to keep them in sync with the rest of RC code base. It would be best to restructure your customizations as plugins that RC could load. In the worst case it is also possible to inject extra logic into RC codebase via the config.inc.php file.
 
On our production servers, we’re using the "stable" update channel, so we only performed the update today.
For some reason, on all of our servers, after completing the update, we received the following message regarding CloudLinux updates:

DirectAdmin has been updated to v1.677 with warnings

This is an automated message notifying you that DirectAdmin has been successfully updated with warnings.
v1.676 (96e35cc) to v1.677 (c7480cc)

Warning message:
/usr/local/directadmin/scripts/update.sh:
This system is receiving updates from CloudLinux Network server.


To view what has changed, please visit:

Version 1.677 | Directadmin Docs

DirectAdmin Knowledge Base
docs.directadmin.com
Click to expand...

There were no actual issues, and everything seems to have updated correctly.
Is this message just a harmless warning that can be safely ignored?
 
@paulonichio, it is safe to ignore this warning. It is slightly annoying that CloudLinux shows this message when we interact with system packages system. The upgrade procedure treats any surplus output from the upgrade script as potential warning. We will see if we could work around it to exclude this message but still show any other potentially more important messages.
 
fln said:
@jigster, yes. Latest CB will not copy over the /usr/local/directadmin/custombuild/custom/roundcube/program/ directory on the freshly installed RoundCoube sources.

The main motivation for discontinuing this type of cutomisations is because they are very fragile and must be updated every time RC sources are updated to keep them in sync with the rest of RC code base. It would be best to restructure your customizations as plugins that RC could load. In the worst case it is also possible to inject extra logic into RC codebase via the config.inc.php file.
Click to expand...
Thanks. I can understand your reasoning for most of the contents of the roundcube /program directory, but the program/localization directory is where we're supposed to make customisations to the language strings isn't it? I've implemented the changes with a roundcube plugin, so the issue is resolved, but it would be better if we could edit the localization files directly as intended.
 
Last edited:
I have just upgraded to 1.677. The Roundcube config setting $config['db_dsnw'] is now being overwritten with every Roundcube build. We use a custom $config['db_dsnw'] setting because we use sqlite, not mysql for Roundcube. It took me a while to work out why all our customers couldn't access their Webmail preferences or contacts!!

Why is $config['db_dsnw'] no longer copied over from /usr/local/directadmin/custombuild/custom/roundcube/config.inc.php as before? All other settings in the custom config file seem to get copied over. Is this intentional, or a bug? It would be great to allow us to customise that setting again!
 
Thanks for sharing you use-case @jigster. Customising RoundCube localisation files seems like a fair request. I was hoping we could get away by enabling the localisation at the skin level with localization: true on the skin meta.json. But it seems this mechanism is only for new skin translation strings, not for the core ones.
Regarding the custom RoundCube database connector string. Using a nonstandard RC database implementation breaks other DirectAdmin features For example, storing user email contacts when creating backups. By forcing everyone to use MySQL/MariaDB for RoundCube settings and contacts, we can make sure we will be able to back them up and restore them.

If there are compelling reasons why using an SQLite backend is preferred over using MySQL/MariaDB, the best way forward would be to extend DA to support the RoundCube SQLite backend natively. It means allowing CB to configure it and allowing DA to read it when creating backups. Could you share the main reasons why you would prefer keeping this data in SQLite?
 
fln said:
Thanks for sharing you use-case @jigster. Customising RoundCube localisation files seems like a fair request. I was hoping we could get away by enabling the localisation at the skin level with localization: true on the skin meta.json. But it seems this mechanism is only for new skin translation strings, not for the core ones.
Regarding the custom RoundCube database connector string. Using a nonstandard RC database implementation breaks other DirectAdmin features For example, storing user email contacts when creating backups. By forcing everyone to use MySQL/MariaDB for RoundCube settings and contacts, we can make sure we will be able to back them up and restore them.

If there are compelling reasons why using an SQLite backend is preferred over using MySQL/MariaDB, the best way forward would be to extend DA to support the RoundCube SQLite backend natively. It means allowing CB to configure it and allowing DA to read it when creating backups. Could you share the main reasons why you would prefer keeping this data in SQLite?
Click to expand...
Thanks for the update @fln. We have RC set up so that each DA account has a separate SQLite database stored in a /home/USER/.webmail directory, then we use the RC config file to dynamically get the domain and set $config['db_dsnw'] to point to the user's RC database in /home/USER/.webmail.

The reason we prefer this set up using SQLite is that each DA user has a separate database which we find easier and more versatile for a number of reasons:
  • it gets backed up with the /home directory so works with any type of backup (e.g. rsync), not just with DA backups.
  • easier for moving accounts between servers as it works even when just using rsync to move files.
  • less impact if problems occur with the database, as it's only a single user affected by each database.
I hope the above offers some insight into our use-case and reasoning. I understand that we have customised things more than most, but it would be great if you offered some way to use a customised $config['db_dsnw'] setting in the RC config. If not, I'll have to create a script using a hook to force this change after every RC build.

Keep up the good work :)
 
  • Like
Reactions: fln
An update to the 1.677 release is pushed out. Key changes:

* Fixed a bug in admin Change Passwords page. It used to load only the first 50 user account names for the user search.
* Extended CustomBuild RoundCube installer to allow customising the ./program directory the same way as it used to be customisable before.
 
You must log in or register to reply here.
Back
Top