OS General

Supported Operating Systems and EOL policy

DirectAdmin software manages configuration of Operating System and various services running inside it. This makes it really dependent on the OS.

To stay compatible with latest Operating Systems and services DirectAdmin needs continuous updates and adjustments. But this also implies we can not be supporting old OS indefinitely.

Our policy is to follow official OS end-of-life dates and extend support for couple more months to ensure smoother transition to new OS version.

If you are running an end-of-life operating system, then no aspect of DirectAdmin functionality is guaranteed. You will no longer receive version updates or security patches. If infrastructure (ours or the Internet) changes, even licensing functionality may permanently fail making DirectAdmin non functional.

Please note that this refers only to DirectAdmin functionality. Already running services like websites, databases, e-mail, etc. are not terminated if DA becomes non-functional.

Below is a list of the end-of-life dates for a given OS. To its right is the date that we will no longer support that OS.

OS NameOS EOL DateDirectAdmin EOL DateComment
RHEL 7June 2024September 2024glibc 2.17, systemd, applies also to other RHEL binary compatible systems
RHEL 8May 2029August 2029glibc 2.28, systemd, applies also to other RHEL binary compatible systems (AlmaLinux, Rocky Lilnux, etc. )
RHEL 9May 2032August 2032glibc 2.34, systemd, applies also to other RHEL binary compatible systems (AlmaLinux, Rocky Lilnux, etc. )
Debian 9 LTSJune 2022September 2022glibc 2.24, systemd
Debian 10 LTSJune 2024September 2024glibc 2.28, systemd
Debian 11 LTSJune 2026September 2026glibc 2.31, systemd

Please note that OS EOL dates might be changed depending on the circumstances. We will be announcing any changes in the forum.

No longer supported Operating Systems and Distros:

OS NameOS EOL DateDirectAdmin EOL DateComment
FreeBSD (any)January 2022
CentOS 6 32-bitNovember 2020May 2021glibc 2.12, no systemd
CentOS 6 64-bitNovember 2020January 2022glibc 2.12, no systemd, June 2024 (security backports only)open in new window
Debian 7 LTSMay 2018May 2019glibc 2.13, no systemd
Debian 8 LTSJune 2020June 2021glibc 2.19, systemd (optional)

Related pages:

Which OS am I using?

During support requests, we will often ask a client which OS version they're using. Providing us with the output from the following commands will help us to accurately determine which OS version you're running.

cat /etc/redhat-release
cat /etc/debian_version
uname -r
uname -m

Some of the above files may not exist, but their non-existence will help us figure out which OS you have.

In addition to figuring out the OS version you're running, we will usually ask you which OS the DirectAdmin binaries are compiled on. To figure that out, you can either go to Admin Level -> Licenses/Updates, or from ssh, you can type:

/usr/local/directadmin/directadmin info

What IP does my system use for outbound connections

If you're trying to figure out what IP your system uses for outbound connections, you can use wget to call this page:

wget --tries=1 -qO - http://myip.directadmin.com

which should display the IP that connected to it.

If you want to test which IP connects outbound when you bind to different local IPs, use the --bind-address option for your local IP eg:

wget --bind-address="" --tries=1 -qO - http://myip.directadmin.com

where you'd replace with the local IP to bind to (useful for LANs or if you're on a VPS where routing for outbound connections is determined by another component of the environment (like a router or master OS).

To check the IP on SSL connections (in case port 443 is being routed differently), test like this:

wget --no-check-certificate --tries=1 -qO - https://myip.directadmin.com

Systemd vs init.d, how to restart services

Operating Systems like CentOS 7 and Debian 8 both support systemd, and DA is expecting that by default.

A systemd OS will use something like this for restarts:

systemctl restart httpd.service

The script is located at:


The traditional init.d uses a more direct script restart with:

/etc/init.d/httpd restart

To get a list of all available services run:

systemctl list-units --all

And use grep to find something specific:

systemctl list-units --all  | grep -i maria
mariadb.service        loaded    active   running   MariaDB database server

CustomBuild itself will auto-detect this for the usual service boot scripts, but the DA binaries do not as it's an internal default.

If your OS doesn't follow the expected default, such as Debian 8 which uses init.d, that's fine. You just need to set


in the directadmin.conf .

My IPs are not being loaded into the network device

After each network restart, the command

service startips start

needs to be run. The startips script is run at bootup time, but on some systems, it seems that the network restart is called again after the initial startup.

One solution is to run:

service startips start

after each startup, but admins cannot be expected to watch their boxes all day long.

An easier solution is to set up the aliased IPs in the network settings so that they're loaded along with the network, no matter how many times it's restarted. Please see the guide below.

Manually adding an additional IP to network device

If you need to manually add an IP to your device so that it's added by the system ("network" script) and not DA ("startips" script), you can do so by adding a network-script for the new IP.

Redhat/CentOS based systems

