Troubleshooting DA service

How to run DirectAdmin in debug mode

Running DirectAdmin service normally will log serous errors in the system error log. The log can be checked with journalctl tool, example command:

journalctl -u directadmin.service

If the standard log does not provide enough information to find the root cause of a problem it is possible to start DirectAdmin in debug mode. In this mode the service will log more information on what is actually being performed. There are many levels of debug, the higher level, the more info will be printed. Usually, running level 2000 is enough to debug the problems. Anything higher is more for specific code debugging, so isn't usually needed.

Level:

To run DirectAdmin in debug mode directly from CLI, first the service needs to be stopped. It can be started with additional ---debug parameter.

systemctl stop directadmin
da server --debug="2000"

Making requests to DA via GUI or API will start showing the additional information in the terminal which started DirectAdmin service (standard output).

When trying to debug an API script, a useful way to filter the output is using grep command, example:

da server --debug="2000" | grep --line-buffered string

It would only show the posted data, and not the other debug information.

Another useful case is to save all debug into a file then open it to review or grep for useful information:

da server --debug="2000" > /var/log/directadmin/debug.log

Service can be terminated using Ctrl+C signal. After debug session is over service needs to be started as normal system service with:

systemctl start directadmin

It will start DirectAdmin as a system service.

Cannot connect to DA on port 2222

If you are unable to access your server via http://YOUR_IP:2222 , there are few things to check:

1. Is DirectAdmin running on a server?

systemctl status directadmin

or

ps auxwwwf | grep directadmin

If you see service down check the log:

tail /var/log/directadmin/error.log

Common problems are:

1. Incorrect ethernet_dev set in the /usr/local/directadmin/conf/directadmin.conf file.

2. Invalid license, either due to wrong uid/lid or IP. Try: </directadmin/general-usage/licensing>

3. Your IP is blacklisted in /usr/local/directadmin/data/admin/ip_blacklist. This is controlled by the "brute force login detection" in Admin Settings. Use a setting no lower than 10, since even loading the login page counts as 1 failed attempt.

4. Used binaries from a different operating system.

