RHEL (and its rebuilds) 5 in Production 3 Phase – 10-year support policy revisited

A security update for the wget package was announced recently. However according to CVE-2014-4877,

Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates.

According to the RHEL Life Cycle,

During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available. Other errata advisories may be delivered as appropriate.

I see. The wget security update was rated “Moderate” and Red Hat decided to not publish this for RHEL-5. Certainly, it is simple to mitigate the reported security issue. Just edit either /etc/wgetrc or ~/.wgetrc and add the following line (bugzilla 1139181):

retr-symlinks=on

However, this is not about how easy a fix can be done, but rather the fact that not all patches are released once RHEL is in production 3 phase. They are provided at Red Hat’s discretion. Users need to be aware of this policy. We tend to think that, during the 10-year supported period, the system remains free of known vulnerabilities as far as it routinely gets updated.

Discard that ‘discard’ — Run fstrim on RHEL and rebuilds

If you have an SSD drive on your system, you may have added the discard option in /etc/fstab which will discard blocks not in use by the file system. Another way to achieve this is to use the fstrim command. Red Hat recommends use of fstrim over the discard option [1]. There is a nice article about TRIM [2] that explains why:

In order to optimize the performance of the SSD, I strongly advise you to avoid doing the TRIM operation in real time (whenever a file is deleted) because you would be putting an unnecessary extra amount of work over the SSD. In other words: You should not enable the discard option in fstab.
Instead, what I recommend is to run a script periodically to tell the SSD which blocks are free with the command fstrim. Doing this operation daily or weekly is more than enough. This way we do not lose any performance due to TRIM when deleting files and we periodically keep informed the SSD about the free blocks.

The article also describes some other advantages of fstrim.

Unless you really need online discard operations for performance, just discard that ‘discard’ option. πŸ™‚

Note added: there is an article about SSD optimization worth reading [3].

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch02s04.html
[2] http://blog.neutrino.es/2013/howto-properly-activate-trim-for-your-ssd-on-linux-fstrim-lvm-and-dmcrypt/
[3] https://wiki.debian.org/SSDOptimization/

Installing only security updates using yum in RHEL

[The contents mostly apply to Scientific Linux 6 as well. CentOS users should see the Notes below]

In Enterprise Linux, it is often desirable to minimize the number of updates to install. Many admins just want to apply security-related updates. This is easily done using yum security plugin. First, install the plugin:

yum install yum-plugin-security

To install only the security updates :

yum --security update

You’ll see something similar to:

===================================================================================
 Package           Arch        Version             Repository                 Size
===================================================================================
Updating:
 mysql             x86_64      5.1.69-1.el6_4      rhel-x86_64-server-6      907 k
 mysql-libs        x86_64      5.1.69-1.el6_4      rhel-x86_64-server-6      1.2 M
 mysql-server      x86_64      5.1.69-1.el6_4      rhel-x86_64-server-6      8.7 M

Transaction Summary
===================================================================================

That’s it. But there are many other things you can do. For example, yum updateinfo has some handy options. Try the following:

yum updateinfo summary
yum updateinfo list security
yum updateinfo list available
yum updateinfo list bugzillas

The first command may show:

Updates Information Summary: available
    3 Important Security notice(s)
    2 Bugfix notice(s)
updateinfo summary done

The second command will display the advisory info such as:

RHSA-2013:0772 Important/Sec. mysql-5.1.69-1.el6_4.x86_64

Then you can apply the update based on the advisory:

yum update --advisory RHSA-2013:0772

Notes for CentOS users
At the time of this writing, CentOS does not have the yum security feature implemented. This might change in a future. Stay tuned.

Notes for Scientific Linux users
Scientific Linux has been providing the package updates in two repositories, sl-security and sl-fastbugs. The sl-security repo contains security-related packages plus their dependencies and is shipped enabled by default. The sl-fastbugs repository is for non-security updates which is shipped disabled. Thus, applying security only updates is the default behavior.

Customizing welcome message in RHEL/CentOS/SL

Customizing motd

You can have the MOTD (message of the day) display messages that may be unique to the machine. One way to do this is to create a script that runs when a user logs on to the system.

First, create a script, make it executable, and save it in /etc/profile.d. Here is an example script named mot.d:

#!/bin/bash
#
echo -e "
##################################
#
# Welcome to `hostname`
# This system is running `cat /etc/redhat-release`
# kernel is `uname -r`
#
# You are logged in as `whoami`
#
##################################
"

Next, edit /etc/ssh/sshd_config as follows:

PrintMotd no

This will disable motd. Now restart the sshd service.

That’s it! When you log in, you’d see something similar to:

##################################
#
# Welcome to machine1
# This system is running Red Hat Enterprise Linux Server release 6.4 (Santiago)
# kernel is 2.6.32-358.2.1.el6.x86_64
#
# You are logged in as user2
#
##################################

[ Please note that this does not work if your login shell is (t)csh. ]

Customizing ssh banner message

You can also create customized greetings for users connecting to your system through ssh. Note that this message is displayed before the actual login.

Create a text file that should appear as the greetings, for example, /etc/sshgreetings.txt.

$ cat /etc/sshgreetings.txt
###############################
#                             #
#      Welcome to Machine1    #
#                             #
###############################

Then edit /etc/ssh/sshd_config as follows:

Banner /etc/sshgreetings.txt

Leap seconds – who cares?

A leap second will be introduced at midnight on June 30, 2012. The last time this happened was on the New Years Eve in 2008.

One might say, “OK, I will get to the next appointment 1 second ahead, good!”. So who cares? System administrators would take the matter seriously though. In fact, you may remember a story of Linux machines crashing at the last occurrence of a leap second [1]. It was due to bad code in the kernel prior to 2.6.29 and many OSs were affected including RHEL 4 and 5 [2].

The code has been fixed since. Make sure your kernel is newer than kernel-2.6.18-164.el5 (RHEL/CentOS/SL). RHEL/CentOS/SL 6 kernels are not affected.

A quick note to add is that the above issue applies only if you are running NTP. If the system is not running NTP, you need to correct the clock manually.

[1] http://ask.slashdot.org/article.pl?sid=09/01/01/1930202

[2] https://bugzilla.redhat.com/show_bug.cgi?id=479765

Removing Suspend and Hibernate from the gnome menu on RHEL-6

I wrote about how to get rid of the “Suspend” option from gnome’s system menu on RHEL/SL/CentOS-5 in my earlier blog. On RHEL-6, “Suspend” and “Hibernate” are now found under “Shutdown” in the “System” menu in gnome.

To remove these options from the list of available actions, create a PolicyKit file named 10-disable-suspend-hibernate.pkla (for example) with the following contents:

[Disable suspend]
Identity=unix-group:*
Action=org.freedesktop.devicekit.power.suspend;org.freedesktop.devicekit.power.hibernate
ResultAny=no
ResultInactive=no
ResultActive=no

and save it in the /var/lib/polkit-1/localauthority/50-local.d directory.

VMware Workstation and RHEL 6.1 and vmmon and trouble

If you have VMware Workstation and are thinking of upgrading your OS to RHEL (or its clone) 6.1, be prepare to go through some extra steps. VMware WS and EL6.1 won’t work together. πŸ™ See, for example, this VMware community forum post: the vmmon.ko module won’t load. Technical details of this issue can be found in this Red Hat bugzilla entry. Apparently, a patch introduced in the EL 6.1 kernel (2.6.32-131.0.15.el6) changed the smp_ops symbol and that prevents the vmmon kernel module from loading.

In VMWare Workstation 7.1.4 build-385536, I see this info with the modinfo command:

vermagic:       2.6.32-71.el6.x86_64 SMP mod_unload modversions

A workaround is to compile the vmmon module on EL 6.1.
Make sure you have kernel-devel installed that matches the running kernel.
Start as a user (not root):

