Validation With Your Web Server¶

If you are using the repository protection feature and if you do not require different certificate authorities on each repository, it is recommended that you configure your web server to validate client certificates against trusted certificate authorities instead of having Pulp do it. For Apache, please see their documentation if you wish to learn how to do this. You can set the new verify_ssl setting to false in the [main]] section of /etc/pulp/repo_auth.conf if you wish to configure Pulp not to check the certificate signatures. There is a performance advantage to configuring this setting this way if you are able to use your web server to validate client certificates instead of Pulp.

Global Repo Authentication¶

Repository authentication may be configured globally for all repositories in the Pulp server or individually on a per repo basis. In the event that both are specified, only the individual repository authentication check will take place.

Global repository authentication is enabled by placing the authentication credentials under /etc/pki/pulp/content/. The following files are relevant:

pulp-global-repo.ca

CA certificate used to validate inbound consumer certificates. If the consumer’s certificate cannot be validated by this CA, the consumer is automatically rejected as being unauthorized.

pulp-global-repo.cert

Certificate to provide to consumers when they bind to repositories. If a repository overrides global repository authentication at the repository level, the certificate provided for the repository itself is used in place of this file. This file is optional; if unspecified, bound consumers will need to acquire a valid certificate for accessing the repository through other means.

pulp-global-repo.key

If the private key for the consumer certificate above is not included in the certificate itself, it may be located in this file and will be sent to bound consumers at the same time as the certificate.

Individual Repository Authentication¶

Individual repositories can be setup to do SSL authentication. This allows you to use authentication on only specific repositories while leaving others unprotected, or to have different credentials for some repositories than others.

The three certificates listed above can be passed to the repository create or update command using the following options respectively:

• --feed-ca-cert
• --feed-cert
• --feed-key

Searching for Errata¶

Pulp has a very powerful search interface that can be used to search content units. In this recipe, you will learn how to use it to search for errata that have been issued on or after a date, and also how to search for errata by type. Let’s start by defining a repo cleverly called repo with a demo feed:

$ pulp-admin rpm repo create --repo-id=repo \
  --feed=http://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/pulp_unittest/ \
  --relative-url=repo
Successfully created repository [repo]

Now let’s sync the repo so it has some errata for us to search:

$ pulp-admin rpm repo sync run --repo-id=repo

The contents of our example repository are from a few years ago, but it includes errata over a span of a few years. Suppose that I wanted to know which errata were issued on or after December 1, 2009. For this example, I will include the --fields=id flag to limit the output to just be the IDs of the errata, but you can season that flag to taste, or omit it if you want to see everything:

$ pulp-admin rpm repo content errata --filters='{"issued": {"$gte": "2009-12-01"}}' \
  --repo-id=repo --fields=id
Id: RHBA-2010:0010

Id: RHBA-2010:0205

Id: RHBA-2010:0206

Id: RHBA-2010:0222

Id: RHBA-2010:0251

Id: RHBA-2010:0281

Id: RHBA-2010:0282

Id: RHBA-2010:0294

Id: RHBA-2010:0418

We already talked about the --fields=id flag, so let’s focus on the --filters='{"issued": {"$gte": "2009-12-01"}}' flag. pulp-admin has some built in simple filtering capabilities, but they aren’t as powerful as the filtering we can achieve with the --filters flag. We can use this flag to pass a JSON filter to MongoDB to have it apply any arbitrary filter we want. In our case, we want to look for the “issued” field of our errata being greater than or equal to 2009-12-01.

There are three different types of errata: Security Advisories (RHSAs), Bug Fix Advisories (RHBAs), and Product Enhancement Advisories (RHEAs). Suppose we wanted to know which RHSAs were available in a repo. We would run this command:

$ pulp-admin rpm repo content errata --match type=security \
  --repo-id=repo --fields=id
Id: RHSA-2007:0114

Id: RHSA-2007:0323

Id: RHSA-2008:0194

Id: RHSA-2008:0892

Id: RHSA-2009:0003

Id: RHSA-2009:0382

Id: RHSA-2009:1472

For this command we asked Pulp to find errata that had their type field set to “security”. We can also find these by applying a regex to the id field:

$ pulp-admin rpm repo content errata \
  --match id=^RHSA --repo-id=repo

In this example, we asked MongoDB to look for errata that had an id that matched our supplied Regular Expression. The carat at the start of our regular expression will match the beginning of the id field, and we used RHSA after that to make sure the ID was an RHSA and not an RHBA or RHEA.

