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 Name | OS EOL Date | DirectAdmin EOL Date | Comment |
|---|---|---|---|
| RHEL 8 | May 2029 | August 2029 | glibc 2.28, kernel 4.18 |
| RHEL 9 | May 2032 | August 2032 | glibc 2.34, kernel 5.14 |
| Debian 11 LTS | August 2026 | November 2026 | glibc 2.31, kernel 5.10 |
| Debian 12 LTS | June 2028 | September 2028 | glibc 2.36, kernel 6.1 |
| Debian 13 LTS | TBA | TBA | |
| Ubuntu 20.04 LTS | April 2025 | July 2025 | glibc 2.31, kernel 5.13 |
| Ubuntu 22.04 LTS | April 2027 | July 2027 | glibc 2.35, kernel 5.19 |
| Ubuntu 24.04 LTS | April 2029 | July 2029 | glibc 2.39, kernel 6.8 |
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 Name | OS EOL Date | DirectAdmin EOL Date | Comment |
|---|---|---|---|
| January 2022 | |||
| November 2020 | January 2022 | glibc 2.12, no systemd | |
| June 2024 | September 2024 | glibc 2.17 | |
| May 2018 | May 2019 | glibc 2.13, no systemd | |
| June 2020 | June 2021 | glibc 2.19, optional systemd | |
| June 2022 | September 2022 | glibc 2.24 | |
| June 2024 | September 2024 | glibc 2.28 | |
| April 2023 | July 2023 | glibc 2.27 |
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.
- 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
- Create the actual network-scripts file:
cd /etc/sysconfig/network-scripts
vi "ifcfg-eth0:0"
- 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.
- 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.
- 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).
Related Errors
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:
systemctl restart sshd
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
Automatically (recommended)
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 here.
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).