As I was finding the kenel version of my Linux server I hit some issues as I ran this command.
[ahmed@amayem kernel]$ uname -r
2.6.32-042stab078.28
I noticed that that version string is a bit unusal. It has stab in it. Kernel version 2.6.32 was released by kernel.org and I don’t see a stab in the version string. The CentOS wiki says the following about version numbers:
The kernel version will always use the structure kernelversion-kernelrelease.centosrelease. On CentOS 5 for example the kernelversion will always be 2.6.18 and will not change, the kernelrelease will normally be a single number (previous examples are 53, 92, 128 and 164) or a string of 3 numbers with periods as separators (previous examples are 92.1.13, 128.1.1, etc). The centosrelease will always be el5 for CentOS 5.
So I clearly don’t have the CentOS kernel.
Not the CentOS Original Kernel
A quick Google search and I found out here that this is actually a RHEL6 openvz kernel. According to OpenVZ’s versioning system this is an OpenVZ kernel based on RHEL 2.6.32 with a major OpenVZ release of 042 and a minor OpenVZ release of 078. The stab means it is stable, and out of testing.
Am I Running CentOS or not
According to the CentOS wiki, NO I am not:
If your kernel version contains the string: stab and looks likes this 2.6.18-92.1.13.el5.028stab059.6, then you have custom-made kernel, usually from a virtualization project based on OpenVZ. This is not a kernel which CentOS provides, and so you are not running real CentOS.
Ouch. They are very adamant that that is not a real CentOS. They even give us a few more ways to check if it’s real or not:
Yum Configuration Files
We will follow the instructions here. We will be using the rpm -qV command which, “will verify the content of a RPM package and will show any changes made to the files that are present in the RPM package”.
[ahmed@amayem ~]$ rpm -qV yum
[ahmed@amayem ~]$
Hmm that looks good. They mention, “On a standard CentOS distribution the rpm -qV commands should return no output”. So yum hasn’t been changed. Let’s check centos-release.
[ahmed@amayem ~]$ rpm -qV centos-release
[ahmed@amayem ~]$
Clean here too. So we are still in alignment with the CentOS distribution. Let’s try the next test.
Changed Core Packages
Next let’s see if core packages have been changed:
[ahmed@amayem ~]$ grep -ri exclude /etc/yum.*
[ahmed@amayem ~]$
And we get a resounding, no change. Well, it looks so far like we are very close to the original CentOS distro.
sudo rpm -Va
Another similar CentOS wiki page mentions that the
sudo rpm -Vacommand will run silently except for expected configuration file changes. (See: man rpm for help in reading such a listing, where there is a decoder for the left hand column details.)
Let’s give it a try:
[ahmed@amayem ~]$ sudo rpm -Va
.M....... /
missing /etc/init/control-alt-delete.conf
missing /etc/init/plymouth-shutdown.conf
missing /etc/init/prefdm.conf
missing /etc/init/quit-plymouth.conf
S.5....T. /etc/init/rc.conf
missing /etc/init/rcS-sulogin.conf
S.5....T. /etc/init/rcS.conf
missing /etc/init/serial.conf
missing /etc/init/start-ttys.conf
missing /etc/init/tty.conf
S.5....T. c /etc/sysconfig/init
S.5....T. c /etc/sysctl.conf
S.5....T. c /etc/sysconfig/saslauthd
S.5....T. /etc/cron.d/dailyjobs
.......T. c /etc/crontab
S.5....T. c /etc/httpd/conf/httpd.conf
.....U... /var/www/html
S.5....T. c /etc/sudoers
S.5....T. c /etc/rsyslog.conf
.M....... /dev/console
......G.. /dev/ptmx
.M....... /dev/random
......G.. /dev/tty
.M....... /dev/urandom
S.5....T. /etc/cron.d/0hourly
S.5....T. c /etc/ssh/sshd_config
.M....... /etc/cron.daily/makewhatis.cron
.M....... c /etc/cron.daily/tmpwatch
.M....... /etc/cron.daily/mlocate.cron
First let’s figure out what this means. Let’s check, as they suggested, the man page.
[ahmed@amayem ~]$ man rpm
We find the following relevant passage:
VERIFY OPTIONS
The general form of an rpm verify command is
rpm {-V|--verify} [select-options] [verify-options]
Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database. Among other things, verifying compares the size, MD5 sum, permissions, type, owner and group of each file. Any discrepancies are displayed. Files that were not installed from the package, for example, documentation files excluded on installation using the "--excludedocs" option, will be silently ignored.
So we understand now that we are verifying the packages we have installed. We also used the -a option which means:
-a, --all
Query all installed packages.
So we were verifying all of our installed packages. The list that appeared is that of the files that have a discrepancy. But what does the left-hand column mean? Our trusty man page tells us:
The format of the output is a string of 8 characters, a possible attribute marker:
c %config configuration file.
d %doc documentation file.
g %ghost file (i.e. the file contents are not included in the package payload).
l %license license file.
r %readme readme file.
from the package header, followed by the file name. Each of the 8 characters denotes the result of a comparison of
attribute(s) of the file to the value of those attribute(s) recorded in the database. A single "." (period) means the
test passed, while a single "?" (question mark) indicates the test could not be performed (e.g. file permissions pre-
vent reading). Otherwise, the (mnemonically emBoldened) character denotes failure of the corresponding --verify test:
S file Size differs
M Mode differs (includes permissions and file type)
5 MD5 sum differs
D Device major/minor number mismatch
L readLink(2) path mismatch
U User ownership differs
G Group ownership differs
T mTime differs
P caPabilities differ
Things make a bit more sense now. We used sudo hence we didn’t see any ? because all tests were run. A line like:
S.5....T. /etc/init/rc.conf
Means that the file /etc/init/rc.conf has a different size, different MD5 sum and different mTime than the package metadata stored in the rpm database. This is to be expected for such a file because it is a configuration file that I have configured. Now the question remains, are all those listed files I had above considered part of the, “expected configuration file changes” mentioned in the wiki? What that means is someone has changed the configuration files. Either I have changed the files, manually or through a program, or the configuration files were changed by someone else. If we find files that have changed that I have not changed then we know that the OS is not the original CentOS. In my case the files of interest are as follows:
missing /etc/init/control-alt-delete.conf
missing /etc/init/plymouth-shutdown.conf
missing /etc/init/prefdm.conf
missing /etc/init/quit-plymouth.conf
missing /etc/init/rcS-sulogin.conf
missing /etc/init/serial.conf
missing /etc/init/start-ttys.conf
missing /etc/init/tty.conf
I don’t remember deleting these files. My vendor says they provide the base OS without managing it. So these files, at least, look suspicious.
lsb_release
[ahmed@amayem ~]$ lsb_release -a
-bash: lsb_release: command not found
Ouch looks like I don’t have it installed. It seems that CentOS does not have this by default. I decided not to install it, because I didn’t want to upgrade its dependencies.
Implications
Even if we pass most of the configuration tests, the kernel, as we have shown, is still not the standard CentOS version, and hence not actually CentOS. The implication is that the CentOS support community will be reluctant to help you.
References
- druuna here for pointing to the kernel archives
- The kernel archives
- The CentOS wiki Other Spins page
- The CentOS wiki Broken Vserver page
- TrevorH for providing the wikis at the CentOS forums
- Binary Tides for the information on
lsb_release.