Copy Errata From One Repository to Another¶

The pulp-admin utility can be used to copy errata from one repository to another. In this recipe, we will create two repositories, sync one with a sample upstream repository, and then copy an erratum from it to the other. Let’s begin by creating our two repositories, repo_1 and repo_2:

$ pulp-admin rpm repo create --repo-id=repo_1 \
  --feed=http://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/pulp_unittest/ \
  --relative-url=repo_1
Successfully created repository [repo_1]

$ pulp-admin rpm repo create --repo-id=repo_2 \
  --relative-url=repo_2
Successfully created repository [repo_2]

Next, we will sync repo_1, so that it will have some errata that we can copy:

$ pulp-admin rpm repo sync run --repo-id=repo_1
+----------------------------------------------------------------------+
Synchronizing Repository [repo_1]
+----------------------------------------------------------------------+

This command may be exited by pressing ctrl+c without affecting the actual
operation on the server.

Downloading metadata...
[|]
... completed

Downloading repository content...
[==================================================] 100%
RPMs:       3/3 items
Delta RPMs: 0/0 items
... completed

Downloading distribution files...
[==================================================] 100%
Distributions: 0/0 items
... completed

Importing errata...
[-]
... completed

Importing package groups/categories...
[-]
... completed

Publishing packages...
[==================================================] 100%
Packages: 3/3 items
... completed

Publishing distributions...
[==================================================] 100%
Distributions: 3/3 items
... completed

Generating metadata
[/]
... completed

Publishing repository over HTTPS
[-]
... completed

Publishing repository over HTTP
[-]
... skipped

Now repo_1 has errata and other units, and repo_2 has no units at all. Suppose that we would like to pull all of the security updates from repo_1 to repo_2. We can determine which errata are RHSA by using a match filter:

$ pulp-admin rpm repo content errata --match type=security \
  --repo-id=repo_1 --fields=id
Id: RHSA-2007:0114

Id: RHSA-2007:0323

Id: RHSA-2008:0194

Id: RHSA-2008:0892

Id: RHSA-2009:0003

Id: RHSA-2009:0382

Id: RHSA-2009:1472

Running that same command for repo_2 doesn’t show any errata, so let’s use the unit copy command to bring these RHSAs over, but not the RHBAs or the RHEAs:

$ pulp-admin rpm repo copy errata --match type=security \
  --from-repo-id=repo_1 --to-repo-id=repo_2
Progress on this task can be viewed using the commands under "repo tasks".

We can inspect the progress of this operation using pulp-admin repo tasks list --repo-id=repo_1. There are only a few errata to be copied here so it should be complete shortly. Now we can inspect the contents of repo_2:

$ pulp-admin rpm repo content errata --repo-id=repo_2 --fields=id
Id: RHSA-2007:0114

Id: RHSA-2007:0323

Id: RHSA-2008:0194

Id: RHSA-2008:0892

Id: RHSA-2009:0003

Id: RHSA-2009:0382

Id: RHSA-2009:1472

Create Your Own Errata¶

You can also create your own errata on a repo using the Pulp client. In order to do this, you will need to create a few CSV files and provide a few data fields to the pulp-admin client.

Let’s begin by making a repo and syncing it:

$ pulp-admin rpm repo create --repo-id=repo \
  --feed=http://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/pulp_unittest/
Successfully created repository [repo]

$ pulp-admin rpm repo sync run --repo-id=repo

Now let’s create a new errata that references one of the test packages from this repo called pulp-test-package. The first file that we will need to provide is a references CSV file. This CSV should have four columns: href, type, id, and description, giving a link to the referenced bug report or CVE, the type of the reference, the ID of the reference, and a brief description. Here is an example, named references.csv, wherein you can see that pulp-test-package-0.2.1 has some serious issues:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123456,bugzilla,123456,pulp-test-package-0.2.1 prints mean error messages to users
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=654321,bugzilla,654321,pulp-test-package-0.2.1 causes users' machines to run out of bits/bytes/whatever. The users must wait until the next supply comes next week

Next, we will need to provide a list of packages that the errata applies to. This CSV provides a list of packages that address the issue that the errata tracks with the following columns: name, version, release, epoch, arch, filename, checksum, checksum_type, and src. For example, let’s create package_list.csv for this:

pulp-test-package,0.3.1,1.fc11,0,x86_64,pulp-test-package-0.3.1-1.fc11.x86_64.rpm,6bce3f26e1fc0fc52ac996f39c0d0e14fc26fb8077081d5b4dbfb6431b08aa9f,sha256,pulp-test-package-0.3.1-1.fc11.src.rpm

Now that we have these two files, we can create our new errata like so:

$ pulp-admin rpm repo uploads erratum --erratum_id=DEMO_ID_1 \
  --title="1: pulp-test-package bit conservation" \
  --description="1: pulp-test-package now conserves your precious bits." \
  --version=1 --release="el6" --type="bugzilla" --status="final" \
  --updated="`date`" --issued="`date`" --reference-csv=references.csv \
  --pkglist-csv=package_list.csv --from=pulp-list@redhat.com --repo-id=repo
+----------------------------------------------------------------------+
                              Unit Upload
+----------------------------------------------------------------------+

Extracting necessary metadata for each request...
... completed

Creating upload requests on the server...
[==================================================] 100%
Initializing upload
... completed

Starting upload of selected units. If this process is stopped through ctrl+c,
the uploads will be paused and may be resumed later using the resume command or
cancelled entirely using the cancel command.

Importing into the repository...
... completed

Deleting the upload request...
... completed

And now we are able to see that our errata is part of the repo:

$ pulp-admin rpm repo content errata --repo-id=repo --match type=bugzilla
Description:      1: pulp-test-package now conserves your precious bits.
From Str:         pulp-list@redhat.com
Id:               DEMO_ID_1
Issued:           Wed Dec 19 12:19:18 EST 2012
Pkglist:
  Name:     el6
  Packages:
    Arch:     x86_64
    Epoch:    0
    Filename: pulp-test-package-0.3.1-1.fc11.x86_64.rpm
    Name:     pulp-test-package
    Release:  1.fc11
    Src:      pulp-test-package-0.3.1-1.fc11.src.rpm
    Sums:     6bce3f26e1fc0fc52ac996f39c0d0e14fc26fb8077081d5b4dbfb6431b08aa9f
    Type:     sha256
    Version:  0.3.1
  Short:
Pushcount:        1
Reboot Suggested: False
References:
  Href:  http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=123456
  Id:    123456
  Title: pulp-test-package-0.2.1 prints mean error messages to users
  Type:  bugzilla
  Href:  http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=654321
  Id:    654321
  Title: pulp-test-package-0.2.1 causes users' machines to run out of
         bits/bytes/whatever. The users must wait until the next supply comes
         next week
  Type:  bugzilla
Release:          el6
Rights:           None
Severity:         None
Solution:         None
Status:           final
Summary:          None
Title:            1: pulp-test-package bit conservation
Type:             bugzilla
Updated:          Wed Dec 19 12:19:18 EST 2012
Version:          1

Create Your Own Package Groups¶

You can easily define your own package groups with the pulp_admin utility. Let’s create and sync a repo:

$ pulp-admin rpm repo create --repo-id=repo_1 \
  --feed=http://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/pulp_unittest/
Successfully created repository [repo_1]

$ pulp-admin rpm repo sync run --repo-id=repo_1

Now let’s build a package group for our demo repo test files:

$ pulp-admin rpm repo uploads group --repo-id=repo_1 --group-id=pulp_test \
  --name="Pulp Test" --description="A package group of Pulp test files." \
  --mand-name=pulp-dot-2.0-test --mand-name=pulp-test-package
+----------------------------------------------------------------------+
                              Unit Upload
+----------------------------------------------------------------------+

Extracting necessary metadata for each request...
... completed

Creating upload requests on the server...
[==================================================] 100%
Initializing upload
... completed

Starting upload of selected units. If this process is stopped through ctrl+c,
the uploads will be paused and may be resumed later using the resume command or
cancelled entirely using the cancel command.

Importing into the repository...
... completed

Deleting the upload request...
... completed

We can see that the package group is now part of our repo:

$ pulp-admin rpm repo content group --repo-id=repo_1 --match id=pulp_test
Conditional Package Names:
Default:                   False
Default Package Names:     None
Description:               A package group of Pulp test files.
Display Order:             0
Id:                        pulp_test
Langonly:                  None
Mandatory Package Names:   pulp-dot-2.0-test, pulp-test-package
Name:                      Pulp Test
Optional Package Names:    None
Repo Id:                   repo_1
Translated Description:
Translated Name:
User Visible:              False

Copying Package Groups Between Repos¶

