Features¶
RPM Support includes a number of features that are not found in the generic Pulp platform, the most important of which are described below.
Types¶
Pulp RPM supports the following types:
RPM
DRPM
SRPM
Erratum
Distribution
Package Group
Package Category
Modules and module defaults
Errata¶
Red Hat provides security, bug fix, and enhancement updates for supported Red Hat Enterprise products. These security updates are provided through the Red Hat CDN, and are described by errata. Pulp supports these errata types with a number of related features.
Errata are synchronized from upstream repositories. Errata can also be copied from one repository to another. Administrators can also upload their own errata to a repository. Please see the Recipes documentation to learn how to perform these operations.
Modularity¶
Pulp supports the following modularity repository content management use cases:
synchronization of the modularity metadata content, the
repodata/*modules.yaml.gz
file, with either immediate or on-demand synchronizationpublication of the modularity metadata with the repository publication
copy of one or more modules and/or module defaults between the repositories
removal of one or more modules and/or module defaults from the repository; RPMs related to a module are also removed to preserve consistency of a module
upload of one or more modules and/or module defaults into the repository
modules published through Pulp are consumable by the
dnf
client
Boolean (rich) dependencies¶
Pulp supports RPM content with boolean dependencies in these basic repository and content management use cases:
synchronization, publication and content upload
copying content between repositories
displaying boolean dependencies
providing the content to the
dnf
client to process boolean dependencies
Advanced copy between repositories¶
There are content types in RPM plugin which relate to each other in some way,
so there are use cases when not only a specific content unit should be copied
but also content units related to it. In such cases a recursive
flag should
be used during copy operation.
In a simple case the result of such API call copies unit and units directly related to it. There are more complicated relations and behavior may vary depending on the content and the type of a recursive flag. More information about such cases below.
RPM dependencies¶
An RPM can depend on other RPMs.
dependencies: foo.rpm -> bar.rpm -> baz.rpm
repo A
|
|----foo-1.0.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
repo B
|
|----bar-0.7.rpm
Result of copying foo-1.0.rpm from repo A to repo B:
repo B
|
|----foo-1.0.rpm
|----bar-0.7.rpm
recursive
Result of copying foo-1.0.rpm from repo A to repo B:
repo B
|
|----foo-1.0.rpm
|----bar-0.7.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
recursive_conservative
Result of copying foo-1.0.rpm from repo A to repo B:
repo B
|
|----foo-1.0.rpm
|----bar-0.7.rpm
|----baz-1.0.rpm
Modules and their artifacts (RPMs), simple case¶
module-FOO: [foo-1.0.rpm]
repo A
|
|----module-FOO
|----foo-1.0.rpm
repo B
|
|----bar-0.7.rpm
Result of copying module-FOO from repo A to repo B:
repo B
|
|----module-FOO
|----foo-1.0.rpm
|----bar-0.7.rpm
All available artifacts are copied, always. There is no way to copy just module on its own,
if any of its artifacts are present in a source repo (repo A).
Modules and their artifacts (RPMs), complicated case 1¶
dependencies: foo.rpm -> bar.rpm -> baz.rpm
module-FOO: [foo-1.0.rpm]
repo A
|
|----module-FOO
|----foo-1.0.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
repo B
|
|----bar-0.7.rpm
recursive
Result of copying module-FOO from repo A to repo B:
repo B
|
|----module-FOO
|----foo-1.0.rpm
|----bar-0.7.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
recursive_conservative
Result of copying module-FOO from repo A to repo B:
repo B
|
|----module-FOO
|----foo-1.0.rpm
|----bar-0.7.rpm
|----baz-1.0.rpm
Modules and their artifacts (RPMs), complicated case 2¶
dependencies: foo.rpm -> bar.rpm -> baz.rpm
module-FOO -> module-XXX
module-FOO: [foo-1.0.rpm]
module-XXX: [xxx-1.0.rpm, yyy-1.0.rpm]
repo A
|
|----module-FOO
|----module-XXX
|----foo-1.0.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
|----xxx-1.0.rpm
|----yyy-1.0.rpm
repo B
|
|----bar-0.7.rpm
recursive
Result of copying module-FOO from repo A to repo B:
repo B
|
|----module-FOO
|----module-XXX
|----foo-1.0.rpm
|----bar-0.7.rpm
|----bar-1.0.rpm
|----baz-1.0.rpm
|----xxx-1.0.rpm
|----yyy-1.0.rpm
recursive_conservative
Result of copying module-FOO from repo A to repo B:
repo B
|
|----module-FOO
|----module-XXX
|----foo-1.0.rpm
|----bar-0.7.rpm
|----baz-1.0.rpm
|----xxx-1.0.rpm
|----yyy-1.0.rpm
Note
Irrespective of which flag is used and which RPMs are in a destination repo,
all module artifacts are copied. recursive
and recursive_conservative
process differently RPM-to-RPM dependencies only.
Flags recursive
and recursive_conservative
can be used together,
recursive_conservative
takes precedence.
Protected Repositories¶
Red Hat protects its repositories with SSL-based entitlement certificates. Pulp supports both ends of that operation:
Each Pulp repository can be configured with a client entitlement certificate and key that it will use to retrieve packages from a remote repository. This is only required when the remote repository is protected, such as when connecting to the Red Hat CDN.
Pulp can be supplied a CA certificate that it will use to verify the authenticity of client certificates when clients try to access Pulp-hosted repositories. This is only required when you want to protect a Pulp-hosted repository. Repositories can have these protection settings specified individually, or they can be set globally for all RPM-related repositories.
For each Pulp-hosted repository that is protected, a consumer certificate can be supplied that will be distributed to consumers when they bind. That certificate will allow them to access the protected repository.
Package Signatures and GPG Key ID Filtering¶
RPM repositories have limited support for acting on package GPG signatures, including requiring packages to have GPG signatures, and whitelisting signing key IDs to only sync packages with matching signing key IDs. The signing key ID filtering feature uses the 8-character “short” key ID, which does not uniquely identify a GPG signing key. This feature does not verify package signatures.
This signature filtering is granted within the current importer settings and current import of the content, without taking into consideration content already present in the repository.
These features cannot be enable with on_demand or background download policies, since access to the package files is required to get the GPG signature information. Only the immediate download policy is compatible with signature filtering.
Export¶
In addition to publishing repositories as normal yum repositories over HTTP or HTTPS, it is also possible to export repositories to ISO images, which are published over HTTP or HTTPS, or to a directory on the Pulp server. Large repositories may be split into several ISOs.
Proxy Settings¶
When retrieving packages from a remote repository, Pulp can use a proxy and can supply basic authentication credentials to that proxy.
Bandwidth Throttling¶
When downloading packages from a remote source, Pulp can limit the speed at which data is transferred. The number of downloader threads can also be specified.
No Metalink Support¶
Pulp RPM does not support any version of Metalink when syncing. Therefore for repositories that publish Metalink data such as EPEL or Fedora RPM repositories, you cannot use the metalink url as your feed url.
Warning
Pulp is susceptible to a replay attack by either a malicious mirror or from a man-in-the-middle attack (MITM) when TLS is not used. When attacked, Pulp is presented older, legitimate packages. This forces Pulp to not receive package updates from either a malicious mirror or the non-TLS MITM. See this blog post for more details about how Metalink would mitigate this.