DirectAdmin 1.59.0 has been released

Hello,

another thing after the update to 1.59.0, is on "Brute Force Monitor" the number of failed attempts has switch to 1 or 0.12 instead of the actual number of failed login attempts.

Can you also look it up? It remains that way even after updating to 1.59.1..
 
Since updating to the newer Directadmin 1.59.0 which uses curl instead of ncftp this is happening:
ftp_upload.php exit code: 67
ftp_upload.php output: curl: (67) Access denied: 530
curl return code: 67
<3:31:25>
Click to expand...

This is odd because the backup still succeeded afterwards and there was a smaller backup running before it which was transferred at 3:33:59 which succeeded successfully with the same password.
Or does this happen because curl can't make concurrent logins or something?

Anyway I never have seen access denied notices on ncftpput before. What could cause this?
 
Usually they start a new thread for it.
Click to expand...
Yes but once a while for small and fast fixes they don't always.

Wil 1.59.1 also fix this? I found this in the /var/log/directadmin/security.log file:
Code: 
2019:09:23-18:04:13: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/ncftp/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:23-18:04:13: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/win/bmed/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:25-11:06:12: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/ncftp/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:25-11:06:12: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/win/bmed/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
And I wonder why this happens as it was said that in 1.59.0 ncftp would not be used anymore.

Happens on multiple servers. Maybe it's best to just remove the ncftp package from the packages directory?
 
Richard G said:
Yes but once a while for small and fast fixes they don't always.

Wil 1.59.1 also fix this? I found this in the /var/log/directadmin/security.log file:
Code: 
2019:09:23-18:04:13: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/ncftp/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:23-18:04:13: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/win/bmed/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:25-11:06:12: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/ncftp/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
2019:09:25-11:06:12: ensure_owner: HardLink found on /usr/local/directadmin/scripts/packages/ncftp-3.2.6/win/bmed/bookmark.c (2 links).  Was attempting to ensure owner is diradmin:diradmin
And I wonder why this happens as it was said that in 1.59.0 ncftp would not be used anymore.

Happens on multiple servers. Maybe it's best to just remove the ncftp package from the packages directory?
Click to expand...

Thanks, I've done 2 things:
  1. Added --hard-dereference to the tar command
  2. Clean up the ncftp-3.2.6 folder after the compile existed with 0 status.

You don't need that source directory after the install finishes, so feel free to remove it if you still have it.

---

For the 1.59.1 announcement, I do recall writing it.. I don't currently see it.
I'll hunt for it and re-post it if needed.
Sorry about that :)

John
 
Richard G said:
Since updating to the newer Directadmin 1.59.0 which uses curl instead of ncftp this is happening:


This is odd because the backup still succeeded afterwards and there was a smaller backup running before it which was transferred at 3:33:59 which succeeded successfully with the same password.
Or does this happen because curl can't make concurrent logins or something?

Anyway I never have seen access denied notices on ncftpput before. What could cause this?
Click to expand...

i have the same problem with backup user by FTP into reseller level ( users with 10 GB and more only )

for small account its work well

ftp_upload.php exit code: 67
ftp_upload.php output: /home/tmp/microfutur.3460837/hydraspe.tar.gz.cfg is empty. curl is not going to be happy about it.
-rw------- 1 diradmin diradmin 0 Oct 11 06:39 /home/tmp/microfutur.3460837/hydraspe.tar.gz.cfg
-rw-r----- 1 diradmin hydraspe 7314773063 Oct 11 06:39 /home/tmp/microfutur.3460837/hydraspe.tar.gz

curl: (67) Access denied: 530
curl return code: 67
<6:39:56>
 
After upgrade to Version 1.591000 i got 503 Service Unavailable error on websites
 
Limpan said:
Thanks for the update!

I tried following the phpMyadmin SSO guide, but gets a "IP mismatch" error thrown at me when I try to click the login button on a database. Any idea how to fix this?
Click to expand...
how to fix, I have the same error
 
DirectAdmin Support said:
Hello,

We're very pleased to announce the release of DirectAdmin 1.59.0.
You can update through:
Code: 
Admin Level -> Licenses/Updates -> Update DirectAdmin

John
Click to expand...

I tried following the phpMyadmin SSO guide, but gets a "IP mismatch" error thrown at me when I try to click the login button on a database. Any idea how to fix this? The problem is urgent for customers who are trying to log in, I cannot log in to phpmyadmin
Click to expand...
yAahJlMP4e.gif
 
HostinganID said:
Did you already try rebuild phpmyadmin and php on custombuild?
Click to expand...
Please give me instructions, I follow this command

cd /usr/local/directadmin/
./directadmin set one_click_pma_login 1
service directadmin restart
cd custombuild
./build update
./build phpmyadmin
 
locyhan said:
Please give me instructions, I follow this command

cd /usr/local/directadmin/
./directadmin set one_click_pma_login 1
service directadmin restart
cd custombuild
./build update
./build phpmyadmin
Click to expand...
Assuming you dont have any custom config files you created in this area.


ok in order do

Code: 
cd /usr/local/directadmin/custombuild
./build clean
./build clean_old_webapps
./build update
./build update_da

then do
Code: 
cd /usr/local/directadmin/
./directadmin set one_click_pma_login 1
service directadmin restart
cd custombuild
./build update
./build phpmyadmin

then dump your browser temp files and cookies
log out of DA
log back in.

Then let us know what happens.
 
locyhan said:
View attachment 2809
Click to expand...
For the "IP mismatch" you could just strip that out from the /var/www/html/phpMyAdmin/direct_login/index.php, but your /var/log/httpd/error_log (depending on URL host value, and php type.. where ever php errors are logged) should have something like
Code: 
phpMyAdmin: direct_login: IP mismatch '$token_ip' != '$client_ip'
swapping out the $token_ip and $client_ip with actual values. Knowing which values are being inserted would be key to debugging the issue. The code in question in the given index.php is:
Code: 
        $token_ip = inet_pton($file_data['ip']);
        $client_ip= inet_pton($_SERVER['REMOTE_ADDR']);
        if ($token_ip != $client_ip)
        {
                error_log("phpMyAdmin: direct_login: IP mismatch '$token_ip' != '$client_ip'");
                die_rm("IP mismatch", $token_file);
        }
so If you fully wish to allow ANY IP use the given token, just change the "if ($token_ip != $client_ip)" to be
Code: 
if (false)
However, I am very curious what 2 values are set, causing the IPs to be different in the check, if you're able. A ticket or new thread might be good for this.

John
 
Thanks for the help, the cause is the custombuid error. I reinstalled and it worked, great
 
You must log in or register to reply here.
Back
Top