Package groups can be copied from one repository to another, which will bring along the packages it references as well. For this example, we will assume you’ve performed the steps from the Create Your Own Package Groups section.

We’ll begin by creating a new empty repo, repo_2:

$ pulp-admin rpm repo create --repo-id=repo_2
Successfully created repository [repo_2]

And now we will copy our package group, pulp_test from repo_1 to repo_2:

$ pulp-admin rpm repo copy group --match id=pulp_test --from-repo-id=repo_1 \
  --to-repo-id=repo_2
Progress on this task can be viewed using the commands under "repo tasks".

This task should complete fairly quickly since there isn’t much to do with our tiny example repo, but we can check on the progress to verify that it is finished:

$ pulp-admin repo tasks list --repo-id=repo_1
+----------------------------------------------------------------------+
                                 Tasks
+----------------------------------------------------------------------+

Operations:  associate
Resources:   repo_2 (repository), repo_1 (repository)
State:       Successful
Start Time:  2012-12-20T16:26:44Z
Finish Time: 2012-12-20T16:26:44Z
Result:      N/A
Task Id:     9f1d0146-cc28-47a8-b0f4-b1b49f84e058

Now we can inspect repo_2 and see that the package group and its RPMs have been copied there:

$ pulp-admin rpm repo content group --repo-id=repo_2
Conditional Package Names:
Default:                   False
Default Package Names:     None
Description:               A package group of Pulp test files.
Display Order:             0
Id:                        pulp_test
Langonly:                  None
Mandatory Package Names:   pulp-dot-2.0-test, pulp-test-package
Name:                      Pulp Test
Optional Package Names:    None
Repo Id:                   repo_1
Translated Description:
Translated Name:
User Visible:              False

$ pulp-admin rpm repo content rpm --repo-id=repo_2
Arch:         x86_64
Buildhost:    gibson
Checksum:     435d92e6c09248b501b8d2ae786f92ccfad69fab8b1bc774e2b66ff6c0d83979
Checksumtype: sha256
Description:  Test package to see how we deal with packages with dots in the
              name
Epoch:        0
Filename:     pulp-dot-2.0-test-0.1.2-1.fc11.x86_64.rpm
License:      MIT
Name:         pulp-dot-2.0-test
Provides:     [[u'pulp-dot-2.0-test(x86-64)', u'EQ', [u'0', u'0.1.2',
              u'1.fc11']], [u'pulp-dot-2.0-test', u'EQ', [u'0', u'0.1.2',
              u'1.fc11']], [u'config(pulp-dot-2.0-test)', u'EQ', [u'0',
              u'0.1.2', u'1.fc11']]]
Release:      1.fc11
Requires:
Vendor:
Version:      0.1.2

Arch:         x86_64
Buildhost:    gibson
Checksum:     6bce3f26e1fc0fc52ac996f39c0d0e14fc26fb8077081d5b4dbfb6431b08aa9f
Checksumtype: sha256
Description:  Test package.  Nothing to see here.
Epoch:        0
Filename:     pulp-test-package-0.3.1-1.fc11.x86_64.rpm
License:      MIT
Name:         pulp-test-package
Provides:     [[u'pulp-test-package(x86-64)', u'EQ', [u'0', u'0.3.1',
              u'1.fc11']], [u'pulp-test-package', u'EQ', [u'0', u'0.3.1',
              u'1.fc11']], [u'config(pulp-test-package)', u'EQ', [u'0',
              u'0.3.1', u'1.fc11']]]
Release:      1.fc11
Requires:
Vendor:
Version:      0.3.1

Create Your Own Package Categories¶

You can also define your own package categories with the pulp_admin utility. Let’s create and sync a repo:

$ pulp-admin rpm repo create --repo-id=repo_1 \
  --feed=http://repos.fedorapeople.org/repos/pulp/pulp/demo_repos/pulp_unittest/
Successfully created repository [repo_1]

$ pulp-admin rpm repo sync run --repo-id=repo_1

Now let’s build two package groups for our demo repo test files:

$ pulp-admin rpm repo uploads group --repo-id=repo_1 \
  --group-id=pulp_test_packages --name="Pulp Test Packages" \
  --description="A package group of Pulp test files." \
  --mand-name=pulp-dot-2.0-test --mand-name=pulp-test-package

$ pulp-admin rpm repo uploads group --repo-id=repo_1 \
  --group-id=pulp_dotted_name_packages --name="Pulp Dotted Name Packages" \
  --description="A group of packages that have dots in their names." \
  --mand-name=pulp-dot-2.0-test

