Pulp plugin to handle Debian packages.

WARNING: There may be bugs.

Admin extensions do not need any additional tools.

Server extensions need:

• python-debian: https://pypi.python.org/pypi/python-debian
• python-debpkgr: https://pypi.python.org/pypi/python-debpkgr

The debian plugin is now available as RPMs for RHEL7, Fedora 24 and Fedora 25. To install the plugin to an existing pulp server, install the following packages:

$ sudo dnf install \
  pulp-deb-plugins \
  python-debian \
  python-pulp-deb-common \
  python2-debpkgr

On a machine with the pulp-admin client, install the admin client extensions:

$ sudo dnf install pulp-deb-admin-extensions

To enable the plugin, you will need to stop pulp services and migrate the database, and then restart the services.

To do this, on the pulp server run:

$ sudo systemctl stop \
  httpd \
  pulp_celerybeat \
  pulp_resource_manager \
  pulp_streamer \
  pulp_workers \
  qpidd \
  goferd

$ sudo -u apache pulp-manage-db

... output omitted ...

$ sudo systemctl start
  httpd \
  pulp_celerybeat \
  pulp_resource_manager \
  pulp_streamer \
  pulp_workers \
  qpidd \
  goferd

The pulp_streamer and goferd services should be omitted if those services are not installed.

On a machine with the pulp-admin client configured to control your pulp server, and with the pulp-deb-admin-extensions package installed, you should now be able to create debian repositories.

$ pulp-admin deb repo create --repo-id now-i-serve-debian-packages

Alternatively, you can build the RPMs from spec file and then install with rpm. If you do this, you must also build python-debian and python-debpkgr as rpm packages and install.

To sync the stable and testing releases of the usual debian archive run:

pulp-admin deb repo create --repo-id 'debian-st' --feed 'ftp://ftp.debian.org/debian/' --releases 'stable,testing'
pulp-admin deb repo sync run --repo-id 'debian-st'

The --releases option is a comma separated list of releases to be synchronized. In a similar way, --components and --architectures are used to select which components and which architectures of the archive are to be synched.

For example to create a testing distribution for sparc that uses main and contrib component, run:

pulp-admin deb repo create --repo-id 'debian-testing-sparc-mc' --feed 'ftp://ftp.debian.org/debian/' \
  --releases 'testing' --components 'main,contrib' --architectures 'sparc'

The typical Ubuntu use case could be like

pulp-admin deb repo create --repo-id 'xenial-amd64' --feed 'http://de.archive.ubuntu.com/ubuntu' \
  --releases 'xenial' --components 'main' --architectures 'amd64'

This plugin uses deb822.PkgRelation to parse Debian dependency fields.

We currently support breaks, conflicts, depends, enhances, pre_depends, provides, recommends, replaces, suggests.

The representation of a Debian relationship is following, when possible, the conventions used by pulp_rpm:

• The representation is a list of sub-items, with an implicit conjunction (AND) for the sub-items. In other words, all the sub-items have to evaluate to True in order for the relationship to be satisfied.
• Simple (single package) items are dictionaries with a name field. They may contain additional fields version, flag, arch, restrictions.
• Versioned dependencies will have a version field to describe the desired target version, and the flag field will denote the operator for comparing versions. Where the operators in a Debian representation are one of "<<", "<=", "=", ">=", ">>", flag will be LT, LE, EQ, GE, GT respectively.
• arch is a list of architecture strings. Negation is represented with a leading exclamation mark.
• restrictions, if present, is a list of one or more lists of strings. Just like with architectures, negation is represented with a leading exclamation mark.

In addition, Debian supports disjunction. Where simple package dependencies are dictionaries, disjunction (OR) is a list of simple package dependencies.

Here are examples of dependencies and their representation in Pulp:

• 'emacs | emacsen, make, debianutils (>= 1.7)':

 [
     [{"name": "emacs"}, {"name": "emacsen"}],
     {"name": "make"},
     {"name": "debianutils", "version": "1.7", "flag": "GE"}
 ]

• 'tcl8.4-dev [amd64], procps [!hurd-i386]':

 [
    {"name": "tcl8.4-dev", "arch": ["amd64"]},
    {"name": "procps", "arch": ["!hurd-i386"]}
 ]

• 'texlive <stage1 !cross> <stage2>':

 [
     {"name": "texlive", "restrictions": [["stage1", "!cross"], ["stage2"]]}
 ]

To enable repository metadata signing, you will need to supply a configuration file /etc/pulp/server/plugins.conf.d/deb_distributor.json, containing something like:

{
  "gpg_cmd": "/usr/local/bin/sign.sh",
  "gpg_key_id": "0452AB3D"
}

The supplied sign command has to be an executable accessible to the Apache user. It will be supplied the path to a Release file to be signed, and is expected to produce a file named Release.gpg in the same directory as the Release file. Additionally, the sign command will be passed the following environment variables:

• GPG_CMD
• GPG_KEY_ID (if specified in the configuration file)
• GPG_REPOSITORY_NAME
• GPG_DIST

The sign command may decide on a key ID to use, based on the repository name or the dist that is being signed.

A minimal sign command using GPG could be:

#!/bin/bash -e

KEYID=${GPG_KEY_ID:-45BA0816}

rm -f ${1}.gpg

gpg --homedir /var/lib/pulp/gpg-home \
    --batch \
    --detach-sign --default-key $KEYID \
    --armor --output ${1}.gpg ${1}

You could import your password-less GPG keys like this:

mkdir /var/lib/pulp/gpg-home
chmod 0700 /var/lib/pulp/gpg-home
gpg --homedir /var/lib/pulp/gpg-home --import <path-to-secret-keys>
chown -R apache.apache /var/lib/pulp/gpg-home

WARNING! The example, as presented above, is not suitable for production use. Unprotected GPG keys may be easily stolen. You may want to consider more secure alternatives for your signing needs, like a dedicated server, potentially with a Hardware Security Module.