DirectAdmin bugs (or normal issues?) after years of flawless work

Eric Gurt

New member
Joined
Jul 13, 2022
Messages
3
Hi,

I've been running server with DirectAdmin for a long while (probably for longer than 8 years).

So, at some point I noticed strange process that seemingly was ran with some crontab logic, related to DirectAdmin. It was taking a lot of time and being never able to complete which heavily affected my Node.js service performance (100% CPU usage from that DA-related process). I think it was "dataskq". I assumed it was related to "600503 Message System" messages that can't even be opened in DirectAdmin (loads forever). I tried to find and remove all messages but with no luck. Eventually, I ended up removing that process from auto-start.

Everything was fine, but now I've noticed Direct Admin not updating SSL certificates.

Whenever I try to request new SSL sertificates with "Free & automatic certificate from Let's Encrypt" I get this (after few seconds of thinking):
Code:
Cannot Execute Your Request

Details

Requesting new certificate order...
Processing authorization for ftp.gevanni.com...
Challenge is valid.
Processing authorization for gevanni.com...
Challenge is valid.
Processing authorization for mail.gevanni.com...
Challenge is valid.
Processing authorization for pop.gevanni.com...
Error: http://pop.gevanni.com/.well-known/acme-challenge/letsencrypt_1657697444 is not reachable. Aborting the script.
dig output for pop.gevanni.com:
194.28.175.6
Please make sure /.well-known alias is setup in WWW server.

I did try to not make SSL certificates for pop and smtp but I'm still getting an error for www.gevanni.com , which is strange since gevanni.com works.
As a result all SSL certificates on my server have expired.

I'm pretty sure well-known aliases are still present in httpd config since I didn't change them.
It also feels like DirectAdmin updating doesn't start.
Code:
Last Updated    Wed Apr 27 23:31:04 2022
Last Restart    Wed Jul 13 06:55:39 2022

What should I do now? I mostly care about SSL certificates being up to date. Server itself is just a testbed for my projects.
 
Last edited:
Hello and Welcome. Maybe some more info would help.
 
Hello and Welcome. Maybe some more info would help.
Operating system and Version
Code:
CentOS Linux release 7.9.2009 (Core)                                                                                                                         
NAME="CentOS Linux"                                                                                                                                           
VERSION="7 (Core)"                                                                                                                                           
ID="centos"                                                                                                                                                   
ID_LIKE="rhel fedora"                                                                                                                                         
VERSION_ID="7"                                                                                                                                               
PRETTY_NAME="CentOS Linux 7 (Core)"                                                                                                                           
ANSI_COLOR="0;31"                                                                                                                                             
CPE_NAME="cpe:/o:centos:centos:7"                                                                                                                             
HOME_URL="https://www.centos.org/"                                                                                                                           
BUG_REPORT_URL="https://bugs.centos.org/"                                                                                                                     
                                                                                                                                                              
CENTOS_MANTISBT_PROJECT="CentOS-7"                                                                                                                           
CENTOS_MANTISBT_PROJECT_VERSION="7"                                                                                                                           
REDHAT_SUPPORT_PRODUCT="centos"                                                                                                                               
REDHAT_SUPPORT_PRODUCT_VERSION="7"                                                                                                                           
                                                                                                                                                              
CentOS Linux release 7.9.2009 (Core)                                                                                                                         
CentOS Linux release 7.9.2009 (Core)


Directadmin Version
Compiled onrhel7_amd64
Server Version1.641

All of the related error message and or log excerpt

dataskq process has ~45% of CPU usage, causes Node.js process to lag.

Code:
[root@vps8600 /]# killall -USR1 dataskq                                                                                                                       
[root@vps8600 /]# tail -n 10 /var/log/directadmin/errortaskq.log                                                                                             
2022:07:16-18:33:24: Ticket::deliverMessage::Can't read ./data/admin/tickets.list: Unable to open ./data/admin/tickets.list for reading.<br>                 
No such file or directory<br>                                                                                                                                 

2022:07:16-18:41:06: Ticket::deliverMessage::Can't read ./data/admin/tickets.list: Unable to open ./data/admin/tickets.list for reading.<br>                 
No such file or directory<br>                                                                                                                                 

2022:07:16-18:50:24: Ticket::deliverMessage::Can't read ./data/admin/tickets.list: Unable to open ./data/admin/tickets.list for reading.<br>                 
No such file or directory<br>                                                                                                                                 

2022:07:16-18:55:24: Dataskq [9312] USR1 signal: Currently processing: check_brute_force_logs: done User sorting : getDirFilesAndDirs(/usr/local/directadmin/plugins, *tlf, *tdlf, (null)) : done

It looks like bruteforce is doing some sorting... There might be a lot of brute-force entries.

Detailed description of the issue

dataskq process has ~45% of CPU usage, causes Node.js process to lag. I tried to disable dataskq's crontab task but it breaks Let's Encrypt work, so I reverted that.
 
just clean all messages (dirs, files) from /usr/local/directadmin/data/tickets/ and configure in DA message system to keep messages some short time (14d for example) by default it keeps all messages forever.
 
just clean all messages (dirs, files) from /usr/local/directadmin/data/tickets/ and configure in DA message system to keep messages some short time (14d for example) by default it keeps all messages forever.
Done

rm -rf /usr/local/directadmin/data/tickets/*

Problem still happens after reboot:

directadmin.jpg
 
You might need to check various logs to see waht dataskq is doing. It can have multiple reasons for causing high cpu.
There are several threads on this hier on DA, so it can have some reasons.

Or is it only keep stating an issue with the tickets?
 
It looks like bruteforce is doing some sorting... There might be a lot of brute-force entries.

You might see if this helps.

Maybe your not clearing old entries

Remove an IP from the BF blacklist after XXXXX minutes (where XXXXX = 86400).

unblock_brute_ip_time=86400


A number of minutes after which the IP is automatically unblocked by Brute Force Monitoring.

Reset count of IP/User failed attempts XX hours after last attempt (where XX = 24).

clear_brute_log_time=24


Number of hours the failed login attempts to be checked within. If ip_brutecount is set to 100 then an ip can have 100 failed attempts within 48 hours before all Admins are notified. If the IP has 99 failed attempts, waits 24 hours, then makes 99 more attempts, no notifications will be sent.

Clear failed login attempts from log X days after entry was made (where X = 4).

clear_brute_log_entry_time=4


The number of days how long to keep brute-force incidents (in /usr/local/directadmin/data/admin/brute_log_entries.list file).

Also if you have a license with support you might log a ticket.
 
Back
Top