And now we can easily create a package category that is a collection of these two groups:

$ pulp-admin rpm repo uploads category --repo-id=repo_1 \
  --category-id=example_category --name="Example Category" \
  --description="An Example Category" --group=pulp_test_packages \
  --group=pulp_dotted_name_packages
+----------------------------------------------------------------------+
                              Unit Upload
+----------------------------------------------------------------------+

Extracting necessary metadata for each request...
... completed

Creating upload requests on the server...
[==================================================] 100%
Initializing upload
... completed

Starting upload of selected units. If this process is stopped through ctrl+c,
the uploads will be paused and may be resumed later using the resume command or
cancelled entirely using the cancel command.

Importing into the repository...
... completed

Deleting the upload request...
... completed

The package category details can be listed as well:

$ pulp-admin rpm repo content category --repo-id=repo_1 \
  --match id=example_category
Description:            An Example Category
Display Order:          0
Id:                     example_category
Name:                   Example Category
Packagegroupids:        pulp_test_packages, pulp_dotted_name_packages
Repo Id:                repo_1
Translated Description:
Translated Name:

Copying Package Categories¶

Like package groups, categories can be copied between repos, which will bring along their groups and packages. Assuming you’ve performed the steps from the Create Your Own Package Categories section, let’s begin by creating an empty second repo:

$ pulp-admin rpm repo create --repo-id=repo_2
Successfully created repository [repo_2]

Now let’s copy example_category from repo_1 to repo_2:

$ pulp-admin rpm repo copy category --match id=example_category \
  --from-repo-id=repo_1 --to-repo-id=repo_2
Progress on this task can be viewed using the commands under "repo tasks".

We should check out the task to see when it’s done with the repo tasks command:

$ pulp-admin repo tasks list --repo-id=repo_1
+----------------------------------------------------------------------+
                                 Tasks
+----------------------------------------------------------------------+

Operations:  associate
Resources:   repo_2 (repository), repo_1 (repository)
State:       Successful
Start Time:  2012-12-20T20:41:12Z
Finish Time: 2012-12-20T20:41:12Z
Result:      N/A
Task Id:     b5139389-b985-40be-8ee5-10bc626a124a

And now we can see that repo_2 has the category, groups, and RPMs:

$ pulp-admin rpm repo content category --repo-id=repo_2
Description:            An Example Category
Display Order:          0
Id:                     example_category
Name:                   Example Category
Packagegroupids:        pulp_test_packages, pulp_dotted_name_packages
Repo Id:                repo_1
Translated Description:
Translated Name:

$ pulp-admin rpm repo content group --repo-id=repo_2
Conditional Package Names:
Default:                   False
Default Package Names:     None
Description:               A group of packages that have dots in their names.
Display Order:             0
Id:                        pulp_dotted_name_packages
Langonly:                  None
Mandatory Package Names:   pulp-dot-2.0-test
Name:                      Pulp Dotted Name Packages
Optional Package Names:    None
Repo Id:                   repo_1
Translated Description:
Translated Name:
User Visible:              False

Conditional Package Names:
Default:                   False
Default Package Names:     None
Description:               A package group of Pulp test files.
Display Order:             0
Id:                        pulp_test_packages
Langonly:                  None
Mandatory Package Names:   pulp-dot-2.0-test, pulp-test-package
Name:                      Pulp Test Packages
Optional Package Names:    None
Repo Id:                   repo_1
Translated Description:
Translated Name:
User Visible:              False

$ pulp-admin rpm repo content rpm --repo-id=repo_2
Arch:         x86_64
Buildhost:    gibson
Checksum:     435d92e6c09248b501b8d2ae786f92ccfad69fab8b1bc774e2b66ff6c0d83979
Checksumtype: sha256
Description:  Test package to see how we deal with packages with dots in the
              name
Epoch:        0
Filename:     pulp-dot-2.0-test-0.1.2-1.fc11.x86_64.rpm
License:      MIT
Name:         pulp-dot-2.0-test
Provides:     [[u'pulp-dot-2.0-test(x86-64)', u'EQ', [u'0', u'0.1.2',
              u'1.fc11']], [u'pulp-dot-2.0-test', u'EQ', [u'0', u'0.1.2',
              u'1.fc11']], [u'config(pulp-dot-2.0-test)', u'EQ', [u'0',
              u'0.1.2', u'1.fc11']]]
Release:      1.fc11
Requires:
Vendor:
Version:      0.1.2

