Things to consider when running Red Hat Enterprise Linux on Azure

Do you plan to (or are you considering) running Red Hat Enterprise Linux (RHEL) on Microsoft Azure? Are you wondering what you have to think about before you do so?

Running RHEL on Azure seems pretty straightforward, and I would partially agree that this is true. However, the typical enterprise requirements when using Azure might be a bit different from the default consumable bring-your-own-subscription (BYOS) and pay-as-you-go (PAYG) images. I won't go into too much detail, but I’ll give you a few hints about network (especially DNS) configuration that should help you get started adapting the Azure images to your needs.

Configuring the environment

In my example, I expect you have a VPN between your Azure VMs and your primary datacenter (be it another form of cloud service or your on-premise one). You need an (internal) DNS server there that is responsible for your hosts, and eventually the services that you want to use.

By default, if you start a Red Hat Enterprise Linux image in Azure, you’ll probably end up with a /etc/resolv.conf similar to this one:

$ cat /etc/resolv.conf
# Generated by NetworkManager
search iftv0wntyplulh4lbl2jpq0ppg.fx.internal.cloudapp.net
nameserver 168.63.129.16

While this is a working configuration that is probably sufficient for a variety of scenarios, it doesn’t fulfill our requirements that it:

• Queries our own name server in order to be able to resolve internal hostnames.
• Doesn’t allow us to query non-FQDN hostnames in our own domain.
• Eventually leaks information about our hostnames to the Microsoft name server (no offense).

Adapting the generated configuration

Experienced sysadmins that worked with DHCP to assign IP/DNS configuration to their clients in the past will eventually know the tricks that are required. The key here is dhclient.conf, the DHCP client configuration file. Using this file, one can override/adapt configuration values provided by the (Microsoft Azure) DHCP server.

In order to make this example easy to reproduce and also a working configuration, we’ll use one of the public Google DNS servers as our primary (and only) DNS server, 8.8.8.8. And, we want our domain to be redhat.com.

We, therefore, create the configuration file /etc/dhcp/dhclient.conf with the following content:

$ cat /etc/dhcp/dhclient.conf
supersede domain-name-servers 8.8.8.8;
supersede domain-search "redhat.com";

This configuration leads to the following generated /etc/resolv.conf:

$ cat /etc/resolv.conf
# Generated by NetworkManager
search redhat.com
nameserver 8.8.8.8

Note that we’d still leak internal hostnames to the Google DNS server in this example. But, as stated above, for the sake of reproducibility I’ve chosen a DNS server that is publicly available for everyone.

Testing the configuration

You’ll probably try this configuration out with internal hostnames, but we’ll test it by trying to resolve just mx1 (non-FQDN):

$ host mx1
mx1.redhat.com has address 209.132.183.28

Voila, exactly what we expect.

Further configuration

There are several other configuration values you can override, add, and adapt to your needs. The best way to find out more about these values is, as all sysadmins should know, the man pages. In this specific case, I’d recommend giving the following a read:

$ man 5 dhclient.conf

Personally, I’d recommend sticking with the default values if there is no absolute need/requirement to change these, but if you do need to override or add any values, then you should be able to find them in the manual page.

Want to try out Red Hat Enterprise Linux? Download it now for free.