## Pulp First Impressions

### Prelude

Today I had a task to get crowd integrated with Subversion for authentication and authorization. This was not a huge hurdle, Atlassian provides an RPM for their crowd apache connector and the setup was straight-forward. They do not at this time provide an RPM repository (or my half hearted search didn't turn up anything).

I don't like doing one off installations any more. I would much rather use puppet to perform installation and management. The path of least resistance would be to use the rpm provider to install and manage the RPM. But, long term, I would much rather have an internal repository

### Enter Pulp

There are many ways to accomplish setting up an RPM repo, but Pulp seems to be the way that RHEL is moving.

### First impressions

Because this is the first time I've used Pulp, some initial impressions. Keep in mind, this is with pretty much zero actual usage of the software.

• Installation is easy
• The documentation about which RPMs to install is a little off
• Holy hell, it uses an AMPQ messaging engine
• Aaaand, there seems to be an agent to install on "consumers"

As an aside, I'm getting annoyed with agents on servers. I understand why they are needed, enjoy the benefits, but hate the sprawl. Typical servers can have agents for:

• monitoring
• backup
• puppet
• mcollective
• file integrity monitoring (tripwire, etc..)
• package management?

### First repository

Getting RHEL added into Pulp was easy, which I wasn't expecting considering you have to go through a server subscription process. I followed the instructions here.

subscription-manager register
subscription-manager refresh
subscription-manager subscribe --auto

pulp-admin rpm repo create --id=rhel-6-server \
--feed=https://cdn.redhat.com/content/dist/rhel/server/6/6Server/x86_64/os \
--feed_ca=/etc/rhsm/ca/redhat-uep.pem \
--feed_key=/etc/pki/entitlement/longnumber-key.pem \
--feed_cert=/etc/pki/entitlement/longnumber.pem \

pulp-admin rpm repo sync run --repo-id=rhel-6-server


And it started syncing… slowly. For the future, doing something like this seems to increase the download workers.

pulp-admin rpm repo update --num-threads=50 --repo-id=rhel-6-server


### Private repository

Getting RHEL to sync is nice, but what I need for my crowd project is a private repo where I can throw the RPM.

pulp-admin rpm repo create --repo-id=customrepo


### Ignoring the client.. for now

The client and back end messaging engine look really great, despite what I said earlier. But I want to get a good feel for pulp before deploying an agent to all my machines. First I tried just adding the repo to /etc/yum.repos.d:

[root@testserver yum.repos.d]# cat private.repo
[customrepo]
name=Custom Repository
baseurl=https://pulp.private.lan/pulp/repos/customrepo
enabled=1
gpgcheck=0
[root@testserver yum.repos.d]#


But that complained with an error about certificates. My initial guess is the server wants the pulp agent to register with it.

[Errno 14] Peer cert cannot be verified or peer cert invalid Trying other mirror.


My work around was simply to remove the https requirement from the repo.

pulp-admin rpm repo update --repo-id=customrepo --serve-http=true pulp-admin rpm repo publish run --repo-id=customrepo


Switched the repo on the server to http and it's able to communicate and pull the RPM I uploaded.

### Things left to do

That gets me to the point of working on the puppet module for crowd, but pulp is a much larger project than I expected so I have more to do.

• Determine if the certificate error is due to requiring the agent
• Explore the features of the pulp agent to see if it's worth pursuing
• Add the RHEL repository I created to a test machine and play with using it instead of Red Hat
• Setup automatic syncing of repositories
• Switch back to SSL
• Add the Red Hat "optional" channel as synchronized repositories
• Play with adding a puppet module repository and figure out how that impacts my current version controlled release pattern

More I'm sure, but that's a good start.