Arch:         x86_64
Buildhost:    gibson
Checksum:     6bce3f26e1fc0fc52ac996f39c0d0e14fc26fb8077081d5b4dbfb6431b08aa9f
Checksumtype: sha256
Description:  Test package.  Nothing to see here.
Epoch:        0
Filename:     pulp-test-package-0.3.1-1.fc11.x86_64.rpm
License:      MIT
Name:         pulp-test-package
Provides:     [[u'pulp-test-package(x86-64)', u'EQ', [u'0', u'0.3.1',
              u'1.fc11']], [u'pulp-test-package', u'EQ', [u'0', u'0.3.1',
              u'1.fc11']], [u'config(pulp-test-package)', u'EQ', [u'0',
              u'0.3.1', u'1.fc11']]]
Release:      1.fc11
Requires:
Vendor:
Version:      0.3.1

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.

Syncing an ISO Repository¶

In this recipe, we will create an ISO repository with an upstream feed, and we will synchronize it.

Let’s begin by creating the repository:

$ pulp-admin iso repo create --repo-id example --feed http://pkilambi.fedorapeople.org/test_file_repo/ --serve-http true
Successfully created repository [example]

In this command, we’ve created an ISO repository that syncs with the given feed URL, and we’ve also instructed it to publish over HTTP.

Now that we’ve created the repository, let’s sync it as well:

$ pulp-admin iso repo sync run --repo-id example
+----------------------------------------------------------------------+
                   Synchronizing Repository [example]
+----------------------------------------------------------------------+

This command may be exited by pressing ctrl+c without affecting the actual
operation on the server.

Downloading the Pulp Manifest...
The Pulp Manifest was downloaded successfully.

Downloading 3 ISOs...
[==================================================] 100%
ISOs: 3/3   Data: 10.2 MB/10.2 MB   Avg: 1.7 MB/s


Successfully downloaded 3 ISOs.

The repository was successfully published.

ISO repositories auto-publish by default, so you can now browse to http://<your-server>/pulp/isos/example/ and view the downloaded ISOs.

Uploading ISOs to a Repository¶

You can also upload your own ISOs to a repository. Let’s begin by creating a repository:

$ pulp-admin iso repo create --repo-id uploads --serve-http true
Successfully created repository [uploads]

We didn’t give this one a feed, but we still instructed it to publish over HTTP. Let’s upload a file:

$ pulp-admin iso repo uploads upload --repo-id uploads -f ~/Desktop/Fedora-17-x86_64-Live-Desktop.iso
+----------------------------------------------------------------------+
                              Unit Upload
+----------------------------------------------------------------------+

Extracting necessary metadata for each request...
[==================================================] 100%
Analyzing: Fedora-17-x86_64-Live-Desktop.iso
... completed

Creating upload requests on the server...
[==================================================] 100%
Initializing: Fedora-17-x86_64-Live-Desktop.iso
... completed

Starting upload of selected units. If this process is stopped through ctrl+c,
the uploads will be paused and may be resumed later using the resume command or
cancelled entirely using the cancel command.

Uploading: Fedora-17-x86_64-Live-Desktop.iso
[==================================================] 100%
676331520/676331520 bytes
... completed

Importing into the repository...
... completed

Deleting the upload request...
... completed

In this example, we uploaded the Fedora 17 ISO from our Desktop. We have not published the repository, and Pulp repositories do not auto publish after uploads, so let’s now publish the repository:

$ pulp-admin iso repo publish run --repo-id uploads
+----------------------------------------------------------------------+
                    Publishing Repository [uploads]
+----------------------------------------------------------------------+

This command may be exited by pressing ctrl+c without affecting the actual
operation on the server.

The repository was successfully published.

You can now browse to http://<your-server>/pulp/isos/uploads/ and view the ISO you’ve uploaded, as well as the generated PULP_MANIFEST file.

RPM¶

The RPM’s ID is rpm.

SRPM¶

The SRPM’s ID is srpm.

DRPM¶

The DRPM’s ID is drpm.

Errata¶

The Erratum’s ID is erratum.

Distribution¶

The distribution type’s ID is distribution.

Package Group¶

The Package Group’s ID is package_group.

Package Group Category¶

The Package Group Category’s ID is package_category.

Package Group Environment¶

The Package Group Environment’s ID is package_environment.

Yum Repo Metadata File¶

The Yum Repo Metadata File’s ID is yum_repo_metadata_file.

