How To Fix “Device eth0 does not seem to be present, delaying initialization” Error!!

Try to start Eth0 device:
# ifup eth0
Device eth0 does not seem to be present, delaying initialisation

First step – check the MAC Addresses are set correctly:-
[root@centOS network-scripts]#    cat ifcfg-eth0 | grep HWA

HWADDR=”08:00:27:FC:73:2A”

[root@centOS network-scripts]#    cat ifcfg-eth1 | grep HWA

HWADDR=”08:00:27:09:E1:75?

[root@centOS network-scripts]#    cat ifcfg-eth2 | grep HWA

HWADDR=”08:00:27:31:2D:D6?

[root@centOS network-scripts]# ip -o link

1: lo: mtu 16436 qdisc noqueue state   UNKNOWN \    link/loopback   00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eth0: mtu 1500 qdisc   pfifo_fast state UP qlen 1000\      link/ether 08:00:27:fc:73:2a brd ff:ff:ff:ff:ff:ff

3: eth8: mtu 1500 qdisc   pfifo_fast state UP qlen 1000\      link/ether 08:00:27:09:e1:75 brd ff:ff:ff:ff:ff:ff

4: eth2: mtu 1500 qdisc   pfifo_fast state UP qlen 1000\      link/ether 08:00:27:31:2d:d6 brd ff:ff:ff:ff:ff:ff

Theres no eth1 but there is an eth8. Lets check what is there in dmesg:
root@centOS network-scripts]# dmesg | grep eth1

e1000 0000:00:08.0: eth1: (PCI:33MHz:32-bit) 08:00:27:09:e1:75

e1000 0000:00:08.0: eth1: Intel(R) PRO/1000 Network Connection

udev: renamed network interface eth1 to eth8.

So udev decided to rename my interface, Why is this? A little look at /etc/udev/rules.d/70-persistent-net.rules revealed the answer:-
[root@centOS ~]# cat /etc/udev/rules.d/70-persistent-net.rules |   grep “08:00:27:09:e1:75?

SUBSYSTEM==”net”, ACTION==”add”,   DRIVERS==”?*”, ATTR{address}==”08:00:27:09:e1:75?,   ATTR{dev_id}==”0x0?, ATTR{type}==”1?,   KERNEL==”eth*”, NAME=”eth1?

SUBSYSTEM==”net”, ACTION==”add”,   DRIVERS==”?*”, ATTR{address}==”08:00:27:09:e1:75?,   ATTR{dev_id}==”0x0?, ATTR{type}==”1?,   KERNEL==”eth*”, NAME=”eth8?

Looks like there are mulitple entries for the same MAC address. Removed the incorrect entry and restart the interface using below command.
# ifup eth0
Thats it..

Cron

The software utility Cron is a time-based job scheduler in Unix-like computer operating systems. People who set up and maintain software environments use cron to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals. It typically automates system maintenance or administration—though its general-purpose nature makes it useful for things like connecting to the Internet and downloading email at regular intervals.

Cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule. The crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept. Users can have their own individual crontab files and often there is a system wide crontab file (usually in /etc or a subdirectory of /etc) that only system administrators can edit.

For Scheduling Repetitive Jobs: crontab

You can schedule routine system administration tasks to execute daily, weekly, or monthly by using the crontab command.
Daily crontab system administration tasks might include the following:

• Removing files more than a few days old from temporary directories
• Executing accounting summary commands
• Taking snapshots of the system by using the df and ps commands
• Performing daily security monitoring
• Running system backups

Weekly crontab system administration tasks might include the following:

• Rebuilding the catman database for use by the man -k command
• Running the fsck -n command to list any disk problems

Monthly crontab system administration tasks might include the following:

• Listing files not used during a specific month
• Producing monthly accounting reports

Controlling Access to the crontab Command

You can control access to the crontab command by using two files in the /etc/cron.d directory: cron.deny and cron.allow. These files permit only specified users to perform crontab command tasks such as creating, editing, displaying, or removing their own crontab files.
The cron.deny and cron.allow files consist of a list of user names, one user name per line.
These access control files work together as follows:

• If cron.allow exists, only the users who are listed in this file can create, edit, display, or remove crontab files.
• If cron.allow does not exist, all users can submit crontab files, except for users who are listed in cron.deny.
• If neither cron.allow nor cron.deny exists, superuser privileges are required to run the crontab command.

Superuser privileges are required to edit or create the cron.deny and cron.allow files.

Note:

• Check for the job errors in /var/spool/mail/username file.
• Escape percent (%) sign with backslash in command line while scheduling a job.

January 19, 2038

What will happen on January 19, 2038?

On this date the Unix Time Stamp will cease to work due to a 32-bit overflow. Before this moment millions of applications will need to either adopt a new convention for time stamps or be migrated to 64-bit systems which will buy the time stamp a "bit" more time.

 What is the unix time stamp?

The unix time stamp is a way to track time as a running total of seconds. This count starts at the Unix Epoch on January 1st, 1970 at UTC. Therefore, the unix time stamp is merely the number of seconds between a particular date and the Unix Epoch. It should also be pointed out (thanks to the comments from visitors to this site) that this point in time technically does not change no matter where you are located on the globe. This is very useful to computer systems for tracking and sorting dated information in dynamic and distributed applications both online and client side.

GHOST: glibc vulnerability (CVE-2015-0235): Release Date:2015-01-27

A very serious security problem has been found in the GNU C Library (Glibc) called GHOST. How can I fix GHOST vulnerability and protect my Linux server against the attack? How do I verify that my server has been fixed against the Glibc GHOST vulnerability? And what is this all about?

A heap-based buffer overflow was found in glibc's __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() glibc function calls. A remote attacker able to make an application call either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the application.
See more information about CVE-2015-0235 from MITRE CVE dictionary and NIST NVD.

Link to download patch for Oracle Linux:
http://linux.oracle.com/cve/CVE-2015-0235.html
Link to download patch for RHEL:
https://access.redhat.com/articles/1332213

An easy way to fix the GHOST vulnerability on a CentOS/RHEL/Fedora/Scientific Linux:
sudo yum clean all
sudo yum update

An easy way to fix the GHOST vulnerability on a Ubuntu/Debian Linux:
sudo apt-get clean
sudo apt-get update
sudo apt-get upgrade

An easy way to fix the GHOST vulnerability on a SUSE Linux Enterprise:
SUSE Linux Enterprise Software Development Kit 11 SP3

zypper in -t patch sdksp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3 for VMware

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP3

zypper in -t patch slessp3-glibc-10206

SUSE Linux Enterprise Server 11 SP2 LTSS

zypper in -t patch slessp2-glibc-10204

SUSE Linux Enterprise Server 11 SP1 LTSS

zypper in -t patch slessp1-glibc-10202

SUSE Linux Enterprise Desktop 11 SP3

zypper in -t patch sledsp3-glibc-10206

Finally run for all SUSE linux version to bring your system up-to-date:

zypper patch

Fix the GHOST vulnerability on a OpenSUSE Linux:
zypper lu
zypper up

Note: Reboot will be required after update for all Linux.