Supported Operating Systems and EOL policy
We should all be keeping our systems up to date. This includes the operating system.
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 7||June 2024||September 2024||glibc 2.17, systemd, applies also to other RHEL binary compatible systems|
|RHEL 8||May 2029||August 2029||glibc 2.28, systemd, applies also to other RHEL binary compatible systems (AlmaLinux, Rocky Lilnux, etc. )|
|Debian 9 LTS||June 2022||September 2022||glibc 2.24, systemd|
|Debian 10 LTS||June 2024||September 2024||glibc 2.28, systemd|
|Debian 11 LTS||June 2026||September 2026||glibc 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 Name||OS EOL Date||DirectAdmin EOL Date||Comment|
|January 1st, 2022|
|November 2020||May 2021||glibc 2.12, no systemd|
|November 2020||January 1st, 2022||glibc 2.12, no systemd, June 2024 (security backports only)open in new window|
|May 2018||May 2019||glibc 2.13, no systemd|
|June 2020||June 2021||glibc 2.19, systemd (optional)|
- CentOSopen in new window
- RHELopen in new window
- Debianopen in new window
- Debian LTSopen in new window
- FreeBSDopen in new window
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 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:
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="22.214.171.124" --tries=1 -qO - http://myip.directadmin.com
where you'd replace 126.96.36.199 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:
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.
- First, we need to know on which device to add the additional IP. Most of the time, it will be , but not always. Type:
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=188.8.131.52 NETMASK=255.255.255.255 ONBOOT=yes ARPCHECK=no
- 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.
- Confirm it's loaded by checking ifconfig again:
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 184.108.40.206 netmask 255.255.255.0
Once set, then type
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" "220.127.116.11" netmask 255.255.255.255 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 18.104.22.168 netmask 255.255.255.255"
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 22.214.171.124
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
Change the following in the directadmin.conf from:
Save/exit, and restart DirectAdmin.
and then just double check one more time that there are no AllowUsers lines in your
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:
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