I’ve talked about predictable network names (and seemingly unpredictable ones) on the blog before, but some readers asked me how they could alter the network naming to fit a particular situation. Oddly enough, my Supermicro 5028D-T4NT has a problem with predictable names and it’s a great example to use here. The problem There’s plenty of detail in my post about the Supermicro 5028D-T4NT, but the basic gist is that something within the firmware is causing the all of the network cards in the server to show up as onboard.

Switching to systemd-networkd for managing your networking interfaces makes things quite a bit simpler over standard networking scripts or NetworkManager. Aside from being easier to configure, it uses fewer resources on your system, which can be handy for smaller virtual machines or containers. Managing tunnels between interfaces is also easier with systemd-networkd. This post will show you how to set up a GRE tunnel between two hosts running systemd-networkd.

I’ve decided to start a series of posts called “Chronicles of SELinux” where I hope to educate more users on how to handle SELinux denials with finesse rather than simply disabling it entirely. To kick things off, I’ll be talking about dealing with web content in the first post. First steps If you’d like to follow along, simply hop onto a system running Fedora 21 (or later), CentOS 7 or Red Hat Enterprise Linux 7.

I talked a bit about systemd’s network device name in my earlier post about systemd-networkd and bonding and I received some questions about how systemd rolls through the possible names of network devices to choose the final name. These predictable network device names threw me a curveball last summer when I couldn’t figure out how the names were constructed. Let’s walk through this process. What’s in a name? Back in the systemd-networkd bonding post, I dug into a dual port Intel network card that showed up in a hotplug slot:

I’ve written about systemd-networkd in the past and how easy it can be to set up new network devices and tunnels. However, the documentation on systemd-networkd with bonding is a bit lacking (but I have a pull request pending for that). Rackspace’s OnMetal Servers are a good place to test since they have bonded networks configured by default. They’re also quite fast and always fun for experiments. To get started, head on over to the Rackspace Cloud control panel and build a compute-1 OnMetal server and choose Fedora 22 as your operating system.