More tea please.


dynpk is a tool for bundling programs together from a local Linux system into an arrangement that allows them to be run on any other Linux system, regardless of distribution. For example, it can be used to run Fedora’s ipython on a RHEL 5 machine without having to perform any compilation from source. As well as being an alternative to static linking, it does more than static linking — bundling all the other files that libraries require to run as well (e.g. files in /etc).


Get the source like so:

git clone git://srobo.org/~rspanton/dynpk.git


Build the wrapper and audit library that dynpk needs to function:

% make
gcc -fPIC -g -c -Wall audit.c -o audit.o
gcc -shared -Wl,-soname,audit -o libaudit.so audit.o
cc -g -o wrap -static -Wall -Wl,--gc-sections  wrap.c


Use the example config file “conf.ini” as base for a new configuration file. This config file tells dynpk what packages and files to include in your bundle, as well as a few runtime-related things. Here’s a config file that’ll wrap bash and coreutils:

# RPMs to include in the bundle
rpms: bash coreutils

# Executables to include in the bundle

# Holes to make in the filesystem to the host
exclude_paths: /home /tmp /dev

# Where the dynamic linker needs to look in the fake system
library_dirs: /lib /usr/lib /usr/lib/mysql

# Things that need to be in PATH in the fakechroot
path: /usr/local/bin /usr/bin /bin /usr/local/sbin /usr/sbin /sbin

# Whether to use libaudit
use_audit: False

Invoke dynpk with it, like so:

./dynpk conf.ini bundle

dynpk will create a directory called “bundle”. Running the bash binary in this bundle will result in a shell that is inside the fakechroot:

[rob@zarniwoop dynpk(master)]$ ./bundle/bin/bash 
[FAKECHROOT@zarniwoop dynpk]$cd /
[FAKECHROOT@zarniwoop /]$ls
bin  dynpk.config  etc	lib  sbin  usr	wrap
[FAKECHROOT@zarniwoop /]$

Here’s a summary of all of the current config file options:

How it works

dynpk encases programs in a fakechroot environment that contains everything they need to run, including the dynamic linker and all of their auxiliary files such as shared libraries and configuration files.

To make sure that programs don’t escape the fakechroot, it wraps them with a statically linked executable that invokes them with the right dynamic linker.

A warning

dynpk is not intended to be a tool to ensure that a program cannot escape its fakechroot. It is intended for situations in which one wants to run a program on a system on which you do not have control over what packages are installed.

Further Work

Things that would be good for dynpk to support:

Site by Robert Spanton. © 2008 - 2011