We had a software package that had a braindead licensing scheme. To generate the license, it uses the MAC address of the network interface card of the machine you are running it on. OK, that's a way of identifying a unique machine. But here's the kicker. It just assumes that your ethernet device is /dev/eth0.

For a while now, NICs that are embedded on the motherboard are identified by udev as em1, em2, etc. This is part of an attempt to make interface naming more predictable and meaningful.

So, how to get em1 renamed to eth0? Here's what worked for me. I should emphasize that I had access to the console, so when ethernet was down I could still access the box.

0. I've been burned enough times to do this out of habit: make a backup of /etc/grub.conf, retaining SELinux info:

# cp --preserve=context /etc/grub.conf /etc/grub.bak

1. Add biosdevname=0 to the kernel boot arguments in /etc/grub.conf.

2. Rename /etc/sysconfig/network-scripts/ifcfg-em1 to /etc/sysconfig/network-scripts/ifcfg-eth0, changing the line

DEVICE="em1"

to

DEVICE="eth0"

3. Delete /etc/udev/rules.d/70-persistent-net.rules

4. Reboot.

Presto, I get eth0 for the former em1 and the rest of the NICs on this Dell R715 are still em2, em3, em4.

Reference:

How to Still Use ethX on Fedora 15
Consistent Network Device Naming
Nicnaming - Solving it with Biosdevname

Listen, my friends, and I will tell you a tale of mystery MAC addresses, DCHP, and Broadcom woes.

It all started when we got a new server. A Dell R815, to be exact. The specs looked great, it could hold a ton of RAM for some of our bioinformatics projects, and the cost was low. Everyone was happy.

Then one day someone called and said, hey, there are a ton of DHCP requests and we've traced them back to [room that server is in]. Here's the MAC address: 002xxxxxxxd1.

This seemed weird to me because we had set up static IPs on the server's two live NICs, both on the primary NIC and on the iDRAC enterprise NIC. To my knowledge, there were no NICs set up with DHCP.

Even more weird was the fact that the MAC address 002xxxxxxxd1 did not actually exist. The R815 had five NICs, numbered like this:

002xxxxxxxd0 (NIC 1)
002xxxxxxxd2 (NIC 2)
002xxxxxxxd4 (NIC 3)
002xxxxxxxd6 (NIC 4)
002xxxxxxxd8 (iDRAC)

We pored over the NIC configurations in Windows 2008 R2 server and its virtual switch and virtual machines (since it was running the Hyper-V role). Nothing. Meanwhile, our sniffer showed that we were not dreaming...indeed, DHCP requests were emanating from that MAC address.

We pulled the network cable and the DHCP requests stopped. We pulled out our hair and ceremoniously waved a Windows 98 boot disk over the server -- we keep one around for just these sorts of occasions.

Finally we turned up something...in the iDRAC remote management screen we found a list of MAC addresses which included the mysterious one we were looking for.

I'll cut to the chase. The Broadcom NeXtreme II 5906 NICs have iSCSI capability built-in. The embedded iSCSI HBA has an IPv4 configuration setting that defaults to DHCP. This setting was on by default, and means that DHCP requests were emanating from the server, receiving a 10.11.x.x address.

The DHCP requests cannot be disabled without installing the BroadCom Managed Applications Control Suite and then following the instructions here.

It is very probable that I'm not very bright and other people expect DHCP requests to come from the iSCSI hardware on their NICs by default. Just thought I'd share. And I note that this is only happens on Windows, not Linux on the same hardware.

tl;dr DHCP requests are issued by default on Broadcom NeXtreme II network adapters on Windows servers unless you download a special tweaker to turn them off, and it took me a while to figure this out.

Reference: Broadcom iSCSI offload engine defaults to DHCP enabled (IBM, 2011-03-03)

Here are the slides from my morning presentation at yesterday's "DrupalCorn" DrupalCamp in Des Moines, Iowa. The presentation was designed to be a brief high-level overview of Drupal.

Introduction to Drupal 7 Architecture (PDF, 1.8MB)

When setting up Pubcookie, you may encounter an "Internal Server Error" in your browser and the following error in /var/log/httpd/ssl_error_log (or wherever you're keeping your SSL error log):

This might be a headscratcher for a while, since you've probably been working hard to make sure that your Pubcookie configuration is nice and tidy and your .htaccess file is set up with PubcookieAppID, like this:

In fact, Apache is telling you exactly what you need to know: it can't make sense of the PubcookieAppID directive because the module that interprets that directive is not loading and thus is "not included in the server configuration."

To solve this, make sure that a line like this is actually somewhere in your configuration, normally somewhere like /etc/httpd/conf.d/pubcookie.conf:

LoadModule pubcookie_module modules/mod_pubcookie.so

In my case, I had commented it out while getting SSL to work. Duh.