DirectAdmin v1.674

fln

fln

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

The release adds support for the Dovecot 2.4.0 version, a new UI for managing DB connection details, improved file upload in File Manager, Exim configuration improvements and a lot of other smaller changes.

A full release change log is here:

DirectAdmin 1.674​

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!
 
We see that changes have been made to dns_create_post hook and many environment variables which where available before are now missing.

Can this be reverted? We need the username and creator environment variable for further DNS processing in our own DNS infrastructure.

Current number of environment variables in 1.674 are very minimal. Before this there used to be more far many environment variables.

environ({'LANG': 'en_US.UTF-8', 'INVOCATION_ID': 'some-random-string', 'skip_template': '0', 'PWD': '/usr/local/directadmin', 'zone_existed': '0', 'JOURNAL_STREAM': '9:12345', 'GOMAXPROCS': '1', 'signed_zone': '0', 'domain': '123.example.com', 'RUNTIME_DIRECTORY': '/run/directadmin', 'SHLVL': '1', 'LANGUAGE': 'nl', 'PATH': '/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin', '_': '/usr/local/directadmin/scripts/custom/dns_create_post.sh'})
 
Last edited:
Thanks for reporting this @Joriz. The multiple environment variables present when executing this hook in earlier DirectAdmin versions were not intended for this hook, but leaked from other script execution as a side effect. Latest DirectAdmin version takes care to isolate different hook execution and this is the reason why the amount of variables available in this hook is now only signed_zone, skip_template, zone_existed, and domain (docs).

We will check the possibility of adding the username token to this hook as well.
 
Last edited:
My DA upgraded to 1.674 and now I can login to DA but get 500 errors on everything I click on.

This is in the /var/log/directadmin/error.log, not sure if it's related:

2025:03:06-10:06:47: httpd header lentgh (4096) is too big

2025-03-06 10_13_39-venom.datafanatics.com _ Dashboard.png
 
frankc420 said:
2025:03:06-10:06:47: httpd header lentgh (4096) is too big
Click to expand...
This is not directly related to DA update. This error can happen on any DirectAdmin version if at least one of the HTTP headers exceeds 4kb size. It is possible to create very long headers by storing large amount of data in cookies. Please try cleaning browser cookies or just try opening DA in another browser. DA by itself does not store much information in cookies (just session ID), but other systems available on the same hostname might do it.
 
fln said:
This is not directly related to DA update. This error can happen on any DirectAdmin version if at least one of the HTTP headers exceeds 4kb size. It is possible to create very long headers by storing large amount of data in cookies. Please try cleaning browser cookies or just try opening DA in another browser. DA by itself does not store much information in cookies (just session ID), but other systems available on the same hostname might do it.
Click to expand...
Thanks, incognito fixed me. That error gave zero indication that the issue was related to cookies. Thanks.
 
An update to DA 1.674 is released. This update fixes an issue in File Manager. When multiple files were selected, the right-click menu was missing the Copy/Move action. This release restores the original menu entry.

@Joriz, to improve backwards compatibility in this release we have also added the username token into dns_create_post hook. Please keep in mind that sometimes the username token will be empty (for example when admin account creates a new DNS zone not associated with any user).
 
DA logo is shown in the priority box when editing MX record
 

Attachments

  • Skjermbilde 2025-03-07 kl. 13.35.09.png
    Skjermbilde 2025-03-07 kl. 13.35.09.png
    19.8 KB · Views: 13
Thanks for reporting it @gate2vn. The logo appeared there by accident. A new build is pushed out without it.
 
If we upgrade to Dovecot 2.4.0, do we need to manually turn on the FTS plugin in Custombuild or does it come integrated with it? Is there any documentation on how implementation might change with this? I've read it being significantly better implementation, but not sure how it will differ on how to turn it on and check how it works.
 
