Configure Wake-on-LAN on Red Hat Enterprise Linux

Wake-on-LAN is a useful feature on most network cards that allows you to remotely boot up a computer.

The ethtool utility (found in the ethtool RPM) can tell you if your network card supports Wake-on-LAN:

[root@example]# ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes

Look for the “Supports Wake-on” line. It should list one or more letters, including “g” (WoL using Magic Packet). In the example above, Wake-on-LAN is currently disabled (“d”).

The Wake-on-LAN setting does not persist. It needs to be configured every time the machine boots. On RHEL, this is usually done from /etc/init.d. Create a script called /etc/init.d/wol with the following content:

#!/bin/bash
#
# wol Wake-on-LAN configuration script
#
# chkconfig: - 99 01
# description: Wake-on-LAN allows a machine to be started using a WoL network packet.\
# This script configured WoL on interfaces listed in $NIC.
# processname: -
# config: -
# pidfile: -

# Source function library.
. /etc/rc.d/init.d/functions

# List of NICs to configure for WoL.
# Note: on Xen hosts, use peth0 instead of eth0.
NIC=”eth0″

if [ “$1” != “start” ]; then
exit 0
fi

echo -n “Enabling Wake-on-LAN for:”
for nic in ${NIC};
do
echo -n ” ${nic}”
[ -x /sbin/ethtool ] && /sbin/ethtool -s ${nic} wol g >/dev/null 2>&1
done

# Note: no error checking – ethtool does not return a useful exit code
success
echo

# EOF

Add the script to the startup sequence:

chkconfig --add wol
chkconfig wol on

The script will now be run on every reboot. You can check the result using ethtool eth0; it should now display “Wake-on: g“.

You should now be able to shutdown your computer, and wake it by sending a “WoL Magic Packet” from another computer. On Linux, use ether-wake (from the net-tools RPM) or wol (from the wol RPM) to send the Magic Packet:

/sbin/ether-wake -i eth0 00:04:23:C0:FF:EE

Voila!

The trouble with setroubleshootd

Pop quiz: what is wrong with this picture?

     top - 17:15:07 up 5 days, 17:35,  1 user,  load average: 3.76, 4.97, 3.18
     Tasks: 135 total,   2 running, 133 sleeping,   0 stopped,   0 zombie
     Cpu(s):  0.0%us,  0.5%sy,  0.0%ni, 52.3%id, 47.2%wa,  0.0%hi,  0.0%si,  0.0%st
     Mem:   2097152k total,  2088744k used,     8408k free,     2564k buffers
     Swap:  1048568k total,   946156k used,   102412k free,    45548k cached

     PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
     1507 root      15   0 1987m 1.2g 2824 S  0.3 62.3   1096:21 setroubleshootd

The system was under severe memory pressure. This caused huge amounts of IO-Wait and slowed the system down to a crawl.

According to top,  setroubleshootd is using 1.2GB out of a total of 2GB of RAM. This is ridiculous. The daemon basically only checks for SElinux-related audit messages and displays a dialog informing you of the event. Why does it need to use more than 60% of physical memory on my system?

As far as I can tell, there’s no real need to run this daemon. Probably only on a graphical workstation, but not on a server.

     chkconfig setroubleshootd off
     service setroubleshootd stop

Problem solved ;-)

This was not an incident; a quick “ps aux |grep” confirmed that setroubleshoot was using a lot of memory on most systems:

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      2926  3.0 13.0 545672 317292 ?       Ssl  Nov11 265:09 /usr/bin/python -E /usr/sbin/setroubleshootd

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      3107 11.9 48.5 1664092 1437740 ?     Ssl  Nov11 1033:51 /usr/bin/python -E /usr/sbin/setroubleshootd

     USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
     root      1503 13.7 74.7 2524604 1566892 ?     Ssl  Nov11 1187:44 /usr/bin/python -E /usr/sbin/setroubleshootd

These are all RHEL / CentOS 5.5 systems, 64-bit with latest updates installed…

RHCA Exams: Two down, three to go!

As an IT professional, I find that certification has become more important over the years. Maybe this has to do with the economic climate – prospective customers and employers are more likely to talk to you if you have a couple of certifications on your resume. In my opinion, certifications that are based on multiple-choice exams offer little value – they merely test your ability to remember factoids.

The Red Hat certification exams are performance-based, so you really need to know your stuff and be able to apply it under considerable time pressure. This is why Red Hat certifications are received so well by customers and employers.

I’ve been a Red Hat Certified Engineer (RHCE RHEL4) since 2005. I’m now aiming for their highest certification level offered, Red Hat Certified Architect (RHCA). The RHCA certification requires you to pass 5 Expertise Exams on top of your RHCE certification; not an easy task.

In May 2009, I took my first Expertise exam, RH423 / EX423 (Directory Services and Authentication). In november 2010, I took one of the hardest exams in the RHCA track: RH442 / EX442 (System Monitoring and Performance Tuning). And boy, was it tough! I barely had 3 minutes left before the 4-hour exam was over and we had to “put down our keyboards” ;-)

Since the exams are subject to strict NDA, I cannot say anything about the content of the actual exam. You can look up the Exam Prep Guide for each Expertise on Red Hat’s website for a list of subjects covered in each course and exam.

So, what can you do to maximize your chance of passing the exams?

  1. Make sure you have plenty of actual experience with Linux
  2. Take the 4-day instructor-led course (usually offered as a bundle with the exam)
  3. Make sure you get plenty of sleep before the exam ;-)

I took the RH300 course for my RHCE RHEL4, and I plan to re-take the course for my upcoming RHCE RHEL6 renewal. That’s how useful I think the courses are!

The courses are jam-packed, but fun. I usually discover a couple of new ways to accomplish things under Linux – you can’t have enough tools in your Linux toolbox! The group discussions also add a lot of value – you’ll learn a lot from other people’s experience, usually involving breaking things in spectacular ways ;-)