Supported Operation Systems and EOL policy

We should all be keeping our systems up to date. This includes the operating system.

Effective October 1st, 2013, our policy for supported operating systems will be to cease support on them 1 year after that OS has reached end-of-life by its creator.

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 EOLDA EOL
CentOS 4February 2012October 2013
CentOS 5March 2017March 2018
CentOS 6 32-bitNovember 2020May 2021
CentOS 6 64-bitNovember 2020January 1st, 2022 June 2024 (security backports only)open in new window
CentOS 7June 2024September 2024
CentOS 8December 2021March 2022
Fedora All VersionsOctober 2013
FreeBSD 5May 2008October 2013
FreeBSD 6November 2010October 2013
FreeBSD 7February 2013February 2014
FreeBSD 8August 2015August 2016
FreeBSD 9December 2016December 2017
FreeBSD 10October 2018October 2019
FreeBSD 11January 1st, 2022
FreeBSD 12January 1st, 2022
Debian 4February 2010October 2013
Debian 5February 2012October 2013
Debian 6 LTSFebruary 2016February 2017
Debian 7 LTSMay 2018May 2019
Debian 8 LTSMay 2020May 2021
Debian 9 LTSMay 2022August 2022

For discussion, please see the related forum threadopen in new window.

Related pages: CentOSopen in new windowDebianopen in new windowFreeBSDopen 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
1
2
3
4
5

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 o
1

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
1

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
1

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
1

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
1

The script is located at:

/etc/systemd/system/httpd.service
1

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

/etc/init.d/httpd restart
1

To get a list of all available services run:

systemctl list-units --all
1

And use grep to find something specific:

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

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

systemd=0
1

in the directadmin.conf .

My IPs are not being loaded into the network device

After each network restart, the command

service startips start
1

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
1

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
1

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
2
  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
1
2
3
4
5
6
7

Save/exit.

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

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
1

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
1
2
3
4
5

Once set, then type

ifup "eth0:0"
1

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 ,

Type:

ifconfig "em0" "12.34.56.78" netmask 255.255.255.255 alias
1

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:

ifconfig_em0=...
1

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

ifconfig_em0_alias0="inet 12.34.56.78 netmask 255.255.255.255"
1

Restart the network:

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

If you get the error:

Error, some other host already uses address 1.2.3.4
1

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

ARPCHECK=no
1

If you get the error:

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

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

NM_CONTROLLED=no
1

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
1

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
1

to:

sshdconfig=/etc/ssh/sshd_config.placebo
1

Save/exit, and restart DirectAdmin.

Type:

touch /etc/ssh/sshd_config.placebo
1

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
1

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
1

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

rdate -s rdate.directadmin.com
1

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
1
2

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

date.timezone = "UTC"
1

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.

For Redhat Systems, use the following format:

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

Example:

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

For FreeBSD systems, use the following format:

date YYMMDDHHMM
1

Example:

date 1910201544
1

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

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
1
2
3
4
5
6
7

Related forum threadopen in new window

Last Updated: 6/23/2021, 9:36:08 PM