VMware rename CentOS 7 NIC names

CentOS 7 virtual machines on VMware will by default use predictable network device naming for network interfaces on the machine, causing their names to be in enoXXXXXXXX format.

This will cause issues when adding 10 or more additional IPs in WHM, as network interface name will be longer than the 15 characters.

Maximum length supported for network interface name on cPanel servers is 15 characters.

When starting ipaliases service, only first 9 additional IPs will be added, and for rest of the IPs error “RTNETLINK answers: Numerical result out of range” will be shown, and IPs will not be shown in ip addr, or ifconfig output.

[[email protected] ~]# /scripts/restartsrv_ipaliases
Waiting for "ipaliases" to stop ...finished.
Waiting for "ipaliases" to start ...finished.
Service Status
Startup Log
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Bringing up eno33559296:cp14 RTNETLINK answers: Numerical
result out of range
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Routing 204.93.248.69 RTNETLINK answers: Invalid argument
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Bringing up eno33559296:cp15 RTNETLINK answers: Numerical
result out of range
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com ipaliases[233833]: Routing 204.93.248.70 RTNETLINK answers: Invalid argument
 Oct 03 20:29:20 server.example.com ipaliases[233833]: [FAILED]
 Oct 03 20:29:20 server.example.com systemd[1]: Started cPanel IP aliases service.
Log Messages
 Oct 3 20:29:20 server ipaliases: [FAILED]
 Oct 3 20:29:20 server ipaliases: Routing x.x.x.x RTNETLINK answers: Invalid argument
 Oct 3 20:29:20 server ipaliases: [FAILED]
 Oct 3 20:29:20 server ipaliases: Bringing up eno33559296:cp15 RTNETLINK answers: Numerical result out of range

To resolve the issues, network devices can be renamed back to old ethX type of naming.

To rename network devices to old names following steps are needed.

  1. Edit /etc/sysconfig/grub
  2. Update GRUB configuration with new kernel parameters
  3. Rename network files
  4. Edit renamed network files
  5. Reboot the server

To rename devices do the following

Edit /etc/sysconfig/grub

Find a line containing “GRUB_CMDLINE_LINUX”, and append “net.ifnames=0 biosdevname=0“ on the line.

File should look something like this.

[[email protected] ~]# cat /etc/sysconfig/grub
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=myvg/rootvol rhgb quiet net.ifnames=0 biosdevname=0"
GRUB_DISABLE_RECOVERY="true"

Update GRUB configuration with new kernel parameters, with following command:

grub2-mkconfig -o /boot/grub2/grub.cfg

Rename enoXXXXXXXX network files of all interfaces to ethX network file.

For example:

mv /etc/sysconfig/network-scripts/ifcfg-eno16777984 /etc/sysconfig/network-scripts/ifcfg-eth0
mv /etc/sysconfig/network-scripts/ifcfg-eno33557248 /etc/sysconfig/network-scripts/ifcfg-eth1

This will rename file ifcfg-eno16777984, to ifcfg-eth0, renaming interface eno16777984 to eth0, and will rename file ifcfg-eno33557248, to ifcfg-eth1, renaming interface eno33557248, to eth1.

Edit new ethX network files.

Replace value of both NAME and DEVICE field with new ethX names.

File should look something like this.

[[email protected] ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
BOOTPROTO=static
NAME=eth0
UUID=b02f4abf-f6da-4ad4-b800-4abf4fe1d50d
DEVICE=eth0
ONBOOT=yes
NM_CONTROLLED=yes
IPADDR=x.x.x.x
NETMASK=255.255.255.0
GATEWAY=x.x.x.1

Reboot the server, and you should now see network interfaces using old CentOS 6 style names.

Additional changes for cPanel servers

Change public network interface in Basic cPanel & WHM Setup.

Go to Home »Server Configuration »Basic cPanel & WHM Setup and change public interface from old enoXXXXXXXX to new ethX name.

Change public interface to new name
Change public interface to new name

Restart ipaliases service with /scripts/restartsrv_ipaliases.

Reset root password on CentOS 6 machine

If you have forgotten root user password on your CentOS 6 machine, you can reset the password to new value, without knowing the old one, by booting the machine to single user mode, and resetting the password with passwd command.

Boot to single user mode

During the CentOS boot process, you will be presented with a countdown before CentOS boot process actually begins to load the OS.

Press any key to enter the GNU GRUB menu.

CentOS 6 boot countdown
CentOS boot countdown

On the GNU GRUB menu highlight the kernel you want to boot, and press ‘e’ key to edit the kernel commands before booting.

CentOS 6 kernel select
CentOS 6 kernel select

Once you have entered the kernel edit mode, find the line beginning with kernel, and highlight it, and press ‘e’ key to edit it.

Edit kernel line
Edit kernel line

On the end of the line add the word ‘single’, with white space before ‘single’, and press ENTER to accept the change.

Add single to then end of the kernel line
Add single to then end of the kernel line

Boot the machine with the edited kernel argument, and you will be logged in as root in single user mode.

Now just issue passwd command, and enter the new password two times, when asked.

Change password with passwd command
Change password with passwd command

Once you have changed the password, reboot the machine, and log to it with your new root password.

Yum and curl returning “Illegal instruction (core dumped)” on Xen

When running yum or curl commands on a CentOS 6 XenServer Virtual Machine you might be getting an “Illegal instruction (core dumped)” error returned in your console output.

[email protected] [~]# yum update
Loaded plugins: fastestmirror, rhnplugin
Setting up Update Process
Loading mirror speeds from cached hostfile
 * base: mirror.us.leaseweb.net
 * cloudlinux-x86_64-server-6: xmlrpc.cln.cloudlinux.com
 * extras: mirror.teklinks.com
 * updates: mirror.teklinks.com
Illegal instruction (core dumped)

The issue is due to Python attempting to execute a CPU opcode advertised as available by the server’s host node virtualization system (XEN), but is not actually supported by the host node’s hardware.

Workaround

Issue can be resolved by running export NSS_DISABLE_HW_AES=1, and then running yum update, to update to newer packages, after which issue should not be happening anymore.

[email protected] [~]# export NSS_DISABLE_HW_AES=1
[email protected] [~]# yum -y update
References:

https://www.centos.org/forums/viewtopic.php?t=58002

https://forums.cpanel.net/threads/kvm-xen-hw_aes-detection-issues-yum-update-illegal-instruction.551681/

CSF chattr and urlget warnings on restart

On most CentOS 7 machines you might be getting this type of warnings when restarting or updating ConfigServer Firewall (CSF), if you are missing certain commands or packages on your server.

*WARNING* Binary location for [CHATTR] [/usr/bin/chattr] in /etc/csf/csf.conf is either incorrect, is not installed or is not executable
*WARNING* Missing or incorrect binary locations will break csf and lfd functionality
*WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

You also might be getting notifications in mail from your Cron Daemon with subject /usr/sbin/csf -u and following message:

*WARNING* URLGET set to use LWP but perl module is not installed, reverting to HTTP::Tiny

This warnings are showing because of missing packages not being installed on the server, and chattr command doesn’t exist.

[[email protected] ~]# type chattr
-bash: type: chattr: not found

To resolve CHATTR warning, you need to install e2fsprogs with

yum -y install e2fsprogs

To resolve URLGET warning you need to install perl-libwww-perl with

yum -y install perl-libwww-perl with

If you are getting following warning by mail notifications, or when running csf -u, you are missing perl-LWP-Protocol-https package.

[[email protected] ~]# csf -u
Oops: Unable to download: Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)

