DirectAdmin 1.704

fln

fln

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

A full release change log is here:

DirectAdmin 1.704​


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!
 
@fln, regarding the CSF dovecot log parser change in /usr/local/csf/lib/ConfigServer/RegexMain.pm, could you please double-check this change?

It looks like the updated regex introduced additional capturing groups, but the assigned capture indexes were not adjusted accordingly.

For example, with the relevant part of a log line like:

imap-login: Login aborted: Logged out (auth failed, 1 attempts in 8 secs) (auth_failed): user=<test>, method=PLAIN, rip=1.1.1.1, lip=...
Click to expand...

The new pattern appears to capture:
$10 = " in 8 secs"
$12 = <test>
$14 = 1.1.1.1

However, the code still uses the previous capture groups:
my $ip = $12;
my $acc = $10;

Wouldn’t the minimal correction be:
my $ip = $14;
my $acc = $12;

Otherwise, it seems the IP check may be receiving the username instead of the remote IP.
 
Just to be sure, it is not intended that we enable firewalld right? I've just encountered this notice when upgrading:
Unit /etc/systemd/system/firewalld.service is masked, ignoring.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having this kind of units are:
* A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
* A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
* A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
* In case of template units, the unit is meant to be enabled with some
instance name specified.
Click to expand...

I haven't seen this any time before.
We have firewalld disabled on all servers since we just use iptables/nftables. If firewalld needs to be enabled please let us know.
 
I got the same today. The reason you might see the warning, is that the CSF/LFD install/upgrade script tries to disable firewalld.service. That's it.

Bash: 
[root@poralix ~]# systemctl status firewalld.service
○ firewalld.service
     Loaded: masked (Reason: Unit firewalld.service is masked.)
     Active: inactive (dead)
[root@poralix ~]#
[root@poralix ~]# systemctl start firewalld.service
Failed to start firewalld.service: Unit firewalld.service is masked.
[root@poralix ~]#
[root@poralix ~]# systemctl stop firewalld.service
[root@poralix ~]#
[root@poralix ~]# systemctl disable firewalld.service
Unit /etc/systemd/system/firewalld.service is masked, ignoring.
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled or disabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.
[root@poralix tools]#


In Linux, when a system service is "masked", the system ignores it. It is "locked" so it cannot be started manually or accidentally turned on. Think of it like taking the battery out of a toy so it can never be turned on.
 
fln said:
We appreciate all the feedback on forums and issues reported in the ticketing system.
Click to expand...

CloudLinux 9 does not seem to have liblsapi-1.1-94 as of yet.

Bash: 
# da build update_versions
Updating mod_lsapi
cp: '/usr/local/php74/bin/lsphp' and '/usr/local/bin/lsphp' are the same file
This system is receiving updates from CloudLinux Network server.
download_cached: using cached '/usr/local/directadmin/custombuild/cache/mod_lsapi-1.1-94.tar.gz' file
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:17:34 ago on Wed Jun 10 23:35:20 2026.
Package yum-utils-4.3.0-20.el9.noarch is already installed.
Package file-5.39-16.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:17:38 ago on Wed Jun 10 23:35:20 2026.
Package criu-lve-3.13-6.el9.x86_64 is already installed.
Package criu-lve-devel-3.13-6.el9.x86_64 is already installed.
Package crit-lve-3.13-6.el9.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:17:40 ago on Wed Jun 10 23:35:20 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:16:10 ago on Wed Jun 10 23:36:59 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:17:59 ago on Wed Jun 10 23:35:20 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:16:22 ago on Wed Jun 10 23:37:06 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:18:18 ago on Wed Jun 10 23:35:20 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:16:41 ago on Wed Jun 10 23:37:06 2026.
No package liblsapi-1.1-94* available.
Exiting due to strict setting.
Error: No package liblsapi-1.1-94* available.
*** mod_lsapi.da_cb_install error: cannot download liblsapi 1.1-94 version ***
build_apache_mod_lsapi: failed to compile '/usr/local/directadmin/custombuild/cache/mod_lsapi-1.1-94.tar.gz' inside '/usr/local/directadmin/custombuild/tmp/tmp.LjSPbnPLmR.mod_lsapi-1.1-94.tar.gz'
failed to build mod_lsapi 1.1-94

The version 1.1.86 seems to be the latest available for CloudLinux 9.x

Bash: 
# yum info liblsapi
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:30:09 ago on Wed 10 Jun 2026 11:35:19 PM PDT.
Installed Packages
Name         : liblsapi
Epoch        : 1
Version      : 1.1
Release      : 86.el9.cloudlinux
Architecture : x86_64
Size         : 114 k
Source       : liblsapi-1.1-86.el9.cloudlinux.src.rpm
Repository   : @System
From repo    : cloudlinux-x86_64-server-9
Summary      : LSAPI library
URL          : http://cloudlinux.com
License      : CloudLinux Commercial License
Description  : This package contains liblscapi

The version 1.1.94 seems to be the available for CloudLinux 10.x only
 
@zEitEr, please report this to the CloudLinux team. We are just running the installer provided by CloudLinux.
 
fln said:
@zEitEr, please report this to the CloudLinux team. We are just running the installer provided by CloudLinux.
Click to expand...

Fixed on the DA server's side by:

Bash: 
echo mod_lsapi:1.1-86: >> /usr/local/directadmin/custombuild/custom_versions.txt

Does not seem to be a CloudLinux's side issue. What do I miss?
 
You must log in or register to reply here.
Back
Top