Stopping your RHEL virtual interfaces from starting at boot. ONPARENT you say?

I recently debugged a pretty interesting problem with one of my clusters. When I rebooted one of the nodes, I noticed that a virtual interface that had ONBOOT set to no was started when the network interfaces were initialized. For those not familiar with RHEL systems, the ONBOOT directive tells the network initialization scripts not to start a given interface. This was rather confusing, and after some experimenting with a virtual machine I saw the EXACT same behavior. Something had to be awry here!

After reading through the ifup-aliases script, I saw a reference to the ONPARENT directive. This directive had similar properties to ONBOOT, but only applied to virtual interfaces. A quick Google search revealed that this is indeed the purpose of the directive, though I haven’t seen a whole lot of documentation that refers to it. :(

So if you need to stop a virtual interface from starting when the network interfaces are initialized, you need to set ONPARENT instead of ONBOOT to no. Here is a sample ifcfg file that shows how to use it:

$ cat /etc/sysconfig/network-scripts/ifcfg-bond0:1

DEVICE=bond0:1
BOOTPROTO=static
ONPARENT=no
IPADDR=192.168.1.21
NETMASK=255.255.255.0
NETWORK=192.168.1.0

I have no idea why Redhat couldn’t use ONBOOT for both, but then again I don’t understand a lot of things that come out of Raleigh. Food for thought!

Who says Linux isn’t stable?

I have been replacing some old hardware over the past few months, and recently noticed that we had several machines with uptimes in the hundreds of days (one 800+ days). For the longest time I thought only Solaris and AIX provided this kind of stability, but over the past few years I’ve started to include Linux in this list as well. You gotta love it when you see this:

$ uptime
2:08pm up 428 days, 3:00, 1 user, load average: 0.63, 0.50, 0.36

Now if only ksplice would make it into the Enterprise distributions! That would be rad, and I’m sure some fun “my uptime is better than your uptime” threads would ensue. :)