Install perl-LWP-Protocol-https with:

yum -y install perl-LWP-Protocol-https

You might also be getting a following warning, if you don’t have host or unzip commands installed on your server.

*WARNING* Binary location for [UNZIP] [/usr/bin/unzip] in /etc/csf/csf.conf is either incorrect, is not installed or is not executable
*WARNING* Binary location for [HOST] [/usr/bin/host] in /etc/csf/csf.conf is either incorrect, is not installed or is not executable

To resolve HOST warning, you needs to install bind-utils package with

yum -y install bind-utils

To resolve UNZIP warning you need to install unzip package with

yum -y install unzip

tl;dr required packages for CSF

If you are getting any kind of warnings when doing csf -r on CentOS 7 server make sure you have following packages installed.

iptables-services
unzip
bind-utils
perl-libwww-perl
e2fsprogs
perl-LWP-Protocol-https

Needed packages can be installed with following commands:

yum -y install iptables-services
yum -y install unzip
yum -y install bind-utils
yum -y install perl-libwww-perl
yum -y install e2fsprogs
yum -y install perl-LWP-Protocol-https

References:

http://forum.configserver.com/viewtopic.php?t=8864

http://www.liquidweb.com/kb/csf-config-server-firewall-installation/

https://community.centminmod.com/threads/ensure-perl-crypt-ssleay-perl-net-ssleay-are-installed-for-csf-firewall.2183/

systemd conflicts with initscripts during yum update

When running yum update on CentOS 7 OpenVZ container you might get a following error:

--> Processing Conflict: systemd-219-19.el7.x86_64 conflicts initscripts < 9.49.28-1 
--> Finished Dependency Resolution
Error: systemd conflicts with initscripts-9.49.17-1.el7.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Exact version I was running on this server is CentOS Linux release 7.1.1503 (Core), and updates were failing due to them requiring a newer systemd version, which required a newer version, v9.49.28 at least,  of initscripts installed.

Reason why systemd was conflicting with current version of initscripts, instead of just updating them to newer version, was that initscripts were excluded from update in yum.conf file.

[[email protected] ~]# grep exclude /etc/yum.conf
exclude=initscripts*

There are no default exclude packages in default CentOS/RHEL installs, and it wasn’t put there by me, so question is why was initscripts excluded from updates.

Issues with initscripts v9.49.24 in CentOS 7 OpenVZ containers

It turns out there were some issues with initscripts v9.49.24, which seemed to introduce problems with network connectivity on CentOS 7 OpenVZ VPS machines.

https://vpsboard.com/topic/1908-creating-cpanel-openvz-template-wwhm-setup-wizard-fix/?page=2
https://forum.proxmox.com/threads/centos-7-openvz-template-in-pve-3-4-issues.21808/

I commented out exclude=initscripts* from yum.conf, and checked the currently available version.

[[email protected] ~]# grep exclude /etc/yum.conf
#exclude=initscripts*
[[email protected] ~]# yum check-updates initscripts
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirrors.greenmountainaccess.net
 * epel: mirror.nexcess.net
 * extras: mirrors.lga7.us.voxel.net
 * updates: mirror.dattobackup.com
 * webtatic: us-east.repo.webtatic.com

initscripts.x86_64                                               9.49.30-1.el7                                                base

Current version is v9.49.30, so I presumed issues with v9.49.24 were corrected in this version, and proceeded with the update.

Update has completed successfully, and all packages including initscrips were updated to latest version, as was CentOS.

[[email protected] ~]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)

I haven’t noticed any network or any other issues on the VPS after the upgrade, so it seems any network issues from v9.49.24, don’t exist in v9.49.30.

[[email protected] ~]# rpm -qa | grep initscripts
initscripts-9.49.30-1.el7.x86_64