We were asked to update mailman so it can support DMARC. To that end, we decided to build our own RPM package for mailman. In this article we describe how we did this and what we learned in the process.
Introduction
Because of the recent DMARC inplementation at several free email providers more and more of our mailman mailinglist subscribers ran into trouble using the maiing lists. Luckily the mailman folks had already implemented a workaround and all I had to do was rebuild an older RPM with the latest source code. This article is a short how-to on how you too can rebuild RPMs for your needs.
Building an RPM - for mailman with DMARC
Sometimes there will be a requirement to apply a local modification or an unofficial patch to a well known program, making it impossible to use its upstream package. This has been the case so far with adding DMARC support to mailman. Creating your own RPM (RPM package manager) is not as scary as you might think. Nine out of ten times, most of the legwork has been taken care of by the package maintainers from Redhat/Epel/IUS or some other repo (also called RPM). All you need to do is track down the latest SRPM (source RPM), unpack it, change it a bit and repackage.
In my case, the request came to update mailman to the latest version in order to support DMARC properly for our mailman mailing lists. More and more of the large e-mail providers like Outlook.com and Yahoo Mail have implemented DMARC, which can break traditional mailing lists.
The outline
To build an RPM, you need to have something called a SPEC file. This is the recipe that tells the rpmbuild
software exactly what's needed to create your RPM. This includes things like dependencies, software patches, configuration files, etc.
All this is rolled into a Source RPM by rpmbuild (or mock) that includes all the needed parts in one handy file. This SRPM is then pre-compiled into a normal RPM by mock (or rpmbuild, but that's less useful usually).
In many cases, you will want to build your RPM on multiple different OS versions. This is where mock, "a 'simple' chroot build environment manager for building RPMs," comes into play. It will let you build all the RPM flavours (el{5,6,7}) on one central build box.
Preparation
To get started on building your first RPM follow these easy steps:
- Do not build your RPM as root (who knows what's inside the SPEC file, right?)
- Create the working folders:
mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS,tmp}
- Create a file called
.rpmmacros
in your homedir with these contents (change the paths to where you're working):
%_topdir /<my-build-folder>/rpmbuild
%_tmppath /<my-build-folder>/rpmbuild/tmp
- Install the following software:
rpm-build
mock
(from extras repo, not from epel) e.g.sudo yum install mock yum --disablerepo=epel
git
Finding an SRPM
Find the latest available version that you can use as a starting point. You can then extract this SRPM to get the SPEC file as well as any patches that are included to make things work smoothly on RHEL/CENTOS. Usually I end up using rpmfind and grab something that's sensible for my OS (for example Fedora RPMs work well when building for CENTOS).
- Download your SRPM
- Extract the SRPM like this:
rpm2cpio ./mailman-2.1.15-24.el7.src.rpm | cpio -idmv
- Place the contents in
~/rpmbuild/tmp
(or where you've made your build dirs)
Get started
All of these folders are the ones you made earlier under ~/rpmbuild
:
- Download the source and put the
.tar.gz
intoSOURCES
- Copy
mailman.spec
fromtmp
toSPECS
- Go through the spec file and check the "patches" and "sources" (this step can take a while, reading patches is not for the faint of heart).
- Copy the sources and patches that you have kept in the .spec file to
SOURCES
. - The easy way out: https://github.com/soostdijck/mailman-el7-rpm
Build
Create your own SRPM with mock
I prefer building my RPMs with mock although you can also use rpmbuild. If you want feel free to give rmbuild a try as well. Something like this should give you a general idea: rpmbuild --nodeps -bs ~/rpmbuild/SPECS/bind.spec
NOTE: to build a package for a particular OS version, there must be a mock
configuration for it under /etc/mock
. For example: /etc/mock/centos-6-x86_64.cfg
:
# mock --unpriv --buildsrpm --no-clean -r centos-6-x86_64 \
--spec=~/rpmbuild/SPECS/mailman.spec \
--sources=~/rpmbuild/SOURCES
Build the package from the SRPM
NOTE: mock
builds RPMs from the SRPM, so if you change anything, rebuild the SRPM as well.# mock --unpriv --no-clean -r centos-6-x86_64 /path/to/your.src.rpm
Installation
When you're happy with your resulting RPM, install it on a testing box. After the testing is done, it is ready for production.
Conclusion
Many people seem to think RPMs are these magical things that either work or don't. I hope this short article will help you to realise that they are just precompiled config files that describe what commands to run in which order, and maybe apply a patch or two. Roll it all into one convenient file and presto.
It all really just comes down to these steps: Grab an existing SRPM, unpack it, tweak the spec file to work with the new source, recompile, profit...
p.s. if you have any questions feel free to leave a comment and I'll try to answer them.
Footnote: RPM Package Manager (RPM) (originally Red Hat Package Manager; now a recursive acronym) is a package management system.
Comments 0
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.