Configuration Parameters¶

The following options are available to the yum importer configuration. All configuration values are optional.

feed

URL where the repository’s content will be synchronized from. This can be either an HTTP URL or a location on disk represented as a file URL.

ssl_validation

Indicates if the server’s SSL certificate is verified against the CA certificate uploaded. The certificate should be verified against the CA for each client request. Has no effect for non-SSL feeds. Valid values to this option are True and False; defaults to True.

ssl_ca_cert

CA certificate string used to validate the feed source’s SSL certificate (for feeds exposed over HTTPS). This option is ignored if ssl_verify is false.

ssl_client_cert

Certificate used as the client certificate when synchronizing the repository. This is used to communicate authentication information to the feed source. The value to this option must be the full path to the certificate. The specified file may be the certificate itself or a single file containing both the certificate and private key.

ssl_client_key

Private key to the certificate specified in ssl_client_cert, assuming it is not included in the certificate file itself.

proxy_host

Indicates the URL to use as a proxy server when synchronizing this repository.

proxy_port

Port to connect to on the proxy server.

proxy_username

Username to pass to the proxy server if it requires authentication.

proxy_password

Password to use for proxy server authentication.

max_speed

The maximum download speed in bytes/sec for a task (such as a sync); defaults to None

validate

If True, as the repository is synchronized the checksum of each file will be verified against the metadata’s expectation. Valid values to this option are True and False; defaults to False.

max_downloads

Number of threads used when synchronizing the repository. This count controls the download threads themselves and has no bearing on the number of operations the Pulp server can execute at a given time; defaults to 1.

remove_missing

If true, as the repository is synchronized, old rpms will be removed. Valid values to this option are True and False; defaults to False

retain_old_count

Count indicating how many old rpm versions to retain; defaults to 0. This count only takes effect when remove_old option is set to True.

purge_orphaned

If True, as the repository is synchronized, packages no longer available from the source repository will be deleted; defaults to True.

skip

List of content types to be skipped during the repository synchronization. If unspecified, all types will be synchronized. Valid values are: rpm, drpm, distribution, errata, packagegroup; default is [].

checksum_type

checksum type to use for metadata generation; defaults to source checksum type of sha256.

num_retries

Number of times to retry before declaring an error during repository synchronization; defaults to 2.

copy_children

Supported only as an override config option to a repository copy command, when this option is False, the copy command will not attempt to locate and copy child packages of errata, groups, or categories. For example, if it is already known that all of a group’s RPMs are available in the destination repository, it can save substantial time to set this to False and thus not have the importer verify the presence of each. default is True.

Configuration Parameters¶

The following options are available to the Yum Distributor configuration.

Required Configuration Parameters¶

http

Flag indicating if the generated ISO will be served over a non-SSL connection. Valid values to this option are True and False. This option is required.

https

Flag indicating if the generated ISO will be served over an SSL connection. Valid values to this option are True and False. This option is required.

Optional Configuration Parameters¶

start_date

Any content that was associated with the repository before this date will be excluded in the generated ISO. Furthermore, the incremental export process exports errata and rpm metadata as JSON documents, and no repo metadata is generated. The date should be in standard ISO8601 format. For example, “2010-01-01T12:00:00”.

end_date

Any content that was associated with the repository after this date will be excluded in the generated ISO. Furthermore, the incremental export process exports errata and rpm metadata as JSON documents, and no repo metadata is generated. The date should be in standard ISO8601 format. For example, “2010-01-01T12:00:00”.

iso_prefix

Prefix to be used in naming the generated ISO. The ISO will be named like this: <prefix>-<timestamp>-<disc_number>.iso. The default is the repository or group id. The prefix should only contain alphanumeric characters, dashes, and underscores.

skip

List of content types to skip during the creation of the ISO. If unspecified, all types will be published. Valid values are: rpm, drpm, srpm, distribution, package_group, and erratum.

iso_size

An integer, which is the maximum size of the generated ISO images in megabytes. In this case, 1 megabyte is 1 * 1024 * 1024 bytes. This will default to 4380 megabytes (4380 * 1024 * 1024 bytes, to be exact) if it is not specified, which should fit on a single layer DVD.

export_dir

A full path to an export directory. If this option is specified, the repositories are not placed in ISO images and published over HTTP or HTTPS. Instead, they are written to the export directory. This option is useful if exporting to an external hard drive, for example.

Unit Key¶

The unit key for the ISO type is an ordered list of name, checksum, and size. Each of these attributes is described below.

