DirectAdmin v1.645 has been released

It was working fine on all boxes before the Curl OS update yesterday.
SFTP backup to multiple FTP's is giving this error now, and just tested it again.
Even de backup is complete on the external FTP's

Should be really a Directadmin issue.
 
I did also some test because we had a simular error "curl: (18) server did not report OK, got 426"
test on debian server (updated to latest DA version): curl 7.64.0 => error
test on centos server (updated to latest DA version): curl 7.61.1 => error
test on centos server (NOT updated to latest DA version): curl 7.85.0 => NO error
 
Yeah way to many changes and issues on Directadmin last releases. @fln please check into this.
 
@exlhost could you please open support ticket, so we could follow-up on the FTP upload failures issue?
 
I enrolled back to 1.644 (2138cff12eb6d60eec6bde18b2bf38b208f9ae51).

Have the same problem still:

Code: 
Cannot find the script in /etc/systemd/system, /usr/lib/systemd/system, nor /lib/systemd/system
/lib/systemd/system/clamav-freshclam.service
 
@exlhost thanks, for opening the ticket. We found the root cause for this issue and releasing new build 94a1c5c8ef5a0be38780fe96758aea1ec743e4e7 with a hot-fix. It includes updated scripts/ftp_upload.php file.

Root cause was that over time curl have slightly changed the meaning of --tlsv1.1 flag. In older curl versions this flag meant that only TLS 1.1 can be used in a secure connection, it will not allow neither higher nor lower TLS protocol version. In curl 7.54 behaviour of this flag was changed to mean that TLS 1.1 or higher can be used. FTP upload script was always adding --tlsv1.1 parameter, so on the systems where curl were downgraded to version older than curl 7.54 FTP uploads over secure connection started requiring exactly TLS 1.1 and not at least TLS 1.1. So this issue affected those hosts that met the following criteria:
  • has curl older than 7.54
  • used secure FTP for backup uploads
  • destination FTP server refused to work over TLS 1.1
@xerox I would suggest staying on 1.645 and just running /usr/local/directadmin/custombuild/build clamav or triggering ClamAV build via GUI.
1669396934747.png
 
OK i tried your solution but this gave me an error.

Code: 
######################################################################## 100.0%
######################################################################## 100.0%
Installing clamav...
Repository copr:copr.fedorainfracloud.org:copart:restic is listed more than once in the configuration
Error: Nothing to do
Repository copr:copr.fedorainfracloud.org:copart:restic is listed more than once in the configuration
No Match for argument: clamav-update
Error: Nothing to do
grep: /etc/clamd.d/scan.conf: No such file or directory
/usr/local/directadmin/custombuild/build: line 18403: /etc/clamd.d/scan.conf: No such file or directory
grep: /etc/clamd.d/scan.conf: No such file or directory
/usr/local/directadmin/custombuild/build: line 18406: /etc/clamd.d/scan.conf: No such file or directory
grep: /etc/clamd.d/scan.conf: No such file or directory
Can't open /etc/clamd.d/scan.conf: No such file or directory.
grep: /etc/freshclam.conf: No such file or directory
Enabling clamd in systemd...
Failed to execute operation: No such file or directory
Failed to execute operation: No such file or directory
Restarting freshclam.
Failed to restart clamav-freshclam.service: Unit not found.
Restarting clamd.
Failed to restart [email protected]: Unit not found.
Restarting exim.
Done ClamAV.
 
@fln
We have applied the fix on other boxes, but it looks like its not fixed over there.

Code: 
User ... has been backed up. <22:09:30>
ftp_upload.php exit code: 18
ftp_upload.php output: curl: (18) server did not report OK, got 450
curl return code: 18
 <22:09:32>
Please see this URL and check for curl exit code '(18)': https://help.directadmin.com/item.php?id=2127

Although a backup error has occurred, the upload of valid backups would have still been attempted to
 
I know my views are useless as I use my owned licence(s), but, seriously, who tests before new 'updates' get pushed out? Are we all guinea pigs

There are too many bugs that creep out nearly every release, and the majority of them are critical......
 
Well, we gave acces to an box with Centos 7 and an older version of Curl 7.29.0
but the other boxes with Almalinux 8.7 and curl 7.61.1 are still giving the sFTP backup error after the Fix.
 
  • Like
Reactions: fln
Yes, the fix for scripts/ftp_upload.php in 94a1c5c8ef5a0be38780fe96758aea1ec743e4e7 addresses the issue when backup upload with curl fails with error code 35:

Code: 
curl: (35) Peer reports incompatible or unsupported protocol version.

@exlhost, In your latest post I see error:

Code: 
ftp_upload.php output: curl: (18) server did not report OK, got 450

This is most likely a different issue. We will be able to follow up on that once we get access to a machine where we could reproduce such issue. Previous issue that was fixed already is a good example that we sometimes need some specific combination of software configuration not only on DA side but on remote FTP server as well for the issue to be reproducible.
 
Peter Laws said:
I know my views are useless as I use my owned licence(s), but, seriously, who tests before new 'updates' get pushed out? Are we all guinea pigs

There are too many bugs that creep out nearly every release, and the majority of them are critical......
Click to expand...
Agreed, after update to 1.645 , it killed my clamd.scan and I need to remove it
 
@fln: error when updating mariadb 10.6 in custombuild on my debian 11 system:
E: Unable to locate package rpcsvc-proto
Installing packages 'rpcsvc-proto' using apt-get attempt 3/3 failed

Seems to have updated though
 
@exlhost, thanks for giving us access to investigate this further. It turns out root cause for (18) server did not report OK, got 450 in this case was in curl and FTPS provider TLS1.3 communication incompatibility. In addition to particular curl version and FTP server software combination its only triggered when uploading big files, small plain-text files can be uploaded fine.

Problem can be avoided by giving FTP upload script a hint to not use TLS1.3 with curl --tls-max 1.2 argument. For @exlhost it was fixed by creating a customized copy of scripts/ftp_upload.php placed in scripts/custom/ftp_upload.php which has --tls-max 1.2 added to the curl command.


@mmgenius error mesasge in your case is slightly different so this might be yet another case or same case but with different remote FTP server software. Could you test it out if adding --tls-max 1.2 helps in your case?

In general any FTP 4xx response code indicates a transient error meaning that FTP server logs could give you hints why he decided that operation have failed.


We need to collect more feedback to see if this is something worth including in the general scripts/ftp_upload.php script for everyone.

@k1l0b1t you can safely ignore this error, this package is available on Debian 12 it is not requred on Debian 11 but we try to install it without explicit Debian version check since its failure is harmless.
 
@fln, --tls-max 1.2 works (it was indeed also like you explained, small file worked fine, large files have error)
 
You must log in or register to reply here.
Back
Top