Task #3065

Replace the vagrant user with a user named 'pulp'

Added by daviddavis over 3 years ago. Updated over 1 year ago.

Start date:
Due date:
% Done:


Estimated time:
Platform Release:
Sprint Candidate:


We currently use a vagrant user that owns files (e.g. /var/lib/pulp) and run processes (e.g. pulp_workers), etc. We'd like to rename this vagrant user to pulp to be consistent with ansible installs.


Related issues

Related to Pulp - Issue #3050: get rid of "apache" user in dev environmentCLOSED - CURRENTRELEASE<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>


#1 Updated by daviddavis over 3 years ago

  • Related to Issue #3050: get rid of "apache" user in dev environment added

#2 Updated by over 3 years ago

When I type "vagrant ssh", will that log into the vm as the "pulp" user?

I think that we should not hardcode the username, but rather continue to do this:

#3 Updated by daviddavis over 3 years ago

Yea, the plan is that when you run "vagrant ssh", you'll ssh in as a user named pulp.

We set pulp_user here:

I think that will be the place we'll need to change to "pulp".

#4 Updated by daviddavis over 3 years ago

  • Description updated (diff)

#5 Updated by over 3 years ago

  • Tracker changed from Issue to Task
  • % Done set to 0

#6 Updated by Ichimonji10 over 3 years ago

I love the idea of not hardcoding a username into our installers, but rather letting Pulp be run as any arbitrary user. It's certainly a more technically correct way of approaching the problem of "how do I run a daemon?" And given that Pulp 3 is designed so that it can be installed into an arbitrary virtualenv, it seems like an especially important consideration to keep in mind. In practical terms, this is easy to do. We're using Ansible to install Pulp 3, and if our Ansible code is well written, it should be able to handle this without any issues at all.

This design decision highlights an important design point that, as far as I can tell, still hasn't been resolved: where is the boundary between Pulp and the outside world? In other words, at what point is data handed to a process owned by the "pulp" or "vagrant" user? This may not be the best place to bring up this discussion. Feel free to point me elsewhere. Rabbit trail alert.

I've seen one proposed solution so far. The solution is for a webserver (apache/nginx/lighttpd/etc) to run as the Pulp 3 user ("pulp", "vagrant", etc), where a (WSGI) process runs inside the webserver's memory space, and where that process is responsible for receiving requests and placing them in the celery queue for other Pulp processes to pick up.

I hope we can avoid this solution. It makes me go cock-eyed when I realize that the system-wide webserver that runs on standard ports like 80/443 won't be running as a standard user. There's a couple reasons for this:

  • This is a highly unusual set-up. If I was hunting for a piece of file distribution software, and I was reading through Pulp's docs and thinking about whether to use it, that piece of information would make me immediately say "that's a ridiculous design." I'd move on to the next candidate.
  • There may be file ownership issues that might now need to be addressed. For example, on my system, nginx owns files like /etc/nginx/..., /etc/logrotate.d/nginx, /usr/bin/nginx, /var/lib/nginx/proxy/, /var/log/nginx/, etc. Do I now need to change the ownership of all those files/dirs/etc? Once I do that, upgrades become a nightmare. A package manager typically knows who owns those files. Will the package manager leave ownership alone when upgrading the system?
  • This may break security policies, like SELinux security policies.
  • This design prevents the web server from easily being used for other applications. What if I want my web server to serve another web application too, or another static website? As a sysadmin, I will be wondering if installing Pulp 3 will break other applications, due to the strange-ness of this set-up.

A much more typical set-up could look like this:

client → reverse proxy → HTTP server → celery queue

In this case, the boundary between the outside world and Pulp 3 processes lies between the reverse proxy and the HTTP server. The reverse proxy can be any arbitrary application that's sufficiently capable, such as Apache, Nginx or LightTPD. That application can be installed as normal and run as the user that users expect, and it would require only a little bit of cofiguration, such as this:

server {
    listen 80;
    return 301 https://$host$request_uri;
server {
    listen 443 ssl;
    ssl_certificate      ssl/;
    ssl_certificate_key  ssl/;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;  # SSLv3 is insecure
    location / {proxy_pass;}

(This is adapated from a real nginx config file)

For initial development purposes, the HTTP server could be the one built in to Django. And as development goes forward, y'all could switch to something like Gunicorn. (Gunicorn integrates well with Django, as it's a WSGI HTTP server.)

#7 Updated by bmbouter over 2 years ago

Recently I've seen that all Vagrant environments use the user vagrant, so I don't think having everything run in the devel environment as user 'vagrant' as a bad thing. I'm +1 to closing this as WONTFIX.

#8 Updated by daviddavis over 2 years ago

  • Status changed from NEW to CLOSED - WONTFIX

bmbouter agreed. I'll close this out and if any objects, they can reopen.

#9 Updated by daviddavis over 1 year ago

  • Sprint/Milestone set to 3.0.0

#10 Updated by bmbouter over 1 year ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF