April 27

What’s the life expectancy of a RHEL release?

I asked myself this question after reviewing the validity period for the RHCE. See my How long is the RHCE valid post. Back then I discovered the RHCE is valid for 2 full releases after the release on which the exam was taken. The answer to one question only created another! I wanted to know exactly how many years “2 full releases” equated to in human years.

After scouring Google quite a few times, I came to realize that there isn’t any cut and dry answer as to how long a Red Hat Enterprise Linux (RHEL) release is actively developed. Sure older versions are still sort of supported once a new major release comes out, but this quest is more about getting a feel for RedHat’s release time-line. The BIG question ultimately led to some digging around through RedHat press releases over here and of course; wikipedia. After gathering the data, I produced a quick and dirty chart comparing the different RHEL versions and their release dates by number months. Hope this helps those with the same questions floating through their heads.

Red Hat Enterprise Linux lifetime

Red Hat RHEL lifetime


RHEL 5: 3/1/2007 – present - 36 months as of 4/2010 – [ 6 releases (so far) ]
RHEL 4: 2/14/2005 – 5/18/2009 - 51 months – [ 4 releases ]
RHEL 3: 10/23/2003 – 6/15/2007 - 44 months – [ 5 releases ]


Armed with this information, one could guess that RHEL 5 will have a life expectancy of about 50 months. If that’s the case, then as of this post, we have just about 14 months left until RHEL 6! If anyone has any further insight, please post a comment.

Category: Linux | 1 Comment
April 24

How long is the RHCE valid?

How long is the RHCE “good” for? – It seems like this is the million dollar question everyone wants answered –including myself. Some people say the RHCE is only good for a single major release of Red Hat Enterprise Linux (RHEL), others say its a year or two without providing anything substantial to back such claims. However, according to RedHat, the RHCE is valid for 2 full releases after the release on which the exam was taken.

This is the legalese you have probably already seen at RedHat;

The validity period for all RHCEs and RHCTs is pegged to the release of the Enterprise product commercially available at the time certification was earned. RHCE and RHCT certifications are considered current until Red Hat retires exams of the release following the version on which your certification was earned. For example, certificates earned on Red Hat Enterprise Linux 3 will be current until August 31, 2007, the last date on which Red Hat Enterprise Linux 4 exams will be offered. Note that Red Hat Enterprise Linux 5 was released in March, months before the final retirement of the version 4 exams.

To provide further clarification for earlier versions, Red Hat Enterprise Linux 4 will remain current until Red Hat Enterprise Linux 5 exams are retired, several months after the release of Red Hat Enterprise Linux 6.

Now this raises another interesting question; What’s the life expectancy of a RHEL release? In my next blog post, I attempt to answer this question and provide an easy to read bar graph illustrating RedHat releases of RHEL3, RHEL4 and RHEL5. I also offer a time-line for each of the RHEL releases.

Category: Linux | 1 Comment
April 12

How to determine if a SATA drive is failing.

When is it a good time to check to see if a hard drive is failing? Well, when your console is full of IO/seek errors, I’d say that is a pretty good time! Hah.

According to research conducted by Google, a document entitled Failure Trends in a Large Disk Drive Population states that the manufacturer, particular model and vintage plays a role, but does not provide failure statistics on model and manufacturers. Most drives were run at 45C or less.

From the SMART data, scan errors, reallocations, offline reallocations and probational counts had a significant correlation with failure probability, whereas seek errors, calibration retries and spin retries had little significance.

Soooo…. you want to look at the Raw_Read_Error_Rate, Seek_Error_Rate and Reallocated_Sector_Ct information from smartctl.

[root@SOMESERVER ~]# smartctl --all /dev/sdb | grep Error
Error logging capability:        (0x01)	Error logging supported.
  1 Raw_Read_Error_Rate     0x000f   117   100   006    Pre-fail  Always       -       166491825
  7 Seek_Error_Rate         0x000f   090   060   030    Pre-fail  Always       -       999290467
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
SMART Error Log Version: 1
[root@SOMESERVER ~]# smartctl --all /dev/sdb| grep Reallocated_Sector_Ct5
Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0

In regards to Reallocated_Sector_Ct, the normalized values (current=100, worst=100) indicate the drive is in  perfect condition (higher is better, and looking at the overall report it appears that 100 is “best”). The threshold value (36) just indicates how low the normalized value would have to drop before the manufacturer would consider the drive to be in a “Pre-fail” condition.

If you run “smartctl –all /dev/sdb | grep Error” again and notice that Raw_Read_Error_Rate and Seek_Error_Rate keep incrementing AND Reallocated_Sector_Ct is greater than 0, its pretty safe to say that you have a ticking time-bomb on your hands. You should consider replacing those drives as soon as possible.

April 4

Unknown linux rootkit?

Recently noticed a bunch of servers (CentOS 5.2 and CentOS 4.8) with SSH fingerprint mismatches. After poking around, it appears that they had been compromised. chkrootkit and RKhunter found nothing but the suspicious entry in /dev (see below).

WARNING: DSA key found for host ourserver.domain.com
in /Users/username/.ssh/known_hosts:578
DSA key fingerprint f4:27:d0:32:6b:4c:9f:6e:52:6f:49:dd:19:54:c2:f1.
+–[ DSA 1024]—-+
| ..o+|
| . o..|
| * . .E|
| + B . . .o|
| S * o …|
| . o = . |
| . o + |
| o . |
| |
+—————–+

The authenticity of host ‘ourserver.domain.com (10.0.0.2)’ can’t be established
but keys of different type are already known for this host.
RSA key fingerprint is 4c:5f:95:3e:52:08:6c:cd:0f:f8:37:38:3c:dd:bf:56.
Are you sure you want to continue connecting (yes/no)? yes

Affected files:

/dev/sax
/bin/suidshell
/usr/local/bin/ssh-agent
/usr/local/bin/sftp-server
/usr/local/bin/ssh-agent2
/usr/local/bin/ssh
/usr/local/bin/ssh-add2
/usr/local/bin/ssh-signer
/usr/local/bin/ssh-keygen2
/usr/local/bin/ssh-probe2
/usr/local/bin/ssh-probe
/usr/local/bin/scp
/usr/local/bin/sftp
/usr/local/bin/ssh-chrootmgr
/usr/local/bin/ssh-signer2
/usr/local/bin/sftp2
/usr/local/bin/scp2
/usr/local/bin/ssh-pubkeymgr
/usr/local/bin/ssh-dummy-shell
/usr/local/bin/ssh-add
/usr/local/bin/sftp-server2
/usr/local/bin/ssh-askpass
/usr/local/bin/ssh2
/usr/local/bin/ssh-keygen
/usr/local/sbin/sshd2
/usr/local/sbin/sshd-check-conf
/usr/local/sbin/sshd
    /usr/local/sbin/sshd2 — captures login credentials for both root and non-root logins over SSH/SCP/sftp etc and logs to /dev/sax

    /bin/suidshell — is exactly that, a shell with the suid bit set that instantly gives root access to any unprivileged user!

    /dev/sax — stores plaintext username and password for root and non-root accounts