(1) mkdir ~/vmsrc ; cd ~/vmsrc
(2) tar xvf /usr/lib/vmware/modules/source/vmmon.tar
(3) cd vmmon-only
(4) make [Note: this builds vmmon.ko]
(5) strip --strip-debug vmmon.ko [This is optional. Note the two dashes]
(6) su -
(7) cd /lib/modules/`uname -r`/misc
(8) mv vmmon.o vmmon.o.dist [Note: save the original just in case]
(9) cp /(path to user's home)/vmsrc/vmmon-only/vmmon.ko vmmon.o

That should do it!

A Kernel Too Far

The ELRepo Project offers the stable mainline kernel built for RHEL/SL/CentOS 5. It is named kernel-ml. I must emphasize that these kernels are not meant for production use but rather for hardware testing.

There are two versions currently being maintained: the long-term kernel 2.6.35 and the latest stable line (2.6.37 as of this writing). Is the newer version better? Not really so. The first alarming sign came from Dag and the maintainer of kernel-ml, Alan. The Gnome power management did not operate correctly for their laptops with kernel-ml-2.6.36.

Alan recently noted that, the further away the LKA (Linux kernel archive) kernel becomes from the 2.6.18 kernel (which is the basis of EL5), the less likely a stable LKA kernel will be usable. In fact, on certain hardware, kernel-ml 2.6.35 runs fine whereas 2.6.37 does not [1,2].

Quoting Phil, “I see more “value” in the kernel-ml-2.6.35 offering. I agree that sooner or later you are likely to hit a point of diminishing returns, and perhaps you’ve already reached that point with the current kernel-ml-2.6.37.”

So, is this kernel too far ?

[1] http://lists.elrepo.org/pipermail/elrepo/2011-February/000473.html
[2] http://lists.elrepo.org/pipermail/elrepo/2011-March/000542.html

gnome login shows all valid user accounts — disable it

In RHEL-6, the gnome login screen displays all user accounts. Apparently this behavior of the gdm greeter was inherited from Fedora. This may not be a problem with personal desktops/laptops but, in an enterprise class Linux like RHEL, it could constitute a security vulnerability. I saw complaints from users as early as in Fedora 9. Alan has filed a bugzila against RHEL-6.

It is possible to disable it. Problem is … it is not easy to do it. The following command (one-liner) will disable the gdm greeter’s listing of users:

sudo -u gdm gconftool-2 --type bool --set /apps/gdm/simple-greeter \\
/disable_user_list true

By the way, you can see the set value by:

sudo -u gdm gconftool-2 --get /apps/gdm/simple-greeter/disable_user_list

Note that the command was run as gdm. Running the same gconftool-2 command as root would not work. Alternatively, you can modify the systemwide configuration. It will be just easy if you manually edit the file /etc/gconf/gconf.xml.defaults/%gconf-tree.xml and change the boolean for disable_user_list from false to true.

Hardware virtualization supported but no vmx or svm flag?

One common method to verify that the system has the hardware virtualization extentions (Intel VT or AMD-V) required for full virtualization is to look into /proc/cpuinfo like:

egrep '(vmx|svm)' --color=always /proc/cpuinfo

There was an intriguing post by pjwelsh in the CentOS forums . Apparently he has a VT-capable CPU but it did not show up in /proc/cpuinfo. When he tried Fedora, it was there.

When someone as knowledgeable as pjwelsh reports an issue, it really needs attention but the thread did not yield any answer.

Then more recently, a post that seemingly reports the same problem appeared in the Forums. It was time to do more investigation.

Turns out it was a known issue and there was an entry in the Red Hat bugzilla explaining how that happened.

As work for 5.5 we masked out a bunch more cpuid flags, one of which was vmxe. This has caused some confusion since many people are used to looking in /proc/cpuinfo for vmx in order to detect if the hardware is capable of virtualization. To avoid the confusion, we’ll bring it back. It does, however, open a door for a guest admin to shoot themselves in the foot (i.e. attempt to load the KVM module on a Xen guest, which will crash the guest). The svm flag for AMD machines is also brought back.

Hmmm, seems over-cleaning to me. The fix was applied as of kernel-2.6.18-194.17.1.el5.