DirectAdmin 1.704

[fln]

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!

 

[unihostbrasil]

@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=...

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.

 

[fln]

Thanks for catching this @unihostbrasil. We pushed out a new CSF and DA build with a fix.

 

[Richard G]

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.

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.

 

[zEitEr]

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.

[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.