DirectAdmin v1.646 has been released

[fln]

Hi everyone!

We are happy to announce the release of DirectAdmin 1.646.

This release brings a nice set of new features combined with improvements of existing features and bug fixes. Key new features are - updated system info page, ability to customize Evolution help-links, initial support for email clients auto-configuration.

In addition to all the improvements there is one visible behaviour change for the DirectAdmin login flow. A system default skin will be used not only for the username and password prompt but also for Two Factor Authentication Code (or security questions). Only after user is fully logged in - user skin will be used. Old behaviour was to use system skin for login prompt, but user skin for asking 2FA or security question.

Full release change log can be found here:

DirectAdmin 1.646​

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

 

[Richard G]

I know about the RFC, but is this customisable?
Outgoing mail: SMTPS mail.example.com 465 SSL/TLS

Like Gmail has?
Port for SSL: 465
Port for TLS/STARTTLS: 587

Because more and more systems are not using 465 anymore, even the biggest Dutch ISP (Ziggo) is not advertising with it anymoer. And as you can see Gmail only uses SSL on this, not TLS which is a more modern SSL protocol.
Also hotmail is using starttls on port 587 and not advertising 465 anymore.

I think some might appreciate a customisable option for this if possible.

 

[Zerg]

There is always TLS used nowadays and "SSL" became a way to tell that TLS connection has to be initiated immediately, and "TLS" that unencrypted STARTTLS should be used to initialize TLS. As time has already shown, initiating TLS connection immediately on port 465 is more secure: https://nostarttls.secvuln.info/

It would good if it is customisable however, we are using different domain name for mail connections.

 

[cjd]

Issue after jailshell update, Debian 10/11, jailed users cron jobs getting:

bwrap: can't find source path /run/user/1234: no such file or directory

Disabled option on affected users as a temporary work around while figuring it out.

 

[fln]

@cjd, thanks for report, you can continue using older jailshell version by placing it in the .../custombuild/custom/jailshell.sh. The following snipped should place v0.7 there:

mkdir -p /usr/local/directadmin/custombuild/custom
curl https://files.directadmin.com/services/custombuild/bubblewrap/jailshell-0.7.sh -o /usr/local/directadmin/custombuild/custom/jailshell.sh

This will start showing an update from 0.8 to 0.7, you can get back to latest version with:

rm /usr/local/directadmin/custombuild/custom/jailshell.sh

In the mean time we will investigate this further and release an update if needed. On our test boxes latest jailshell works on Debian systems, but it might rely on specific configuration.

 

[sparek]

I know about the RFC, but is this customisable?
Outgoing mail: SMTPS mail.example.com 465 SSL/TLS

Like Gmail has?
Port for SSL: 465
Port for TLS/STARTTLS: 587

Because more and more systems are not using 465 anymore, even the biggest Dutch ISP (Ziggo) is not advertising with it anymoer. And as you can see Gmail only uses SSL on this, not TLS which is a more modern SSL protocol.
Also hotmail is using starttls on port 587 and not advertising 465 anymore.

I think some might appreciate a customisable option for this if possible.

SSL and TLS refer to the same thing. Something about a copyright with the term SSL came about a long time ago, so the "official" name was changed to TLS. But that didn't stop people from using the term SSL.

Essentially what you're referring to is "Opportunistic TLS" or the STARTTLS command. This occurs when a connection is made and the client requests an upgrade to secure TLS. You might think of this as "explicit TLS" because you (the client) have to explicitly request an upgrade to TLS. The server may or may not comply with this request, but generally a client that requests a TLS upgrade, if it doesn't get one, it stops the connection (thus the "require TLS" parameter).

Implicit TLS or referred to in Exim as tls_on_connect - is when the connection is already negotiated to be a TLS connection upon connection. There's no explicit request to upgrade the connection to TLS because by connecting to the service on that defined port, you're already defining it as a secure TLS connection.

I completely agree with you on principle though. There are WAY too many email clients that don't differentiate between these two methods and causes a lot of confusion for people that understand the difference. Most email clients will simply ask "Require SSL" or "Require TLS" or "Require secure connection". OK. Does that mean that the client should expect an implicit TLS connection (i.e. port 465) or does it mean that the client should always request an explicit TLS connection (port 25 or 587 with a STARTTLS)? The different meanings mean different port numbers to use in your client set up.

The Gmail SMTP settings should probably (at least in my opinion) probably be worded:

Secured connection using implicit (tls_on_connect) TLS
Secured connection using explicit (STARTTLS) TLS

which I think would be more accurate.

As debated in the other thread - I really though the majority of email clients were switching more to explicit TLS, but the RFC linked to in that thread seems to indicate that implicit TLS is now preferred. However, this is also a good example of RFC standards vs. what the major players in said industry is doing. Email client developers didn't appear to get that memo and I think the majority of them are more explicit TLS bound, which puts administrators in a difficult position: follow the RFCs or follow the public mass?

 

[fln]

@cjd , you are right, just noticed the issue affects cron, not normal shells. There are known differences in how Debian vs RHEL systems handle cron sessions (PAM config). Pushed out a fix to address the issue. Jailshell v0.9 no longer requires for /run/user/{uid} to exist and can run without it, new build is 5165de7174aa6408f0362bda0722baf497e8c83c.

 

[Richard G]

However, this is also a good example of RFC standards vs. what the major players in said industry is doing.

