Howto disable Consistent Network Device Naming

RHEL 7 (and CentOS 7) introduced the concept of Consistent Network Device Naming. In practice this means that an old network device name like eth0 would change into something enp0s25. Should it not be obvious how those funky new network device names are generated then read SystemD: Understanding Predictable Network Interface Names

Here are the steps to disable Consistent Network Device Naming on RHEL 7 or CentOS 7:

Step 1) add kernel boot args & regenerate the grub config

The following kernel boot arguments need to be added:

Open /etc/default/grub with your favorite editor and add those two options to the line starting with GRUB_CMDLINE_LINUX:

Now let’s regenerate the grub config with the following command:

[root@test ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

And you should see output like this:

Step 2) add a udev symlink, just to make sure

Basically adding the biosdevname=0 and net.ifnames=0 arguments to grub should be enough. But here’s another way just in case:

[root@test ~]# ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

After rebooting the host, the old familiar network ethX devices should be back.

Howto log extra Kickstart headers in nginx

When a server is kickstarted via PXE to deploy RHEL or CentOS it can send a few useful headers when requesting the Kickstart file. The following headers are sent if enabled in the PXE config:

X-Anaconda-Architecture: x86_64
X-Anaconda-System-Release: CentOS
X-RHN-Provisioning-MAC-0: eth0 11:22:33:44:55:66
X-System-Serial-Number: A1B2C3D4G5

Since these headers uniquely identify the requesting host, they can be used by a web app to modify the Kickstart file before it is sent back. You could for example define a specific network setup or partitioning layout.

In RHEL7 or CentOS7 you can enable these headers by adding inst.ks.sendmac and inst.ks.sendsn to the PXE config. Here’s an example:

By default nginx does not log these headers. Here’s how to make nginx log them.

1) add the headers to the log_format of your choice

In this example I just use the default ‘main’ log_format and have appended the headers to log. Open the file /etc/nginx/nginx.conf with your favorite text editor and add the lines beginning with $http_x_ (so the last 4 lines):

You can add additional X-… headers off course. Just make sure that you prepend them with $http_ and that all characters are converted to lowercase and that any dashes ‘-‘ are converted to underscores ‘_’.

2) enable the log_format in your nginx server config

You now need to enable the log_format above (‘main’) to the ‘server’ section in your nginx config. Open the config file for your virtual server and modify the access_log line so that it uses the ‘main’ format:

Restart nginx, PXE boot a VM for deployment and see the headers show up in the nginx log:

Notice the ‘?’ in the GET /ks/?CentOS-7_x86_64.ks? That means that it asks for the default index with argument CentOS-7_x86_64.ks. Fully written it looks like this:

GET /ks/index.php?CentOS-7_x86_64.ks

By just using the ‘?’ you are more flexible as you can change the ‘index’ config option in the nginx configuration without having to change the PXE boot config.

Dovecot, self-signed certificates and unknown CA problem

Quick tip if you are trying to deploy Dovecot on RHEL6 or CentOS6 and get an error message about an ‘unknown CA’ like this:

The reason that this error occurs is that Dovecot can not verify a client certificate because it doesn’t know about the self-signed CA certificate because it can not find the self-signed CA certificate. It’s a puzzling error, especially when the CA certificate is present in the Dovecot config:

This happens because Dovecot can not find the CA certificate in the /etc/pki/dovecot/certs directory. Note the directory. The Dovecot RPM on EL6 comes pre-packaged with two directories: /etc/pki/dovecot/certs/ and /etc/pki/dovecot/private/. But if you put a self-signed CA certificate in /etc/pki/dovecot/certs/ Dovecot can not find it because it is looking elsewhere for the CA certificate.

The solution is to put the self-signed CA certificate in /etc/pki/tls/certs/.