Running pserve as another user causes import error

[Mark Huang]

Hi all,

I recently transferred all my code to a production server and was trying to start my application as another user. I am using Debian and running as root. I entered the following command:

pserve production.ini --user=www-data --group=www-data start

This caused an import error: "No module named resource"

I thought I didn't install the necessary packages to run my application so I re downloaded everything again as root. It still didn't work. I'm thinking if this has to do with a permissions issue, www-data user doesn't have access to the modules in my virtual environment created by the root user.

However if I just run pserve production.ini start, I get no such errors. Can anybody help me?

Regards,
Mark Huang

[Jonathan Vanasco]

I'm just wondering -- do you get the same errors with --user or --
group as you do with both --user & --group ?

i typically deploy like this:

$ sudo bash
$ su www-data
$ cd /var/www/virtual_envs
$ virtualenv maypp-2.7 ## or whatever python version
$ source /var/www/virtual_envs/maypp-2.7/bin/activate
$ cd /var/www/sites
# place the site under something like /var/www/sites/myapp
( maybe you have releases, maybe its scm )
$ cd /var/www/sites/myapp/--path--to--egg
$ python setup.py develop

The general idea, is that :
1. i have a non-root user for one or more web-apps
2. the virtualenvs are easy to find
3. the apps/structures are easy to find
4. the apps/structures are the user/group of the non-root web user.

i like to use nginx, so i'll use whatever stock non-root web user they
have to simplify my install ( www-data on ubuntu )

[Mike Orr]

It sounds like you're on the right track. The virtualenv needs to be
readable by the user and/or group the program is running as. Even if
certain modules have already been imported by the time pserve drops
privileges, you'll still run into trouble with application
supplemental modules.

When you run 'pserve' without switching users, the virtualenv files
are readable, so the problem doesn't arise.

I set up my production directory like this:

data/ -- Real-time data files, readable/writeable by www-data.
apps/ -- Version-controlled application files, readable by www-data
static/ -- Non-version-controlled application files (maintained
manually or via cron jobs), readable by www-data.
venv/ -- Virtual environments, readable by www-data.

Each application has a subdirectory under these; e.g., data/app1/ .
That way the permissions are simple and easy to audit: everything gets
"normal" permissions except the 'data' directory.

--
Mike Orr <slugg...@gmail.com>

[Mark Huang]

Thanks everyone.  I finally decided to re-do my setup and it worked.