Apr 132013
 

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
Jun 152012
 

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

Sep 182011
 

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.

May 282011
 

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!

Mar 122011
 

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

Jan 022011
 

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.

Dec 112010
 

[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.

Jun 302009
 

It all started in the CentOS forums.

CentOS, being an Enterprise Class Linux distro, may not have support for new hardware, especially those found in desktops and laptops. CentOS forums get many postings from users who are looking for drivers that are needed for their network device, webcam, etc. In fact, googling for “driver” and “centos” yields much more hits from the forums than the mailing list as shown in my earlier blog.

Alan Bartlett who has been actively helping in the forum has strong background in the kernel and its modules and has been building, whenever possible, a driver module each time he sees a cry for help. In a fairly short period of time, quite an impressive number of such kernel modules were built this way and it was growing.

Because these drivers were designed to be independent of the kernel version (kABI-tracking, kABI = kernel application binary interface), they survive kernel updates. Also, they can be used in RHEL and all its rebuilds, not just CentOS. So, it was a good idea to make them available to wider communities. NedSlider proposed to establish a repository for that purpose. The ELRepo project was thus started by five members of the CentOS / Scientific Linux community.

A little more details of ELRepo can be found in the Ned’s recent blog.

May 292009
 

A while ago, I was talking with my buddies and the subject was about installing / updating a package using yum.  yum did not find the package that had just been added.  No problem, either yum clean metadata or yum clean all will do.  Err … it didn’t. 

As it turned out, it didn’t work because the repository in question was disabled by default.  The man page for yum clearly states:

Note that "all files" in the commands below means "all files in 
currently enabled repositories".   If you  want  to  also clean  any 
(temporarily)  disabled  repositories you need to use --enablerepo=’*’ 
option.
Apr 122009
 

For some reason, my desktop gnome menu had a “Suspend” option.  It was right under the “Log out …” option in the System dropdown menu.  One day, when I meant to click on the “Log out” option, my mouse went too far and I ended up selecting this “Suspend” option.

After struggling for the next few minutes, I gave up and rebooted the machine to come out of the suspended state.

The Suspend option should not have been there to begin with.  Anyway, it was time to remove it.  Fortunately, that was as easy as typing [1]:

gconftool-2 --type boolean --set /apps/gnome-power-manager/can_suspend false

Likewise, if you want to get rid of the Hybernate option,

gconftool-2 --type boolean --set /apps/gnome-power-manager/can_hibernate false

[1] http://magazine.redhat.com/2008/05/30/tips-and-tricks-how-do-i-remove-the-suspendhibernate-entries-from-the-system-menu-in-the-gnome-panel/