Blog Archives

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.

SELinux and FreeNX

[Note added in August 2011: Be sure to read the comment by Dan Walsh. There is a simpler solution]

When you attempt to connect to a remote machine using freenx, you might encounter this message:

The NX service is not available or the NX access was disabled on host XXX.

This is likely due to SELinux blocking the connection. If you are using QtNX, it just hangs without any message.  Here is how to solve the issue.

(1) Disable auditd.

service auditd stop

(2) Rename /var/log/audit/audit.log or move it somewhere else.

(3) Enable auditd

service auditd start

(4) Try connection from the client. It will fail. This writes the audit.log file.

(5) Generate SELinux policy rules from the log file and install it.

cat /var/log/audit/audit.log | audit2allow -M freenx
semodule -i freenx.pp

(6) You can see the policy by reading the .te file.

cat freenx.te

module freenx 1.0;

require {
type nx_server_var_lib_t;
type sshd_t;
class file read;
}

#============= sshd_t ==============
allow sshd_t nx_server_var_lib_t:file read;

(7) Now, try connecting from the client again. It will fail again. Repeat the steps (1) to (5) using ‘freenx2′ instead of ‘freenx’.

(8) You will most likely need to repeat the process yet one more time until the connection finally succeeds. So, once again repeat the steps (1) to (5) but this time using ‘freenx3′ instead of ‘freenx’.

If you look at the policy files generated, you will find what was added by each action.

Search is ON — An update

I talked about getting help for CentOS in February 2009 and presented some Google search results comparing the number of hits between the mailing lists and the forums. That was 15 months ago and I thought I should update the results.  Exactly the same search was performed yesterday (May 29, 2010).


Search term  M/L Forums
============ === ======
install        0    25
installation   0     7
kernel         0    23
driver(s)      0    22
DNS            3    37
postfix       19    24
sendmail       5    30
selinux        0    23
apache         0    23
httpd          0    40
xen            3    33
kickstart      5    25
crash          2    21
panic          2    27

Google’s tendency to pick up forum posts rather than mailing list posts is much more obvious now than it was last year.  It looks as if Google is fond of the forums better than the mailing lists :-D Or is it simply because there are more posts in the forums?

Regardless of the reason, what this means is that it is important to keep the quality of the forum contents high.  I would say that the current status is quite good; there are a number of forum regulars providing help.  Inappropriate replies, if they appear, get corrected by senior members.  Still, the forums can use more helping hands.  Why don’t you join in and make this CentOS help venue even better?

Want a custom kernel on CentOS? NOooooo! (really?)

If you visit the Custom kernel article on the CentOS wiki, you will see lots of warnings including the fact custom kernels are not supported by CentOS. If in doubt, just mention “custom…” in the centos IRC channel, you would be told to go away (if you are lucky enough to not get banned :-D ).

In the CentOS forums, things are a little more relaxed. After usual warnings, you will receive some (or even extensive) help. As someone put it in a recent post, “… but there are *some* situations, where it [custom kernel] is desirable (usage on notebooks with HW that’s not supported by native kernels – which is e.g. my case or curious minds of young and restless geeks etc. )”.

I am far from ‘young and restless’ and I am not a geek. However, I did compile the latest mainline kernel — in an attempt to help those encountering trouble with installing newer kernels. The error was “mount: could not find filesystem”. I could reproduce it on my CentOS system.

As always, Alan and Ned engaged their brains and we tried several things to find a solution. We were getting nowhere when vanecka posted a fix in this forum thread.

Fix:
Enable CONFIG_SYSFS_DEPRECATED_V2 in the kernel source configuration.
If you run “make menuconfig”, browse to:
General Setup —> enable deprecated sysfs features which may confuse old usersp, and enable this option.
—OR—
Edit your .config file with a text editor and add/modify entry:
CONFIG_SYSFS_DEPRECATED_V2=y

Genius! If you are interested in learning more details about this option, head for this web page.

CentOSPlus kernel and VMware Workstation6.5/Server 2.0.x

CentOS aims at being 100% binary compatible with the upstream vendor (including bugs). To accommodate users needs, the CentOS team offers the centosplus kernel which includes features that are not in the distro kernel. It has a number of options (mostly device drivers) enabled and also has patches that correct known issues.

Recently, it was reported that the centosplus kernel had a problem with certain versions of VMware products as seen in this CentOS forum thread.

Specifically, building the vmnet module on a host fails with the error:

/tmp/vmware-config2/vmnet-only/compat_netdevice.h:273: error: redefinition of ‘struct napi_struct’

Apparently, somewhere in the kernel source that was added in the centosplus kernel, there is that definition and it is conflicting with the VMware code.

It turned out that the problem exists in the VM guest as well: building of the vmxnet modules fails with the same error. The fix, in both cases, is to untar:

/usr/lib/vmware/modules/source/vmnet.tar (host)
/usr/lib/vmware-tools/modules/source/vmxnet.tar (guest)

and comment out the following block in compat_netdevice.h:

struct napi_struct {
int dummy;
};

More details can be found in the CentOS bug tracker.

Go green with newer AMD processors

Not long ago, Steve, one of the founders of the ELRepo project, built new systems with the AMD II X4 Phenom processor. After hearing his positive comments, I replaced my old desktop with a new one equipped with a Phenom cpu.

Steve soon noticed that the machine consumed more power when it was running CentOS compared to when running Fedora. Turns out that, in CentOS, there is no per-core control — meaning when the system needs a higher processor power, all cores will shoot up to the maximum frequency. In Fedora, each core gets attenuated independently.

This issue was noted by a CentOS forum user, AlexAT, here. He not only reported it in the upstream bugzilla but came up with a fix later.

Using the patch provided by AlexAT, we built a kernel module kmod-powernow-k8 and released it through ELRepo. After installing kmod-powernow-k8, Steve saw that the system was now measured drawing ~110W at idle from the wall outlet, similar to the power consumption observed under Fedora 10 and under CentOS 4.7. So without kmod-powernow-k8 installed, the system was consuming ~40W (36%) more power at idle and the core temperature was running 8-10°C hotter than with kmod-powernow-k8 installed, making this a very environmentally friendly kmod.

So, if you have newer Opterons, the Phenoms or Phenoms II (or Kuma core Athlons X2), you should give this driver a try. Also, you would want a backported AMD K10 core temperature monitor driver module (kmod-k10temp) from ELRepo.

Let’s go green!