Spoofing the Build Hostname in Mock

Back to Listing

Hanover, MD, 15 January 2015


I’ve recently been converted to the wonderful world of building RPMs with Mock. Unfortunately, that old problem of wanting all of my packages to look like they come from a single build host has reared its head and my usual searching of Google turned up things that were promising but sadly did not work properly.

The solution turns out to be relatively straightforward and is outlined below.

Prepare the Hackery

The first thing that you need to do is to enable the spoofing of the hostname for all commands running within the Mock chroot.

Create a small snippet of C code that looks like the following:

#include <string.h>
#include <asm/errno.h>
int gethostname(char* name, size_t len) {
 * Be sure to replace 'your.custom.hostname' below with an appropriate
 * fqdn of your choosing.
  char* tmp_name = "your.custom.hostname";
  if ( len < 10 ) {
    return( EINVAL );
  strcpy( name, tmp_name );
  return 0;

Now compile the file using the following commands:

gcc -fPIC -rdynamic -g -c -Wall gethostname.c<br /> gcc -shared -Wl,-soname,libmy.so.1 -o libmy.so.1.0.1 gethostname.o -lc -ldl

You should now have a file, libmy.so.1.0.1, in your current directory.

Bash it Up

You now need to add a segment to the end of your Mock /etc/mock/site-defaults.cfg. You could pick any given Mock configuration file in /etc/mock, but I’m assuming that you want to spoof the hostname in all cases.

config_opts['files']['etc/profile.d/fakehostname.sh'] = """
openssl base64 -d -a -out /tmp/fakename.so.1 <<EOM
# This portion should contain the Base64 encoded
# version of libmy.so.1.0.1 as created above
# If using vim, you can use the following command
# :r! openssl base64 -e -a -in /path/to/libmy.so.1.0.1
# This will be a LOT of text.
# Do NOT include these comments
export LD_PRELOAD=/tmp/fakename.so.1

Mock Some RPMs!

You’re now ready to build RPMs in Mock using your newly created fake hostname. It would be great if the RPM maintainers would make this a standard option and there have been various arguments over time why this is, or is not, a good idea. But, this works 100% of the time without affecting your base operating system.

Trevor has worked in a variety of IT fields over the last decade, including systems engineering, operating system automation, security engineering, and various levels of development.

At OP his responsibilities include maintaining overall technical oversight for Onyx Point solutions, providing technical leadership and mentorship to the DevOps teams. He is also responsible for leading OP’s solutions and intellectual property development efforts, setting the technical focus of the company, and managing OP products and related services. In this regard, he oversees product development and delivery as well as developing the strategic roadmap for OP’s product line.

At Onyx Point, our engineers focus on Security, System Administration, Automation, Dataflow, and DevOps consulting for government and commercial clients. We offer professional services for Puppet, RedHat, SIMP, NiFi, GitLab, and the other solutions in place that keep your systems running securely and efficiently. We offer Open Source Software support and Engineering and Consulting services through GSA IT Schedule 70. As Open Source contributors and advocates, we encourage the use of FOSS products in Government as part of an overarching IT Efficiencies plan to reduce ongoing IT expenditures attributed to software licensing. Our support and contributions to Open Source, are just one of our many guiding principles

  • Customer First.
  • Security in All We Do.
  • Pursue Innovation with Integrity.
  • Communicate Openly and Respectfully.
  • Offer Your Talents, and Appreciate the Talents of Others
Share this story

We work with these Technologies + Partners