DirectAdmin 1.665

fln

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

This release brings MariaDB 11.4 support, and upgrade to DB backup logic, substantial improvements for CustomBuild, and a clean-up of obsolete features.

A full release change log is here:

DirectAdmin 1.665

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!
 
An update is released, to change latest MySQL 8.0 version from 8.0.38 to 8.0.37 and MySQL 8.4 from 8.4.1 to 8.4.0.

Received one report of MySQL not starting and crashing with the following error:

Code:
2024-07-11T19:56:45Z UTC - mysqld got signal 11 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=6227f28e6cc1a743f6222b3a3a0c05561cc905ee
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000
/usr/local/mysql/bin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x2e) [0x208916e]
/usr/local/mysql/bin/mysqld(print_fatal_signal(int)+0x35f) [0xfcf17f]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0xa5) [0xfcf235]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13140) [0x7f60c0163140]
/usr/local/mysql/bin/mysqld(Validate_files::check(__gnu_cxx::__normal_iterator<dd::Tablespace const* const*, std::vector<dd::Tables>
/usr/local/mysql/bin/mysqld(std::thread::_State_impl<std::thread::_Invoker<std::tuple<Detached_thread, std::function<void (__gnu_cx>
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7ea7) [0x7f60c0157ea7]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x3f) [0x7f60bf341a6f]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

Change log for both versions reports a change in Validate_files::check() function:
  • MySQL 8.0.38 -> InnoDB: Removed unnecessary heap usage in the Validate_files::check() function.
  • MySQL 8.4.1 -> InnoDB: Removed unnecessary heap usage in the Validate_files::check() function.
This does not affect all the servers, our test machines works fine with 8.0.38 on all distros. However to be on the safe side versions were bumped down to avoid this version for the time being. Similar looking problem can be found on Oracle support page.

Rollback to previous minor version resolves the issue.
 
Hi,
Did you change something in mariadb backups?? Because after yesterday DA update my backups have errors.... "An error occurred during the backup - Database: exporting database "acdm_1544": exit status 3: mysqldump: Error 2013: Lost connection to server during query when dumping table `catalog_courses_products` at row: 1" - I can see that it has record with 50mb text... but before directadmin update that wasn't a problem.... I can even properly export that database to file in Phpmyadmin...
 
@ShinJii yes, this release includes changes in how database backups are created. The general idea is still the same we execute mysqldump, there are some small changes (we always dump procedures now). It would be best if you could open a support ticket and we could find the root cause what causes the backup to fail.
 
After the upgrade to 1.665 , the "./build versions" command returns the following message:

"Error: Cache-only enabled but no cache for 'cloudlinux-x86_64-server-8"

How to solve it ?
 
An update is released with the following changes:
  • When creating DB backup automatically set maximum allowed packet size. This should prevent Error 2013: Lost connection to server during query errors. When creating backups.
  • Update lego version to 4.17.4.
  • Make sure modifying existing login key will throw errors if login key had no longer supported commands (for example CMD_API_SECURITY_QUESTIONS).

@exlhost, yes some Evolution plugins were removed. More details here.

@ShinJii the issue with DB backups was caused by new backup code no longer load addition mysql configuration files when creating backups. To make sure large data sets does not cause problems for DB backups we have updated the default value of default_mysqldump_options field in directadmin.conf to include --max-allowed-packet=1G.

@matkra we have too little information to investigate it further, please open a support ticket.
 
On an Cloudlinux 7.9 server :
PHP scripts return error 500
Compilation breaks : "configure: error: Package requirements (sqlite3 >= 3.7.7) were not met"

Had to re-install sqlite-devel and many libraries to be able to compile it.
probably unrelated to the new version but should not happen..
 
Last edited:
@netswitch PHP compilation error should not be directly related to this update. To find the root cause please check the full CB log. Prior to compiling PHP CustomBuild always installs libsqlite3-dev package on Debian based systems and sqlite-devel on RHEL based systems. On all supported systems this should bring sqlite3 newer than 3.7.7.
 
A small update is released to current release channel, with the following changes:
  • Fix in Evolution skin mailing list management page to show all subscribers, not just first page.
  • Apache version update from 2.4.61 to 2.4.62
 
A small update is released to current release channel, with the following changes:
  • Fix in Evolution skin mailing list management page to show all subscribers, not just first page.
  • Apache version update from 2.4.61 to 2.4.62
Thanks.

Would it be possible, when you do a new release on a current version that it gets a .1 on the end or something? I can appreciate why you might not want to roll out 1.666 (this one might want to be skipped for other reasons 😅) but for those of us manage releases manually, we know we have to go again for the updates... so 1.665.1 or something :)

Also, while i'm here, would it be possible to put the build ref in the release notes, if it doesn't already exist somewhere else? As rolling back doesn't take the version number and needs the build ref would be super useful to have a list of those somewhere....

Thanks again for another great release!
 
Hi guys, after the last update (legacy license) backup via FTP no longer works for me.

Does it work normally for you?

User admin has been backed up. <3:00:59>
ftp_upload.php exit code: 8
ftp_upload.php output: curl: (8) Failed to connect to XXXXXX.your-storagebox.de port 21: Connection refused
curl return code: 8

If I try to log in with filezilla I don't encounter any problems.

thanks
 
Might be an ipv6 issue, check this thread, some solution at the bottom.
 
@41279. Backup uploads via FTP work as expected on our test servers.

@deltaB. Build ID already uniquely identifies the release. If DA shows an update is available (when the current build ID does not match the latest build ID), it means it is not running the latest build. It does not really matter which build it is since for each DA version, there is only one build that we consider to be the latest.

The whole idea with hot-fix releases is to never make any changes that would require updating a change-log. Well, except for the changes in the versions.txt file (used by CustomBuild). The versions.txt file serves as a recommendation for the software versions we suggest using. If one needs to use a different version, it can be configured in the CustomBuild custom versions section.

So to sum up, a hotfix release will include updates and bug fixes for stuff that is already documented in the change-log or change CB versions. There should never be a need to run older builds of the same version or to even care about build IDs. If you do not want automatic DA updates, it is OK to keep autoupdate=0 in the directadmin.conf. But having autopatch=0 in directadmin.conf should be considered a configuration error. It is designed to be used only by developers to be able to use not-yet-released builds.

Our long-term goal is to reduce the number of hot-fix releases and just make normal releases more often.

@patrickkasie thanks for reporting the problem.
 
@41279. Backup uploads via FTP work as expected on our test servers.

@deltaB. Build ID already uniquely identifies the release. If DA shows an update is available (when the current build ID does not match the latest build ID), it means it is not running the latest build. It does not really matter which build it is since for each DA version, there is only one build that we consider to be the latest.

The whole idea with hot-fix releases is to never make any changes that would require updating a change-log. Well, except for the changes in the versions.txt file (used by CustomBuild). The versions.txt file serves as a recommendation for the software versions we suggest using. If one needs to use a different version, it can be configured in the CustomBuild custom versions section.

So to sum up, a hotfix release will include updates and bug fixes for stuff that is already documented in the change-log or change CB versions. There should never be a need to run older builds of the same version or to even care about build IDs. If you do not want automatic DA updates, it is OK to keep autoupdate=0 in the directadmin.conf. But having autopatch=0 in directadmin.conf should be considered a configuration error. It is designed to be used only by developers to be able to use not-yet-released builds.

Our long-term goal is to reduce the number of hot-fix releases and just make normal releases more often.

@patrickkasie thanks for reporting the problem.

Makes perfect sense. Thanks for the detailed response. I wasn't aware of the autopatch= function.
 
Hi @fln
did mysql 5.7 already drop support or bug, because missing option in custombuild.
 
MySQL 5.7 availability depends on the distro. It is available on all Debian systems and on RHEL 7. On RHEL 8 and RHEL 9 minimum MySQL version is 8.0.

RHEL 8 does not support MySQL 5.7 because it uses RPMs for installing MySQL. RHEL 9 uses static MySQL binaries so I think we might be able to support MySQL 5.7, but it is not tested. RHEL 9 just blocks MySQL 5.7 to stay similar to RHEL 8.
 
@ShinJii yes, this release includes changes in how database backups are created. The general idea is still the same we execute mysqldump, there are some small changes (we always dump procedures now). It would be best if you could open a support ticket and we could find the root cause what causes the backup to fail.

Hello @fln,

Thanks for the improvements on this release.

It appears that the recent update triggers errors when trying to send backups to an NFS partition (which we can also get for free from certain providers like OVHCloud).


OUTPUT :

An error occurred during the backup (id=1)

Database: writing database config file for "database_example1": chown /nfs-backup/2024-08-12/example/backup/database_example1.conf.a7406f39.temp: operation not permitted
<1:00:30>
Database: writing database config file for "database_example2": chown /nfs-backup/2024-08-12/example2/backup/database_example2.conf.4b38b4cd.temp: operation not permitted
<1:00:48>

The issue could probably be the same for an S3 mountpoint or any system that is not compatible with changing ownership?

Perhaps the backup is still consistent, but we need a setting to receive the message "Your backups are now ready (id=1)" instead of "An error occurred during the backup (id=1)" to avoid the need for daily manual backup monitoring, as you know.

Thanks in advance!
 
Back
Top