We'll use an IP example of , so replace all instances of that value with your own IP.

  1. First, we need to know on which device to add the additional IP. Most of the time, it will be , but not always. Type:
ip a

to get a listing of your current devices. See which device your server IP is using (Eg: eth0). Then, for your additional IP, you'll just add another number to it with a colon, eg: eth0:0

  1. Create the actual network-scripts file:
cd /etc/sysconfig/network-scripts
vi "ifcfg-eth0:0"
  1. In that file, add the following code:


  1. Restart your network and pray it works:
service network restart
service startips start

The "startips" script is just for the DA-controlled IPs. You need to run it after restarting your network to load all IPs controlled by DA. Your own IP should have been loaded into the device with the "network restart" step.

  1. Confirm it's loaded by checking ifconfig again:
ip a


Although we don't have much testing for this with Debian, try editing /etc/network/interfaces and, at the bottom of the file (assuming you already have eth0 listed there), add eth0:0:

auto eth0:0
allow-hotplug eth0:0
iface eth0:0 inet static

Once set, then type

ifup "eth0:0"

As mentioned, this has very limited testing, so be absolutely sure that the settings you're adding are correct. It's possible that the box can become inaccessible if an error is made at this point (which is why we can't do this for you).

FreeBSD ALPHA testing

Assuming your main device name is ,


ifconfig "em0" "" netmask alias

This should load the IP into the em0 device. Once this is confirmed to have worked, edit /etc/rc.conf and, below the line that starts with:


you'll add an alias line that looks like this:

ifconfig_em0_alias0="inet netmask"

Restart the network:

/etc/rc.d/netif restart && /etc/rc.d/routing restart

If you get the error:

Error, some other host already uses address

then add this line to your ifcfg-eth0:0 file:


If you get the error:

Error: Connection activation failed: The connection is not for this device.

then add this to your ifcfg-eth0:0 file:


Starting sshd: too many allow users

If you get the following error when trying to start sshd:

Starting sshd: /etc/ssh/sshd_config line 371: too many allow users

that means that there are too many "AllowUsers" lines in the file.

What you can do is remove all AllowUsers lines from the /etc/ssh/sshd_config, and edit /usr/local/directadmin/conf/directadmin.conf .

Change the following in the directadmin.conf from:




Save/exit, and restart DirectAdmin.


touch /etc/ssh/sshd_config.placebo

and then just double check one more time that there are no AllowUsers lines in your /etc/ssh/sshd_conf file.

Restart SSHd with:

service sshd restart

What this will do is have DA add/remove users to a file that is a placebo, which doesn't have any effect. As long as there are no AllowUsers lines in the main /etc/ssh/sshd_config file, then all users are allowed to connect.

If one or more AllowUsers lines are present in the main sshd_config file, then only those users can connect, hence the importance to not have any added to the main file. Make fully sure you've restarted DA before logging out, else you might allow SSH for only 1 user, thus blocking root or any other user SSH access.

Note that the /etc/ssh/sshd_config file can be edited from within the Admin Level -> File Editor, so don't fret if you mess it up. You can fix it through DA.

Setting the system date and clock

To sync your server with the DirectAdmin atomic clock in Boulder, Colorado, use either ntp or rdate.

ntp is a newer, more accurate method of setting the date:

/usr/sbin/ntpdate -b -u ntp.directadmin.com

For any operating system, if you have the rdate program, you can simply type:

rdate -s rdate.directadmin.com

Note: If the value set by rdate/ntpdate isn't correct, then you likely have the wrong timezone specified. Commands like system-config-date or redhat-config-date can set it up for you. Else you'd need to create a symbolic link from one of the timezones in /usr/share/zoneinfo to /etc/localtime, eg:

mv /etc/localtime /etc/localtime.moved
ln -s /usr/share/zoneinfo/Canada/Mountain /etc/localtime

You should also update your php.ini file(s) to use the correct timezone. Edit the value:

date.timezone = "UTC"

and change UTC to your timezone. Valid PHP timezones are listed hereopen in new window.


To set the system clock, use the date command.

For Redhat Systems, use the following format:

date --set="Mmm DD HH:MM:SS YYYY"


date --set="Oct 20 15:44:29 2019"

For FreeBSD systems, use the following format:



date 1910201544

Which will set the date/time to 2019, October 20th, 15:44 (3:44pm).

Error libz.so.1: no version information available

If you see the error:

/usr/local/lib/libz.so.1: no version information available (required by python)

it is because of the version of libz installed. The reason for the current version has to do with the version of libz that libxml2 requires. A newer version of both will resolve the issue, but due to many reported issues with this update, we reverted to the older version of libz and libxml2. Note that the warning is not going to hurt anything, so it can be ignored.

We do not recommend using the options below.

If you still wish to update libz and libxml2 to their newer versions to avoid the message, type:

cd /usr/local/directadmin/custombuild
./build update
./build set new_zlib yes
./build update_data
./build zlib
./build libxml2
./build php n

Related forum threadopen in new window

Last Updated: