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, kernel 3.10
RHEL 8May 2029August 2029glibc 2.28, kernel 4.18
RHEL 9May 2032August 2032glibc 2.34, kernel 5.14
Debian 10 LTSJune 2024September 2024glibc 2.28, kernel 4.19
Debian 11 LTSJune 2026September 2026glibc 2.31, kernel 5.10
Debian 12 LTSJune 2028September 2028glibc 2.36, kernel 6.1
Ubuntu 20.04 LTSApril 2025July 2025glibc 2.31, kernel 5.13
Ubuntu 22.04 LTSApril 2027July 2027glibc 2.35, kernel 5.19

RHEL in this list means any RHEL binary compatible distribution, for example: AlmaLinux, Rocky Linux, CentOS, etc.

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
Debian 7 LTSMay 2018May 2019glibc 2.13, no systemd
Debian 8 LTSJune 2020June 2021glibc 2.19, systemd (optional)
Debian 9 LTSJune 2022September 2022glibc 2.24, systemd
Ubuntu 18.04 LTSApril 2023July 2023glibc 2.27, systemd

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/os-release
uname -a

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:

da 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="12.34.56.78" --tries=1 -qO - http://myip.directadmin.com

where you'd replace 12.34.56.78 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 how to restart services

Restarting directadmin service using systemd is done with command:

systemctl restart directadmin.service

The script is located at:

/etc/systemd/system/directadmin.service

List of all available services can be pulled with command:

systemctl list-units --all

Using grep is an easy way to find service based on its name or description:

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

My IPs are not being loaded into the network device

After each network restart, the command

systemctl start startips

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:

systemctl start startips

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:
DEVICE=eth0:0
BOOTPROTO=none
ONPARENT=yes
IPADDR=12.34.56.78
NETMASK=255.255.255.255
ONBOOT=yes
ARPCHECK=no

Save/exit.

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

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

Debian

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
   address 12.34.56.78
   netmask 255.255.255.0

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).

If you get the error:

Error, some other host already uses address 1.2.3.4

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

ARPCHECK=no

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:

NM_CONTROLLED=no

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:

sshdconfig=/etc/ssh/sshd_config

to:

sshdconfig=/etc/ssh/sshd_config.placebo

Save/exit, and restart DirectAdmin.

Type:

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.

Manually

To set the system clock, use the date command.

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

Example:

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

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

Last Updated: