The new breed

Picked up a new Lenovo ThinkCentre this week and installed Fedora 17 on it. My idea is to use it as a platform for my virtual lab environment at home. A friendly warning to my brothers and sisters in system administration below.

The system is a Lenovo ThinkCentre Edge72 3484-BGU mini tower. For $499 you get an i3 dual core 3.3 GHz CPU, a 3 port SATA controller and 2 RAM slots that can hold up to 16 GB total (and an IEEE standard parallel port!). When I got it home I swapped out the 500 GB 7200 RPM Western Digital Blue hard disk it shipped with a blank Seagate Barracuda of the same size and speed. I’d rather run the WD, but I wanted to preserve the O/S “just in case”. There are 2 x 8 GB sticks of AMD branded RAM on the way from NewEgg that I’ll swap the shipping 4 GB out for.

[the Lenovo support site reported my “one year” warranty expires in October of this year — I can’t wait to hear how they explain that one!]

The installation of Fedora 17 went well enough. I used the x86_64 Live DVD for that. One thing I made sure to do was to throw the switch in the BIOS that favored “Legacy” operating systems over UEFI-ready ones. The Edge72 is a UEFI machine and I decided it was best not to bet on Fedora’s compatibility with that new standard (the bricking earlier in the week of several Samsung laptops installed with the latest, supposedly “UEFI compatible”, Ubuntu definitely had an influence on that decision).

Why Fedora 17? One reason really: Red Hat Enterprise 7, the next version of the enterprise system due out later this year will be based on Fedora 17/18.

I recently set aside some time to watch the video from last year’s Red Hat Summit, and together with what I’d already gleaned from various outside sources it was clear that RHEL 7’s release is going to mark a major change in how Linux will be managed by enterprise IT departments going forward. Not at the 30,000 foot “high level”, but down here in the weeds (or the engine room, to use another metaphor), where mere mortal system administrators like myself live.

After a weekend with Fedora 17 I came away with two very strong conclusions: (a) installing the more recently released Fedora 18 would have been an absolute nightmare; and (b) every Linux system administrator who wants to keep their job over the next 3 or 4 years when RHEL 7 will probably become dominant needs to start learning the new system NOW.

Major, potentially show-stopping for the uninitiated, changes in both what you can do and how you do it have been introduced over the last few versions of Fedora and these are front and center in Fedora 17. Forget all that nonsense about the awful, productivity-killing, Gnome 3 desktop. Most of the changes there are mere annoyances that are easily accommodated by utilities like the gnome-tweak-tool (that you can use to restore the minimize button, unfortunately its effect on the fonts used by the system is less spectacular — be prepared for the thin, spidery look that’s part of the Ubuntu experience).

The real threat comes from deep within. Two subsystems in particular: NetworkManager and systemd.

NetworkManager continues to be the most evil of all that server administrators will have to deal with. Configuring a bridged network for KVM virtual machines to use has been a real horror show, requiring all the accumulated wisdom of the ages to get working. Those who have had experience building servers with RHEL 6 already know most of the drill: (1) Stop and disable NetworkManager; (2) Create new ifcfg- control scripts under /etc/sysconfig/network-scripts (being sure to include the directive “NM_CONTROLLED=no” in all scripts, including ifcfg-lo). Like RHEL 6, Fedora 17 also continues to foist the maddeningly inconsistent “Consistent Device Naming” insanity on us as “for our own good”. Who elected these guys king anyway?

And System V init is dead as of Fedora 17. Really dead. The service command actually invokes systemctl, the systemd administration tool, and chkconfig forwards commands as requests to systemctl. So anyone who still reflexively does a “/etc/init.d/httpd restart” is going to need to kick the habit pretty soon. I’ll be checking out the legacy compatibility with some enterprise apps that still use the old style init scripts just as soon as I get through migrating all my files and scripts from the old workstation.

Of course there are those who would argue that many needed changes to Unix/Linux are long overdue. The System V init system is over 30 years old, and has not exactly improved with age. Self-configuring network services are also something that should have been perfected at least 5 years ago, back when we all completed our adoption of IPv6 and retired the last of our IPv4 subnets. But that’s another story.