Try running DirectAdmin manually (if it's not already running) to see what the problem is:

da server --debug=200

Most likely, the error message will be shown on screen. Otherwise use Ctrl+C to stop.

2. Is port 2222 open in firewall?

If DirectAdmin is running but you cannot access it from outside, the common cause is that port 2222 is closed in firewall. First try accessing port 2222 on 127.0.0.1 IP:

telnet 127.0.0.1 2222

If connected, either try stopping the firewall or opening port 2222.

CentOS7

Stop firewall:

systemctl disable firewalld
systemctl stop firewalld

Or open port 2222:

firewall-cmd --zone=public --add-port=2222/tcp --permanent

CentOS 6, Ubuntu, Debian

Stop firewall:

service iptables stop
chkconfig iptables off

Or open port 2222:

iptables -I INPUT -p tcp --dport 2222 -j ACCEPT

We recommend installing CSF, a great tool that maintains firewall rules. Follow their installation guide.

Cannot login to DA as admin

If you're not able to login to DirectAdmin, this is usually caused by one of the following:

1. Your partition that stores the DirectAdmin session files is likely full. The session files are required for saving login information which allows you to login. To check your partitions, type df -h to check. The sessions are saved under /usr/local/directadmin/data/sessions, so it's going to either be your / partition or your /usr partition, depending on how your file system is set up.

2. Your IP is changing. This can happen when your internet provider gives you a rotating IP address. The most common provider that does this is a satellite internet provider. DirectAdmin checks the IP of the session for each request, so if your IP changes, you'll get booted to the login page. To resolve that, you can disable the IP check so that your rotating IP is allowed: http://www.directadmin.com/features.php?id=443

3. You are using wrong password. Try resetting it via SSH as root:

passwd admin

And type new password. Use the same command to reset the password for any user (replace admin in the above command with the username that needs the password reset).

4. The system clock or the client clock might be out of sync. All clocks must be accurate, or the session cookies may expire prematurely.

5. Other possible reasons:

• Make sure your browser supports cookies and they're not being filtered out.
• DirectAdmin needs to be restarted if it was just updated.
• You've got binaries for a different operating system.
• Your "usersdir" setting in your directadmin.conf is blank or broken. Enter command /usr/local/directadmin/directadmin config | grep usersdir, you should get a similar output as below:

[~]# /usr/local/directadmin/directadmin config | grep usersdir
usersdir=./data/users

Your IP is blacklisted

If you get the message:

Your IP is blacklisted

this means that you've had too many failed login attempts or accesses to port 2222 without being logged in.

To remove yourself from the blacklist, edit /usr/local/directadmin/data/admin/ip_blacklist and remove your IP from the list.

If you wish to ensure you never get blacklisted, you can create and add your IP to the file /usr/local/directadmin/data/admin/ip_whitelist, one IP per line.

The setting that controls how many attempts you get can be changed in Admin Level -> Admin Settings -> Blacklist IPs for excessive login attempts.

We don't usually recommend any value lower than 10. This is because even loading the login page counts as a failed login attempt, so if you set a low number, you'll be more likely to blacklist yourself.

This is the feature page for this option:
http://www.directadmin.com/features.php?id=573

As for DirectAdmin 1.34.0, you can set DirectAdmin to automatically remove IPs from the blacklist after a specified amount of time. Feature page:
http://www.directadmin.com/features.php?id=1013

Rejected session for user admin because IP does not match session file

If you're logged in, or having issues logging in, where you get booted back to the main login page, and your /var/log/directadmin/error.log shows this error

Rejected session for user admin because IP (1.2.3.4) doesn't match session file (5.6.7.8)

but both IPs are yours, that's likely due to some IP rotating which can happen with proxies, mobile devices, or when a client connection uses both IPv4 and IPv6 interchangeably.

As this IP check is not commonly done with session based logins, it is considered an extra level of security, so you can disable it if you need to by adding:

disable_ip_check=1

to your /usr/local/directadmin/conf/directadmin.conf and restarting DirectAdmin.

Related:
https://www.directadmin.com/features.php?id=443

Install: Cannot find the DirectAdmin binary. Extraction failed

If you're installing DA, but get the error:

gzip: stdin: unexpected end of file
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Cannot find the DirectAdmin binary.  Extraction failed
it could be for a various number of reasons.

Find the error below that best matches what you see in the last 1-2 pages of output before the error.

1. Download of update.tar.gz result header contains

x-return-code: unauthorized

Solution: Create a ticket for Sales.

2. If you getting

ERROR: Certificate verification error for www.directadmin.com: unable to get local issuer certificate
To connect to www.directadmin.com insecurely, use `--no-check-certificate'.

Solution:

The request you've made cannot be executed because it does not exist in your authority level

When using DirectAdmin, if you ever hit this error:

You cannot execute that command
The request you've made cannot be executed because it does not exist in your authority level

it would be because the request CMD call is not available to you. There could be various reasons for this. Below we'll outline the possible causes and debug methods needed to resolve it.

1. Logged in as different account

DirectAdmin uses session for browser-based authentication. This uses a session cookie which spans across all tabs/instances of a given browser. If you have 2+ tabs open, and login as a less privileged account in tab B (e.g., a User), then the other tabs (tab A) would also be logged in as this account, even if their page has not been updated. Making an action in tab A where you may have a link available, may no longer work as the session is now privileged to a lower/different account. Hit F5 on tab A to confirm you're seeing what you are allowed to see.

2. The commands.allow/deny

DirectAdmin supports lists that allow or deny commands that might otherwise be available to an account. Various ways to affect these lists include:

a) Per-User commands.allow/deny lists

b) Global never_commands

c) Feature Sets

Debugging Why

To get to the bottom of the "why" of the error, if needed, you can use DirectAdmin "USR_DEBUG", exactly level 703 (not higher, not lower), e.g.,

systemctl stop directadmin
da server --debug=703

and then make the given request which triggers the error. We'd be looking for output relating to either function call

User::isAllowedToExecute
User::deny_override

which do the controlling of these functions.

Use Ctrl-C to exit debug mode, and run:

systemctl start directadmin

to get DA running again.

How to debug a segfault within DirectAdmin

If you get a message "A segmentation fault has occurred", this is a program error generally due to either incompatible binaries for your OS, or incorrect handling of data.

The first thing you should do is go to Admin Level -> Licenses/Updates and check to ensure that the OS the binaries were compiled for match the OS you're using.

To debug it, the first thing you should do is check your /var/log/directadmin/error.log to see what the problem is. There will be a segfault message with a program location.

To further debug the error, mainly for reporting to us, you'd need to install "gdb" to debug the binary. You'll also need to be able to reliably duplicate the segfault.

1. Login to DA normally, and go the page such that you're one click away from generating the segfault.

2. Login to ssh as root and type:

cd /usr/local/directadmin
killall -9 directadmin
gdb directadmin
run s

This will have loaded up a single process non-forked copy of DirectAdmin. It only gets 1 call to it, then it will quit.

3. Go back to your "1 click away" browser, and submit the form to generate the segfault. You'll probably not get any output which is fine.

4. Back to SSH again, gdb should have pointed out that the program segfaulted. Type

bt full

to dump the memory for the programs location. Copy/paste that entire output and send it to us.

Domain Already Exists

This message will appear if the domain is already on the system. The way that DirectAdmin checks to see if the domain is already on the system is by looking in the named.conf file. (RedHat: /etc/named.conf)

If you are positive that domain has not been added anywhere in DirectAdmin (use "Show All Accounts" in the Admin Panel), then it should be safe to remove the zone from the named.conf file either manually, or by removing the zone from Admin Panel -> DNS Admin. Then you should be able to add the domain.

Be sure to backup the zone if you do not wish to lose the DNS data.

With the addition of the Multi Server option, DNS can now be hosted on other DA servers. Ensure that any Servers you have listed in your "Admin Level -> Multi Server Setup" page also do not have the domain in their named.conf files. If you disable the "check domain" option, then that server will not be queried.

You'd also want to ensure the domain is not in:

• Remote Multi-Server Setup IP, with "Domain Check" option
• the /etc/virtual/domains file
• the /etc/virtual/domainowners file
• the /etc/virtual/domain.com file
• any /var/named/*.nzf file if rndc is used for adding/removing zones

Your hostname and the servername you have set in DirectAdmin, do not match

If you get the error

Your hostname, , and the servername you have set in DirectAdmin, server.host.com, do not match.

or

hostname: Name or service not known

1. Please check the hostname, it should be a FQDN - Fully Qualified Domain Name:

hostname --fqdn

2. If you do have a hostname in the output, it means you just need to update the hostname in Admin Level -> Admin Settings -> servername . Set it, and save. You may need to change it to something else, then back again to re-sync it.

3. Ensure that you have a full zone for the hostname in your DNS: Admin Level -> DNS Admin -> server.host.com so that it resolves and has MX records.

4. Check the /etc/hosts file, and change:

1.2.3.4   your.hostname.com

to be:

1.2.3.4   your.hostname.com your

such that you have both the long and short forms of your hostname beside your server IP.

Handling ethernet devices on VPS/VDS installs

Installations on VPS/VDS could require additional steps to have DirectAdmin detect a proper ethernet device. Add the following to /usr/local/directadmin/conf/directadmin.conf:

ethernet_dev=devicename

For example, on many VPS systems, it will be:

ethernet_dev=venet0:0

Other systems where the IP is not the base IP on the device, you'd need to simply set the correct number:

ethernet_dev=eth0:1

Or other systems with the IP on a different device, it might be:

ethernet_dev=eth1

To see which device your IP is in, type:

ip a

Replace devicename with the FULL devicename reported by the above command. If your VDS/VPS system emulates eth0, then you may skip this step.

DirectAdmin not starting, cannot execute binary file

If you get one of the following errors:

./directadmin: cannot execute binary file

/lib64/ld-linux-x86-64.so.2: bad ELF interpreter: No such file or directory

error while loading shared libraries: libssl.so.10: cannot open shared object file: No such file or directory

it will mean that the OS version set in your license file does not match the OS you're using.

To get the correct binaries, you'll need to change the OS set in your license.

You can set this by logging into your Client Account Area, click the license ID to change the settings, and set the OS as needed.

If it's a new install, re-run the setup.sh again.

If it's an existing install, then grab the new binaries manually.

How to provide root access to DirectAdmin support

Whitelist our IP

When opening a support request via https://tickets.directadmin.com, you may be asked to provide root access for DirectAdmin support to adequately troubleshoot your issues. The first thing you should do is whitelist our IP in any firewall you're using. The support IP is 49.12.185.180.

CSF

If you're using CSF, you can whitelist our support IP via the following command via root SSH:

csf -a 49.12.185.180

Alternatively, you could whitelist our IP via the CSF plugin GUI in DirectAdmin:

1. Log into DirectAdmin
2. Click "Extra Features"
3. Click "ConfigServer Security & Firewall"
4. Beneath the section "csf - Quick Actions", in the input field next to "Quick Allow", enter the IP and then click the "Quick Allow" button.

Firewalld

The command to whitelist our IP in Firewalld would be as follows:

firewall-cmd --permanent --add-source=49.12.185.180

Iptables

To allow incoming connections from 49.12.185.180, use the command,

iptables -A INPUT -s 49.12.185.180 -j ACCEPT

Then, allow outgoing connections to 49.12.185.180:

iptables -A OUTPUT -d 49.12.185.180 -j ACCEPT

SSH KEYS

You can add our SSH key to your server's /root/.ssh/authorized_keys file. The key you'll need to add is located here:

https://directadmin.com/authorized_keys

You could use the single command from within the server as the root user:

curl -s https://directadmin.com/authorized_keys  >> /root/.ssh/authorized_keys

If, for some reason, you are unable to curl the key from the link above, please use this command:

if ! grep -m1 -qs 'jump.directadmin.com' /root/.ssh/authorized_keys; then echo 'from="49.12.185.180,2a01:4f8:c012:a61e::1" ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzNcABOtOXi17pw+FfXYLzAguypCmD49hJr1mNm3FzmgM2xYOEMxwdVd1TWprdZCtwTDXB9fBPBOSmrmHY1hFWOLMPscG9ojC+k0jxVb+JuSKWXO1jCDTbSRG/x+stE2dyFJqTFH+ScDG/yKrFsuDxr3EOga8LEytkA3iSV11CkbAHdJvT5Ib2UtlCYevguZzUg1j8UsMlYl7S/rGOFrks81QTY7f15ue2dEP6K8F2uD6JXCPuxsN5beLe//nlsiGXoVr11EiYx0iHsOlaSyJJG70J0x2rTKq6AvZjoRHAupFv9tPynn1pEjD0WcewWyaBDmTdxYcEJKiReCSxPhXHw== jump.directadmin.com' >> /root/.ssh/authorized_keys; fi

Confirm that the key was added:

grep 'jump.directadmin.com' /root/.ssh/authorized_keys

PASSWORD AUTHENTICATION

If you'd prefer to provide a root password, you can do so safely via our ticketing system. If you're including a password in your response, be sure to click "Contains Password" so that it gets encrypted in our ticket system.

CUSTOMIZATIONS

Make sure to let us know if you're using a custom SSH port.

Be Specific

Lastly, while this isn't directly related to providing us with root access, it is important to be specific when describing what error you are observing. Try to provide step-by-step instructions for us to reproduce the error on our end. This will result in quicker resolution.