Yes that was what i was thinking about too. Same with the RFC which in fact limits the amount of characters in an e-mail, but the major players and even almost everybody uses a lot more, which recently caused an issue on an Exim update when this suddenly started to work "correctly" again.
Well.... we'll have to see and wait what is going to happen when major players are not following RFC's anymore.
Thanks for your explanation and insight!

 

[Richard G]

@fln Can you check this pleae? I also was not aware about such change in 1.646 and seems not to work anyway.

exim.variables.conf.custom broken

Since DirectAdmin version 1.646 we have issues on servers with exim.variables.conf.custom. We have many servers with custom openssl_options, tls_require_ciphers, tls_certificate or other settings. For example: /usr/local/directadmin/custombuild/build exim_conf 2023-01-05 14:41:20 Exim...

forum.directadmin.com

 

[fln]

An update to custom exim variables merge (to allow any number of white-spaces after variables) is released in 02a9d50d12fd29395c87d1116d37f189c70a570b, thanks @tomputer.

 

[cjd]

@fln , Just had time to test jailshell on one of the accounts. With 0.9 version I'm getting a different error:

bwrap: execvp /bin/bash: No such file or directory

I have cron running:

cd /home/USER/domains/THEIRDOMAIN.COM/public_html; wp cron event run --due-now >/dev/null 2>&1

This worked fine in 0.7, I don't have time to look at it till later. Only tested this on Debian 10 so far, only testing on one host right now, don't want to upset customers.

 

[fln]

@cjd, this could be happen on old systems, which are not yet migrated to the merged /usr structure, more info in debian wiki.

Fresh installs of Debian 10 (or newer) comes with merged /usr structure at install time but very old systems that have lived through multiple rolling upgrades up to Debian 10 might still have old layout. You can fix it by installing special package called usrmerge.

Note: There is no need to install this package on systems with already merged layout. You can check if you systems is using new layout by checking if /bin is a symlink to /usr/bin.

Modern system with unified layout:

# stat /bin
  File: /bin -> usr/bin
  Size: 7             Blocks: 0          IO Block: 4096   symbolic link
...

Old system that need usrmerge package:

# stat /bin
  File: /bin
  Size: 4096          Blocks: 8          IO Block: 4096   directory
...

 

[cjd]

@fln yes you are correct, was originally a Debian 9 system, I will do that after the full system backup tonight and see if that corrects the issue. Thank you. Also will check the other systems for any issues, if any, will report back either way on my results.

 

[Erulezz]

New PHP versions have been released with security fixes;

05 Jan 2023

PHP 8.2.1 Released!​

The PHP development team announces the immediate availability of PHP 8.2.1. This is a security release.
All PHP 8.2 users are encouraged to upgrade to this version.

Can this make it in this version please?

 

[ps4all]

(Translated from Dutch into English);

oops!
Permissions required to load the theme have not been granted for this account, or an unexpected problem has occurred. Contact your administrator.
try again
Sign out

(Admin account can't be used anymore).
Already tried to fix permissions which solved nothing.


Also got a error after updating Exim and Exim_conf;

Jan 5 21:11:57 xxxxxxxxxxxxxx systemd[1]: session-679686.scope: Succeeded.
Jan 5 21:11:58 xxxxxxxxxxxxxx systemd[1]: Started Exim Mail Transport Agent.
Jan 5 21:11:58 xxxxxxxxxxxxxx exim[6049]: 2023-01-05 21:11:58 Exim configuration error in line 783 of /etc/exim.conf:
Jan 5 21:11:58 xxxxxxxxxxxxxx exim[6049]: option "srs" unknown
Jan 5 21:11:58 xxxxxxxxxxxxxx systemd[1]: exim.service: Main process exited, code=exited, status=1/FAILURE
Jan 5 21:11:58 xxxxxxxxxxxxxx systemd[1]: exim.service: Failed with result 'exit-code'.

Replaced exim.conf with the old one else exim wouldn't start at all, line 783:

srs_router:
driver = redirect
condition = ${if exists{/etc/exim.srs.forward.conf}}
srs = reverse
data = :blackhole:
domains = +local_domains

1. Using Debian 10
2. The exim issue has now occured on several Debian 10 servers already.

 

[Phuturist]

(Translated from Dutch into English);
oops!
Permissions required to load the theme have not been granted for this account, or an unexpected problem has occurred. Contact your administrator.
try again
Sign out

(Admin account can't be used anymore).

Got this error as well, but only on one admin account. Can luckely still log in with another admin account.

 

[ps4all]

Got this error as well, but only on one admin account. Can luckely still log in with another admin account.

Got it solved myself;

Solution?:
Go to directory /usr/local/directadmin/data/users/admin/skin_customizations/evolution/files
Move, rename or delete file options-v1.json

Try logging in again, it should work.

Only issue remaining: exim as mentioned here.

 

[Phuturist]

Got it solved myself;

Solution?:
Go to directory /usr/local/directadmin/data/users/admin/skin_customizations/evolution/files
Move, rename or delete file options-v1.json

Try logging in again, it should work.

Only issue remaining: exim as mentioned here.

Thanx, worked for me as well.

 

[fln]

Would be great if anyone affected by this evolution error would share the contents of options-v1.json file. This would help us find out what kind of configuration could cause such an issue. Would be best to send it as a private message. Thanks.

 

[Phuturist]

Would be great if anyone affected by this evolution error would share the contents of options-v1.json file. This would help us find out what kind of configuration could cause such an issue. Would be best to send it as a private message. Thanks.

Dont think a private message is neccesary. This was the content of my options-1.json. Nothing special in there.

{
  "menuType": "list",
  "theme": "darkmode"
}