Search K
Appearance
Appearance
Released: 2025-11-12
When web installer is started, there will be an option to continue the installation using CLI mode.
The CLI mode can be activated by typing Y at the CLI prompt. Example:
[setup.sh] Please open the following URL in your browser to continue the DirectAdmin installation:
http://192.168.0.10:35222/?key=UNRetIHjabpOER08Vap1mxgbEUcIFbw7
If installation could not be completed using the given URL, installation can be continued using the command line.
Would you like to continue in command line mode? [Y/n]:This option is useful in situations when the URL for continuing installation in the web browser is not possible. It can happen on servers with minimal access from the public internet.
The user-level ModSecurity page is updated and renamed to Web application firewall. The updated page makes it easier to quickly check the state of the web application firewall on user-owned domains. The overview of all hostnames is especially on the ModSecurity admin-level page.

Simplify ACME counters structure by writing all entries into a single file /usr/local/directadmin/data/admin/letsencrypt_rate_limits/weekly.json.
Old letsencrypt files and directories structure is dropped.
The ModSecurity settings for domains and subdomains will be configured independently. Before this release, the ModSecurity settings for subdomains used to be derived with multi-level inheritance. It could be configured to have its own configuration, or it could inherit the configuration from the main domain, or it could use the server defaults.
Starting with this release, the subdomain ModSecurity configuration will be either explicitly configured or will use global defaults. The main domain configuration will not affect subdomain configuration.
On update, each subdomain that used to inherit the configuration from the main domain will get a copy of the main domain configuration. This ensures there will be no change of behaviour in the ModSecurity configuration for all existing servers.
The feature to execute plugin calls under a fixed UNIX user feature used to allow execution as root UNIX user only for the admin-level user accounts.
With this release, the restriction is lifted, and it is now possible to create a plugin for user-level or reseller-level accounts that would execute the plugin code as root UNIX user.
This is controlled by the admin_run_as, reseller_run_as, and user_run_as configuration fields in the plugin.conf file.
This change does not grant plugin developers more access than they used to have before. The standard way of executing plugin action as root was by packing a custom application with set-uid capabilities. There were many problems related to using set-uid wrappers:
All the plugins that used to bundle the set-uid wrapper can replace it with a configuration option in the plugin.conf file.
15.02 to 15.052.4.1-4 to 2.4.26.3.4-6 to 6.3.4-70.5.0 to 0.6.010.11.14 to 10.11.1510.6.23 to 10.6.2411.4.8 to 11.4.911.8.3 to 11.8.44.19.0 to 4.20.01.29.2 to 1.29.31.8.4 to 1.8.4.18.5.0RC2 to 8.5.0RC46.2.0 to 6.3.08.2.2 to 8.2.32.2.5 to 2.3.0The default configuration for PHP-FPM services is updated to use syslog for logging instead of plain text files.
The following files will no longer be used:
/usr/local/php*/var/log/php-fpm.log/var/log/php-fpm*.logThe journalctl command should be used to get access to the PHP-FPM service logs. Example commands:
journalctl -u php-fpm81.service
journalctl -u php-fpm82.service
...The following configuration files were updated ./custombuild/configure/fpm/conf/php-fpm.conf.*.
Note: The PHP-FPM service logs contain only the information about the FPM service itself. They do not contain errors from the PHP code. These logs are only useful when debugging the PHP-FPM configuration problems.
OpenSSH 9.8 separated the sshd process into sshd and sshd-session. The new process name is visible in the logs for failed and successful logins.
CSF log parser patterns are updated to support both the new sshd-session and the old sshd process name.
The default CSF configuration will not use the Process Tracking and Integrity Checking features.
These features create too many false positive reports on modern servers and use server resources without adding much value.
Changes in /etc/csf/csf.conf:
LF_INTEGRITY = "3600" changed to LF_INTEGRITY = "0".PT_LIMIT = "60" changed to PT_LIMIT = "0".New DirectAdmin installations will use new default values. Configuration in existing servers will be updated with this DirectAdmin update.
These features are still functional and can be manually enabled. Once enabled manually, the configuration will not be disabled with the upcoming DirectAdmin or CSF updates.
Both reseller and user level dialogs were replaced with new pages.

protocols.conf file for Dovecot custombuildfix A bug in the CustomBuild script is fixed that prevented using a custom protocols.conf file for the Dovecot service. Prior to the fix, if a custom protocols.conf file were present, the Dovecot configuration would fail with the following error:
cp: cannot stat '/usr/local/directadmin/custombuild/configure/dovecot/conf/protocols.conf': No such file or directoryWith removal of unified_ftp_password_file directadmin.conf flag, user creation would trigger ftp service restart without a valid reason. This erroneous behaviour is fixed.
Deleting a DNS record now removes duplicates. Previously, a separate API request had to be sent for each identical DNS record.
Within DNS management pages, if there were multiple of the same DNS record, selecting any of the table rows with that value used to selected all of the rows that had that same value and displayed incorrect amount of selected rows. With this change, each row is treated as separate.
Table rows now properly highlight on hover
If available plugin version cannot be retrieved within 10 seconds, it will now be skipped.
plugins_allowed_run_as configuration option from directadmin.conf removal Plugins running as a custom UNIX user will always be supported. This means plugin creators can rely on the admin_run_as, reseller_run_as, and user_run_as configuration options in the plugins.conf to always work as expected.
Prior to this change, plugin creators could not rely on this feature, because depending on the server configuration it might or might not work as expected. This change will make the plugin system more reliable and easier to work with.
mod_security_rules.conf template removal The template file mod_security_rules.conf is no longer used.