At a high level, the process of managing updates on Ubuntu from our Pulp server is exactly the same as it is for managing the RPM based updates for CentOS (save for the fact that we have no option regarding the use of the Pulp Consumer and must use Ansible for the update process).

There are, however, a couple of limitations when it comes to the use of Pulp with Ubuntu's APT repository system:

• At the time of writing, there is an issue whereby the Pulp sync process does not mirror the signing keys from the upstream Ubuntu repository. This means that even though the upstream repository features Release.gpg, it is not mirrored on the Pulp server. Hopefully, in the future, this will be fixed, but in this chapter, we will work around this by adding implicit trust to the packages.
• HTTPS support on Ubuntu is configured not to accept updates from unverifiable (that is, self-signed) certificates by default. Although we can turn off SSL verification as we did on CentOS, Ubuntu's APT package manager then goes in search of an InRelease file (which should have the aforementioned GPG key embedded). As we discussed in the previous point, the Pulp DEB plugin does not support the signing of mirrored repositories, and so right now, the only workaround for this is to use unencrypted HTTP traffic. Hopefully, in a future release, these two issues will be fixed—however, at the time of writing, there appears to be no documented fix or workaround for them.

With these two limitations understood, we can define our APT sources file for the repository set we created earlier. Following on from the examples in the previous section, our /etc/apt/sources.list file could look like this:

deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-amd64-08aug19 bionic main
deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-security-amd64-08aug19 bionic-security main
deb [trusted=yes] http://pulp.example.com/pulp/deb/bionic-updates-amd64-08aug19 bionic-updates main

The [trusted=yes] string tells the APT package manager to ignore the lack of package signing. The file structure itself is incredibly simple, and so just as with our CentOS example, we can create a template file so that the relative URL can be populated using a variable:

1. First, we'll create a role called pulpconfig and create the following templates/sources.list.j2 template:

deb [trusted=yes] http://pulp.example.com/pulp/deb/{{ ubuntu_os_relurl }} bionic main
deb [trusted=yes] http://pulp.example.com/pulp/deb/{{ ubuntu_security_relurl }} bionic-security main
deb [trusted=yes] http://pulp.example.com/pulp/deb/{{ ubuntu_updates_relurl }} bionic-updates main

2. Then, we will create some tasks with the role to install this template and move aside any old configuration for APT:

---
- name: Create a directory to back up any existing REPO configuration
  file:
    path: /etc/apt/originalconfig
    state: directory

- name: Move existing config into backup directory
  shell: mv /etc/apt/sources.list /etc/apt/originalconfig

- name: Copy across and populate Pulp templated config
  template:
    src: templates/sources.list.j2
    dest: /etc/apt/sources.list
    owner: root
    group: root

- name: Clean out dpkg database
  shell: "apt-get clean"

3. Finally, we will define a role to update the kernel, but this time using APT:

---
- name: Update the kernel
  apt:
    name: linux-generic
    state: latest

4. Our site.yml playbook for Ubuntu systems now looks like this—save for the variable differences, it is almost identical to the CentOS 7 one, once again highlighting the value in using Ansible as an automation platform:

---
- name: Install Pulp repos and update kernel
  hosts: all
  become: yes
  vars:
    ubuntu_os_relurl: "bionic-amd64-08aug19"
    ubuntu_security_relurl: "bionic-security-amd64-08aug19"
    ubuntu_updates_relurl: "bionic-updates-amd64-08aug19"

  roles:
    - pulpconfig
    - updatekernel

5. Now, after putting this all together and running it, we should see output similar to what can be seen in the following screenshot:

Putting aside the security limitations present in the current Pulp Debian support, this provides a neat space-efficient solution for managing Ubuntu updates across an enterprise infrastructure in a manner that is repeatable and lends itself well to automation. As with our earlier CentOS-based example, it would be very easy to test packages from a new snapshot by simply changing the variable definitions passed to our roles.

As with CentOS, should a new package set not be suitable for production use, Ansible makes it easy to restore the previous repository configuration. However, rolling back packages on Ubuntu (and other Debian-based distributions) is a much more manual process than we saw in the previous section. Fortunately, there is a great deal of history regarding package transactions kept in /var/log/dpkg.log and /var/log/apt/history.log*, which can be used to determine which packages were installed and/or upgraded and when. The apt-get command can then be used to install a specific version of a package using the apt-get install <packagename>=<version> syntax. There are many elegant scripted solutions to this problem on the internet, and so it is left as an exercise for you to determine the one best suited to your needs and environment.