Installing Pulp

As we discussed in Chapter 1, Building a Standard Operating Environment on Linux, in this book, there will be times when even though you may have built a standardized operating environment around a given Linux distribution such as Ubuntu Server, you have to create an exception. Pulp is such a case, for although it can manage both .rpm and .deb packages (hence handling repository requirements for a wide variety of Linux distributions), it is only packaged for (and therefore is easiest to install) on CentOS, Fedora, and RHEL-based operating systems. You can still manage your Ubuntu Server estate with Pulp—you just need to install it on CentOS (or your preferred Red Hat variant). 

There are several facets to the Pulp installation. For example, Pulp relies on a MongoDB installation, which may be external if desired. Similarly, it also relies on a message bus, and it is possible to use either RabbitMQ or Qpid as preferred. Most organizations will have their own standards for these things, and so it is left as an exercise to you to define the architecture best suited to your enterprise. In this chapter, we will perform a very simple installation of Pulp on a single server to demonstrate the steps involved. 

Given the relative complexity of installing Pulp, it is recommended that you create an Ansible Playbook for your Pulp installation. However, in this chapter, we will complete the installation manually to demonstrate the work involved—there is no one-size-fits-all Pulp installation:

  1. Before we can begin the installation, we must build a virtual (or physical) server to host our Pulp repositories. For our example, we will base this on CentOS 7.6, which is the latest supported version for Pulp at the time of writing. Also, note the following filesystem requirements:
    • /var/lib/mongodb: We will build our example Pulp server with MongoDB on the same host. The MongoDB database can grow to over 10 GB in size, and it is recommended to mount this path on a dedicated LVM backed filesystem so that it can be easily grown if required, and so that if it ever does fill up, it doesn't halt the rest of the system.
    • /var/lib/pulp: This directory is where the Pulp repositories are housed, and again it should be on a dedicated LVM backed filesystem. The size will be determined by the repositories you wish to create—for example, if you want to mirror a 20 GB upstream repository, then /var/lib/pulp needs to be a minimum of 20 GB in size. This filesystem also must be XFS-based—if created on ext4, you run the risk of running out of inodes.
  2. Once these requirements are met, we must install the EPEL repository as the Pulp install will draw packages from here:
$ sudo yum install epel-release
  1. We then need to install the Pulp repository file:
$ sudo wget -O /etc/yum.repos.d/rhel-pulp.repo https://repos.fedorapeople.org/repos/pulp/pulp/rhel-pulp.repo
  1. Next, we set up the MongoDB server—this must be completed before we proceed with the Pulp installation. It is expected that most enterprises will have some internal standards for the database servers that they will follow—here, we will suffice with a default installation with SSL encryption:
$ sudo yum install mongodb-server
  1. Again, it is fair to say that most enterprises will have their own certificate authority, be it internal or otherwise. For our example server, we will generate a simple self-signed certificate with the following command:
$ sudo openssl req -x509 -nodes -newkey rsa:4096 -keyout /etc/ssl/mongodb-cert.key -out /etc/ssl/mongodb-cert.crt -days 3650 -subj "/C=GB/CN=pulp.example.com"
  1. We then need to concatenate the private key and certificate into one file for MongoDB to pick up:
$ sudo cat /etc/ssl/mongodb-cert.key /etc/ssl/mongodb-cert.crt | sudo tee /etc/ssl/mongodb.pem > /dev/null
  1. With this complete, we must reconfigure MongoDB to pick up the newly created certificate file and enable SSL. Edit the /etc/mongod.conf file and configure the following parameters (any other parameters in the file can be left at their defaults):
# Use ssl on configured ports
sslOnNormalPorts = true

# PEM file for ssl
sslPEMKeyFile = /etc/ssl/mongodb.pem
  1. At this stage, we can now enable the MongoDB service to start on boot and start it:
$ sudo systemctl enable mongod.service
$ sudo systemctl restart mongod.service
  1. With our Mongo database server running, we now need to install the message bus. Again, most enterprises will have corporate standards for this and it is recommended to adhere to these where they are defined. The following example is the minimum required set of steps for a functional demo—it should not be considered fully secured, but it is functional for the sake of testing and evaluating pulp. Here, we simply install the required packages and then enable and start the services:
$ sudo yum install qpid-cpp-server qpid-cpp-server-linearstore
$ sudo systemctl enable qpidd.service
$ sudo systemctl start qpidd.service
  1. With our underlying infrastructure completed, we can now install Pulp itself. The initial steps are to install the base packages:
$ sudo yum install pulp-server python-gofer-qpid python2-qpid qpid-tools

Pulp uses a plugin-based architecture to host the various repositories it is capable of serving. At the time of writing, Pulp is capable of hosting the following:

    • RPM-based repositories (for example, CentOS, RHEL, and Fedora)
    • DEB-based repositories (for example, Debian and Ubuntu)
    • Python modules (for example, for mirroring PyPI content)
    • Puppet manifests
    • Docker images
    • OSTree content

Unfortunately, this chapter does not allow us space to go into all of these modules in detail—however, it is safe to say that, at a high-level, Pulp operates in the same manner across all these different technologies. Whether working with Python modules, Docker images, or RPM packages, you can create a central repository that is stable and can be version controlled to ensure an up-to-date environment can be maintained without losing control of what that environment contains. 

As our use case is Pulp for serving out Linux packages, we will install the RPM- and DEB-based plugins:

$ sudo yum install pulp-deb-plugins pulp-rpm-plugins
  1. With Pulp installed, we must configure the core services. This is performed by editing /etc/pulp/server.conf—most of the default settings are fine for a simple demo such as ours—however, as we enabled SSL support on our MongoDB backend, we must tell the Pulp server we have done this and disable SSL verification as we are using self-signed certificates. The [database] section of the aforementioned file should look like this:
[database]
ssl: true
verify_ssl: false

If you examine this file, you will see there is a great deal of configuration that can be carried out, all of which is well documented with comments. Specifically, you can customize the following sections:

    • [email]: This is off by default but if you want your Pulp server to send email reports, you would configure this here.
    • [database]: We have simply turned on SSL support in this section, but if the database was on an external server or required more advanced parameters, these would be specified here.
    • [messaging]: For communication between different Pulp components, the default Qpid message broker requires no further configuration here, but if you are using RabbitMQ and/or have turned on authentication/SSL support, then that will need to be configured here.
    • [tasks]: Pulp can have separate message brokers for inter-component communication and its asynchronous tasks, and the broker for the latter can be configured here. As we are using the same Qpid instance for both functions, nothing further is required for this example.
    • [server]: This is used to configure the server's default credentials, hostname, and such.
  1. Once the Pulp server is configured, we must generate the RSA key pair and CA certificate for Pulp using the following two commands:
$ sudo pulp-gen-key-pair
$ sudo pulp-gen-ca-certificate
  1. Pulp uses Apache to serve its HTTP(S) content, and so we must configure this. First of all, we initialize the backend database by running the following command (note it is run as the apache user):
$ sudo -u apache pulp-manage-db
  1. If you are intending to use SSL transport with Apache, be sure to configure it to your enterprise requirements. CentOS installs a self-signed certificate for Apache SSL by default, but you may want to replace this with a certificate signed by your Enterprise CA. Also, be sure to disable the insecure SSL protocols—as a minimum, it is recommended to place the following two settings into /etc/httpd/conf.d/ssl.conf:
SSLProtocol all -SSLv2 -SSLv3

SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA

This, of course, is only a guide, and most enterprises will have their own security standards that should be adhered to here.

As new vulnerabilities are discovered, these requirements may change. The preceding configuration is believed to be good practice at the time of writing, but could change at any time without notice. It is up to you to check any and all security-related settings for your environment.
  1. With Apache configured, set it to start on boot and start it up:
$ sudo systemctl enable httpd.service
$ sudo systemctl start httpd.service
  1. Pulp has several other backend services that are required for it to be operational. Each of these can be configured and tuned as required, but again, for the sake of our example server, it is sufficient to enable and start each in turn:
$ sudo systemctl enable pulp_workers.service
$ sudo systemctl start pulp_workers.service

$ sudo systemctl enable pulp_celerybeat.service
$ sudo systemctl start pulp_celerybeat.service

$ sudo systemctl enable pulp_resource_manager.service
$ sudo systemctl start pulp_resource_manager.service
  1. Our final task is to install the administrative components of Pulp so that we can manage our server:
$ sudo yum install pulp-admin-client pulp-rpm-admin-extensions pulp-deb-admin-extensions

  1. There is one final task to complete for our server. Pulp is designed to be administered remotely, and as such, it communicates over SSL to ensure the security of all transactions. Although we have created an all-in-one host and throughout this chapter will perform the server admin from the same host, we need to tell the Pulp admin client that we are using self-signed certificates—otherwise, SSL validation will fail. To do this, edit /etc/pulp/admin/admin.conf, and in the [server] section, define the following parameter:
verify_ssl: False
  1. Finally, we can test that our Pulp server is operational by logging in to it. Although Pulp supports multiple user accounts, and even integration with LDAP backends, a simple installation such as ours comes with one administrator account, where the username and password are both admin.

If all goes well, you should see output similar to the following and be able to query to server status (note that the output has been truncated to save space):

Now that we have a fully operational Pulp server, we shall demonstrate the process of creating repositories for managed stable updates and system builds using our newly built Pulp system.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset