DirectAdmin 1.709

fln

fln

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

A full release change log is here:

DirectAdmin 1.709​


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!
 
Thanks @stefantriep. The empty docs page was a placeholder for the next DA 1.710 release with an incorrect title. The title is fixed now.
 
After this update, SSL is no longer working correctly for subdomains. I’m getting HSTS errors, regardless of whether I use a wildcard SSL certificate, a regular certificate, or ZeroSSL.
It even requested a new SSL which was not needed.

Every update seems to introduce new SSL-related problems.
 
@exlhost, could you please share some details or open the support ticket. This is not something we see on our test servers.
 
@fln After updating to DirectAdmin 1.709, the Brute Force Monitor (evo/brute-force-monitor) is no longer working correctly on my server.

The issue is not limited to the monitor itself — the Brute Force Monitor link does not open/work when clicked, and I cannot access the page through the Evo interface.

This started immediately after the DirectAdmin 1.709 update.

Could you please check whether there is a problem with the Evo Brute Force Monitor route/page in 1.709 and advise how this can be fixed?

DirectAdmin version: 1.709
Affected area: evo/brute-force-monitor
Problem: Link/page does not open or function after the update.
 
@Can, the BFM page work as expected on our test servers and on the demo.directadmin.com.

Maybe it is something specific to your server. Please open a support ticket and we will investigate it further.
 
fln said:
@exlhost, could you please share some details or open the support ticket. This is not something we see on our test servers.
Click to expand...
We did that, I followed Roman's steps, you can read my response there. Please note that when we have performed the update from 1.708 to 1.709 again, we will see on the SSL page from the current the SSL certificate: New certificates are waiting to be provisioned.
 
Thank you @exlhost. The root of the problem was a subdomain that is using the www alias. The new system no longer issues certificates for the subdomains with additional www prefix.

In the next DA release 1.710 (currently in alpha) we are removing the www alias from web server configuration completely. For users who want to continue using subdomains with main name and an additional www alias we added a maintenance task. When executed this task reports any subdomains that have functional www prefixes and allows automatically creating normal subdomains for them. More details here.
 
fln said:
Thank you @exlhost. The root of the problem was a subdomain that is using the www alias. The new system no longer issues certificates for the subdomains with additional www prefix.

In the next DA release 1.710 (currently in alpha) we are removing the www alias from web server configuration completely. For users who want to continue using subdomains with main name and an additional www alias we added a maintenance task. When executed this task reports any subdomains that have functional www prefixes and allows automatically creating normal subdomains for them. More details here.
Click to expand...
Can you elaborate on how the maintenance task knows if the www subdomain is used or is in use?
Does it check the apache-logfile for activity?

Kr
Dries
 
The detection works by checking if the subdomain alias is covered by a TLS certificate. If www alias was not covered, then it is a strong indication that name is non-functional (it would throw TLS error if visited).

If the alias name was used in plain-text only mode, the migration will not detect it. This makes sure we will not be adding surplus additional subdomains just because it was crawled by web scrapers.
 
It looks dovecot 2.4.5 stores new incoming emails into /Maildir/cur (instead of /Maildir/new) , is it ?
 
@ccto, yes. We had to adjust some of our integration tests to align them with the new Dovecot behaviour.
 
After upgrading Dovecot 2.4.4 to 2.4.5, we are seeing errors which seem to be caused by a bug in Dovecot Pigeonhole:

Code: 
Sep 25 11:55:29 srv12 dovecot[2496069]: imap([email protected])<2500062><9An4jUxcqM1/AAAB>: Panic: file imap-sieve-storage.c: line 588 (imap_sieve_mailbox_transaction_run): assertion failed: (src_box != NULL)
Sep 25 11:55:29 srv12 dovecot[2496069]: imap([email protected])<2500062><9An4jUxcqM1/AAAB>: Error: Raw backtrace: libdovecot.so.0(backtrace_append+0x40) [0x7f09c9142a60] -> libdovecot.so.0(backtrace_get+0x22) [0x7f09c9142bb2] -> libdovecot.so.0(+0x151362) [0x7f09c9151362] -> libdovecot.so.0(+0x1513f1) [0x7f09c91513f1] -> libdovecot.so.0(+0x6ebaa) [0x7f09c906ebaa] -> lib95_imap_sieve_plugin.so(+0x4c05) [0x7f09c8b4ac05] -> lib10_quota_plugin.so(+0xdbe4) [0x7f09c8b6fbe4] -> libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x7b) [0x7f09c94cf59b] -> libdovecot-storage.so.0(mailbox_transaction_commit+0x22) [0x7f09c94cf6b2] -> imap [[email protected] 127.0.0.1 UID MOVE](+0x18980) [0x55855ce08980] -> imap [[email protected] 127.0.0.1 UID MOVE](command_exec+0xa4) [0x55855ce17fc4] -> imap [[email protected] 127.0.0.1 UID MOVE](+0x25b02) [0x55855ce15b02] -> imap [[email protected] 127.0.0.1 UID MOVE](+0x25bb4) [0x55855ce15bb4] -> imap [[email protected] 127.0.0.1 UID MOVE](+0x25e3b) [0x55855ce15e3b] -> imap [[email protected] 127.0.0.1 UID MOVE](client_handle_input+0x1d5) [0x55855ce162a5] -> imap [[email protected] 127.0.0.1 UID MOVE](client_input+0x73) [0x55855ce16873] -> libdovecot.so.0(io_loop_call_io+0x69) [0x7f09c916adb9] -> libdovecot.so.0(io_loop_handler_run_internal+0x147) [0x7f09c916c557] -> libdovecot.so.0(io_loop_handler_run+0x50) [0x7f09c916ae60] -> libdovecot.so.0(io_loop_run+0x40) [0x7f09c916b060] -> libdovecot.so.0(master_service_run+0xe8) [0x7f09c90b6278] -> imap [[email protected] 127.0.0.1 UID MOVE](main+0x3ee) [0x55855ce05dce] -> libc.so.6(+0x2a610) [0x7f09c8c2a610] -> libc.so.6(__libc_start_main+0x80) [0x7f09c8c2a6c0] -> imap [[email protected] 127.0.0.1 UID MOVE](_start+0x25) [0x55855ce05f85]
Sep 25 11:55:29 srv12 dovecot[2496069]: imap([email protected])<2500062><9An4jUxcqM1/AAAB>: Fatal: master: service(imap): child 2500062 killed with signal 6 (core dumped)

I believe this has been patched upstream in the Dovecot Pigeonhole repository, but DirectAdmin bundles Pigeonhole with Dovecot so we can't update just Pigeonhole. As a temp fix I used the following which seems to have resolved the problem:

Code: 
echo 'mail_attachment_detection_options =' > /etc/dovecot/conf.d/999_fix_crash.conf
systemctl restart dovecot

Is this the best way to fix this? A downgrade back to Dovecot 2.4.4 also resolves the issue.
Could anyone from DirectAdmin confirm if you are aware of this bug already, and when or in which DA version you may be releasing a fix? Then I can remove the temp fix. Thanks
 
Sysem Backup stopped working, System Backup script update.
Code: 
An error occurred during the backup 9/27/2026, 10:57 AM
Starting System backup...

Prechecks:
  Sanity checks: ....curl: (64) Requested SSL level failed
<br>
Why? FTP does not need SSL.
1790501422387.png


Edit: I changed the FTP server to accept ssl (Enable TLS support), now this message appears:
Starting System backup...

Prechecks:
Sanity checks: ....curl: (21) QUOT string not accepted: DELE /Redacted/upload_test.txt
<br>

The file was uploaded to my ftp server, but as a security I don't allow deletion or read actions by FTP, only for myself as a local user.
Please skip the delete test and I'm happy with ssl ftp.

Edit 2: For testing purposes I gave R/W access to my ftp server. Now again another error appears.
Starting System backup...

Prechecks:
Sanity checks: .... Done
Free disk space: .... Done

Archiving:
/var/named
/etc/named.conf
/etc/openlitespeed
-> /backup/09-27-26/sysbk-09-27-26.tar.zst .... Done

Transfer:
/backup/09-27-26 -> redacted.net ....curl: (18) server did not report OK, got 426
<br>

Edit 3: Other observation. the backup file on my DA server in/backup/09-27-26/sysbk-09-27-26.tar.zst seems to be valid, the file uploaded to my ftp-server seems to be corrupt/incomplete.

Edit 4: After every failure the /backup directory is not cleaned up. When starting a new backup I get the message:
Starting System backup...

Prechecks:
Sanity checks: ....backup already performed for 09-27-26 (/backup/09-27-26), aborting...
<br>

Then I have to SSH to my server to delete the leftovers from the backup.

Edit 5: Backup and Restore still works fine.
 
Last edited:
You must log in or register to reply here.
Back
Top