@jca, the email full-text-search is controlled by the dovecot_fts option in the CustomBuild options.conf file. If dovecot_fts=yes is set (can be changed with command da build set dovecot_fts yes command), then CustomBuild will pick different FTS plugin based on the Dovecot version.
  • If Dovecot 2.3.x is used then fts-xapian plugin will be installed and enabled.
  • If Dovecot 2.4.x is used the fts-flatcurve plugin will be used, it is now part of Dovecot core.
To try out Dovecot 2.4.0 with fts-flatcurve plugin use the following commands:

Code: 
da build set dovecot_fts yes
curl -X PUT -d '{"version":"2.4.0"}' "$(da api-url)/api/custombuild/versions-custom/dovecot"
da build dovecot

Note: the curl command above is the same as echo 'dovecot:2.4.0:' >> /usr/local/directadmin/custombuild/custom_versions.txt, just done using an API call rather than direct access to the custom_versions.txt file.
 
I see the default FTS config is different between 2.3/xapian and 2.4/flatcurve, is there any specific reason for that, e.g. fts_enforced and the autoindex excludes?

2.3/xapian:
Code: 
# cat /usr/local/directadmin/custombuild/configure/dovecot/conf.d/90-fts-xapian.conf
#add quota to end of line in:
#/etc/dovecot/conf/mail_plugins.conf, eg:
#mail_plugins = $mail_plugins fts fts_xapian

plugin {
        plugin = fts fts_xapian

        fts = xapian
        fts_xapian = partial=3 full=20 verbose=0

        fts_autoindex = yes
        fts_enforced = yes

        fts_autoindex_exclude = \Junk
        fts_autoindex_exclude2 = \Trash
        fts_autoindex_exclude3 = \INBOX.spam
        fts_autoindex_exclude4 = \Inbox.Trash
}

2.4/flatcurve:
Code: 
# cat /usr/local/directadmin/custombuild/configure/dovecot/2.4/conf.d/90-fts-xapian.conf

fts flatcurve {
        fts_flatcurve_min_term_size = 3
}

fts_autoindex = yes

language en {
  default = yes
}
language_tokenizers {
    generic = yes
}

Edit: Ref the excludes, I see that the 2.4/conf/namespace_private.conf file has fts_autoindex = no for Junk, spam/Spam, and Trash, so the result should be the same.
 
Last edited:
On one of our servers I can't sign in. DirectAdmin returns me to the sign in page and the log records a successful sign in.

2025:03:13-16:55:21: '0.0.0.0' successful login to 'XXX'

We've already tried disabling @FA, restarting the server and updating DirectAdmin manually which was already up to date.

[root@dhs11 data]# da update
directadmin current v1.674 d743d404c31a832c86d9e384f5c22d353951b958 is already latest

Anyone have a clue? The server was updated last night. We're not seeing any errors in the DirectAdmin logfiles.

Additional info

- creating a link using the command line doesn't work, just redirects back to the sign in page
- this user doesn't have a the default admin user, I've deleted it and installed another one
- sso links using the api key I've created for it still work
- end users and resellers can still sign in
- I've found a second server that has the same problem
 
Last edited:
@xyntanl, please open a support ticket. This will give us a chance to find the root cause for it. I do not think it is directly related to the update.
 
An update to this DA version is released to bump the default PHP versions to:
  • PHP 8.1.32
  • PHP 8.2.28
  • PHP 8.3.19
  • PHP 8.4.5
These PHP versions got the security fixes for CVE-2025-1217, CVE-2025-1219, CVE-2025-1734, CVE-2025-1736, CVE-2025-1861.
 
@fln

I don't know if it's a bug or a feature, but when you make a password field visible and want to type or change a password yourself, you can only type, delete one letter or symbol at once, and then it doesn't go any further.

error.jpg
 
We see that since 1.674 a lot of our actions in DirectAdmin hooks are failing due to lack of information about the user and creator. This was previously available in many hooks as environment variable.

We use this information to store data and preform (security) checks on external systems which are part of the hosting platform. As some hooks run before the user.conf is populated we rely on the information we get from the hooks.

Can this be restored?

This would make the hooks more useful again for all kind of integration cases and checks. (y)
 
You must log in or register to reply here.
Back
Top