How edit a NIC (Network Interface Card) on Centos 7

1). Check with he command IP a which NICs you have and what they are called, (like; eno1).

2). Change to the directory /etc/sysconfig/network-scripts/

The name of the file to be edited contains the NIC name. For example: ifcfg-eno1

3). Edit the file. E.g. with the NANO editor.

nano ifcfg-eno1

You’ll see something like this, in this case it’s for a fixed IP address.

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eno1
UUID=xxxxx (you’ll see a long unique code)
DEVICE=eno1
ONBOOT=yes
IPADDR=10.10.10.30 (or your IP address)
PREFIX=24 (which is the same as a DNS mask of 255.255.255.0)

 

A typical DHCP setting looks like this:

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eno2
UUID=xxxxx (you’ll see a long unique code)
DEVICE=eno1
ONBOOT=yes

4) Make changes and save them (in the case of NANO by ctr – O to save, and then ctr – X to quit).

5) Restart the network service as follows:

systemctl restart network

 

 

Easiest CLI text editor for Linux

Nano is my favorite pick for a CLI editor when using Linux.

Example for Centos 7:

1) Install:

yum install nano

Typically already installed. No harm in the above command, if already installed it will just give you the feedback ‘nothing to do’.

2) How to use

a) Open a file in the current directory:

nano filename

b) Open a file in another directory:

nano /path/to/directory/myfile.txt

3) Some relevant commands:

Save a file: ctr - O

Exit: ctrl - X (it will prompt you for saving if necessary)

cPanel sends excessive amount of warning emails

If you installed cPanel and get an excessive amount of emails with warnings similar to the one below, there is a solution!

The problem:

You get tenths (sometimes hundreds or even more) emails per day with warnings similar to this:

Resource: Virtual Memory Size
Exceeded: 241 > 200 (MB)
Executable: /opt/cpanel/ea-php70/root/usr/bin/php-cgi
Command Line: /opt/cpanel/ea-php70/root/usr/bin/php-cgi
PID: 16297 (Parent PID:16100)
Killed: No

The warnings can vary, for example the executable may be /opt/cpanel/ea-php72/root/usr/bin/php-cgi if you use PHP 7.2 instead of PHP 7.0 in the example above. Also the executable may be a different one, and the line ‘exceeded’ may show different values.

What causes the emails:

cPanel has a plugin “ConfigServer Security & Firewall” or in short “CSF”.

This plugin has settings which triggers warning messages to the email you set in cPanel. The warning triggered in the above problem is the value in the field ‘PT_USERMEM’ which is set at 200 MB RAM, whilst the executable actually used 241 MB RAM.

Solution 1: Change the trigger value

By changing the value at which the emails are triggered in CSF’s settings, you can ensure you get less warnings.

  • Login to your server via WHM as root
  • Go to the bottom of the left menu to the Plugins section
  • Select “ConfigServer Security & Firewall”.
  • Click on the ‘CSF’ tab
  • Click on “Firewall Configuration”
  • Go to the field “PT_USERMEM’
  • Change the value from 200 (in our example, yours could be set differently) to anything between 0 and 1024. Setting 0 means no more emails will be sent as a consequence of this trigger. Setting the trigger to 1024 means you will still get warnings if there are truly excessive usages, which may be interesting to know. What value to set depends (sorry, I hate that too) on your systems resources such as the amount of RAM. I set mine at 1024 as I have plenty of RAM.
  • Restart CSF by scrolling down to the bottom and clicking “Change”, waiting until the changes are confirmed, and then clicking the button which then shows “Restart csf+lfd”

Solution 2: Ignore the executable, no more warnings

To completely ignore the executable that triggered the warning from now on, and receive no more emails, do this:

  • Log in via SSH using root as user
  • Find the file csf.pignore
    • In my case (CENTOS) this is at etc/csf/csf.pignore
    • In other Linux distributions this might be elsewhere
  • Add the executable to be ignored (if it is not already present):
    • In our example the executable was as follows: /opt/cpanel/ea-php70/root/usr/bin/php-cgi
    • Therefore we will add the following line in csf.pignore:
      • exe:/opt/cpanel/ea-php70/root/usr/bin/php-cgi
    • If your executable was different, add the one that caused the emails to be sent
      • For example if you use PHP 7.2 instead of PHP 7.0 as in the example, the executable in the warning would have been:
        • /opt/cpanel/ea-php72/root/usr/bin/php-cgi
      • And therefore the line to add to csf.pignore would be:
        • exe:/opt/cpanel/ea-php72/root/usr/bin/php-cgi
    • Restart CSF (see above at Solution 1, or find the SSH command appropriate for your Linux distribution)

 

Centos 7 – Bug in a Linux kernel, how to solve this structurally

Once in a blue moon the inevitable happens. A buggy Linux kernel is updated through your ‘yum update’ action. It happened to me. Here are the steps I took:

1) Check which kernels you have installed:

rpm -qa kernel

A list of kernels is displayed.

2) If there are more than (say) 3 kernels, do some housekeeping:

a) If yum utilities are not already installed, do this first:
yum install yum-utils -y

b) Next, delete* old kernels, (apart from the most recent 3 kernels):
package-cleanup --oldkernels --count=3

3) Now the tricky part. Delete the buggy kernel. For example, kernel-3.10.0-693.11.6.el7.x86_64 did not work for a XEN virtualized server.

yum remove kernel-3.10.0-693.11.6.el7.x86_64

4) The structural part; until the kernel is outdated by 3 versions, do not update kernels for a little while:

yum -y update --exclude=kernel*

5) Granted, this can hardly be classified as structural. But it works until the kernel has been superseded by 3 new versions, then you can go back to your usual yum update command, and no longer exclude the kernel from being updated.

 

*Note: If a buggy kernel is already active on your server step 2b may not work, most Centos installs prevent deletion of your active kernel. Google is your friend for this more complex scenario which is outside the scope of this ‘memory’.