Signing RPM packages

RPM signingI’m sure many Linux sysadmins around the university build RPMs to ease the deployment of software to RedHat-a-like systems. But how many people sign them? Signing is important to make sure your boxes are getting the packages you’re expecting, and allows smoother installation on the box itself. I’ve written a few notes about what we do in the ResNet NetOps team in case they are useful to anyone else. These are loosely based upon some notes hidden in the depths of the ResNet wiki.

Setting rpmbuild up to sign

Before you can sign packages, you need to set up your signing key. There is one key per repo, not per repo maintainer (apparently this is different from apt – I dunno, I’m an RPM guy!). There’s no point in re-inventing the wheel, so use these instructions to get set up with your signing key.

Signing your own packages

If you build your packages either from specfile and tarball, or by rebuilding a source rpm, signing is easy. At the time you build your package, just add the --sign option to sign the RPM with your key. There’s no need to specify whom to sign the package as, because your ~/.rpmmacros file specifies this.

rpmbuild -ba --sign source-1.0.spec
rpmbuild --rebuild source-1.0.srpm

Re-signing someone else’s packages

Often, you’ll need to drag someone else’s third-party RPM into your repo for easy deployment. All the RPMs in your repo should be signed with the same key, regardless of original source. You can sign existing RPMs like this:

rpm --resign package-1.0.rpm

What’s this all about?

Every blog needs a first post, and this is it!

What’s the scope of this blog?
Very broadly, the intention is that this blog will fill up with information about Unix and Linux at the University of Bristol.

“It’s all just unix”
We’re hoping to post about cool stuff we’re working on, interesting unix related topics we’re thinking about, talks we’ve seen, and a place to sharing current practice, evolve best practice etc.  The blog is being driven by members of the Virtual Unix Team so will hopefully feature articles from unix/linux administrators around the university, giving a broad range of content.

Unix and Linux use at the University of Bristol is very varied[1], but at the end of the day, it’s all just a slightly different spin on unix so it’s all on topic here!

Local community support
The other purpose of this blog is to pull together (and advertise!) the various sources of community support for linux systems.  We’ve written a first pass at a page about these here: it’ll be expanded as things change, and we’re open to feedback about it, so if you know of a source of support that’s not listed, please let us know!

[1] Off the top of my head I can think of systems running Solaris, RedHat Enterprise, Debian, CenOS, Ubuntu, Scientific Linux, Gentoo, SuSE, FreeBSD, NetBSD…