Related topics




Linux – and the community that surrounds the open-source OS – can seem intimidating to the uninitiated, but it does not have to be so. To illustrate, I want to go over the single most common "why doesn't it work" issue I encounter among junior admins: cloning CentOS virtual machines (VMs).

Let's presume that you have a basic virtualisation system without any bells or whistles. You clone your VMs by taking the master VM offline, copying the image file and lighting the clone up. At this point, most virtualisation software will pop up a little message asking you if you had copied the VM or moved it; the hypervisor wants to know if it should (among other things) generate a new set of MAC addresses for the virtual NICs, the emulated network hardware.

When you light up your cloned VM, you'll find that it can't see any of its network cards; running the program ifconfig will return only the loopback interface. This is a bit of a problem if you want that VM to actually do anything useful.

The resolution is reasonably simple; the udev application (responsible for detecting network adapter changes) has likely picked up the new NICs, but not done anything particularly useful about them. Open up /etc/udev/rules.d/70-persistent-net.rules in your favourite text editor and you'll see two lines of text (at least) that describe network adapters trying to lay claim to each eth* slot.

You can put a # character in front of any lines that don't correspond to the current MAC address of the virtual NIC assigned to this VM; the hash symbol marks the line as a comment to be ignored by software. Alternately, simply delete /etc/udev/rules.d/70-persistent-net.rules, reboot and let udev generate a clean copy.

You'll notice after that reboot that /etc/udev/rules.d/70-persistent-net.rules now only contains one entry for each NIC in your system, but ifconfig still only shows the loopback adapter. This is because the sysconfig networking scripts (located at /etc/sysconfig/networking-scripts/ifcfg-eth*) haven't been updated with the new MAC address. Open up the appropriate file (for example /etc/sysconfig/networking-scripts/ifcfg-eth0) and edit the MAC address in there so that it matches the MAC address discovered by udev in /etc/udev/rules.d/70-persistent-net.rules.

A frustrating but fairly straightforward fix.

More fun with enterprise Linux distro CentOS

If you followed that, then we should be able to plough through some of the related networking wrinkles virtualising CentOS poses. First up: CentOS 6.x doesn't recognise the "enhanced" networking cards of VMware or Hyper-V until the hypervisor tools are installed. If you – as I often do – forget this fact and install a clean VM without first using "legacy" networking options, then after installing the hypervisor tools (to get the network drivers) and rebooting, you'll still have no network cards.


Generated in one, but not the other (click to enlarge).

Udev will pick them up; you'll be able to see which MAC was assigned to which eth* interface by taking a look at /etc/udev/rules.d/70-persistent-net.rules. The issue is that none of the ifcfg-eth* scripts in /etc/sysconfig/networking-scripts/ were ever generated in the first place: there were no network cards visible to the operating system upon install.

If you want networking, you'll have to create those by hand. If you did go the "proper" route and install the system with legacy networking support, installed the hypervisor tools and then switched the NICs to the enhanced variety you'll be right back in the same boat as if you just cloned the VM.

I chose CentOS's bizarre networking configuration as one example among dozens of "not particularly difficult to work around, but damned annoying" design choices in the Linux world. Each distro has them and these choices present a burden to new admins. They can even be frustrating to experienced ones. Worse still for the new admin is trying to find help to these sorts of problems in the internet's many forums.

It's unfortunate because the Linux community as a whole isn't represented by vocal discussion-board posters, no more than the distros themselves should be judged by a few maddening quirks. There are plenty of Linux administrators and users out there who don't care one whit for the screeching holy wars. They are often quite happy to help and they usually go on to build features and products to make the lives of administrators easy.

One great example of an underused feature is the customisation wizard in VMware's vCenter. It can and does take a lot of the stress of cloning a VM off your hands.


Virtualmin (click to enlarge)

Puppet and Chef are good tools for systems administration on a wider scale; even System Center 2012 SP1 has made solid inroads here. For those standing up and maintaining web-facing services, the Virtualmin family (Webmin, Virtualmin, Cloudmin and Usermin) help automate and simplify many mundane (and often frustrating) tasks.

Linux doesn't have to be scary. It isn't difficult to learn and the community isn't nearly so toxic as the most vociferous members would make it seem. It does however take some commitment to learn. It is far easier if you start the journey by unearthing forums and IRC channels that are noob friendly. Try to find configuration and management tools that make the transition easier.

Over the years I've talked about some of the tools that make Linux easier for me. Today I am making an appeal to El Reg's esteemed commentards: in the forums, please list your favourite resources for Linux noobs. What forums, IRC channels, wikis, manpage repositories, configuration tools and so forth have made your lives easier? There are thousands and thousands of Linux admins that read this site; let's put our heads together and make a grand list. Maybe together we can help the signal overcome the noise. ®

Sponsored: Transform Your IT Infrastructure