Fedora 18 – A Sysadmin’s view

The road less traveled

At our school we have around 100 desktops, a vast majority of which run Fedora, and somewhere around 900 users. We switched from Windows to Fedora shortly after Fedora 8 was released and we’ve hit 8, 10, 13, 16, and 17 (deploying a local koji instance has made it easier to upgrade).

As I finished putting together our new Fedora 18 image, there were a few things I wanted to mention.

The Good

  1. Offline updates: Traditionally, our systems automatically updated on shutdown. In the 16-17 releases, that became very fragile as any systemctl scriptlets in the updates would block because systemd was in the process of shutting down. Now, with systemd’s support for offline updates, we can download the updates on shutdown, reboot the computer, and install the updates in a minimal system environment. I’ve packaged my offline updater here.
  2. btrfs snapshots: This isn’t new in Fedora 18, but, with the availability of offline updates, we’ve finally been able to take proper advantage of it. One problem we have is that we have impatient students who think the reset button is the best way to get access to a computer that’s in the middle of a large update. Now, if some genius reboots the computer while it’s updating, it reverts to its pre-update state, and then attempts the update again. If, on the other hand, the update fails due to a software fault, the computer reverts to its pre-update state and boots normally. Either way, the system won’t be the half-updated zombie that so many of my Fedora 17 desktops are.
  3. dconf mandatory settings: Over the years we’ve moved from gconf to dconf, and I love the easy way that dconf allows us to set mandatory settings for Gnome. This continued working with only a small modification from Fedora 17 to Fedora 18, available here and here.
  4. Javascript config for polkit: I love how flexible this is. We push out the same Fedora image to our school laptops, but the primary difference compared to the desktop is that we allow our laptop users to suspend, hibernate and shutdown their laptops, while our desktop users can’t do any of the above. What I would really like to do is have the JS config check for the existence of a file (say /etc/sysconfig/laptop), and do different things based on that, but I haven’t managed to work out how to do that yet. My first attempt is here.
  5. systemd: This isn’t a new feature in 18, but systemd deserves a shout-out anyway. It does a great job of making my workstations boot quickly and has greatly simplified my initscripts. It’s so nice to be able to easily prevent the display manager from starting before we have mounted our network directories.
  6. Gnome Shell: We actually started experimenting with Gnome Shell when it was first included in Fedora, and I switched to it as the default desktop in Fedora 13. As we’ve moved from 13 to 16, then 17, and now 18, it’s been a nice clean evolution for our users. When I first enabled Gnome Shell in our Fedora 13 test environment, the feedback from our students was very positive. “It doesn’t look like Windows 98 any more!” was the most common comment. As we’ve upgraded, our users have only become more happy with it.

The Bad

The bad in Fedora 18 mainly comes down to the one area where Linux in general, and Fedora specifically, is weak – being backwards-compatible. This was noticeable in two very specific places:

  1. Javascript config for polkit: While I was impressed with the new javascript config’s flexibility, I was most definitely not impressed that my old pkla files were completely ignored. As a system administrator, I find it frustrating when I have to completely rewrite my configuration files because “now we have a better way”. I’ve read the blog post explaining the reasoning behind the switch to the JS config, but how hard would it have been to either keep the old pkla interpreter, or, if it was really desired, rewrite the pkla interpreter in javascript? The ironic part of this is that the “old” pkla configuration was itself a non-backwards-compatible change from the even older PolicyKit configuration a little less than four years ago.
  2. dconf mandatory settings: With the version of dconf in Fedora 18, we now have the ability to have multiple user dconf databases. This is a great feature, but it requires a change in the format of the database profile files, which meant my database profile files from Fedora 17 no longer worked correctly. In fact, they caused gnome-settings-daemon to crash, which crashed Gnome and left users unable to log in. Oops. To be fair, this was a far less annoying change because I only had to change a couple of lines, but I’m still not impressed that dconf couldn’t just read my old db profile files.

As a developer, I totally understand the “I have a better way” mindset, but I think backwards compatibility is still vital. That’s why I love rsync and systemd, but have very little time for unison (three different versions in the Fedora repositories because newer versions don’t speak the same language as older versions).

I know some people will say, “If you want stability, just use RHEL.” That’s fine, but I’m not necessarily looking for stability. I like the rate of change in Fedora. What I dislike is when things break because someone wanted to do something different.

All in all, I’ve been really happy with Fedora as our school’s primary OS, and each new release’s features only make me happier. Now I need to go fix a regression in yum-presto that popped up because of some changes we made because we wanted to do something different.


Comments

Mark T. Kennedy
Monday, Feb 25, 2013

you use btrfs in production? if so, for how long? any problems?

jonathanunderwood
Tuesday, Feb 26, 2013

I’m curious as to how deploying a koji instance has made upgrading easier?

Jonathan Dieter
Tuesday, Feb 26, 2013

We’ve used btrfs on our servers in the past, mainly because we wanted to be able to use snapshots as archives. We switched to ZFS because btrfs just wasn’t fast enough, but this was a couple of years ago.

Right now, we’re using btrfs on the workstations and it’s rocketing. Our boot time has been reduced by somewhere around 50%. One thing to remember, though, is that our workstations can be easily reimaged if there is a problem, so it’s not like the data is in any way critical.

Jonathan Dieter
Tuesday, Feb 26, 2013

It’s all mainly organizational. Our koji instance forces me to follow certain procedures when building and releasing rpms that make it easier for me to see what I did in previous releases and reuse most of it. Our Fedora 8 -> Fedora 10 upgrade was especially difficult because I didn’t do a good job of keeping my packages organized.

If you look at http://koji.lesbg.com/lesbg/18/x86_64/RPMS, you’ll see a mix of rpms, some dating all the way back to Fedora 13. Koji takes care of the inheritance so I don’t have to worry about whether or not I’ve got the latest build, and supports multiple releases, so I can start putting together our Fedora 18 build while still pushing critical fixes to Fedora 17.

And, finally, koji takes care of repo management, giving me a repository of only the latest packages, making it easy to see what we’re actually using. I can then easily retire obsolete packages in newer repositories while keeping them in the old repositories.

Bhaskar
Monday, Mar 4, 2013

Hi, I am pretty new to linux. started using fedora 17 a few months back. I tried to upgrade it to Fedora 18 by yum upgrade… After all files were downloaded, the machine rebooted and it now just gets stuck with busy cursor. It never reaches the login screen, Just that fedora logo with a busy cursor. Can you help me out.

Regards

Bhaskar

Checo
Saturday, Mar 9, 2013

Sorry to leave a message in this post, but I couldn’t do it on the Novacom for Fedora, Thanks for the work for like a charm the yum install novacom.

Great work.

Jonathan Dieter
Saturday, Mar 9, 2013

You are most welcome! Thanks for taking the time to show your appreciation!