Warning about migrating to Centos 7

jojolafrite

Verified User
Joined
Sep 19, 2014
Messages
53
I just want to raise a warning for those who want to migrate to centos 7. I think Centos 7 isn't mature enough for moving a server to Centos 7 in production.

1.
I think centos 7 isn't still mature enough to be used in production. There are issues with network interfaces right now (with the last version). For instance, if you have an updated centos 7 version right now and do a >systemctl restart network & then >systemctl status network you may see an error with loopback interface.

2.
In centos 7, they have implemented something called consistent device network device naming. In other words, they changed the eth0 naming. I really don't understand them. It was stable with centos 6.6 and they have decided to change this naming system.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/ch-Consistent_Network_Device_Naming.html

It looks like it produces issues for bridges (and people who use VPS, most of us).

3. i have myself crashed stable versions of centos 7 Virtual machines. So, to me it looks like it is not that stable. This issue never happened to me with centos 6.5 or centos 6.6.

4. the new systemd module also produces errors.

5. Packages in Centos 7 are older than in centos 6.6 as they aren't still updated.
"several system-critical packages are of a higher version number in CentOS 6.6 than they are in CentOS 7"
reference: http://wiki.centos.org/TipsAndTricks/CentOSUpgradeTool


considering that the support for centos 6.6 goes up to 2020 & that directadmin works very well with centos 6.6, it is possible to wait for centos 7 to get more stable.
 
Last edited:
I already decided not to change to Centos 7 for as long as possible due to the stupid changes with starting daemons and the namechange of network devices. It was not needed and only causing irritation due to the fact that it's deviating compared to other distro's like Debian/Ubuntu so you have to keep several different procedures in mind. That was not necessary.

I really don't understand why these basic things had to be changed while theyre already working like a charm for so many years. I don't mind updating and following modern things, but some basic things are better left unchanged.
 
I already decided not to change to Centos 7 for as long as possible due to the stupid changes with starting daemons and the namechange of network devices. It was not needed and only causing irritation due to the fact that it's deviating compared to other distro's like Debian/Ubuntu so you have to keep several different procedures in mind. That was not necessary.

I really don't understand why these basic things had to be changed while theyre already working like a charm for so many years. I don't mind updating and following modern things, but some basic things are better left unchanged.

wise words, really.
I 100% agree with you.
 
I have been running centos7 for about 7 months without issue, on the network configs, you can use the older method for configuration to work around that. Nothing else has been an issue with production servers. There were a couple of quirks we ran into with DA, however John fixed them up in no time and applied the fixes into production.

Don't let this topic hole you back imo, it's running great!
 
I also don't see any serious issues with CentOS 7, with one exception. The scripts startips does not get executed on server boot.
 
Don't let this topic hole you back imo, it's running great!
That might be the case, but I'm sorry, I'm getting to old for this crap. Have to search and learn about the systemctl stuff again, while /etc/init.d scripts are used on several distro's. IMHO the change was unneeded, still don't understand the benefits of it.

We will probably be running Centos 6 as long as possible. Unless there are real benefits which gives reason for upgrading to 7.
But that choice has to make everyone for themselves.
 

If it would be that simple :)

Code:
[root@server ~]# systemctl enable startips.service
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
[root@server ~]#


In my case it would be:

Code:
cp /usr/local/directadmin/scripts/startips.service /etc/systemd/system/startips.service
systemctl enable startips.service
 
Since i have written this thread, changes has been made, now centos 7.1 has a nice old school /etc/sysconfig/network-scripts/ifcfg-eth0

I don't see any problems in /var/log/messages.

I have installed directadmin and it looks good.

I have uninstalled firewalld & intalled iptables and i have all the good from centos 6.6 and all the good from centos 7.1
 
Thank you for the update. That looks beeter.
I'm still wondering however why they changed the service starting, there was nothing wrong with it.

But next server we will probably get Centos 7 too.
 
Thank you for the update. That looks beeter.
I'm still wondering however why they changed the service starting, there was nothing wrong with it.

But next server we will probably get Centos 7 too.

Let's talk about the new service management systemctl. I must say it was useful for me because now you can see the last few lines of the lof belonging to a service when you use the command status.

For instance, if you want to see the status for service iptables and you type systemctl status iptables
you get many more information than before:

2hztuyv.png


Also systemctl replaces chkconfig. Now when you want to add a service at startup you do:
systemctl enable iptables.
 
Back
Top