As I mentioned in my last post, I’m setting up the computer system in our sister school in Ain Zhalta, up in the mountains, and last summer I set up the computer system in our sister school down in Tyre.

This includes both servers and workstations, and, being the lazy sysadmin that I am, I prefer not to reinvent the wheel for each place. My method last summer was to build rpms for most of the school-specific configuration settings, which allows me to make small changes and have them pulled in automatically.

The one problem I’ve hit is that there are some packages that have to be different between the two (and now three) schools. For example, the package lesbg-gdm-gconf contains the gconf settings so our login says “Welcome to the LES Loueizeh computer system”. Somehow, I don’t think Tyre or Ain Zhalta will appreciate having that showing on their welcome screen. Each school also has a different logo, and, again, the other schools don’t want our logo on their backgrounds.

So, what I really need is a way of organizing my rpms so that the common ones get passed to all the schools while the per-school ones only get passed to their school. Hmm. Think, think, what software is available in Fedora that could do that…

Enter koji. I had already setup a koji buildsystem to help track down the disappearing deltarpms bug (yes, the bug is still there, but that’s for another day), and the hardest part was getting the SSL certs right.

I set up a koji instance on our dedicated server (now yum upgraded to Fedora 13, see this post for more details) by following these instructions, and now have a nice centralized build system for our schools at http://koji.lesbg.com.

The beauty of koji is that it handles inheritance. For Fedora 13, I’ve created one parent tag, dist-f13, and three child tags dist-f13-lesbg, dist-f13-lest, dist-f13-lesaz. All of the common packages are built to the dist-f13 tag, while the school-specific packages are built to their respective tags. Every night, I generate three repositories (lesbg, lest, and lesaz), and each repository has the correct rpms for that school. What could be easier than that?

There are a few caveats, though. First, our dedicated server is slow. It’s an old celeron with a whole 1GB of RAM (through HiVelocity), so I’ve had to compromise on a few little things. First off, we run both the x86_64 and i386 Fedora distributions, but our server is i386 only. This means that, at least for the moment, all of our packages have to be noarch.

Second, a normal part of the build process is to merge the upstream Fedora repositories with the local packages after each build (so it can be used to build the next package). On our server, this takes almost two hours. So I’ve modified it so the build repository doesn’t include the local packages, and that mess is now gone. The downside is that I can’t BuildRequires any local packages, but, seeing as they’re all supposed to be configuration anyway, that hasn’t been a problem yet (and I don’t expect that it ever will be).

Anyhow, aside from some small glitches that seem to reflect more on the slow hardware available, koji has done the trick and done it nicely. With our current setup, I can now add another organization with a minimal amount of fuss, and that’s just what I was looking for! Thanks koji devs!

Gears credit: Gears gears cogs bits n pieces by Elsie esq. Used under CC BY

As some have noticed, there haven’t been nearly as many deltarpms in Fedora since about the time Fedora 13 was released. This was a result of a couple of different bugs (see bug report here).

The first problem, affecting Fedora 13, was that deltarpms were only being created against GA. This meant that you only really benefited from them if it was the first update for that package for Fedora 13.

The second problem, affecting all Fedora releases, was that deltarpms were being deleted after each push. This meant that if you weren’t downloading your updates very frequently, you would miss a lot of them.

The good news is that both problems should be fixed in today’s or tomorrow’s push.

Edit (7/2/2010): It looks like the second problem has not been fixed. We’re still trying to track down the problem.

Bug credit: Amoeba by David Patterson and Aimlee Laderman at Micro*scope. Used under CC BY-NC