Lets say I want to make an RPM which delivers an Apache Webserver with its own OpenSSL:


Since Apache mod_ssl requires a real OpenSSL installation I have to configure --prefix=/mydir/openssl, make, make install OpenSSL to /mydir/openssl so Apache with mod_ssl can actually compile with configure --with-ssl=/mydir/openssl.

Unthinkable on a build server (Jenkins) with no permissions on anything outside its jobs directory. But I need to build Apache with OpenSSL and package it into an RPM (to deliver postfixed multiple Apaches each with their own OpenSSL).

So I thought that mock is the solution (which is more likely to be installed on the build server than we get any user/install permissions).

But I haven't found a full documentation on how I can use mock to use rpmbuilds full capabilities.

I tried mock -r epel-7-x68_64 example.src.rpm but it is looking for /builddir/build/SPECS/example.spec and so failing ... why? from where did it got this file?

This was just an example, the real problem consists of 7 independent software packages which should get configured/compiled against each other so they act as a single service ... and packaged into a single RPM for Red Hat Satellite to be delivered onto >200 servers ... without actually installing them on the build server ...

Any help or a link to usable documentation/examples are highly appreciable!


The best sources of documentation would be the mock source code, the official rpm documentation, the rpm packaging guide, and any further documentation any of those recommend. As for your posted example, it appears your example.src.rpm package does not have a proper spec file in the correct place for mock to work with.

mock will take an input of a src.rpm file to rebuild, or you can use a spec file and sources directory to build a source rpm (SRPM). With some extra config, you can even use mock directly with source code checkouts. Once you have mock installed and a user configured to use it (mock will complain if you attempt to use as root, an unprivileged user needs to be in the mock group), it is fairly simple to use:

yumdownloader --source openssl
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results openssl-*.src.rpm

That will rebuild the distribution provided OpenSSL and place the resulting packages in the rpm-results dir. To make changes to the distribution provided package, you would want to install the src.rpm, make your changes, then build the resulting rpm files:

yumdownloader --source openssl
rpm -ivh openssl-*.src.rpm
# usually this installs to ~/rpmbuild
# make your changes to ~/rpmbuild/SOURCES/* and ~/rpmbuild/SPEC/openssl.spec as necesary
mkdir rpm-results
mock -r epel-7-x68_64 --resultdir=rpm-results --buildsrpm ~/rpmbuild/SPEC/openssl.spec
mock -r epel-7-x68_64 --resultdir=rpm-results rpm-results/openssl-*.src.rpm

I am not sure if newer versions do not require the two step build (SRPM => RPM), but this is how we have been using mock at my shop. You would likely want/need to do that for each package you are attempting to rebuild. I would not advise packaging everything into a single package like you ask, but nothing technically stops you from doing that. You would just need to make you own spec file that combines everything together or use a different tool such as FPM.

  • Hey thank you for your answer. I got mock running and rebuilding my SRPM but I have the same problem as without mock: within mock's chroot I can't make install any of the packages because the SRPM rebuild is run as non-root so it can't "install" anything during the build (and installing them into BUILDROOT does not work because other packages need them bo be installed into their true path to compile ...). Is there any way the SRPM rebuild process can be run as root within mock's chroot? again this all should work on a build server with a non-root user! – Pali Apr 4 '18 at 8:26
  • Not sure if your issue is caused by incorrectly using mock or if you are incorrectly building packages. The mock user has full access to the mock chroot, when I enter the chroot I am the root user. You install a package into the mock chroot with mock --install somepackage.rpm. Packages are installed into the mock chroot in the exact place the RPM tells them to install it. You do not mention how you are attempting to build packages, maybe a spec file you are trying or some specific errors you are seeing so others can know what you need help with. – GracefulRestart Apr 4 '18 at 17:13
  • appearently the srpm rebuild is run as user 'mockbuild' (aka. the user running 'mock') while mock's chroot is populated as root and so the srpm rebuild process can't create directories at top level of mock's chroot because it's owned by root:root ... – Pali Apr 5 '18 at 6:36
  • The files should belong to the mock group so users in the mock group have access to them. You should never have to interact directly with the chroot anyway, just use the tools mock provides to manage everything. I guess I still do not follow what your problem is, why is the ownership of the files causing an issue for you? – GracefulRestart Apr 5 '18 at 7:11
  • yes I know that they "should" belong to the mock group but every directory in the chroot belongs to root:root except the '/builddir' directory obviously ... its a fresh mock installation and I also deletet mock's chroot directory (the one with the root and result directories) and populated it multiple times but as I know the chroot is populated as root user ... trying it out is more reliable than any docs ... – Pali Apr 5 '18 at 7:15

I am a maintainer of Mock, so I should provide you an answer. But I really cannot, because you did not specify what is actually a problem.

I can only elaborate on how Mock works and resolve some of your confusions.

When you call mock -r fedora-27-x86_64, then Mock will do (skipping some boring details):

  1. dnf install --installroot /var/lib/mock/fedora-27-x86_64/root @buildsys-build This will install minimal system in separate directory. Further in this answer I will refer to /var/lib/mock/fedora-27-x86_64/root as $CHROOT.

  2. Mock will extract your example.src.rpm. Especially it will put spec file into $CHROOT/builddir/build/SPECS and tar ball into $CHROOT/builddir/build/SOURCES.

  3. Mock will parse your spec file and install all packages listed in BuildRequires into $CHROOT. (This is done as root).

  4. Mock will then chroot() into $CHROOT and run there rpmbuild -ba /builddir/build/SPECS/example.spec. This is done as unprivileged user (with the UID equal to your UID). This is done because running rpmbuild have always been discouraged and can lead to serious problems.

So if you want to install some additional packages in chroot., you should not do that from within spec file by calling yum/dnf install (especially because rpm is not reentrant). But you should specify those packages in BuildRequires and provide a repository with those packages.

You can provide a repository either using mockchain -a REPOS (mockchain is a thin layer on top of mock) or by:

cp /etc/mock/fedora-27-x86_64.cfg ~/my-custom-fedora-27-x86_64.cfg
#add your repository to ~/my-custom-fedora-27-x86_64.cfg
mock -r ~/my-custom-fedora-27-x86_64.cfg example.src.rpm

If you have 7 src.rpm packages depended on each other, then probably the best way is to call mockchain 1.src.rpm 2.src.rpm .... 7.src.rpm and mockchain will create a temporary repository for results and try to build those packages in a naive way in while at-least-one-package-build do another loop.

If you specify what is actually your problem, then I can provide a more specific answer.

  • Many thanks for explaining what Mock is actually doing! Thing is I have to build 7 software packages from source because most of them are configured (./configure --with-openssl=/bla etc.) to use some other of those software packages (header files, installation directory, etc.). So I wanted to use Mock so I can install them all in their real paths (buildroot is not working because after packaging them into the RPM and installing them most things are broken since they have hardcoded paths in their binaries). But mock's rebuild is run as mockbuild user and has no permissions to mkdir /bla ... – Pali Apr 5 '18 at 13:17
  • ??? When you build your custom openssl, and then put is as BuildRequires, then it is put into $CHROOT, which is a root during buildtime. Note that buildroot is (from host perspective) $CHROOT/%{buildroot}/ and it is used for creating layout which will go into %files. Not for installing dependencies. – msuchy Apr 9 '18 at 6:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.