Although there are some subtle differences in the command-line structure between the RPM repository plugin for Pulp and the DEB one, the overall process is the same. As before, some prior knowledge is also required of the repository structure to create an effective mirror. In this book, we have worked with Ubuntu Server 18.04 LTS as an example, and the default repository set that is configured on this is as follows:

• bionic: This is the baseline repository for the release of Ubuntu Server 18.04 (codename Bionic Beaver), and as with the OS repository for CentOS 7, does not change following the release of the operating system
• bionic-security: These are security-specific updates for the bionic operating system built post-release
• bionic-updates: These are non-security updates for the bionic operating system release

There are other repositories too, such as backports, and in addition to the main component (which we will concern ourselves with here), there is a wide array of packages available in the restricted, universe, and multiverse components. Going into greater detail about the Ubuntu repository structure is beyond the scope of this book, but suffice to say there is a wide array of documentation available on this subject. The following link is a good place to start reading about the different Ubuntu repositories you may wish to mirror: https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories_and_Updates.

For now, let's suppose we are updating a minimal build of Ubuntu Server 18.04 LTS. For this, we are only interested in packages in the main component, but we do need a snapshot of all the security fixes and updates at a given point in time, just like one we had for our CentOS 7 build:

1. First of all, having ensured we are logged in to the pulp-admin client as before, we will create a repository in Pulp for the main component and the operating system release packages:

$ pulp-admin deb repo create --repo-id='bionic-amd64-08aug19' --relative-url='bionic-amd64-08aug19' --feed='http://de.archive.ubuntu.com/ubuntu' --releases=bionic --components=main --architectures='amd64' --serve-http=true

As you can see, the preceding command is very similar to our RPM repository creation command. We specify repo-id and relative-url in the same manner as before and specify an upstream feed URL. This time, though, we are specifying the Ubuntu releases, components, and architectures as command-line options whereas, in our CentOS 7 example, these were implicit in the URL we mirrored. In addition to these DEB-specific configuration parameters, we are now also specifying the --serve-http option. By default, Pulp serves all repository content over HTTPS only. However, owing to some limitations around package signing for DEB packages in Pulp, which will be discussed later in this chapter, we must enable the serving of repository content over plain HTTP.

Having done this, we will create two more repositories for the security and updates repositories:

$ pulp-admin deb repo create --repo-id='bionic-security-amd64-08aug19' --relative-url='bionic-security-amd64-08aug19' --feed='http://de.archive.ubuntu.com/ubuntu' --releases=bionic-security --components=main --architectures='amd64' --serve-http=true

$ pulp-admin deb repo create --repo-id='bionic-updates-amd64-08aug19' --relative-url='bionic-updates-amd64-08aug19' --feed='http://de.archive.ubuntu.com/ubuntu' --releases=bionic-updates --components=main --architectures='amd64' --serve-http=true

2. With our repository creation completed, we can run our sync processes, just like we did previously:

$ pulp-admin deb repo sync run --repo-id='bionic-amd64-08aug19'

$ pulp-admin deb repo sync run --repo-id='bionic-security-amd64-08aug19'

$ pulp-admin deb repo sync run --repo-id='bionic-updates-amd64-08aug19'

3. Finally, we publish the repositories:

$ pulp-admin deb repo publish run --repo-id='bionic-amd64-08aug19'

$ pulp-admin deb repo publish run --repo-id='bionic-security-amd64-08aug19'

$ pulp-admin deb repo publish run --repo-id='bionic-updates-amd64-08aug19'

It is worth noting that Ubuntu repositories tend to be much larger than their CentOS counterparts, especially the updates and security ones. During the sync process, the packages are downloaded into /var/cache/pulp temporarily before they are archived into the /var/lib/pulp directory. If /var/cache/pulp is on your root filesystem, there is a significant danger of your root filesystem filling up, and as such, it may be best to create a new volume for this purpose and mount at /var/cache/pulp to prevent a disk full situation from stopping your Pulp server.

The DEB plugin for Pulp features the same package deduplication as its RPM counterpart and publishes packages over HTTPS (and optionally HTTP) in the same manner. With a few changes to the syntax of the commands, we can effectively create snapshots of upstream Linux repositories for most of the major distributions that are found in enterprise environments.

As a result of completing this section, you have learned how to create your own repository mirrors for both RPM- and DEB-based content in Pulp, which may be treated as stable and unchanging and hence provide an excellent basis for patch management in an enterprise.

In the next section of this chapter, we will look at how to deploy these repositories to two different types of Linux server.