Sjoerd Oostdijck

How We Deployed DMARC

5 min read

0 You have liked this article 0 times.
0

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 into SOURCES
  • Copy mailman.spec from tmp to SPECS
  • 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.

0 You have liked this article 0 times.
0

About the author

Comments 0