name

This is the filename of the ISO.

checksum

This is the SHA-256 checksum of the ISO file.

size

This is the size in bytes of the ISO file.

Metadata¶

ISOs have no additional metadata outside of the unit key.

Configuration Parameters¶

The following configuration parameters are all optional, and can be used to determine the behavior of the ISO importer.

feed

This should be a string that represents the URL to an upstream ISO repository that you would like this importer to be able to synchronize with. This parameter is optional because it is valid to create an ISO importer that does not synchronize with an upstream feed, but is rather used to contain uploaded ISOs, or ISOs that are copied from other repositories. This parameter becomes required if any of the other parameters are provided.

max_speed

This should be a numerical value, or a string that can be interpreted as a numerical value, representing the maximum speed that the importer should be allowed to transfer ISOs at when synchronizing with feed. It should be specified in units of bytes per second.

max_downloads

This should be an integer, or a string that can be interpreted as an integer, representing the maximum number of concurrent downloads that should be performed when synchronizing with feed. This parameter defaults to 5.

proxy_password

A string representing the password that should be used to authenticate with the proxy server specified in proxy_host. This parameter is required if the proxy_username is provided.

proxy_port

An integer, or a string that can be interpreted as an integer, representing the port that should be used when connecting to proxy_host.

proxy_host

A string representing the URL of the proxy server that should be used when synchronizing with feed. This parameter is required if any of the other proxy setting are provided.

proxy_username

A string representing the username that should be used to authenticate with the proxy server at proxy_host. This parameter is required if the proxy_password is provided.

remove_missing

This is a boolean value, or a string “True” or “False”. If set to “True”, the importer will remove any ISOs that are currently in the local Pulp repository that are not found in the manifest at feed. If “False”, missing ISOs will not be removed. This parameter defaults to False.

ssl_ca_cert

This is a string representing the SSL certificate authority certificate that should be used to validate the server responding at feed. It should be provided in PEM format.

ssl_client_cert

This is a string representing the SSL client certificate that should be used to authenticate the importer to the upstream repository at feed. It should be provided in PEM format. This parameter is required if the ssl_client_key is provided.

ssl_client_key

This is a string representing the private key for ssl_client_cert. It should be provided in PEM format.

ssl_validation

This is a boolean that indicates whether we should verify the remote feed against the given ssl_ca_cert.

validate

This is a boolean value, or a string “True” or “False”. If set to “True”, the importer will check the downloaded ISOs’ file sizes and checksums against the expected values in the manifest when downloading from feed. If “False”, no validation will be performed. This parameter defaults to True.

Configuration Parameters¶

The following configuration parameters can be used to determine the behavior of the ISO Distributor. Both configuration parameters are required.

serve_http

This is a boolean value, or a string “True” or “False”. If set to True, the distributor will publish the ISO repository over plain HTTP, port 80. If False, it will not be published over plain HTTP.

serve_https

This is a boolean value, or a string “True” or “False”. If set to True, the distributor will publish the ISO repository over SSL protected HTTP, port 443. If False, it will not be published over HTTPS.

ssl_auth_ca_cert

If the distributor is configured with an authorization CA certificate and the repository protection WSGI app is enabled, the distributed repository will become a protected repository. The given CA certificate will be used to verify the clients’ entitlement certificates. If this certificate is not provided, the repository will be an unprotected repository.

Calculation¶

In order to use simple string sorting in the database, the original values for version and release are encoded for their sort index values. The encoding algorithm is as follows:

• Each version is split apart by periods. We’ll refer to each piece as a segment.
• If a segment only consists of numbers, it’s transformed into the format dd-num, where:
  • dd - number of digits in the value, including leading zeroes if necessary
  • num - value of the int being encoded
• If a segment contains one or more letters, it is:

• Split into multiple segments of continuous letters or numbers. For example, 12a3bc becomes 12.a.3.bc
• All of these number-only subsegments is encoded according to the rules above.
• All letter subsegments are prefixed with a dollar sign ($).
• Any non-alphanumeric characters are discarded.

Examples:

• 3.9    -> 01-3.01-9
• 3.10   -> 01-3.02-10
• 5.256  -> 01-5.03-256
• 1.1a   -> 01-1.01-1.$a
• 1.a+   -> 01-1.$a
• 12a3bc -> 02-12.$a.01-3.$bc
• 2xFg33.+f.5 -> 01-2.$xFg.02-33.$f.01-5